過去のプロジェクトから得た暗黙知を、次のプロジェクトに活かす

ＩＣＴプロジェクトでは、いろいろな意味で　成功／失敗　の評価がされます。
システム企画フェーズまで捉えた場合、その目的・目標の達成度で評価されることになります。
また、構築フェーズのみで捉えた場合、一般的にはＱＣＤで評価されることが多いと思います。

その立場・役割によって、評価指標は異なると思いますが、
プロジェクトの終結時または終結後には、その評価を実施しておくべきと考えられます。
それは、さまざまな図書・雑誌などで記載されているとおりであると、私は認識しています。


しかし、
・正しく客観的に評価をしたり、
・その評価を次のプロジェクトに活かす、
ということは、意外にできていない場合が多いのではないか、とも感じています。


例えば、
成功と評価されるプロジェクトにおいては、その成功要因について、また、更に改善すべき点について、
失敗と評価されるプロジェクトにおいては、外部要因（例：外部環境やお客様の方針変更）ではなく、自社でコントロールできる内部的なプロセス面などの要因について、
などの分析と活用が不十分な場合も多いように感じます。


そもそも成功プロジェクトは、その満足感のために、十分に振り返りがなされない場合もあると思います。
十分に分析された成功要因は、次のプロジェクトに必ず活かすことができます。

また失敗プロジェクトについては、メンバーの気持ちの面などで、本質的な分析が難しい場合があります。
外部のみに責任や原因を感じ過ぎたり、また逆に自分自身に責任や原因を感じ過ぎたりして、十分な分析ができない場合もあると、私は認識しいています。


よって、少し時間をおいてから、成功／失敗要因を利用する方法も効果的なように、私は感じています。

例えば、類似プロジェクト、同一顧客のプロジェクトを立ち上げる際、
参考となるプロジェクトの教訓を把握しつつ、それらに参加したメンバーを交えたミーティングを実施することが効果的な方法の一つです。

終結時に思っていた成功要因／失敗要因も、時間が経過し、且つ他のプロジェクトを経験する過程などが影響し、少し見方や評価等が変わる場合があります。
また、そもそも文書化する過程で抽象化され過ぎたり、また文書化し辛い背景情報等もあるかもしれません。

それらは、当該プロジェクトの教訓としては明文化されていないものですが、たいへん貴重です。
その貴重な「暗黙知」的な成功要因／失敗要因を、新たなプロジェクトの計画にインプットして「形式知」として取り扱う、
私は、それがプロジェクトの教訓を活かす有効な方法の一つのように思っています。

成功が見通せるプロジェクト計画を策定する

あるプロジェクトが無事、終了しました。
システムのＱＣＤは問題なく、そして上位のビジネス目的へ予定どおり貢献できるという手ごたえを感じています。
やや小さめのプロジェクトだったのですが、他システム連携があり、難易度は比較的高いものでした。

さて、失敗プロジェクトは７割などと言われますが（近年は改善しているようですが）、実際に私も大きな失敗をしたことがあります。

失敗する場合と成功する場合について、私は次の３点が大きく異なっていると感じています。


1.上流工程の品質が良いこと。

2.プロジェクト計画を策定した結果、「成功する」という感触が得られること。

3.プロジェクト実行中、プロジェクト関係者（顧客、メンバー、ベンダーなど）とのコミュニケーションが十分なこと。


特に、2.は重要だと感じています。

いろいろな制約事項がありますが、その中で、何とかして「成功が見通せる」計画を策定する必要があります。
リスクへの対処計画を含めて、「これはイケるぞ！」という感触を得ておきたいものです。


当然のことと思われるかもしれませんが、プロジェクトリーダーは、満足がいく条件が得られず、最終的に失敗することは何としても避けなくてはなりません。
例えば「だから●●●●のスキル者をプロジェクトに入れるべきだったのに。。。」などど、計画段階の要求が通らなかったことに失敗の原因と責任を求めてはいけないと、私は思っています。

プロジェクトリーダーの仕事は、プロジェクト計画を立てる段階から既にスタートしています。
よって、「成功が見通せる」計画を立てる責任は、プロジェクトリーダーにあります。


＜関連記事＞
　プロジェクト計画とプロジェクト運営ルール
　チームワークを高める
　システム構築は顧客との協働作業

　超上流工程からシステム運用テストまでにおける考慮事項

プロマネ義務

『日経コンピュータ　№815　2012.8.16』の特集『「プロマネ義務」って何だ！』において、
スルガ銀行とＩＢＭの裁判にて、東京地裁が日本ＩＢＭへの損害賠償の根拠とした「ＰＭ義務」、
そして、それとの対照となる「協力義務」についての考察が書かれていました。

この記事のおかげで、同裁判の争点と判決の根拠等が理解しやすくなりました。


今まで、ＩＣＴベンダーにおいて、そして経済産業省の『モデル取引契約』などにおいては、
発注企業とＩＣＴベンダーとの間の責任を明確化すること、フェーズごとの分割契約と準委任と請負の選択などについて、
いろいろ提案され、ＩＣＴ業界内では好意を持たれていたと、私は認識しています。

