執筆者は4名体制で、マーケティングコンサルタント、システムエバンジェリスト、システム導入コンサル、管理部門が週2回、とっておきの役に立つ/くだらない話をお届けします。(くだらない話の方が多いのですが。提供:株式会社アール(http://www.eighteen.co.jp)201511月5顧問エンジニア/Den-Oシステム開発の契約は議論の尽きないところです。日本ではまだウォーターフォール型を軸とした契約が主流となっています。最近の開発スタイルはアジャイル開発にシフトしつつもどうしても契約締結が難しくユーザー企業に受け入れられていないのが実状です。契約書では機能範囲と納期、金額の3つを明確に示すことが必要ですが、アジャイル開発ではこれらがはっきり決まらないことが多いというか、進めながら決めていくスタイルなので事前に契約書に示すことが出来ないのです。ハイブリットという表現でウォーターフォール型とアジャイル型を組み合わせた形式で契約を締結する案件が増えてきていると聞きますが、まだまだウォーターフォール型で進むのでしょう。ウォーターフォール型が悪いのか?と言われると決してそうではないのです。当然のススメ方であるのは間違いありません。議論され続けるのか?それはシステム開発に対する考え方が大きく変わってきたからです。システム開発に求められるものは「何を構築するのか」「何を作るのか」です。顧客要件でありRFPなどで提示される内容です。これがなければ何も進みません。RFPを具体的にする作業工程が要件定義なのですが、ここに問題が多くあります。要件定義工程は一般的に準委任といって作業時間を成果として支払をする契約をとります。ひとつひとつユーザーの要件を具体的にして機能に落とし込み、パッケージ製品であればカスタマイズ範囲も具体的にする工程となります。工程として問題はないように思えます。何が問題なのでしょう。定義した内容が正しく相互に伝わらないことが問題のひとつです。ユーザーは自分たちの業務から話をします。業務システムであれば当たり前のアプローチです。システムベンダーは自分たちのシステムが持っている機能から話をします。同じキーワードが飛び交っているとお互いに「同じこと」を話している気になっていますが、その本質は異なることが多いのです。システムベンダーは「機能の代用と運用の改善」を求めますが、ユーザーは自分たちの運用にシステムを合わせたがります。要件定義で合意したつもりでも出来てきたものは「言ったことと異なる」ものになっているのです。結局作るのはシステムベンダーであって、ユーザーではありません。要件定義はシステムベンダーの都合の良い理解の上に成り立っているものが多いのです。ひとつ問題があります。たしかにその当時はその要件に対してその実現方法で良かった。あれから何ヶ月が経過したのかもしかしたら年単位で経過していることも有ります。その要件の根本が変わっているなんてことも多いでしょう。それを変更すると「仕様変更」になってしまい他の機能との整合性が取れない場合もあるためそのまま突き進むしか無いもしくは、出来てきても使えない代物になっているのです。機能、運用に対する理解は一致していいてもそれを実現しなければいけない「時間」が置き去りになっていることが多いことで発生する問題です。ウォーターフォール型での問題はシステム開発に時間がかかるほどに問題となってしまう契約形態なのです。やったら改善できるのでしょうか?一部で取り入れられ始めたのが顧問エンジニアの採用です。これは医療などで言われるセカンドオピニオンと同じで第三者の意見を入れることで改善を促すのです。顧問エンジニアはユーザーの立場で要件定義などの打合せに参加をします。そのときにユーザー課題の本質とシステムベンダーからの回答の本質を噛み砕くことが仕事になります。システムベンダーの説明内容をユーザーが理解できるようにしてあげること。その内容で何か問題が考えられることを意見する。整理するとプロジェクトが大炎上することなく進めることが可能になっていきます。PMOと言われる立場の人がこれを行うべきなのですが、ほとんど機能していません。それはユーザーへの理解が薄いからです。PMOはシステムベンダーがプロジェクトを遂行するための立場になっています。プロジェクトの内容云々ではなくシステムベンダーとしてプロジェクトの納期を守ることが最優先なのです。そんな人材にコストをかけるプロジェクト自体いかがなものかと思います。顧問エンジニアはユーザー企業内での理解が必要です。即日で用意できるほど簡単な立場ではありません。問題、向かっていく方向性などを理解していただくことからはじめなければなりません。ユーザーが求めるシステム情報の提供も必要でしょう。これはこれで費用も時間も掛かります。システムが不要な業務遂行が考えられないのであれば、一日も早くこういった考え方を取り入れるべきではないかと思います。IT業界が人材不足である今日でユーザー企業におけるシステム部門の人材確保及びシステム部門としての存続も難しい状況です。社内人材を育てることを社内だけで考えるのではなく、顧問エンジニアとともに相互に育て上げていくことが望ましいのではないでしょうか。継続できるチカラを得ることが重要だと私は思います。