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

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

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

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

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

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

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

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

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

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

ITプロジェクトにおけるリスクマネジメントと人的資源の充足について（過去のプロジェクト振り返りその8）

今回はリスクマネージメント、および人的資源について述べる。
これでソフトウェアプロジェクトサバイバルガイドの一通りの設問の要点を述べたことになる。

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

プロジェクトの初期段階でリスクを見通した一覧が作成されることはまずない。（日本人の特性なのか？）希望に満ち溢れたプロジェクトの初期段階でリスクを列挙し管理していくことは、はばかられるのではないかと考えている。

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

25.とも関連するが、大規模プロジェクトにおいてリスクを洗い出すことは通常ある。しかし洗い出すのは担当者レベルであり、客観的にリスクを評価し対策を考える管理責任者を置くことは稀である。よってプロジェクト全体にかかわるリスクは放置されがちとなる。

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

ITプロジェクトにおいて大切な要素の一つは、全体を一貫した技術的考え方（アーキテクチャ）で統一し、その考え方に沿って以降の工程を進めていくことにあると考えている。しかしながら、営業が提案するBUZZワードがアーキテクチャであると勘違いされ、それを深める技術リーダーが置かれることは少ない。よって工程が進むにつれ、当初の技術的考え方は忘れ去られ、（または最初から全くないか）各サブチームはばらばらの方向に進むことが多い。

以上でソフトウェアプロジェクトサバイバルガイドのチェックリストのうち個人的に重要だと思われるものを抜粋し説明をすることは終えた。次回以降は、実際に自分が関わった２つの大規模プロジェクトをチェックしてみたい。

ITプロジェクトのコントロールや運用（過去のプロジェクト振り返りその7）

今回は、プロジェクトのコントロール（するための組織や運用）について述べる。

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

巨大プロジェクトにおいて役員が最高責任者となっていない場合は、少ない。しかしながら方向性や自身の意思を示すことは少なく、実質的には下から上がってきた方針を追認するするだけの場合は多い。神輿としての役員は置かれるが、意思決定の役目を果たすだけの見識を持つ役員は少ない。

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

プロジェクトの要所要所にチェックポイントが設けられることは多いが、上記のように明確なマイルストーンが置かれることもやはり少ない。また２択ではなく、３択（◯×△とか）が多い。チェックポイントも「XXの計画書が作成されていること」などと、中身は問われない。問題がある場合も「改善点はあるものの概ねOK」として△でお茶を濁す。そして最後の最後で大爆発する。

二者択一の明確なチェックポイントリストを一度見てみたい。。
（かなり細かく作りこむのかな？）

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

この制度が設けられているプロジェクトは残念ながら見たことがない。いわゆる「目安箱」制度だが、より現場の状況を把握するために良い仕組みと思う。過去一度だけ似たような制度が設けられようとしたが、組織階層外からの報告は良しとされず、結局お流れになった。

ITプロジェクトにおける計画立案（アーキテクチャとリソース計画）について（過去のプロジェクト振り返りその6）

今回は、計画立案の設問について述べる。

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

アーキテクチャをプロジェクト全体として共有することは重要である。しかし計画段階でそれを設定することができるプロジェクトは多くない。また実現可能性の高いアーキテクチャ（本を丸写ししたようなアーキテクチャではなく）を設計できる人も少ない。


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

20年前ならいざ知らず、近年は人的リソースについては、上記のことを考慮して計画することが多い。しかしながらそもそも「計画時におけるプロジェクト規模の見積もりの難しさ」という問題があり、余裕をもってリソース計画を立てたつもりであっても、結局工程が進むにつれリソースを食いつぶしてしまうことが多い。計画と実際の規模の間に借りが大きい場合は、そのプロジェクトはデスマーチとなる。

ITプロジェクトにおけるプロジェクトビジョンとビジネス要求について（過去のプロジェクト振り返りその5）

第２章のソフトウェアサバイバルテストにおいては、具体的な設問に答えていき、採点をしてプロジェクトの成熟度を図るようになっている。自分の経験したプロジェクトを採点するのは、「その12」ぐらいを予定している。

ここではテストの設問を引用しながら、内容について述べていきたい。

