連載
» 2014年09月17日 18時00分 UPDATE

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

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

[内野宏信,@IT]

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

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

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

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

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

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

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

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

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

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

Copyright© 2017 ITmedia, Inc. All Rights Reserved.

@IT Special

- PR -

TechTargetジャパン

この記事に関連するホワイトペーパー

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。