大きなシステムを作ってお客さんに提供する仕事に関わる全ての人の参考になる一冊『曖昧性とのたたかい―体験的プロジェクトマネジメント論』（名内泰蔵）【Kindle・本】

大きなシステムを作ってお客さんに提供する仕事に関わる全ての人の参考になる一冊。

WEB上の決済システムの営業から人事のコンサルタントとして転職して最初の仕事は大規模な人事に関するシステム構築の仕事。前職では当たり前のように動いていた”システム”と呼ばれるものを自分で作る楽しさがある。

質の高いものを作るためにはまっすぐ実直にまじめに走り続けるしかない。

システムを作る人間の一人にこの本はそう伝えてくれる。誰もが一度は使ったことがあるであろうみどりの窓口のシステム構築に関わってきた著者がソフトウェア開発についてメモをしていたことが1冊の本にまとまった。

タイトルにも使われている「曖昧性」という言葉は開発に関わったことがある人であればピンとくるでしょう。はっきりと文面化されておらず、様々な資料やインタビューから読み取ることで全てを言葉にすることが難しいシステムの仕様を決定し、お客さんにシステムの内容を承認してもらい、開発を行う。

完成するまで成果物が見えないシステム開発だからこそ”曖昧性”という言葉が使われている。開発を行う全ての人が”曖昧性”にどう向き合い、どう自分の答えをぶつけていくのかが大切になる。曖昧だからこそ、リスクヘッジをしないといけないし、苦労もある。難易度も高い。

だからこそ、やり遂げた時の喜びは大きくなるのだろう。

まだ、1つの大きなシステム開発をやりとげたことはないので、やり遂げた場にいたいと強く思うお仕事の日々。

【引用】

日立製作所に在籍していた筆者は、昭和39年に日本初の本格的オンラインリアルタイムシステムである国鉄のみどりの窓口システム（通称「マルス」）の開発に参加

プロジェクトマネジメントの妙薬や“銀の弾丸は存在しない

【メモ】

スコープの早期明確化、スコープの膨張抑制、スコープの変更（あるいは変動）抑制がプロジェクトをなんとか成功裏におさめる鍵となる。すなわち、スコープマネジメント

プロジェクト計画段階、基本設計段階から、「人は間違え、機械は壊れ、バグは残ると覚悟せよ」と考え、最悪事態への備え（prepare for the worst）と、どんな困難でも負けずに突き進む

受注合戦というのは、顧客、自社、コンペチタが、似て非なる三者三様のシステム仕様の解釈に基いて、最低契約金額を決めるプロセスになってしまうのである。これを「曖昧の三角関係」と呼ぶ

あとで予算増額を要請をせざるを得ないとしても、その場合には第三者を納得させることができる「予算増額要請の正当性」の論拠を、契約時から準備しておかなければならない。すなわち見積りおよび契約時には、その時点で「想定したシステム仕様」を可能な限り明確にすることである。この明確化を怠れば、予算増額要請の論拠が失われてしまう

「正体がよく見えず、ついつい巨大化しがちな、システムという怪獣をいかにして丈夫な檻に閉じ込めるか」が大口赤字回避の課題

どうせ契約後にはっきりさせるしか方法はないなどと最初からあきらめてしまうのは間違いだ。時間が許すかぎり、顧客に対して何度も質問し、要求事項のより正確な文書化に努めて、曖昧さを少しでも減らすべき

バリー・W・ベームは出荷までの最適スケジュール時間T（月）はであるとした。たとえば所要人月が64人月の場合には、10ヶ月の工期ということになる

納期の定義には「仕様凍結後○ヶ月」とか「○月×日、仕様凍結を前提として」というような文言を入れておきたい

プロトタイピング方式は、仕様確定までの要員派遣契約の間で最大限活用してもらい、早期仕様確定に役立てるのが最も有効な利用法であろう。そして、仕様確定後に請負契約としてもらうべき

ファンクションポイント法（Function Point Method）：1979年にIBMのAllan J. Albrecht 氏が考案したシステム規模を測定する手法。それまでに主流であったステップ数（Lines ofCode：LOC）でシステム規模を測定する方法が適当な指標とはならなくなったために考案された。ファンクションポイント法では、システムが持つ機能（ファンクション）を切り出し、1つの機能がどれだけ複雑かを評価し、点数化（ポイント化）する。その点数に一定の係数を掛け、システム全体の規模を定量的に計測する。ここで使われる機能とはユーザー要件から導出されるものであるため、仕様が確定してから再度計測しなければ、見積り精度は上がらないとされている。

一般にシステムの機能とは、なんらかの入力（x）を与えて、しかるべき処理Fを行い、結果としてF(x)を出力することである。このようなシステムの完成度を検証するためには、入力xを変えてみて常に正しい結果F(x)が出力されることを検証しなければならない

スーパーSEとは、顧客予算に合わせて、顧客の希望業務をなんとかこなせるシステムを提案、設計できるSE

仕様確定は、できるだけ早く、かつ詳しく、そして小さく決めることがポイントである。時間がかかることも、仕様が膨らむことも、すべて、そのあとに続く開発に許される時間と予算を圧迫することになる

実現方式を云々する前に、まず業務仕様を固めることが第一歩であることを強力に顧客に訴えるべき

「最良の業務改善はその業務自体をやめることである」

レビュー時間も2時間以内に抑えたい。これは人間の注意力が持続する限界はほぼ2時間と言われているから

要求仕様決定段階における仕様変更コストを1としたとき、テスト段階で直すと20倍、納入時点で直すと200倍かかる

稼働前後の修正変更は絶対禁止バグであれ仕様変更であれ、修正・変更は工程混乱の元凶である。システム開発の終盤、総合テスト工程以降では、厳重な変更管理が必要である。特にシステム稼働開始前後数ヶ月（最低2ヶ月）の仕様変更は稼働に不可欠の機能を除き、絶対禁止

悪い報告がタイムリーになされないのは部下の躾の悪さより、報告を受けたときのマネジャーの対応に大半の非があると考えて間違いない

遅れているプロジェクトに人員を補充するとスケジュールはさらに遅れる。補充しないで放置するとプロジェクトは壊滅する

曖昧性が生じていたのは、「×××の場合は○○○する」という類の仕様の書き方にある。「それでは、×××でない場合はどうするのですか？」と問うと必ずしもすぐには答が出てこないという状況にあった。これは何も国鉄だけの問題ではなく、大半の顧客から最初に提示される業務プログラムの仕様はこういう個別事例の仕様、いわば「点仕様」となっていた。よくても、せいぜいいくつかの例の関連性を示す「線仕様」になっていた。ところがプログラムを作ろうとするには、すべての場合を規定した「面仕様」になっていないと困るのである

【手に入れたきっかけ】

Kindleキャンペーン

【オススメ度】

★★★★★

曖昧性とのたたかい