”
要求
1.明確なビジョンステートメントまたはミッションステートメントがプロジェクトで制定されているか。
”
これまで述べた通り、この設問に「はい」と答えられるプロジェクトは少ない。単にシステムが古くなり関連ソフトウェア、ハードウェアのサポート切れという場合も多いのではないかと思う。

"
2.すべてのチームメンバーが、ビジョンを達成可能であると信じているか？
"

１番目の設問とも関連するが、この質問に明確に「はい」と答えられる人も少ないはずだ。明確に決まってないからだ。「いいえ」または「しらない」という答えが多いのではないかと思う。
また日本人の特性かもしれないが、表向きは「はい」答える人も多いのではと思う。かっこいい錦の御旗に逆らえる人はそうはいないからだ。大本営に逆らえる人はそうはいない。実現可能なビジョンを考えるという点が、できているプロジェクトにはなかなか出会えない。外国のプロジェクトではどうなんだろうか？実現可能なビジョンがとてつもなく難しいように思える。

"
3.事業における便益を詳細に示し、メリットの測定方法を明らかにするビジネスケースを策定しているか。
"

これもこれまで述べてきた通り設定できているケースは少ない。

ITプロジェクトにおいて目標設定が軽視されることについて（過去のプロジェクト振り返りその4）

前回は、目標設定の重要性について述べた。
振り返ってみると、過去自分は10以上のプロジェクトに関わってきたが、目標が明確に設定されているプロジェクトはなかった。（目標を窺い知ることのできないほどの末端担当者の場合もあったが、それでも末端担当者でも目標を胸に刻んでプロジェクトを推進できるようにするべきと思う。）
直近のプロジェクトでは、当初目標設定がなされていたが、やはり時間とともに忘れ去られていったように思う。または、頭の片隅に目標はあったが、達成できないことがわかってしまってきたため、口に出すのがはばかられるようになってきてしまっているのかもしれない。

企業におけるシステムの導入、または刷新の効果は、結局のところお金に換算できる。（システムを積極的に止める（撤廃する）という事例は聞いたことがない。対象事業そのものが無くなるためシステムが必要なくなったという例は聞いたことがあるが）

XX費用の削減、XXの収益の増大、利便性の向上や作業の効率化という目標も結局のところ費用削減につながっていく（具体的金額目標を設定しない場合も多いが）

かつて、官公庁で業務・システム最適化計画というIT戦略目標策定のプロジェクトに携わったが、システムをいくら効率化しても部門単位で見れば要員の削減にはなるかもしれないが、公務員をクビにできるはずもなく、虚しさを感じた覚えがある。

目標は「金！」というのは、企業にとって至極あたりまえだが、「使って楽しい」システムも目標にできればと思う。AIに仕事を奪われると戦々恐々とするのではなくて、ともに素晴らしいサービスを提供できるような世界になればと思う。

まだ続く。。

ITプロジェクトにおいての顧客とプロジェクトチームの関係と成功の為の目標設定（過去のプロジェクト振り返りその3）

プロジェクト計画について引き続き書いてみます。

プロジェクトの立ち上げ時において、プロジェクトサバイバルガイドには

”顧客の権利章典

顧客は次の権利を持つものとする。

1.プロジェクトの目標を設定し、その目標に従ってプロジェクトを進めさせる。

一方

"プロジェクトチームの権利章典

プロジェクトチームは次の権利を持つものとする。

1.プロジェクトの目標を把握し、優先事項を明確にする。

と顧客側とプロジェクトチームを対にして述べ目標設定の重要性を説いています。

しかし自分が関わったプロジェクトは多くの場合、目標は曖昧で、かつプロジェクトの進行とともに目標は忘れ去られ、プロジェクトが終わること（プロダクトの完成）が目的になっていきます。

プロジェクトの目標設定は顧客側の責任ではありますが、「具体的」目標値とその計測方法はプロジェクトチームも共に考え決めていくべきと考えます。例えばシステムの導入によりXX億円の営業利益の増収とか。そして本当にそうなるかの検証も合わせて行わなければならないと思います。

