プログラミングはコミュニケーションだ

スキル | 人間関係 | 職場

» 2008/11/10

　この業界で長年仕事をしていると、ほれぼれするようなソースコードを見ることがあります。

　JR系列のSIerに呼ばれて、とある業界団体が管理する観光スポット紹介サイトの改修を手がけたことがあります。PC用、携帯用のページはすでにあるから、それに加えてPDA用のページを作るというプロジェクトでした。面白みのない地味な印象のサイトでしたが、ソース解析を進めていくと、なかなか面白い仕組みになっているのがわかってきました。ブラウザからのリクエストが全部同じURLへ集まるようになっているのです。そのURLで呼び出されるServletが、要求されたページの種類ごとに別のURLにディスパッチするようにできている。

　これは有効な方法だと直感できました。まずなんといってもサーバ側のクラスが構造化されます。画面の要求する機能とは別の論理でクラスを構成することができる。それにサイトのURLを一元的に管理できます。ブラウザがアクセスする窓口が一箇所に絞られるのですから、リクエストを管理しやすい。セキュリティの面でも有効である。つまり今で言うところのMVCパターンで作られていたのです。まだStrutsが一般に知られる前でした。JavaのWebアプリケーションがJSPコードをHTMLの間にソースコードを埋め込むという形で作られるのが一般的だった時代です。これは勉強になる仕事だと思いました。

　しかしこのプロジェクトは突然打ち切りになってしまいました。きっとPDA用のページを作っても誰も読みに来ないだろうと判断されてしまったのでしょう。惜しかったけれど、結果的には私にとって勉強しただけ得になりました。ソースにはPGの名前と作成した会社の名前が記されてありましたので、いつか一緒に仕事をしてみたいなと思って会社名を手帳に控えておきました（いまだにそういう機会はありませんが）。ネットで調べると、横浜にある会社です。もしかしたらJR系の会社かもしれません。そうだとしたら、さすがはJR、グループ企業まで技術レベルが高い。

　こんな思い出話から始めたのは、べつにJRをヨイショすることが目的ではありません。この時のソースコードからは、それ以上に重要なことが読み取れたからです。

●プログラミング作業はチームワーク

　MVCパターンは、サイトで使うJavaクラス全体の大枠となるパターンです。これを採用しているということは、プログラミング作業の前に各PGがこのパターンの有効性を納得し、それに合わせて各クラスを実装したということを意味しています。つまりこのソースはPGの綿密な連携作業によって作られたということです。

　それまでプログラミング作業は個人技の世界でした。COBOLでは原則的にSEが仕様を切り分けました。切り分けられたモジュールは完全に独立した世界ですので、PGはプログラムを他人と共同して作るということはありません。C言語では1個のソースからは1個のプロセスが生まれるので、ほぼ完全な独立性を持っています。これを分けてプログラムするのはけっこう難しいことで、1人で作りこむには大変だからといって、作業を分担することはあまりしません。VBアプリケーションは断片化したソースコードが複雑に絡み合っているので、これも作業を分担するのはなかなかに難しい。そのためC言語やVBの開発では、特定のPGに過重な負担がかかって、工程が遅れるということが頻繁にありました。

　ところがJavaはインターフェイスを境にPGの作業をあらかじめ分担しておくことができます。そうすることで得られるメリットは計り知れなく大きい。

●インターフェイス概論

　ここでJavaを知らない人のために「インターフェイス」の説明をしておきましょう。Javaのソースコードは「クラス」と呼ばれる単位に分けて書かれます。クラスには「メソッド」が定義され、その中にそのクラスが持つ機能を具体的にコーディングします。実際にプログラムが作動するときは、このクラスをもとにメモリ空間にインスタンスを必要な数だけ作る、これがコンピュータを動かす実態になるわけです。インターフェイスはメソッドだけ定義したクラスのようなものです。これを使うときには、このインターフェイスをもとにしてクラスを作って動かします。

