システム開発のプロが実際にやってる～リアルな「リスクの予防/軽減策」

システム開発におけるリスク管理において、リスクが発動した後の「対応・対処」ではなく、主に「予防・軽減」について少しリアルな視点からお伝えしようと思います。
「リスク管理」に関する一般的な情報は他のサイトにも多くありますので、そちらをご覧いただければと思います。
ここでは受注側だけでなく、発注者側のリスク管理にも触れつつ、既知のリスクに焦点を当ててリアルに分かりやすく説明してみたいと思います。触れていきたいと思います。

まだこちらをご覧になっていない方はぜひご覧ください。

お金と納期（時間）のリスク

受注者のリスク
我々にとっての金銭的リスクは、意図しない赤字です。
たとえば、品質が悪ければバグ修正やテストのコストが増えます。
それにより進捗が遅延すればエンジニアの追加投入など、コストの増加を招いてしまいます。
ほんの一例ですが、このようにリスクは連鎖的に発生していきます。
計画通りに完遂できるよう、日々のマネジメントを徹底することでリスクの発生を抑えていきます。

発注者のリスク
発注者側の金銭的リスクとしては、プロジェクト中の要件や仕様変更による予算オーバーでしょうか。
これは、要件定義に十分な時間をかけ、自分事としてしっかりと取り組むことで軽減できるかと思います。

また、我々は仕様変更を吸収するための予算バッファを見積もりには含めません（含める場合は、それを明記しお客様と認識を合わせておきます）。
ですので、発注側で予算のバッファを確保できるなら、それを推奨します。

また、納期的リスクについては、ベンダーへの依存が大きいかと思います。
これに関しては
　・ベンダーに依頼されたことは極力期限を守る
　・進捗や課題を常に把握し、ベンダーと密にコミュニケーションを取る
　・丸投げしない
などの対応でリスクヘッジするのがよろしいのではないでしょうか。

人のリスク

受注者のリスク
組織やエンジニアのスキル不足は、品質や生産性に悪影響を与えるリスクです。
当社ではマネージャー陣がスタッフのスキルや得意・苦手分野を把握しており、このリスクはほぼ発生しません！
100%自社開発で、日頃からスタッフと密に関わっているからこそできることかと思います。
とは言え、日進月歩で進化するテクノロジーを組織もエンジニアも身に着けていかなければなりません。
新しい技術や領域に挑戦する際には、バッファを持って計画することでリスクを軽減しています。
たとえば、3日間の作業を5日間として計画し、エンジニアのスキルアップに投資することで新しいスキルを身に着けていきます。

発注者のリスク
発注側においては、プロジェクトの責任者や担当者に適切な方を選ぶことがリスク回避につながるかと思っています。自社（システム開発）の目的を十分に把握し、かつ関わる業務に精通した方が適任ではないでしょうか。

コミュニケーション不足

受注者のリスク
我々内部のコミュニケーションは、朝夕のミーティングやフリーアドレスの環境などで、発生確率をほぼゼロにしています。
また、みんなが意見や考えを自由に発信できる文化も醸成していると思っています。

お客様とのコミュニケーションにおいては、主に以下のことを意識し、お客様の理解や共通認識を深めていけるよう取り組んでおります。

・密に話す
・口頭で終わらせない
・共通認識をもてるように図や表を用いて工夫する
・用語の定義を合わせる
・専門用語を多用しない
・認識のズレがあるかもしれないと感じた際には、別の言いまわしで確認する

発注者のリスク
ベンダーに対して、様々な情報や状況を積極的に伝えることが大切かと思います。
受注者側と同様の対応を取ると良いかもしれません。

病欠

これは普通に発生します。
病欠は予測できないため、計画には反映できないです、はい。
当社は大きな会社ではないため、待機要員がいるわけではありません。
結局はプロジェクトメンバ、もしくは別プロジェクトのメンバで誰かの稼働をあげてリカバリするしかないのです。
（もちろんスケジュールに影響が発生しそうな場合は、お客様に相談はいたします）
テレワークを活用し、感染拡大を防止するなどの対応は行うものの、このリスクは受容して進めております。

技術的リスク

新しい技術の採用による、スキルアンマッチや要件を実現できないなどの問題ですね。

受注者のリスク
このリスクは回避するのでほぼ発生しません。
時代の流れに追従するために新しい技術を学び続けることは必須です。
ですが、実績もない、検証もしない、でいきなり新しい技術を採用することはあり得ません。

ただ、要件を満たすために「こうすればできるのでは（想定）」という場面はあります。
その場合は、以下のようなことを行います。
・事前検証を提案する
・事前に顧客にリスクを説明し理解いただき、実現できなかったときの代替案を提案する
これによって問題が生じたことは、過去にはありません。

発注者のリスク
既存ビジネスを大きく変える、あるいは新規ビジネスの立ち上げ・検証などをする場合があるかと思います。
そういった場合は一気に投資するのではなく、リスクの影響を最小限にするためPoCやPoVとして発注することをお勧めいたします。

他にもいろいろあるのですが、特にお伝えしたいことは「情報セキュリティリスクは重大な影響をもたらす」という点です。
システム開発およびシステム運用におけるセキュリティ対策は、利用者が意識しにくい部分であり、軽視されがちです。
ここは十分な時間とお金を投資して、しっかりと対策を講じることが不可欠です。
セキュリティ対策にコストをかけようとしないベンダーは信用できないと考えたほうがよいと思います。（個人的な意見です）

品質的リスク

開発者からみた品質

我々の品質管理手法については、今後別のブログでご紹介したいと思います。

発注者としては、「思っていたものと違う」「動作不良が多い」などの問題となります。
これに対する対策としては、信頼できるベンダーを選定するか、各工程で発注者自ら品質確認することなどが考えられますが、完全な対策は難しいかもしれません。
我々もソフトウェアの品質には自信を持っていますが、自身がないと言うベンダーはいないですから、判断が難しいですよね。

昔の話になりますが、メーカーの下請けをしていた頃、大手メーカー様に厳しく鍛えられた経験があり、それが今も生きています。当時は非常に苦労しましたが、今ではその経験に感謝しています。

利用者からみた品質

利用者から見た品質はどうでしょうか。

・利用者の満足具合
・楽しさや満足感の提供
・ビジネスのリスクの軽減

これらの要素は、当社が直接保証できるものではありません。
ですので、利用者の立場に立って要件や仕様を提案しながら進めることで、満足いただけるよう心掛けております。

さいごに

リスク管理はシステム開発の成功に欠かせない重要な要素です。
プロジェクトの直前に備えるだけでなく、組織づくりやプロジェクト推進の過程でも、普段からリスクに対する意識を持つことが大切です。

少し長くなってしまいましたが、システム開発におけるリスク管理について、受注側と発注側の視点から少しでもお役に立てたなら幸いです。