こんにちは
「知識ゼロから学ぶソフトウェアプロジェクト管理」を読んだ感想です。
書籍
対象
- エンジニア視点のソフトウェア開発におけるプロジェクト管理について学びたい人
- ソフトウェア開発の体制を改善したいけど何をすれば良いか分からない人
本書は「エンジニア」寄りの視点からソフトウェア開発におけるプロジェクト管理について，筆者の経験談と各種参考文献を交えて解説しています。
ノウハウ集的な内容であり，プロジェクト管理という正解を出しにくい内容についての本ですが，砕けた文体なのもあって比較的楽しく読み進めることが出来ました。
自組織の体制について見直したい人向けの本だと感じます。
メモ
最早，メモというより個人の感想です。
個人的に本書が伝えたい内容は以下の3点だと思った。
- 「時間が無い」を言い訳に問題から目を背けるな
- ソフトウェア開発では、残業と人員増加はよく考えてから行え
- ソフトウェア開発手法の正解は分からないが、失敗しないようにある程度の制御は出来る
第1章 まえがき
PMBOK: 専門家がプロジェクト成功への方法論やスキルなどをまとめたもの
CMMI: システム開発組織のプロセス成熟度をモデル化したもの
PMBOKとかCMMIなどが話題になるけど、登場当初と今を比較すると内容が膨大になっており、理解した頃には古い情報になっているかもしれない。
IT技術だけでなく他分野にも同じ事が言えると思う。
知識や事柄を表面的に理解するだけでなく、それが誕生するまでの背景や思想を学ぶことで自分の経験に活かしていきたいね。
時間が無い・忙しいを言い訳にして、改善する事を怠り、同じ過ちを繰返す。
自分も能力不足やミスした時の言い訳、面倒事を避けるために「時間が無い」と言うことがあるので、マジで便利な言葉だと思う。
時間が無いのは皆同じなので、言わないように反省する。
第2章 典型的な失敗例
デンバー空港、みずほ銀行、アリアン5ロケットのソフトウェア問題について
当事者になりたくない内容なので、賢者になるために歴史を学びたいと思う。
内容と直接関係ないけど、結果論で放言高論しすぎないようにしたいと感じた。
モチベーションの欠如は事故を引き起こしやすい
その通りだと思うけど、人間なので難しい問題だとも感じる。
仕事に対する意識の差は、サビ残やハラスメントを引き起こしやすいしね。
第3章 人が全て
日本と海外のIT企業を比較して、日本企業の生産効率が悪い理由が述べられている。
プロジェクトがうまくいかなかった例を提示し、その原因と解決策について述べている点は良かったが、エンジニア視点の話の展開の仕方に違和感が感じた。
日本と海外のIT企業を比較して、日本のソフトウェア開発体制が如何に悪いかが述べられている。
ただ、マイクロソフトを比較対象として、日本のIT企業の開発体制は遅れているって言うのはどうなの...？って感じた。
労働環境だけで言えば、海外のゲーム開発には「クランチ」と呼ばれる文化があり、これは日本企業以上に過酷だと思う(反例を上げることに意味はないけどね)。
まぁ、日本企業が遅れているのは正しい気がする。
お持ち帰り検討が多すぎて判断が遅いし、効率化を図ろうとすると「仕事が無くなる」って文句言う人もいるしね(????)
en.wikipedia.org
wired.jp
第4章 はじめよければ全てよし
エンジニア的には仕様変更は起きて欲しくない
顧客が仕様変更を求めてる時に「やりたくない」とは言えないので、なるべくプロジェクトの前半で起こるように動く。
アジャイル開発を取り入れるなど。
テスト可能な要求はUMLで書き起こせる状態に近い
そうだなと強く思うけど、そこまで整ってる要求仕様は見たことない...
パトリオット: ミサイル迎撃システム
第5章 ちゃんと設計しろって言うけど
要求仕様書は詳細に記述しよう
ソフトウェアの動作だけ、UIの概要図を載せただけはただの概要書だと思う。
無駄なコミュニケーションが増える要因だし、仕様変更時の対応コストも大きいので可能な限り正確に記述してほしいね。
(急な仕様変更で今まで書いた労力が無駄になるから書きたくない気持ちも分かるけどね)
デザインパターン
共通理解が進みやすいので、ソースコードの保守性も上がりやすい気がする。
もうバッファオーバフローは理解するべき技術でもない
そうかもしれないけど、ちょっとここは引っかかる。
Microsoftがセキュリティと開発ライフサイクルについてのアイデアをまとめている
learn.microsoft.com
McCabe数: 循環的複雑度
サイクロマティック複雑度のことっぽい。
Thomas McCabeが開発した。
第6章 オーソドックスか？アジャイルか？
ウォーターフォールは前工程に問題が無いことが期待されている
問題が無いのが一番だが、必要な手戻りは行うべきであり、これはアジャイル開発だろうが同じ。
スクラムにおけるニワトリとブタの寓話
適切な場面では鳴いたほうが良いが、思い付きを鳴きまくられるとミンチにしたくなる。
自称アジャイルほどテストしない
アジャイル開発とは．．．？？？？ってなるよね。
必ずしも開発手法に即する必要はないけど、やらない理由を探すのは良くないよね。
可能ならばテストはした方が良い
当たり前だけど、気分．コスト的に中々出来ないよね。
未来への先行投資だと思って、今後は可能な限りやっていきたい(自戒の念)
ソースコードは綺麗な方が良い
何を基準に綺麗かを判断するのが難しいけど、個人的にはコーディング規約準拠よりも処理の簡潔さだと思う。
if文で全列挙するより、条件に潜む共通事項を見つけ出し、それを簡素な処理にまとめられる能力かな...？
完全な偏見だけど、共通事項を見つけ出せる人のプログラムは、スコープが浅く，単純かつ合理的で芸術性が高いように感じる。
第7章 PMBOK使えばいいの？
Microsoft Project
プロジェクト管理ツールで、Officeとは別形態っぽい。
パッと見は使いやすそうだけど、Office対象外、プロプライエタリな点が気になる。
www.microsoft.com
1日の作業内容を円グラフで可視化してみる
何も決まらない無駄な会議の多さに驚愕できるかも。
画面上の文章を読み上げるだけの会議は何なんだろうね。(おっさん版の絵本読み聞かせ？？？)
人件費VS設備費
ソフトウェア開発における費用の大部分は人件費であり、コスト削減の最適手法は生産性の低いエンジニアを解雇すること(レイオフ)。
海外企業は気軽にレイオフするイメージがある。
日本企業は気軽に解雇出来ない点では安心だけど、組織の腐敗が進みやすい点が明確な欠点だね。
プログラミングの開発コスト
プログラミングのコストより、設計やテスト、プロマネのコストの方が高い。
プログラミングに関する事を優先して勉強する傾向にあるけど、本当に重要なのはそれ以外かもね。
週40時間労働でスケジュールに余裕がある場合はバグが少ない
分かりきった事実だが、何故か出来ない。悲しいね。
第8章 それでもプロジェクトマネージメントが うまくいかない理由
オフショアリング
業務の一部を海外に移転、委託などすること。
日本人はバグ埋め込み率が低く、ソースコードの記述速度が早い傾向にある
米国プログラマは革新的な事に重きを置く傾向にあるらしい。
海外の文化的背景について理解できれば、この辺りの価値観の違いも理解できるかもね。
プロジェクト成功の鍵は人
人の能力差が仕事の出来を左右するのは残酷な事実だよね。
採用担当者は相手の潜在能力と性格を見抜いてほしい。
ダイバーシティ
色々な属性の人から考え方を学ぶ。
確証バイアスに陥らない為にも有効だと強く感じる。
普段は週40時間労働、出荷直前に10%のプレッシャーを与えるのが良い
プレッシャーは少しあったほうが効率が良くなるのも理解できる。
ただ、残業はマジで辞めてほしい。意味もなく残響する人も悪です。
週末は複雑な仕事をしない方が良い
身が入らないからね。気持ち的には土曜日だし。
自分もいつもの5倍マシ位やる気がない。
ポストモーテム
「死後の」とかの意味があるらしい。
ソフトウェア開発では検死である。死斑もよく確認しよう。
ソフトウェアの世界
生存者バイアスで語られがち
感想
PMBOK/CMMI/アジャイル開発について、エンジニア視点で解説している本を探している時に見つけました。
ソフトウェア開発におけるベストプラクティスについて、大量の参考文献と筆者の経験談から語られており、自分の求めていた教科書的な内容(用語説明的なやつ)とは異なりましたが読んで良かったと感じました。
中間管理職でも無い一般従業員の自分が実践出来る事は多くないですが、可能な範囲で実践していきたいと思います。
今度はPM視点のソフトウェア開発について解説している書籍も読んでみたいね。
