やはり危機に瀕していたIT業界の「モラル」という記事が目に留まったので，今日はその話題に関して．全体的には，ベンダ側（作る側）の不満を並べてみました，といった印象を受けましたが，いくつか気になる意見もありました．
要求を正確に伝える“当たり前”の難しさ
「詳細設計書を客先に提出し，検収していただいたにもかかわらず，実装段階で追加仕様が発生することが多々ある。ユーザー企業のモラルは問われないのだろうか？（中略）仕様書の改版に疲弊した現場では，テストが軽視されるという悪循環が見られる」（インテグレータ勤務，30代）
「システム開発の案件では，顧客企業側に問題があるケースも少なくない。実際の開発を始めてからの仕様変更などを，当たり前のように言ってくる。顧客企業側のモラルも問題だと思う。レベルの低い顧客とばかり付き合っていれば，レベルの低いシステム会社が育つのは，仕方がない気がする」（インテグレータ勤務，30代）
顧客の思いつきにも見える仕様追加が大きな問題だと言う指摘です．一理はあるかもしれませんが，それを“レベルの低い顧客”と片付けてしまって良いものなのでしょうか．私も，一度ユーザ側としてシステムの開発を見てきました．その時に思ったことは，確かにベンダ側は詳細な設計書を作成して，熱心に説明してくれます．しかしながら，やはり紙の上だけで全てを把握するのは困難なことです．特に，自分の要求を満たすためには，その設計書では何が抜けているのかを見つけることは，なかなか難しい作業となります．
開発を頼む際に，自分の要求を余すことなく相手に正確に伝えなければならないのは“当たり前”のことです．ですが，“当たり前”だからと言ってそれを行うことが“容易”であるとは限りません．これだけ同じ問題が頻発するのは，恐らくはその“当たり前”は実践することが非常に難しい“当たり前”のことなのでしょう．
ベンダ基点からユーザ基点へ
さて，現在のIT業界の状況を変えるにはどうすれば良いのか？この答えの一つとして，ユーザが詳細設計書を持参して，ベンダに開発を依頼するというスタンスを取ると良いのかもしれません．これが何を意味しているかと言うと，現在は左下の図のようにベンダを基点として開発が進みます．このため，下請け会社の存在は隠される傾向にあり，その結果，実際の開発がどのような状況にあるのかをユーザが把握しにくい，ユーザの要求がベンダを通じて下請け会社へ伝わるため認識の食い違いが起こることがある，などの問題が生じます．そこで，右下の図のように詳細設計書が作成された時点で一度契約を終了し，出来上がった設計書を持ってユーザが直接，実際に開発を行うベンダへ依頼するというユーザ基点の開発プロセスを採用すれば，前述したような問題がいくらか解消されるのでは，と思います．
加えて，このような開発プロセスを取ることでユーザと実際に開発している企業とが直接関わることになり，上記の記事で指摘されていた“ITエンジニア自身が働く喜びを感じることのできる環境”を作ることにも繋がっていきます．
「お客さんから『ありがとう』の一言があれば，それだけでSEは頑張ることができる」と話す。ところが「下請けのSEには，お客さんと直接やり取りすることがない。それでいて仕事は単調なコーディング作業で，自分がシステム開発にどう貢献しているかも分からない。これに加えて仕事が過酷となれば，モラルを保てるはずがない」（戸並氏）。
また，先にも述べたように，出来上がった詳細設計書にはほぼ間違いなく（自分の要求を満たすためには）何らかの不足事項が存在しています．そのため，実際に開発を行う段階になった際には，できるだけ早くプロトタイプのような物を作成し，それを基に一度ユーザに何が足りないかを確認してもらうフェーズを設けると良いのでは，と思います．この際，そのときのユーザの要求によっては，最悪そのプロトタイプを捨てなければならなくなるかもしれません．そのため，一見非生産的ですが，“作ったものを一度捨てる”というフェーズを導入する（ユーザにプロトタイプを見てもらった次のフェーズか）と，結果的にうまくいくようになるのかもしれません（もちろん，捨てなくても良い場合も存在し，その場合はラッキーだったと）．
