ＩT紛争と要件定義(1)

前回は、ＩＴ紛争が、大体どのような様相のものであるかをお話しました。紛争なのですから、当たり前と言えば、当たり前なのですが、ＩＴと言うデジタルな世界の話にしては、随分と泥臭く、しかも曖昧な世界だと感じた読者の方も多かったでしょう。実際、私もこの業界に２０年以上いますが、如何に技術が進歩して、開発が自動化しても、結局最後は、人間のやることだな、と感じることが多々あります。紛争の元は、結局、「言った言わない」、「認識のずれや誤解」など、実に人間らしいものであることが殆どです。 　さて、今回からは、このブログの本筋である「ＩＴ紛争を防ぐポイントと紛争になったときに訴求すべきこと」について順次、お話していきたいと思います。事実上の初回である今回は、おそらくＩＴ紛争でもっとも大きな話題になる「システムの要件定義」についてのお話です。とは言え、この部分については、本当に多くの話題があり、一回では、とてもお話しきれません。今回は、まず、ＩＴ開発における「要件定義」が追加される祭の危険についてお話ししたいと思います。少し、話が長くなるかもしれませんが、紛争の回避と解決のため、非常に重要な部分でもあるので、ご容赦ください。 　要件というのは、簡単に言うと、システムにどのような機能や性能を持たせるかを決めたものです。人によってこれを「要求」と言うこともありますが、ここでは、とりあえず、「要件」としておきます。実は、この要件定義に関わる問題が、紛争の元になる場合が大変多いのが現実です。 　私自身も経験がありますが、ユーザー側と要件を打ち合わせを重ねるうちに、あるいは、要件を定義した後、後続工程を行っているときに、いつの間にかこの要件が変わったり、増えていってしまうことがあります。ユーザー部門が、顧客情報を簡単に引き出せるデータベースを構築しようとしたとき、本来は、現状管理している顧客情報の項目だけをデータベース化すれば済む筈だったのに、「もっとこんな情報も欲しい、あんな分析もしたい」と新たな情報収集や分析機能を盛り込むように、段々と要件が増えていったり、変わったりしてしまう、といったことが、ＩＴ開発では良くあります。まあ、それでも、多少の無理をしつつ、本来の目的自体は達成し、且つ追加要件も実現できれば、とりあえずＯＫなのですが、例えば、費用面の問題で、プロジェクトが破綻し、紛争にまで持ち込まれると、この辺りは、大きな問題になってきます。ユーザーである発注者側は、「当初、約束した費用の数倍を請求された、払わなければ、今後の開発を止めると言われ、仕方なく払う約束をさせられ、一部は、既に支払ってしまった。」と訴え、開発者である受注者側は、「当初の目的とは異なる数多くの機能の追加を強要された。”お客様”であるユーザーサイドから言われれば、受け入れざるを得なかった。請求した費用も大幅に減額したもので、要員確保の為にどうしても必要な部分だけである。開発を継続できないと言ったのは、脅しではなく、現実的に要員がいなければ作りたくても作れない、と言う意味である。」と訴えるような争いになってしまいま す。 　IＴ開発においては、通常、要件定義は、発注者側の責任においてなされます。実際に手を動かして「要件定義書」を作成するのが、ベンダーだったとしても、その内容については、発注者側が責任を持つべきとの考えです。家を建てるときに、間取りや外観を設計者が提案したとしても、最終的に決定するのが、施主であるとの似ています。 　上に書いたようなことも、結局は、発注者側が、目的に外れた要件を次々と定義してしまったが為に、こうしたことが起きてしまったと言えます。では、こうした場合、発注者だけが専ら責任を問われるのかと言えば、そうでもないケースが多いようです。 　これを先ほどの建築に当てはめて考えると、どうなるでしょうか。当初の決まっていた間取りから、「部屋を増やしてほしい」「やっぱり、窓は南側にも欲しい」と、次々に要望が変化して、結局、完成が大幅に遅れたとしても、設計者や建築会社に責任を負わせるでしょうか？このあたりが、ＩTの特殊なところです。 　だとすれば、上述のような争いも結局のところ、発注者側の要件定義が不十分であったが為に起きたことであり、その責任を負うべき、とも考えられます。しかしながら、ＩT開発の場合、そう単純には、割り切れません。情報システムの要件と言うものは、非常に専門的で且つ複雑なものだからです。 　例えば、ＡＫＢ４８のコンサートチケット予約システムを作るとします。今をときめく人気者のコンサートですから、インターネットや販売店からの予約は、開始時刻から数分で数万件、数十万件に達するでしょう。当初の要件は、「予約依頼を受け付ける」、「希望座席タイプlを検索する」、「座席があったら予約する」と言ったことが挙げられるでしょう。当初の要件定義は、これで一旦、落ち着きました。しかし、開発中に、例えば、「ファンクラブ会員には、予め優先席を設けておく」、「予約内容の変更もすぐに行える」と言った追加要件が発生したとします。 　発注者であるコンサート主催者からすると、この要件追加は当然のことかもしれません。しかし、これだけの数を一気に処理する中で、「ファンクラブ特別対応」や「予約変更」処理をかませるのは、プログラムの複雑化、処理性能の劣化等の危険があります。(詳しく解説していると、このブログのタイトルを変えなければならないので、ここでは、技術解説はしませんが、この手の変更は、場合によって、ハードウェアの交換までに及び大改修に発展する危険があります。) 確かに、やればできることですが、工数やスケジュールには、かなり影響が出ます。しかしながら、この難しさを発注者は、理解できません。これを理解し、影響を説明できるのは、開発者側だけです。開発者側は、これによる危険や工数増、スケジュールについて発注者に説明し、「それでもやるのか？」と正す必要がある訳です。こうした確認を怠って、プロジェクトが破綻し、紛争まで発展した場合、開発者は、こうした確認を行ったこと、それでもやってくれと言われたこと、費用やスケジュールについてのやりとりがどうであったか、といったあたりをしっかりと訴えることが必要だと考えられます。 　もしも、これをしっかり訴求できないのであれば、紛争においては、ここを「弱み」と捉えて、別の戦略が必要になるのかもしれませんね。(この辺りは、弁護士でもない私が言うべきことでは、ありませんが。。) 　と言う訳で、例え、発注者側の責任とされる「要件定義」の分野でも、開発者側にそれなりの責任が発生することをお話ししました。しかし、上述の例は、あくまで、当初の要件が、ある程度の完全さを持っていることが前提です。数十万件のチケット予約をすると言うことが、何はともあれ、実現できる機能、性能等を具備しており、とりあえず、作り始められる、こんな要件が必要でしょう。しかし、実際のシステム作りでは、当初から、要件を網羅的且つ完全に定義することは困難です。「この追加要件は、本来必要なものであり、これがなければシステム自体、用をなさない。」と言ったことがよくあります。そうした要件は、いくら後から持って来られたとしても、やらない訳にはいきませんし、これを理由に開発者側が追加費用やスケジュール変更を申し出ても、合意することは困難でしょう。開発者側からみれば、なんだか「押し切られた」ように感じるかもしれませんが、発注者側から見れば、「当然に必要なこと」です。つまり、追加要件にも「当初、想定できなかった新しいもの」と「当初から決めておくべきだったヌケ」があることになります。 　この「当然に必要なこと」と「当初、想定できなかった新しいもの」は、どう切り分けるのでしょうか、そもそも「当然に必要なこと」を漏れなく定義するには、どうするのでしょうか。なかなか難しい問題で、私にも確かな答えは、ありませんが、一つ重要なヒントとして挙げられるのが、「システム化の目的」です。システムには、構築する目的があり、開発の最初にこれが定義されます。「対象業務にかかっているコストを３０％下げる」とか、「顧客情報を共有化して、営業職員の作業を効率化する」など、システムを構築するにあたっては、こうした目的とかかるコストを比べて、決済することが通常です。上述の例で言えば、「大量のチケット予約処理を自動化して、これに掛かる経費を減らす」と言ったところでしょう。そして、この「システム化の目的」には、多くの場合前提条件もつきます。「ファンクラブの予約は、一般客より優先する」と言ったルールがこれにあたるでしょう。 　この目的と前提条件が大きなキーになります。システムで当初から定めるべき要件は、この目的と前提条件に結びつくものであり、この要件がなければ、それらが達成できないものです。一方これらに結びつかない「予約変更」には「？」マークがつきます。変更は、別のシステムや電話応対で別途行うことも可能だからです。あるいは、予約受付の広告に「予約したチケットの変更は受け付けません」と書くだけですむものかも知れません。こうした色分けを誤ると、結局「役にたたないシステムを作って、追加費用まで請求された！」「いや、言われたものは作った。追加は、追加なのだから、費用は当然請求する」と言う争いに陥ります。 　こうした争いを未然に防ぐには、「この要件は、目的と前提条件に基づいたものか」、「この目的と前提を満たすには、この要件で十分か」を常に反復して、検証しておくことが必要になります。また、紛争時には、要件が、本来必要であるものであるか、否か、もし、不要であるとするなら、それでも実装すべき事情について、双方の合意があったかなかったかを訴求する事が、大切という訳です。