　いわばインターフェイスとは、形だけ作った中身のないクラスのようなものです。こんなものがどうして必要なのか疑問に思われる方も多いかもしれません。わたしも始めのうちはどのように使えばいいかわかりませんでした。それがようやく理解できたのは、Javaの仕事をするようになって1、2年してからでしょうか。

　インターフェイスとは要するに「接合面」なのです。ロボットを開発するとします。胴体と腕を分担して開発することになりました。まず最初にすることは何でしょうか。接合面の設計です。接合部分の形、寸法、信号端子の種類、電圧、信号体系等々。これらをあらかじめ決めておけば、胴体を作るチームと腕を作るチームは、互いに相手のことを知らなくてもそれぞれの部分の開発に専念することができます。また接合面の規格を守っていれば、別の腕を付け替えることもできる。合体ロボットのように次々とアイテムを変更することも可能です。すなわちインターフェイスは部品を規格化するのです。これを有効的に使うことで大規模システムは整理され、分担して作りやすくなりますし、開発後のメンテナンスも容易になります。

　ですから大規模なシステムでは、何よりも先にインターフェイスを設計することが重要なのです。開発が進んでからでは、インターフェイスを適用するのは極めて困難です。あらかじめ全体の構成を見渡し、規格化できるパターンがあったら、そこにインターフェイスを作っておく。そうすれば複雑なシステム全体が部分部分に分けやすくなり、ロジック自体がパターン化されて、コーディングの量自体も減ります。できれば基本設計の段階でインターフェイスを決めておきたいところなのですが、このことについては十分理解されているとはいえないのが現状です。

●コミュニケーションの必要性

　話題をもとに戻しましょう。実装作業の分担の話でした。個人で作ることができる機能はおのずから限界があります。機能の規模が大きくなればなるほどバグの数は増えていきます。ですから1つの機能を分担して作ることは、大規模アプリケーションを作るときの必須の条件なのです。さらに開発の状況に合わせて人的資源を機動的に使うことができるようになる。ユーザーの気まぐれで急な仕様変更があっても、柔軟に対応できる。すなわちJavaにおいてはプログラミングとは個人技ではなく、綿密なチームワークを必要とする共同作業に変わったのです。

　私がこれまでの開発経験から考える理想的なシステム開発の現場は次のようなものです。5人から10人までのPGがチームを組み、机を並べている。そばにはいつでも使える会議スペースがあり、ホワイトボードが用意されている。開発が始まると、まずクラス構成を綿密に打ち合わせる。ホワイトボードに絵を描きながら、ああでもないこうでもないを繰り返し、やがて総員納得の上で全体のクラス構成を決定し、実装の技量にそってコーディングを分担する。コーディングが始まっても、いつでも必要があればすぐチームミーティングを持つ。システムの変更事項はそこで周知徹底する。こんな開発体制を組めたなら、どんな大規模システムの実装が来てもこわくはありません。

●開発の現状は

　しかしWebアプリケーション開発の現場は、たいていの場合これとはほど遠い現状にあります。PGはたいてい別の会社から呼ばれてきて、互いに交流はありません。配属された先のSEのいうことを聞かなければならないことになっています。PG同士でミーティングを持ったりすると、何かと誤解されます。またPGは個人で仕事をすることが多く、共同して仕事をするという経験が少ないので、他人の意見を積極的に聞こうということもありませんから、その仕事はなおさら孤立したものになります。

　頻繁にミーティングを開いて打ち合わせをするのはSEさんたちですが、プログラミングをあまり知らないSEは、ユーザーの要求を実装者に伝えるだけの単なる「御用聞き」になってしまいがちです。業務の内容に合わせてクラスを設計するなどという高等技術は身についていません。ミーティングは、プロジェクトマネージャから進捗を問いただされ、仕様変更があったことを上意下達的に言い渡されるだけの場になっています。クラス構成を話し合うとか、さっきも触れたインターフェイスを作るとか、テストプランを練るとか、そういったソースコードの品質にかかわる話し合いが行われることはほとんどありません。このような体制で作られるプログラムがオブジェクト指向であるわけはありません。画面からのリクエストごとに1メソッドが動き、そのメソッドに一切合財の機能を盛り込んでしまう、ということになります。

