レコード数６億件（RDBMS）

とあるシステムの設計をしていて、毎日30万件以上、月1000万件、年間１億２千万件、と試算した。少なくは無いがものすごく多いとも思わない。
５年分くらいはデータを保持したいので、６億件１テーブルに保持したいといったら、基盤チームからやめてくれと懇願されました。1レコードはそんなに大きくはないので1kバイトないくらい。仮に1kバイトとして、5年で大体600Gくらいかな。別にかまわないと思うのだけど。
6億件全体をこねこねすることもないのでパフォーマンスも問題ない。Insertもパーティショニングをつかえば問題ないと思います。
世の中的には、どうなんでしょうか？

AIの活用が今後増えていくと思いますが、そういった素データの保持が重要な気がします。今回のケースは本当に保持が必要か再検討しますが、600Gぐらいでうろたえるなと思いました。

ExcelのCSVの取り扱いについて（苦労した）

テストデータを作っていて、苦労したので記録しておく。

バージョンはExcel2010だった。
データはCSVで数行のデータをコピペして、ところどころ値を変えて１万行くらいに増殖させようとしていた。CSVなので下記のような形。
（CSVにもいろいろ方言はあるが）

”ABC","¥123,456","XYZ"

みたいな形。

このCSVをExcelで編集して「CSV」形式で保存しても勝手に下記のような形式に変換される。

ABC,"¥123,456",XYZ

つまり

1. 勝手にダブルクォートを削除する。
2. 全部削除ならまだ統一感があるが、データ内にカンマ「,」が含まれているとその列のダブルクォートは残す。

テストデータとしては、全部ダブルクォートで囲みたいので、sedで編集した。

小さな親切、大きなお世話だ。

IT開発におけるパフォーマンス問題について

最近また業務システムの設計をするようになった。
その時に、それまでの旧システムを維持・管理している方から言われてハッとしたことがある。古いシステムはいわゆるオフコンで、夜間にバッチ処理で150万件のレコードを処理して、1000万件のレコードを更新しにいっていると聞いた。
一方自分は、新しいシステムで旧システムで同じ時間で15万件を処理するためには、どうしたら良いかと悩んでいる。
旧システムよりは、ハードの性能は格段に上がっているはずで、新技術もいろいろあるはずなのに、なぜパフォーマンス問題に悩まなければならないのだろうかと思った。
技術チームにアドバイスを求めると、「RDBMS内でできることは、RDBMSにできるだけやらせてプログラム内で多段ループを組んでその中でSQLを投げることはやめなさい」と言われた。言われていることはわかるし、そうするつもりもなかったけれど、それでも15万件を処理するのに不安が残るねという話になった。
処理自体はいたってシンプルで、処理対象のレコードをいろいろな条件でとってきて、項目をいろいろ編集して別のテーブルに書く。コンピューターの一番得意な処理のはずなのになんで時間がかかってしまうのだろう。
もしかして一括大量処理には、いまだにCOBOLで汎用機やオフコンの方が向いているのだろうか？それとも自分の考え方が間違っているのだろうか？確かにCSVファイルを一括で処理したりするだけならばAWKの方が早かったりするのだけれでも。なんでもJavaというのが間違っているのだろうか？

IT開発プロジェクにおける計画外のタスクについて

また、みずほ銀行の基幹システム開発が話題になっている。本当か嘘かわからないが、工数の９割が進捗会議についやされているという噂を見た。また進捗会議にむけての会議もあるらしい。
通常計画フェーズにおいて、スケジュールを引く、ウォーターフォールだろうがアジャイルだろうが引くはずだ。形式は、ガントチャートかもしれないし、チケット形式かもしれない。とにかくやるべきことを明確にしようとするはずだ。
しかしながら、いざ計画から設計〜開発、テストとフェーズが進むと計画外のタスクが増えてくる。
内容は、問題解決のための活動が多いが、それ以外の活動もある。冒頭に述べた会議のための活動もその一つだ。またメンバー内での意識合わせもある。予期していなかった他チームからの依頼も非常におおい。資料をExcelで作成（Excelのほうが作るのに便利だと思ったから）していたら、別の人に見せるためにPowerPointに作り直してくれと言われることもある。なので似たような資料が増殖していくことが多い。どれが本物かわからない。その確認のためにまた作業が発生する。
そのように計画外タスクが増え続ける状況にもかかわらず、計画したタスクの期限は守れという。仕事量の総量は増え続けているのに期限を守れるはずもない。みずほ銀行の内部は、こういった状況になっているのではないかと想像する。
予算（人かける期間）は最初に決まってしまっているので、増えてしまった作業を計画に組み込むことができない。どうしようもないほど計画したタスクが遅れてしまった時には、「当初計画した」タスクは見直すが、よほど大きくかつ皆が必要だと認める作業は追加されない。資料の再生産や、会議のための会議は結構な作業量になるが、これをタスクと認めてくれるリーダーは少ない。これら作業量が臨界点を超えるとプロジェクトは失敗する。

ITプロジェクトで失敗した時