調停時に必要な主張(6)

東日本大震災の復旧、復興、なかなか進んでいないようですね。私も当初は、「政治家や官僚は何をやっているんだ、東京電力は、既得権を守ることしか考えないのか。」などと、他人の責任ばかり考えていましたが、最近は、自分自身の責任について考えるようになりました。政治家や官僚、東京電力は、案外、国民の関心や動向に敏感な気がします。国民が震災に関心をなくせば、これらの人々は当然にそちらに目が行かなくなります。被災地へ支援に向かう人の数、義援金の多寡、マスコミに取り上げられる回数、こうしたものが、これらの人々に対する無言のメッセージあるいは圧力になり、熱心さを引き出すのではないかと思います。
今よりも、もっと多くの人々が被災地を訪れたり、復旧、復興の様々なキャンペーンに参加して、大きなムーブメントを起こすことが、今こそ必要なことではないでしょうか。しかしながら、自分は何もしていない。毎日普通に会社へ行き、普通に電気を使っている、それどころか、被害者意識さえもっている。これでは、政治家や官僚、東京電力を責めることは、できないのではないかと、少し反省しているこの頃です。復旧、復興への協力は、善意ではなく国民の責任ではないかと、少し極端なことも考えたりしています。

今回も「請負契約」における「調停時に必要な主張」について、お話しようと思います。今更の復習ですが、「請負契約」は、「準委任契約」とは異なり、完成した成果物に対して、開発者が責任を持つ形態です。システムをどのように作ったかはさておき、結果として発注者と受注者が約束した通りのものができていれば、良い訳です。
ITの場合、「請負」の範囲は、よく開発の工程を元に決められます。システムがどのように動作し、どのような性能を持つべきかを決める「要件定義(要求定義)」は、準委任で行い、以降の設計・製造・テストを「請負」で行う。発注者は、開発者から受け渡されたシステムに対して受入試験を行い、当初定義した「要件」を満たしていることを確認して検収を行うというタイプが比較的多いようですが、設計の一部あるいは、全てを発注者が行って、開発とテストの一部を開発者が行うことも、よく見られます。
いずれにせよ、発注者と受注者の責任は、どこかに線引きがあるわけですが、要件定義を発注者の責任とする線引きを行った場合、少し注意すべきことがあります。「要件定義における専門家の責任」についてです。この問題は、ソフトウェアやシステムの開発に係わる紛争における調停では、本当に良く出てくる話題で、私自身も調停において、毎回のようにお話させていただいていることで、ITの専門家調停委員の間でも比較的支配的かと思われる考え方です。

「要件」あるいは「要求」と言うのは、開発したシステムやソフトウェアが具備すべき機能や性能、使い勝手や安全性等をユーザー側である発注者が開発者である受注者に提示し、話し合って合意するもので、開発の見積もりや契約に影響する大切なものです。これがないことには、システムやソフトウェアを作りようがありません。
家の建築で例えれば、施主が設計者、建築家と取り決める間取りや窓、ドアの数、内装や外壁の素材、耐震性、防火性、防犯性についての要求と言ったところでしょうか。設計者や建築家は、この要求を満たすべく設計、建築を行うのと同じようにシステムやソフトウェアの開発者は、この「要件」、「要求」を元に開発を実施し、これを満たすことが、検収の条件となるものです。
システムやソフトウェアの「要件」は、どのような情報をどのように入力したらどのような結果がでるかと言った機能要件、処理の速度や処理できる容量を定める性能要件、障害発生時の復旧時間や業務の継続性について定める信頼性要件等々多くのものがあり、情報システムのユーザーが組織する「日本情報システム・ユーザー協会(JUAS)では、以下のような分類をしています。

　・システムの信頼性/使用性/効率性/保守性/移植性/障害抑制性/効果性/運用性/技術要件/機能性

要件の分類や定義について詳しくお知りになりたい方は、上述のJUASや独立行政法人 情報処理推進機構(IPA)のソフトウェアエンジニアリングセンター(SEC)のホームページなどをご覧いただければ、と思いますが、このブログを読んでいただく上では、これらについて理解していただく必要はありません。ただ、「こんなのプロじゃなきゃ分かるわけない」と感じていただければ、結構です。
さて、契約が「設計以降を請負」とする一般的な形態である場合、要件定義の責任は、発注者側にあります。どのようなものを作って欲しいかを明示してくれなければ、作り手はなにもできません。経済産業省の外郭団体であり、有名な「共通フレーム2007」を刊行している情報処理推進機構では、要件以外にも例えば、画面設計や帳票設計のようなユーザーインターフェースについてもユーザー側が責任を持つべきとの考えがあるようです。
しかし、よくよく考えてみると、これは、ユーザーにとって、随分と酷な話です。例え、パソコンの操作も覚束ないユーザーでも、システムを新たに構築したいと考えれば、上述のような難しい言葉をすべて理解した上で、漏れなく、矛盾なく定義する責任があるというのです。これでは、独自にIT専門部隊を持たないユーザー企業や団体は、事実上システム導入ができないことになってしまいます。