例　コールセンター　プロジェクト予算1億円　期間１年　機能追加により応答率が30%向上する。これにより人件費が20%削減よってシステム導入後３年間で費用を回収し、その後は会社に利益をもたらす。　とか。

例としてはものすごく簡単に書きましたがこれを、決め、予測し、計測することは非常に難しい。プロジェクトは、常に変化し当初の予測値とずれていくため、例えば途中で予算が1.2億になり、期間が15ヶ月になった時には、本来目標も修正していかなければなりません。

続く。。

ITプロジェクトの成功率（過去のプロジェクト振り返りその2）

第1章の冒頭に以下のように書かれている。

/*
ソフトウェアプロジェクトが完了段階まで存続できる確率は、多くの場合、低い。
*/

Yes!そのとおり、プロジェクトの完了をどう定義するかによってその確率は変わってくるが、自分はプロジェクトの開始当初の予算、期間、効果（期待されている機能、それにともなう事業目標）が+-30%の誤差で達成できれば完了（成功）と考える。

※1 予算と期間については、マイナスの誤差は、経験したことがない。また効果についてもプラスの誤差は経験したことがない。この経験を覆す事例を知りたい。（雑誌取材とかに話している効果は大体盛ってますからね。）

※2 本の中では+-10%で成功と書かれていますが、そんな難しいこと無理ですと言いたい。これも事例があったら知りたい。

/*
しかし、この確率の低さは必然ではない。ソフトウェアプロジェクトを完了させるための第1歩は、プロジェクトを正しい手順を踏んで開始することにある。きちんとした形で開始できれば、単に完了できるという以上の単に完了できるという以上のメリットが得られる
*/

これもYes!そのとおり、プロジェクトの困難さの大部分は開始時にあると考える。開始時の条件が間違っていると以降の工程でいくら努力改善しようとも、そのプロジェクトは、よれていく、最後には何のためにプロジェクトを推進しているのかわからない状態に陥る。（責任を取りたくない人がいる。間違いを道めたくない人がいる。そしてなんとプロジェクトが混乱した方が儲かる人がいる。）

※ここにビジネスチャンスがあると自分は考える。具体的には、別途述べる。

ソフトウェアプロジェクトサバイバルガイドというITプロジェクトにおけるバイブル（過去のプロジェクト振り返りその1）

これまでの仕事を振り返るにあたって、なんの軸もなしに書いてしまった場合、ただの愚痴の垂れ流しになるので、
我がバイブルであるスティーブ マコネル著作「新訳ソフトウエアプロジェクトサバイバルガイド」にそって過去を振り返っていきたいと思います。

章立ては以下のとおり

出展　著者Steve McConnell　「新訳　ソフトウェアプロジェクトサバイバルガイド」
ISBN4−89100−476−2

"
第１部サバイバルの心得
ソフトウェアサバイバルテスト
サバイバルの概念
サバイバルのためのスキル
成功するプロジェクトの条件
第２部サバイバルの準備
変化する目標への対応
暫定計画
要求開発
品質保証
アーキテクチャ設計
最終準備
第３部ステージ別納品の効用
ステージ開始時の計画
詳細設計
構築
システムテスト
ソフトウェアのリリース
ステージ完了時の確認事項
第４部プロジェクト終結後の作業
プロジェクト履歴
サバイバルメモ
"

プロジェクトの始まりから終わりまでのプロセスのチェック項目が網羅されています。
この軸にそって、ポイントを引用しながら、自分が経験したプロジェクトで過去何が問題だったか、どうすればよかったを振り返っていきたいと思います。

※2016/7/14　追記　著作権との関連でblogで引用する場合のルールを調べた。
基本的なルールは以下のとおり

1. 出典を明確にすること。
2. 引用する必然性があること。（長々と引用して、一言これってすごいですよね！というのはアウト。自分の考えを述べるために引用する。）
3. 自分の著述部分との主従関係（あくまでも自分の著述が主）
4. 引用部分を明示すること。

よって出典と引用部分を明確するようにした。

疑問点：blogは公開日記帳みたいなものであるため、必然性と主従関係をどう見るかが難しいように思う。日々積み重ねたblog全体としての必然性、主従関係と見るか、ある日の1postだけで必然性と主従関係を見るか？前者と考えるがどうか？