エンジニアは日々現場で学ぶ
開発現場で学べること
第2回　スーパーコンサルタントはここが違う！

クロノス 山野寛
2003/11/28

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

■プロジェクトを成功へ導く人々

　開発現場には、そのプロジェクトを成功に導くことを職務とする人物が必要である。多くの場合、PM（プロジェクトマネージャ）やPL（プロジェクトリーダー）と呼ばれる人物がその役割を担う。彼らはプロジェクト全体のマネジメント、例えばスケジュールやリソースの管理、エンドユーザーとの折衝などによって、プロジェクトを成功に導こうとしている。

　一方で、業務改善の提案やプロジェクトに最適な開発プロセスの策定と導入、エンドユーザーの要求に即したアーキテクチャの選定などを行うことによって、プロジェクトを成功に導くことを職務としている「コンサルタント」と呼ばれる人たちが存在する。優秀なコンサルタントが参画しているプロジェクトであれば、多くの問題や課題に対する解決策の助言をしてもらうことによって、プロジェクトがスムーズに進むことも多い。もちろん、コンサルタントと呼ばれる人たちのすべてが高いスキルを持っていて、プロジェクトにとって最高の提案をしてくれるというわけではないだろう。

　では、われわれエンジニアから見た「理想のコンサルタント」とは、いったいどのような人間像を指すのだろうか。「第1回 忙しいのはユーザーだ」で紹介したプロジェクトに参画しているコンサルタントA氏の言動から、その答えが導き出せるかもしれない。

■あるコンサルタントの話

　A氏は開発プロセス（RUP）やオブジェクト指向開発のスペシャリストであり、私が今回のプロジェクトで非常に信頼しているメンバーの1人である。

　われわれエンジニアは、開発を進める中で困ったことや知りたいことがあれば、まずはA氏に相談する。そのため、A氏の周囲にはいつも人が集まっている。そのことを裏付ける次のようなエピソードがある。

　先日、A氏はある新人のエンジニアにデータモデリングに関してのアドバイスをしていたが、その話を近くで聞いていた別のプロジェクトのエンジニアたちが次々とA氏の周りに集まり、気が付けば十数人ほどで「モデリング勉強会」が始まっていたというのだ。このことからも、本プロジェクトにおいてA氏の影響や信頼性は非常に大きいことがうかがえるだろう。

■エンジニアのプライドを決して傷つけない

　さて、私は幸運にも普段A氏の隣の席に座っている。そのため、日々ここぞとばかりに質問を投げ掛けているが、おかげでA氏がそれだけの信頼を得ている要因がいくつか見えてきたような気がしている。

　まず、人の考えや発言を絶対に否定しないということである。

　私は現在、業務のモデリングである「分析クラス図」の作成を行っているが、経験不足も手伝い、なかなかうまい具合にモデリングが進まないことも多い。そういった場合は、一度A氏にその成果物をチェックしてもらうことがある。以下はそのやりとりの一部である。

私　　「Aさん、分析クラス図を作成したので見ていただけますか」 A氏　「ええ、いいですよ」 私　　「これですが……」 A氏　「なかなかいいですね。えっと、このクラスにある『債務状態』ってどういう属性ですか」 私　　「クラスの状態を表すためにこの属性が必要かと思ったので追加しました」 A氏　「なるほど、そういう意味ですね。うーんと、どうしようかな」 私　　「なんか変ですかね？」 A氏　「いや、まったく変じゃないですよ。モデリングに正解はないですしね。そうですね、ここの部分は『債務別状態クラス』を作成して、集約関係にするという表現もできそうですね。基本的な意味は同じだと思うのですが、こういう形であれば分かりやすいかもしれません」

といったような感じで、A氏は笑顔で応えてくれます。読んで分かるように、この会話の中には私の作成した分析クラス図や私自身の考えに対して否定するような言葉は見当たらず、聞いている私もまったく不快に感じない。むしろ私は「なるほどなぁ」と素直にうなずいてしまうのである。

　逆に、次のような会話であればどのような印象を受けるだろうか。

Z氏　「このクラスに『債務状態』ってあるけど何のための属性？」 私　　「クラスの状態を表すためにこの属性が必要かと思ったので追加しました」 Z氏　「この場合の状態は属性にしない方がいいよ。拡張性が悪くなるから。普通こういう場合は『債務別状態クラス』を作成して集約関係にするんだよ。その方が拡張性もあるし、分かりやすいから」

　さて、どうだろう？

　後輩やほかのエンジニアから質問されたとき、後者のようない言い方をしていないだろうか。少なくとも私はこのようないい方をした経験はたくさん思い当たる。プライドの高い技術者はこれだけで不快感や不信感を持ってしまうかもしれない。そしてそれが度重なると「この人にはもう聞きたくない」と思うようになるかもしれない。

　このようにA氏は、常にエンジニアのプライドを傷つけないようないい回しをするため、どんな細かいことでもすぐにA氏に相談できるのである。

■謙虚な姿勢

　先日、私がユースケースの「アクター」という概念についてA氏と話していたときのことである。

