ソフトウェアを構築する際、最も難しいのが「顧客要求を正確に捉え、機能に反映させる」ことです。
コンピュータの世界と言っても、ソフトウェアは人間同士が会話しお互いの要求や解釈を理解したうえで作り上げていく、それこそ“家作り”と同様です。

家を建てるときには、家族構成や日当たり、区画、デザインなど、多くの施主の“夢”を、建築士や施工業者が形にしていくわけです。価値観は人によって異なります。家のイメージといっても素人には簡単に表現するすべはありません。あらゆる価値観を持った人々の夢やイメージを、その人にとって価値あるものとして形にしていくのが建築士の技量です。

施主のイメージと建築士の技量をかね合わせ施主にわかりやすく理解してもらうために、建築業界では様々な手法を取り入れています。図面起こしからや模型作り、最近では３Ｄシミュレーションのような画期的な表現方法などを使い、実物により近いイメージを共有するのです。

ソフトウェア開発業界では、今でも広く活用されているウォーターフォール型という、上流工程から順々に下流工程へと落とし込み、最終的にソフトウェアを完成させる、川の流れのような手法が主流です。

ところが、この手法はユーザーにとっては決してわかりやすいものではなく、「ユーザーのニーズをきちんと機能に展開できているか」を確認するには、分厚い仕様書を必死に見たり担当するシステムエンジニアに直接聞くしかありませんでした。結局長い時間かかって完成した時点でようやく動くものとなり、初めて使ってみて、最悪のケースでは「自分の思っていたものと違う」という不幸な結末を迎えることさえあるのです。もちろんそのようなケースはごく一部ではありますが。

最悪のケースとなる一番の理由は「作り手と使い手の想いのズレ」です。「想いのズレ」は、コミュニケーションの不足や表現力が不足していることが要因です。 そこで、この「想いのズレ」を防ぐため、これまでもいろいろな手法がとられてきました。プロタイピングやパイロットプロジェクトなどがそれに当たります。家作りで言う「模型作り」や「３Ｄシミュレーション」のようなものです。

ソフトウェアは、使い手が効率的に効果的に運用することでその意味を持ってきます。決して、作り手の都合で使い手が我慢をして使うことなどあってはならないのです。

ＭＩＳではアジャイル開発手法の中でも、テストフェーズでユーザーに参画していただき「想いのズレ」を修正していく「エクストリーム・プログラミング」という手法を推進しています。
エクストリーム・プログラミングでは、ある一定のブロックごとにプログラムが完成した時点で、ユーザーにもテストに参加してもらいます。ユーザーで設計書を見て機能が満足されているかを判断できる人物はほとんど存在しません。完成したプログラムであれば、ユーザーが動かすことでその判断が出来ます。プログラムとして「動く機能」を実体験してもらうことで、自らの要求が満たされているかを早い時点で確認することが出来るようになりますし、想いが違っていれば早い時点で修正することができるようになります。
早い段階で不具合を発見しますので、その後に行われる全体テストの時点で発生する不具合も極小化できます。

また、会社で情報システムをリニューアルするというのは一大イベントです。これまでの業務の流れが変わったり、新しいシステムを理解、運用したりと多くのパワーを必要とします。
新しいシステムが完成した時点で初めて使ってみよう、となると、ほとんどの場合慌てて使い方を覚え、サービスインしてからも慣れるために相当の時間を要します。

プログラム単位でテストに参加していれば、テスト時点で一度遣い方を覚えられますので、サービスインに向けた心積もりが出来、これまでよりは、スムーズにサービスインすることができるようになります。