個人事業主にしてベテランプログラマー。人呼んで「IT業界の小関智弘」(?)

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

»

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

 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業界は技術革新が早いので、知識が古びるのも早い。ですから知っている人は、その知識が古びないうちに教えなければ結局、損をします。だから技術者はたいてい「教えたがり」です。そしていつか自分が質問される立場になったら、こころよく教えてあげてください。そんな小さな心掛けが、やがては業界を変えていく力になるかもしれないのです。

Comment(9)

コメント

anaka

これが理想であれば、ウチは割とそれに近いですね。
パッケージソフトと自社サービスの開発のみで、受託開発はしていないのでできるのかも知れません。

Java J2SE のエントリレベル(アソシエイツレベル)の田所です。

職業訓練校の教師から、クラス=鯛焼きの型、インスタンス=鯛焼き、と教わりました(笑)実際の鯛焼きを想像すると、逆にややこしいのですが(苦笑)僕はそんなふうなレベルです(笑)

まあ、インフラ屋さんなので、実務で言語を扱うことはほとんどないのですが、今回のお話、非常にためになりました。また、年齢の話は禁句かも知れませんが、それでもなお現役を続けられていることに敬服いたします。では。

インドリ

コミュニケーションは重要だと思います。
しかし、日本ではそれを妨げる風潮がかなりあります。
この記事に書いていないことを書くと「公私混同」です。
公私混同がよくありますから、正直な意見を言うと「私怨をもたれる」という結果になります。
仕事の事は仕事、個人は個人という「区別が」が日本にはありません。
他にも「派閥を作り闘争を繰り広げる」だとか・・・もう仕事しろといいたいです。
日本のホワイトカラーは生産力が低いというデータも頷けます。
あと精神論ばかり言うという点も大きいです。
開発で精神論ばかり言っても前に進みません。
そんなことより決めるべきことが沢山ありますし、そんな暇があったらエンドユーザーの意見を一つでも多く聞いてほしいです。
という風になって、「日本式コミュニケーション」はどうしてもやりたくなくなってしまいますね・・・
重要さは分かっていますが日本式コミュニケーションは仕事が前に進まないので、黙ってシステム構築する方が実際速いです。
独りで作ると大概のシステム3ヶ月~6ヶ月で構築できます。
しかし、多人数となるのと1年たっても仕様が定まらない状態になります。
ですから、プログラマに限らず、社会人全員が仕事用コミュニケーション術を学んで欲しいです。
※もちろん私自信も鍛錬が必要です。

エムワイ

またコメントさせて頂きます。

私もずいぶん前ですが、「enhydra」
というとても珍しいServletコンテナでの開発の時に
フレームワークを作ってくれた方のソースがとても美しかったです。
まったくstrutsの概念とは別だったのですが、うまくMVCで別けられており
私も最近まで小さなサービスなどにはこの概念を用いてプチフレームワークを作って活用しておりました。
そのプロジェクトで最初はそのフレームワークの概念がまったく解らず
何度もその方に質問しに行き、まだ若かった私は結構失礼な言い方などもしてしまいましたが、
理解出来た時には、自分のレベルの低さに恥ずかしくなりました。

コミュニケーションとはまったく関係ない話ですいません。

とうじょう

> C言語では1個のソースからは1個のプロセスが生まれるので、ほぼ完全な独立性を持っています。これを分けてプログラムするのはけっこう難しいことで、1人で作りこむには大変だからといって、作業を分担することはあまりしません。

この部分なのですが、「1個のソースからは1個のプロセスが生まれる」というのが全くの謎です。通常は分割コンパイルによって作業分担するのではないかと思います。C言語は大人数プロジェクトでまだまだ使われているはずですし。

コラムニスト後藤

とうじょうさんへ。

コメントありがとうございます。ご質問がありましたのでお答えします。

C言語も通常は分割コンパイルによって作業分担するのではないかとのこと。いわれてみるとそのとおりです。

JavaでもC言語でも、予想外に大きくなってしまったプログラムを途中から分割するのは至難の業です。最初から計画的に分割しておかなければ、あとからたいへんなのは変わりません。

ただC言語はJavaに比較すると、分割するのにかなり不便です。グローバル変数を使うと収拾がつかなくなりますし、関数の引数だけではインターフェースとしていささか不便です。

C言語は、もともとあまり大きなプログラムを作ることを想定した言語ではありません。小さな機能をコンパクトにまとめたプロセスを作り、shellでそれらをまとめて複雑な処理を行う、というのがUNIXの基本的な設計思想でしょう。

