法の観点で見ても、アジャイル、DevOpsはごくごく「当たり前」のこと：特集：DevOpsで変わる情シスの未来（番外編）

アジャイルやDevOpsの核となる「共にビジネスゴールを見据える」「共に役立つシステムを作る」という要件は、法の観点から見ても正しい。

» 2014年09月17日 18時00分公開

※本記事はアフィリエイトプログラムによる収益を得ています

プロジェクトが“崖っぷち”に至る理由とは？

●著者：細川義洋●日本実業出版社●ISBN-10: 4534052014●ISBN-13:978-45340520189●発売日：2014/7/10

　「調停とは、ITプロジェクトのトラブルが最後に行き着く先です。ここで解決しない問題には、もう裁判以外に解決手段がないという崖っぷちのような場所です」。「しかし、実際に調停を行っていると『ここに来る前に解決できたのではないか？』と思えるような紛争が多々あります」。たとえ「要件の定義モレや技術的に解決できない問題の発覚といった困難な問題でも、プロジェクトを中断して再度企画を立て直したり、両者の合意の中でプロジェクトを中止するなどして、双方の傷を最小限に抑え込む工夫はあるはずです」。「IT紛争というのは多くの場合、どちらか一方に非があるということはないものです。その点をお互いに認め合えば、必ず合意点を見つけられるものなのです」――。

※本文中の引用部分については紹介書籍の仮名遣いを踏襲しています

　本書、「モメないプロジェクト管理 77の鉄則」は、東京高等裁判所IT専門委員、東京地方裁判所民事調停委員・IT専門委員の細川義洋氏が、多数の調停案件を通じて蓄積した「モメない」ためのノウハウを分かりやすく解説した作品だ。＠IT自分戦略研究所でも、連載『「訴えてやる！」の前に読む IT訴訟徹底解説』を展開中だが、本書ではプロジェクト管理や「プロジェクトマネージャーが実際に起こしてしまいがちな問題」にフォーカスし、「崖っぷち」に追い込まれる前になすべきこと、考えるべきことを詳しくアドバイスしている。

　印象的なのは、そうした「紛争を防止するための“鉄則”」を説くものでありながら、今日のビジネス要請に応える上でも鉄則といえる、非常に本質的な指摘が多数なされている点だ。中でも象徴的なのは、冒頭の一節にもある、「IT紛争というのは多くの場合、どちらか一方に非があるということはない」という一文だろう。

　事実、開発の失敗やトラブルは、ビジネス部門／ユーザー企業が「どのようなシステムを作るのか」を入念に考えることなく発注してしまう、いわゆる“丸投げ”や、要件を解きほぐさ（せ）ないまま、言われたままに使えないシステム／使われないシステムを作ってしまう開発部門／社外のSIer・ベンダーの開発スタンスに起因する例が多い。すなわち、開発の失敗・トラブルとは、システムを「使う側」と「作る側」、いずれか一方だけに問題があるわけではなく、双方の連携性の欠如、理解・認識のズレなどに本質的な原因があるわけだ。

　周知の通り、こうした問題の解消は“ビジネスとの連動”を要件とするDevOpsやアジャイルの文脈においても重視されている。その点、本書を読むと「失敗やトラブルを防ぐためのノウハウ」とは、つまるところ「ビジネス・エンドユーザーと、開発・運用を齟齬なく連動させるノウハウ」でもあることに気付かされる。以下では、いくつかの“鉄則”を紹介してみたい。

役立つシステムを作れなければ債務不履行？開発プロジェクトの鉄則とは？

　例えば、プロジェクトをスタートさせる上では、発注側とベンダー・SIer側の「役割分担」を明確化することが前提となる。というのも、要件を決めていく中では、「対立する部門の仲裁をしたり、ユーザのシステム担当者に変わって、上層部に掛け合ったりということまでベンダのメンバが行う」ことがある。ベンダー側としては「ユーザの中で何とかしてくれ」とも言いたくなるものだが、「昨今のIT訴訟における裁判所の判断を見ると、こうしたことが、必ずしもベンダの『好意』ではなく『義務』と見なされる」例が多いのだという。

