プロジェクト成功の秘訣とは？ 情シスがPDCAの「Do」を意識して対応すること

1. プロジェクト管理改善のためのポイントを考える

2023年も残りわずかになった。何かいつもと違う年末を迎えた気がする。新型コロナウイルス関連のニュースが少なくなったものの、地球規模の異常気象、どうすることもできない戦争。国内では連日クマによる被害のニュース。全ての生き物は地球の異変を感じているのかもしれない。不安というか危機感を覚える。年末の国民的テレビ歌番組も例年とは違う内容になる。今まで当たり前だったものが変わってきた。2024年はどんな年になるのだろう。新しい年を迎えるにあたって、希望に満ちた未来に向かう道を作っていきたい。 さて、私事だが2020年12月からコラムを書き始めて3年が経過した。これからも読者の方々、関係者への感謝の気持ちを忘れず、情シス現場の皆さんのお役に立てるよう情報発信を続けていきたい。

前職（NHK）情シス時代のことだが、開発業務でプロジェクト管理全てを開発ベンダに任せた（丸投げした）ことで、開発が予定通り進まず仕様変更や工数の見直しなどが発生し、スケジュールが遅延したことがあった。スケジュールが思い通りにいかない理由は1つだけではなく、様々な要素が積み重なっていくものだった。情シスがPDCAサイクルの“あること”に注意を払うだけで改善できた例を今日はお話ししたい。魔法のようなものではないので気楽に読んでほしい（笑）。

2. スケジュール通りにシステム開発が進まない原因

あるプロジェクトを例に話を進めよう。情シスがユーザ部門からの要請を受けて、工程管理も含めて開発ベンダに依頼するケースを想像してほしい。

とあるプロジェクト進行中、開発ベンダとの会議で進捗状況を確認すると、「想定していたより複雑な機能の要求があったので、見積もりを作成した時より工数がかかってしまいそうだ。追加コストが必要になり、スケジュールも変更してほしい」との要望が出てしまった──。

仕方がないので、コストの追加やスケジュールの変更をしたが、さらにリリースが延期したり、機能開発の一部が間に合わなかったりする状況であった。「こうなる前にもっと早く言ってほしかった」と思ったもののすでに手遅れで、予定通りにシステム開発を完了させることができなかった。そして、さらなる追加コストが発生しスケジュールも遅延しているのに、なかなかシステム開発が進まない…という結果になってしまった。

このようなケースが発生する原因は、ある意味、システム開発のプロジェクト管理を開発ベンダに過度に依存したことかもしれない。なぜ、うまくいかなかったのか、理由を考えた時、情シス側がプロジェクトを実行するうえで、開発ベンダとのPDCAサイクルに合わせた行動でユーザ部門（社員）への説明や、関連部署への調整役である「Do」の部分ができていなかったからではないだろうか。このような調整業務についてわかってはいても、できないものだ。しかし、プロジェクト計画書の中に情シスの仕事として明確にしておくことが大切なのである

3. 「全てベンダ任せ」の状態はよい結果につながらない

個人の感想になるが、発注する側の立場で話をすると、発注の要件定義書では、スキルの高い開発ベンダを選定し、技術者の資格条件や、類似した開発事例の経験の有無といった制限を設け、開発ベンダの選定には気を遣っている。

最近では、どんな大手の開発会社であっても自社要員だけでは行っていないため、開発案件に本当にベストな要員を割り当てられるとは限らないと思っている。情シスとしても全てを任せれば、他の仕事ができるようになるなどメリットは生まれるが、プロジェクトがスタートしてから全てベンダ任せの状態ではよい結果につながらない。

プロジェクトが遅延していたら、情シスで対処すればすぐに解決することが多い。プロジェクト管理に積極的に加わり参加すれば開発ベンダが無駄な作業に時間を費やさずに最大のパフォーマンスを発揮できる。

しかし、ほとんどの場合、開発ベンダがスケジュールを計画してそれに従って進み、進捗定例会議などで取り上げられる問題点の報告も、開発ベンダ視点で上がってくるという状態であることが問題なのだ。だから、プロジェクトが思うように進まない。

