バグだらけのプログラム，動いても使えない情報システム----脚光を浴びているIT業界だが，現場で働く技術者の方なら，このようなソフトウエアの品質上の問題が頻繁に発生していることは，よくご存知だろう。ハードウエアの性能が向上し，さまざまな開発方法論が登場して開発ツールも機能アップしているというのに・・・。いったい，どこに原因があるのだろうか。

　原因はいくつか挙げられるだろう。たとえば，「ここ数年の技術革新の猛烈なスピードが原因だ」という見方がある。システムの構造が目まぐるしく変わり複雑になるにつれ，技術者が学ぶべき新しい技術は次々と増える。それに比例してユーザーの要求はますます厳しく，納期もどんどん短くなる。短時間に多くのこと（それもたいていは新しいこと）をやろうとすれば，品質を維持しにくくなるのも当然---というわけだ。

　確かにもっともな意見だが，筆者はあえて異論をはさみたい。猛烈な技術革新の渦中にあっても，立派に成功をおさめているプロジェクトが少なくないからだ。では何が，成功と失敗を分けているのか。成功チームに，たまたま優秀な人材が揃っただけなのだろうか。

　筆者が注目しているのは，開発チームにおける人と人との関係，すなわちコミュニケーションである。ユーザーとSE，SEとプログラマなど，開発プロジェクトにかかわるすべてのメンバーのあいだの関係だ。

　例えば，うまくいかない（いかなかった）開発プロジェクトでは，責任のなすり付け合いが行われることが少なくない。SEは「プログラムのバグに原因がある」と言い，プログラマは「設計に不備があったからだ」と嘆く。あるいは，営業が「ムチャな納期や要件で受注したからだ」とか，「トップが何もわかっていないからだ」といった話もよく聞く。「こんな安月給ではやってられない」なんて愚痴も出るだろう。結局，みんな人のせいにする。

　実はこの構図，メインフレーム開発の時代からWebシステム開発の現在まで，ずっと変わっていない。プロジェクトの大小とも関係ない。技術や開発規模とは別の次元の問題なのだ。

　ソフトウエア開発の問題を，人間関係のコミュニケーション問題として取り上げた名著に，構造化分析手法で有名なTom Demarco氏の「ピープルウエア」（日経BP出版センター）がある。Demarco氏はそのなかで，「ソフトウエア開発の問題は，技術より人にある」と述べた。

　原著は1987年初版だが，14年経った現在，問題は解決しただろうか。確かにオフィス環境やマシンの設備などは改善したかもしれない。しかし，本質的な問題であるコミュニケーションの問題は，むしろここ10年の技術革新や社会環境の変化の影に隠れて，より深刻化してしまったのではないか。

　ユーザーと技術者，SEとプログラマのあいだにあるコミュニケーション・ギャップは，前述のように何も変わってない。欧米的なドライなビジネスがもてはやされる現在では，「よりトゲトゲしくなっている」と言えるかもしれない。特に，下請け的になりがちなプログラマの立場は弱い。

　筆者は別に，コミュニケーション・ギャップがなくなればすべての問題が解決する，と言いたいわけではない。技術者に対する教育や報酬の問題も大切だろう。しかしコミュニケーションの問題は，それらに比べると軽視されてきたテーマだと主張したいのだ。理由は簡単。難しいからである。

　それでも，コミュニケーション・ギャップを埋めて，ユーザーやSE，プログラマ間で納得のいくモノ作りが展開できれば，つまらない品質上の問題のいくつかを解決することができるはずだ。

　具体的な手法も考え出されている。例えば，最近注目を浴びているソフトウエア開発手法「XP（エクストリーム・プログラミング）」では，二人のプログラマが一つのコードを書く「ペアプログラミング」や，顧客（ユーザー）をフルタイムで開発に参加させる「オンサイト顧客」などの手法が提唱されている。いずれも，開発工程のなかに“メンバーがコミュニケーションせざるを得ない”状況を作り出そうという試みである。

　ソフトウエア開発におけるコミュニケーションをどう考えるべきか。そして，どうすればコミュニケーション・ギャップのない開発ができるのか。ソフトウエア開発の中で“人”をどう扱うべきかを，真剣に議論してもよい時期にきていると思う。

（真島　馨＝日経ソフトウエア編集）