エンジニアは日々現場で学ぶ

開発現場で学べること
第7回 開発現場のコミュニケーションを高める3つの方法

クロノス 山野寛
2004/6/4

エンジニアにとって最も大切なことの1つが、開発現場での経験だ。それがエンジニアに多くの知識と勘をもたらす。そんな開発現場で若きエンジニアが失敗し、そこで何を学んでいくか。それを毎回紹介したい。

開発現場でのコミュニケーションとは

 前々回(「第5回 開発中のトラブルは必然と考えよう」)と前回(「第6回 開発存続の危機で分かったSEに必要なスキル」)で、われわれのプロジェクトで発生したトラブルについての話をした。「人の不幸は蜜の味」という言葉があるように、他人の失敗話を聞くのは案外楽しいものではあるし、読者の中にはこの連載にそれを望んでいるかもしれない。中にはこれまでの話の流れから、われわれのプロジェクトが「失敗プロジェクト」に違いないという烙印(らくいん)を押した方もいるのだろうか。そのような読者の期待(?)を裏切るのは非常に申し訳ないが、今回のプロジェクトはとても順調に進んでいる。

 確かに、開発では連載で紹介している以外にも数々のトラブルが発生しているのは事実だ。しかし、プロジェクトは順調なのだ。筆者にはその原因が分かっているつもりである。あえて稚拙な言葉で表現すると、それは「明るく楽しい現場」だからである。今回の現場はメンバー同士とても仲がよく、活発に意見が交わされ、常に活気がある。つまり、プロジェクト全体のコミュニケーションがうまく取れていることが成功の一番の要因だと筆者は感じている。

 コミュニケーションが活発であれば、各メンバーの考えや作業の進ちょく状況の把握、またプロジェクト全体がいまどのような状態にあるのかが察知しやすくなる。例えば、メンバーが実施したテスト結果に関していえば、テストを行った人物がどのような性格であるかを一考することによって、確認しなければならないポイントが絞られてきたりもするのだ。

 第6回で紹介したトラブルに関しても、コミュニケーションが足りずに発生したことを踏まえ、即座にプロジェクト全体に対してその原因と対応策を伝えることによって、無事乗り越えることができたのである。このように、現場でのコミュニケーションは非常に重要である。今回は、筆者が開発において最も重要視している「プロジェクトにおけるコミュニケーションの向上」について述べたいと思う。

現場でのコミュニケーションの重要性

 初めに、筆者が開発現場におけるコミュニケーションの重要性を実感した次のエピソードを聞いていただきたい。

 これは筆者がまだプログラマとして仕事をしていたころの話である。その現場は開発メンバーが30人以上の比較的大規模な開発であり、筆者は製造フェイズからの参画となった。それまではいくつかの小〜中規模開発しか経験したことのなかった筆者にとって、その開発の規模とメンバーの多さには驚いたのだが、それ以上にショックを受けた出来事があった。

 参画の初日、開発のリーダーに声を掛けられ、いきなり「取りあえずこれをやってくれ」といった感じで仕事を与えられたのだ。つまり、自己紹介や参画しているメンバーの紹介はまったくなかったのである。それまで経験してきた現場では、初めに開発メンバーに対して自己紹介をし、ほかのメンバーがどのような役割でどういった仕事をしているのかという話が必ずあったものだが、その現場では特にそれらしいことはせず、いきなり作業をしてくれといわれたことに、正直筆者は不安を感じた。

 しかし当時筆者は経験も浅く、分からないことも多かったため、誰に質問すればよいのかさえ分からない状況で作業を行うのはよくないと思い、リーダーに

「メンバー紹介をしていただけませんか」

と伝えたところ、

「いまはちょっと忙しいから、取りあえず座席表でも見ておいてよ」

と軽くあしらわれたのである。その後も一向にメンバーに紹介されることがなかったため、開発メンバーの名前や役割を覚えるのにも時間がかかり、日がたつにつれ筆者のモチベーションは下がる一方だった。その後筆者は、とある都合によって開発途中で現場を離れることになったのだが、後から聞いた話によると、開発は失敗に終わり大きな損失を出してしまったらしい。

 しかしいま思うと、このような開発現場では、開発に失敗して当然だと感じる。コミュニケーションの第一歩である自己紹介やメンバー紹介を軽んじていては、プロジェクト内の意思疎通が図れるはずもなく、メンバーのモチベーションが上がるはずがないからだ。

 このエピソードからも分かるとおり、開発においてメンバー間のコミュニケーションの重要性は非常に高い。少し大げさないい方かもしれないが、

プロジェクトの成功は、いかに現場のコミュニケーションを向上できるかにかかっている

