SI
ここ数日間の状況 3
風邪で咳が止まらない
寒くなり、周りにも風邪をひいている人が増え、私も風邪を引いてしまいました。ここ数日間は、咳が出だすと止まらず、マスクの意味が無いくらいの咳き込みようで、
客先での打ち合わせ、通勤電車の中、自席での作業時も、周りに迷惑をかけています。
申し訳ありません。
咳も止まりませんが、仕事も止まらず、
各々のPJで必要なタイミングで必要なアウトプットが求められるため、
先週末は休日出勤をして対応しました。
昨日までで、Ａ案件の動作検証とUATは完了してリリース待ちになり、
Ｂ案件の仕様検討レビューを間に合わせスケジュール遅延の起因にはさせず、
ただ、Ｃ案件の設計は遅延しているので早く完了させないとならなし、
D案件は顧客からの連絡待ち＆データ待ちのまま停止中、という状況ですが、
今日は風邪でお休みすることにしました。
何か特別な出来事があったか？
前回のブログから１年以上経過したので、ここ数日ではなく過去１年を振り返ると、一番大きな出来事としては、SI部に新しいメンバーが入ったということがあります。
・・・年を取ると本当に1年が早い。
- 過去の経験もあり前提となる共通認識もあるため理解が早い
- 使う用語が違わず論理的なので話が解り易い
- 自分の考えをまとめた上で質問されるので、質問の意図が解り易く回答し易い
私が悪態を吐いても流してくれる。・・・素晴らしい。新卒採用ではこうはいかない。
残念ながらSI部は新卒採用が出来るほどの余裕が無いのです。
・・・SI部の余裕ではなく私の能力の方だという事実は棚に上げておきます。
SI部の採用基準の１つで重要だと考えている点は自分よりも優れていることですが、
これは相対的な物差しであり、評価者の能力が低ければ相当数の応募者が基準値をクリアします。
だから大丈夫。来年にもう１人採用したいと考えています。
人月の神話
さて、ソフトウェア開発者の方には馴染みがあるでしょうが、ソフトウェア開発業界の定番書『人月の神話』について、私も有名な一説は知っていますが、
通読した経験はありませんので、自戒の念を込めて、少し紹介しておきたいと思います。
私が持っている20周年記念版より
- 人月の神話・・・コスト計算をもとにして組み立てられた見積技術は、労力と進捗とを混同している。人月は、間違った危険な神話である。というのも、人月とは、「人」と「月」が相互に交換可能だということを意味しているからだ。
- ブルックスの法則・・・遅れているソフトウェアプロジェクトに要員を追加することは、以下の三点において、必要となる全体の労力を増大させる。すなわち、再配分作業とそのための中断、新しい要員の訓練、それから新たに必要となる相互コミュニケーションである。
- 非常に優秀なプロのプログラマは、同じトレーニングを受け経験二年というレベルでの比較では、出来の良くないプログラマの十倍も生産性が高い。
- 少数精鋭チームが最高である－－－人数は出来るだけ少ない方が良い。
- 少数精鋭チームで非常に大きなシステムに取り組むと、開発が遅れすぎる。
- コンセプトの完全性こそ、システムデザインにおいてもっとも重要な考慮点である。
- コンセプトが統合されているシステムは、より早く開発されテストができる。
- インプリメンテーション期間中、システムアーキテクトは継続したシステムの完全性を確保するために、不断の警戒を維持しなければならない。
- 重要な文書それぞれを維持管理することで、状況の監視ができるようになり、万一の場合の警告メカニズムも得られる。
- 各文書は、それ自体チェックリスト兼データベースである。
- マイルストーンは具体的かつ明確で測定可能なイベントとして、ナイフの刃のような鋭さをもって定義されなければならない。
- マイルストーンが自分も欺けないくらい鋭利だと思えば、マイルストーンの進捗をごまかそうとするプログラマはめったにいなくなるだろう。
- どの遅延がどのくらい問題なのかを理解する手段として、クリティカルパススケジューリングに代わるものはない。
- ほとんどの文書は概要の説明が十分でない点で落第だ。遠くに立って見てからゆっくり近づくことだ。
- 狼人間を撃つ銀の弾はない。（ソフトウェア生産性という怪物をやっつける特効薬はない。）
- ウォーターフォールモデルは間違いだ。漸増的構築モデルの方が勝っている。
これらを実感している人や理解出来る人と一緒に仕事がしたいなぁと思います。
ソフトウェア開発に限らずWebサイト構築においても多くの点で共通点がありますので、
社内の他の部のメンバーでも、仮に知らない人が居れば、是非、概要だけでも。。。
誤訳
私の業務に近い言葉で書いたり、直接は関係ない最近思った内容を少し補足すると以下になります。
- 1人で3ヵ月（12週間）の開発作業が4人なら3週間で終わるということはない。
- スケジュール遅延を要員追加で補えるというのは幻想であり、さらに遅延する。
- 全体像が見えない6人編成チームよりも、
全体像が見える1人＋他2人の編成チームの方が成功する。 - 機能の豊富さに惑わされる愚かさは、正確さ、速さ、整合性、を損なう。
（何でも出来るは、何も正しく出来ない、と同じである。） - 実現内容は未定にも関わらず、コストとスケジュールが約束出来ることはない。
- コストとスケジュールの前提条件が無い提案などしてはいけない。
狼少年と呼ばれることになり、周りの全てを不幸にする。 - プロジェクト管理とは顧客も含めた各々の担当者の作業を止めないようにすることである。
- マイルストーンは重要だ。期限のない作業など仕事とは呼ばない。
- スケジュール管理や変更管理が正確にされないプロジェクトはデスマーチへと続く。
- 文書として残されなければ、その内容は早々に忘れ去られる。
口頭で伝えるだけなど業務上あり得ない。 - 概要説明や俯瞰して眺めた図を描けなければ、他人に内容が伝わるはずが無い。
- 言語、ツール、ライブラリ、IDE、フレームワーク、方法論、
などで諸問題が一気に解決することはない。
しかし、部分的にでも生産性が向上するならば、取り入れない理由にはならない。 - 問題の本質は、何が問題であるか自体を認識していないことである。
