SE の教科書【完全版】

『SE の教科書【完全版】』（深沢隆司，技術評論社，2009年11月25日）を読了。

業務システム開発については，意味合い的に特に難しいことはありません。「顧客の業務を実現，効率化するコンピュータシステムの開発」といったところです。

ですから，「業務システム開発」の意味する範囲はとても広く，企業・組織によってとらえ方はさまざまですし，その境界線も明確ではありません。対象とするユーザーの業種によっても，まったく異なってくると思います。（p. 26）

業務システムと言っても，色々なシステムがある。

細かい部分で不満を持たれない，詳細な仕様を最初からきちんと作っていけばよいだけです。（p. 58）

仕様の決定を先送りしない。

プロジェクトのあらゆる重要な決定事項が会議によって公式に決定されるのであれば，会議はプロジェクトにとって最も重要な公式コミュニケーションの場です。そして，会議の成果物は「決定事項」です。（p. 106）

プロジェクトにおける会議の目的は，何かを決定すること。

問題点を指摘しているだけでは何にもなりませんので，これらすべてを解決するにはどうすべきかを考えた結果，以下の二つを作成すればよいという結論にたどり着きました。（p. 142 - 143）

初期段階から SE（仕様策定者）とプログラマー（実装担当者）の意識合わせを行いながら作成する，最低限のドキュメント

そのドキュメントの内容をリリースレベルで実現したソースプログラム

SE とプログラマーの意識合わせを行いながら，最低限のドキュメントを作成する。

失敗を繰り返す組織では，過去にプロジェクトがうまくいっていなかったとしても，原因を特定していないし，解明してもいません。そして，そもそも組織全体として，コミュニケーション（伝言）の価値を軽く考えているので，そこに時間やパワーを費やす必要性を，決定権を持っている人が感じていません。コミュニケーションを軽く考えていることは，「知らない」ことを簡単にバカにする姿勢や，他の組織をネタにどうでもいいような悪口を言う行動に表れてきますので，しばらく見ているとわかる場合があります。（p. 202）

コミュニケーションの価値を理解し，適切なコミュニケーションをとる。

トヨタでは，トップから末端まで全員が「現場を知る」「現場経験者である」ということが徹底されていると聞きます。（p. 232）

私の会社において，技術系の職種は「現場を知る」「現場経験者である」ということが徹底されている。

この階層構造を作り上げるにあたって，ルールといえるのは次の二つだけです。（p. 261）

下の階層のものがすべて揃ったら，上のものが完成したことになる

いちばん末端（いちばん下の階層）の要素は，「完成が検証できない成果物」となっていなければならない

小さく分解して，上のものを完成させる。

日本人は，もともとマネジメントよりはモノ作りのほうが好きな民族なのだと思います。

ですから，最近よく「マネジャーになりたがらない人が多い」という声を聞きますし，それを根拠に「最近の若い人たちはやる気がない」などと言う場合もありますが，筆者には「彼らはよくわかっている」と感じられます。

正確に納得のいく形でマネジメントを教えてもらえることはほとんどありませんし，「仕事の中で自分でつかめ」というのなら，今よく見かけるマネジメントは本当につかむべきものでしょうか？筆者には，とてもそうは思えません。（p. 340）

マネジメントがなければ，モノ作りも大成しない。