ObjectSquare [2009 年 5 月号]

[技術講座]


ジョー・マラスコ氏
「 21 世紀のソフトウェア開発管理」セミナー報告

補足インタビュー後編

( 株 ) オージス総研 藤井拓

今回も前回に引き続き「 21 世紀のソフトウェア開発管理」セミナーの全日程を終えた 10 月 3 日にオージス総研の田町オフィスでマラスコさんに行ったインタビューの内容を報告します。今回は、セミナーの内容から外れて筆者が最近興味を抱いている技術者やマネージャーの成長と、今後のソフトウェア開発とについてお聞きしました。




成長への意欲

--著書の中でチックセントミーハイのフロー理論を拡張して処遇と成長に関してのお考えを説明し、マネージャーの視点で部下の成長を促すことの重要性を強調しておられていました。同時に部下が自ら意欲的に成長することも大事ではないかと思います。技術者や若手のマネージャーが自らを成長しようと思うためにはどうしたらよいでしょうか?

一般的に人にどうやって成長する意欲を持ってもらうかということだね。人によって、動機はマチマチだ。プロとしてなし遂げたことが大事な人もいるし、人から認められることが大事な人もいる。それ以外に、処遇というような側面がもっと大事だという人もいる。チームに何人ものメンバーがいる場合、それらの人たちを動機づけているものが何かということに非常に注意を払った方がよい。人から認められることが大事だと思う人がいるのであれば、給料を上げてもうまく動機づけできないだろう。大事なことが1つある。チームで成功を収めて、何かを作り上げたり、よい成果を達成するなど会社に貢献した場合には、チームになんらかのご褒美をあげる必要がある。そのご褒美は、業績と直接結びつくものである。多くの人のやる気をそぐ問題の1つは、ご褒美を一緒にもらえないということである。

私の Apex 開発チームは、製品の開発を期日どおりに完了するのに成功した。その際に、私はチームメンバーにストックオプションを追加することを要求した。それにより、メンバーは会社と成功を分かち合えた。それはとても大事なことだと思うが、それが人を動機付ける唯一のものではない。少なくともアメリカではそれが問題なのだ。アメリカでは、動機づけの大きな手段として処遇をあまりにも重視しすぎている。

インタビュー終了後
インタビュー終了後



成長のために行うべきこと

--技術者や若手のマネージャーが自らを成長させるために行うべきことは何かという質問に戻りたいと思います。著書[1]の第1章に、大学時代の計算の訓練によりエンジニアとして基本ができたと書かれています。そのようなこと、またはそれに代わるようなことが、技術者や若手のマネージャーが成長するために必要でしょうか。

私は、昔に戻って計算尺を使うべきだとは思わない。世代毎に使う道具は異なるだろう。私自身のよい例を話すと、工学部時代にノモグラフを学んだが、それは 1900 年から 1960 年までは非常によく使われる道具だった。その後、非常に面白いことがおきたのだ。電卓が登場し、さらにPCと表計算ソフトが登場し、ノモグラフが消えたのだ。完全に。実際、工学部では現在ノモグラフを教えない。さて、成長についての記事を書いた時に、成長にはノモグラフが必要なんだとはたと気づいたのだ。私はノモグラフとともに成長してきたからだ。しかし、ノモグラフを今の人に見せると、それを結び付けるのに苦労する。今では、そのような種類の作図ツールを使わなくなっているからだ。そういうことから、1つの道具、手法、アプローチがそれほど大事だったり、神聖だったりしないのではないかと思う。計算尺が廃れてさびしい気持ちはあるが、それは過去のものだ。

藤井注:ノモグラフは、特定の数式の変数と得られる値との関係を図示したもの。特定の変数の組み合わせに対する方程式の値や、方程式の特定の値を与える変数の値を作図で求めることができる。ノモグラフについてのより詳しい説明はマラスコさんの Web 上のノモグラフの説明ページ(英語)[2]をご参照ください。

本当に大事だと思うのは、自分が成し遂げなくてならないことに適したツールセットの使い方を若い技術者が学ぶことである。例えば、表計算ソフトは非常に一般的であるが、表計算ソフトの使い方を知らなければ非常に大きなハンディキャップがあることになる。将来の道具がどんなものかということは分からない。昔は機械製図を学んで育ったのが、今では CAD システムの使い方を学んでいる。このようなトレンドは、ずっと続くだろう。新たな道具、手法、アプローチは現れ続けるだろう。自分自身のプロとしての成長の一部として、若い時期だけではなく、それ以降のキャリアを通じて、新たな道具がどんなものかを学ばなければならない。そうしなければ、取り残されてしまうだろう。