●ウォーターフォール型開発とアジャイル開発

　これまで大規模なソフトウェアが作られる場合、基本設計で大まかなことを決め、機能をいくつかのブロックに分け、細分化するごとに仕様の詳細を決めていくというトップダウンの設計手法がとられてきました。水が下に流れるように設計が進められるということから、これをウォーターフォール型の設計といいます。細分化されたプログラムが相互に関連を持つことがあまりないCOBOLのようなシステムならこれは有効です。しかしオブジェクト指向のJavaはそういうわけにはいきません。これではクラス設計をするPG（あるいはSE）のところに来る前に仕様が断片的になってしまいます。設計者がその能力を持っていても、これでは実力の振るいようがありません。

　ウォーターフォール型の開発がJavaに向かないことは、すでにだいぶ昔から指摘されてきたことです。アメリカではその反省から、PG相互のコミュニケーションを密接にし、開発のスパンを短く繰り返すことで、実装者とユーザーの距離を短くし、ユーザーの気まぐれな要求変更に対応しようという手法が開発されました。これをアジャイル開発といいます。この開発方法の有効性はすでに実証されています。にもかかわらず日本ではこの開発手法が行われることはめったにありません。

　その理由はよくわかりませんが、次のようなことが考えられます。まず日本のユーザーにはドキュメント信仰があります。ソフトウェアはただでさえブラックボックスになりやすく、ブラックボックスになったら最後、改修も再利用もできなくなると信じられています。だからドキュメントはできるだけ詳細に残してもらいたい。アジャイル開発ではどうしてもドキュメントは軽視される傾向にありますので、ユーザーには不評なのかもしれません。

　しかし実際には、詳細すぎる設計書などシステム開発では無用の長物。ソースコードさえきちんと管理されて残っているなら、そのシステムはブラックボックスでもなんでもないし、きちんとしたスキルのある技術者を呼べば、システムは必ず生き返ります（問題はその様な技術者をどうやって調達するかということになります）。

　もう1つは、アジャイル開発は「管理しにくい」と思われているからではないでしょうか。アジャイル開発は、開発技術者が直接ユーザーから要望を聞いたり、技術者同士で頻繁にミーティングを行います。現場から遠ざかって技術に疎くなったPMは、これらのミーティングを仕切りきれません。設計会議から疎外された管理者は「下っ端が集まって造反をたくらんでいるのでは」と不安になりがちです。ましてやアジャイル開発で鍵を握るのは、これまで冷遇してきたプログラマ、会社では要らないからできるだけ外注で調達してきた職種です。自社の請負業務が全部外注の人間で決定されるとなったなら、おもしろかろうはずがない。

●大事なのはコミュニケーション

　別にアジャイル開発を導入しなければならないというのではありません。プログラミングで重要なのはコミュニケーションです。PGは端末に向かって黙々とコーディングとバグ取りをしていればいいというのは昔の話です。理想的なプログラミングは、ちょっとコーディングをしていたかと思うと、立ったり座ったり、同僚と話をしたり、はた目から見ると、まるでまじめに仕事をしていないかと思われるかもしれません。しかし実際には彼らは仕事の上で重要な情報やアイデアの交換をしているのです。こうしてコミュニケートすることで、仕様に対する誤解を修正し、設計過程で見逃した不整合を見つけやすくなります。また、自分のソースコードに対して他人の批評を受けることで、わかりやすく利用性の高いコードが作られていきます。他人と話し合うことで新しい発想も生まれてくる。解けなかった問題が解けてしまう。まるで大学のセミナールームか、工業高校の実習室のような雰囲気、それこそが高い生産性を実現する作業環境なのです。Javaのようなオブジェクト指向言語では、他人が作ったソースコードをいかに有効に利用することができるかが生産性向上の鍵になります。プログラムのような形のないものを相互に利用し合うには、このような気軽で親密なコミュニケーションのできる環境、人間関係が何よりも必要なのです。

