HOME > ニュース > 顧問エンジニア/Den-O

ニュース

2015/11/05

顧問エンジニア/Den-O

システム開発の契約は議論の尽きないところです。日本ではまだウォーターフォール型を軸とした契約が主流となっています。最近の開発スタイルはアジャイル開発にシフトしつつもどうしても契約締結が難しくユーザー企業に受け入れられていないのが実状です。契約書では機能範囲と納期、金額の3つを明確に示すことが必要ですが、アジャイル開発ではこれらがはっきり決まらないことが多いというか、進めながら決めていくスタイルなので事前に契約書に示すことが出来ないのです。ハイブリットという表現でウォーターフォール型とアジャイル型を組み合わせた形式で契約を締結する案件が増えてきていると聞きますが、まだまだウォーターフォール型で進むのでしょう。

niagara-218591_1920

ウォーターフォール型が悪いのか?と言われると決してそうではないのです。至極当然のススメ方であるのは間違いありません。ではなぜ議論され続けるのか?それはシステム開発に対する考え方が大きく変わってきたからです。システム開発に求められるものは「何を構築するのか」「何を作るのか」です。顧客要件でありRFPなどで提示される内容です。これがなければ何も進みません。RFPを具体的にする作業工程が要件定義なのですが、ここに問題が多くあります。要件定義工程は一般的に準委任といって作業時間を成果として支払をする契約をとります。ひとつひとつユーザーの要件を具体的にして機能に落とし込み、パッケージ製品であればカスタマイズ範囲も具体的にする工程となります。工程として問題はないように思えます。では何が問題なのでしょう。
定義した内容が正しく相互に伝わらないことが問題のひとつです。

ユーザーは自分たちの業務から話をします。業務システムであれば当たり前のアプローチです。システムベンダーは自分たちのシステムが持っている機能から話をします。同じキーワードが飛び交っているとお互いに「同じこと」を話している気になっていますが、その本質は異なることが多いのです。システムベンダーは「機能の代用と運用の改善」を求めますが、ユーザーは自分たちの運用にシステムを合わせたがります。要件定義で合意したつもりでも出来てきたものは「言ったことと異なる」ものになっているのです。結局作るのはシステムベンダーであって、ユーザーではありません。要件定義はシステムベンダーの都合の良い理解の上に成り立っているものが多いのです。

もうひとつ問題があります。それは時間です。
たしかにその当時はその要件に対してその実現方法で良かった。でもあれから何ヶ月が経過したのかもしかしたら年単位で経過していることも有ります。もうその要件の根本が変わっているなんてことも多いでしょう。でもそれを変更すると「仕様変更」になってしまい他の機能との整合性が取れない場合もあるためそのまま突き進むしか無いもしくは、出来てきても使えない代物になっているのです。機能、運用に対する理解は一致していいてもそれを実現しなければいけない「時間」が置き去りになっていることが多いことで発生する問題です。ウォーターフォール型での問題はシステム開発に時間がかかるほどに問題となってしまう契約形態なのです。
どうやったら改善できるのでしょうか?

時計/ドライブ

一部で取り入れられ始めたのが顧問エンジニアの採用です。これは医療などで言われるセカンドオピニオンと同じで第三者の意見を入れることで改善を促すのです。顧問エンジニアはユーザーの立場で要件定義などの打合せに参加をします。そのときにユーザー課題の本質とシステムベンダーからの回答の本質を噛み砕くことが仕事になります。とくにシステムベンダーの説明内容をユーザーが理解できるようにしてあげること。その内容で何か問題が考えられることを意見する。そういった立場になって意見することで契約上問題となる「機能」「時間」「費用」を整理するとプロジェクトが大炎上することなく進めることが可能になっていきます。もともとはPMOと言われる立場の人がこれを行うべきなのですが、ほとんど機能していません。それはユーザーへの理解が薄いからです。PMOはシステムベンダーがプロジェクトを遂行するための立場になっています。プロジェクトの内容云々ではなくシステムベンダーとしてプロジェクトの納期を守ることが最優先なのです。そんな人材にコストをかけるプロジェクト自体いかがなものかと思います。

顧問エンジニアはユーザー企業内での理解が必要です。即日で用意できるほど簡単な立場ではありません。最初は何も知らない人材からユーザー企業の状況、課題、部署間の問題、向かっていく方向性などを理解していただくことからはじめなければなりません。またユーザーが求めるシステム情報の提供も必要でしょう。これはこれで費用も時間も掛かります。でもシステムが不要な業務遂行が考えられないのであれば、一日も早くこういった考え方を取り入れるべきではないかと思います。IT業界が人材不足である今日でユーザー企業におけるシステム部門の人材確保及びシステム部門としての存続も難しい状況です。社内人材を育てることを社内だけで考えるのではなく、顧問エンジニアとともに相互に育て上げていくことが望ましいのではないでしょうか。継続できるチカラを得ることが重要だと私は思います。