--おっしゃったのは、適切な道具を使うということと、学び続けるということの2点ですね。科学の実験は、そのような成長の手段としてよいと思われますか。

ソフトウェアは、とても特殊な領域だと思う。というのは、論理性と計算能力の両方が求められ、間違いにルーズなことが許されない領域だからである。小さな間違いであっても、プログラムは動かない。私自身のキャリアを振り返ると、プログラマーとしてはそこそこだったが、防御的にプログラミングし、間違いを防ぐということを早い段階で学んだ。さらに、デバッガーとしては非常に優秀だった。プログラムにバグを見つけることが得意だったのだ。そのようなことが得意だった理由の1つは、科学者として訓練を受けたからである。例えば、科学の実験がうまくいかない場合、その原因をデバッグしなければならない。うまくいかない原因を究明しなくてはいけない。原因が分かれば、解決できるのだ。これは、まさにデバッグで行うことだ。バグのありかを探し、修正するのだ。様々なデバッグの方法は、科学者として学んだことだ。

同じ理由で、数学も大事だと思う。数学は考え方であり、とても正確で系統的であり、思考の訓練としてもよい。若い人たちには、いくつかのことをお勧めしたい。まず数学。コンピュータ科学でそんなに数学は使わないという人もいるが、それは学ばなくてよい理由にはならない。数学を学ぶのは訓練なのだ。考え方なのだ。科学的な手法を理解することも、若い人にとてもよいだろう。繰り返しになるが、それは秩序と創造性が組み合わさったものであるからだ。

若い人にもう1つ大変良いのは、パズルを解くことだ。例えば、数独を解くのはとてもよい。それで、思考の訓練を助けるからだ。もっと論理的に考え、答えを探す方法を身につけることを助けるからだ。これらすべてのことがソフトウェアを作る際に役立つのである。

もう1つ若い人によいのは、読書だ。読んで、読んで、可能な限り多く読んだ方がよい。そうすることで、幅広いアプローチを身につけるのだ。コンピュータ関連の狭い分野だけではない本を次から次へとの読む。様々な書籍を読むことで、考えたり、論理的に類推する力が強くなる。常に読書をするという習慣を人生の早い段階で育むのは、とても有用である。



学び続けること

--次の質問は、著書やセミナーの範囲から外れますが、私が個人的に直面している問題に関するものです。私は、自社のエンジニアの育成に関わっていますが、私自身はそれらのエンジニアの上司ではありません。そのため、いろいろな所属から参加するエンジニアが相手で、その人たちをスキルアップへの意欲が高まるように助けるという立場です。ただ、そのような立場でスキルアップへの意欲が高まることを助けるということに難しさも感じています。個々のエンジニアはとても勤勉で、お客様の要望を満足するように一生懸命仕事をします。しかし、自分自身で学んだり、他のエンジニアに貢献するということが優先度として 2 番目や 3 番目になってしまいます。能力もあり、勤勉なので、お客様にサービスを提供するために 100% の時間を費やしてしまいます。学ぶことへの意欲を高めるための方法は何かないでしょうか?

とても簡単なことを言うことができる。現在持っているスキルセットでお客様を 100% 満足させられるかもしれない。それはそれでよい。しかし、5 年後はどうだろうか。5 年後に現在と同じスキルセットを持っていても、世の中は変わっているだろう。お客様の要求は変わり、要求の 90% しか満足させられなくなるかもしれない。それでもまだなんとかなるかもしれない。何もしなければ、10 年後はどうなるだろうか。90% から 80% に落ちるのではなく、90% から 50% に落ちるだろう。というのは、時間に対して一定の割合で減るのではないからである。世界の変化のスピードは、ますます速くなるだろう。顧客の満足度を高めることが絶えず気になる人には、私は次のように言う。「顧客の満足度が高い状態にあり続けるためには、自分自身が学び、成長し続けなければならない。そうしなければ、取り残される。そして、とても悲しい思いをする。というのは、自分のスキルセットや道具箱がお客様の満足を得るためには不適切なことが分かるからだ。」つまり、取り残されないかどうかが問われるのだ。このことは、コストではなく、投資なのだと説明すべきだろう。今お金を使うことで将来必要になるスキルセットが得られるだろう。このプロセスはずっと続く。引退に近くなった人が学ぶのを止めるのは、残された期間の後のことを気にしなくてもよいからである。私は、ずっと学び続けるべきだと信じている。