実際の調停においても、例(実例をもとにした架空の例です)があります。
一般顧客から書類で寄せられるサービス申し込みをどうしても書類受け取りの翌日正午までに、入力完了する必要があるユーザー企業が、これを実現するためにクライアントPCに付属のスキャナから書類のイメージを入力し、OCR処理をしてサーバに登録するシステムの開発に着手しました。サービス申し込みは、1日に千件以上寄せられ、OCR処理したデータは、一件毎にオペレーターが確認・修正しながら入力していくわけですから、PCの台数もそれなりに必要です。
このシステムには、モデルとなった他のシステムが他部門にあり、オペレーションや業務量も似通っていたことから、PCの台数は、10台と決められ、開発が進められました。しかし、実際にユーザー受け入れテストをしてみると、業務は、期待されていた時間の3倍かかり、計算上、正午に終了する筈が、15:00を超えることになってしまいました。これでは、業務に使えません。
ソフトウェアのつくりやハードウェアの性能には、大きな問題はありませんでした。問題はオペレーターの操作速度です。モデルとした他部門のシステムと比べて、入力項目も多く、また、内容も単なる誤字修正だけではなく、入力項目同士の相関チェックを目検で行う部分もあったため、登録に多くの時間を要することとなっていたのです。これらをこなすのには、オペレーターが相当の速度を持って入力を行う必要がありますが、この場合のオペレーターは、特別に早い操作能力を持っている人たちでは、ありませんでした。
要件定義書には、この部分の性能を単に「正午までに業務が終了すること」とのみ記されており、オペレーターの操作速度等の前提が置かれていません。ユーザー側は「要件を満たしていない」と主張し、開発者側は、「オペレーターの操作能力は、開発者の責任ではない。」と主張しています。
この場合、確かに「正午までに業務を終わらせる」ためのオペレーターを揃えることは、ユーザー側の責任だったのかも知れません。しかし、ユーザー側は、ITの素人で、画面の複雑さとオペレーターのスキル、処理時間の関連を正確には捉えられていませんでした。こんなに習熟したオペレーターが必要なら何故、言ってくれなかったのか、との主張も分かります。一方、開発者側は、予算やスケジュールを考えると、ソフトウェア、ハードウェア共にこれがベストの選択であったことは、ユーザー側も承知の筈、と主張しています。習熟したオペレーターの獲得の困難さと予算、スケジュールの制限を比べて検討することが欠けていました。
調停では、これを双方の責任としました。原則として、要件定義はユーザー側の責任です。要件を正午までに、終わらせるためには、一件当たり処理時間は何分までに抑える必要があり、その前提条件としてオペレーターの習熟度を定めることもユーザー側には、必要でした。しかし一方で、開発者側も専門家として、要件定義では、何を定め、何を前提条件、制約条件として置いておかなければならないかをユーザー側に説明するべきで、オペレーターの習熟度を考慮に入れることも当然”ガイド”すべきだったのではないか、との説明を行い、両者の納得を得ることができました。「要件定義を行う責任は、ユーザー側にあるが、ベンダー側は、何を定義すべきかを漏れなくガイドする必要がある。」と言うのが、基本的な考えです。
従って、こうした紛争の場合、単に完成したシステムが定義された要件を満たしているか、だけでなく、要件そのものが十分であったか、それを定義するために双方が相応の責任を果たしたかを主張することが、必要になると考えます。上述のような要件の切り口をもとに、ITの専門家である開発者が、漏れなく矛盾のないガイドを行ったか、発注者は、そのガイドに従って、要件を定義していったか、が双方の主張のしどころということになります。
無論、こうしたガイドの責任も「常識」で考えられる範囲にとどまることは、言うまでもありません。まだ、世に知られていないコンピューターウィルスやクラッキングに対するセキュリティ要件についてガイドを行わなかったとしても、それは致し方のないところです。そのあたりは、常識による判断ということになるでしょう。

ITシステムの開発は、受注者と発注者の協力なしには、成功しません。不幸にして紛争になる開発は、大概、この協力が不足しています。調停に臨む上では、双方の責任はなんであったか、それを双方が果たしたかを軸に見ていくと、ある程度納得感のある結論が得られるかと思います。

調停時に必要な主張(5)

夏の甲子園の地区予選が真っ盛りです。私は、自宅で作業することが多いので、良く作業をしながら、テレビ観戦しているのですが、高校野球の場合、プロ野球のように一人で決めきるバッターは少なく、得点は、やはり、打線のつながりで挙げるケースが多いですね。ランナーが出る→バンドで送る→進塁打で３塁へ進んだランナーを単打で返す。プロなら、１人ランナーが出れば、誰かが長打で返してくれるだろうと期待する作戦も多いのでしょうが、個の力よりチームみんなで取りに行く高校野球には、「つながり」の大切さを感じることがしばしばです。(ラミちゃん、アベちゃんがホームランを打たないと、途端に勝率の下がるどこかのチームも少しは、見習っていただきたい。)

と、言うわけで、今回は、「つながり」をキーワードにお話をしたいと思います。「請負」に関する調停時に必要な主張の続きとして、設計以降のフェーズを委託した(請け負った)場合のお話ですが、こちらの方は、高校野球よりずっと厳密に「要件」と「設計」あるいは「テスト」のつながりを確認すべき、と言った内容です。

さて、発注者者が開発者に対して、要件を提示し、設計工程からテストまでを委託したが、できあがったシステムに不備があったといったケースの場合、どこをどう主張するといったことの前に、双方が合意する必要がある事柄があります。それは、紛争中のシステム開発において、「どこまでが、要件定義(要求仕様)で、どこからが、設計であるか」と言うことです。これについて、共通の認識を持っておかないと、調停は争点のずれたものとなってしまいます。このあたりについても、今までお話してきた様々なことと同様に「IT業界独特のいい加減さ」があるところで、要件定義と設計の区分を明確にできる人は、少ないのではないでしょうか。実際のところ、要件定義と設計は、各開発プロジェクトで定義されるのが、通常で、客観的なガイドはあっても、明確な基準はありません。
例えば、システムの画面イメージについてですが、以前にお話しした共通フレーム２００７によれば、外部設計に位置づけられます。しかし、実際には、ユーザーが要件を定義する場合に画面をかなり詳しく設計してしまう場合もあり、画面設計＝外部設計と決めつけるわけにはいきません。このシステム開発の要件定義とは何であったか、外部設計とは何かを、先ず明らかにして調停に入る必要があります。

さて、この辺りの合意が済んだところで本論です。設計以降を委託した(請け負った)場合にまず、インプットとなる要件定義が、正しいことあるいは、不備であることを確認することが必要です。要件の定義に責任を持つ側である委託元は、その要件に網羅性があり、且つ正しいことを主張することになります。こう書けば、当たり前のことのように思えますが、よくある例として、要件より前のシステム導入の目的と完成したシステムを比較して、「設計以降を委託したが、作ったシステムがそもそものシステム化の目的を達成できるものではない。目的を達成しない以上、費用の支払いはできない。」との主張を目にしますが、これは、ほとんどの場合、無効な主張となります。設計以降を請け負った開発側が責任を負うべきは、あくまで、「要件」に対してであり、システム化の目的を達成するか否かは、その範囲外です。(但し、以前に書いた要件定義における専門家の責任を開発者側が十分に果たさなかった場合は、少し話が違ってきますが)

