先日、J-AISA（情報システム監査普及機構）主催の第5回定例研究会に参加しました。
「ベンダー選定と評価基準」ということで、外部調達とシステム監査に関するお話でした。

昨今は、クラウドサービスの台頭などに見られるように、システムの大部分を外部調達でまかなうことが増えました。
その傾向は、今後も続いていくといわれています。

ですが、外部調達には色々とリスクが潜んでいます。
その中でも、今回のお話では特に「ベンダー選定」についてお話を聞かせていただきました。

これをお読みの方が開発畑の方だと、あまり「ベンダー選定」という業務に馴染みがないかもしれません。
私も似たようなものではあるのですが、自治体などでは、『希望するシステムをどのベンダーでまかなうか』という検討事項があります。
それが「ベンダー選定」です。

一般的には、発注する側が希望する条件などを示し、提供する側がその条件にどのように応えられるかを回答する。
そのうえで、発注する側が独自の基準に基づいて提供側の条件を評価し、どこに依頼するかを決定するという流れになります。

が。
これがうまくいかないケースがある、というのが本日のテーマでした。

その理由については色々とお話があったのですが、個人的に一番印象に残ったのは、『発注側（自治体側）は、提供する側のプロジェクト管理体制を軽視する傾向がある』という点です。

自治体に限らず、システムを発注する側は、システム開発に対して十分な知見を持っていないケースが少なくありません。
また、提供する側としても『何を作ってほしいのか』というのが最初に聞きたいことになり、自社のプロジェクト管理体制などは、聞かれなければ答えないスタンスが多いと思います。
その結果どうなるかというと、システムに求める機能などはある程度出てくるものの、それ以外の項目、特に管理体制などが要求事項に挙がってこないという問題が発生します。

ですが、プロジェクトの管理体制というのは、プロジェクトの成否を分ける、非常に大きな要素です。
どれだけ優れた機能を提供できるとしても、管理体制が脆弱で品質が悪かったり、納期が遅延するようでは、プロジェクトとして成功したとは言えません。

セミナーでは、このような問題を検出する具体例として、体制図の例などが挙げられました。
一般的に、外部調達においては、提供する側は『このような開発体制で行います』という情報を提供して入札します。
その一例が体制図なのですが、しっかりとしたプロジェクト管理体制が敷かれている組織では、ここの情報がキッチリと出てくるというお話がありました。

例えば、プロジェクトマネージャーにはＡさんを配置する。
そのうえで、αチームとβチームに分け、それぞれにチームリーダーを配置する。
そういった、開発の体制が見えるものがひとつ。

もうひとつは、じゃあその配置されるＡさんはどんな業務を行ってきたのか、どんな実績を持っているのかという経歴に関する情報です。
官公庁の入札案件などでは、情報処理技術者試験の有資格者が求められたりしますが、それもこの体制図の一部に表されます。

そのような情報がしっかり出てくるところは、プロジェクト管理体制もしっかりしている。
それを発注側が気にかけられるか。
そこにひとつのポイントがあるというようなお話でした。

もうひとつ、こちらも印象に残った点ですが、『プロジェクト監査を行うとして、現実的にどのタイミングで実施できるのか』という問題提起もありました。
先の事例なども考慮すると、調達先を探す前、条件などを決めた際に、一度監査を行うことが『理論上は』正しく見えます。

しかし、実態として、調達先を探す前の段階では、そのような予算はつきません。

では、予算もついて、かつ、監査の効果を実感できるタイミングとはいつか？
その議論に対するひとつの答えとして、『調達先を決定する直前』という提案がありました。

『調達先を決定する直前』というのは、開示した調達条件に対して、各ベンダーから応札（応募）があった後です。
つまり、『その調達を行うのだ』というのは決定していて、『どこに依頼するか』を決める前のタイミングです。
ここならば、プロジェクト監査の活動にも多少の予算をつけられる可能性があります。

一方で、そのタイミングを逃すと、以降のタイミングで監査を行っても後手に回ってしまうことが多くなります。
プロジェクトの遂行中というのは状況が常に変化するため、監査を行っても監査意見を表明するころには、とっくに該当作業が終わっていることも考えられます。
ウォーターフォールモデルなどでは、各工程の完了時に監査を行うという考え方もありますが、そこで行う監査は各工程が期待通りに終わっているかどうかの監査が多く、プロジェクト管理体制や調達条件そのものに関する監査が行われることはないと思います。
また、プロジェクトが完了した後の監査も、監査目的が異なる（次回以降のプロジェクトに活かすため）のでやはり適切ではありません。

結局のところ、ある種の苦渋の決断として、『調達先を決定する直前』しかない、というのが実情のようです。
普段開発畑にいる人間としては、このあたりの実情を知る機会は中々ないので、大変勉強になるお話でした。

システム監査というと、情報セキュリティに関する監査、もっと具体的に言うと、ISO 27001 の認証取得に関する監査が多いと思います。
ただ、私が本当にやりたいのは、今回の研究会で議題となったような「プロジェクト監査」です。

開発者のひとりとして、これまで色々なプロジェクトに関わってきましたが、簡単な振り返り会はあっても、監査と呼ぶような大がかりでしっかりとしたものはありませんでした。
ですが、どんなプロジェクトでも、失敗のひとつやふたつあると思います。
それらをしっかりとすくいあげて、検証し、評価し、組織全体のナレッジとして蓄積することで、同じ過ちを回避する。
そのための活動ができないか。
そんなことを考えながら、今後も監査の勉強を進めていきたいと思います。

それでは、管理体制の不足と聞いて耳が痛い、山本慎一郎でした。