プロジェクトが破綻する原因にトラックナンバー問題がある。知識が個人に独り占めされ様々なトラブルがおきるという問題だ。その人が事故や病気になれば破綻するし、或いはその人に問い合わせが集中して多忙になればチームは破綻する。これは個人が知識伝播…

1.DIへの賛否10年ほど前、DIはソフトウェア産業の問題を解決する銀の弾丸として喧伝され、それを実現するDIフレームワークのspringやseasarが登場した。DIはとても流行し最終的にはEJB3.0に取り込まれるまでになった。ではDIとは一体何者なのだろうか。ここ…

ソフトウェア再利用は開発効率と品質を向上させるための方法論の中でも最も重要なもののひとつである。だが、多くの組織はこの方法論の適用に対し積極的とは云えない。それはなぜだろうか。ヨードンは、その理由は４つあると説明している。・ソフトウェア工…

ソフトウェア再利用は開発効率と品質を向上させるための方法論の中でも最も重要なもののひとつである。だが、多くの組織はこの方法論の適用に対し積極的とは云えない。それはなぜだろうか。ヨードンは、その理由は４つあると説明している。・ソフトウェア工…

システム開発で仕様変更が発生した時に開発者たちは通常どうするのだろいか。ある開発者はこんな云い方をした。「先ずは仕様書を修正するのがスジだ。ただそれは時間との兼ね合いだ。より優先すべきはプログラムとテストであり、仕様書の修正は時間のある時…

[リーダブルコード]コメント：ライターズブロックを乗り越える これがJavaであれば、私ならテンプレートメソッドパターンで局所化しプログラム完了の遅延を図る。 テンプレートメソッドパターンではフックメソッドの実装を下位クラスに委ねる。このパターン…

[リーダブルコード]コメント：情報密度の濃さ：正確に書く なかなか面白いことを書いている。 もしも私がプログラマで、コードレビューでこのような指摘がでたらなかなか厳しいレビューアだなと思うだろうが確かにその通りである。行数カウンタなどの機能に…

色んな人が「オブジェクト指向やデザインパターンを中途半端な知識で使うな」という趣旨の事を仰っています正論です。パターンや設計手法は「考え方の見本」であり、それらを考えなしに使うというのは本末転倒です （中略） けれど私はやはり、「やりたいな…

継承は、新しい機能を追加するだけでなく、既存の機能を差し替えることにより、基本クラスを拡張することができます。具体的には、基本クラスのメソッド（あるいはプロパティ）を派生クラスで再定義して、置き換えるというものです。これは「メソッドのオー…

ここで、オブジェクト指向が禁止なら継承もできないのか、のように、裏返せば継承つかったらオブジェクト指向のような認識であるなら、メイヤーの「オブジェクト指向入門」２冊を隅から隅まで読んで出直すべきだ*1。 そこまで云うのであればこの人はその２冊…

JAVAの新機能ラムダ。関数型プログラム到来と絶賛されているが私はこの評価に戸惑いを覚える。そもそもこのラムダは関数型プログラムにパラダイムシフトできる人間だけがそのメリットを教授できる。一介のプログラマが手を出せる代物ではない。だが技術者に…

「仕様と違う結果」が起きる原因をバグと云う。バグはエラーとは異なる概念だ。 ログイン画面を考えてみよう。 ユーザーIDとパスワードを正しく入力し、ログインボタンを押すとトップ画面に移る。これは正常系というログインの本来の事象だ。 これに対し、ユ…

システム開発に於けるソースコードの正しさとは何か。バグがないこと、ではない。仕様書の記載をソースコードが守っていることだ。仕様書はソースコードのルールである。遵守していればそのソースコードは正しくそうでなければそのソースコードは正しくない…

仕様書が曖昧になる要因に雛形の不備がある。例えばオブジェクト指向設計に於いてはクラス仕様書は必須である。所がクラス仕様書の雛形がない現場もある。そのような現場ではしばしば他の仕様書の雛形が代用される。勿論出来ないことはないことはない。だが…

