井上 研一 スルガ銀行と日本IBMの一件については、以前から関心を持って見ていたのですが、東京高裁の出した、「中止提言義務」というのがなかなか斬新なようです。
銀行の基幹システムの開発失敗を巡り、スルガ銀行が開発者の日本ＩＢＭを訴えていた訴訟の波紋が広がっている。東京高裁は昨年秋の判決でシステム開発会社に対し、プロジェクトの途中で達成が困難だと分かった場合、中止を提言する義務があるという新たな考え方を示したからだ。システム業界は「中止を申し出るのは実務上、悩ましい」と戸惑っている。
高裁は「プロジェクト中止提言義務」という新しい考え方を示した。「開発会社は最終合意を交わす段階で目標達成が難しい場合、システムを抜本的に見直すか、開発を断念するかをユーザーに提言すべきだ」とし、日本ＩＢＭはそれを怠ったとした。開発者はシステムを実現できない場合、適切な時期に顧客に中止を提言しなければならないという。
「銀行システム刷新失敗、責任は？ 開発者に「中止提言義務」 スルガ銀VS日本ＩＢＭで高裁判決 一括受注が大半、決断困難」日本経済新聞・2014/2/24 朝刊
記事では、この新たな義務について、諸々の関係者の悩ましく思っているという声を紹介しています。
ただ、高裁の言っていることは至極真っ当だとも思えるわけです。基本的にはSIerはそういうシステム開発に関する知見を期待されて契約に至っています。お金を貰って仕事をしている以上は善管注意義務になるでしょうし、だとしたら、難しいなら難しい、出来ないなら出来ないときちんと伝えないと、法律上ではなく、倫理的にも義務を果たしたとは言えないでしょう。
だからこそ、「無茶！」とか「無理！」ではなく、「悩ましい」なのでしょうが。
そもそも、なぜ、この真っ当な意見が「悩ましい」につながるかというと、「請負」という契約の仕方に問題があるのではないかと思います。
請負という契約形態
請負は成果物責任なので、とにかく完成させないと（法的に）義務を果たしたことになりません。
だから、デスマーチだろうがなんだろうが、ユーザの最終的な満足を無視してでも、完成させる。そうしないと「金なら払わん！」とか「金返せ！」ということになってしまいますから。
記事でも取り上げられている「モデル取引・契約書」では、要件定義は準委任、設計・開発は請負を推奨しています。スルガ銀行と日本IBMの契約は、要件定義から請負になっていたのですね。
ただ、モデル取引・契約書にしても、極めてウォーターフォール的で、準委任の要件定義フェーズで要件は確定するから、設計・開発フェーズでは要件はブレないということになって、請負でも良いという話になるわけです。
請負で本当に大丈夫なのか？
でも、実際にはそんなこともなくて、特に最近はアジャイルやリーン開発の考え方にも表れているように、それを是としているわけです。それを是としているからこそ、プロセスの方を工夫していこうとなっています。
それなら、高裁の言う中止提言義務も果たせるかもしれません。
では、そういう考え方でシステム開発の仕事を行う場合、「請負」という契約形態が適していると言えるのでしょうか・・・。
クラウドソーシング界隈の動向
一方では、クラウドソーシングとか、フリーで働くエンジニア像というものも、もてはやされつつあります。
私も一人会社をやっているエンジニアですが、まだ準委任で常駐での仕事しか受けたことがありません。
なので、あまり確たることは言えないのですが、いろいろと話を聞く限りでは、請負で非常駐の仕事が前提というか、やりたい方向性になっているようです。少なくとも、クラウドソーシングだと常駐はあり得ないだろうし、契約も請負になるでしょう。
納品しない・・・
それを否定するつもりはないし、私自身もそれが望ましいのかなと思っているのですが、この辺の要件の変更だとか、契約形態だとか、それにまつわる諸々について、どう対応しているのだろう。と、疑問が湧いてきます。
例えば、ソニックガーデンのやっている「納品しない受託開発」まで考えられていれば、上手くいくのかもしれません。でも、クラウドソーシングとかフリーでやっている人が、そこまで考えているかというと、多分違うように思います。だって、納品しているでしょう・・・。iPhoneアプリのように、納品するしかないようなものも多いですし。
まとめ
というわけで、その辺をきちんと対応する方法が整備され、ユーザとの間でもオーソライズされていけば、良いなぁと思う今日この頃です。
もちろん、当社としても色々考えているところではあるのですが・・・。