では、要件が正しいことを明らかにするには、何を論拠にすべきでしょうか。要件定義書は、当然ですが、それだけではありません。開発中に発生した要件の変更について、合意した文書や議事録などもその証明になります。また、一切文書に残っていなくとも、「いまどきの常識であり、わざわざ記述する必要のないもの」も要件と考えられます。インターネット接続をするシステムにおけるセキュリティや画面の非常識な操作性などは、開発者側が言われなくてもシステムに具備すべき要件です。
一方、開発者側は、要件に網羅性不足や不備があり、それが、瑕疵等の原因になっていると説明できるのであれば、その辺りを主張すべきでしょう。つくると約束していない機能を作っていないと主張されている。性能面における目安値を盾に「性能要件を満たしていない」との主張されている、等に対する防御としては、このあたりの不足や不備を主張することが必要だと思います。

さて、要件が正しいことが確認されたら、次は、要件定義書と設計書の整合性についてです。要件として提示した内容が、設計書のどこに書かれているか、それが妥当であるかを確認することになります。この場合少し難しいのは、申立人が、委託元である場合、要件定義書と設計書の不整合を説明することが困難であることです。何せコンピュータシステムの設計書ですから、素人が、的確にこれらを読み解くのは、至難の業です。勿論、別途、専門家に見てもらって、このあたりを指摘する手もありますが、手っ取り早いのは、テスト結果を見ることです。システムを構築する場合、その納入前には、「要件」がすべて満たされているかを確認する「受け入れテスト」や「システムテスト」が行われます。これらのテスト仕様やケースは、委託元が理解し、合意した「要件定義書」に基づいて作成されていますので、委託元もこのテスト結果が要件に対して妥当な結果を示しているかを確認できるはずです。因みに、もしこうしたテストが実施されていなければ、こちらの方が問題で、そもそも、「ものづくりを途中で止めている」と言うことになり、開発者側の不利は、否めません。仮に、委託元が、「テスト不要」と言った場合でも、専門家として、開発者側の非は、ゼロには、ならないと考えた方が良いと思います。

　一方で、開発者側は、要件に対して、設計に網羅性があり、正しく妥当であることを主張することが必要になりますが、無論、これもテスト仕様とその結果で、その正しさを主張することも可能かと思います。

設計以降を請け負った場合については、まだまだ、たくさんお話すべきことがありますが、長くなるので、今回は、この辺で終わりにしたいと思います。

調停時に必要な主張(4)

刑事コロンボのピーターフォークさんが、亡くなりました。小学校の頃、毎週土曜日の夜、楽しみに見ていたのを思い出します。若い人は知らないかもしれませんが、このドラマが放映されて以来、日本でも刑事ドラマがブームになり、「太陽に吠えろ」等いろいろな番組が始まりました。随分あとになってからですが、「古畑任三郎」もドラマの構成が、コロンボそっくりです。最初から、犯人が分かっている刑事物にもかかわらず、あんなに楽しめたのは、ほんの小さな手がかりを見逃さず、推理を積み上げていくパズルのような魅力があったからかも知れません。細かいことを見逃さない目というのは大切です。
本日は、「請負契約」のITシステム開発において、最も細かい目が必要とされる「開発」と「単体テスト」のお話です。もっとも、この部分は、「請負」であれ「準委任」であれほぼ、開発者に任されている部分ですが、一応「請負」を前提にお話します。

前回お話しした通り、「開発」とは、設計書に従って、プログラムを実際に書いていくプログラミングという作業が中心です。プログラミングは、別名、コーディングとも呼ばれます。プログラミングとコーディングは厳密には異なる物と言えますが、訴訟や調停の場では、同じ意味に捉えてもそれほど支障はないと思います。そして、記述したプログラムがとりあえず、それ単体でうまく動くかを確認するのが「単体テスト」です。作業の性質から言って、プログラミングと単体テストは、繰り返し実施されますので、この２つは、必ずと言っていいほど、セットで行うことになります。

さて、「開発」と「単体テスト」を委任した場合、「約束した仕事」とは、どのようなものでしょうか。言うまでもなく、設計書に書かれた内容を正しく解釈し、設計書通りに動作するプログラムを作ることで、検収の要件である成果物は、「プログラム」とそのプログラムが正しく作れた証跡である「単体テスト結果」になります。従って、もしも発注者が、「約束した仕事を行っていない」と主張する場合、明らかにすべき事は、設計書とプログラムが整合していないこと、設計書どおりに正しく作られていないことであり、「約束した仕事を行った」と主張する受注者は、その逆を明らかにすべき、となります。
しかしながら、訴訟や調停の場で、作成したプログラムが設計書どおりである(ない)ことを証明するのは、なかなか困難な作業です。コンピューターのプログラムは、１本に数十行から数千行に及ぶプログラミング言語の羅列であり、コンピューターの技術者であっても、プログラム自体を読んで、その構造や意味合いを正しく理解するのには、相当の時間を要します。まして、これを日本語で書かれた設計書と見比べて、「確かにこの通り掛かれている」と断じるのは、かなり困難です。
そこで、着目すべきは、単体テストケースとその結果です。単体テストケースは、プログラムが設計書通りであることを確認するポイントが全て、網羅され、正しく書かれているべきものです。テストケースが詳細設計書と整合しており、全てのポイントについて、「合格」していることを示せれば、「約束した仕事」を完了した、と主張することができ、委託元は、そのどこかに不備があることを示せれば、「約束した仕事」を完了していない、と主張することができます。そして、単体テストケース自体が詳細設計書と整合して、漏れがないことも主張すべき点となります。
ただし、単体テストの場合、きちんとしたドキュメントを残していない場合もあります。この場合は、テスト中のメモ書きでもホワイトボードの写しでも、兎に角、単体テストケースとその結果が書かれているものを証跡として出すことで、双方の主張を裏付けられます。口頭で、「やった」、「やらない」と言い争うよりは、余程効率的です。
ところで、開発や単体テストを始めるにあたって、において、そもそも提示された設計書が不備だった場合はどうでしょうか。いくら正しくテストケースを設定しても、その元である設計書が間違っていたり、網羅性がなかったり、あるいは、曖昧で誤解を招くような記述があったらどうでしょうか。例えば、建築などの場合は、その落ち度は、設計者のみにあると考えるのかもしれません。しかし、ITの調停では、そんなにあっさりとは、決められません。ITでは、設計者が当初書いた設計書には、何らかの問題があることが日常茶飯事です。ITの開発者であれば、当初受け取った設計書を、ただ、盲信してプログラミングしたり、テストケースを作ることが危険であることは、容易に予測できます。
例えば、設計書に「この画面で数字の1が押されたらどうする、2が押されたらどうする」との記述があるが、それ以外のキーが押された場合の処理がない場合、これを妄信して、1の処理、２の処理のみをプログラミングすれば、それ以外のキーが押されたとき、システムは、予期しない動作をします。設計者にプログラミング経験が少ない場合、こうしたことが起き得ます。この場合、その不備を指摘し、修正を依頼できるのは、プログラマーと言う事になりますし、このように、ある意味常識的なことを注意しなかったプログラマーには、不具合の責任の一端くらいは、負うべきかと考えられます。
前にも書きましたが、システム作りは協業です。双方が持てる専門性をきちんと発揮することも「約束した仕事」の重要なファクターであると、私は考えています。

調停時に必要な主張(3)