ただ制御系などでは、一つのプロセスがメモリに常駐して複雑な作業を行わなければならないケースが少なくないので、大規模なプログラムを分割して作ることも多いでしょう。そういった場合のご苦労はお察し申し上げます。

幸か不幸か、わたしが参加したC言語のプロジェクトは、数人規模で、機能を大きく分けた後はプロセス間通信をすることもなく、比較的閉じられた世界で実装しました。それゆえC言語でも大規模開発が行われているのだということに考えが及びませんでした。

ただこの文章の本旨は、C言語プログラマーは、プログラミング作業でJavaなどに比べてコミュニケーションをあまり必要としないということですので、このような表現になりました。ご理解ください。

とうじょう

返信ありがとうございます。

はじめに、ソフトウェアがコミュニケーションの産物であることは、100%同意です。ただ、このことが実装言語によって差が出るように書かれていることに対して、「!?」と感じた次第です。実装言語ではなく、プロジェクトの規模に依るのではないかと。

今やVBでも、アセンブリを分割するのは当然として、インターフェイスやクラスで分離しますので、作業分担に関してはJavaと何ら変わらないはずです。ましてや、VBやC#はパーシャルクラスに対応していますので、Java以上に作業分担がしやすいはず。CやVB(おそらくVB6以前ですね)では作業分担が困難で、Javaでは作業分担がしやすいというのは、たまたまそういうプロジェクトに当たっただけだと思います。

バグは境界に宿ることが多いので、境界となるものをきっちりと規定するのがセオリーと考えます。境界とは、JavaやC#であればインターフェイスだろうし、Cであればグローバル変数と関数とかだろうし、プロジェクトであればサブプロジェクト間のコミュニケーションといったものになるでしょう。この部分に(仕様上の限界はありますが)実装言語による差はないのではないかと思います。CやVBでも見事に分離されたものに当たったこともありますし、BASICみたいなJavaによる実装を見たこともありますし。

サブシステム単位やチーム単位では密なコミュニケーションが必要なはずで、これはJavaでもCでもVBでも何でも、実装言語に左右されるものではないと思うのです。

なんだか論旨から逸れてしまってすみません。

コラムニスト後藤

とうじょうさんへ。

再度のコメントありがとうございます。

開発現場のコミュニケーションが「実装言語ではなく、プロジェクトの規模に依る」とのお話、お説のとおりです。作業を分担する場合のインターフェースの重要性は、言語に関係なく考慮しなければならないのはもちろんのことです。今回のコラムの本旨も、現場の管理体制がコミュニケーションを阻害するようではトラブルの原因になるということを指摘することにありました。

ただプロジェクト分割で起こる問題点を、不用意に言語の特性になぞらえて説明してしまったために誤解が生じたのだと思います。論旨の進め方が不適切であったことをお詫びします。

またご指摘のとおりわたしのVBは相当古く、最新の技術事情を反映していませんでした。ご教示ありがとうございます。

これからも問題点がありましたら、遠慮なくご指摘ください。

下流からIT業界全部読ましてもらいました。小生46歳のprogramarです。それも日本語のプログラマではたぶんないと思います。46才ですが業界の経験10年ぐらい。筆者と同年齢ですが、筆者のような経験がありません。36歳の時に職種変更しました。10年間一環して、とあるベンチャー起業でリードデベロパーとして、C++, C#オブジェクト指向で開発してきました。筆者が書かれる日本のITの現場はその間約一年ぐらい、日本の受託開発も経験するべしと、転職して経験しただけです。実は一年でいやになってやめて、ふたたびベンチャーに戻って、現在はプログラミングづけの毎日です。私の開発現場ではまさに、プログラマ間のコミュニケーションを重要視し、ソースコードはコンピュータのためにあるのではなく、他のプログラマ、そして忘れたころに自分が後で読むときに楽なように、そしてコピーペースト厳禁、他人のプログラムはコピーペーストで利用すっるのではなく、リファクタしてそのものを自分が使えるように修正して使う、などとにかく、アジャイル的指向をそうでなかった世界どっぷりとつかっていたプログラマに繰り返し徹底させ、考えを変えさせることに苦労する毎日です。

はっきりいって、programarの世界はものすごい勢いで技術革新が進んでいます。オブジェクト指向は当然重要ですが、最近習得したFunction programingの考え、これマルチコアーCPUの時代には必須の技術です。明らかに私はSEよりprogramaの方が、高度な技術が必要な職業だと思ってます。そういった、技術をもつ本当のprogrammerが日本の現場で、大切に扱われるようにならないと日本のIT、この先真っ暗です。というか、私が快適に働ける、受託開発の職場が現れてくれないと、私のお先も真っ暗です。多くの人にこの記事を読んでもらいたいものです。

コメントを投稿する