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

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

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

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

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

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

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

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

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

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

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

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

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

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

ホーアトリプル導入にはプログラム正当性確保というメリットがあるが設計者の作業負荷増大というデメリットもある。ではどんな作業負荷があるのか。ひとつは設計者が仕様書に表明を書かなければならなくなるということだ。通常のプロジェクトでは設計者は仕…

コンピュータ理論のひとつにホア論理というのがある。この論理の中心はHoare Tripleという式である。{P}C{Q} この式はプログラム実行による状態変化を表す。CはPの状態に始まりQの状態で終わる。Cはコマンド、Pは事前状態、Qは事後状態である。プログラムの…

ソフトウェアの寿命とは何時か。誰もが認めるのは、寿命はソフトウェアが使われなくなった時である、という考えだ。企業システムの多くは長期運用が前提だ。運用されなくなれば寿命がきたと云える。その寿命が早ければ開発費を回収できなくなる。では寿命を…

よくこんな質問がある。「例外は何か」答えはこうだ。「表明違反により起きたイベントである」呼び出し側がこのイベントを放置すれば処理は失敗に終わる。そうなりたくなければ例外を捕捉し リトライによる回復 を試せばよい。それでも成功しなければ今度は …

バグとは何かという質問に答えられないプログラマはおそらく居ないだろう。だが、その答えは誰もが同じではない。或る人は「バグとは不具合である。」と云い、或る人は「バグとは欠陥である。」と云い、或る人は「バグとはエラーである。」と云い、或る人は…

ノウハウという資産を過去のSIer達は見つけ育てていた。其れこそ会社の成長の源だと知っていたからだ。ノウハウとは無能技術者が有能技術者に勝つ知恵である。誰でもノウハウがあれば有能技術者と渡り合える。成果を出せる。 いろいろな社員をかかえる会社が…

COBOLやPL-1、Cの時代は「バグ率」は品質のひとつに過ぎなかった。所が最近は品質＝「バグ率」と皆考えるようになった。少なくとも私にはそう思える。SIerの優秀なSEもバグ率には熱心だが、変更性、解析性、環境性、規格性等々の品質は測ろうともしない。 何…

管理について、そもそも進捗管理をエクセルでやるというのはどうなんだろうと思う。RedMineのようなツールを使えば管理コストは減るのにこれを使わない理由は彼らに知識がないからとしか思えない。エクセルで日々の進捗をつけていたら時間はいくらあっても足…

前回説明したようにassert文を使えば正しいソフトウェアを書く手助けになる。これはassert文の最も重要な使命だ。ある重要な原則がある。すなわち「契約による設計」の原則である。あるメソッドを呼び出すということはあるサービスを受ける契約を結ぶという…

JavaプログラマGold教科書は名前に反し内容は初心者向けである。とは云いつつ、やはり初心者には難しい箇所もある。その一つがアサーションである。 アサーションとは、プログラマが前提としている条件をチェックし、プログラムの正しい動きを保障するための…

しばらくこのブログを放置していたせいで過去の日記が全てなくなっていた。それはそれで残念だが、これを機会に改めて日記を再開したいと思う。 さて、先日知人である山本道子さんが翔泳社から「JavaプログラマGold教科書」を上梓した。本の売れ行きは上々の…