2009-08

IT系の初心者向け啓蒙書や資格本を多く手がける著者による、

• IT業界(SE)に興味がある人、目指す人
• 業務でSEと接することになった人

のための軽めの読み物。

この本一冊でSEが何をしてるかとか、開発と運用の違いとか、システム開発における一連の流れとか、SEとユーザの間に起こる問題とか、そういったことは一通り理解はできる。
理解はできるが、果たして本書がターゲットとする層に上手く理解されるかというと難しいところもあると感じる。
というのも、本書は少々冗談が過ぎたり、極端に走ることが多いからだ。
※いや極端じゃないよ、そういうのばっかりだよという現場もあるのかもしれない。私には極端に見えるが。

ITの世界をまあ知っている人にとっては冗談や極端の部分の差は分かる。
でもそうじゃない人にとっては、多分その辺の差はわかりにくい。
※SEという職種は・・とか言ってる部分の何割かは極端であると思う。

第三章の「ユーザとSEの胸のうち」も、やはりちょっと極端な例に思える。
ここの登場人物はユーザもSEもシステムを真剣には考えていない。
しかし現実にはSEもユーザももう少し真剣にシステムを考えていて、でもやはりSEとユーザの間には齟齬が発生し、結果的に上手く行かないことが多いということなのだろう。

まあそのテーマは新書では手が余る内容という気もするので、こういう軽い読み物系になるのはマーケティング戦略としては正しいのかもしれない。

同じ著者の本としては、以下の書は分かりやすい。
SE/プログラマを目指す人、ネットワークに自信が無い人にはオススメである。

SE/プログラマの人には、続けて以下のサイトをオススメしたい。
3分間ネットワーキング
このサイトの内容は、本にもなっている。

以下、自分のメモ。

・運用系と開発系の違い
・プログラマはアーティストか大工さんか
・営業と開発。技術習得か顧客獲得か
・役所の庶務課とIT企業のオペレータ
・業務スキルと技術スキル。営業は業務スキルはあるが。
・要求定義と要件定義
　依頼主の条件が要求定義
　その中でシステム化するところが要件定義
・学部生は問題解決の方法、マスターは問題解決の方法を創り出すこと、ドクターは問題を見つけること。
・シンクライアント(メインフレーム)->ファットクライアント(エンドユーザーコンピューティング EUC)->シンクライアント(セキュリティ、個人情報)->リッチクライアント
・EDIはアダプタ
・EDIからEAによる標準化へ

随分前に買ったまま積ん読になっていた勝間和代氏のフレームワーク本。
さすがによくまとまっているなあ。
オススメ書籍一覧もあるし、最初のガイドとして最適ではないかと思う。

・普段から、最低限2*2のマトリックスか既存のフレームワークで物事を整理
・全ての思考を仮設からスタート
・ロジカル・シンキングをこなした上で、ラテラル・シンキング水平思考力へ
　ロジカル・シンキング-絞り込む
　ラテラル・シンキング-広げる
・取り返しが付かないような失敗以外の失敗を繰り返して学習する
・統計重要
・身の回りの分かっている数字を記録する
・複数の仮設を立て、比較する
・要領のいい人と悪い人との違いというのは、1回数字に落としてやってるか、なんとなくやっているか
・他人に対しては信頼から始める。囚人のジレンマモデル。

ちなみに勝間さんについて、最近のTwitter騒動を見てこれはすごい人だと再認識した。
アウトプット早い！、多い！、と本書籍の自身の主張まさにそのまま。
これは仕事できるわという感じでした。

• 「Twitter」が日本でブレークするための条件　勝間和代
• 勝間和代 (kazuyo_k) on Twitter

ソフトウェア技術者ならず、見積りをする全ての人にオススメしたい本。

見積もりにはアート(技法)としての見積もりとサイエンスとしての見積もりがあり、本書ではアートとしての見積もりに重きを置く、と書かれており、実際さまざまな見積もり技法について説明している。

その技法は、恐らく多くの見積もりをする人にとって、十分に役に立つものだと思う。
本書の188ページにある例を引用する。

例えば、6ヶ月のスケジュールがあったとしよう。あなたは、最初のマイルストーンを4週間で達成する計画を立てた。しかし、実際には6週間かかってしまった。この場合、あなたなら次のうちどれを選ぶだろうか。

• 失った2週間は、スケジュールの後の方で埋め合わせられると考える。
• スケジュールの合計の2週間を追加する。
• 誤差の大きさ(この場合は50%)をスケジュール全体に掛け合わせる。

もっともありがちなのは、1番目の選択肢だろう。通常は次のような論法になる。「要求にかける時間が予定より少し長かった。だが、もう要求は固まった。残りの時間を切り詰めよう。コーディングとテストの間で不足分を埋め合わせられるはずだ」。しかし、1991年に300以上のプロジェクトについて調査した結果によると、プロジェクトが一度失った時間を埋め合わせることは、まず不可能であることが分かっている。それどころか、遅れはさらに広がる傾向にある。したがって、この選択肢がベストチョイスなることは、ほとんどないと思ってよい。
(中略)
よほどの例外を除いて、実際の結果が見積もり通りにならない場合の正しい選択肢は、3番目ということになる。