4. 情報シスが計画の策定や、問題解決に積極的に関わる

プロジェクト進行中に、予定にないところでユーザ部門（社員）の声を拾い上げ、課題を見つけることに力を注ぎ過ぎると、当初の見込みより工数がかかってしまい先に進まなくなることがある。

このような課題については、開発ベンダではなく情シスが調整するべきだ。両者の利害が関係する課題を解決するには、情シスこそが両者の立場を理解できるからだ。このようなユーザ部門からの調整事の積み重ねが遅延の発生につながると理解し、そうならないように情シスは積極的に関わってほしい。もしかしたら、開発ベンダが一番お願いしたい業務かもしれない。

5. PDCAサイクルではプロジェクト計画書の作成を共同で行う

前職（NHK）の2013年、情シスとしては大きなプロジェクトがスタートし、サイバーBCP構築計画が立ち上がった。基幹システム、メール環境が自然災害時だけではなく、サイバー攻撃への代替措置として持続可能なシステムを考えるプロジェクトだった。システム検査については、実際に事故は起こせないため想定実験を繰り返し行った。当時、膨大な想定シナリオを作り本番切替まで実験を繰り返した。思えば作文（シナリオ）を書くことが苦にならなかったことが、今のコラム投稿につながっているのかもしれない（笑）。

開発工程の進め方や、開発工程ごとの成果物、開発ベンダの作業スケジュールや、開発ベンダ側の技術者の体制については情シスがPDCAサイクルのプロジェクト計画書策定から関わり、常にユーザ部門（社員）も巻き込んで、訓練に加えてもらうなど組織全体で取り組むようにした。開発ベンダに丸投げしてはいないものの、ユーザ部門からの全ての要望に対しては満足が得られず、優先順位を考えるなど、関連部署との合意形成に時間を費やす日々だった。これはある意味、接着剤としての役割を情シスが請け負ったことによってプロジェクトがスケジュール通りに進み、成功につながったのではないだろうか。

各部署への説明は、難しい用語を一切使わず、IT解説書を作るなど常にユーザ部門と開発ベンダに寄り添いながら進めていた。関連部署の上層部からは常に「情シスの言うことは難しい」と言われ続けた。当時、情シスからだけの説明は止めて、総務部、技術部などを巻き込んで、その部署から説明をしてもらった。新システムに対する理解を得て、他部署を巻き込み、プロジェクト推進を順当に進めたり、開発ベンダのやりやすい環境を作ったりするのは情シスの仕事なのである。

6. プロジェクトのゴールを共有する

プロジェクトで最も重要なことは、プロジェクトのゴール（場所）を共有すること。ゴールについてはイメージ（想像）ではない、目的地（場所）を考えなければならない。この認識がずれていると目先の課題だけに気持ちが向いてしまい、目指す場所とは違うところに行ってしまう。到着してから気づいては遅いのだ。

最近はWBSでの管理を行うことが多いが、予算内に収めるには開発工程ごとのエンジニアの工数見積もりがどれくらいで、それに対して成果がどれくらい出ているか、管理上の見える化が必要だ。予定内に収まるように関係者全員で協力をすることも重要であるが、遅延で済むのか、完成にたどりつかないのかでは全然違う。整備に関する情報発信も情シスの仕事で社内のHPポータルサイトを使い、進捗状況や運用制限情報などを掲載するなどきめ細かな対応も必要なのである。

7. まとめ

プロジェクトを成功させるのは、情シス自身もPDCAサイクルを回しながら進めていくことが必要で、ユーザ部門（社員）に追加要件を押し込まれたりしても情シスがそれを制御してくれる存在でいることが開発ベンダからの信頼も確保でき、成功への道が見えてくる。さらにチーム内の相互の信頼関係を保てれば、プロジェクトの進捗管理はよりスムーズに行うことができる。情シスは「Do」を意識して対応することが大切だ