当たり前のことだけれども人間だれしも失敗をする。その時どのような心持ちでいれば良かったかを書いてみたいと思う。なぜこのとこを書こうかと思ったかと言えば、最近自分はプロジェクトで小さな失敗をした。（正確に言うと失敗をしたかも知れないと思い込んでビクビクしていた）その時に冷静に考えて、なんで自分はこんなにビクビクするんだろうと振り返ってみた。
過去自分はプロジェクトの激務で体調を崩し、長期にわたって休んでしまったことがある。それは失敗をリカバリーしようとして激務に激務を重ねて結果的に体調を崩してしまった。
（もとからそのプロジェクトは失敗していたが、リカバリーせよとの指示を受けてプロジェクトに入った）
その時のトラウマがあるのだろうと思う。その時の自分は委任契約で大手ITベンダーに雇われていた。それなりに高給の契約ではあったが、契約上はプロジェクトの成否に一切責任のない立場のはずであった。
しかし実態はユーザーさんから毎日毎日「どうなっているんだ！怒」と責められ、どなられる毎日であった。しまいには「お前のせいでこれこれの金額分の損失を被った。どう賠償してくれるんだ！」と言われた。ベンダーのPMに相談したがなにもしてくれなかった。
また同じ立場であるはずの協力会社の人も責めてしまった。「なんでできないんだ！」とか「どうしてこうなった」と言ってしまった。
結局のところ「火中の栗を拾う」とは聞こえが良いが、「本当」の責任者は責任をとらず、委任契約である自分に便宜上責任を押し付けたのだった。
その時の自分は「プロジェクトを救う！」といった今考えると意味の無い義侠心にかられて、仲間を責め、自分を責め、プライベートもすてて頑張ったが、個人の力では限界もあり潰れてしまった。
委任契約で個人が受けるペナルティーは、契約を打ち切られる以外にはなく、責められるいわれもないはずである。
通常は契約の継続は生活の安定とリンクしているので、ついつい無理をしてしまいがちになる。とことん追い詰められると最後は「死」を意識してしまうまでになるが、サラリーマンと違って労災は降りない。残業代も契約上明記がなければ請求権はない。
なので心の安定を図る為、いつでも契約を打ち切られる（こちらから打ち切る）ことを念頭において仕事をしている。「信頼している」と言われてもその人は99%生涯の面倒は見てくれない。どころか半年先の約束でさえ平気で破る。なので戦国時代の武将では無いが、常に死地にあることを意識していれば、おのずと飄々と「責任逃れ」ができる。責任はないので責任逃れという言葉はおかしいが。
冒頭に書いたビクビクしてしまった理由は、昔の記憶が少し残っていたからだろうと思う。なので、何かあったらこのブログを見直して、これからも飄々とプロジェクトに関わることができればと思う。
委任契約の関係は、切るか切られるかしかないのだから。

システム要件の暗黙知化について（あるいは無知）

要件定義のポイントは、だれにでもその要件がわかるようにすることが必要と思う。文章でもいいし図表でもいいし確かにああそうだねと理解できることが必要。業務の流れ、データの流れ、インプットとアウトプットを明確に知りたいと思う。
しかし要件定義において良くあるのは、「現行通りにつくってください」ということがよくある。そのパターンが一番困る。現行を知るためには、無限のインプットのパターンとそのアウトプットを確認するか、何万行〜何百万行のソースコードをよむしかない。ソースコードの中にもマジックリテラルが仕込まれていて意味不明なことは普通にあり得る。

ではお客様はどのようにシステムを使って仕事をしているのだろうか？仕事のひとつひとつの意味を理解している人は少ないのかもしれない。企業は、一人一人の仕事の総体でお金を稼いでいるはずなのだけれでも、自分の担務の意味（特にシステムを使う意味）を理解している人は少ないのかもしれない。画面の文字の位置、帳票の文字の大きさには異常にこだわるのに、なぜその位置に文字がないと困るのか答えられる人はいない。

当初この文章を書き始めたのは、要件が属人化していてプロジェクト全体に共有化されにくいということを書こうと思った。その仕事のある領域では達人みたいなひとがいて、またそれを聞き取ったエンジニアも共有できる形に要件をまとめきれず、結果的に設計をするにあたって「聞き直す」しかない。「なんでそんなこともわからないのか？」「まえに話したはずなんだけれども」と怪訝な顔をされる場面が過去によくあったからだ。

しかし、よくよく考えてみると上段で書いたように実は「本当に要件を知っている」人はいないのかもしれない。細部にわたってこだわりがあり、何かを知っているように見えて、なぜそのような仕事の仕方なのかを理解している人はいない気がする。
したがって要件が不明なプロジェクトは失敗する。

※最後に「プロジェクトは失敗する」でしめるのが多くなってきた気がする。失敗シリーズとでも名付けようかな。

ITプロジェクトのプロセス改善と標準化

ITプロジェクトをやっていると、よくお客様に対して「新規システムを導入するだけではダメで、プロセス改善も同時に行ってください！そうでないと効果がないです！！」と言う場面がある。
それは実際真実なのだが、振り返ってみるとプロジェクト内部でも色々とプロセスを改善したいことが良くある。ツールを導入して効率化してと言う場合もあれば、プロセスそのものを変更したらもっと効率的にプロジェクトを運用できるのにということもあった。

しかしお客様に向かっては厳しくいうくせに自身のプロジェクト運営は全然ダメだった。
一つは、プロジェクトの標準ツールが決まっていて、それ以外は導入してならぬとか。それは大体ExcelかPowerPointかWordか、一般的な企業なら大体あるはずのツールをしか使わせてもらえない。ガントチャートを引くのにMS Projectを使いたいと言ったら「高いからダメだ」とか。IT企業のくせに情報化投資を全然しない。Excel大活躍である。もっともお金がかかるのは人件費なのに、ツールにお金をかけることには極めて消極的だった。
もう一つはプロセスを変えたいとプロジェクト内部で提案した時に、決まり文句で「決まったことだから」「他のチームもプロセスを変えなければならないので無理」とか。

そんなIT企業が真にお客様のための業務効率化に寄与できるとは思わない。「つくることだけ」が目的になっているプロジェクトが多いのではないかと思う。
ちなみにMS Projectは最近しらべたらブラウザベースの簡易版で月に700円程度。実績入力と閲覧だけならこれで十分と思う。アプリをインストールするタイプでも月3600円ぐらい。計画立案をしたりカスタムレポートを使ったりするならば、こちらの方がいいと思うが、それでも3600円だ。
あとプロセスに関しては、お客様側のキーマンに直訴して俺様プロセスを作ったりしていた。本当は良くないのだが、非効率ゆえに仕事量に圧殺されて本当にやるべきことができなくなってしまうからだ。（レポートの為にコピペを繰り返すのに時間を割くのはもったいない）
よってそんな非効率プロジェクトは大体うまくはいかない。