もしも技術者が常に「明確で論理的な仕様書」を作成できるなら、システム開発など児戯に等しい。然し残念ながら我々にはその能力がない。我々の作る仕様書にはどこかに曖昧な表現がある。この曖昧な表現は人を混乱させ彼等に間違った解釈をさせる。混乱は進…

前に知り合いの営業マンから突然連絡が来たことがある。私を必要としている案件があるというものだったが単価が安くて断ろうとした。然し彼女は面談だけでも出て欲しいと食い下がる。どうやら彼女のビジネスパートナーが技術者を紹介して欲しいと彼女に云っ…

鬼平犯科帳に「盗賊二筋道」という話がある。あらすじはこうだ。高萩の捨五郎という盗人が子供を助けようとして侍に切られてしまう。捨五郎は怪我を理由に盗みの手助けという仕事を断るのだが、それを逆恨みされ、口合人の寺尾の治兵衛と共に命を狙われてし…

システム開発に於いてもしもプラットフォームやフレームワーク、開発ガイドがないならスクラッチで作るしかない。つまり技術者の属人性に頼りはじめから作るしかない。 現代のシステム開発で其れは非現実的である。何故ならプロジェクトのメンバーを自社社員…

どうすれば曖昧な仕様書を見つけることができるか。この問題に対する答えは簡単ではない。これまで多くの者が取り組み、そして挫折してきた。しかし出来ないことではない。画面の必須項目チェックや桁数、型、和名、英名などの制約、関連性や整合性など、仕…

昨日は曖昧な仕様書に気づかない技術者の話をしたが、ではどうすれば曖昧な仕様書を見つけることができるのだろうか。いや、そもそもそんなことができるのだろうか。答えはYESだ。勿論簡単ではない。これまでその問題に多くの者が取り組み挫折してきた経緯か…

皆さんは、自分が仕様書を本当に理解しているか自分自身に問いかけをしているだろうか。先日、私はある仕様書について担当者に質問をした。その仕様書は酷く曖昧で一目ではとても理解できない内容だったからだ。するとその担当者は「これは〜という意味です…

ある漫画で、風俗店に風俗嬢を紹介するスカウトマンの話が出てくる。彼等は街で女の子に声をかけ風俗店に紹介する。そして面談。果たして女の子が採用されれば、その後の女の子の売り上げの1割程度がスカウトマンにバックされる。毎月である。女の子が200万…

JUnitはXPに於けるテストファーストプラクティスのツールである。もちろんXP以外でも採用されるがそれにしてもアジャイルである。このツールはテストファースト、則ちテストコードを書いてからプログラミングを始めるという手法の為にある。だが多くの現場は…

Webシステムの概要説明で「我々のシステムはMVCパターンを使っている」というのは些か問題である。なぜなら「MVCパターンを使っている」といった表現は何も説明していないに等しいからである。現代のWebシステム開発では殆どがMVCパターンを採用している。MV…

要求定義の最大の難所は次の確認である。⑴顧客の真の要求をベンダーが理解しているか(機能要求と非機能要求)⑵予算と期日を守れるのか(実現性)要求定義工程ではベンダーが「叩き台」を元にヒアリングをする。その結果が要求仕様書となる。だが、これはノウハ…

小保方女史のSTAP細胞。この世紀の発見の本質は汎用化と多態性である。どの業界に於いても技術者にとって汎用化＆多態性はエキサイティングだ。それにしても、小保方女史のアプローチは斬新でネイチャー誌に酷評される程というから驚きだ。レビューアに「生…

JavaプログラマGoldの試験範囲にデザインパターンの理解がある。ではデザインとはどのようなパターンか。JavaプログラマGold教科書にはこうある。「パターンはある文脈の問題に対して繰り返し適用可能な解決策と定義されています。文脈とは取り巻く環境、状…

プロジェクトの結果は管理者の裁量で決まる。だからこそプロジェクトの責任者はプロジェクトを成功に導くために良い管理者を選定しなければならない。では良い管理者とはどんな管理者のことか。よくあるイメージは「プロジェクトをいくつも成功させている管…