また出番が回ってきました．よろしくお付き合いお願いします．
前回，前々回は風呂敷を広げすぎて，まとめきれませんでした．今回は…
■IT "それ"が見えたら，終わり（映画）
メイン州のデリーで子供の連続殺人事件が発生します．犯人は27年周期で現れる奇怪なピエロの格好をした悪魔，ペニーワイズ．彼はほとんどの大人には見えずに，子供にだけ見えます．子供は恐怖を与えれば与えるほど美味になるので…原作はスティーブン・キング．怖いです．
■IT "それ"が見えたら，終わり（プロジェクト）
プロジェクトでも「終わり」が見えることがあります．
中東で化学プラントのプロジェクトに従事した知人の話ですが，政変が起きて発注元の政府が転覆してしまったそうです．担当していたプロジェクトも空中分解してしまいました．革命軍の兵士に囲まれたときには「これで俺も詰んだな」と思ったそうです．怖いです．
さすがにそこまでの経験はありませんが，私も予算オーバーや納期遅れの経験くらいはあります．幸いなことに，自分がマネジメントを担当したプロジェクトでは空中分解の経験はありませんが，いくつかの瓦解したプロジェクトは見てきましたし，メンバーとして参加した場合には相当酷い目にもあっています．
■品質問題
まだ私がエンドユーザーに居て，この業界の駆出し（といっても30歳位）の頃です．プログラミングが少しできるようになったレベルで参加したプロジェクトでのお話です．
マシンのリプレースによる，広い意味でのマイグレーション・プロジェクトでした．古いマシンが撤去されサービスインしたにも関わらず，夜間バッチが20時間かかるわ，バックアップから再更新するたびに結果が違うわという状態に陥りました．
原因は責任者のスキル不足による設計ミスと，テストの不足（障害の定量管理も行われていませんでした），切り戻し処理が計画されていなかった点だと思います．当時の責任者は持病を抱えており，サービスインしたら入院する予定を立てていたので，予定通り入院してしまいました．
ほぼ半年かけて全てのプログラムをほとんど一人で書き直して，やっとまともに動くようにしましたが，その間はほとんど不眠不休に近い状態で働きました．ちなみに残業手当は一切貰えませんでした…月曜の朝に出勤して金曜の夜に帰ってそのまま飲みに行って，土曜日の午後からまた出勤したりすると，心臓がバクバクいってきます．今考えると怖いです．
その時に「スキルが低い他人の失敗に巻き込まれて，こんな目に合うのはもう嫌だ．失敗するなら自分で失敗しよう」と思いました．その時から情報処理技術者の試験を受け始め，自分のスキルが業界のどこら辺に位置するかを確認するようになりました．
■要件定義
これは10年近く前の話です．
当時，私は品質管理部門に所属し，大型プロジェクトのプロジェクト・マネージャに状況をヒアリングしたうえで，上司を通じて経営陣に報告するような仕事をしていました．
あるパッケージを利用して基幹システムを再構築するというプロジェクトがあり，このパッケージは，ユーザーのシステム部門の責任者が選択したそうで，比較的新しいコンセプトに基づいているものでした．その時点では，弊社はそのパッケージに関して開発経験が無く，パッケージベンダーの助力を仰いだうえで協力してやっていこうという話になっていたそうです．
プロジェクトマネージャに毎月ヒアリングしていたのですが，毎月ほぼ順調という報告が返ってきていました．しかし，3回目くらいに「どうもおかしい」と思い「彼の報告は信用できない．何か起きている」と上司に報告したところ…その後，すぐにユーザーさんから内容証明の郵便が届き，プロジェクトは雨散霧消してしまいました．
結局は「要件が固められない」と弊社が悪者にされただけでしたが，最終的にはパッケージベンダーも手を引いてしまいました．ユーザーの要求とパッケージの仕様の擦り合わせが上手くいかず，プロジェクトマネージャもユーザーとベンダーの間で右往左往しているように見えたので，これではまともに要件定義できないだろうなとは思いました．逆に言えば，あのまま続けていれば，もっと酷いことになった可能性もありました．
当該のプロジェクトマネージャには「そのパッケージのフィージビリティ・スタディをやって，もし駄目なら他の経験のあるパッケージを提案した方が良い」との助言はしていましたが「このパッケージの採用はユーザーからの与件ですから」と言って動きませんでした．
パッケージにはそれぞれ「思想」みたいなものがあります．
その「思想」と自社の業務が合わないと法外なカスタマイズ費用が発生する上に，下手をすれば動かせないシステムを押し付けられることにもなります．コンセプトが明確なパッケージの場合，そのパッケージに合わせて自社の業務を変更するくらいの勇気を持つ必要があります．
■パンデミック
本稿の執筆時点では，コロナウイルスによる肺炎（COVID-19）が世界的な問題になっています．早期の終息を祈りますが，本稿の公開時点で終息している確率は限りなく低いと思います．
まだネットがそれほど普及していなかった時代の話ですが，納期（日本の場合3月末が多い）が近づいてきた1月中旬，何とか納期も予算も守れそうな目途が立ったなと思っていました．金曜日に協力会社の中核メンバーから「風邪引いたみたいなので今日は休みます．来週は出ます」と電話連絡が入りました．「お大事に，無理しなくても今のところ大丈夫ですよ」と伝えましたが…
本人は翌週の月曜日の進捗会議から出勤してきましたが，その週末からバタバタと中核メンバーが倒れはじめてしまいました．結果的に1/3近い数のメンバーが倒れてしまい，ユーザーさんには納期の延長を申し込む羽目に陥りました．システムが実際に使われるのは，まだ少し先でしたので事なきを得ましたが，仮納品や再納品，デリバリーの予定変更等の余計な工数がかかりました．パンデミックは怖いです．
■セキュリティ
私が客先に常駐していた時，定例の打合せに担当者が現れません．その方の上司に確認したら「今週の打合せは中止にしてくれ．あとしばらくは定例会議も無くていい．何かあったら私に直接報告するように」とのことでした．
「これは何かヤバいぞ」と思いましたし，メンバーにも不安が広まったので，裏のコミュニケーション・ルートから探ってみました．その結果，当該の担当者は，顧客データを業者に売り払ったことが露見したため懲戒処分を受けたということが分かりました．
結局はその担当者抜きでプロジェクトを進めることになりましたが，エンドユーザーにはありがちですが，当該のシステムに関してはその方しか分からない部分が多く，判断に迷う場面が増えました，しばらくして代わりの担当者が異動して来ましたが，畑違いの部署からでしたので，ITに関するスキルが低い上に当該のシステムに関する知識はほぼ皆無でした．残念ながら，直ぐにプロジェクトの足を引っ張るような状況に陥りました，
結局はリスケして，半年の大幅遅延でプロジェクトは終了しましたが，コストも相当膨らみました．対価はきちんと払って頂きましたし，結果的に当該システムに詳しい要員が弊社のメンバーだけになったので，常駐要員も複数継続しました．当時の上司は喜んでいましたが，SES契約ってこういう所が嫌ですね．
この頃は今ほど個人情報やセキュリティについての意識が高くなかった時代ではありますが，セキュリティに対する要員教育が不足していたと思います．
私がその事件を知ったとき「これは早期に公表して，情報漏洩した可能性のある顧客にきちんと謝った方が良いですよ」とアドバイスしましたが，今ほどセキュリティインシデント対応の方法が明確になっていなかった時代のことで，顧客の上層部は隠蔽する方を選びました．結局，隠しおおせるはずもなく，新聞の全面広告やTVCMでの謝罪に追い込まれました．最初に公表して謝罪すれば，恐らく1～2千万の損害で済んだと思いますが，隠蔽したがために数億の経費がかかった上に株価の大幅な下落，ブランドの信用失墜まで招いた事例です．でもこの部分はプロジェクトの破綻とは関係ないですね．
■工期遅延&コストオーバー
こちらも結構昔の話ですが，古いUNIXのC言語からJavaに切り替えるマイグレーション・プロジェクトで，自動変換ツールの利用を前提に比較的安価で受注したプロジェクトがありました．実際に蓋を開けてみると，そのツールで変換可能な割合が2割くらいしかないことが分かりました．他のツールも試したようですが，結果的には全面書き換えになり，工期は1年延びました．
工期が延びると当然コストも膨らみます．新しいオフィスを借り，ネットワークも引いて，エンジニアをかき集めて突貫工事で進めましたが，原価が受注額の倍を軽く超えるくらいかかりました．
私はこのプロジェクトには全く係わっていませんでしたが，担当したエンジニアは結構優秀で，フィージビリティ・スタディも事前にやっていて，行けそうだと感触を持っていたそうです．後で考えると，フィージビリティ・スタディの範囲に問題があったようですが，私が担当しても同じような失敗をする可能性があるなと感じました．
■プロジェクトの成功率
ソニー生命の調査によると，高校生のなりたい職業の1位が「ITエンジニア・プログラマー」だそうです．
https://www.sonylife.co.jp/company/news/2019/nr_190806.html
「今どきの若いもんは，この業界のブラックさを知らないな」と思ったのですが，考えてみると，徹夜作業が当たり前で毎朝のように床や椅子の上で何人も死んだように寝ているという，タコ部屋・マグロ漁船状態は，このところ減っていると思います．そこで調べてみると，やはりプロジェクトの成功率は向上しているようです．
日経ビジネスによると，2003年の時点ではQCDの全てを順守できたプロジェクトの比率は26.7%だそうです．QCDの全てを満足するのは容易ではありませんね．
2018年には「品質」の項目を「満足度」に変えて調査すると成功率は52.8%になりました．もし「プロジェクトの成功」の定義を「顧客が満足した結果を残すこと」とすると，実に80%近い成功率になります．
当該の記事によると，プロジェクトが失敗する一番の理由は要件定義の問題にあるそうです．また，失敗しやすいシステムとして，CRM，SFA，SCMがあげられています．いずれもステークホルダーが多く要件が決めにくいシステムです．経験上も，工期の問題から要件定義の途中で見切り発車すると，あまり良いことはありません．
https://business.nikkei.com/atcl/opinion/15/100753/030700005/
今のプロジェクトは，生産管理やCRM，SCMを全く新規に造ることは滅多にありません．広い意味でのマイグレーションがほとんどです．
記事にはマイグレーション・プロジェクトについての言及がありませんが，経験上，失敗すると酷くなるように思います．感覚的には，順調に行くか一つ間違えると原価が受注額の倍以上かかるような酷い目にあうという感じがします．
前回，前々回と「構造」を理解することの重要性を書いてきたつもりです．
日経ビジネスの記事にも「経営者や業務部門は『企業の内外にある業務の構造を整理し』それを『頭に入れてから要件を話し合う」活動にぜひ取り組んでほしい」という記述があります．対象の構造を理解することは，プロジェクト成功の十分条件ではありませんが，必要条件ではあるように思います．
■定量的コントロールのススメ
前述の日経ビジネスの記事にもありますが，プロジェクトの成功率が向上している理由の一つには，プロジェクトへの定量的コントロールの導入があるように感じます．
以前，紹介したと思いますが，IPA/SECから「ソフトウェア開発データ白書」が公開されています．しかも無料（!）で使えます．
https://www.ipa.go.jp/ikc/reports/20181011.html
ソフトウェア開発の場合は人間系の作業が中心なので，統計値はバラつき（分散）が大きく，中央値と平均値の違いもバカになりません，定量データを補正するに足る定性データは提供されていませんし，特異値の混入によるバイアスもバカになりませんので，全面的に信用して使うことは難しいと思います．しかし，母数が結構あるので，感覚的には概ね納得できる値が提示されています．しかも元データもEXCELで提供されていますので，特異値を排除するとかスコープを自分のプロジェクトに合わせるとか加工して使うことができます．
しかし実際にどういった項目をどういった目的で使うかは，結構難しいです．
本来は，計画（見積り）→実行→完了の各段階で同じ評価軸を使うことが望ましいのですが，例えば「生産性」を「KSLOC/工数」でコントロールする場合，計画時においてKSLOCは明確になりません．したがって見積りに使うことは難しくなります．
経験上はFunction Pointを使う方法が一番精度が高いように思いますが，これも手間がかかる割に，経験者の勘を超えることが難しいようです．かといって勘だけに頼っていても，失敗する確率は減りません．
例えば前述の「KSLOC/工数」に関して言えば…
1) プロジェクトの早い段階で計測する．
2) IPAの値と比較する．
3) あまりに乖離しているようなら，原因を探して改善する．
4) さらに習熟曲線を加味して，今後の予測を立てる．
といった使い方ができます．
今後の予測を立ててみて，生産性を3倍にしないと工期もコストも達成不可能ということが見えた場合…「"それ"が見えたら，終わり」の状態です．
他にも，レビューやテストでの不具合数の推移や比率，不具合修正にかかった工数の推移等の「"それ"が見えたら，終わり」のコントロールに使えるデータはあります．ただし同じデータを視ても"それ"が視えるかどうかは，視る人のセンスや技量にかかってきます．
■ティッピング・ポイント
物事にはティッピング・ポイント（転換点：Tipping Point）があります．
そのポイントを過ぎると，それまで小さな変化を示していた事象が急激に変化します．不具合数が一定の量で推移してきたのが，ある時を境に急激に増加するようなことが起きます．
こういった事を事前に検知し対応するためには，定量的コントロールと定性的な観察が必要になります．トム・デマルコは40年近く前に「測定できないものは制御できない」と言っています．
プロジェクトは時間的な制限があります．終わりに近づけば近づくほど，打てる手は少なくなります．セキュリティでも同じですが，少しでも早く"それ"（リスクの予兆）を検知して対応をすることが必要です．
■定量的コントロールの限界
これまで定量的コントロールについて書いてきましたが，実際には「そんなことは，もう昔からやってるよ」という方が多いと思います．
プロジェクトにおける定量的データは，ほとんどの場合，一定の主観を交えて現場から上がってくるので，いくらでも誤魔化しがききます．報告者が虚偽の報告をするつもりがなくても，バイアスがかかります．
「3日程度遅延していますがリカバリー可能です」といった報告をよく聞きますが，実際に報告者はリカバリー可能と思っているので検証が難しい場合が多いです．プロジェクトの仕組みとして，必要最低限の検証ができるようにしておくことが有効です．
また「定性的な観察が必要」と書きましたが，数字だけ見ていても現場は分かりません．定性的な観察は定量的なデータを超えることがあります．例えば前述の「要件定義」で「どうもおかしい」と思ったのは，後になって考えれば定性的な観察で異変を察知していました．
完全に字数がオーバーしている（前後編に分ければよかった）ので，プロジェクトが「詰む」時の定性的な予兆については，また機会があれば書かせて頂こうと思います．
■終わりに（パンデミックについて再び）
前述の「パンデミック」でCOVID-19について触れました．
この時期はCOVID-19だけでなくインフルエンザにも注意が必要です．東洋経済社の報道によると「アメリカ疾病対策センター（CDC）は、昨年10月1日以降2月1日までの間に，合計2200万～3100万人がインフルエンザにかかり，死亡者は1万2000～3万人となったと推定している」とのことです．
https://toyokeizai.net/articles/-/330373
私も数週間前にインフルエンザのような症状が出て，医者に行って検査を受けたところ「陰性」でした．その時に，どうも医者の歯切れが悪く「この検査ではインフルエンザとは言えない」というような口ぶりでした．気になって調べてみると，インフルエンザの簡易検査は「特異度」は高いけれど「感度」は低いそうです．ということは偽陰性が多い（陽性なら確実にインフルエンザだが，陰性でもインフルエンザでないとは言いきれない）ということになります．
万一客先で感染が広がると大変なので，医師と相談して，インフルエンザと同じように解熱後48時間は外出を控えるという対応をとりました．
インフルエンザの検査が「陰性」でも，この対応を取ったことは正しかったと思います．こういったリスクへの対策として，リモートワークを可能にしておくという方法があります．皆様の組織でも一度検討されては如何でしょう ?
最後までお読みいただいた方（もし居れば）有難うございました．
■執筆者プロフィール
上原 守
ITC，CISA，CISM，ISMS審査員補，情報処理安全確保支援士
IPA プロジェクトマネージャ，システム監査技術者 他
エンドユーザ，ユーザのシステム部門，ソフトハウスでの経験を活かして，上流から下流まで，幅広いソリューションが提供できることを目指しています．
コメントをお書きください