読者です 読者をやめる 読者になる 読者になる

久保清隆のブログ

ライフハック、健康、旅行など、役立つ情報を書きます。

ソフトウェア開発を成功に導く法則

デッドライン

デッドライン

ソフトウェア開発の小説。
テーマはプロジェクト管理。
示唆に富む内容が多く、ソフトウェア開発に従事している技術者やマネジャーが読めば、考える良い材料になると思った。
以下、参考になった部分、具体的にどう実践するか考えていきたい部分を中心にまとめ。

【目次】
チャンスとの出会い
管理ごっこ
シリコン・バレジット
管理者の最初の仕事
支配者
世界最強のプロジェクト管理者
管理者の採用
リスク管理と生産性
人材管理の智将
モデルとシミュレーション
デッドライン:理想と現実
プロジェクトの数量化
プロセスの改良と変更
設計とデバッグの関係
残業の効果
あいまいな仕様書
対立解決指導者
対立と仲裁
プロジェクトの人数
ムダな会議の減らし方
問題解決の奇跡
プロジェクトの完成
101の教訓

ポイント

プロジェクト管理のハード面とソフト面
  • ハード面
    • PERTチャート
    • 状況報告
    • 人事部との連絡
    • 週会議の実施
    • 電子メールの活用
    • タイムカードの記入
    • 進捗状況の記録
    • プロジェクト目標の到達報告
    • 品質プログラム
  • ソフト面
    • 人材の選択
    • 適材適所
    • 士気の維持
    • チーム編成
正しい管理の4つの基本
  1. 適切な人材を雇用する
  2. その人材を適所にあてはめる
  3. 人々の士気を保つ
  4. チームの結束を固め、維持する
  • 上記以外のことは全部管理ごっこである。
生産性を高める方法
  • 短期的に生産性を高める方法などない。生産性は、長期的な投資によって向上する。
  • 短期的な効果を約束するものは、いんちきである可能性が高い。
リスク管理
  • リスクを管理することによってプロジェクトを管理せよ。
  • プロジェクトごとにリスク調査の方法を確立して継続せよ。
  • 最終的な望まざる結果だけでなく、日常のリスクに注意せよ。
  • それぞれのリスクの実現する確率と予想コストを評価せよ。
  • リスクが現実になる前の初期の兆候を予測せよ。
  • 悪い話が上層部に伝わりやすい経路(匿名性など)を作っておくこと。
むだを減らす
  • 成功を最大化するより、失敗を抑えることによって、全体的な成績を高めることができる。
  • プロジェクトの初期にむだにする一日も、末期にむだにする一日も等しく打撃になる。
  • 一日をむだにする方法はいくらでもある。しかし、一日を取り戻す方法は一つもない。
改善
  • 優れたプロセスと、プロセスを絶えず改良することは、立派な目標である。それらはまだ、ごく自然な目標でもある。優れた技術労働者は、指示があろうとなかろうと、それらに焦点を当てる。
  • 形式的なプロセス改良プログラムには時間と金がかかる。一つのプロセス改良プログラムのために、プロジェクトが交替することもありうる。生産性の向上が実現したとしても、そのプログラムを受け入れたプロジェクトでプロセス改良の為に費やされた時間を相殺できる可能性は低い。
  • プロセスは、注意深く選んだ一つの手順改良によって、その変更に投資した時間と金に報いるだけの利益を期待できることがある。
  • プロジェクトの期間中に二つ以上の手順改良に順応することは、現実には期待できない。複数の技能改良プログラム(たとえば、全般的なCMM等級の引き上げ)は、プログラムを実施しなかった場合に比べ、プロジェクトの完成を遅らせる可能性が非常に高い。
  • 標準的なプロセスの危険な点は、人々が賢明な省略を行う機会を失わせることである。特に、人員過剰のプロジェクトの場合、標準的なプロセスによって全員に行き渡るだけの仕事(役に立とうが立つまいが)が発生するなら、標準的なプロセスが厳密に守られてしまう。
設計とデバッグ
  • 多くの開発では、設計と称して実際にはきちんとした設計をしないで、デバッグを通して設計している。
  • 仕事のやり方を変える
    • デバッグの時間を大幅に減らさなければ、プロジェクトの成績を通常より大幅に高める方法はない
    • 優れたプロジェクトは、デバッグに費やす時間の割合がはるかに低い
    • 優れたプロジェクトは、設計に費やす時間の割合がはるかに高い