これを読んで思わずにやりとしたり、あるいは過去の見積もりを思い出す人も多いだろう。
そういう人にもオススメしたい。

実際本書には小難しい(サイエンスよりの)議論も存在するが、最初にアート(技法)に重きを置くと書かれている通り、すぐに役に立つ技法が沢山のっている、いわば見積もり技法のカタログ集と言える。
第9章の1例を挙げると、1点見積もりは実際には「最良ケース」に近くなってしまうことから、次のような公式を提案している。

期待ケース = [最良ケース + (4 * 最有力ケース) + 最悪ケース] / 6

例えば自分で以下のように機能追加の見積もりをしてみる。

• 最良ケース=5人日
• 最悪ケース=20人日
• 最有力ケース=10人日

この場合、より確度の高い1点見積もりを出すために期待ケースの見積もりを出すとすれば、
期待ケース = [5 + (4 * 10) + 20] / 6 = 65/6 = 約11人日
となる。
なお実際にありがちなのは、最良ケース=5人日をそのまま採用してしまうケースだと思う。

※この辺りの「公式」をより正確に理解しようとすると、統計学的知識が必要になるようである。(分散とか標準偏差とか)
※下記はよい本らしい。

・見積もりとターゲットとコミットメントは違うものだ。
　・見積もりは分析的なプロセスであり、確率論的な考え方をする。
　・ターゲットは、実現したいビジネス上の目標。
　・コミットメントは、定義された機能を特定の品質レベルを確保しながら期日までに納品するという約束。
　・よって、コミットメントが見積もりよりも挑戦的だったり、保守的だったりすることが当然ある。
・見積もりと計画の関係
　・見積もりのゴールは正確性であり、特定の結果を追求することではない。
　・計画のコールは特定の結果の追求。
・見積もりがシングルポイントで示される(例: 14週間)場合、それは現実的なものではない。
　実際は見積もりの皮を被ったターゲットである。
・あらゆる見積もりは、確率が含まれている。確率を明示した見積もりは良い見積もり。
　16週以内で完成する確率は0%
　18週以内で完成する確率は10%
　20週以内で完成する確率は50%
　22週以内で完成する確率は75%
　24週以内で完成する確率は90%
・自分のコミットメントが幅のある見積もりの中のどこに位置するのかを把握し、それに応じた計画を立てる。
・見積もりは予言ではない。
・よい見積もりとは、プロジェクトの責任者がターゲットを達成するためのコントロールを行ううえで、適正な意志決定ができる明確な視点を提供する見積もり。
・常人が直感的なセンスで考える「90%確か」は、実際には「30%確か」にほぼ近い。
・見積もりの幅を狭くするプレッシャーを感じたら、それが本当に存在するのか確認すべし。
・多くのビジネスでは、見積もりの予測可能性を重視する。(短かったり、安かったり、というのは結果)
・ソフトウェア業界には過少見積もりの問題がある。まず見積もりを多くすることから始める必要がある。
・優れたプロジェクトマネージャーは、見積もり誤差が実際の20%以内にあれば、プロジェクト完了に向けてナビゲートできる。がそれを超えれば難しい。
・即興の見積もりは止めよう。
・見積もりに必要なのは過去のプロジェクトの見積もりと実績。
・開発者の見積もりは既に十分に楽観的に短くなっているため、削ってはいけない。
・アクティビティの見落としも考慮する。
・ソフトウェア開発では、多くの問題について何千もの意志決定をする必要があるプロセスである。そのためそれぞれの意志決定の不確実性がプロジェクトの不確実性を引き起こす。よって、プロジェクトの見積もりは、プロセスの進行に応じて「不確実性のコーン(円錐)」を形成することになる。
・コーンはひとりでには狭くならない。狭くするためにはプロジェクトコントロールが必要。
・ソフトウェア開発は規模の不経済が適用される。プロジェクトが大きくなればなるほど、効率は悪くなる。(失敗プロジェクトになる可能性も高い)
・1点見積もりは、最悪ケースの見積もりと最良ケースの見積もりのうちの最良ケースの見積もりに近い。

・その他多数…

薄く平易な本なので簡単に分かった気にはなるが、多分実践しないとモノにはならない本。
アイデアは次の5つのステップで作られるというが、これだけ知ってもあまり意味はないだろう。

1. 資料集め。当面の課題に加えて、一般的な知識。
2. パズルの組み合わせ。仮のアイデアでも思いついたらメモしておく。色々組み合わせて試行錯誤する。
3. しばらく放置。なるようになるのに任せる。自身は音楽を聴いたりするなど、自分の想像力や感情を刺激するようにする。
4. 見つけた！という段階。常にそれを考えていることが必要。
5. 見つけたものを具体化する。現実の世界に生まれたばかりのアイデアを連れ出す。