さった11月10日に東京で開催された「JJUG CCC 2012 Fall」に参加しました。
http://www.java-users.jp/?page_id=92
JJUGの新会長である鈴木さんの基調講演は、IT業界で著名な「ござ先輩」こと湯本さんと二人でのトークセッションで、期待どおりの内容でした。テンポよくシステム開発の問題や、その問題の捉え方のヒントが飛び出していきます。ちなみに基調講演の概要は次のとおりです。
基調講演-1 利用されるソフトウェアの創り方 -ITアーキテクトの役割を再考する-
ソフトウェアをいかに開発するか。とても大事なことですが、良いソフトウェアは利用されなくてはいけません。どうすれば利用されるソフトウェアを創ることができるでしょうか。ITアーキテクトの役割を通じて考えていきたいと思います。湯本堅隆/ござ先輩（有限会社エフ・ケーコーポレーション）
鈴木雄介（日本Javaユーザーグループ/グロースエクスパートナーズ株式会社）
講演内容について、私のおおざっぱなメモは次のとおり。
- PM - PG - SE - User - 真のUserという構図がある。
- PMはPG,SEとUserの双方と等しくコミュニケーションをとらなければならない。
- PM,PG,SE,User 全部を経験した人はArchitectになれる。
- 異常系をいつも考え、想定外を予見する。これは経験でしか培われない。
- 現場UserはITありきではない。ITがなくてもUserは業務を何とかする。
- 自分が複雑な業務をできるUserは、複雑なITを求める。
これらのメモから、私が感じたことを整理してみました。
SEは「言われたことをつくるのが楽」という呪縛から抜け出せるか
少なからぬSEは、お客様（以降、ユーザーといいます。）と仕様の妥当性を交渉するよりも、言われたことをつくることを選択します。その理由の一つは、対象業務に精通していないため、仕様の妥当性を判断できないためです。そしてもう一つはユーザーの方から「こうつくれば受け入れる」と提示されるためです。
しかし要求通りに開発した機能（画面）が使いにくかった場合、責められるのもまたSEです。曰く「（SEは）プロなんだから、（ユーザーの）言った仕様がおかしいと感じたら提案すべきだ。こんな使いづらい機能（画面）ができあがったのは私の本意ではない。」
このような問題を、プロジェクト管理手法やWBSで解決できるのかどうか、私はまだ答えを持っていません。
ただ経験上、ユーザーの仕様を一度で理解するのは困難です。二回、三回とつくりなおしてようやく仕様の背景（意図）がわかった、ということは何度もあります。それを早めに気付くためには、ユーザーと最初で深く話し合うことですが、根掘り葉掘り伺うと、最初は忙しいと嫌がられるかも知れません。「あなたはSEなのに、そんなことも質問するのか。」と呆れられるかも知れません。ですので、それにかけるエネルギーより、つくってしまった方が楽というのがSEの立場でしょう。しかしお客様の仕様をすべて理解できるのは「業務コンサルタント」であり、特に若いSEは業務に精通していないことを恥じる事はないと思っています。この点を認められるかどうかがポイントかも知れません。
ユーザーは、100%でなければ受け入れられないという呪縛から抜け出せるか
少なからぬユーザーは、自分の要求が「簡単で、常識的で、一回説明すれば誰でも理解できる内容」だと考えています。しかしこれも私の経験上、そんな簡単な業務（要求）はありません。まず、そのユーザーの業務上の立場を知らなければなりません。現場でオペレーションをしている方は、画面の使い勝手が最優先で、いかに入力の手間をなくすかが重要な仕様です。もしくは例外処理の自動化で、これも自分の業務を楽にしたいという視点です。しかし管理者層になれば、いかに多くの情報を現場に入力してもらい、経営指標に活用できる数字を出力するかが重要です。そしてこの二つの要求は相反することがしばしばです。
難しいのは、現場の要求をすべて満たさないと受け入れられないという状況です。これは当初の見積時にはまったく見えてこないもので、かつ、これらを開発するコストはほとんどの場合、膨大になります。0から80%まで作り上げるのは比較的、低コストでも可能なのですが、そこから100%に引き上げるのが難しいのです。特に99%を100%にする、というのは、しばしば根本的な作り直しを伴うことさえあります。
このときユーザーが意識するのはコストです。「最初に請負契約を締結したのであれば、すべての要求を満たすべきで、追加コストは支払わない。」と押し通そうとすれば、そのプロジェクトはデスマーチ化するか、裁判沙汰になるでしょう。いずれにせよ時間を浪費し、お互いが傷つきます。素早くITを手に入れることがかつてないほど重要な時代に、時間の浪費はもったいないことです。
よく考えてみれば、99%でも、場合によっては80%でも、業務そのものの運用は可能であることが多いのです。その妥協点を話し合うというのは、どの工程ですべきでしょうか。上流工程で発見できる話ではないので、契約の段階でお互いが合意することが最良のはずです。しかし、最初にこのような話をできるのか。特にそのユーザーとの関係が初回の場合、そのような話をすると契約そのものをいただけないのではないか。
私はユーザーのITリテラシというのはプログラミングやOSの操作の習熟度ではないと考えています。システム開発とは本来、難しいもので、お互いの妥協が必要であり、かつ最初から完璧を目指さないという思想を受け入れることです。これを逆手にとって「自分はITリテラシが低いので、プロであるSEに丸投げするが、完璧なものでなければ受け入れない。」という態度で臨むのは結果的にプロジェクトの成功を遠のかせます。開発者に対して何とか作らせよう、ではなく、現実的な妥協点を一緒になって考える、というのが結果的に納期・コスト・品質のバランスをとったシステムを手に入れる王道です。
ツールの進化とは別に、これらの問題は並行して解決する必要がある
これらの話は、開発ツールの進化によって解決できるものではない、と考えています。では誰がリードするべきでしょうか。その役割をもった職種の一つは、ITコンサルタントと呼ばれる人々でしょうか。ユーザーと開発者の間に立って調整する人は、チームの中で潤滑油になります。ITコーディネータをはじめ、そのような立場に近い方々は多くいらっしゃいます。そして基本的には、ユーザーと開発者がお互いをプロとして尊重し合うという対人関係を構築することです。そのような場で活躍できれば、業務アプリケーション開発というのはユーザーにとっても開発者にとっても本当に楽しい仕事であり、人生を充実させる良い経験になる、と考えています。