IT開発プロジェクトにおける要件（または要求）定義と以降の局面の期間割合について

大体のベンダーさんにおいては、ウォーターフォールアプローチを取ることが多いのだけれども、すごく大雑把に言って各局面の期間割合は、
要件定義：1
基本設計：2
詳細設計・開発・単体テスト：3
結合テスト：2
総合テスト：2

ぐらいでは無いかと思う。

いつも思うのだが、テスト局面を手厚くして、要件定義及び基本設計にそれほど時間をかけていないのはどうかと思う。実際問題、要件は決め切れないことが多いし、細かい要件について引き出そうとするときりがなくなるというのはわかる気がする。
しかし、それにしても要件定義時の資料の陳腐化が激しくて、以降の局面でその資料が使い物にならないことが多すぎる。また忙しくて要件定義時の資料を直そうということ起こらない。
結果的に要件定義っぽい活動を延々と続けていることになる。テスト局面に入っても。テスト局面が比較的長くとってあるのは、要件が未決定のまま開発に突入してしまうことが多すぎて、経験則からテスト局面を長くとってしまうのではと考える。

ならばいっそ要件定義の局面をできるだけ長くとってはどうかと思う。自分の経験上はできる限り長く要件定義（あるいは要求、システム構想）の期間をとってじっくりユーザーさんと「やりたいこと」を煮詰めてから開発に突入した方が良い結果が生まれる気がする。開発することが明確であるならば期間は短くてもかなりのスピード感をもって開発を進めることができるはず（そうそう特殊なロジックを必要とするアプリケーションはない）

後続局面での手戻りほどオーバーヘッドが大きいのは周知の事実である。なので、できる限り不明なことは、事前に潰しておきたいというのが自分の方針になっている。

工数的にみても、最初プロジェクトの立ち上がりは、数人で始まり、だんだん人数が増えて、最盛期に数十人〜数百人に達するということが多いと思う。
数人で受け取った要件を数十人に展開するのはかなり難しいと思うし、数人では気づきが少ないことも多いと思う。

よって要件定義早期に多くの人間を投入し、それなりの期間を取ることができれば、品質も良く、開発・テスト期間も圧縮できると考える。

IT開発プロジェクトの個人個人の生産性について（過労死事件に寄せて）

電通で入社１年目の方が自死された事件について、労災認定されたことが話題になっている。その方のTwitterの投稿を見るとそれは凄まじく言い尽くせない悲しみを感じた。
また以前ワタミで自死された新入社員の過労死認定の訴訟を行った遺族の方が、和解金を使って「ブラック企業」との訴訟費用を援助する基金を設立されたとのニュースもみた。

自分自身を振り返ると、かつては自死された方ほどではないが、徹夜も辞さないとの姿勢で働いていたことがある（30代前半ぐらいまでだが）。また周囲に対してもそのような姿勢が望ましいとの考えを持っていたことがある。
結論から言うとそれは誤っていた。
自死された方との違いは、「頑張っている自分」に酔っていたのと、なんだかんだ（仮眠とか、ちょっとしたサボりで）休んでいたからだと思う。

毎日16時間からそれ以上働いていたが、客観的に見ると本当に生産的なことができたのは8時間以内で、もっというと最高の集中力を発揮できたのは5、6時間だったと思う。
残りの時間は、何かを待っていたり、無駄な会議（ほんとうなら自分は必要のない会議）に参加したり、実質的には何もしていなかったように思う。PCの画面をぼーっと眺めているだけの時間もあったように思う。無理に長時間何かをしようとしても思考力が低下しているので、ミスも多くなりミスをカバーするためにさらに時間を要するという悪循環に陥った。

ITの（あるいは日本の）世界では、何も生み出さなくても頑張っている姿勢を示すことが大事という風潮があるように思う。本来合理的な活動であるはずの会社（あるいはプロジェクト）において非合理的、非科学的な行動規範を求められるのは馬鹿げている。
（長時間労働を強要し、ましてや残業時間のごまかしなどが行なわれている。ブラック企業とか聞こえよくいうが、違法行為である）

なので30代後半からはなるべく長時間労働をしないようにしていたが、それでも周辺からのプレッシャーと自分への過信と（信頼されていることに対しての）自己満足で長時間労働してしまったことがある。結果的には体調を崩してしまった。崩した結果、プロジェクトを休んだりしてしまった。休みを含めた平均労働時間は、8時間を確実に切っている。ならば最初から長時間労働しないほうがよかったのではないかと思う。休めば急に人がいなくなるので、代わりの人を探したり、代替要員の新たな学習コストもバカにならない。
※補足すると思い返すと「信頼」とは聞こえが良いが、実際には「お前が働かないと俺が困る」という利己主義に基づくもの。

無能な管理職で「プレッシャーをあたえると生産性があがる」という奇妙な考えを持つ人がいる。そんなデータはどこにもない。
おそらく「火事場の馬鹿力」のような考えなのだとは思うが、ITプロジェクトは、日々続く普通の経済活動であり、「極限状況において、人間がごく稀に発揮する力」を期待するのは無能の極みである。※火事場の馬鹿力も客観的なデータがあるのかわからない。都市伝説ではないかと思う。自分自身は、高いプレッシャーの環境下でいつもより良いパフォーマンスを示せたことは無い。（低下するほうが多かったように思う）
オリンピックのトップアスリートは、いかにリラックスするかを常に考えている。

プロジェクトで生産性を向上させるには、いかにコミュケーションをとっていくかの創意工夫が必要と考える。いわゆるアジャイル方法論が注目されるのもコミュニケーションを重視する方法論であるからだと思う。

ITに関わる方で（それ以外の業種の方でも）、ぜひ読んでおいて欲しいのが、

