グリーCTO藤本氏が明かす、エンジニアリングの観点をマネジメントに生かす具体的な方法一生、エンジニアで食べていける?(1/2 ページ)

開発の効率を高め、より良いサービスを実現し、価値を高めていくために、開発者には何ができるのか――そんなテーマを追求する「明日の開発カンファレンス」が2017年4月14日に開催された。その中から2つのセッションの模様を紹介する。

» 2017年05月30日 05時00分 公開
[高橋睦美@IT]

 開発の効率を高め、より良いサービスを実現し、価値を高めていくために、開発者には何ができるのか――そんなテーマを追求する『開発リーダのための「明日の開発カンファレンス 2017」』が2017年4月14日に開催された。

 より良い開発の実現に向け、DevOpsやCI/CD、アジャイルにテスト駆動開発といったキーワードが飛び交う昨今、オープンソースでさまざまなツールが提供されている。カンファレンスでは、まずは小さくてもいいので最初の一歩を踏み出し、時にプロの手を借りつつ、上に立つ立場の人も巻き込みながら、開発を進めていくことの重要性が共有された。本稿では、下記2つのセッションの模様を紹介する。

エンジニアリングのスキルや知見を活用してマネジメントを

グリー 取締役 執行役員常務 最高技術責任者の藤本真樹氏

 一歩、二歩、そして三歩先の開発をより良いものに……と考える開発者は多い。せっかくそうやってキャリアを積んできたのに、会社から「君もそろそろマネジメントを」と言われ、悩んだり、尻込みしたりする開発者もまた多いのではないだろうか。そんなとき、「マネジメントや会社経営にエンジニアリングの観点を持ち込み、エンジニアリングのアプローチでより良くすることもできるのではないか」と、グリーの藤本真樹氏(取締役 執行役員常務 最高技術責任者)は「今日からはじめるEngineering Management」の講演で述べた。

 エンジニアとしての開発経験だけではなく、CTO(最高技術責任者)、VP(組織責任者)として人をマネジメントする立場としての経験も積んできた藤本氏は次のように講演の趣旨を説明した。

 「ソフトウェアエンジニアリング業界は、人もお金も何もかも足りないけれど、特にエンジニアリングマネジャーの足りなさも重要な課題。『いいマネジャーが有り余っています!』っていう会社はなかなか聞かない。一方でエンジニアに『マネジャーをやって』と言うと、『ええっ』という反応が返ってくることが多い。もちろんスペシャリストの育成も大事だが、一方で、ここも何とかしていかなければならない」

 エンジニアとしてオペレーションマネジメントやテクノロジーマネジメント、システムエンジニアリングに関して培ってきた経験やスキル、能力は、チームやプロジェクト管理といった領域に応用できるし、むしろ全く使わないのはもったいないという。

 「マネジメントは、エンジニアにとって興味のないもの、面倒くさいものと思われることが多い。『そもそもエンジニアはコードを書くのが好きだから、エンジニアなのであって、人が好きならエンジニアにはなっていない』という人も少なくないと思う。少なくとも僕の場合はそう(笑)。一方で、良いマネジャーが多いほど組織はより良くなり、気持ち良く働けるようになる。エンジニアとしての経験を活用し、エンジニアが働きやすいマネジャーを増やしていくことも重要だ」

 しばしば会社では、キャリアパスとして、ある程度経験を積んだ後は引き続き技術を追求する「スペシャリスト」と管理職的な「マネジャー」の二股に分かれる絵が示される。「この図は誤解を生むと思っている。マネジメントも専門スキルの1つ。ネットワーク技術やコードと同じで勉強すれば詳しくなるし、上手にできる。その上、先人の知恵も多くある。1つのスペシャリストとして捉えれば、やりがいがあるのではないか」

 シビアな話になるが、一生、エンジニアで食べていくというのは厳しい道であるのも事実だ。40歳、50歳と年を重ねても集中してコードを書き、常に技術にキャッチアップしていくとなると、相応の気力と努力が必要だ。そんなとき、マネジメントスキルは自分の1つの武器になり得る。「マネジメントに関しては、勉強の機会が多く、書籍も豊富なことから、後ろ向きにならず、機会があるなら自分の糧にすべくトライして、うまく生かしてみるといいのではないか」

 ただ、大事なのは、書籍だけ読んでできた気になってはいけないということだ。「技術書やコードを書くのと同じで、100冊読んでも上手にはならない。読んだらやってみること、実践することが大事だ」