生産性を高めるための間違った取り組み
  • プレッシャーをかけても思考は速くならない。
  • 残業時間を増やすのは、生産性を落とす方法である。
  • 一時的なプレッシャーや残業は、人々の焦点を定め、その仕事が重要であるという認識を高めるには有効な方法かもしれないが、プレッシャーをかけすぎると、必ず失敗する。
  • 管理者がプレッシャーを使うことが多いのは、他に何をすればいいのかわからないから、または、他の方法の難しさにひるんでいるからである。
対立に対する建設的な考え方
  • 開発に複数の当事者が関わっている限り、利害の対立は避けられない。
  • システムの構築と導入の事業には、特に対立が多い。
  • 対立は尊重すべきである。対立はプロらしくない行動のしるしではない。
  • 全員の勝利条件を尊重することをあらかじめ宣言しておく。あらゆるレベルで勝利条件を引き出すようにする。
  • 交渉は難しい。仲裁は簡単だ。
  • 勝利条件が相容れないか、または部分的に相容れない場合でも、関係者が対立解決の為に仲裁に移行するように、あらかじめ準備しておく。
  • われわれは味方同士である。敵は問題そのものだ。
対立をうまく解決する人
  • 触媒のような人格というものがある。そのような人は、チームがまとまって結束し、なおかつ健全性と生産性を維持できるようにすることでプロジェクトに貢献する。触媒が他に何もしなかったとしても(通常はほかにもいろんなことをするが)、触媒の役割は重要で貴重である。
  • 仲裁は、触媒の役割の特殊なケースである。仲裁はわずかな投資で学習できる。
  • 「あなたたちの仲裁をさせてもらえますか」というささやかな儀式の開始が、対立解決の本質的な第一歩になることがある。
プロジェクトの要員配置
  • 初期に人数が多すぎると、プロジェクトは重要な設計作業を省略せざるを得ない(全員に仕事を与えるため)。設計が完成する前に大勢に仕事を割り当てると、人や作業グループの間のインタフェースを最小化できない。
  • ソフトウェアの設計を担当するアーキテクトと呼ばれる職種がある。アーキテクトのグループが、システム全体の設計を行い、実装者のグループがそのシステムを実装する。
  • プロジェクト発足当初からアーキテクトグループと実装者グループの両方がいるプロジェクトでは、実装に着手できるレベルの詳細な設計が終わっていない段階で、アーキテクトのグループが詳細な設計の提示時期のスケジュールを調整しようとすると、「詳細な設計が出来上がるまで実装者のグループは何をしていればよいのか?」という疑問が必ずあがる。
  • 理想の人数配分は、プロジェクト器官の大部分を少人数のコア・チームで行い、プロジェクトの終盤(プロジェクト器官の最後の6分の1ぐらい)に人数を大幅に増やすというものである。
  • 無茶なスケジュールを達成するように決められたプロジェクトは、妥当なスケジュールで開始されたプロジェクトに比べ、完成までに時間がかかると思われる。

感想

ストーリー形式なので読みやすく、実際の開発であるなぁということが多く含まれているので、色々と考えながら読むことができた。
プレッシャーのところに関しては、クリエイティブな仕事だと効果が薄く、事務的作業であれば効果が高いのかなと思った。モチベーション3.0で似たようなことを言っていたのを思い出した。クリエイティブな仕事にはアメとムチは向かない。必要なのは、内的動機。それには、自律性と自由と熟達(何か価値あることにおいて上達したいという欲求)が必要。これらを得るための方法で、Googleの20%ルールが紹介されていた。(責任を伴う「自由時間」が自律と創造をうながす:日経ビジネスオンライン参照)。
今回まとめたことを意識して、定期的に読みなおして、具体的に実践したことはデータとして蓄積して、ノウハウを確立し、開発効率を高めていこうと思う。



お読み頂きありがとうございます。
少しでもお役に立てたらクリックお願いします↓。
にほんブログ村 IT技術ブログ プログラム・プログラマへ人気ブログランキングへ Subscribe with livedoor Reader 


◆◆このブログのサイトマップへ◆◆