人月の神話（フレデリック・ブルックス）
ピープルウェア（トム・デマルコ）
アジャイルソフトウェア開発宣言※最後の2行をちゃんと頭の隅に置いておくこと

である。いかに長時間労働が、クオリティを低下させるかが見えてくると思う。自分はこれらを勉強することによって間違った考えを修正することができたように思う。特にトム・デマルコは自分にとっての神様みたいな存在（会ったこと無いけど著作を通じて）。

最後にトム・デマルコの著作　デッドライン（これも名著）から引用しておく、
”プレッシャーをかけても思考は速くならない”

至言であると思う。

ITシステム開発のミニマリズムとリリース（過去のプロジェクト振り返りその12）

今回は、ITシステム開発におけるミニマリズムについて書く。

ソフトウェアプロジェクトサバイバルガイドによると
"ソフトウェアプロジェクトで開発に成功するためには、ソフトゥアコンポーネントとその機能の複雑さという点について、要求定義時からリリースまで「単純なほど良い」という方針が必要である。"
とある。

自分は、古い業務システムをリプレースするプロジェクトが多かったが、古いシステムとなると過去のいろいろな経緯（機能追加の蓄積等）によって、どうしても置き換える新しいシステムは複雑になりがちである。その場合、自分はシステムの断捨離を推奨する。過去に組み込まれた多くの追加機能のほとんどは、ちょっと便利な機能であり、システムの根幹を左右するほどの機能はほとんどない。
いまだ人間は非常に優秀なシステムの一部であり、追加機能に100人月かけるならば、2人の人間の手作業でしのげないかどうかを検討するべきであると考える。

ただプロジェクトを実際にやっていると、そうは言ってもということがよくある。しかし最終的にリリースするソフトウエアが複雑であっても。最初のフェーズは単純に作り、その後、機能追加していくフォーズを設ければ良いと思う。つまり最終的なリリースとコア機能の構築フェーズ、追加機能の構築フェーズを切り離し、何段階にも分けて開発・テストを繰り返せば良い。

特にウォーターフォール開発では最初に（しかも短い期間で）、すべての機能要件の詳細をつまびらかにしなければ、次のフェーズに移れないという考えがあるが、そんなことは人間には無理である。

1. コア機能の要件と理解
2. コア機能の開発・テスト
3. コア機能を踏まえた上での追加機能の要件の検討
4. 追加機能の開発・テスト
5. 繰り返し
6. リリースタイミングは、ユーザーが追加機能の充足度から判断して決めれば良い。
• 永遠に開発し続ける可能性もあるが、どこかで割り切ってリリースするはず。

おお！アジャイルっぽいとも思ったが、ちょっと違う気もする。アジャイルは早期リリースを重視するんじゃないんだっけ？？

ITプロジェクトを設計する

プロジェクトを設計するというと、少し変な感じがするがこの概念は勝手に自分が考えた。勝手にプロジェクト設計と名をつける。あるいはプロジェクトのためのプロジェクト(PfP:Project for Project)と名付ける。※商標登録しておこうかな。主に発注者側である企業さんに対してであるが、RFP(Request For Proposal)のさらに一段手前において

• 何をプロジェクトの目的とするか
• その手段として何を用いるか（ITなのか業務改善なのか、あるいはその両方なのか）
• どうやって目的の達成具合を測定するか
• おおよその規模感（1億円なら投資できるが、10億円は無理とか）

等々を明確化し、組み立てていく、要求をできるだけ定義していくのがこのフェーズの目的である。当然決まっていないこともあると思うが、それは「決まっていない」と明確化していく。（それによって提案も変わってくるから）成果物はプロジェクト計画書（設計書）となる。プロジェクト計画書の目次は、

1. プロジェクト目的
2. 対象業務・システム
1. 対象業務・システム概要
2. 主要課題
3. 手段
1. ITによる目的達成部分と達成手段の概要
2. 業務改革による目的達成部分と達成手段の概要
4. 効果
1. 効果概要
2. 効果の測定方法
5. 意思決定者（組織）
6. 実行組織
7. 関連組織
8. 要員規模
1. 実行組織の要員規模
2. 関連組織の要員規模
3. 外部調達する要員規模
9. プロジェクト終了に向けたスケジュール概要
1. 内的主要マイルストーン（※プロジェクト自体のマイルストーン）
2. 外的主要マイルストーン（※プロジェクト外で発生するマイルストーン、例えば法改正等）
10. プロジェクト課題
1. 主要課題
2. 課題責任者
3. 課題対策
11. プロジェクトリスク
1. 主要リスク
2. リスク責任者
3. リスク対策

ぐらいかなと思います。重要なのは、この計画書に意思決定者、実行組織、関連組織が内容に同意し、ハンコを押すこと。（血判状的な）※未決事項があるならそれはそれで良い。未決であることが明確であることに意義がある。

これぐらいをまず検討していると、プロジェクトの成功確率がぐっと高くなるのではと考える。

IT開発プロジェクトと軍隊（戦争）について

前にITプロジェクトと建築土木について書いたので。今回は、ITプロジェクトと軍隊（戦争）の類似について考えてみる。
似ていると思うところ。

1. 戦略と戦術がある。
1. 戦略目標は超重要。戦術レベルでいくら勝利しても。戦略的には敗北はする。
2. 大部隊を動かす。
1. 戦争にも大小あるが、総力戦になると数百万の人が動く。
2. ITプロジェクトは最大規模でも数万だと思うが、十分大人数。
3. プロジェクトのあるいは戦闘の初期段階では、情報が足らない。
1. ITプロジェクトの場合は、要求、要件が不明確。できないことも不明確。
2. 戦闘の場合は、敵の全容が不明確。現代戦ではあまりないのかもしれないが、味方の別部隊の動きも不明確（フォークランド紛争の戦記を読んで思いました。またしばしば味方への誤爆もあるから現代においても完全には相互連携は実現されていないのだと思う。）

