« 単身赴任中です | Main | 久々にフィッシングメールが来た »
コンピュータシステムを開発するとき、それなりに能力のある SE が集まって、複数の開発ベンダーとともに、だいたいきちんと仕事をこなしていってもシステムはちゃんとはできあがらないのだなあと最近実感しました。
コンピュータシステムを開発するとき、僕は大抵の場合、開発ベンダーの一員として仕事をします。SE としての仕事もしますし、サーバをセットアップしたりもしますし、テストを設計したり実施したりもしますが、必ずやるのは実際にプログラムを作るといわゆるデベロッパーとしての仕事です。ところが今回は純粋な SE として仕事をしています。後から参加したのでシステム全体の仕様を策定したりはしませんでしたが、複数の開発ベンダーを統括するような立場です。今は各開発ベンダーが担当するサブシステム間の問題を解決したりしています。
共にやっている SE の人達はどなたも純粋な SE の人達です。自分で実際にプログラムを作った経験はあまりありませんが、システムに関する知識はそれなりに持っているし、知らないことでも理解する能力を持っています。問題解決能力もそれなりにあって「間抜け」ではありません。どちらかというと優秀な部類に入ります。しかし、それでもシステムはちゃんとは完成しないのだということを目の当たりにしています。
その原因は技術に関する知識が(僕から見たら)乏しいからです。仕事の内容は書けないけれど抽象化したり置き換えて例を挙げてみましょう。
開発ベンダー A 社、B 社が作るサブシステム間のやりとりの方式を決め、その実際的な取り決め(プロトコルとかインターフェース)を策定したとします。A 社と B 社はそれに従って実際に動くものを開発するわけですが、それぞれがどのように配置されるかというのはお互いに関心がありません。本当は関心があっても自分達の責任領域ではないので口出ししないのです。
ところが配置の仕方によってはそもそもサブシステム間のやりとりの方式が実現不可能である場合があります。例えば A 社が開発するサーバを B 社が開発する HTML+JavaScript が AJAX という技法を用いて利用するとします。サーバのインターフェースも決め、web ページ(HTML+JavaScript+css)の表示と動作を決め、各社がそれを実装したものを準備します。A 社は取り決めたアクセスがあれば取り決めた応答を返すものを作り、B 社は取り決めた問い合わせやリクエストをサーバに出して取り決めた表示をするものを作ります。それぞれが仕様に従って完璧に動作したとしても、この組み合わせではシステムが成立しない場合があるのです。それはサーバと web ページが URL 上別なサーバにある場合です。セキュリティ制約上、それぞれが URL 上別なサーバにあると、web ページ側からサーバにアクセスすることはできないのです。
初めて AJAX な web ページを作ってみようとした人の多くが気付くこの制約。これを知らないと別なサーバに配置して問題があると気付きません。下手をすると問題があるかもしれないと疑いもしません。
A 社のサーバシステムはちゃんとしたリクエストがあればちゃんと応答し、B 社のクライアントシステムはサーバにアクセスできてサーバがちゃんと応答すればちゃんと動作するように仕上がってきても、そのまま進めてしまうと、それを組み合わせたシステムは動作しません。結局結合試験と呼ばれるシステムをテストするフェーズになって大騒ぎになります。
もちろん、当然ではありますが、SE だからと言って世の中そういう制約を知らない人ばかりではありません。知らなくても気付かない人ばかりでもありません。だから世の中の色々なシステムはある程度の完成をして動作しているのです。しかし、知らないし気付かないこともあるのです。
ではそういう場合、その SE 集団には何が足りなかったのでしょうか。
直ぐに思いつくのは知識です。AJAX という技法の制約を知っていればそういう大騒ぎになる前に、システム全体の構成を考えるときに折り込んで未然に防ぐことができます。ですが、SE は技術の詳細まで必ずしも知っているわけではありませんし、必ずしも最初から知らなければならないわけでもありません。知識があれば問題は起こりませんが、知識が無くても問題を起こさないものが足りないというのが真の原因です。
その何かの一つが実現可能性の調査です。
実現可能性の調査というとフィージビリティスタディですが、この言葉はもっとマネージメント的な意味合いが濃い言葉です。テクニカルな局面では「それって本当にできるの?」ということを確かめることと考えてこの言葉を使うのもありです。標語としてフィージビリティスタディを胸にしまっておくとよいでしょう。
この調査を怠ると、初めて使用するとかで経験が少ない技術を用いたシステムは誰も気付かない原因で破綻する可能性が出てきます。これを防ぐには幾つかのパターンがあります。ぱっと思いつくのは次の二つのパターンです。
どちらが良いかは一概には言えませんが、僕は A をお薦めします。なぜなら小さなモデルでも作るためには B の要素が入ってくるからです。そして B だけではなかなか気付かないことも実際にやって駄目なら気付くことができます。開発ベンダーとより話が通じるようにもなるでしょう。
とはいうものの純粋 SE の集団だとそれも難しいかもしれません。その技術を用いるために必要になるその周りの技術もモデル作りのために習得する必要があるからです。例えば先ほどの AJAX の例ですと、JavaScript の AJAX 関連のところだけ習得すれば確かめられるわけではなく、JavaScript 全体の基本的なことも使える程度に知らなければなりませんし、その JavaScript を乗せる web ページを書くために HTML や XHTML も知らなければなりません。また、受け側のサーバを作るために PHP や Perl あるいは Java を知らなければなりませんし、Apache などの HTTP サーバプログラムも知らないとなりません。実際の開発経験がないのならこれらを全部ある程度習得しなければならないのです。純粋 SE にそんな暇は無いでしょう。(もちろん自己研鑽のために自宅で勉強している人もたくさんいると思います)
じゃあどうすればよいのか。
自分にできないのなら他人にやらせるのです。その技術に詳しい SE を他所の部署から引っ張ってくるのでもよいです。社内にそういう人材がいなければ仕様策定段階で開発ベンダーの要員を連れてくればよいのです。開発ベンダーは開発ベンダーでお客さんである SE 集団と対面する人は大抵の場合 SE という立場にある人で、自分達と同じような人員かもしれません。実現可能性の調査や実現可能性がある仕様策定のサポートのためだけに開発ベンダーの協力を仰ぐのではなく、その後、実際の開発を依頼する前提の方がよいでしょう。その後自分達が実際に開発するのであれば、全体として実現できないような仕様を作ってしまうと自分達の首を絞めることになりかねません。責任をもって臨んでくれると期待できます。
開発ベンダーの都合もありますし予算もあるでしょうから、それも適わないときもあるかもしれません。そういうときはある程度経験を積んだフリーランスかそれに近い立場の人で、その方面に詳しい人を一本抜きで連れてくるという手もあります。デベロッパー色が濃い SE がいると便利ですよ。開発ベンダーとの会話で純粋 SE では気付かないような設計のミスを事前に見抜けたりしますし、抜け落ち開発項目があったら作ってくれますし、いざとなったら開発ベンダーに乗り込んで一緒にデバッグもできます。
ん〜、要するに僕を雇うならもっと早く雇えということです。あは。