と筆者は思う。当然、この意見に対して「周知の事実だ」と考える方は多いだろうし、実際にコミュニケーションを向上させるためにさまざまな工夫をしてきた方もいるだろう。筆者もいままでに、現場を活性化するためのいろいろな手段を考えてきたのだが、今回は筆者がいまの現場で行っている効果的なコミュニケーションの向上法を紹介しよう。

コミュニケーションの根本とは

 今回紹介する方法はコミュニケーションの根本から考えたものである。IT業界に限らず、ビジネスにおいて最も重要なスキルを「コミュニケーションスキル」だという人は多い。しかし、コミュニケーションという言葉自体は、人によってさまざまなとらえ方があるようだ。

 例えば、面白いことをいって人を笑わせるのが得意な人や、人前で演説やプレゼンテーションをするのが得意な人は、コミュニケーションが上手だと思う人もいるだろう。しかし、筆者はコミュニケーションという言葉の根本は

相手が考えていることや望んでいることを察知し、それに応じた発言や行動を取ること

にあると考えている。そのため、本当にコミュニケーションの上手な人は「話し上手」ではなく「聞き上手」であるとよくいわれる。相手の話の趣旨を理解し、それに対して適切な返答をする、これが本当の意味のコミュニケーションとされているからだ。

 以上を踏まえ、筆者が考える開発現場におけるコミュニケーションの向上は、

(1)メンバー同士に興味を持たせる
(2)プロジェクト全体に興味を持たせる
(3)技術者の知識欲を煽(あお)る

という3つを重視している。では、実際にどのようにしてそれを現場で実践しているのか、1つずつ詳しく説明していこう。

メンバー同士に興味を持たせる

 今回の現場では、参画初日に自己紹介と各メンバーの名前や役割を説明する場をプロジェクトマネージャ(PM)が設けてくれたため、すんなりと作業に入ることができた。上記で述べたように、コミュニケーションとはつまり「相手が考えていることや望んでいることを察知する」ことが前提であり、「自分を知ってもらう」、そして「相手を理解する」ことがコミュニケーションの第一歩である。お互いを理解し興味を持つことによってコミュニケーションは自然と向上する。このことをPMやリーダー、われわれSEの観点からいい換えると、

いかにしてメンバー同士に興味を持たせるか

ということに尽きるのではないだろうか。われわれはこれを実現するために次のような方法を用いている。

 今回の開発では、XPで推奨されているスタンドアップミーティング(立ったままミーティングを行うこと)を毎朝15分程度実施し、現時点で完了したタスクや作業中に発生した問題点、当日実施するタスクなどを報告する場を設けている。その中で、十数人いるメンバーの中から立場を意識することなく、ミーティングの進行役を日替わりで指名してミーティングを実施するのだ。また、議事録担当も日替わりで指名し、いわゆるミーティング全体がラウンドロビン形式で実施されるようにしている。これはプロジェクトのリーダーと筆者が考えたコミュニケーションを向上させるための非常に効果的な方法である。

 メンバー全員の前である役目を負わせることによって、その人がどういう人物なのかといった情報を出力でき、ほかのメンバーはその人に対して興味や関心が生まれる。また、本人が周りから認知されていることを自覚することによって、さらにほかのメンバーに対する興味や関心が生まれるという、いわばコミュニケーションのチェイン(連鎖)が出来るのである。これは、メンバー間のコミュニケーションをより活発にする原理でもある。おとなしく自己主張をしない、いわゆる「オタク」が多いといわれるIT業界においては、各メンバー間に興味を持たせるにはこういった多少強引な方法でコミュニケーションのチェインをつくるのが適しているのではないかと筆者は考えている(図1)。

図1  情報の出力によるコミュニケーションのチェイン(連鎖)

プロジェクト全体に興味を持たせる

 メンバーの開発へのモチベーションを向上させるためには、プロジェクト全体に対して興味を持たせることが重要である。筆者もさまざまな現場を見てきたが、どの現場も「上流は上流、下流は下流」といったように、分析者/設計者とプログラマの隔たりが大きいように感じる。特にプログラマは、上流工程のエンジニアとあまりコミュニケーションを取らずに、業務を理解することなくプログラムを作成しているケースが多い。こういった現場では、「仕様と違うプログラムが出来上がる」ような問題がたびたび発生する。それを防ぐためにも、上流工程と下流工程は各現場をよく理解し、興味を持つことが重要となる。

 今回筆者とともにシステムの設計に携わっているSEのSさんは、スキルや考え方に偏りがなく、とてもバランスの取れた人物である。業務やモデリング技術にも精通し、プログラミングという部分においても知識は豊富である。そんなSさんはある程度作業に余裕があるときに、次のような方法でプログラマに対して製造依頼を行うのである。

 Sさんはまず、プログラマとの打ち合わせの際に、開発対象となるユースケースの説明を行う。そこで業務の流れを簡単に説明した後、すでに完成している分析モデルとは別ものとして、その業務の簡単な分析モデリングを実施するのである。そこではSさんが1人でモデリングを行うのではなく、プログラマの意見を聞きながら一緒にモデリングを進めていき、最終的にはすでに作成してある分析クラス図と同じ結果になるように導くのがポイントである。モデリングがある程度思いどおりになったところで、作成した設計クラス図を説明し、実際の製造依頼を行うのである。

 このようなやり方は、業務にもプログラミングにも精通したSさんのような技術者でなければ実施するのは難しいかもしれないし、製造依頼にそれほど時間を費やすことはできない現場が多いかもしれない。しかし、分析を行った末にプログラムへと実装されるまでの過程を経験することによって、プログラマは必ず上流工程を含めたプロジェクト全体に興味を持つようになる。プロジェクト全体に興味が持てると、自然と上流工程と下流工程の垣根はなくなり、プロジェクト全体のコミュニケーションはより活発になるだろう(図2)。