戦略目標が重要というのは、これまでにも書いてきたので省略する。

戦術というのは、ITプロジェクトにおける各種方法論だと考える。戦略が破綻していれば、戦術（方法論）がいかに優れていても敗北する。

大部隊を動かすというのは、ITプロジェクトも軍隊も同じだが、（かってな思いだが）各々の兵隊が任務を達成して、それが全体の目的の達成につながるというのは軍隊の方が優れているのではないかと思う。ITプロジェクトにおいては、数千の人間がいても、そのうち何割かは何もしていないか、あるいは無駄なことをしているのを見てきた。

軍隊においてはそれはないと信じたい。なぜなら、少なくとも何かしていないと「死ぬ」から。（想像だが）軍隊においては個々の行動規範が明確化、マニュアル化されており、それに従った訓練がなされているから。千変万化する戦場において、（できるだけ）的確な行動を個人がするためには、それがマニュアル化と訓練が必要だと思う。

※なんとなく行動する軍隊とか想像できない。

ITプロジェクトでは、そのマニュアル化と訓練ができていないと思う。

各々の役割に対する行動規範が不明確で、また日々の訓練も出来ていない。大した研修もなしにOJTと称して最前線に投入されるのは、よくあることと思う。プログラミング研修などは、兵隊がライフルの撃ち方を教わるレベルであって体系立てた訓練とは言えないと思う。

ただし、ITプロジェクトは日々立ち上がるのに対して、戦争はそう滅多に起こらない。なので訓練の余裕がないのかもしれない。

また情報の不明確さに対しては、軍隊は情報をを重視する（どこに敵がいるかがわからないとお話にならない）ため、あらゆる手段を講じて情報を得ようとする。現代戦においては、「情報戦が勝敗を決める」とまで言われているようである。

ITプロジェクトにおいては、その情報を得て分析する努力が足りていないように思える。「見える化」が声高に言われて久しいが、見えた後の分析と行動ができていないように思う。事前に見えるようにもしない。（プロジェクト企画は常にバラ色の未来で、問題やリスクがあることを明記してあるのを見たことがない）

戦争においては、できるだけ本格的な戦闘の前に情報を得ようと、偵察を重視する。ITプロジェクトにおいても本格的なプロジェクト開始の前に「偵察」行動が必要なのではないか？それは、プロトタイピングかもしれないし、要求の分析、RFPをちゃんと書くことかもしれない。プロジェクト企画の段階で、「偵察」のプロが偵察行動を行うだけで、戦争に負ける＝プロジェクトが失敗することを防げるように考える。

IT開発プロジェクトの見積

今回は、見積について少し書いてみたいと思う。
プロジェクトの初期段階での見積もりの不確実性と、サイクリックな再見積もり（アジャイル系アプローチ等）の提案についてはいろいろな人が別に述べていると思うので割愛する。

プロジェクトの初期段階での見積もりの不確実性については、いくつかの要素があるのではと考えたので整理したい。なぜプロジェクトの初期段階で見積もりが不正確なのか？
もちろん前提として、プロジェクトの戦略目標は定まっているものとする。（定まっていないなら必ずプロジェクトは崩壊する）
※このへんのところは名著　失敗の本質―日本軍の組織論的研究
中公文庫
ISBN-10: 4122018331
を読んでほしい。

見積もりの不確実性の根本は、「決まっていないこと、わからないこと」の多さにあると思う。よってサイクリックな再見積もりによって不確実性をだんだんと減らしていく。

しかし最初の段階でも「決まっていること、わかること」は当然ある。そして「決まっていること、わかること」は、「決まっていないこと、わからないこと」より相対的に多いと考える。
８：２の法則から考えると８割ぐらいの要求は決まっていて、またプロジェクトコストに対する８：２の法則から考えると８割の決まっていることは、最終コストの２割で実現できるのでは？と考える。

じゃあ残りの２割の要求は？と考えるとそれは、レアケースに対する要求ではないか？

とするとプロジェクトの初期段階ではその決まっていることに焦点をあて見積もると、精度の高い見積もりが得られるのでは？と考える。そして初期段階で決まっていることことが、そのプロジェクトのコア機能であり、その時点で「決まっていなこと、わからないこと」は捨て置いて、計画してプロジェクトをスタートさせれば良いのでは？残りのレアな機能については、コア機能の完成後、おっつけ組み込むアプローチがあるのではないか？

最初にこれがアジャイル的進め方かなあと思ったが、ちょっと違うかもしれない。もう少し深堀して考える必要があると思う。

※「決まっていること、わかっていること」の数だけでいうと、８割よりずっと少ないかもしれない。無意識のうちにビジネスに対する重要性を掛け算しているのかな？書き直すのが面倒なので補足しておく。

IT開発プロジェクトと建築土木

もうIT関連の仕事に携わって２０年ぐらいになるが、関係したプロジェクトは成功も失敗もある。自分自身がPMとして失敗してしまったプロジェクトもあるし、さまざまな担当して担当タスクを失敗してしまったこともあるし、自分は失敗しなかったがプロジェクトとしては、失敗だったこともある。

ちなみに自分の中では、当初のシステムの目標に対し、期間、予算、機能（品質）が+30%の幅の中に収まることと考えている。（甘い見方かもしれないが）

ITプロジェクトを推進するにあたって、例えば「ビルを立てる」といった建築土木のプロジェクトの進め方との関連を意識したりしてきた。

ITプロジェクトと建築土木の考え方の間には類似点があると考えていた。

1. ものすごくざっくりというと作業工程が計画〜設計〜実装（建築土木ではなんと表現するのだろう）と工程の進み方が似ていると考えていた。※アジャイル開発においても基本これは変わらないと考えている。進め方の粒度の違いだけ。
2. 何十〜何千という見知らぬ人間が集まって目標を完遂する。各工程でスペシャリストが集まり、ものを作り上げていく。釘を打つ人と壁紙を貼る人の間のコミュニケーションはどのようにとっていくのだろうとか。
3. 予算、工期、品質の目標がある。