特に、発注企業側の責任、そしてその責任を果たすことがプロジェクトの成功要因であるような記載などがされており、
私は、その内容は理解できると思いつつも、どこか（発注企業側ではなく）ＩＣＴ業界寄り、または能力の高い情報システム部門が存在する組織を中心とした考え方であるように感じていました。

よって、私がご支援する（情報システム部門が存在しないか専任者がわずかな）中堅・中小企業においては、
それらの考え方をそのまま適用することは馴染まないと判断し、その判断をベースにいろいろご支援してきました。


今回の判決により、単純に考えますと、フェーズごとの分割契約にすること、上流工程など発注企業との「協働」が不可欠であるフェーズを準委任契約にすることなどは、ＩＣＴベンダー側のリスク軽減にならない可能性がある、という状況になったと私は捉えています。

また（少し乱暴な表現ですが）、「プロジェクトの成功要因は上流工程・超上流工程の出来栄え次第であり、そのフェーズの主体は発注企業側であり、よって、プロジェクトの成功は発注企業に大きく依存する」というＩＣＴベンダー側の主張も通りづらくなったと考えられます。


以上のように、全体的に風向きが変わる可能性が高いと、私は考えています。


しかし、今回の判決においては、契約書で明記されていない、『ＰＭ責任』というものの概念と範囲を主な根拠としているようであり、
私はこれについては危険な考え方のようも感じています。

日経コンピュータの『「プロマネ義務」って何だ！』では、その『ＰＭ責任』の根拠を、契約書ではなく『民法の基本原則である信義則（信義誠実の原則）だろう』という推測を紹介しています。
それはある程度、納得できる解釈であり、理解できるのですが、
プロジェクト失敗の原因を「信義則」違反であると主張し、契約書に明記されている以上の損害賠償請求をされる可能性が生じるため、ＩＣＴベンダーの防衛意識が働き過ぎないか、私はとても心配です。


一方、今回の判決に関して、基本契約書の性質が争点になるものと、以前はいろいろ推測されていました。
これが請負か？準委任か？ということだったのですが、

この判決からの私の解釈、推測としては、

基本契約書を締結して、（個別契約にはなるが）要件定義からリリースまでの一定の役割を担うＩＣＴベンダーであることを合意した場合には、要件定義からリリースまでにおける『ＰＭ責任』が、ＩＣＴベンダー側に自然発生すると捉える方が良いと考えられます。

その契約の性質が「請負」であれば、もちろん完成責任を負いますし、
また「準委任」であった場合でも（過去の記事でも記載しましたが）、専門家としての注意義務責任は重く、
よって、専門家としてプロジェクトを成功に導く活動を行う重い責任があるものと、私は解釈しています。

他方の発注企業には、ＩＣＴベンダーに大きな『ＰＭ責任』を担わせるのであれば、それに応じた正当な対価を約束するとともに、
『ＰＭ責任』と対となる、または一体の関係である『協力義務』を果たしていただく必要があるでしょう。

前向きにとらえれば、（外部コンサルタントを含め）誰が『ＰＭ責任』のどの範囲まで担うのか、、それと対となる『協力義務』の具体的な内容などが明確化できれば、
プロジェクトの失敗要因の一つは解消されるものと考えられます。


＜関連記事＞
　準委任契約の特性について考える
　準委任契約の特性のついて考える（その２）
　準委任契約の特性について考える（その３）
　準委任契約の特性について考える（その４）

　システム構築は顧客との協働作業

　超上流工程からシステム運用テストまでにおける考慮事項

システム構築は顧客との「協働」作業（その2）

以前の記事　『システム構築は顧客との「協働」作業』　で、

「顧客との相互理解を大切する姿勢を一貫して通すことで、顧客側にもそのことが自然と伝わり、それが良い方向に作用することで、システム構築プロジェクトが「協働」作業の場となり、結果としてプロジェクト成功につながっていくものと、私は信じています。」

というコメントを記載しました。


最近、システムの不具合等が原因での問題・トラブル対応において、そのこと等をあらためて再認識しました。


システムや仕様の不具合が原因と言っても、更に原因を分析した場合、さまざまなことが複合したことで問題が生じた、という場合も多々あります。

例えば、仕様上で考慮されていなかった事項と運用ミスが重なった場合などであり、
さらに、仕様上で考慮されていなかった利用が、その例外処理があることを関係者が認識できていなかったりとか、
また運用ミスは、画面のわかり辛さが影響していたりとか、

また、システムの品質が悪く、リリース予定日に間に合わない状況になったが、その理由は、お客様からの直前の仕様変更の要求によるものであったりとか、
さらに、その仕様変更を最終的に構築ベンダーが公式に合意したのかどうかが曖昧であったりとか、

繰り返しですが、さまざまなことが起因している場合も多々あります。


それら一つ一つを見ていくと、構築ベンダーに責任があること、お客様に責任があること、それらが曖昧であることなど、さまざまです。


