第3回 マネジメントとは「自分の環境を作る仕事」だ
岑康貴（＠IT自分戦略研究所）
赤司聡（撮影）
2010/1/18
 |
| 能登信晴（のとときはる） ディー・エヌ・エー（DeNA） ECビジネス第二事業本部 システムグループ グループリーダー 1974年2月、神奈川県出身。慶応義塾大学環境情報学部 (SFC) 卒業後、日本電信電話（NTT）入社。情報通信研究所、サイバースペース研究所にて検索エンジンの研究開発に従事。2004年1月にディー・エヌ・エーに入社し、さまざまなサービスの開発・運用に関わる。現在は「モバオク」「モバコレ」を担当。ディー・エヌ・エーの技術に関して雑誌記事執筆や講演活動も行っている。twitter IDは「noto」。 |
■研究者からサービス事業者への転身
新卒でNTTに入社して、4年ほど研究所で研究開発に従事しました。もともとインターネット関連技術やヒューマンコンピュータインタラクションの研究がしたかったのですが、1996年当時、そういったことができる企業はあまり多くなく、その中でNTTを選びました。主に検索エンジンのクローラ開発を行っていました。
入社直前までNTT研究所には石井裕さん（現 MIT Media Lab 教授) という大先輩がいました。彼のような仕事がしたいというのもNTTを選んだ大きな理由でした。彼がいうように、誰かが作った評価軸上のインクリメンタルな技術改善をするのではなく、新しい領域を切り開くような研究テーマを、と思って、社内でいろいろな提案をしていました。ところが、いつもサービスの提案になってしまって、要素技術の研究になりませんでした。そのとき、自分が本当にやりたいのは、「サービスを多くの人に使ってもらいたい」「多くの人の生活スタイルに影響を与えたい」「サービス提供を通じて新しい文化を作りたい」ということだと気付いたのです。そこで、研究所を辞め、DeNAに入りました。
多くの人の生活スタイルに影響をあたえ、文化になるほどのサービスは、ビジネスとして成立するものです。パッと目立ってすぐ飽きられるものではなく、末長く使い続けられる必要があります。そのため、技術だけではなく、ビジネスのことも分かるようになりたいと思いました。DeNAには、同じような思いを持っている人が多く、そういうビジネスのノウハウもたくさんある。それがDeNAを選んだ理由です。
■自分でコードを書かないという仕事の苦労
今でこそ「DeNA＝ケータイ向けサービスの会社」のイメージですが、入社した当初はまだ「モバゲータウン」もリリースされていないころで、主力サービスはビッターズでした。入社当初はビッダーズの開発グループに所属していたのですが、半年くらいたったころ、社内で「ソリューション事業」が立ち上がり、顧客企業向けコンサルティングや受託開発業務に従事することになりました。
| エンジニアライフ コラムニスト募集中！ |
あなたも＠ITでコラムを書いてみないか 自分のスキル・キャリアの棚卸し、勉強会のレポート、 プロとしてのアドバイス……書くことは無限にある！ コードもコラムも書けるエンジニアになりたい挑戦者からの応募、絶賛受付中 |
とある企業のオークションサイトを作るという仕事があって、要件定義をほぼすべて1人で行ったのが1つの転機になりました。自ら「どんなものを作るか」を考えるのは研究所時代と同じですが、今までと大きく異なる点が3つありました。
1つは「自分でコードを書かない」ということ。それから「自分の作業が遅延すると、自分の決めた仕様に基づいて設計・実装をしてくれる20〜30人が後工程を進められない」ということ。そして、「動くものがない状態で、抜け漏れのない整合性のとれた仕様を作り上げなければならない」ということでした。自分でも予算やコストを把握して進めていたプロジェクトでしたし、2番目、3番目の部分をしくじると、そのままプロジェクトのコスト増大やスケジュール遅延につながってしまう。とはいえ、余裕のまったくないスケジュール……。自分1人ですべての責任を負うというのは、たいへんなプレッシャーでした。ただ、1人でここまでできるという手応えはつかめましたし、自分はコードを書かなくても意外とバリューを出せるんだなという自信も持てました。
■リーダーと開発者の両立は難しい。ひとまずリーダーに専念
そういったプロジェクトを他に2つくらいこなして、なんとなく今後はコードを書かずにサービス企画とプロジェクトマネジメントをしていくんだろうなと思っていたら、今度は「ポケットアフィリエイト」の部門に異動になり、新機能の仕様決めから実装まで、自分ともう1人でやるのがミッションになりました。しばらくブランクがあったので、多少コードの読み書きには抵抗がありました。ですが、ソースコードを読んでみると、DeNAで今まで扱っていたJavaのコードより読み書きしやすくて、「これなら仕様決めから実装まで自分でできるし、その方が速いな」と思いました。当時Ruby on Railsが出てきて、プログラマ1人でできる領域が拡大していましたが、社内ではPerlベースのコード (オープンソース化したMobaSiF) が近い意味を持っていたと思います。
その後「モバオク」「モバコレ」「ポケットアフィリエイト」と3つのサービスの技術責任者を務めながら、「モバゲー」内のケータイサイト検索エンジンの開発も自ら行っていました。コードを書いて動くものを作るのは好きですが、ベンチャーだからリーダーをやる人も必要だと考えていました。だから、両方やっていました。
あるとき非常に大きなトラブルが起きて、自分のリソースをすべてそのトラブルシューティングに回さなければならなくなりました。このとき「リーダー業務と自分で行う開発の両立は難しい」と痛感させられました。コーディングには、集中するための、ある程度まとまった時間が必要ですが、リーダー業務ではミーティングが多く、時間が細切れになってしまう。もともとそこにジレンマがありましたが、大きなトラブルを経験して、まわりに約束した通りに自分の開発が進められないことで決定的になりました。それを契機に「あれもこれもと中途半端なことをやるよりは、まずリーダー業務やマネジメントに専念しよう」と決断しました。
■マネジメントという「自分の環境を作る仕事」の面白さ
自分のコーディングに没頭している時は、正直いって「マネジメントの仕事はしたくない」と思う場面がありました。それでも意外と続けられているのは、コーディングとは異なるマネジメントの魅力、可能性をつかみ取ってきたからだと思います。
1つは、自分の能力をチームにスケールさせること。自分ができることは自チームのメンバーにもできるようになってもらう。DeNAでは、全メンバーに成長が期待されています。今できることを続けるだけでなく、常に新しいチャレンジをして、今までできなかったことができるようになるのが当たり前。今まで自分しかできなかったことが、他のメンバーもできるようになるということは、メンバー自身が成長できたということだし、DeNAという組織ももっと強くなるし、自分は自分にしかできないことにもっと集中できるようになる。こういう風に自分の能力をまわりに伝播させて、スケーラビリティを追求できるところがおもしろい。
もう1つは自分の環境を作ること。いち開発者としてマネジメントされている間は、環境作りをマネージャに依存している状態です。組織面も含めて自分で理想だと思う環境をつくるためにはマネジメント能力が必要です。研究所時代は、自分の環境は自分で作れといわれ、1人でサーバやネットワークの構築を行って研究環境を作っていました。今はそういった環境作りを、組織体制に関しても少しずつ行えるようになってきていると思います。
それから、人への興味。わたしは「平日の昼ご飯は1人で食べたい」という性格なのですが、それなのに、意外と人に興味がある、ということが分かってきたのです。この人はどういうことを大切と思っているんだろう、今は何ができるようになりたいと思っていて、実際どこまでできるようになっているのだろう、どこにつまづいているのだろう、というようなことを知りたいと思うし、話をしていると、そういう部分が自然と見えてきます。それなら、今はこういう課題に気付いてもらえばいいのかな、というようなことを考えて、一番よく伝わる方法を考えて、伝えてみる。そういうことの積み重ねを面白いと感じています。
リーダーとして「自分がどんどん意見を出して、まわりの人にはそれに基づいて進めてもらう」というのも1つのスタイルですが、それだとメンバーが「決めてくれるんだな」と思って依存しちゃうから、わたしはぎりぎりまで手も口も出さず、メンバーに決めてもらうようにしています。DeNAには「最後の砦」という言葉があって、全員が最終的に責任を取れる、物事のジャッジができる人になってもらおうという考え方があります。自発性を重視しているわけです。だから、なるべく「気付いてもらう」「自分で考えてもらう」のがわたしの役割です。
エンジニアとして自分で手を動かしてしまった方が速い、と感じることがないわけではありません。でも、相手にやってもらって、メンバーが成長して、わたしが何もいわずにできるようになるのなら、その方がメンバーも組織もわたしも、望ましい状況になる。そのためにはじっくり待つことも重要です。もちろんスピードも重要なので、期限を切ったりしますけど。
■「プレイングマネージャ勉強会」やりたい！
マネジメントに専念すると決めた理由がもう1つあります。メンバーを育成して、自分の持っているミッションの一部を任せて、自分のマネジメント範囲を適正な規模にできれば、自分でもまた、ある程度、開発の仕事ができるようになるはずだと思うんです。
エンジニアのマネージャはプレイングマネージャが理想なのではないかと思っています。自分でコードを書いていないと、いつの間にかコードを書いている人と意識が乖離してしまう。コードを書いている人が働きやすい環境を作るのがマネージャの仕事なのに、そういった人たちと意識がずれてしまっては、いい環境は作れません。また、マネージャはある程度メンバーからリスペクトされる必要があると思いますけれど、コードを書かないで、新しい技術を自ら活用しないで尊敬を集めるというのも、難しいのではないかと思います
同時に、マネジメントの面白さや魅力は、もっと評価されてもいいと考えています。この分野では、どうも「プログラマやハッカー、ギークは格好良い」が「マネージャは格好悪い」というイメージがあるような気がします。マネジメントも魅力的な仕事で、可能性もいろいろあるけれど、ブログなどでマネジメントのティップスについて書く、という雰囲気は、今のところないですよね。「企業秘密だから出せない」という側面もあるのでしょうが、イメージの問題も強いと思います。
エンジニアなので、やっぱり技術は好きで、コーディングも面白い。でも、マネジメントも、これはこれでいい仕事だよね、という価値観を広めたいです。なかなかコーディングと両立しづらいけれど、どうやったらうまくプレイングマネージャを続けられるかというノウハウを共有できればいいなと思います。そういえば、技術勉強会はたくさんありますが、「プレイングマネージャ勉強会」ってないですよね。そういうものをやれるとおもしろいなと思います。
＠IT自分戦略研究所は2014年2月、＠ITのフォーラムになりました。
現在ご覧いただいている記事は、既掲載記事をアーカイブ化したものです。新着記事は、 新しくなったトップページよりご覧ください。
これからも、＠IT自分戦略研究所をよろしくお願いいたします。