私　　「私はアクターというものは、ユースケースから何かしらの『利益』を得るものがアクターであるという認識を持っているのですが……」 A氏　「そうですね。それが最も明確なアクターの定義でしょうね」 私　 「このユースケース図には、バッチを起動する『スケジューラ』がアクターとして書かれているのですが、これはアクターになり得ると思いますか。これはユースケースを起動するだけで、何も利益を得ていない気がするのですが……」 A氏　「それについてはオブジェクト指向の世界では、昔からいろいろな議論があるのですが、私もスケジューラはアクターではないと思っているんですよ。やはり何も利益を得ていませんしね」 私　 「そうですよねぇ。もしかしたら、スケジューラは『ユースケースを実行するという任務』を果たしたこと自体が利益になるのかもしれませんね。ちょっと強引ですか」 A氏　「なるほど！ それは私にはなかった発想ですね。そういう考えは成り立つかもしれません！ いや、納得してしまいましたよ」

といった後、すぐにA氏はその発想をノートに書き留めたのである。

　A氏はオブジェクト指向に関して長年研究している著名な方であり、もちろんオブジェクト指向の勉強を始めて間もない私に比べはるかに知識は豊富である。それにもかかわらず、私のような若輩者の発言にでも感心できる謙虚さは、今後コンサルタントを目指すエンジニアにとっては見習うべきところである。

　A氏のこの謙虚さは、より多くの人とのコミュニケーションを活発にし、A氏自身いろいろな知識を得るためのきっかけづくりに役立っているのだと思う。

■卓越した知識と探求欲

　A氏の机には、山のように英語の技術書が置かれている。そして社内でのミーティングや勉強会などでは、話の途中でそれらの技術書を開いては、われわれに分かりやすく解説してくれるのである。これだけでもかなりの知識を持っているのは明らかだが、私が最も目を引かれるのはA氏の探求欲である。

　以前、私がA氏に何げなく

「○○○っていうツールご存じですか」

と質問をした際、A氏は

「いや、聞いたことないですね」

と答えた後、すぐにフロア中の技術者に「○○○とは何か」を質問し始めたのである。その5分後には私がした質問に対して事細かに回答できるほどの知識を得ていたのである。私はA氏のこの行動に、少なくとも次の3つの利益があることを認識した。

（1）質問した者に対して答えることができる
（2）自分自身の知識になる
（3）ノウ・フー（know who）を得ることができる

　1と2は予想のつく利益ではあるが、非常に大切なのは3の「ノウ・フーを得る」という利益であろう。われわれがどんなに努力や勉強をしても、この業界の幅広い技術に関するすべての知識を身に付けることは不可能である。

　もし、われわれがこの業界でプロジェクトを成功に導くためのコンサルタントを目指そうとした場合、自分の守備範囲外の質問に対する答えを導き出すために必要な知識が、この「ノウ・フー」、つまり「誰がそれを知っているのか」ということである。A氏はそのことを裏付けるかのように、

「○○○に関してはBさんとCさんが詳しいようですね」

と、私に伝授してくれたのである。私はその行動で、A氏の膨大な知識を支えているものはやはり、探求欲であると実感したのである。

■優秀なコンサルタント＝プロジェクト成功か

　こういった非常に優れたコンサルタントが身近にいると、プロジェクトは必ず成功に終わると予想するかもしれないが、必ずしもそうではないように私は感じている。もしプロジェクトにA氏のような非常に知識が豊富で人間性に優れた人材がいると、多くのエンジニアはその人に頼りすぎてしまう傾向があるからだ。

　事実、現在われわれは成果物やドキュメントを必ずといってよいほどA氏に確認してもらっており、それはA氏に確認してもらわないと不安であるという気持ちが自分自身に生まれてしまっていることの表れである。いい換えれば、自分で行った作業に自信が持てなくなってしまっているのである。

　もしA氏が突然このプロジェクトから離れた場合どうなってしまうのだろうか。たぶん、どのようにプロジェクトを進めればよいか分からず、途方に暮れてしまう危険性があるだろう。それを、われわれエンジニアは自覚する必要がある。

　つまりわれわれエンジニアは、優秀なコンサルタントにアドバイスを求めることがあったとしても、決してそのことに依存してしまってはならない。そして、コンサルタントから得た知識や技術を、自ら応用し活用できるスキルを日ごろから養っておかなければならないということである。

■コンサルタントの変わった一面

　先日、A氏は突然私のところに来て、

「山野さん、これあげますよ」

といって、コンビニで売っている透明な弁当箱を私に手渡した。A氏は、

「付せんにToDoを書いて、この弁当箱に入れていけば、予定を忘れずに済みますよ。付せんがたまっていたらそれは仕事がたまっているということですよ。もちろん弁当箱として使ってもいいですよ」

といい、笑いながらその場を去っていったのである。私はその行動に「変わったことを考える人だなぁ」と思いながら、「憎めない人だなぁ」とも思った。

　膨大な知識を持ちながらも謙虚であり、多くの技術者から絶大の信頼があり、ちょっとだけ変わった発想を持ったA氏。私の思う「理想のコンサルタント像」はそこにある。

筆者プロフィール

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