ぐぐっと暑くなりました。雨も降るので、梅雨明けはまだかと思いますが、もう、海に行ってしまいたいくらいの陽気ですね。私の本職は、ITコンサルタントとかITプロセスコンサルタントとか呼ばれる仕事で、会社はフリーオフィス。自宅で仕事をすることもＯＫと言う恵まれた環境ですが、ここのところは、暑くて、家にはいられず、近所のドトールやスタバに入り浸っています。ところが、最近は、同じようなことを考えるサラリーマンが、増えてきてか、その手のお店が混んできました。悪い時間に行くと、席は満席に近く、なんとなく温度が上がっているようです。おまけに、エアコンも温度設定が、控えめで、折角、涼を求めてお店に入っても、期待を裏切られることがしばしばです。期待が大きければ大きいほど、それが達成されなかったときの失望感は、大きいものですね。

と言うわけで、今回からは、不幸にして期待が裏切られた「請負契約」についてお話したいと思います。「契約通りにモノを作ってくれなかった」、「いや、ちゃんと作った」と主張するために有効と思われる観点について、お話しようと思うのですが、今回は、その前提知識として、情報システムの開発工程について、簡単に説明しようと思います。
IT関連のお仕事をされている方には、当たり前すぎる内容なのですが、この後の説明をITの専門家以外の方にご理解いただくためには、やはり必要かと思い書く事にしました。

さて、一口にITの開発工程と言っても、大規模システム開発によく使われる古典的なウォーターフォールや小規模な開発によく使われるアジャイル、最初に大まかな機能を作り込んで、徐々に詳細化していくスパイラル、ユーザーに出来上がりの画面や帳票を見せながら開発していくプロトタイプなど、種類は様々です。ただ、今回は、開発の基本として、広く知られるウォーターフォールについて、情報処理推進機構のソフトウェアエンジニアリングセンターが発行している「共通フレーム2007」を参考にお話ししたいと思います。他の開発手法については、また別途触れたいと思いますが、IT訴訟において、一番問題となる「要件定義」については、共通する部分も多いと思いますので、ご参考にしていただければと思います。
ウォーターフォールにおける開発工程は、大体以下のように定義されます。

① 企画・構想
② 要件定義
③ 外部設計
④ 内部設計
⑤ 開発(製造)
⑥ 単体テスト
⑦ 統合(結合)テスト
⑧ システムテスト
⑨ 運用テスト
⑩ 受け入れテスト

各工程では、概ね、以下の作業が行われます。

①企画・構想
ユーザー企業が、自身の業務の問題点と解決策を明らかにし、その中で、どのような部分をシステム化するかを企画する工程です。この工程は、通常ユーザー企業内部で行われるため、訴訟や調停で問題になることはあまりありません。

②要件定義(要求定義)
ITシステムやソフトウェアが備えるべき機能や性能、実現にあたっての制約事項・前提条件等を明らかにする工程です。この工程は、ITの訴訟や調停において、問題となることが多い部分ですので、もう少し詳細に説明しましょう。
要件定義は、大きく分けて、「業務要件定義」と「システム要件定義」に分けられ、「業務要件」を先に定義して、それを元に「システム要件」を定義します。

1) 業務要件定義
システム化の対象となる業務を明らかにし、誰がどのような業務をいつ行うか、その業務の制限時間は、どうか、その他制約事項はないか、と言ったことを定めます。例えば、企業の「給与算出業務」に必要な業務を、

・ 社員は、自身の勤怠を申請する勤怠申請業務
・ 社員の上司が、申請された勤怠情報を確認し、承認する勤怠承認機能
・ 給与計算者が、承認された勤怠情報を元に給与を計算する給与計算機能
・ 給与課長と人事部長が、計算結果を確認して承認する給与承認機能

と言った具合に定義し、更にそれを細分化していきます。「勤怠申請機能」であれば、社員が申請する項目は、何であるか、自身で計算するべき項目があれば、それは、どのようなものか、申請する様式は、どのようなものか、と言ったことを定義しておきます。要するに、業務の順に従って、「誰が、いつ、何をして、何を出すか」と言った点を明らかにしていく訳です。

一方で、この申請には、いくつかの前提条件や制約条件があることも明らかにしていく必要があります。時間的な制約や操作者のスキル、他業務との前後関係等、業務を行う上で考慮に入れておくべき事柄で、「入力情報・業務・出力情報」だけでは、洗わせない事柄を整理していきます。「当社には、日本語と英語を母国語とする社員がいる」、「当社規定では、承認者が不在の場合、承認者の上席者が、承認を代行することとなっている」などが前提条件、「当社社員が、勤怠申請に割ける時間は、15分が限度である」等が制約事項になってくるでしょうか。

2) システム要件定義
もう一つのシステム要件定義は、業務要件定義を受けて、それをITシステムでどのように支援するか、どのような機能をシステムに具備しておくべきかを明らかにします。上の例の勤怠申請機能から考えると、「社員が勤怠情報として、出勤日、有給休暇取得日、出勤時刻、退社時刻、控除時間を記入した後、就業時間を計算して追記する」と言う業務要件は、「勤怠情報入力画面を表示する」「初期値として社員番号、社員名、入力対象月別カレンダーを表示する」、「出勤日、有給休暇取得日、出勤時刻、退社時刻、控除時間を入力できる項目を表示する」、「入力時の論理チェックはこの場合、行わない」と言った具合にシステム要件に置き換えられます。これらは、システムが持つべき機能を明らかにするという意味で「機能要件」と呼ばれます。
一方、上述の前提条件や制約条件等から、システムの処理速度や操作性、セキュリティ等を明らかにしたものを「非機能要件」と呼んで、「機能要件」と区別しています。「非機能要件」は、要件定義でも見落とされることが多く、IT紛争でよく問題になる要件です。

③外部設計(方式設計含む)
システム要件定義を元に、システムが行う入出力を明確にしていきます。入出力とは、ITシステムと外部のやりとりのことです。画面の前に座ったオペレーターが情報や命令を入力して、画面や帳票に演算結果を出力すること、ファイルやデータベースとやりとりすること、又、接続された他のシステムとやりとりすることを定義します。また、比較的大規模なシステムを構築する際、いくつかのサブシステムに分割する際には、このサブシステム間のやりとりもこの工程で設計します。
具体的には、勤怠情報入力画面のレイアウト、入力する社員番号や勤務時間、出力する計算結果等のデータ型、桁数等を設計します。ファイルやデータベース出力等についても同じです。

また、この工程では、上述のような入出力に併せて、要件をどのような実現方式で具現化するかも定義します。ＷＥＢでシステムを構築するかクラウドの機能を利用するか、データベースをどのようにするか、通信はどのように行うか、等をもれなく明らかにしていきます。順番が前後して、申し訳ありませんが、これを「方式設計」として外部設計の前段で行うこともあります。

④内部設計
外部設計がシステムの外側のみを設計するのに対して、内部設計では、内側を設計します。プログラムに記述する命令の順序を考慮しながら、詳細の処理や分岐条件等を定めていきます。

⑤開発(製造)
これは、所謂プログラミングです。この部分は、調停時に話題になることが少ないのですが、例えば、コンピューターのメモリを異常に消費してしまうようなプログラミングをしてしまうなどしてしまうと、開発者側の責任の割合が大変大きくなる部分です。