建築に失敗したビルというのは聞かないが、（実はあるのか？？）、失敗したITプロジェクトはごろごろある。なぜなんだろうと考えた結果、計画局面の決定ぐあいが違うのでは？と思い至った。大きなビルならモックアップをつくって検証すると聞いたことがある。また設計図など共通認識を持つための情報ツールがもう枯れた技術となっていて実装時に迷うことがないのでは？（記法なども統一されているだろうし、A社の設計図は、全然別のB社が完全に読み取れるはず）

とするとITプロジェクトにおいても

1. 計画、設計局面において、できるだけ決定できることは細かく決定しておくこと。
2. 決定したことの共通理解を関係者がもつこと。また理解のための共通言語（設計図に相当するもの）もつこと。
3. 上記とも関係するが、共通理解のためのイメージ合わせのためプロトタイプを利用すること（モックアップに相当。プロトタイプの再利用など考えず使い捨てにしたほうが良いと思う）

実装より計画を！（アジャイル宣言に反している気がしますが。。）

に重点をおくと現状が改善されるように思った。通常のウォーターフォール開発では計画〜要件定義までに予算の２割も使えば多いほうだが、（計画には１割も使っていないのでは？）これを少なくとも３割程度までUPすると後半の手戻りも少なくより成功に近づくのではと考えた。

とあるプロジェクトのPMOの１週間

9:30−18:30が定時
そんなにも忙しくない時

月曜日
9:30−10:00　メールチェック等
10:00−11:00　バグ報告会
11:00−12:00　午後の資料準備
13:00−14:00　資料準備の続き
14:00−15:30　定例会議（変更管理等）
15:30-16:00　ちょっとした隙間
16:00−17:00　バグ確認（現場からの報告）
17:00−19:30　いろいろ資料作成
帰宅

火曜日
9:30−10:00　メールチェック等
10:00−11:00　バグ報告会
11:00−12:00　リーダーミーティング
13:00−16:00　テスト状況の報告書作成
16:00−17:00　バグ確認（現場からの報告）
17:00−19:30　いろいろ資料作成＆打ち合わせ
帰宅

水曜日
9:30−10:00　メールチェック等
10:00−11:00　バグ報告会
11:00−12:00　いろいろ資料作成＆打ち合わせ
13:00−13:30　ちょっとした隙間
13:30-15:00　テスト進捗会議
15:00−16:00　全体進捗会議
16:00−17:00　バグ確認（現場からの報告）
17:00−19:30　変更管理等の打ち合わせ
帰宅

木曜日
9:30−10:00　マネージャーブリーフィング
10:00−11:00　バグ報告会
11:00−12:00　いろいろ資料作成＆打ち合わせ
13:00−14:00　いろいろ資料作成＆打ち合わせ
14:00-15:00　テスト報告会議
15:00−16:00　いろいろ資料作成
16:00−17:00　バグ確認（現場からの報告）
17:00−19:30　いろいろ資料作成（月曜日に向けて）
帰宅


金曜日
9:30−10:00　メールチェック等
10:00−12:00　いろいろ資料作成＆打ち合わせ
13:00−14:00　いろいろ資料作成＆打ち合わせ
14:00-15:00　テスト連絡会議
15:00−16:00　いろいろ資料作成＆打ち合わせ
16:00−17:00　バグ確認（現場からの報告）
17:00−18:00　プロジェクト連絡会議
18:00−19:30　いろいろ資料作成（月曜日に向けて）
帰宅

テスト関連会議多すぎ〜　一番忙しい時はわすれました。
延々と会議と打ち合わせだったような気が。。

ITシステム開発プロセスについて（過去のプロジェクト振り返りその11）

システム開発プロセスについては様々な方法論があるが、ここでは個々の方法論については述べない。
過去のプロジェクトにおいてよく体験してしてきたことだが、開発方法論の大枠（ウォーターフォールでいくとか）は、計画段階で決めるものの、方法論を実際に実行するための細部にわたるプロセスは、必要性が見えてきたときに初めて検討され始める傾向がある。

初期段階において、開発プロセスの「実際の」運用を決めておかないと、必要性が高まってきたときに、決め始めるのではオーバーヘッドが大きいとよく感じる。

スティーブマコネルの「ソフトゥエアプロジェクトサバイバルガイド」には、計画段階でのプロセスの決定を推奨している。例としては以下のプロセスを事前に決定する必要があると述べている。

• 変更管理
• 品質保証
• 欠陥追跡
• システム統合（システム間インターフェースの考え方）
• ソースコードのバージョン管理
• スケジュール（見積含め）

例えば、変更管理を例にとると「変更を誰がどのように評価し、受け入れるのか」が実際に変更が大量に積みあがるまで管理プロセスが決定していないことがよくあった。

またスケジュールに関しても、当初のスケジュール（ドンブリ勘定でとりあえず置いてみたもの）が、やはりうまくいかないので３ヶ月から２週間ごとに再見積もりとスケジュールの引き直しを求められたことが、よくあった。

ちなみに当初スケジュールを自分で見積もらせてもらったことは、ほとんどない。どこかの誰かが適当に引いたものの順守を求められるという理不尽なことがよくある。

プロセスの実際の運用が遅れれば遅れるほど、プロセス運用の試行錯誤（突貫工事で作らなければならなくなるため）と本来の作業が重なり合い非効率な、場合によっては本来の作業を阻害するような事態が引き起こされる。

あるプロジェクトで「チームメンバーがプロジェクトを達成不可能と信じていること」を深堀ってみる

とあるプロジェクトでチームのメンバーは、口々にプロジェクトを達成不可能といっていた。その理由大きくいうと以下の３つに集約されるのではないかと思う。

