コンピュータシステム、システムが稼働しない事案が訴訟になることも珍しいことではありません。
最近IT業界で話題の訴訟でIBMが19億円もの賠償を払う判決が東京地裁から出た案件があります。SIer(エスアイヤー: Systems Integrator)の多くは理不尽だと思っている事でしょう。トラブルは何も最近だけの話ではなくコンピュータが企業に導入され始めたころから付きまとっています。なぜ、トラブルはなくならないのか。理由は人と人が言葉と文章でコミュニケーションする限界です。特に今回のようなクラウドで有名なセールスフォースのパッケージソフトのカスタマイズで高機能低価格目指していたのにと言った点です。当初の見積りでは12億3400万円を見込んでいたのに賠償額の方が多い、実際には開発費が膨らんで今まで支払った費用の85%を返還した状態です。いささかIBMにとっては厳しい内容です。
ここでコミュニケーションとしての言葉がどのように伝わるのか試してみます。是非、実際に試してください。コピー紙と筆記具を用意します、描く内容は、「紙に「四角（□）の図形」を書いてみてください、次に丸（○）を3つ上に書いてください。」※元の質問を少し変えています。
実際に周りの人にも是非書いてもらい他人の書いたものと比較してみてください。ちなみに私は月見団子のように四角の上辺に三角に積んだ団子をイメージした丸を書きました。最初にこの質問を聞いた時は他の人も大体似たものになると思っていました。しかし実際には千差万別そっくりはなかなかないのです。大きかったり小さかったり資格の位置が中央だったり左右によって至り、丸の位置もバラバラです。正解はと言うと、どのような絵を描いても四角と丸が3つあれば正しいのです。上と書いてあるから指定されていると思われるかもしれませんが、どこの上とは書かれていません。しかも2次元にとらえるか3次元かによっても異なります。四角の三辺に丸を書いても四角の中に３重丸を書いても視点が違うだけで間違いではありません。我々は自分の常識の中で相手が理解していると勝手に思っているのです。
SIerはこのような状況ではるかに複雑なシステムを顧客ニーズに合わせて開発するのは至難の業となります。まずは概算見積もりをして着手となるのですが、概算見積もりの精度は-20%から+100%程度のものです。どうしてそんなに誤差が無くならないのかと言えばソフト開発は開発環境の制約や仕様に係る詳細の工数の精度は創造と経験により算出するため積算が難しいのです。さすがにこのままでは誤差が多いのでさらに何回かフェーズなどに分割します。一般に何か月かに分けた多段階契約をするのですが、要件定義のフェーズではソフトウェアの成果物は得られません。ここでユーザーに仕様書を承認するよう要求しますがそれが本当業務に適用するか想像する事は実際には困難です。そしてできたと言われるソフトが求めていたものと違うとなれば仕様変更が頻発し開発のし直しになり破綻に至ります。
IT業界もいかに課題をこなすか技術を磨いてきました。大型案件ではよくウォーターフォール型開発手法が長らくとられてきました。これは要件定義、設計、実装、検証、保守と上から下に順番に進める手法です。しかし、最初に要件定義が完璧でないと以下は崩れていきます、おそらくこの点でIBMがハマった罠です。標準的な業務であれば問題無いでしょうが、今日業務は複雑化していますし現行のシステムを補完するような運用がされています。Excelなどでの作業もあり組み合わされた業務は使っている人さえ自分の業務を要件定義するから説明して、と言われても難しいのではないでしょうか。この難題に立ち向かうためにいろいろ考えられてきたのが2001年頃登場したアジャイル開発です。
アジャイル開発は結構泥臭い4つの価値を実現しようとするものです。
a.プロセスやツールよりも個人と対話を
b.包括的なドキュメントよりも動くソフトウェアを
c.契約交渉よりも顧客との協調を
d.計画に従うことよりも変化への対応を
言っている事は正論なのですが、仕事としてc.dはSIerにとってはなかなか難しい事ではありますがa.b.は双方にとって当たり前で大切な事であるのは明白です。これを実現するために最初に大まかな全体像と開発を分割する機能単位を決めます。さらに開発しているものがユーサーニーズに合っているか確認するために数か月単位にリリースします。このリリースで問題があれ開発にフィードバックし軌道修正します。このリリースを繰り返して全体像に向かっていきます。利点の多いアジャイルですが、欠点としてはユーザーもこのリリースに付き合わなければならない点です。しかしこれは大切な事でユーザーが求めていたものができているのかを判断する大切なポイントです。必ず使ってみて判断して頂きたい。そして最後には満足できるシステム全体が完成する事でしょう。
アジャイルをさらに進め2007年頃に登場した開発手法はよりユーザー寄りにしたDevOps(デブオプス: Development & Operations)手法があります。DevOpsは文字通り開発者チームと運用チームが強調して現場と一緒に開発させる手法です。これでアジャイルのc.dを解消できます。なにせ、ユーザーと一緒に開発するのだから顧客と強調しているし、変更も顧客の都合だから計画の変更も容易、実は良さそうですが終わりのない開発をすることを意味します。特に新規案件をアメーバーのように広げていく業務開発には向いていますが既存システムを移行するのは極めて難しく開発担当者の技量に左右される面も多くなります。この手法の評価はまだ固まっていないのですが、システムを内製化する時に適応するなら向いていているでしょう。
どの方法もシステム開発には経験と知恵が必要となります。私の師匠がいつも言っていたのが知識は当然大事だがそれを「知恵」にするのが一番大切だと。IT業界は次々に新しい言葉や技術が出てきますがそのような技術の知識だけではうまく行かない、知恵を絞り本質的な解決を目指せと言われてきました。知識は陳腐化するが知恵はいつまでも輝くもので経験と実績の積み重ねが発揮されるのです。