⑥単体テスト
作ったプログラムを一つずつテストしていきます。プログラム内部の命令の順序や分岐条件が、間違っていないこと、つまり、開発(製造)が内部設計どおりであることを確認します。多くの場合、単体テストは、開発とセットで繰り返し行われます。この部分も開発と同様に、開発者のみにより行われるのが通常ですから、見つけ出すべきエラーを見逃すと開発者側の責任が問われます。

⑦統合(結合)テスト
実際には、いくつかの段階に分かれて実施します。単体テストの終了したプログラム同士の連携が正しいか、プログラムの集まったサブシステムが、他のサブシステムと正しく連携しているか、ユーザインタフェースは、正しいか、外部入出力は、正しいか(外部設計書どおりか)等をテストします。

⑧システムテスト
システムがシステム要件定義書や外部設計どおりに作られているかをシステムが実際に使用されるストーリーに従って、テストします。

⑨運用テスト
基本的にシステムテストと同じような内容のテストを行う他、システムのバックアップ等、システムの保守、運用に関するテストも実施します。通常、テスターをそのシステム導入後のオペレーターや運用者が努めます。このテストには、ユーザー側も参加しますので、エラー見逃しには、発注者側の責任も問われるのが通常です。

⑩受入テスト
「請負契約」の場合、このテストの完了が、所謂「検収要件」の中心になるのが、通常です。あらかじめ準備したシステムの完了基準にしたがってテストを行いますが、基本的には、業務要件・システム要件が満たされていることを確認します。

以上が、ITシステム(ソフトウェア)開発のあらましです。専門外の方には、とっつきにくいと思いますので、今後のブログの中でも、随時、必要なことを反復、補足していきたいと思います。

調停時に必要な主張(2)

私の友人が、この度、サンフランシスコに、“かっぱえびせん”で有名なカルビーのショップをオープンしました。カルビーほどの会社が、今まで、アメリカに進出していなかったことは意外ですが、ポテチやポップコーンくらいしか、スナック菓子のないアメリカには、「Kappa Ebisen」は、新鮮かも知れません。成功してほしいものです。もし、あちらへ行かれる機会があったら、是非一度訪ねてあげてください。

さて、今回は、前回書いた「IT調停にしてほしい主張(1)の補足を書きたいと思います。前回の記述の中で、調停時にしてほしい主張として、作業者が「常識的な作業品質」を以て作業を行ったか否かを主張してほしいと書きました。そして、その中には一定の知識・経験を持った作業者が、指示された作業を遅滞なく行うことを主張してほしいと言ったことも書きました。しかし、作業自体が、きちんと行われたか、あるいは、行われなかったことをどのように示せばよいのでしょうか。これは、非常に難しい問題です。作業者が一定の知識・経験を持っている事は、業務の経歴や資格を見ればある程度、客観的に示す事ができるでしょう、遅滞のない作業や作業時間も客観的にみることができます。しかし、作業者が期待した品質を以て作業を行ったかを客観的にみるには、それらとは、別の着眼点が必要です。作業者が、そのプロジェクトにおいて、「いい加減な」仕事をして、納期だけは、間に合わせたが、成果物の品質が劣悪だった場合、この作業の仕方と成果物の品質の因果関係を直接見ることは、人や作業が複雑に絡まり合うIT開発においては非常に困難です。
そこで、作業自体の品質を見るための着眼点が必要になってきます。私自身もこの着眼点をどうするか、まだまだ研究中なのですが、自身の行った開発も含めていろいろと考えてみた結果、開発における「作業の生産性」、「欠陥除去率」、「欠陥数」が着眼点として使えるのでは、考えるようになりました。作業者が、何らかの理由で指示された作業を怠れば、生産性は落ちます。また、いい加減なもの作りやテスト、レビューを行えば、「欠陥除去率」、「欠陥数」が大きすぎたり、小さすぎたりするはずです。逆にこれらの計測値が、常識の範囲内であれば、作業自体はおおよそきちんと行われたと考えても差し支えないと、私は経験上考えています。もう少し詳しく見ていきましょう。

1.作業の生産性
IT業界では、ある程度のスキルを持った人間が、一定期間作業を行った場合の出来高について、「共通認識」のようなものがあります。立場上、「それは、これです。」と決めつけるわけには行かないのですが、一般的な論を一つだけお話しします。例えば、 COBOL言語でシステムを構築する場合、設計・開発・テストに係る工数は、1000ステップ(プログラムの行数)あたり、0.8から1.0人月程度と言う共通認識があります。開発規模が、100万ステップのシステムであれば、設計からテストまで、およそ1000人月、50人の作業者が20ヶ月程度かかる、と言った具合です。
そして、この1000人月のうち、設計・開発・テストの各工程の配分についても同じく、「共通認識」が、あります。くどいようですが、実際に、これが、どのような数値かは、立場上、申し上げられません。ただ、恐らく、当事者である技術者も大体このあたりは、分かっていると思いますし、例え当事者でなくとも、見積り経験のある技術者であれば、恐らく、常識として知っていると思います。また、ソフトウェア開発の見積り方であるファンクションポイント法を勉強すると、そのあたりは、テンプレートとして提供されている場合が多く、一つの参考基準になると思います。
もちろん、同じ規模でもプログラムの複雑さや新規性によって、数値は、変わってきますが、ファンクションポイント法では、そのあたりもちゃんと考慮した数値の出し方も決めていますので、それなりに当てになると思います。こうした方法で出した工数と実際の工数が、大体合致していること(例えば0.7倍から2倍程度の中に収まっていること)を受注者が訴えれば、一定の品質を保って作業を行ったことの論拠になりますし、逆にそれを超えるのであれば、発注者側の論拠と言えるでしょう。(ちなみに、これを下回るようであれば、もともとの見積りミスか、作業の定義に誤りがあることが、疑われます。)
こうした業界の「共通認識」葉、IPAやJUASと言った所謂、業界団体で研究が重ねられ、発表されていますので、こうした団体のホームページや刊行物を見ることは、良い勉強になります。また、ＳＡPのようなパッケージを元にしたカスタマイズ作業であれば、ベンダーに問い合わせてみるのもよいでしょう。
ただし、注意しなければいけないのは、これらはあくまで、他人の数字だと言う事です。IT開発は、受注者、発注者の体制やツールその他制約条件によって、生産性は変動します。一番のお薦めは、受注者や発注者の過去の実績です。過去の成功プロジェクトのなかから、規模や使用技術が似通ったものをできれば複数取り出し、紛争となっているプロジェクトの設計書作成、コーディング、テスト等の生産性と比べることが、もっとも妥当なモノサシになります。双方が、自身のモノサシを提示し、その妥当性を調停委員が、客観的に判断できれば、あいまいな「作業の品質」について余計な議論をせず、早期の紛争解決が、期待できます。

