ウチのシステムはなぜ使えない

ウチのシステムはなぜ使えない SEとユーザの失敗学 (光文社新書)

ウチのシステムはなぜ使えない SEとユーザの失敗学 (光文社新書)

IT化したのに、なぜか書類の量が激増!SEに痛い目に遭わされたユーザ、ユーザの無理難題にぶち切れたSE、ともに必読。

http://www.amazon.jp/dp/4334034446

本書は受託開発の難しさを、システムに関わる3者(発注/受託/運用)それぞれの視点をとおして説明しています。
私もシステム開発をして食べていますが、作る側と使う側の意識や考え方の齟齬というものの大きさは日常から強く感じていることであり、その点については身をもって理解しています。これだけ便利になった世の中なのですから、やりたいことをシステムにするという作業はそれほど難しくないと思われがちなのですがとんでもありません。
特に上流工程に限って言えば、要件を聞き取ってまとめる→仕様書にまとめるという作業がありますのでさすがにここまでは自動化することは難しいです。そういった部分の出来/不出来は実施する人のスキルに依存しますし、この成果の品質を評価するのは非常に難しいために後工程で問題が露呈してしまう場合があります。
そんなわけで作る側の視点になってしまいますが、発注する側が想像する以上に期待された結果を出せるシステム作りというのは難しいです。何となく私の受けている印象としては「これくらい簡単に作れるんでしょ」みたいな視点というのも少なからず感じることはあって、発注側の想像している理想と現実の間にものすごいギャップがあるのではなかろうかと思うのです。


ちなみに、簡単に作れると勘違いされる原因のひとつとして、開発環境が非常に便利になったということが挙げられます。Windows限定ですがVS.NETはびっくりするくらい便利ですし、WindowsLinux共通のものでいえばだとEclipseが非常に使い勝手がよいです。
特にEclipsehaさまざまなコンパイラにも対応しているのでかなり広範囲に適用できますし、画面を作るだけであれば今までプログラムを作ったことがない方でもそれなりに画面を作り上げることも難しくなくなりました。


このように画面が簡単に作れるようになったのはたしかに便利ですが、ビジネスロジックについては今までと同じように書く必要があります。動作させる環境(フレームワーク/ランタイム)によっては機能が充実していて、ロジックそのものは簡易な表記になる場合もありますがそれでも自分で書かなければいけないことには変わりありません。
そしてプログラムの中でもっとも大事なことは、画面ではなくビジネスロジックです。画面が作ってあるだけで完成したような気分になってしまう人がたまにいますが、はっきり言ってそんなのはありえません。


いつも話がそれてしまってすいません。本書に話を戻します。
本書は、上記のようなシステムに対する理解や期待、価値観がずれることでシステム作りがうまくいかない現状についてとても分かりやすくまとめられています。ただし基本的にはシステム開発に携わっている人間であれば目新しい話ではなく、単に現状を再認識する以上の意味はありません。もちろん再認識することで、例えばいつも邪険に扱っている営業担当に優しくしようと思ったり、つまらないことばかり聞いてくる人の話も聞いてみようかと思ったりすることもありますのでまったく意味が無いかと言えば決してそうではありません。


ただし本書をおすすめしたい対象としては、システム化をしたいと願う発注者やこれからシステム開発を生業として生きていこうと考えている新卒の方がよいのかなと感じました。業界そのものに興味がある人は一読してみてもおもしろいのではないかと思います。