委託者と受託者の価値の共有

ソフトウェア開発を委託する側と受託する側の価値や目的の共有を支援する方法を研究テーマの一つにできないか考えています。かなり大きめで難易度が高いテーマです。しかし、多くの開発プロジェクトで共通の課題になりやすく、うまくできれば大きく役立つと考えています。アジャイルマニフェストの「契約交渉よりも顧客との協調を」「計画に従うよりも変化への対応を」といったあたりにも関係する内容であり、価値や目的の共有の難しさに共感される方も多いのではないかと思います。

価値や目的の共有を研究テーマの一部に含めたいと思ったのは、私自身がエンジニアとしてソフトウェア開発に従事していたときに経験したことがきっかけです。もう10年以上前の話になります。自社サービスの開発に2年くらい従事した後に、受託開発とその受託の一部を再委託する案件に携わりました。

自社サービスの場合、最終的な利用者のことを中心に仕様や構成を考えていたのですが、受託開発になると契約や委託者の承認がそれよりも大きな存在になりました。今でも印象に残っています。そのときは要求仕様をまとめて設計作業をした上で、コーディング、統合テストくらいまでを別の委託先にお願いしました。再委託すると、立場は変わりますが同じような状況に出くわしました。最終的にどういう使われ方をするかということよりも、こちらがお願いしたことへの忠実さやお願いの不備が話題の中心になりやすくなりました。特に不備があったわけでもスケジュール超過したわけでもありませんが、自社サービスとの違いを感じるきっかけになりました。もちろん全てがこうとは言えませんが、一般的な委託／受託の関係だとこういうこともあるということを知る経験になったと思います。

大学で研究をするようになってからソフトウェア開発に従事する方にお話を聞く機会をかなりの回数いただいており、今も続いています。そこでも同じような話を聞くことがあります。もちろん、委託や受託の開発がうまくいっているところもあり、それぞれ役割分担がうまくいっている開発もあります。その共通点は開発するソフトウェアやシステムの価値や目的が共有できていることと信頼関係が築けていることなのではないかと感じます。それらを実現する仕組みは様々ですが、共通点は価値の共有や信頼関係の構築に熱心というところにあるように感じます。

大学に移ってから価値の共有において私の印象に強く残っているのは、ある業務システム開発の委託側と受託側の不具合の深刻さに関する話でした。委託側は情報システムを扱う部門で、最終的な利用者である業務部門や委託側の顧客との間を取り持ちます。受託側がシステムを再起動しないと復帰できないトラブルを非常に深刻な問題と考えているのに対して、委託側はそれが与える業務への影響を心配していたことです。「性能が落ちて業務が滞ると困るから委託側にとっては深刻」という話と「受託側としてシステムダウンは起こってはならず、これが深刻な問題」という話があり、なかなかかみ合わなかったことを今でもふと思い出すことがあります。

ご自身の開発ではいかがでしょうか。非公式のコミュニケーション、都度委託者の価値を共有できるような場を設ける、可視化するといった工夫をお持ちかもしれません。もしかすると、ある程度は割り切って対応するという選択をされているかもしれません。

価値の共有は、ソフトウェアの受託開発だけの課題ではなく、どこにでもある課題ではないかと思います。委託側と受託側の課題の共有に関する取組みは様々で唯一の正しいやり方はないでしょう。他でうまくいっている方法をそのまま真似るよりは「（既存の）この仕組みに加えたらどうだろう」「このやり方を拡張したらどうだろう」といった考えを積み重ねるほうが現実的です。

拙著「間違いだらけの設計レビュー」の改訂版でも、設計レビューや要求仕様書のレビューで、システムやソフトウェアの最終的な価値を見据えて重点化する事例を加えました。価値を共有したり分析したりする方法を引き続き考えていきます。

改訂版がお手元にある方は、2章の60～80ページにある3つの実際の事例（グループ会社向け認証システム、多拠点の情報端末管理システム、案件管理システム）と1つの架空の具体例（座席予約システム）の部分ですのでご覧ください。お手元になく、ちょっと見てみようという方は、書店や日経ITproストアのページ（こちら）、Amazonのページ（こちら）から。