派遣で働くエンジニアのスキルアップを応援するサイト

PRODUCED BY RECRUIT

【イベントレポート】裁判から学ぶ!成功するシステム開発に必要な人材になるには

株式会社リクルートスタッフィングが運営するITSTAFFINGでは、弊社に派遣登録いただいている皆さまのスキル向上を支援するイベントを、定期的に開催しています。2018年1月12日には「成功するシステム開発は裁判に学べ!」を開催。

東京地方裁判所調停委員で、書籍「成功するシステム開発は裁判で学べ!」の著者でもある細川義洋さんを講師にお招きし、泥沼にはまらないために、エンジニアが知っておくべきこと、やって良いこと・悪いことなどを、裁判事例をもとにわかりやすく紹介していただきました。そのイベントの様子をご紹介します。

f:id:itstaffing:20180222152618j:plain

■今回のイベントのポイント

・過去の判例からITプロジェクトにおけるユーザーとベンダーの責任を解説
・ワン オブ ゼムにならないために「踏み込んで意見を言えるか」が重要
・技術者がやってよいこと・悪いことなど、派遣スタッフからの質問を一部紹介


【講 師】細川義洋さん
▲【講 師】細川義洋さん
NECソフト、日本アイ・ビー・エムでエンジニアやコンサルタントとして活躍した後、日本国内にも数十名しかいない「IT事件担当の民事調停委員」に推薦され着任。2017年春まで数多くのIT紛争事件の解決に寄与してきた。『成功するシステム開発は裁判で学べ!』(技術評論社)ほか、著書多数。

「できない」と伝えるのはベンダーの義務

最初に紹介された事例は、ユーザーサイドとベンダーサイドの責任について。システム開発分野では有名な判決事例だそうです。

f:id:itstaffing:20180222152628j:plain
東京地裁で公開されている判例からユーザーとベンダーの責任についてよく分かる事例を採り上げて紹介。

ある健康保険組合のシステム開発で、2億5千万円規模の案件だったが、開発が進んでいくうちにユーザーから「画面を変えて欲しい」「登録機能を頼んだけれど編集機能も追加してほしい」など、後から次々と新たな要望が出されました。結果として、開発期限を過ぎても完成せず、ユーザーが代金の返却と損害賠償を請求したとのこと。

「さて、この裁判はユーザーとベンダーのどちらが勝訴したでしょう?」と細川さんが参加者に問いかけると、会場内ではユーザー勝訴が1名、ベンダー勝訴が多数を占めた。

しかし、実際の裁判結果は「ユーザー勝訴」でした。「なぜ?」という参加者の疑問に、細川さんが次のようにわかりやすく解説されました。

「ベンダーはシステム開発の工程をよく知る、いわば玄人です。(システム開発工程の)素人であるユーザーが、いろいろ要望を出してきたら、玄人は『それはできません。この工期と費用では難しい』とあらかじめ伝える義務があります。これを怠った場合、プロジェクト管理義務違反となりベンダーが責任を果たしていないことになります」(細川さん)

f:id:itstaffing:20180222152631j:plain
▲裁判での難しい専門用語はわかりやすい言葉に置き換えて説明してくださるので、参加者にも、とてもわかりやすい。

「できません」と言うのは、権利でなく義務だと認識することが重要だそうです。

また、その反対の事例として、ユーザーの協力義務違反となる事例も紹介。ユーザーも「技術のことはわからないから」の一点張りでは通用せず、わからなければ、人を雇ってでも、既存システムについての調査をして、ベンダーに協力しなければなりません。企業の情報システム部で仕事をする人は、こうした点にも注意が必要です。

大切なのは要件の実現ではなく目的の達成

エンジニアが、いくらでも代えの利くワン オブ ゼムにならずオンリーワンの存在になるにはどうすればよいのでしょうか。そんなヒントも裁判から見えてきます。

近年では、分野によってアジャイルやそれに準ずる開発手法が普及しはじめています。しかし、細川さんによれば、アジャイル開発を進める多くの企業が「外部スタッフにはなかなか頼めない」と悩んでいるそう。というのも「この仕様おかしくないですか? 本当にこれでいいんですか?」と言える人でないとアジャイル開発を任せるのは難しく、外部スタッフだと、そこまで踏み込んでくれる人がなかなか見つからないというのが理由のようです。

その典型例が、旅行会社の航空券予約・決済システムの開発事例で、完成したシステムにPC上からサーバ上のデータベースを操作する「遠隔操作機能」が実装されていなかったため、訴訟に発展したケースです。

f:id:itstaffing:20180222152634j:plain
▲要件定義の内容に疑問を持ち声に出していくエンジニアがワン オブ ゼムにならずに生き残れる。そんな教訓になる事例。

この事例は、ユーザーの勝訴でした。ユーザーによる検収も済んでいるので、ユーザー勝訴の結果に疑問を持つかもしれませんが、細川さんによれば「裁判では検収は重要ではない」とのこと。要件定義書に書かれていなくても、業務に必要なものとして判断されればベンダーの責任になることがあるそうです。

遠隔操作は、旅行業のシステムでは半ば常識とされる機能で、実はこのケース、ベンダーが「自分たちは旅行業のことをよく分かっているから」と売り込んできたという経緯がありました。もし、そのベンダーが本当に旅行業をよく分かっているのならば「要件に遠隔操作機能が盛り込まれていませんが、本当にこれでいいのでしょうか?」と言う必要があったのです。

f:id:itstaffing:20180222152637j:plain
▲時折、自身のエンジニア時代の体験なども織り交ぜながらの講演は、エンジニアにとっても親しみやすい。

「大切なのは、要件を実現することより、契約目的を達成することです。要件にこだわる人は、仕様書に書かれた以上のものは作れません。しかし、開発の目的が分かって開発をする人は、ユーザーにとっても心強い存在。ワン オブ ゼムにならずに、生き残っていけるはずです」(細川さん)

不快であることを、まずは周囲に認識させる!

最後に技術者がやってよいことと、悪いことについて紹介してくれました。

前の勤務先からソースコードを無断で持ち出した例は、もちろんエンジニアの敗訴。しかも知的所有権がからむ刑事訴訟なので結果は重く受け止める必要があります。参加者からの「ソースコードそのものではなく、自分の頭の中にあるアルゴリズムを次の会社で使うのはどうか?」との質問に、細川さんは「厳密にはアウトですが、頭の中を調べることはできないので、厳密に運用することはできないのが実情」とグレーゾーンであるとの見解を示しました。

f:id:itstaffing:20180222152641j:plain
▲調停員として数々の裁判事例に目を通してきた細川さんに質問できる機会は、そうそうないため、参加者からは数多くの質問が寄せられた。

また、エンジニアが自分の身を守るため、過労死に関する訴訟についても紹介。派遣先と派遣元のどちらにも「安全配慮義務」というものがあり、エンジニアに精神的あるいは肉体的に過度な負担があると認識している場合は、負担軽減措置をとらなければなりません。

「もし就業先で精神的・肉体的に過度に不快ならば、それを周囲に認識させるということが大切です。『それぐらい我慢しろ』と言われるかもしれませんが、言って損はありません」(細川さん)

訴訟という、普段は馴染みのない世界にも、エンジニアが生き残っていくためのヒントが数多くあるということが新鮮な体験でした。