プロジェクトマネジャーが人材育成を重視するためには

--もう1つ質問があります。優秀なプロジェクトマネジャーは次世代の人材の育成に責任を持つべきだと仰いました。しかし、プロジェクトマネジャーにそのようなことを受け入れるようにするのは誰でしょうか。

それは、トップから行うべきことだ。継承というのは、組織の文化の一部でなければならない。一番上の CEO を始めとする全員が、自分の後継者の育成を行い、自分の仕事の引継ぎを行うべきである。

--全員が、それぞれの仕事の中で同じ文化を共有するのですね。

そうである。一貫した文化だ。大きな組織では、置き換えられない人や不可欠な人はいない。実際には、とても健全な組織では次世代のリーダーを育成することにより将来に備えている。そんな会社は、健やかな文化があるといえる。誰も仕事を失うことを恐れない。その代わり、「自分の仕事はなくなるだろうが、組織で他の仕事を受け持つだろう。他の仕事を行う前に、自分の仕事を引き受けてくれる人がいないといけない。その準備をしなくてはならない」と思うのである。


ソフトウェア開発会社の今後

--次に講演の内容から外れた質問です。現在、プロジェクトマネージャーの多くがソフトウェア開発の今後がどうなるかという点を心配しているのではないかと思います。例えば、SI 会社の規模は小さくなるのではないかという心配です。というのは、現在では大きな会社であることのメリットは減っているような気がするからです。マラスコさんは、SI 会社の規模は今後どんどん小さくなる傾向が続くと思われているでしょうか。

マラスコさんの趣味
マラスコさんの趣味

分からない。分からないというのは、2つの異なる方向があるからである。他の会社を合併してどんどん大きくなる会社もあるだろう。そうなる理由は、単に財務面の安定性からである。会社が多くなるほど、大きなバッファーを持つので厳しい時期も小さな会社よりも楽に乗り切れるだろう。小さな会社は、財務的にもっと余裕がないところにいるのだ。そのために、安定性に欠ける傾向がある。

しかし、それとは逆の傾向も見ることができるかもしれない。小さくても、特定の領域に非常に特化した会社はある。ニッチな専門性である。これらの会社は、より小さく、より機敏で、より柔軟であり、より大きな会社をしのぐこともできるだろう。小さな会社が、より大きな会社と幅広い分野に渡って競合するのは無理である。というのは、スキルと専門性の多様性が乏しいからである。それは、大きな会社だけが持ちえるものなのだ。しかし、大きな会社でもプロジェクトに要員を割り当てる場合には、従業員の一部を選ぶことにならざるをえない。小さな会社が対象とする問題にまさに適したスキルと専門性を持つ人材の集団を持てば、大きな会社をしのぐことも可能だろう。考ええるもう1つの方向性は、小さく、非常に特殊なタスクに特化した会社が増えていくというものである。

--著書の中では、強い文化を育むという点では小さな会社の方が有利かもしれないと書かれていますよね。

確かにそのとおりである。もう1つ小さな会社が有利な点がある。小さな会社では、自分たちの文化への貢献が大事なことを従業員全員が信じることができる。このことで、コミットメントや責任に対する意識が強くなる。大きな会社では、うちの会社はとっても大きいのでなんとかなるさという気持ちを持ちを持ちがちになる。これが、個人の説明責任を弱めるのだ。このため、私は小さな会社の可能性を信じている。ただ、財務の面では厳しいだろう。小さなチームが財務的に厳しいのは、オーバーヘッドに対する余裕が非常に少ないためである。大きな会社は、ある程度のオーバーヘッドを許容できる。

--クラウド・コンピューティングや SaaS のようなものについて言及されましたが、将来のソフトウェア開発についてさらにお聞きしたいと思います。現在は、多くのお客様が自前のシステムを持っていますが、将来それらのソフトウェアは少数の大手ベンダーのクラウド・コンピューティング環境に集約されると思われますか?

