トップ > 読書 > 【要約】人月の神話

【要約】人月の神話

読書 SE 仕事

著者

フレデリック・ブルックス

書籍の概要

IBM360システムおよびOS/360の開発リーダーであった著者が、
開発の過程で遭遇したさまざまな問題にどのように対処したか。
その結果は正しかったのか。
今も繰り返してなされる間違った判断と認識。

本書では、未だに色あせてない議論がなされており、
ソフトウェア開発管理者・プログラマのみならず、
現在のパソコンの神話ならぬ真実の世界を知りたい一般のパソコンユーザも
読んでおくべき書である。

Amazon 「BOOK」データベースより抜粋

手にとってみた経緯

私はSIerに勤めています。
この著書はこの業界では知らない人はいない方です。
又は、タイトルだけでも聞いたことがある方もいらっしゃるのではないでしょうか？

この名著たる所以を知りたい事もあり、
又、自身のマネジメントスキル向上の一環として手に取る事にしました。

この記事は2017年にEvernoteにまとめた情報を推敲し、公開しているものになります。


特徴

対象読者

プロジェクトマネージャ
システムアーキテクト
プログラマ

良い点

工期と工数を逆転させてシステムが作れる訳がない。
その感覚として当たり前の事を事例やデータを元に論じられてる。

又、プロジェクトマネージャがどこに視点を向けなければならないかも論じられており、
古典ではあるもののその考え方は参考になる。

悪い点

海外の著書の為、少々言い回しが独特且つ冗長である。

内容紹介

このエリアでは特に私が気に入っている点をポイント！として記載しておく。

ポイント！ 遅れているソフトウェアプロジェクトへの要員追加はさらに遅らせるだけだ。
　→ ゆとりの法則にも記載のある内容だが、
　　 どうしてもこの案を打たなければならない場合もある。
　　 現場メンバーや顧客に説明の上、この副作用を理解しておく事。
　　 ※ 教育コスト、コミュニケーションの増加によるコスト、タスク再配分作業によるコスト

ポイント！ システム全体のコンセプトは完全性を要するものであり、
システムアーキテクトがトップダウン方式ですべてを設計しなければならない。
そしてそれらの仕事は小数で実施されるべきである。（思想は大人数では守れない）
※ 互いに意見が同じくして共鳴しているメンバー同士であれば設計は可能である。
　→ 超上流、上流工程に大量の要員を投入するプロジェクトがあるが、
　　 作業分解が出来ていない場合、プロジェクトは混乱を極める。
　　 思想を具現化出来る人々にて整理し、その後、具現化する必要がある為、
　　 この工程を短縮する事は相当に難しい。
　　 ※ 沢山人が居ればうまく行く工程ではない。

ポイント！ マネージャの基本的な仕事は全員を同じ方向に進ませることである。
主要な日課は意思決定ではなく、コミュニケーションを図ることである。
文章があれば作業負荷は軽減される。
　→ 文章にする事の力を私は経験上強く知っている。
　　 口頭では忘れ去られてしまったり、後で読み返せない。
　　 又、日本語が苦手な方も口頭では誤解を生む事は往々にして発生する。
　　 方針を定め、具体的な例を文章化し、説明会を設け、更にフィードバックを受ける。
　　 ここまでしてもプロジェクトは真っ直ぐに進まないもので、
　　 これをしなければどうなるかは火を見るより明らかだ。

ポイント！ スケジュールはある日突然遅延するのではなく、
徐々に忍び寄ってくるものである。
　→ 優れたプロジェクトマネージャ、プロジェクトリーダは良く気が付く。
　　 1つ1つの事象から違和感を嗅ぎ分ける嗅覚が鋭いのだ。
　　 この嗅覚から起こり得る未来の問題を彼らは取り除かねばならない。
　　 起きた事の意思決定をしているだけで満足しては駄目なのだ。

ポイント！ 私の目安では全体のスケジュール「100%」に対して
設計は33.33%
CDは16.67%
UTは25.00%
後続は25.00%を割り当てる。
　→ 超概算見積もりの場合に要件定義の規模感から割合で算出する。
　　 自社の割合を元に算出するのが生産性の担保も取れて良いが、
　　 他の軸も持っておくと良いだろう。
　　 IPAも同様の指標を発表している為、そちらも参考にすると良い。

ポイント！ プログラムを修正する人が使用する文章では、
単にプログラムがどうなっているかを示すのではなく、
なぜそうなっている事を伝えるべきだ。

目的こそ理解の鍵である。
　→ 現行踏襲プロジェクトやビジネスルールを明記しないプロジェクトの場合、
　　 コードが正の振る舞いが良く分からない事象が発生する。
　　 少なくとも何を達成する為のコードなのか。は文章化が必要だ。
　　 又は、文章化が困難な場合は、仕様ホルダーの長期確保と
　　 スキルトランスファを行おう。

次のアクション

その工期と要員は妥当化否かを判断出来る様になろう。
※ IPAの統計データがこの国のプロジェクトであれば参考になるだろう。
　きな臭いという感覚も必要だが、データの裏付けも必要だ。

プロジェクトの不吉な予感を感じ取れる多角的な受け取り方をしよう。
パブロフの犬の様な反射では、予見する力は養われない。

自身が設計する設計書は目的が記載出来ているだろうか？
ただ作る為だけの設計を行うと、ソフトウェアは結合時に崩壊する。
外出しでも良い為、ビジネスルールを整理する時間を設けよう。
この書籍を読んだ方が、何かしらの仕事のヒントを得られれば、幸いです。

↓クリックしていただければ励みになります！
書評、レビュー 本ブログ・テーマ
書評、レビュー


miyamori_k 読者になる

広告を非表示にする
コメントを書く