2.欠陥除去率
さて、もう一つの「欠陥除去率」についてです。ここで言う欠陥は 、２つに分けて考えられます。一つは、設計書やテスト仕様書などのドキュメントの誤りをプロジェクト内の成果物レビュー(ピアレビュー)で見つけたもの。もう一つは、実際に書かれたプログラムのミスをテストで、検出したものです。これらの欠陥を約束した時期までにどれだけ除去できたかが、「欠陥除去率」です。
前者のドキュメントエラーについては、ドキュメントの書き直しで済むわけですから、レビューで指摘された場合、次回レビューまでに、ほぼ100%修正できていることが求められる筈です。もちろん、多少の修正漏れは、許容範囲ですが、同じ指摘を何度も受けるようでは、作業の品質が劣ると言わざるを得ません。技術的に高度な再検討が必要で、時間の係る場合もあるとは思いますが、その場合は、再レビューの日程そのものを妥当に設定している筈です。文書の欠陥をちゃんと約束どおり、除去したこと、あるいは、しなかったことは、作業の品質を訴える上で、有効な指標になると思います。
一方、プログラム自体のエラーについては、簡単に次回テストまで、とは行きません。と言うか、次回テストまでに全ての欠陥を除去しきっていなければならない、となると作業者には、相当厳しい条件となってしまいます。本来は、そうあるべきでしょうが、この業界の常識としては、単体テストにおいて、除去すべき欠陥がある一定期間残存し、同じテストを何度も繰り返さざるを得ないことは、よくあることで、少なくとも、それをもって作業の品質が悪い、と言い切るのは、酷な話です。
着目点は、各テスト工程毎に除去すべき欠陥を除去しきれているか、と言う点です。コンピュータシステムのテストは、多くの場合、いくつかの段階に分けて行われます。一本一本のプログラムの動作を個別に検証する単体テスト、複数のプログラムやサブシステム同士の連携を検証する結合テスト(あるいは、統合テスト)、システム全体としてうまく動くかを見るシステムテストなどの段階がそれです。(他にもテストは、ありますが、冗長になるので、このあたりにしておきます。)
プログラム単体の欠陥は、単体テストで除去されているべきであり、プログラム間やサブシステム間の欠陥は、結合テストで除去されているべきものです。これが、除去しきれずに、プログラム単体のエラーが、結合テストやシステムテストで、あまりに多く検出される、結合テストで検出するべき欠陥が、システムテストでやはり、大量に発見されるようであれば、「真面目にテストしているの？」とのことになります。このあたりは、「作業の品質」を見る上で、やはり、有効な指標になり得るのでは、ないでしょうか。実際には、本来のテストで検出できずに、後続に残ってしまう欠陥は、あるのですが、程度の問題があります。テストの検出漏れが、10も20も出てきてしまうようであれば、やはり、品質を確保した作業とは、言えないでしょう。逆に、テストの検出漏れが、ほんの数個であれば、「ちゃんと仕事をしている」ことの論拠になると思います。

3.欠陥数
これについては、比較的理解しやすいと思います。レビューやテストにおいて、あまりに多くの欠陥がでるようであれば、作業の品質を疑わざるをえません。ただし、ITでは、この欠陥が少なすぎることも問題になります。IT開発においては、設計書であれ、プログラムであれ、またテスト仕様書であれ、難解な技術用語や通常の人間には理解できないプログラミング言語を何万・何十万と書き連ねる訳ですから、人間工学的にみても、「ノーミス」ということは、あり得ません。必ず一定数のエラーが出るはずです。これが、少なすぎる場合、レビューやテスト自体の品質に問題があることが多く、やはり作業の品質を疑わせるものです。（欠陥の数が少ない場合、本当に最初から成果物の品質が良いことも考えられますから、これについては、完成したシステム自体の品質と比べる必要がありますが。）

以上が、「準委任」における着目点として、私が考えるところです。中には、自身にとって不都合なものもあるかもしれなせんが、調停委員は、当然気にするところでもありますので、早期に明らかにすることが、結果として双方の利益になると思います。

調停時に必要な主張(1)

Face Bookを始めました。実は、随分以前から登録だけはしていたのですが、最近会った友人に誘われてつないでみたところ、驚くほどの知り合いが見つかって、毎日、友達登録や投稿に忙しい日々です。ただ、楽しさのあまり、つい時間を忘れてしまい、公私共にいろんなことが、後回しになってしまい、会議資料の作成やら、公共料金の支払いやらいろいろと遅れてしまいました。皆さんもお気をつけ下さい。まあ、それでも、とりあえず楽しいからやってはいますが、やはり、自分の生活に本当に必要なものとそうではいものは、しっかり区別しておきたいものです。

と、言うわけで、今回からは、前回の「調停時にいらない主張」の反対、「調停時にしてほしい主張」について、何回かに分けてお話ししようと思うのですが、その前に、IT業界における「仕事の完成」に関する曖昧さについて、お話ししたいと思います。多少回り道になってしまうのですが、調停においてどのような主張をすることが、納得感のある調停案を出来るだけ短期に得るかを考える上での、予備知識となりますので、少し我慢して読んでみて下さい。

IT訴訟や調停のポイントを簡単に言ってしまうと、「約束した仕事をちゃんとやったか、やれなかったとしたら、その責は、どちらにどれくらいあるのか。」と言ったことになります。決して複雑なことはありません。また、コンピュータ言語やソフトウェア、ハード売れあの仕組みなど、技術に関するポイントというのもありません。その意味では、他の業種と大差ないと思います。
ただ、他の業種と異なり、IT業界は産業として、まだまだ未成熟なところがあり、いろいろな基準や常識が定まっていません。「何をもって仕事が完成したと言えるのか」、「行った仕事は、当初、期待したものであるのか」を厳密に切り分けることが、非常に困難な業界です。
この業界の特殊さの例として、納入物の完成度に関する考え方が挙げられます。ITの場合、開発者が納入して、稼働を始めたシステムが、どこも修正する箇所もなく動くことは、非常に稀です。画面のデザインや文言のあやまり、処理速度の遅さ、使い勝手の悪さ等、業務に決定的な支障をきたさない小さな問題から、出力された演算結果が誤っている。業務上必要な件数を処理できないなど、そのままでは、使えないものまで、様々な問題が、リリース後のシステムで起きるのが、ある意味「当たり前」になっています。発注者と開発者の間に一定の信頼関係がある場合には、こうしたこともあまり問題にならず、(無論、クレームと謝罪の対象ではありますが。)　大概の場合、開発者側が修正作業を無償で行うことにより、仕事は完成したことになります。費用の支払いも問題なく行われます。
これが、自動車だったらどうでしょう。買った車の塗装が、一部禿げていたり、座席シートのクッションが一部抜けていたりしたら、例え、機能や安全性に問題がなくても「返品もの」ではないでしょうか。家を建てる場合には、「返品」には至らないかもしれませんが、柱や壁に傷や穴があれば、「仕事の完成」とはみなさないと思います。
ところが、ITの場合、この程度のことは、日常茶飯事で、納品後に改修すれば、殆ど問題になりません。そんな事を問題にして、発注者が、支払いをしなければ、IT企業は、殆どの場合、商売にならなくなってしまいます。IT調停の難しさの一つがここにあります。本当にこの仕事は完成したのか、瑕疵はないのかそもそも瑕疵とは何か、と言ったところに明確な線引きがないのです。実際の調停でも、発注者が「仕事は完成していない」と主張し、受注者は「業界の慣習からすれば、仕事は完成したと言ってもさしつかえない」、「軽微な問題であり、瑕疵にはあたらない」と反論する例を私はいくつも見てきました。

