この7月、筆者らが2年以上にわたって開発に携わってきたシステムが無事リリースされた。世の中にシステム開発の遅延や断念といったニュースが少なからず流れる中、当初の計画通りにシステムを動かせたことの感慨は大きい。それに加え、今回の開発は「利用者主導の開発」の検証という意味もあった。そのことについて書いておきたい。
筆者は6年前に上梓した書籍で、システム開発が失敗する要因は、G、A、P、Sの4種類のギャップであると示した。システム開発の目的を経営層と共有できていない「Goalのギャップ」。業務知識が開発側に伝わっていない「Activityのギャップ」。プロジェクトが計画していた工程からずれる「Processのギャップ」。開発側に必要な技術が不足している「Skillのギャップ」。これらの頭文字を取るとギャップ（GAPS）となる。
どうすればこれらのギャップを埋められるのか。筆者は開発側だけでは無理だと考えている。Goalのギャップが典型だが、システム開発を難しくする根本要因が発注側にあることは多い。開発側にも改めるべきところはあるが、発注側が丸投げをやめてプロジェクトに主体的に参画しなければ、システム開発の成功はおぼつかない。
筆者らはこの「利用者主導の開発」を単なる理想論に終わらせないために具体的な道具立てを提案してきた。基本的な発想は、発注側がフレームワークをはじめとするソフトウエアプラットフォームや開発プロセスの標準を用意し、開発側にそれに従ってもらうというものだ。そうすれば発注側が開発に関与できるようになる。
だが、この開発を実行に移すにはいろいろな困難がある。まず、開発側は、請負開発にもかかわらず進め方に口出しされることに反発する。未経験の進め方を覚えなければならないし、開発状況が発注側に丸見えになってしまう。表面化しないうちにやりくりしていた小さなミスまで知られてしまう。
しかし、これは考え方次第だ。進め方は一度習得してしまえば、次回以降は習得していない競合他社よりも優位に立てる。開発状況に関しても隠すのではなく、トラブルが起こっても初期の状態で発注側と共有し、一緒に解決できればむしろプラスだ。
大きな課題は開発側ではなくむしろ発注側にある。丸投げをせずにプロジェクト運営に参画するには、システム開発の知識と経験が必要だ。そして、プロジェクト運営に口を出す以上は責任を持つことになる。システム開発が失敗したときの責任を開発側にだけ負わせることができなくなる。責任主体として振る舞う覚悟が不可欠なのだ。
冒頭で紹介したシステム開発では、利用者主導の開発を適用し、さまざまな問題に直面した。未経験の開発の進め方に戸惑う開発チーム。丸投げのときより積極的な関与が求められる利用部門のスタッフ。要件が思ったよりも複雑だったために検討漏れなどが判明すると、その都度利用側と開発側のステークホルダー間で調整を行う。こうした調整をプロジェクトの立ち上げから延々繰り返してきた。
プロジェクト期間は長く、さまざまなあつれきは生じたが、一つひとつ問題を解決する中で、お互いの信頼関係が醸成されてきた。プロジェクトの終盤になると、全力で一緒に問題解決に取り組む形ができていた。この信頼感によって、スケジュールがタイトな中であっても開発チームのモチベーションは下がらなかった。ピーク時には残業が続いたがマインド的には最高の（＝幸せな）状態でリリースできた。関係者全員の熱意と努力のたまものであるが、それを阻害しない環境を作れた意義は大きいと思う。
今回の開発を通じてさまざまな課題は見つかったものの、利用者主導の開発の持つ将来性には確信が持てた。すべての関係者が幸せになれる開発の現場を増やしていきたいと思っている。