　つまり、「ユーザ内部の調整も、そこにシステム開発に必要な情報収集、要件の取捨選択、効率的で安全な作業順など、専門家だからこそできることを含む」場合には、それも「ベンダの役割」と見なされるというわけだ。よって、本書では、「ベンダはユーザに行って欲しいと思う作業があるときには、これを明示的に役割分担表に表してユーザと合意しておく」必要があると指摘。「実施者、成果物アウトプットを意識できるまで（双方の）タスクをブレークダウン」しておくことが、プロジェクト成功の前提となると説いている。

　「ユーザが委託者としての責任を果たすように提言する」という鉄則も目を引く。特に深刻なのは、「委託者が適切に受託者の作業を管理せずに適切な指揮命令を行わなかったり、プロジェクトの課題を把握せず、その解決に必要な判断もしない上、欠陥があっても受託者に文句を言うだけで当事者意識がない、といった場合」だ。つまり、「成果物に責任を負う覚悟」を持ち、開発成功というビジネスゴールに向けてユーザー側を導くことも開発側の重要な役割と見なされるのだ。

　「単に作るだけではなく、ユーザがシステムを使えるようにする」という鉄則も大きなポイントだろう。「システムを目的どおりに使用できない状態のままベンダが引き上げしまうこと」は「債務不履行を問われる危険性」もあるほどの問題。システム開発の契約とは、あくまで「目的物が遅滞なく完成し、それをユーザが使用してメリットを受けられる状態にすること」が目的。それを実現することも、あくまで開発を請け負う側の“義務”なのだ。

　「要件変更・追加の可否は導入の目的を軸に考える」ことも、頭では分かっていながら、状況に流されてしまいやすいことの一つだろう。例えば「不意の要件追加・変更要望があり、代わりに落とす要件あるいは機能を選択する」際に、「ベンダ・ユーザのシステム担当者と、ユーザの経営層とエンドユーザで思いがバラバラ」となり、意見をまとめきれないまま「ユーザに寄与しないもの」ができてしまうことは実にありがちだ。筆者は、「新規の要件を申し出たユーザが影響力の大きな人間であるとき」など、流されがちな状況を具体的に解説。これを防ぐために、「導入の目的と要件・機能の関連を文書化する」ことを勧めている。

　さて、いかがだろう。以上のように、一つ一つの鉄則は「プロジェクトを正しく完遂するための基礎」ばかりだ。だが実際には、なおざりにされやすいものばかりでもあることに、あらためて気付かされるのではないだろうか。

　何より重要なのは、「役割分担」をはじめ、システムを使う側と作る側の「協働」や、ビジネスの「メリットを受けられる」システムを作る、相手が非協力的なら共に作れるよう導く、といった辺りだろう。これらはDevOpsやアジャイルの文脈でも特に重視されていることだが、実は決して特別なことではなく、「契約」という法的な観点から見ても、「真に役立つシステムを共に作る」ことはあくまで「開発の基本」なのだ。この点を再認識させられる向きも多いのではないだろうか。

　とはいえ、なかなかセオリー通りには物事を進めさせてくれないのが現実というものだ。その点、本書は調停を通じて幾多の“現実”を知る著者が、プロジェクトで起こりがちな問題と問題抑止の鉄則を、きわめて具体的に紹介している。「開発と運用が契約で分断されている中で、どうすればシステムのリリースサイクル、改善サイクルを加速できるのか」といったDevOps実践の方策としても参考になるはずだ。開発のスピード、コストばかりが重視されがちな中で、あらためてプロジェクトの本質を振り返ってみてはいかがだろうか。

参考リンク:「訴えてやる！」の前に読む IT訴訟徹底解説（＠IT自分戦略研究所）