IT業界の曖昧さは、契約形態にも見られます。システム開発において、よく見られる形態として、「請負契約」と「準委任契約」がありますが、出来上がったシステムに完成責任を持たない筈の「準委任契約」でも、実質的には、開発者が責任を負い、瑕疵の修正は、全て、開発者が無償で行う例も多いようす。
こうした仕事の完成に関わる曖昧さは、これ以外にも「〇〇一式」としか記載がなく、検収条件のわからない契約書や、契約変更を経ずに追加になったり、逆になくなってしまったりする要件の問題、納入されたシステムを十分に検査せずに検収をしてしまう問題等枚挙に暇がありません。いずれもこの業界の未熟さを表しています。

他業界の方からすれば、呆れてしまうかもしれませんが、こうしたことが当たり前のように行われているのが、IT業界の偽らざる現実です。無論、昨今は、所謂大手ITベンダーを中心に、こうした曖昧さを排除すべく、要件定義や作業の完了基準、契約といったプロセスを整えているところも多いのですが、調停に上がってくる紛争を見ているとその浸透度はまだまだのようです。

今回以降、お話ししようと考えている「調停時にしてほしい主張」とは、まさにこうした問題について、双方がどのように認識し、合意していたかということです。法律や、業界の常識は、ともかく、開発時にどのような約束事が当事者間であったのか、これが、調停を行ううえでの大切な基準になります。このことは、単に調停委員会が考えをまとめる上で、有効であるだけではなく、調停の早期終結とお互いの納得の為、調停の早い段階で、是非とも押さえておきたいところです。

では、調停において、調停委員に何を主張すれば、仕事が完成した、あるいは、しなかったと訴求できるのでしょうか。あくまで、私見ではありますが、私は、以下のように考えます。
まず、「準委任契約」における役割分担についての考え方です。ご案内の通り「準委任契約」では、受注者が、成果物つまり出来上がったシステムの動作や機能に責任を持ちません。例えば、システムの画面遷移が異なる、論理演算を意図した通りに行っていない(“計算が間違っている”のは、論外ですが。) 等、開発したシステムの挙動が本来ユーザーの意図したものと異なっていたとしても、発注者からの要望が、そもそもそうなっていたとしたら、受注者つまり開発者は、その役割を果たしたことになります。開発者は、契約書等で約束した期間、一定の作業品質を守って業務を遂行することが必要ですが、それを守っている限り、成果物そのものの動作や機能に責任を持ちません。このあたりは、他業界の常識とも相容れる考えかと思います。
従って、調停委員が、発注者と受注者に対して、まず確認したいことは、「約束した仕事」とは、どのようなものであったか、ということになります。訴訟では、考え方が少し変わるのかもしれませんが、少なくとも調停においては、それが、如何に不十分なものであったとしても、双方の合意が話し合いの出発点になります。作業時間や場所、作業の内容や作成対象の成果物、指揮命令系統や作業者に求められる技術レベルや経験等について合意した事項がこれに当たります。きちんとした契約書や契約書別紙、RFP、作業指示書等があれば、それに超したことはありませんが、それがなくても議事録や電子メール、ホワイトボードのコピーでも、双方が合意したものがあれば、なんでもかまいません。それもない場合には、準備書面等に「こういう約束であった」と記載するだけでも議論の出発点にはなります。また、併せて、作業を行う上での条件について合意した事項があれば、それも示す事が必要です。これは、主として開発者側に必要な場合が多いようですが、「確かに作業は完成しなかったが、それは、相手が約束したはずの情報を提供してくれなかった」等の言い分が、ある場合があります。そうした主張をするためには作業を行うために取り決められた諸条件を示す必要があります。
と、ここまでは、常識的なことですが、ITのように比較的専門性の高い作業について、「約束した仕事を行ったか」を考える上では、単に作業を行ったか、だけではなく、期待された知識と経験を以て作業を行ったか、つまり「作業の品質」を考える必要があります。
「作業の品質」という考え方自体は、どのような作業にもあると思います。例えば、店頭販売を「支援」するのであれば、営業時間内、お店に居て、来店したお客さんに失礼のないように接しながら、お店のプロセスにしたがった販売活動を行っていれば、「常識的な作業品質」を保てていると言えるでしょう。事務系の仕事を「支援」するのであれば、必要な書類や伝票その他作業を誤りなく、時間どおりに行うことが、「作業品質」にあたるのかも知れません。
ITの場合はどうでしょうか、私はこれを、「期待された技術・知識を持った要員が、仕事をサボることなく、作業を行い、極端な作業の遅れや常識外れの欠陥を出さずに作業を決められた時間内、行うこと。」と考えています。「決められた作業を行えば、その質は問われない」との乱暴な意見も聞く事がありますが、そんなことはないと思います。契約時に発注者が開発者に当然期待してよい品質は、あると思います。
ここで言う「当然期待してよい品質」とは、どのようなものでしょうか。決められた時間、指示された作業を行うことは当然ですし、作業者がその作業を行うだけの知識・経験を持ち合わせていることも当然に期待されることです。これは、どの業界でもおなじことでしょう。しかし、ITの場合は、もう少し複雑です。決められた時間内、正しいプロセスに従って、誤りなく仕事をしても、それだけでは、「常識的な作業品質」にはなりません。開発者には、技術者として当然に気づくべき事柄というものがあります。例えば、実現できない要件や要件間の矛盾、セキュリティの十分性など、確かに要件の提供者である発注者が責任を持つべき事柄でも専門家の意見なしでは、気づかないことがらがあります。無論、ここでいうのは、専門家であれば、常識的に気づく程度の事柄です。高度の知識や経験がなければ見抜けないものは、「準委任」の範疇外でしょう。例えば、外部のインターネットを経由するWEBシステムにおいて、ボタン押下から画面表示までの時間を保証するとか、24時間稼働するシステムにも関わらず、毎夜数時間のバッチ処理が必要とか、個人データを暗号化もせずにインターネットを介した通信で受け渡すとか、発注者には、気づきにくい様々な危険を開発者が専門家として注意喚起や代替提案を行うべき事柄がいくつもあります。無論、発注者側がその危険を承知で、作業指示を行う場合は、それで良いのですが、発注者が必ずしもITに明るくない場合、または、そのシステムの実現に必要な技術(パッケージソフトなど)に明るくない場合には、こうした責任が開発者側にも一定程度あると、私は考えます。

これらをまとめると、「準委任契約」において、双方が主張すべき点は、以下のようになると思います。

・ 作業者の選出にあたって、明確な条件提示があったか。また、作業者は、その条件を満たしていたか。
・ 作業環境や作業条件、必要な情報提供等の条件に合意していたか、それは、適時に実現されていたか。
・ 第三者が見ても理解できる作業指示とその完了基準があったか、それは、守られたか。
・ 作業時間は約束され、その通り働いたか。
・ 作業は、遅滞なく実施されたか。
・ 作業は、社会通念上、常識的な勤勉さを以て行われたか。
・ 作業は、発注者のルールやプロセスに従って行われたか。
・ 開発者は専門家として、発注者はシステムの使い手として常識的な注意喚起や問題点の指摘等をおこなったか。

これで、全てという訳ではありませんが、このあたりを整理して調停に臨むことが、問題の早期解決に寄与することにつながると思います。調停といえども紛争ですから、双方、自分に都合の良いところだけを主張することは、致し方ありません。双方の意見の違いが分かる事も調停の上では有効ですし、こうした整理を行うことで、自身の弱みをあらかじめ把握しておくことも、大切かと思います。