しかし、お客様と構築ベンダーが、ほぼ全てにおいて相手方に原因・責任があるという思考になってしまう場合があります。

その場合、お互いに自分を「防衛」すること等がやり取りの目的になってしまって、中途半端な解決策になって二次的な問題が発生したり、また、お互いの不信感を高めてしまうなど、良いことは一つもありません。


問題・トラブルによる損害の大きさにもよりますが、

問題・トラブルへの対応時においても、「協働」の姿勢で解決にあたることが望ましいと、私は考えています。

「構築ベンダーとしての対処はここまでで良い」と単独で判断したり、また「当然、すべて構築ベンダー側で対処すべき」と一方的な考えを持つのではなく、

まずは解決のための必要な作業全般を洗い出し、
それは誰がどのように実施すべきか、
問題・トラブルの原因や構築契約、保守サポート契約内容との兼ね合いで、構築ベンダーへの支払いは必要かどうか等を、
お客様と構築ベンダーとの間で、「協働」の意識をもって決定していくようにしたいものです。

その際、支払い有無や金額について保留になる事項もあるかもしれません。
しかし、それはトラブルが無事に解決した後に話し合えば、自然と正しい決定が成されるものと、私は信じています。


まず問題・トラブルは発生させないようにマネジメントすること、
またプロジェクのスコープや役割分担、保守サポートの内容や役割分担などを明確にしておくこと等は当然なのですが、

トラブル発生で相手が怒ったり、また一線を引いた態度でいる中、
冷静な言動で相手の協力を引き出しつつ、相手作業への支援内容を提示すること等で解決を図ろうとする、
責任感ある担当者の態度を見て、そのことをあらためて感じさせられました。


＜関連記事＞
　超上流工程からシステム運用テストまでにおける考慮事項
　システム構築は顧客との「協働」作業

パッケージソフトウェアのテスト

簡易？且つノンカスタマイズで導入するパッケージソフトのテストは、どの程度実施すべきか？

パッケージソフトの場合、ソフトウェア自体の品質は、ほぼ問題ないと考えて良い場合が多いと思います。

よって、スクラッチ開発のソフトウェアを導入する場合と比較して、テスト期間が短く設定される場合が多いと思います。
それらを含めた導入期間の短縮化なども、パッケージソフトを導入するメリットであるとも考えられています。


どの程度まで、テストを簡略化できるのか？

それは当然、個々の製品、プロジェクトの性質から判断されることになります。

例えば、テスト環境でのソフトウェアテストは必要ない、という判断ができるかもしれません。
逆に、ブラックＢＯＸ化されているため、本番環境を用いたシステム総合テストは性能テストを通常以上に実施する、という判断もあるかもしれません。

よって、いずれにしてもテスト計画やテスト項目・シナリオの「検討」自体を簡略化することはできないと考えられます。
以上から、テスト計画等の文書化は省略できない、ということが見えてくるかと思います。


パッケージソフトを導入する際に、油断してはならないということを、最近、考えさせられました。

動作保障されていいると言われたパッケージソフトウェアの組み合わせでの導入時には、特に注意が必要です。

この場合、通常と同じく導入決定前の事前検証を十分に実施する必要があります。
これはスクラッチ開発ではできない、パッケージソフトウェアだからこそのメリットです。
それが様々な理由で実施できない場合には、導入過程においてシステム間結合テストを十分に実施する、またはベンダー側のシステム間結合テストに立ち会って動作確認を十分に実施することをお勧めしたいと思います。

その過程等を通して、システム総合テストを開始するまでに、さまざまな問題の解決策を検討し終えておく必要があります。

製品の仕様または製品自体の選定が導入過程で変更せざるを得なくなった場合には、なおさらのことです。
その場合には、提供会社、構築ベンダーの説明を鵜呑みにはせず、まずはリスケジューリングする方が安全であると思われます。


その上で、システム総合テストは、欠かせないです。
当然のことなのですが、例えばネットワーク環境などが起因して十分な性能が出ない、という場合が起こり得ます。

この場合、可能な範囲で導入決定前の事前検証を十分に実施する必要があります。
前記のとおり、これはスクラッチ開発ではできない、パッケージソフトウェアだからこそのメリットです。
それが様々な理由で実施できない場合には、あらかじめ、そのリスクを勘案した対策案を検討しておくと安全です。


そして、運用テストの過程で新たに発見された運用上の注意は、運用マニュアルを追加・修正することで対応し、また、利用者への案内や説明会資料にも、必要に応じて反映させることになります。


パッケージソフトウェアの導入は、プログラミングやソフトウェアテストの工程が無くなりますが、
その前後の工程については、少なくとも工程自体および工程ごとの計画策定について、スクラッチ開発と「内容」は変わっても、「ボリューム」は大きく変わらないと考える方が良いと、私は考えます。


＜関連記事＞
　超上流工程からシステム運用テストまでにおける考慮事項

　ソフトウェアの総合テスト
　システム総合テストの重要性
　顧客の受入テスト（運用テスト）