1. 仕事量がものすごく多い。やってもやっても終わらない。
2. 優秀な人とそうでない人の差が大きくフォローしきれない。
3. プロジェクトとして現場レベルで決めたことを実際に現業をやっている部門に持っていくと簡単にひっくり返される。

1.について。自分のチームは要件定義を行うチームであった。要件としてはパワーポイント１ページに集約されることであっても、主管部門との調整、他の業務との整合性をとることに多くの時間を割かれた。日中の時間帯のほぼ７、８割が会議であった。必然的に自分の中で考えをまとめたり、資料を作ったりというのは残業時間で行うことしかできないことになった。コミュニケーションパスが多すぎて一つのことを決めるために小さなことから大きなことまで会議会議の連続であった。

2.について。優秀な人はまあいいとして、ソフトウェア開発プロジェクトには向き不向きがあると思う。向いている人というのは、

1. 積極的にコミュニケーションを取れる人。（単なる会話ではなく交渉能力、調整能力に長けた人）
2. 論理立てて物事を考えられる人。（なぜそれをするのかを突き詰めて考えることができる人）

の2点のうちどちらかでもできる人でないと辛いのではと思う。人間性はすごくいい人なのだけれどもプロジェクトにおいてつらい毎日を送っている人が何人かいた。マネージャーは適性を見抜いて人を配置することがすごく重要だと思う。不向きの人がいた場合、３人いて３人分の仕事があるのに、２．５人分の仕事しかこなせない体制になっている場合がしばしばある。その場合優秀な人がフォローに回ることになる。

3.について。プロジェクトと主管部門との力関係で、決めたことが左右される。また長期にわたるプロジェクトの場合、主管部門の担当者の異動があったりすると方針が１８０度がらっと変わったりもする。それは担当者レベルでもマネージャーレベルでもあった。

上記のことが重なり合い、毎日のように起こっているとチームメンバーの士気はさがっていく。決めるべきことがいつまでたっても決まらない。度々の方向転換があり、右往左往する。仕事時間は増える。

なので「このプロジェクトの目標は達成不可能」と思い込むとなる。

プロジェクト開発に関する見積について過去の振り返り

IT開発プロジェクトにおける規模見積について考えてみた。

IPA情報処理推進機構によると、見積の要素としては、以下の要素が挙げられている。

"

規模

　ファンクションポイント

　コード行数

 　機能数、画面数、テーブル数

その他見積りに影響を与えるもの（工数の変動要因）

　プラットフォーム/環境

　ハードウェア、オペレーティングシステム

 　言語、ツール、ユーティリティ

 　開発環境

プロダクト

　アプリケーション種別

　複雑度、要求される信頼性

　ライフサイクル

人材

　能力と経験

　総労働時間

"

見積は当初の計画時からどんどん増える方向に乖離していくものである。（残念ながら少なくなる方向に乖離していくことは経験したことがない。そういう事例はあるのだろうか？）多くの場合、計画（提案）時には、上記の要素の大部分はわからないことが多い。そこで、経験者、あるいはひどい場合は開発未経験の営業さんがエィっとドンブリ勘定で出すことが多い。さらには、「予算はこれぐらいと決まっているから。この範囲内でよろしく！」とどんなことをするのかも決まっていないのに型にはめられてしまうこともある。

自分が経験した中で一番優れた見積は、ある中規模SIベンダーさんで、上記のような要素を入力すると自動的にブレ幅も示した上で、開発規模を算出してくれるツールをもっていた。しかも過去の多数のプロジェクトの実績を加味しながら、そのツールは常に進化し続けていて、かなり精度の高い見積を出すことができたことがある。またそのプロジェクト独自の要素（今までに使ったことのない言語であるとか）も加味することができて非常に良くできたツールであった。

大規模SIベンダーさんであれば、過去事例も山ほどあるはずとおもうがそういったツールは、後にも先にも１度しか経験していない。（過去事例の要素を洗い出してみて、実績と突き合わせて分析すればかなり精度の高い見積が出せそうと思うのだけれども）

仮説に仮説を重ねて何らかの数字を出していってもほとんど意味のない数字になってしまう。が要件定義の具体的な個別タスクの工数の積算などそんなことをよくやった記憶がある。

成果物に対しての作業工数が測りにくい作業に対しては、作業の積み上げによる積算よりも、全体から俯瞰して算出したほうが良いような気がする。「考える」作業に対しての見積は一筋縄ではいかない。最終的には１ページの要件定義書であっても、それを作り上げる過程ではたくさんの会議があって、うんうんうなりながら考える時間がある。また会議で説得するための資料作りなどの作業もあまり目には見えない。なので細かい作業の一つ一つを洗い出して積み上げると、とんでもない工数となる。（それぐらいかかるのが現実に近いのだけれども）

大体のプロジェクトにおいては、もう「やりたいこと」がほとんど決まっていることが、前提になっている気がする。しかし実態は「やりたいことがわからない」ほうが多いと思う。「古いシステムと同じで！」というのも「やりたいことがわからない」に等しいと思っている。そういった場合には、要件定義の工数は際限なくかかっていく。そしてデスマーチへとつながっていく。

別のプロジェクトも健全度具合をチェックしてみた（過去のプロジェクト振り返りその10）

別のプロジェクトについてもチェックリストにそってチェックしてみた。サバイバルテストの詳細は、以下のURLにある。

http://www.construx.com/Thought_Leadership/Books/Survival_Guide/Resources_by_Subject/Survival_Test/

プロジェクトのチェックを早速始める。
完全に「はい」と言える場合は、3点。おそらく「そのとおり」の場合は2点。
そう言えなくもないという場合は1点。そうではない場合は、0点。
全体的に厳し目に採点することにする。

要求
6項目で、8点であった。