そうだね、とっても変だ。実際には、すべてのものが巡り巡っている。メインフレーム・コンピューティングの初期まで戻れば、なにもかもがサービス・ビューロで行われていた。今のクラウド・コンピューティングは、サービス・ビューロにとてもよく似ている。集約しているのだが、別の方法を使い、舞台裏で行っているなどなどである。いつも私がよく使う振り子のアナロジーを使うことができるだろう。振り戻りがあるだろうし、自分たちのビジネスが特別で他とは違うと思い、システムを自分でしっかりコントロールしたいと思えば、コンピューティングを自分たちのところに戻すだろう。ある程度、コンピューティングが自分たちのビジネスのコア部分ではなく、単なるサービスや道具と考えれば、外に出していくだろう。外から買うか、アウトソースするか、サービスとして使うかのいずれかだろう。あるものにおいてトレンドはクラウドや SaaS へと続くだろうが、すべてがその方向に進むとは思わない。自前でコンピューティングを行うという会社も残るだろう。それが競争上の優位性を生んでいるからである。

藤井注:サービス・ビューロは、特定のサービスを提供する会社。

分かりやすい例を挙げてみよう。大昔には、すべての会社が自前の給与計算システムを持っていた。現在では、ほとんどすべての会社がサービスやパッケージソフトウェアを使って給与計算を行っている。その理由は、もはや自前で給与計算システムを持つためのお金を使うのに見合うほどの独自性も相違点もないからである。いまでは意味がないのである。より多くのものが日用的なものになるつれ、その部分のコンピューティングはクラウドや SaaS の方向に進むだろう。

--自前のシステムを開発する場合に、要求の量は減らないだろうとお考えでしょうか?

減らないで増えるだろう。ただ異なったものになるだろう。

--インタビューは以上です。今日は、どうもありがとうございました。


補足インタビュー後編のおわりに

筆者が最初にマラスコさんに出会ったのは 1996 年ごろです。当時は、マラスコさんはApexというAdaの開発環境の事業部長であり、Apexの今後の製品開発計画を各地域の責任者に説明する打ち合わせに私も参加したのでした。マラスコさんの第1印象はまさに「アメリカの典型的なボス」でした。その打ち合わせの冒頭で、マラスコさんは各地域の責任者に「あなた方の聞きたいことを言ってください」と言い、各責任者の発言を白板に書きとめました。発言が一段落したところで、マラスコさんは「分かった。それでは以降の説明は君に任す」と言い、マーケティング担当者にその場を委ねて脇に退きました。マラスコさんが説明を行うものだと思っていた私は肩透かしを食らいました。この行動は私にとって不可解であり、「どういう性格の人かな」とマラスコさんに興味を抱いたのでした。

それ以降、マラスコさんと何回か一緒に仕事をしたり、食事にいったりした際にも、いくつか面白いエピソードがありますが、話が長くなりそうなので割愛します。マラスコさんは、奥さんが日系人であり、日本ラショナル社会長であった故マーク・サドラーさんの親友だったこともあり、非常な日本びいきです。今回の来日は、著書の訳本の刊行と、マラスコさんの日本(と元の同僚)への好意で実現しました。今回の来日の際に一緒に行動したことで、私もいろいろなことを教えて頂きましたが、その一部でも皆さんにお伝えできたら幸いです。

蛇足だと思いますが、マラスコさんの趣味はバーベキューを焼くこととゴルフです。週末には、バーベキューグリルを車で引いて公園に行き、バーベキューを振舞っているようです。このことはマラスコさんの Webサイト[3]に掲載されています。今回の記事に掲載するためにバーベキューを焼く姿を写した写真を所望したところ、マラスコさんから「ウィリアム・シャトナーは日本で有名かどうか知らないけど」とのコメントともに YouTube のあるページの URI[4] が送られてきました。見てみたら、なんとマラスコさんがウィリアム・シャトナーにバーベキューの焼き方を指南していたのでした。スター・トレックファンはぜひお楽しみください。

藤井注:ウィリアム・シャトナーは、スター・トレックのカーク船長を演じた俳優さんです。


参考文献及びサイト



© 2009 OGIS-RI Co., Ltd.
Next Index
Prev. Index