　まあ、実際このような開発をしたことがあるわけではありません。日本のソフトウェア開発現場は、さきほども述べたように、このような雰囲気とは対極的な環境にあります。だだっ広い部屋の一角に端末がところ狭しと並べられ（最近は机1つさえ満足に与えてもらえません。折りたたみテーブルにいくつも端末だけ置いて、ほとんど肘を突っつきあうような場所で何カ月も作業させられます）、それぞれ別の会社から派遣されたPGが、それぞれ隣の人の名前も知らずに（ときどき隣の人は日本語を話せないこともある）、与えられた仕様書を黙々と実装しているだけ。こんなタコ部屋現場が多いのではないでしょうか。

　プログラミングの現場でコミュニケーションが足りないのは、もちろんSIerの管理方法にだけ原因があるわけではありません。技術者の方にも責任があります。概して腕のいい技術者ほど寡黙なものです。口を動かすより手を動かして、自分で結果を出すのに夢中になるので、チームワークをおろそかにしがちです。それに熟練したPGは独学でスキルを身につけてきた場合が多く、教えたがりなわりには、進んで他人と情報交換をしようとしない。その点では学校でプログラミングを勉強してきた人間が多いアメリカとは土壌が違うのです。日本のPGがいきなりアジャイルな開発環境に放り込まれても、きっととまどうばかりでしょう。

●もっとおしゃべりしましょう

　このような現状を変えていくのは、やはり管理者の責任であり、年配者のつとめでしょう。プログラミング作業でのコミュニケーションの重要性は、アジャイル開発、ウォーターフォール型開発にかかわらず有効です。このコラムをお読みのあなたがPMならば、毎日ミーティングを開くばかりでなく、頻繁にPGの肩を叩いて声をかけてあげてください。最初は内心いやがられるかもしれません。しかし相手が自分の仕事の内容に親身になって関心を持ってくれているのだとわかれば、やがて態度は変わってきます。声をかけるときは単に進捗ばかりに関心を持ってはいけません。プログラムの中身についても突っ込みを入れてみましょう。未熟なPGなら足りない部分を指導してあげてください。優秀なPGならたいてい自分の作品について自慢したいところを持っていますので、そこをほめてあげてください。また、彼らはプロジェクトについていいアイデアを持っていたりします。それを会議の場では言い出せずにだまっていたりします。それを吸い上げるのにもいい機会です（もちろんこれらのためにはPMがプログラミングについて熟知していなければならないのですが）。とにかく重要なことは、少しでもコミュニケーションの頻度を上げることです。

　コミュニケーションが増えれば、必ずプロジェクトにプラスになります。一見むだ話に見えるかもしれませんが、それが目に見えないところで効果を持ってくるのです。過去に失敗したプロジェクトのことを思い出してください。それは開発者全員が押し黙り、互いに背を向け合ったような、沈滞したプロジェクトではありませんでしたか？ メンバーが死人のように口をきかず破滅に向かって進んでしまうので「デスマーチ」というのです（ちょっとちがうかも？）。

　若いPGの皆さん。もっとおしゃべりしましょう。ひとりで黙々と開発する時代は終わりました。わからないことは積極的に他人に質問しましょう。知っていいる人はたいてい教えてくれます。教えてくれないのは、答えを知らないからです。IT業界は技術革新が早いので、知識が古びるのも早い。ですから知っている人は、その知識が古びないうちに教えなければ結局、損をします。だから技術者はたいてい「教えたがり」です。そしていつか自分が質問される立場になったら、こころよく教えてあげてください。そんな小さな心掛けが、やがては業界を変えていく力になるかもしれないのです。