”
要求
1.明確なビジョンステートメントまたはミッションステートメントがプロジェクトで制定されているか。
2.すべてのチームメンバーが、ビジョンを達成可能であると信じているか？
"

は設問1は2点、設問2は1点であった。

計画立案
８項目で、9点であった。

"
計画立案
10.アーキテクチャと設計についての詳細な文書を作成してあるか。

13.プロジェクト計画には休日、休暇、病欠、教育などの時間が見込まれているか。さらに、リソースの使用率が100%未満で計画されているか。
"

は、設問10は2点、13は0点であった。

プロジェクトのコントロール
10項目で、14点であった。

15.意思決定権を持つ特定の役員が、プロジェクトの責任者として選任されているか、さらに、その人物は積極的にプロジェクトを支持しているか。

17.完全に達成されたか、あるいはまったく達成されていないかを判定できる「二者択一型」の明確なマイルストーンが、プロジェクトの要所に設定されているか。

19.フィードバックするための制度が設けられているか。この制度は、プロジェクトのメンバーが直属の上司や経営上層部に対して匿名で問題を報告できる必要がある。
"

設問15は3点、17、19は0点であった。

リスクマネジメント
3項目で、2点であった。

"
リスクマネジメント
25.プロジェクト計画案には、プロジェクトが現在抱えているリスクの一覧を明示した資料が含まれているか、その一覧は最近更新されたか。

"
26.プロジェクトの管理責任者がいるか。その責任者は、プロジェクトに発生しているリスクを発見して特定する責任を持つ。
"

設問25、26ともに1点であった。

人的資源
6項目で、6点であった。

"
人的資源
30.そのプロジェクトを成功に導ける指導力を持った技術リーダーがいるか。
"

設問30は0点であった。

合計は、39点。先のプロジェクトよりは点数は良いが、やはり危険領域である。
サバイバルガイドによると、40〜59点が普通のプロジェクトで、40点未満は危険と言及している。引用すると、

"
この範囲の得点しか獲得できなかったプロジェクトは、要求、計画立案、プロジェクトのコントロール、リスクマネジメント、人的資源という主要な領域において重大な弱点を持っている。このレベルのプロジェクトにとって最大の懸念は、そもそもプロジェクトそのものを完了できるかどうかということである。
"

実際にはまだこのプロジェクトは、現在進行形である。（自分はプロジェクトを離れてしまったが）現在のところ重大な問題を抱えていることがわかる。

ある過去の開発プロジェクトの要求、開発立案、プロジェクトのコントロール、リスクマネジメント、人的資源をチェックしてみた（過去のプロジェクト振り返りその9）

今回から過去関わったプロジェクトの２つについて、スティーブマコネル著のソフトウェアサバイバルチェックリストに沿ってチェックしてみる。サバイバルテストの詳細は英文だが以下のURLにある。

http://www.construx.com/Thought_Leadership/Books/Survival_Guide/Resources_by_Subject/Survival_Test/

プロジェクトのチェックを早速始める。
完全に「はい」と言える場合は、3点。おそらく「そのとおり」の場合は2点。
そう言えなくもないという場合は1点。そうではない場合は、0点。
全体的に厳し目に採点することにする。

要求
6項目で、7点であった。満点が18点なので半分以下。
自分が以前に言及した。

”
要求
1.明確なビジョンステートメントまたはミッションステートメントがプロジェクトで制定されているか。
2.すべてのチームメンバーが、ビジョンを達成可能であると信じているか？
"

は両方とも1点であった。

計画立案
８項目で、7点であった。

"
計画立案
10.アーキテクチャと設計についての詳細な文書を作成してあるか。

13.プロジェクト計画には休日、休暇、病欠、教育などの時間が見込まれているか。さらに、リソースの使用率が100%未満で計画されているか。
"

は、やはり両方1点であった。

プロジェクトのコントロール
10項目で、10点であった。

15.意思決定権を持つ特定の役員が、プロジェクトの責任者として選任されているか、さらに、その人物は積極的にプロジェクトを支持しているか。

17.完全に達成されたか、あるいはまったく達成されていないかを判定できる「二者択一型」の明確なマイルストーンが、プロジェクトの要所に設定されているか。

19.フィードバックするための制度が設けられているか。この制度は、プロジェクトのメンバーが直属の上司や経営上層部に対して匿名で問題を報告できる必要がある。
"

設問15は2点、17、19は0点であった。

リスクマネジメント
3項目で、3点であった。

"
リスクマネジメント
25.プロジェクト計画案には、プロジェクトが現在抱えているリスクの一覧を明示した資料が含まれているか、その一覧は最近更新されたか。

"
26.プロジェクトの管理責任者がいるか。その責任者は、プロジェクトに発生しているリスクを発見して特定する責任を持つ。
"

設問25は1点、26は0点であった。

人的資源
6項目で、7点であった。（実際の人物を顔を思い出して甘く点数をつけてしまったかも）

"
人的資源
30.そのプロジェクトを成功に導ける指導力を持った技術リーダーがいるか。
"

設問30は0点であった。

合計は、25点。

サバイバルガイドによると、40〜59点が普通のプロジェクトで、40点未満は危険と言及している。引用すると、

"
この範囲の得点しか獲得できなかったプロジェクトは、要求、計画立案、プロジェクトのコントロール、リスクマネジメント、人的資源という主要な領域において重大な弱点を持っている。このレベルのプロジェクトにとって最大の懸念は、そもそもプロジェクトそのものを完了できるかどうかということである。
"

実際にどうであったかというと、何を持って完了とするかによるが、結果的にサービスを提供することはできた。ただし予算は当初のおそらく3倍に膨れ上がった。またサービス提供後の運用にも大変な苦労をしていると伝え聞く。
個人的には、当初の計画の予算、期間、品質を守って（当然ある程度のブレ幅は許容するとして）成功と考える。このプロジェクトの場合、予算、品質は失敗プロジェクトと言えるのかもしれない。