とあるプロジェクトの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倍に膨れ上がった。またサービス提供後の運用にも大変な苦労をしていると伝え聞く。
個人的には、当初の計画の予算、期間、品質を守って（当然ある程度のブレ幅は許容するとして）成功と考える。このプロジェクトの場合、予算、品質は失敗プロジェクトと言えるのかもしれない。

DevOpsについて勉強した。

DevOpsといえば高速な開発と本番環境へのプロダクトの投入と思い込んでいた。まちがっていないが、もっと広く深い概念と理解した。

2016年現在確立した定義はないが、自分の理解を列挙してみる。

1. Dev（開発）とOps（運用）の協力体制をより密にすること。
2. これまでは、開発の立場としては、開発したプロダクトをより早く本番環境に載せたい。
3. 一方運用側は、安定稼働を望むため変化を好まない。
4. そのような利害関係があるので、企業体として求められる「早くサービスを提供すること」に対応しきれない部分があった。※上記の書き方だと運用側が抵抗勢力のように読めてしまうが、低品質のプロダクトをもってくる開発側にも問題がある。あと本番環境と開発環境の差異などで障害は発生しがちである。なのでコンテナ技術が発達してきたのかな？
5. そのための考え方がDevOpsという言葉に集約される。
6. より密に協力していこうという考え方の背景は、ITをコストカットのためのツールとしてではなく、ITを使って競争に打ち勝つという考え方がある。そのためより便利で安定性のあるソフトウエアプロダクトが求められている。
7. また協力の考え方だけでなく、それを実現するためのツール群も近年現れてきた。
• ツール群によるプロダクト開発（と投入）のレベルに段階があるので少し解説する。さっき覚えた（笑
1. 第1段階　バージョン管理（本番のソースコードと開発中のソースコードの差異管理。）
2. 第2段階　継続的インテグレーション（テストとOKであれば開発系ソースコードへのコミットの自動化）
3. 第3段階　継続的デプロイ（第２段階の結果、問題がなければプロダクトのビルドと本番環境への適用の自動化）
4. 第4段階　継続的デリバリ（本番環境へのデプロイタイミングをビジネス要求に沿って決定する。※第3段階までくるといつでも本番環境にプロダクトを投入できる状態になる）
• 上記の段階を実現するための便利なツール群が近年登場してきた。
8. 欧米ではここ7,8年前ぐらいからこの考え方はあって、日本では自分の見聞きする限りせいぜい第2段階どまり。（スマホゲームだと第4段階まで行っていないとだめだろうけども、毎日のように何かイベントがあるから）

一番重要なのは6.の考え方だと思う、その方法としてDevOpsという考え方が生まれてきたのだと考える。