図2 分析モデリングを用いた製造依頼の手順

 われわれSEはプログラマに対して単に製造依頼を行うだけではなく、コミュニケーション向上という観点から、実際にプロジェクト全体に興味を持ってもらえるように仕向けるのも1つの責務ではないだろうか。

技術者の知識欲を煽る

 筆者は現場でよく遊んでいる。遊んでいるといっても仕事を放棄しているわけではない。メンバーのモチベーションを上げるための「ちょっとした遊び」をしているのだ。

 例えば筆者は、少しの合間を見つけて、メンバーに次のような話を持ち掛ける。

 「どうやったらモデリング技術が上達するのかな。」

メンバーA 「やっぱり、いろいろなものをモデリングしてみるのが一番近道じゃないかな」

 「いろいろなものか……。だったら『焼き鳥』をモデリングしてみようか」

メンバーA 「焼き鳥をモデリング!? 案外面白いかもしれないね」

 「例えば焼き鳥の『鳥肉クラス』と『串(くし)クラス』は多対1の関係にあるよね」

メンバーA 「いや、中には串が2本以上刺さっているものもあると思うよ」

 「そうか、多対多になるのか。しかし、この関係には何かルールがあるかもしれないなぁ」

メンバーA 「もしかしたら、調理方法によって串が増えるのかもしれないね」

 「じゃあ、『調理方法クラス』が『鳥肉クラス』と『串クラス』の関連クラスになるのかな」

  このような話をしながら遊び感覚でモデリングしてみるのである。これは筆者が最近、「高度な技術を使って『無駄』なことを行うことを面白いと感じるエンジニアが多い」と感じ、その「エンジニアの性質」を利用したものである。人間は面白いと感じるものに対しては異様なまでのモチベーションを保つことができる。上記のような遊びは、技術を用いて身近なものをモデリングすることで技術への興味を煽り、モチベーションとコミュニケーションを向上させることを目的としているのである。メンバーの作業への向上心が低下していると感じたときは、筆者はここぞとばかりにこのような話をするのだ。

PMやSEが果たすべき役割とは

 筆者はもともとおとなしい性格ではない(むしろ騒々しい)のだが、今回の開発メンバーには性格が明るい人が多い。しかし現実は、性格が明るいからといって現場のコミュニケーションがうまくいくとは限らないのも事実だ。やはりPMやSEが常に現場のコミュニケーションを向上させるような努力をしていかなければならないだろう。今回話した方法をそのまま皆さんの現場で採用することは難しいかもしれないが、上記に述べた「相手が考えていることや望んでいることを察知し、それに応じた発言や行動を取ること」というコミュニケーションの根本を考えながら、プロジェクト全体を活性化する方法を日ごろから模索してみてはどうだろう。そして、もしその方法が効果的だと判断できれば、プロジェクトの成功のために活用していただきたい。最後にあえてもう1度いわせてもらうと、

プロジェクトの成功は、いかに現場のコミュニケーションを向上できるかにかかっている

のである。

筆者プロフィール
山野寛(やまのひろし)●クロノスに勤務するシステム・アーキテクト。立命館大学理工学部 卒業。クライアント/サーバからWeb系システムを中心にいくつかの開発現場に参加し、ここ数年はJ2EEをメインとしたオブジェクト指向開発にアーキテクトとして設計から携わっているという。

自分戦略研究所、フォーラム化のお知らせ

@IT自分戦略研究所は2014年2月、@ITのフォーラムになりました。

現在ご覧いただいている記事は、既掲載記事をアーカイブ化したものです。新着記事は、 新しくなったトップページよりご覧ください。

これからも、@IT自分戦略研究所をよろしくお願いいたします。