久しぶりにブログを書いてみる。12月は色々忙しく、書く気力がありませんでした。
2016年は、一旦自分の研鑽のために、今後10年のために、勉強に割り当てると決めたはずだった。しかしながら秋には変節し、再びプロジェクトへと参画した。参画自体は後悔はしていないが、時間の使い方を見直さなければなあと考えた。
最初はIT技術の全方位を勉強しようといろいろ読み漁り、自分のPCにインストールをし、勉強をした。しかし現在、IT技術はますます多様化、複雑化していて、全方位で勉強するにはとてつもない時間が必要と感じた。
2017年、プロジェクトがどうなるかはまだわからないが、プロジェクト内で本務ではないが、データベースのことを考える機会が多かった。もしもう少し勉強をする時間ができたらデータベース技術を中心に勉強してみたい。
さて世の中全般をみると、2016年は、AIの年だったと言えるかもしれない。将棋や囲碁が話題になったが、自分にとっては、AIの医療や自動運転への応用が驚いた。
人間では思いつかなかった治療方法がAIから提案されたり、
過去には、自動運転について懐疑的な内容のブログを書いたりしたが、いろいろ調べるにつれ、実はもうすでに人間が運転するより、AIが運転するほうがより安全なレベルまで進歩しているとか。
2017年もやはりAIの応用を中心に世の中は動いていくと思う。もっと言ってしまえば人間と世の中のサイバー化が進んでいくのではと考える。（パラリンピックで障碍者が、補助器具の力を借りて、一部の競技ではオリンピックの記録を上回ったりすることがあるとのこと）
とすると世界で一番少子高齢化が進む日本がある程度の幸福を甘受し続けるためには、AIとロボット技術の発展が不可欠であるように思う。
（運輸業界の人手不足とか、AIによって緩和できるのではと思う。高速道路での無人トラックのコンボイとか夢が溢れる）
自分のすきなSF小説に、ブルース・スターリングの「スキズマトリックス」という本がある。そのなかに工作者（バイオテクノロジーに特化し自分を改造した未来の人間）と機械主義者（メカトロニクスに特化し自分を改造した未来の人間）の対立が描かれる。日本人はどちらにいくのだろうか？あるいは両方のハイブリッドか？
2017年1月9日月曜日
2016年12月4日日曜日
ExcelのCSVの取り扱いについて（苦労した）
テストデータを作っていて、苦労したので記録しておく。
バージョンはExcel2010だった。
データはCSVで数行のデータをコピペして、ところどころ値を変えて１万行くらいに増殖させようとしていた。CSVなので下記のような形。
（CSVにもいろいろ方言はあるが）
”ABC","¥123,456","XYZ"
みたいな形。
このCSVをExcelで編集して「CSV」形式で保存しても勝手に下記のような形式に変換される。
ABC,"¥123,456",XYZ
つまり
バージョンはExcel2010だった。
データはCSVで数行のデータをコピペして、ところどころ値を変えて１万行くらいに増殖させようとしていた。CSVなので下記のような形。
（CSVにもいろいろ方言はあるが）
”ABC","¥123,456","XYZ"
みたいな形。
このCSVをExcelで編集して「CSV」形式で保存しても勝手に下記のような形式に変換される。
ABC,"¥123,456",XYZ
つまり
- 勝手にダブルクォートを削除する。
- 全部削除ならまだ統一感があるが、データ内にカンマ「,」が含まれているとその列のダブルクォートは残す。
テストデータとしては、全部ダブルクォートで囲みたいので、sedで編集した。
小さな親切、大きなお世話だ。
2016年11月13日日曜日
IT開発プロジェクにおける計画外のタスクについて
また、みずほ銀行の基幹システム開発が話題になっている。本当か嘘かわからないが、工数の９割が進捗会議についやされているという噂を見た。また進捗会議にむけての会議もあるらしい。
通常計画フェーズにおいて、スケジュールを引く、ウォーターフォールだろうがアジャイルだろうが引くはずだ。形式は、ガントチャートかもしれないし、チケット形式かもしれない。とにかくやるべきことを明確にしようとするはずだ。
しかしながら、いざ計画から設計〜開発、テストとフェーズが進むと計画外のタスクが増えてくる。
内容は、問題解決のための活動が多いが、それ以外の活動もある。冒頭に述べた会議のための活動もその一つだ。またメンバー内での意識合わせもある。予期していなかった他チームからの依頼も非常におおい。資料をExcelで作成（Excelのほうが作るのに便利だと思ったから）していたら、別の人に見せるためにPowerPointに作り直してくれと言われることもある。なので似たような資料が増殖していくことが多い。どれが本物かわからない。その確認のためにまた作業が発生する。
そのように計画外タスクが増え続ける状況にもかかわらず、計画したタスクの期限は守れという。仕事量の総量は増え続けているのに期限を守れるはずもない。みずほ銀行の内部は、こういった状況になっているのではないかと想像する。
予算（人かける期間）は最初に決まってしまっているので、増えてしまった作業を計画に組み込むことができない。どうしようもないほど計画したタスクが遅れてしまった時には、「当初計画した」タスクは見直すが、よほど大きくかつ皆が必要だと認める作業は追加されない。資料の再生産や、会議のための会議は結構な作業量になるが、これをタスクと認めてくれるリーダーは少ない。これら作業量が臨界点を超えるとプロジェクトは失敗する。
通常計画フェーズにおいて、スケジュールを引く、ウォーターフォールだろうがアジャイルだろうが引くはずだ。形式は、ガントチャートかもしれないし、チケット形式かもしれない。とにかくやるべきことを明確にしようとするはずだ。
しかしながら、いざ計画から設計〜開発、テストとフェーズが進むと計画外のタスクが増えてくる。
内容は、問題解決のための活動が多いが、それ以外の活動もある。冒頭に述べた会議のための活動もその一つだ。またメンバー内での意識合わせもある。予期していなかった他チームからの依頼も非常におおい。資料をExcelで作成（Excelのほうが作るのに便利だと思ったから）していたら、別の人に見せるためにPowerPointに作り直してくれと言われることもある。なので似たような資料が増殖していくことが多い。どれが本物かわからない。その確認のためにまた作業が発生する。
そのように計画外タスクが増え続ける状況にもかかわらず、計画したタスクの期限は守れという。仕事量の総量は増え続けているのに期限を守れるはずもない。みずほ銀行の内部は、こういった状況になっているのではないかと想像する。
予算（人かける期間）は最初に決まってしまっているので、増えてしまった作業を計画に組み込むことができない。どうしようもないほど計画したタスクが遅れてしまった時には、「当初計画した」タスクは見直すが、よほど大きくかつ皆が必要だと認める作業は追加されない。資料の再生産や、会議のための会議は結構な作業量になるが、これをタスクと認めてくれるリーダーは少ない。これら作業量が臨界点を超えるとプロジェクトは失敗する。
2016年11月11日金曜日
ITプロジェクトで失敗した時
当たり前のことだけれども人間だれしも失敗をする。その時どのような心持ちでいれば良かったかを書いてみたいと思う。なぜこのとこを書こうかと思ったかと言えば、最近自分はプロジェクトで小さな失敗をした。（正確に言うと失敗をしたかも知れないと思い込んでビクビクしていた）その時に冷静に考えて、なんで自分はこんなにビクビクするんだろうと振り返ってみた。
過去自分はプロジェクトの激務で体調を崩し、長期にわたって休んでしまったことがある。それは失敗をリカバリーしようとして激務に激務を重ねて結果的に体調を崩してしまった。
（もとからそのプロジェクトは失敗していたが、リカバリーせよとの指示を受けてプロジェクトに入った）
その時のトラウマがあるのだろうと思う。その時の自分は委任契約で大手ITベンダーに雇われていた。それなりに高給の契約ではあったが、契約上はプロジェクトの成否に一切責任のない立場のはずであった。
しかし実態はユーザーさんから毎日毎日「どうなっているんだ！怒」と責められ、どなられる毎日であった。しまいには「お前のせいでこれこれの金額分の損失を被った。どう賠償してくれるんだ！」と言われた。ベンダーのPMに相談したがなにもしてくれなかった。
また同じ立場であるはずの協力会社の人も責めてしまった。「なんでできないんだ！」とか「どうしてこうなった」と言ってしまった。
結局のところ「火中の栗を拾う」とは聞こえが良いが、「本当」の責任者は責任をとらず、委任契約である自分に便宜上責任を押し付けたのだった。
その時の自分は「プロジェクトを救う！」といった今考えると意味の無い義侠心にかられて、仲間を責め、自分を責め、プライベートもすてて頑張ったが、個人の力では限界もあり潰れてしまった。
委任契約で個人が受けるペナルティーは、契約を打ち切られる以外にはなく、責められるいわれもないはずである。
通常は契約の継続は生活の安定とリンクしているので、ついつい無理をしてしまいがちになる。とことん追い詰められると最後は「死」を意識してしまうまでになるが、サラリーマンと違って労災は降りない。残業代も契約上明記がなければ請求権はない。
なので心の安定を図る為、いつでも契約を打ち切られる（こちらから打ち切る）ことを念頭において仕事をしている。「信頼している」と言われてもその人は99%生涯の面倒は見てくれない。どころか半年先の約束でさえ平気で破る。なので戦国時代の武将では無いが、常に死地にあることを意識していれば、おのずと飄々と「責任逃れ」ができる。責任はないので責任逃れという言葉はおかしいが。
冒頭に書いたビクビクしてしまった理由は、昔の記憶が少し残っていたからだろうと思う。なので、何かあったらこのブログを見直して、これからも飄々とプロジェクトに関わることができればと思う。
委任契約の関係は、切るか切られるかしかないのだから。
過去自分はプロジェクトの激務で体調を崩し、長期にわたって休んでしまったことがある。それは失敗をリカバリーしようとして激務に激務を重ねて結果的に体調を崩してしまった。
（もとからそのプロジェクトは失敗していたが、リカバリーせよとの指示を受けてプロジェクトに入った）
その時のトラウマがあるのだろうと思う。その時の自分は委任契約で大手ITベンダーに雇われていた。それなりに高給の契約ではあったが、契約上はプロジェクトの成否に一切責任のない立場のはずであった。
しかし実態はユーザーさんから毎日毎日「どうなっているんだ！怒」と責められ、どなられる毎日であった。しまいには「お前のせいでこれこれの金額分の損失を被った。どう賠償してくれるんだ！」と言われた。ベンダーのPMに相談したがなにもしてくれなかった。
また同じ立場であるはずの協力会社の人も責めてしまった。「なんでできないんだ！」とか「どうしてこうなった」と言ってしまった。
結局のところ「火中の栗を拾う」とは聞こえが良いが、「本当」の責任者は責任をとらず、委任契約である自分に便宜上責任を押し付けたのだった。
その時の自分は「プロジェクトを救う！」といった今考えると意味の無い義侠心にかられて、仲間を責め、自分を責め、プライベートもすてて頑張ったが、個人の力では限界もあり潰れてしまった。
委任契約で個人が受けるペナルティーは、契約を打ち切られる以外にはなく、責められるいわれもないはずである。
通常は契約の継続は生活の安定とリンクしているので、ついつい無理をしてしまいがちになる。とことん追い詰められると最後は「死」を意識してしまうまでになるが、サラリーマンと違って労災は降りない。残業代も契約上明記がなければ請求権はない。
なので心の安定を図る為、いつでも契約を打ち切られる（こちらから打ち切る）ことを念頭において仕事をしている。「信頼している」と言われてもその人は99%生涯の面倒は見てくれない。どころか半年先の約束でさえ平気で破る。なので戦国時代の武将では無いが、常に死地にあることを意識していれば、おのずと飄々と「責任逃れ」ができる。責任はないので責任逃れという言葉はおかしいが。
冒頭に書いたビクビクしてしまった理由は、昔の記憶が少し残っていたからだろうと思う。なので、何かあったらこのブログを見直して、これからも飄々とプロジェクトに関わることができればと思う。
委任契約の関係は、切るか切られるかしかないのだから。
2016年11月3日木曜日
システム要件の暗黙知化について（あるいは無知）
要件定義のポイントは、だれにでもその要件がわかるようにすることが必要と思う。文章でもいいし図表でもいいし確かにああそうだねと理解できることが必要。業務の流れ、データの流れ、インプットとアウトプットを明確に知りたいと思う。
しかし要件定義において良くあるのは、「現行通りにつくってください」ということがよくある。そのパターンが一番困る。現行を知るためには、無限のインプットのパターンとそのアウトプットを確認するか、何万行〜何百万行のソースコードをよむしかない。ソースコードの中にもマジックリテラルが仕込まれていて意味不明なことは普通にあり得る。
ではお客様はどのようにシステムを使って仕事をしているのだろうか？仕事のひとつひとつの意味を理解している人は少ないのかもしれない。企業は、一人一人の仕事の総体でお金を稼いでいるはずなのだけれでも、自分の担務の意味（特にシステムを使う意味）を理解している人は少ないのかもしれない。画面の文字の位置、帳票の文字の大きさには異常にこだわるのに、なぜその位置に文字がないと困るのか答えられる人はいない。
当初この文章を書き始めたのは、要件が属人化していてプロジェクト全体に共有化されにくいということを書こうと思った。その仕事のある領域では達人みたいなひとがいて、またそれを聞き取ったエンジニアも共有できる形に要件をまとめきれず、結果的に設計をするにあたって「聞き直す」しかない。「なんでそんなこともわからないのか？」「まえに話したはずなんだけれども」と怪訝な顔をされる場面が過去によくあったからだ。
しかし、よくよく考えてみると上段で書いたように実は「本当に要件を知っている」人はいないのかもしれない。細部にわたってこだわりがあり、何かを知っているように見えて、なぜそのような仕事の仕方なのかを理解している人はいない気がする。
したがって要件が不明なプロジェクトは失敗する。
※最後に「プロジェクトは失敗する」でしめるのが多くなってきた気がする。失敗シリーズとでも名付けようかな。
しかし要件定義において良くあるのは、「現行通りにつくってください」ということがよくある。そのパターンが一番困る。現行を知るためには、無限のインプットのパターンとそのアウトプットを確認するか、何万行〜何百万行のソースコードをよむしかない。ソースコードの中にもマジックリテラルが仕込まれていて意味不明なことは普通にあり得る。
ではお客様はどのようにシステムを使って仕事をしているのだろうか？仕事のひとつひとつの意味を理解している人は少ないのかもしれない。企業は、一人一人の仕事の総体でお金を稼いでいるはずなのだけれでも、自分の担務の意味（特にシステムを使う意味）を理解している人は少ないのかもしれない。画面の文字の位置、帳票の文字の大きさには異常にこだわるのに、なぜその位置に文字がないと困るのか答えられる人はいない。
当初この文章を書き始めたのは、要件が属人化していてプロジェクト全体に共有化されにくいということを書こうと思った。その仕事のある領域では達人みたいなひとがいて、またそれを聞き取ったエンジニアも共有できる形に要件をまとめきれず、結果的に設計をするにあたって「聞き直す」しかない。「なんでそんなこともわからないのか？」「まえに話したはずなんだけれども」と怪訝な顔をされる場面が過去によくあったからだ。
しかし、よくよく考えてみると上段で書いたように実は「本当に要件を知っている」人はいないのかもしれない。細部にわたってこだわりがあり、何かを知っているように見えて、なぜそのような仕事の仕方なのかを理解している人はいない気がする。
したがって要件が不明なプロジェクトは失敗する。
※最後に「プロジェクトは失敗する」でしめるのが多くなってきた気がする。失敗シリーズとでも名付けようかな。
2016年11月2日水曜日
ITプロジェクトのプロセス改善と標準化
ITプロジェクトをやっていると、よくお客様に対して「新規システムを導入するだけではダメで、プロセス改善も同時に行ってください！そうでないと効果がないです！！」と言う場面がある。
それは実際真実なのだが、振り返ってみるとプロジェクト内部でも色々とプロセスを改善したいことが良くある。ツールを導入して効率化してと言う場合もあれば、プロセスそのものを変更したらもっと効率的にプロジェクトを運用できるのにということもあった。
しかしお客様に向かっては厳しくいうくせに自身のプロジェクト運営は全然ダメだった。
一つは、プロジェクトの標準ツールが決まっていて、それ以外は導入してならぬとか。それは大体ExcelかPowerPointかWordか、一般的な企業なら大体あるはずのツールをしか使わせてもらえない。ガントチャートを引くのにMS Projectを使いたいと言ったら「高いからダメだ」とか。IT企業のくせに情報化投資を全然しない。Excel大活躍である。もっともお金がかかるのは人件費なのに、ツールにお金をかけることには極めて消極的だった。
もう一つはプロセスを変えたいとプロジェクト内部で提案した時に、決まり文句で「決まったことだから」「他のチームもプロセスを変えなければならないので無理」とか。
そんなIT企業が真にお客様のための業務効率化に寄与できるとは思わない。「つくることだけ」が目的になっているプロジェクトが多いのではないかと思う。
ちなみにMS Projectは最近しらべたらブラウザベースの簡易版で月に700円程度。実績入力と閲覧だけならこれで十分と思う。アプリをインストールするタイプでも月3600円ぐらい。計画立案をしたりカスタムレポートを使ったりするならば、こちらの方がいいと思うが、それでも3600円だ。
あとプロセスに関しては、お客様側のキーマンに直訴して俺様プロセスを作ったりしていた。本当は良くないのだが、非効率ゆえに仕事量に圧殺されて本当にやるべきことができなくなってしまうからだ。（レポートの為にコピペを繰り返すのに時間を割くのはもったいない）
よってそんな非効率プロジェクトは大体うまくはいかない。
それは実際真実なのだが、振り返ってみるとプロジェクト内部でも色々とプロセスを改善したいことが良くある。ツールを導入して効率化してと言う場合もあれば、プロセスそのものを変更したらもっと効率的にプロジェクトを運用できるのにということもあった。
しかしお客様に向かっては厳しくいうくせに自身のプロジェクト運営は全然ダメだった。
一つは、プロジェクトの標準ツールが決まっていて、それ以外は導入してならぬとか。それは大体ExcelかPowerPointかWordか、一般的な企業なら大体あるはずのツールをしか使わせてもらえない。ガントチャートを引くのにMS Projectを使いたいと言ったら「高いからダメだ」とか。IT企業のくせに情報化投資を全然しない。Excel大活躍である。もっともお金がかかるのは人件費なのに、ツールにお金をかけることには極めて消極的だった。
もう一つはプロセスを変えたいとプロジェクト内部で提案した時に、決まり文句で「決まったことだから」「他のチームもプロセスを変えなければならないので無理」とか。
そんなIT企業が真にお客様のための業務効率化に寄与できるとは思わない。「つくることだけ」が目的になっているプロジェクトが多いのではないかと思う。
ちなみにMS Projectは最近しらべたらブラウザベースの簡易版で月に700円程度。実績入力と閲覧だけならこれで十分と思う。アプリをインストールするタイプでも月3600円ぐらい。計画立案をしたりカスタムレポートを使ったりするならば、こちらの方がいいと思うが、それでも3600円だ。
あとプロセスに関しては、お客様側のキーマンに直訴して俺様プロセスを作ったりしていた。本当は良くないのだが、非効率ゆえに仕事量に圧殺されて本当にやるべきことができなくなってしまうからだ。（レポートの為にコピペを繰り返すのに時間を割くのはもったいない）
よってそんな非効率プロジェクトは大体うまくはいかない。
2016年10月30日日曜日
IT開発プロジェクトにおける要件（または要求）定義と以降の局面の期間割合について
大体のベンダーさんにおいては、ウォーターフォールアプローチを取ることが多いのだけれども、すごく大雑把に言って各局面の期間割合は、
要件定義：1
基本設計：2
詳細設計・開発・単体テスト：3
結合テスト：2
総合テスト：2
ぐらいでは無いかと思う。
いつも思うのだが、テスト局面を手厚くして、要件定義及び基本設計にそれほど時間をかけていないのはどうかと思う。実際問題、要件は決め切れないことが多いし、細かい要件について引き出そうとするときりがなくなるというのはわかる気がする。
しかし、それにしても要件定義時の資料の陳腐化が激しくて、以降の局面でその資料が使い物にならないことが多すぎる。また忙しくて要件定義時の資料を直そうということ起こらない。
結果的に要件定義っぽい活動を延々と続けていることになる。テスト局面に入っても。テスト局面が比較的長くとってあるのは、要件が未決定のまま開発に突入してしまうことが多すぎて、経験則からテスト局面を長くとってしまうのではと考える。
ならばいっそ要件定義の局面をできるだけ長くとってはどうかと思う。自分の経験上はできる限り長く要件定義（あるいは要求、システム構想）の期間をとってじっくりユーザーさんと「やりたいこと」を煮詰めてから開発に突入した方が良い結果が生まれる気がする。開発することが明確であるならば期間は短くてもかなりのスピード感をもって開発を進めることができるはず（そうそう特殊なロジックを必要とするアプリケーションはない）
後続局面での手戻りほどオーバーヘッドが大きいのは周知の事実である。なので、できる限り不明なことは、事前に潰しておきたいというのが自分の方針になっている。
工数的にみても、最初プロジェクトの立ち上がりは、数人で始まり、だんだん人数が増えて、最盛期に数十人〜数百人に達するということが多いと思う。
数人で受け取った要件を数十人に展開するのはかなり難しいと思うし、数人では気づきが少ないことも多いと思う。
よって要件定義早期に多くの人間を投入し、それなりの期間を取ることができれば、品質も良く、開発・テスト期間も圧縮できると考える。
要件定義：1
基本設計：2
詳細設計・開発・単体テスト：3
結合テスト：2
総合テスト：2
ぐらいでは無いかと思う。
いつも思うのだが、テスト局面を手厚くして、要件定義及び基本設計にそれほど時間をかけていないのはどうかと思う。実際問題、要件は決め切れないことが多いし、細かい要件について引き出そうとするときりがなくなるというのはわかる気がする。
しかし、それにしても要件定義時の資料の陳腐化が激しくて、以降の局面でその資料が使い物にならないことが多すぎる。また忙しくて要件定義時の資料を直そうということ起こらない。
結果的に要件定義っぽい活動を延々と続けていることになる。テスト局面に入っても。テスト局面が比較的長くとってあるのは、要件が未決定のまま開発に突入してしまうことが多すぎて、経験則からテスト局面を長くとってしまうのではと考える。
ならばいっそ要件定義の局面をできるだけ長くとってはどうかと思う。自分の経験上はできる限り長く要件定義（あるいは要求、システム構想）の期間をとってじっくりユーザーさんと「やりたいこと」を煮詰めてから開発に突入した方が良い結果が生まれる気がする。開発することが明確であるならば期間は短くてもかなりのスピード感をもって開発を進めることができるはず（そうそう特殊なロジックを必要とするアプリケーションはない）
後続局面での手戻りほどオーバーヘッドが大きいのは周知の事実である。なので、できる限り不明なことは、事前に潰しておきたいというのが自分の方針になっている。
工数的にみても、最初プロジェクトの立ち上がりは、数人で始まり、だんだん人数が増えて、最盛期に数十人〜数百人に達するということが多いと思う。
数人で受け取った要件を数十人に展開するのはかなり難しいと思うし、数人では気づきが少ないことも多いと思う。
よって要件定義早期に多くの人間を投入し、それなりの期間を取ることができれば、品質も良く、開発・テスト期間も圧縮できると考える。
2016年10月10日月曜日
IT開発プロジェクトの個人個人の生産性について（過労死事件に寄せて）
電通で入社１年目の方が自死された事件について、労災認定されたことが話題になっている。その方のTwitterの投稿を見るとそれは凄まじく言い尽くせない悲しみを感じた。
また以前ワタミで自死された新入社員の過労死認定の訴訟を行った遺族の方が、和解金を使って「ブラック企業」との訴訟費用を援助する基金を設立されたとのニュースもみた。
自分自身を振り返ると、かつては自死された方ほどではないが、徹夜も辞さないとの姿勢で働いていたことがある（30代前半ぐらいまでだが）。また周囲に対してもそのような姿勢が望ましいとの考えを持っていたことがある。
結論から言うとそれは誤っていた。
自死された方との違いは、「頑張っている自分」に酔っていたのと、なんだかんだ（仮眠とか、ちょっとしたサボりで）休んでいたからだと思う。
毎日16時間からそれ以上働いていたが、客観的に見ると本当に生産的なことができたのは8時間以内で、もっというと最高の集中力を発揮できたのは5、6時間だったと思う。
残りの時間は、何かを待っていたり、無駄な会議（ほんとうなら自分は必要のない会議）に参加したり、実質的には何もしていなかったように思う。PCの画面をぼーっと眺めているだけの時間もあったように思う。無理に長時間何かをしようとしても思考力が低下しているので、ミスも多くなりミスをカバーするためにさらに時間を要するという悪循環に陥った。
ITの（あるいは日本の）世界では、何も生み出さなくても頑張っている姿勢を示すことが大事という風潮があるように思う。本来合理的な活動であるはずの会社（あるいはプロジェクト）において非合理的、非科学的な行動規範を求められるのは馬鹿げている。
（長時間労働を強要し、ましてや残業時間のごまかしなどが行なわれている。ブラック企業とか聞こえよくいうが、違法行為である）
なので30代後半からはなるべく長時間労働をしないようにしていたが、それでも周辺からのプレッシャーと自分への過信と（信頼されていることに対しての）自己満足で長時間労働してしまったことがある。結果的には体調を崩してしまった。崩した結果、プロジェクトを休んだりしてしまった。休みを含めた平均労働時間は、8時間を確実に切っている。ならば最初から長時間労働しないほうがよかったのではないかと思う。休めば急に人がいなくなるので、代わりの人を探したり、代替要員の新たな学習コストもバカにならない。
※補足すると思い返すと「信頼」とは聞こえが良いが、実際には「お前が働かないと俺が困る」という利己主義に基づくもの。
無能な管理職で「プレッシャーをあたえると生産性があがる」という奇妙な考えを持つ人がいる。そんなデータはどこにもない。
おそらく「火事場の馬鹿力」のような考えなのだとは思うが、ITプロジェクトは、日々続く普通の経済活動であり、「極限状況において、人間がごく稀に発揮する力」を期待するのは無能の極みである。※火事場の馬鹿力も客観的なデータがあるのかわからない。都市伝説ではないかと思う。自分自身は、高いプレッシャーの環境下でいつもより良いパフォーマンスを示せたことは無い。（低下するほうが多かったように思う）
オリンピックのトップアスリートは、いかにリラックスするかを常に考えている。
プロジェクトで生産性を向上させるには、いかにコミュケーションをとっていくかの創意工夫が必要と考える。いわゆるアジャイル方法論が注目されるのもコミュニケーションを重視する方法論であるからだと思う。
ITに関わる方で（それ以外の業種の方でも）、ぜひ読んでおいて欲しいのが、
人月の神話（フレデリック・ブルックス）
ピープルウェア（トム・デマルコ）
アジャイルソフトウェア開発宣言※最後の2行をちゃんと頭の隅に置いておくこと
である。いかに長時間労働が、クオリティを低下させるかが見えてくると思う。自分はこれらを勉強することによって間違った考えを修正することができたように思う。特にトム・デマルコは自分にとっての神様みたいな存在（会ったこと無いけど著作を通じて）。
最後にトム・デマルコの著作 デッドライン（これも名著）から引用しておく、
”プレッシャーをかけても思考は速くならない”
至言であると思う。
また以前ワタミで自死された新入社員の過労死認定の訴訟を行った遺族の方が、和解金を使って「ブラック企業」との訴訟費用を援助する基金を設立されたとのニュースもみた。
自分自身を振り返ると、かつては自死された方ほどではないが、徹夜も辞さないとの姿勢で働いていたことがある（30代前半ぐらいまでだが）。また周囲に対してもそのような姿勢が望ましいとの考えを持っていたことがある。
結論から言うとそれは誤っていた。
自死された方との違いは、「頑張っている自分」に酔っていたのと、なんだかんだ（仮眠とか、ちょっとしたサボりで）休んでいたからだと思う。
毎日16時間からそれ以上働いていたが、客観的に見ると本当に生産的なことができたのは8時間以内で、もっというと最高の集中力を発揮できたのは5、6時間だったと思う。
残りの時間は、何かを待っていたり、無駄な会議（ほんとうなら自分は必要のない会議）に参加したり、実質的には何もしていなかったように思う。PCの画面をぼーっと眺めているだけの時間もあったように思う。無理に長時間何かをしようとしても思考力が低下しているので、ミスも多くなりミスをカバーするためにさらに時間を要するという悪循環に陥った。
ITの（あるいは日本の）世界では、何も生み出さなくても頑張っている姿勢を示すことが大事という風潮があるように思う。本来合理的な活動であるはずの会社（あるいはプロジェクト）において非合理的、非科学的な行動規範を求められるのは馬鹿げている。
（長時間労働を強要し、ましてや残業時間のごまかしなどが行なわれている。ブラック企業とか聞こえよくいうが、違法行為である）
なので30代後半からはなるべく長時間労働をしないようにしていたが、それでも周辺からのプレッシャーと自分への過信と（信頼されていることに対しての）自己満足で長時間労働してしまったことがある。結果的には体調を崩してしまった。崩した結果、プロジェクトを休んだりしてしまった。休みを含めた平均労働時間は、8時間を確実に切っている。ならば最初から長時間労働しないほうがよかったのではないかと思う。休めば急に人がいなくなるので、代わりの人を探したり、代替要員の新たな学習コストもバカにならない。
※補足すると思い返すと「信頼」とは聞こえが良いが、実際には「お前が働かないと俺が困る」という利己主義に基づくもの。
無能な管理職で「プレッシャーをあたえると生産性があがる」という奇妙な考えを持つ人がいる。そんなデータはどこにもない。
おそらく「火事場の馬鹿力」のような考えなのだとは思うが、ITプロジェクトは、日々続く普通の経済活動であり、「極限状況において、人間がごく稀に発揮する力」を期待するのは無能の極みである。※火事場の馬鹿力も客観的なデータがあるのかわからない。都市伝説ではないかと思う。自分自身は、高いプレッシャーの環境下でいつもより良いパフォーマンスを示せたことは無い。（低下するほうが多かったように思う）
オリンピックのトップアスリートは、いかにリラックスするかを常に考えている。
プロジェクトで生産性を向上させるには、いかにコミュケーションをとっていくかの創意工夫が必要と考える。いわゆるアジャイル方法論が注目されるのもコミュニケーションを重視する方法論であるからだと思う。
ITに関わる方で（それ以外の業種の方でも）、ぜひ読んでおいて欲しいのが、
人月の神話（フレデリック・ブルックス）
ピープルウェア（トム・デマルコ）
アジャイルソフトウェア開発宣言※最後の2行をちゃんと頭の隅に置いておくこと
である。いかに長時間労働が、クオリティを低下させるかが見えてくると思う。自分はこれらを勉強することによって間違った考えを修正することができたように思う。特にトム・デマルコは自分にとっての神様みたいな存在（会ったこと無いけど著作を通じて）。
最後にトム・デマルコの著作 デッドライン（これも名著）から引用しておく、
”プレッシャーをかけても思考は速くならない”
至言であると思う。
2016年10月5日水曜日
ITシステム開発のミニマリズムとリリース（過去のプロジェクト振り返りその12）
今回は、ITシステム開発におけるミニマリズムについて書く。
ソフトウェアプロジェクトサバイバルガイドによると
"ソフトウェアプロジェクトで開発に成功するためには、ソフトゥアコンポーネントとその機能の複雑さという点について、要求定義時からリリースまで「単純なほど良い」という方針が必要である。"
とある。
自分は、古い業務システムをリプレースするプロジェクトが多かったが、古いシステムとなると過去のいろいろな経緯（機能追加の蓄積等）によって、どうしても置き換える新しいシステムは複雑になりがちである。その場合、自分はシステムの断捨離を推奨する。過去に組み込まれた多くの追加機能のほとんどは、ちょっと便利な機能であり、システムの根幹を左右するほどの機能はほとんどない。
いまだ人間は非常に優秀なシステムの一部であり、追加機能に100人月かけるならば、2人の人間の手作業でしのげないかどうかを検討するべきであると考える。
ただプロジェクトを実際にやっていると、そうは言ってもということがよくある。しかし最終的にリリースするソフトウエアが複雑であっても。最初のフェーズは単純に作り、その後、機能追加していくフォーズを設ければ良いと思う。つまり最終的なリリースとコア機能の構築フェーズ、追加機能の構築フェーズを切り離し、何段階にも分けて開発・テストを繰り返せば良い。
特にウォーターフォール開発では最初に（しかも短い期間で）、すべての機能要件の詳細をつまびらかにしなければ、次のフェーズに移れないという考えがあるが、そんなことは人間には無理である。
ソフトウェアプロジェクトサバイバルガイドによると
"ソフトウェアプロジェクトで開発に成功するためには、ソフトゥアコンポーネントとその機能の複雑さという点について、要求定義時からリリースまで「単純なほど良い」という方針が必要である。"
とある。
自分は、古い業務システムをリプレースするプロジェクトが多かったが、古いシステムとなると過去のいろいろな経緯（機能追加の蓄積等）によって、どうしても置き換える新しいシステムは複雑になりがちである。その場合、自分はシステムの断捨離を推奨する。過去に組み込まれた多くの追加機能のほとんどは、ちょっと便利な機能であり、システムの根幹を左右するほどの機能はほとんどない。
いまだ人間は非常に優秀なシステムの一部であり、追加機能に100人月かけるならば、2人の人間の手作業でしのげないかどうかを検討するべきであると考える。
ただプロジェクトを実際にやっていると、そうは言ってもということがよくある。しかし最終的にリリースするソフトウエアが複雑であっても。最初のフェーズは単純に作り、その後、機能追加していくフォーズを設ければ良いと思う。つまり最終的なリリースとコア機能の構築フェーズ、追加機能の構築フェーズを切り離し、何段階にも分けて開発・テストを繰り返せば良い。
特にウォーターフォール開発では最初に（しかも短い期間で）、すべての機能要件の詳細をつまびらかにしなければ、次のフェーズに移れないという考えがあるが、そんなことは人間には無理である。
- コア機能の要件と理解
- コア機能の開発・テスト
- コア機能を踏まえた上での追加機能の要件の検討
- 追加機能の開発・テスト
- 繰り返し
- リリースタイミングは、ユーザーが追加機能の充足度から判断して決めれば良い。
- 永遠に開発し続ける可能性もあるが、どこかで割り切ってリリースするはず。
おお！アジャイルっぽいとも思ったが、ちょっと違う気もする。アジャイルは早期リリースを重視するんじゃないんだっけ？？
2016年10月4日火曜日
ITプロジェクトを設計する
プロジェクトを設計するというと、少し変な感じがするがこの概念は勝手に自分が考えた。勝手にプロジェクト設計と名をつける。あるいはプロジェクトのためのプロジェクト(PfP:Project for Project)と名付ける。※商標登録しておこうかな。主に発注者側である企業さんに対してであるが、RFP(Request For Proposal)のさらに一段手前において
- 何をプロジェクトの目的とするか
- その手段として何を用いるか（ITなのか業務改善なのか、あるいはその両方なのか）
- どうやって目的の達成具合を測定するか
- おおよその規模感（1億円なら投資できるが、10億円は無理とか）
等々を明確化し、組み立てていく、要求をできるだけ定義していくのがこのフェーズの目的である。当然決まっていないこともあると思うが、それは「決まっていない」と明確化していく。（それによって提案も変わってくるから）成果物はプロジェクト計画書（設計書）となる。プロジェクト計画書の目次は、
- プロジェクト目的
- 対象業務・システム
- 対象業務・システム概要
- 主要課題
- 手段
- ITによる目的達成部分と達成手段の概要
- 業務改革による目的達成部分と達成手段の概要
- 効果
- 効果概要
- 効果の測定方法
- 意思決定者（組織）
- 実行組織
- 関連組織
- 要員規模
- 実行組織の要員規模
- 関連組織の要員規模
- 外部調達する要員規模
- プロジェクト終了に向けたスケジュール概要
- 内的主要マイルストーン（※プロジェクト自体のマイルストーン）
- 外的主要マイルストーン（※プロジェクト外で発生するマイルストーン、例えば法改正等）
- プロジェクト課題
- 主要課題
- 課題責任者
- 課題対策
- プロジェクトリスク
- 主要リスク
- リスク責任者
- リスク対策
ぐらいかなと思います。重要なのは、この計画書に意思決定者、実行組織、関連組織が内容に同意し、ハンコを押すこと。（血判状的な）※未決事項があるならそれはそれで良い。未決であることが明確であることに意義がある。
これぐらいをまず検討していると、プロジェクトの成功確率がぐっと高くなるのではと考える。
2016年9月29日木曜日
IT開発プロジェクトと軍隊（戦争）について
前にITプロジェクトと建築土木について書いたので。今回は、ITプロジェクトと軍隊（戦争）の類似について考えてみる。
似ていると思うところ。
似ていると思うところ。
- 戦略と戦術がある。
- 戦略目標は超重要。戦術レベルでいくら勝利しても。戦略的には敗北はする。
- 大部隊を動かす。
- 戦争にも大小あるが、総力戦になると数百万の人が動く。
- ITプロジェクトは最大規模でも数万だと思うが、十分大人数。
- プロジェクトのあるいは戦闘の初期段階では、情報が足らない。
- ITプロジェクトの場合は、要求、要件が不明確。できないことも不明確。
- 戦闘の場合は、敵の全容が不明確。現代戦ではあまりないのかもしれないが、味方の別部隊の動きも不明確（フォークランド紛争の戦記を読んで思いました。またしばしば味方への誤爆もあるから現代においても完全には相互連携は実現されていないのだと思う。）
戦略目標が重要というのは、これまでにも書いてきたので省略する。
戦術というのは、ITプロジェクトにおける各種方法論だと考える。戦略が破綻していれば、戦術（方法論）がいかに優れていても敗北する。
大部隊を動かすというのは、ITプロジェクトも軍隊も同じだが、（かってな思いだが）各々の兵隊が任務を達成して、それが全体の目的の達成につながるというのは軍隊の方が優れているのではないかと思う。ITプロジェクトにおいては、数千の人間がいても、そのうち何割かは何もしていないか、あるいは無駄なことをしているのを見てきた。
軍隊においてはそれはないと信じたい。なぜなら、少なくとも何かしていないと「死ぬ」から。（想像だが）軍隊においては個々の行動規範が明確化、マニュアル化されており、それに従った訓練がなされているから。千変万化する戦場において、（できるだけ）的確な行動を個人がするためには、それがマニュアル化と訓練が必要だと思う。
※なんとなく行動する軍隊とか想像できない。
ITプロジェクトでは、そのマニュアル化と訓練ができていないと思う。
各々の役割に対する行動規範が不明確で、また日々の訓練も出来ていない。大した研修もなしにOJTと称して最前線に投入されるのは、よくあることと思う。プログラミング研修などは、兵隊がライフルの撃ち方を教わるレベルであって体系立てた訓練とは言えないと思う。
ただし、ITプロジェクトは日々立ち上がるのに対して、戦争はそう滅多に起こらない。なので訓練の余裕がないのかもしれない。
また情報の不明確さに対しては、軍隊は情報をを重視する（どこに敵がいるかがわからないとお話にならない）ため、あらゆる手段を講じて情報を得ようとする。現代戦においては、「情報戦が勝敗を決める」とまで言われているようである。
ITプロジェクトにおいては、その情報を得て分析する努力が足りていないように思える。「見える化」が声高に言われて久しいが、見えた後の分析と行動ができていないように思う。事前に見えるようにもしない。（プロジェクト企画は常にバラ色の未来で、問題やリスクがあることを明記してあるのを見たことがない）
戦争においては、できるだけ本格的な戦闘の前に情報を得ようと、偵察を重視する。ITプロジェクトにおいても本格的なプロジェクト開始の前に「偵察」行動が必要なのではないか？それは、プロトタイピングかもしれないし、要求の分析、RFPをちゃんと書くことかもしれない。プロジェクト企画の段階で、「偵察」のプロが偵察行動を行うだけで、戦争に負ける＝プロジェクトが失敗することを防げるように考える。
2016年9月26日月曜日
IT開発プロジェクトの見積
今回は、見積について少し書いてみたいと思う。
プロジェクトの初期段階での見積もりの不確実性と、サイクリックな再見積もり（アジャイル系アプローチ等）の提案についてはいろいろな人が別に述べていると思うので割愛する。
プロジェクトの初期段階での見積もりの不確実性については、いくつかの要素があるのではと考えたので整理したい。なぜプロジェクトの初期段階で見積もりが不正確なのか？
もちろん前提として、プロジェクトの戦略目標は定まっているものとする。（定まっていないなら必ずプロジェクトは崩壊する）
※このへんのところは名著 失敗の本質―日本軍の組織論的研究
中公文庫
ISBN-10: 4122018331
を読んでほしい。
見積もりの不確実性の根本は、「決まっていないこと、わからないこと」の多さにあると思う。よってサイクリックな再見積もりによって不確実性をだんだんと減らしていく。
しかし最初の段階でも「決まっていること、わかること」は当然ある。そして「決まっていること、わかること」は、「決まっていないこと、わからないこと」より相対的に多いと考える。
８：２の法則から考えると８割ぐらいの要求は決まっていて、またプロジェクトコストに対する８：２の法則から考えると８割の決まっていることは、最終コストの２割で実現できるのでは？と考える。
じゃあ残りの２割の要求は？と考えるとそれは、レアケースに対する要求ではないか？
とするとプロジェクトの初期段階ではその決まっていることに焦点をあて見積もると、精度の高い見積もりが得られるのでは？と考える。そして初期段階で決まっていることことが、そのプロジェクトのコア機能であり、その時点で「決まっていなこと、わからないこと」は捨て置いて、計画してプロジェクトをスタートさせれば良いのでは？残りのレアな機能については、コア機能の完成後、おっつけ組み込むアプローチがあるのではないか？
最初にこれがアジャイル的進め方かなあと思ったが、ちょっと違うかもしれない。もう少し深堀して考える必要があると思う。
※「決まっていること、わかっていること」の数だけでいうと、８割よりずっと少ないかもしれない。無意識のうちにビジネスに対する重要性を掛け算しているのかな？書き直すのが面倒なので補足しておく。
プロジェクトの初期段階での見積もりの不確実性と、サイクリックな再見積もり（アジャイル系アプローチ等）の提案についてはいろいろな人が別に述べていると思うので割愛する。
プロジェクトの初期段階での見積もりの不確実性については、いくつかの要素があるのではと考えたので整理したい。なぜプロジェクトの初期段階で見積もりが不正確なのか？
もちろん前提として、プロジェクトの戦略目標は定まっているものとする。（定まっていないなら必ずプロジェクトは崩壊する）
※このへんのところは名著 失敗の本質―日本軍の組織論的研究
中公文庫
ISBN-10: 4122018331
を読んでほしい。
見積もりの不確実性の根本は、「決まっていないこと、わからないこと」の多さにあると思う。よってサイクリックな再見積もりによって不確実性をだんだんと減らしていく。
しかし最初の段階でも「決まっていること、わかること」は当然ある。そして「決まっていること、わかること」は、「決まっていないこと、わからないこと」より相対的に多いと考える。
８：２の法則から考えると８割ぐらいの要求は決まっていて、またプロジェクトコストに対する８：２の法則から考えると８割の決まっていることは、最終コストの２割で実現できるのでは？と考える。
じゃあ残りの２割の要求は？と考えるとそれは、レアケースに対する要求ではないか？
とするとプロジェクトの初期段階ではその決まっていることに焦点をあて見積もると、精度の高い見積もりが得られるのでは？と考える。そして初期段階で決まっていることことが、そのプロジェクトのコア機能であり、その時点で「決まっていなこと、わからないこと」は捨て置いて、計画してプロジェクトをスタートさせれば良いのでは？残りのレアな機能については、コア機能の完成後、おっつけ組み込むアプローチがあるのではないか？
最初にこれがアジャイル的進め方かなあと思ったが、ちょっと違うかもしれない。もう少し深堀して考える必要があると思う。
※「決まっていること、わかっていること」の数だけでいうと、８割よりずっと少ないかもしれない。無意識のうちにビジネスに対する重要性を掛け算しているのかな？書き直すのが面倒なので補足しておく。
2016年9月20日火曜日
IT開発プロジェクトと建築土木
もうIT関連の仕事に携わって２０年ぐらいになるが、関係したプロジェクトは成功も失敗もある。自分自身がPMとして失敗してしまったプロジェクトもあるし、さまざまな担当して担当タスクを失敗してしまったこともあるし、自分は失敗しなかったがプロジェクトとしては、失敗だったこともある。
ちなみに自分の中では、当初のシステムの目標に対し、期間、予算、機能（品質）が+30%の幅の中に収まることと考えている。（甘い見方かもしれないが）
ITプロジェクトを推進するにあたって、例えば「ビルを立てる」といった建築土木のプロジェクトの進め方との関連を意識したりしてきた。
ITプロジェクトと建築土木の考え方の間には類似点があると考えていた。
ちなみに自分の中では、当初のシステムの目標に対し、期間、予算、機能（品質）が+30%の幅の中に収まることと考えている。（甘い見方かもしれないが）
ITプロジェクトを推進するにあたって、例えば「ビルを立てる」といった建築土木のプロジェクトの進め方との関連を意識したりしてきた。
ITプロジェクトと建築土木の考え方の間には類似点があると考えていた。
- ものすごくざっくりというと作業工程が計画〜設計〜実装（建築土木ではなんと表現するのだろう）と工程の進み方が似ていると考えていた。※アジャイル開発においても基本これは変わらないと考えている。進め方の粒度の違いだけ。
- 何十〜何千という見知らぬ人間が集まって目標を完遂する。各工程でスペシャリストが集まり、ものを作り上げていく。釘を打つ人と壁紙を貼る人の間のコミュニケーションはどのようにとっていくのだろうとか。
- 予算、工期、品質の目標がある。
建築に失敗したビルというのは聞かないが、（実はあるのか？？）、失敗したITプロジェクトはごろごろある。なぜなんだろうと考えた結果、計画局面の決定ぐあいが違うのでは？と思い至った。大きなビルならモックアップをつくって検証すると聞いたことがある。また設計図など共通認識を持つための情報ツールがもう枯れた技術となっていて実装時に迷うことがないのでは？（記法なども統一されているだろうし、A社の設計図は、全然別のB社が完全に読み取れるはず）
とするとITプロジェクトにおいても
- 計画、設計局面において、できるだけ決定できることは細かく決定しておくこと。
- 決定したことの共通理解を関係者がもつこと。また理解のための共通言語（設計図に相当するもの）もつこと。
- 上記とも関係するが、共通理解のためのイメージ合わせのためプロトタイプを利用すること（モックアップに相当。プロトタイプの再利用など考えず使い捨てにしたほうが良いと思う）
実装より計画を！（アジャイル宣言に反している気がしますが。。）
に重点をおくと現状が改善されるように思った。通常のウォーターフォール開発では計画〜要件定義までに予算の２割も使えば多いほうだが、（計画には１割も使っていないのでは？）これを少なくとも３割程度までUPすると後半の手戻りも少なくより成功に近づくのではと考えた。
2016年9月15日木曜日
とあるプロジェクトの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 いろいろ資料作成（月曜日に向けて）
帰宅
テスト関連会議多すぎ〜 一番忙しい時はわすれました。
延々と会議と打ち合わせだったような気が。。
そんなにも忙しくない時
月曜日
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 いろいろ資料作成（月曜日に向けて）
帰宅
テスト関連会議多すぎ〜 一番忙しい時はわすれました。
延々と会議と打ち合わせだったような気が。。
2016年9月8日木曜日
あるプロジェクトで「チームメンバーがプロジェクトを達成不可能と信じていること」を深堀ってみる
とあるプロジェクトでチームのメンバーは、口々にプロジェクトを達成不可能といっていた。その理由大きくいうと以下の３つに集約されるのではないかと思う。
- 仕事量がものすごく多い。やってもやっても終わらない。
- 優秀な人とそうでない人の差が大きくフォローしきれない。
- プロジェクトとして現場レベルで決めたことを実際に現業をやっている部門に持っていくと簡単にひっくり返される。
1.について。自分のチームは要件定義を行うチームであった。要件としてはパワーポイント１ページに集約されることであっても、主管部門との調整、他の業務との整合性をとることに多くの時間を割かれた。日中の時間帯のほぼ７、８割が会議であった。必然的に自分の中で考えをまとめたり、資料を作ったりというのは残業時間で行うことしかできないことになった。コミュニケーションパスが多すぎて一つのことを決めるために小さなことから大きなことまで会議会議の連続であった。
2.について。優秀な人はまあいいとして、ソフトウェア開発プロジェクトには向き不向きがあると思う。向いている人というのは、
2.について。優秀な人はまあいいとして、ソフトウェア開発プロジェクトには向き不向きがあると思う。向いている人というのは、
- 積極的にコミュニケーションを取れる人。（単なる会話ではなく交渉能力、調整能力に長けた人）
- 論理立てて物事を考えられる人。（なぜそれをするのかを突き詰めて考えることができる人）
の2点のうちどちらかでもできる人でないと辛いのではと思う。人間性はすごくいい人なのだけれどもプロジェクトにおいてつらい毎日を送っている人が何人かいた。マネージャーは適性を見抜いて人を配置することがすごく重要だと思う。不向きの人がいた場合、３人いて３人分の仕事があるのに、２．５人分の仕事しかこなせない体制になっている場合がしばしばある。その場合優秀な人がフォローに回ることになる。
3.について。プロジェクトと主管部門との力関係で、決めたことが左右される。また長期にわたるプロジェクトの場合、主管部門の担当者の異動があったりすると方針が１８０度がらっと変わったりもする。それは担当者レベルでもマネージャーレベルでもあった。
上記のことが重なり合い、毎日のように起こっているとチームメンバーの士気はさがっていく。決めるべきことがいつまでたっても決まらない。度々の方向転換があり、右往左往する。仕事時間は増える。
なので「このプロジェクトの目標は達成不可能」と思い込むとなる。
2016年9月7日水曜日
プロジェクト開発に関する見積について過去の振り返り
IT開発プロジェクトにおける規模見積について考えてみた。
IPA情報処理推進機構によると、見積の要素としては、以下の要素が挙げられている。
"
規模
ファンクションポイント
コード行数
機能数、画面数、テーブル数
その他見積りに影響を与えるもの（工数の変動要因）
プラットフォーム/環境
ハードウェア、オペレーティングシステム
言語、ツール、ユーティリティ
開発環境
プロダクト
アプリケーション種別
複雑度、要求される信頼性
ライフサイクル
人材
能力と経験
総労働時間
"
見積は当初の計画時からどんどん増える方向に乖離していくものである。（残念ながら少なくなる方向に乖離していくことは経験したことがない。そういう事例はあるのだろうか？）多くの場合、計画（提案）時には、上記の要素の大部分はわからないことが多い。そこで、経験者、あるいはひどい場合は開発未経験の営業さんがエィっとドンブリ勘定で出すことが多い。さらには、「予算はこれぐらいと決まっているから。この範囲内でよろしく！」とどんなことをするのかも決まっていないのに型にはめられてしまうこともある。
自分が経験した中で一番優れた見積は、ある中規模SIベンダーさんで、上記のような要素を入力すると自動的にブレ幅も示した上で、開発規模を算出してくれるツールをもっていた。しかも過去の多数のプロジェクトの実績を加味しながら、そのツールは常に進化し続けていて、かなり精度の高い見積を出すことができたことがある。またそのプロジェクト独自の要素（今までに使ったことのない言語であるとか）も加味することができて非常に良くできたツールであった。
大規模SIベンダーさんであれば、過去事例も山ほどあるはずとおもうがそういったツールは、後にも先にも１度しか経験していない。（過去事例の要素を洗い出してみて、実績と突き合わせて分析すればかなり精度の高い見積が出せそうと思うのだけれども）
仮説に仮説を重ねて何らかの数字を出していってもほとんど意味のない数字になってしまう。が要件定義の具体的な個別タスクの工数の積算などそんなことをよくやった記憶がある。
成果物に対しての作業工数が測りにくい作業に対しては、作業の積み上げによる積算よりも、全体から俯瞰して算出したほうが良いような気がする。「考える」作業に対しての見積は一筋縄ではいかない。最終的には１ページの要件定義書であっても、それを作り上げる過程ではたくさんの会議があって、うんうんうなりながら考える時間がある。また会議で説得するための資料作りなどの作業もあまり目には見えない。なので細かい作業の一つ一つを洗い出して積み上げると、とんでもない工数となる。（それぐらいかかるのが現実に近いのだけれども）
大体のプロジェクトにおいては、もう「やりたいこと」がほとんど決まっていることが、前提になっている気がする。しかし実態は「やりたいことがわからない」ほうが多いと思う。「古いシステムと同じで！」というのも「やりたいことがわからない」に等しいと思っている。そういった場合には、要件定義の工数は際限なくかかっていく。そしてデスマーチへとつながっていく。
2016年9月5日月曜日
別のプロジェクトも健全度具合をチェックしてみた（過去のプロジェクト振り返りその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点未満は危険と言及している。引用すると、
"
この範囲の得点しか獲得できなかったプロジェクトは、要求、計画立案、プロジェクトのコントロール、リスクマネジメント、人的資源という主要な領域において重大な弱点を持っている。このレベルのプロジェクトにとって最大の懸念は、そもそもプロジェクトそのものを完了できるかどうかということである。
"
実際にはまだこのプロジェクトは、現在進行形である。（自分はプロジェクトを離れてしまったが）現在のところ重大な問題を抱えていることがわかる。
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倍に膨れ上がった。またサービス提供後の運用にも大変な苦労をしていると伝え聞く。
個人的には、当初の計画の予算、期間、品質を守って（当然ある程度のブレ幅は許容するとして）成功と考える。このプロジェクトの場合、予算、品質は失敗プロジェクトと言えるのかもしれない。
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倍に膨れ上がった。またサービス提供後の運用にも大変な苦労をしていると伝え聞く。
個人的には、当初の計画の予算、期間、品質を守って（当然ある程度のブレ幅は許容するとして）成功と考える。このプロジェクトの場合、予算、品質は失敗プロジェクトと言えるのかもしれない。
2016年8月31日水曜日
ITプロジェクトにおけるリスクマネジメントと人的資源の充足について（過去のプロジェクト振り返りその8）
今回はリスクマネージメント、および人的資源について述べる。
これでソフトウェアプロジェクトサバイバルガイドの一通りの設問の要点を述べたことになる。
"
リスクマネジメント
25.プロジェクト計画案には、プロジェクトが現在抱えているリスクの一覧を明示した資料が含まれているか、その一覧は最近更新されたか。
"
プロジェクトの初期段階でリスクを見通した一覧が作成されることはまずない。（日本人の特性なのか？）希望に満ち溢れたプロジェクトの初期段階でリスクを列挙し管理していくことは、はばかられるのではないかと考えている。
"
26.プロジェクトの管理責任者がいるか。その責任者は、プロジェクトに発生しているリスクを発見して特定する責任を持つ。
"
25.とも関連するが、大規模プロジェクトにおいてリスクを洗い出すことは通常ある。しかし洗い出すのは担当者レベルであり、客観的にリスクを評価し対策を考える管理責任者を置くことは稀である。よってプロジェクト全体にかかわるリスクは放置されがちとなる。
"
人的資源
30.そのプロジェクトを成功に導ける指導力を持った技術リーダーがいるか。
"
ITプロジェクトにおいて大切な要素の一つは、全体を一貫した技術的考え方（アーキテクチャ）で統一し、その考え方に沿って以降の工程を進めていくことにあると考えている。しかしながら、営業が提案するBUZZワードがアーキテクチャであると勘違いされ、それを深める技術リーダーが置かれることは少ない。よって工程が進むにつれ、当初の技術的考え方は忘れ去られ、（または最初から全くないか）各サブチームはばらばらの方向に進むことが多い。
以上でソフトウェアプロジェクトサバイバルガイドのチェックリストのうち個人的に重要だと思われるものを抜粋し説明をすることは終えた。次回以降は、実際に自分が関わった２つの大規模プロジェクトをチェックしてみたい。
これでソフトウェアプロジェクトサバイバルガイドの一通りの設問の要点を述べたことになる。
"
リスクマネジメント
25.プロジェクト計画案には、プロジェクトが現在抱えているリスクの一覧を明示した資料が含まれているか、その一覧は最近更新されたか。
"
プロジェクトの初期段階でリスクを見通した一覧が作成されることはまずない。（日本人の特性なのか？）希望に満ち溢れたプロジェクトの初期段階でリスクを列挙し管理していくことは、はばかられるのではないかと考えている。
"
26.プロジェクトの管理責任者がいるか。その責任者は、プロジェクトに発生しているリスクを発見して特定する責任を持つ。
"
25.とも関連するが、大規模プロジェクトにおいてリスクを洗い出すことは通常ある。しかし洗い出すのは担当者レベルであり、客観的にリスクを評価し対策を考える管理責任者を置くことは稀である。よってプロジェクト全体にかかわるリスクは放置されがちとなる。
"
人的資源
30.そのプロジェクトを成功に導ける指導力を持った技術リーダーがいるか。
"
ITプロジェクトにおいて大切な要素の一つは、全体を一貫した技術的考え方（アーキテクチャ）で統一し、その考え方に沿って以降の工程を進めていくことにあると考えている。しかしながら、営業が提案するBUZZワードがアーキテクチャであると勘違いされ、それを深める技術リーダーが置かれることは少ない。よって工程が進むにつれ、当初の技術的考え方は忘れ去られ、（または最初から全くないか）各サブチームはばらばらの方向に進むことが多い。
以上でソフトウェアプロジェクトサバイバルガイドのチェックリストのうち個人的に重要だと思われるものを抜粋し説明をすることは終えた。次回以降は、実際に自分が関わった２つの大規模プロジェクトをチェックしてみたい。
2016年8月30日火曜日
大企業の基幹システム開発における進め方のポイント
大企業の基幹システム開発における開発方法論（は関係ない？）
を書いたので、どのように進めればよいか考えてみる。
個人の力では個々人の意識改善、組織のあり方を変えるのは、ほぼ不可能ではあるが、理想がなくてはギャップも埋められないので、理想であることを意識して書いてみる。
個々のプロジェクトの性質に依存する事項ではなく組織の（および個人）のあり方について書いてみる。
では、まずネタとしてCIAの前身であるOffice of Strategic Servicesの作ったスパイに命ずる相手組織の撹乱作戦（Simple Sabotage Field Manual ）の内訳を簡単に書く。（実際に第二次大戦時の機密文書として存在し近年公開されたらしい）
・何をするにも「指揮系統」を主張し、意志決定を早めるためのいかなる抜け道も認めないようにせよ
・可能な限り物事は委員会で決定せよ。委員会は決して５人以下にしてはならない。
・できる限り本質的でない議題を持ち出せ。
・業務の承認手続きを複雑にせよ、どんなことでも３人以上の承認を得るようにせよ。
つまりこの逆張りをすればいいことになる。
を書いたので、どのように進めればよいか考えてみる。
個人の力では個々人の意識改善、組織のあり方を変えるのは、ほぼ不可能ではあるが、理想がなくてはギャップも埋められないので、理想であることを意識して書いてみる。
個々のプロジェクトの性質に依存する事項ではなく組織の（および個人）のあり方について書いてみる。
では、まずネタとしてCIAの前身であるOffice of Strategic Servicesの作ったスパイに命ずる相手組織の撹乱作戦（Simple Sabotage Field Manual ）の内訳を簡単に書く。（実際に第二次大戦時の機密文書として存在し近年公開されたらしい）
・何をするにも「指揮系統」を主張し、意志決定を早めるためのいかなる抜け道も認めないようにせよ
・可能な限り物事は委員会で決定せよ。委員会は決して５人以下にしてはならない。
・できる限り本質的でない議題を持ち出せ。
・業務の承認手続きを複雑にせよ、どんなことでも３人以上の承認を得るようにせよ。
・ペーパーワークを増やせ。
・さほど重要でない仕事でも完璧さを求めよ。
・内容よりも手続きを重視せよ。
・やるべき重要な仕事をさておき会議を行え。
つまりこの逆張りをすればいいことになる。
- 組織のフラット化。
- 管理組織をコンパクトにする。
- 会議の数を最小にする。
- （正確さよりも）迅速な意思決定。
あと第二次大戦の時になかったのはITインフラであるが、使わない誰も見ない情報をITシステムに入力することを要求するということがよくある。そしてその情報の集計などの再加工させ報告を求められることがある。ペーパーワークを増やすことにも通ずるが報告書のなんと多いこと、またどんな状況報告であっても聞いて終わり、一緒に対応策を考えることはしない。
よって
- 情報は、必要な人がITシステムから「自分で」取り出して加工して分析すればよい。
- 報告を求め、問題点がある場合は一緒に考える。
も加えたい。
これらを心がけるだけで、プロジェクト開発はかなり円滑に進み、いたずらに巨大化しないのではないだろうか？
登録:
投稿 (Atom)