人の相性はスイッチの相性と同じ?

 では、藤本氏自身が実践してみた結果はどうなのか。同氏は、マネジメントに取り組む中で直面し、エンジニアリング的なアプローチで解決に取り組んだ例を紹介した。

 1つ目は『評価が大変ですね問題』。例えば半期に一度の評価では、とにかく面談が必要で、あっという間にスケジュールが埋まる上に、1人当たり30分ではフィードバックしたくても内容を十分に伝えきれない。「これは、エンジニアリングで言えば、半年ずっとコードを書いていきなりリリースするようなもので、それではちゃんと動くわけがない。では、イテレーションの感覚を短くすればいいじゃないか」

 そう考えた藤本氏は、月に1、2回程度のペースで社員と「どう?」と話をし、その場で期待値の擦り合わせや修正の方向性などを伝えるようにしてみた。短い間隔でどんどんフィードバックし、修正していくというスタイルだ。「こんなふうに、マネジメントの問題にエンジニアリングの考え方の応用範囲を広げるのは面白いし、うまくいくところもある」

 また、いきなり「明日からこのチームの面倒を見てくれ、よろしく」と言われたときに、何をすればいいか迷う……といったときにも、エンジニアとして培ってきたアプローチが役立つという。「役割やインタフェース、その価値が分からずにコードを書いても良くならないのと一緒で、何をするのか、どこに向かうかをぶれずにまとめることが大事だ。重要なのは、何でもいいのでチームの向かう先をイメージすること。そのために必要な方法やツールは、エンジニアリングと同じで、その都度学べばいい」

 チームをマネジメントしていく中では、どうしても人間関係の問題が生じることもあるだろう。「これは、ネットワークスイッチの相性と同じ、と考えれば気が楽になる。相性が悪いならばアプローチはシンプルで、お金をかけて相性が良いものばかりでそろえるか、あるいは、異なるプロトコルを合わせるために自分が“ずれ”を理解し、間に入ってプロキシとして動作するかだ。もちろん正解はないけれど、こんな考え方もあると思えば、ちょっとだけ面白くならないだろうか?」

 どの技術を選択するか。テクノロジーマネジメントに関しては「ガバナンスをするならする、しないならしないで、スタンスを一定に保つことが大切だ。強いて新しい技術を使うことにチャレンジするならば、結合を疎にし、きちんと後から振り返りできるように記録することが大事」

 こうしてあれこれマネジメントにチャレンジしてみた結果、やはり、この仕事はつまらない……と思うこともあるだろう。そんなときは、なるべく機械にやってもらうのがいいという。「それを追求すれば、より楽で、より効率の良い、より良いコードにたどり着く」

「リーダーシップ」の2つのタイプ

 最後に藤本氏は、リーダーシップの2つのタイプについて紹介した。リーダーの在り方のカテゴリーの例として、チームを強力に率いる「支配型リーダーシップ」と、「みんながんばれ」と後押しする「サーバント型(支援型)リーダーシップ」がある。

 「サーバント型リーダーシップは良い考え方だけれど、『スレーブ』(奴隷)になっていないかという点にだけは気を付けたい。サーバントとスレーブの一番の違いは、そこに『意志』があるかどうかだ。チームとしてより良く働き、目標を達成したい意志があれば、暫定的には苦しくても、半年後には良い結果が得られるだろう」

 そして、好むと好まざるとにかかわらず、複数人で1つのことをやるために頑張らなくてはならないとき、せっかくエンジニアの勉強をしてきたなら、そのスキルを活用するのは悪いことではない。「ただし、人と機械は違う。人には感情があるので手戻り残すとが大きいし、変化に時間がかかる。そういった差分を考えつつ、エンジニアリングのアプローチを活用してはいかがだろうか」

       1|2 次のページへ

Copyright © ITmedia, Inc. All Rights Reserved.

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。