ログイン

会員登録

検索

ログイン

メニュー

検索

ログイン

メニュー

伊藤直也の1人CTO Night

2016.08.30 - 2016.08.30

伊藤直也の1人CTO Night（全8記事）

2016.10.27

メインカテゴリテクノロジー

君のチームに「構造」はあるか？　伊藤直也が語る、学びが蓄積されるマネジメント

リンクをコピー

記事をブックマークブックマーク解除

画像・スライド一覧

2016年8月30日、これまで2社のCTOと5社の技術顧問を経験してきた一休の伊藤直也氏による「1人CTO Night」が開催されました。主催は転職サイト「DODA」を運営する、株式会社インテリジェンス。開発知識に加え、マネジメントスキルも求められるプロダクトマネージャーが最速・最高のアウトプットを生み出すにはどうすればいいのでしょうか。本パートでは、伊藤氏が過去の実例から「学習結果が蓄積されるマネジメント」について語りました。

「CTO」と「VP of Engineering」

伊藤直也氏（以下、伊藤）：「1人CTO Night」というちょっとキャッチーな名前のイベントですが（笑）、さっそく始めさせていただきます。一休の伊藤です。

今日は「一休の伊藤」というかたちで出ていますが、あまり自社の宣伝をしてもしょうがないので、過去に技術顧問をやってきた時の経験などを含めて「いろいろな会社でこういうことがありました」と、中立的にマネジメントの話をしていきたいと思ってます。

事前に聞いてみたいんですが、このなかでマネージャーをやってる方は、どのくらいいらっしゃいますか？

（会場挙手）

おお、けっこういますね。半分より多いかな。あとはエンジニアの方が多いんですよね？　では、そういった文脈で話していきます。

今回の対象にしたいのは、1万人いるような大きな会社の話ではなく、Webあるいは受託系のシステムでも……なんでもいいですが、基本的には従業員が50〜300人くらいの規模の会社のことだと思って聞いていただきたいと思ってます。

それ以上の規模になるとまたフェーズが変わってくるので、今日話すことが当てはまらないかもしれないです。

一応私、CTOという肩書をもって今日「1人CTO Night」というお話をしているんですけど……。今日はCTOの話より、どちらかというと海外では「VP of Engineering」（Vice-President of Engineering）と言われている肩書きの人が担当する領域の話をしたいと思います。

この2つの何が違うかというと、日本ではCTOがどちらも兼任することが多いですが、基本的にCTOは、tech leadというか、chief architect的な、あくまで技術のリードをしていく人のトップというイメージが強いです。

例えば、玉川（憲）氏が以前にいらっしゃったAmazonのAWSのCTO、ヴァーナー・ボーガス（Werner Vogels）さんなどが有名です。ご自身でクラウドシステムのバックエンドのアーキテクチャを考えてリードしている。技術で問題解決をやってるCTOも多いというか。それが本懐のCTOだと思うのですが。

それとは別に組織を作ったり、人を集めてきたり、マネジメントしたりというのがVP of Engineeringです。役割が分かれていることが多いですね。

おそらく今日来ていただいているマネージャーさんは、こっちのVP of Engineering的な仕事のほうが多いんじゃないかと思います。そのため、その文脈で話をしていきたいと思います。

マネジメントで一番大事なのは、問題発見

ひと言に「マネジメント」といっても、いろいろ領域があります。ここに書いてあるだけではないですね。例えば、採用などいろいろあります。

今日は事前にいろいろ質問をいただいていますが、「組織やチームをどうやってマネージしていくか」「人をどうやってマネージしてるか」という質問がすごく多かったので、その2つにスコープを絞って、コツや自分なりの考えを話していきたいと思います。

各論に入る前に、これは最近、僕がいろんなところで出している図です。『イシューからはじめよ』という本がありまして、その最初のほうに出てくる図なんですね。

エンジニアの組織でよくある話なんですが、エンジニアは手段をビジネスにしている仕事じゃないですか？　最終的な成果物ももちろん作るけれど、その途中のコードをどうやってうまく設計するか、そもそもどうやってシステムに落とし込むか、というプロセスをやる仕事です。

しかし、仕事だけに限らずどんなことでも、問題を解く方法と「そもそも問題設定が正しいかどうか」を見極めるという、2軸に分けて考える必要があるんですよね。

エンジニアというと、ついついこの軸が2本じゃなくて1本になっちゃって。だから、例えば「GitHubを入れれば組織がうまくいく」という、冷静に考えるとそんな短絡的なことはないはずのことを真顔で言い出すんですよ。そういうのをきちんと分けて考えなきゃいけない。

この横軸の「イシュー度」が、正しい問題設定をきちんとできているかです。上が、それをどうやって解くかという話ですよね。

やはりマネジメントで一番大事な仕事は、問題を解決することじゃなくて「問題を発見する」「正しい問題を見極めることにフォーカスする」、あるいは「チームを正しい問題にフォーカスさせることだ」が基本的な姿勢としてあると思うんですよね。

よくエンジニアからマネジメント側になったばかりの人は、自分があらゆる問題を解こうとするんだけれど。マネージャーは、その問題をきちんと発見して設定し、それを現場にいるメンバーに渡して解いてもらうのが基本姿勢だと思うんですよ。もちろん自分で解いてもいいんだけれども。

正しい問題設定さえできていれば、あとはみんなが問題を解いてくれる状況を作り出して、自分は正しい問題を見極めることにフォーカスするのがすごく重要です。

これをやらないと、組織があっちいったりこっちいったりして、わけわからないことを始めたり、それをやっても効果があんまり薄いってことをやっちゃたりします。こっちにこんなに大きな問題があるのに、瑣末な問題ばかり解いちゃう。

そういうことが起こるので、「今、一番自分たちが解かなきゃいけない問題はなんなのか」にフォーカスさせることが、マネージャーとしては重要です。こういった前提をおいて、組織マネジメントについて見ていきます。

その組織とチームに「構造」はあるか

まず最初に、「組織あるいはチームには構造がある」という話をします。

とくに内製開発ですね。自社でエンジニアを何人も雇って、自分たちで自分たちの事業をやってるような。一休のようなサービスはそうなんですが、そういうチームのマネジメントは、スポーツチームのマネジメントになんとなく感覚としては近いです。

あごでエンジニアを使って仕事をしてもらう感じではなく、高い能力を持った人の潜在能力をどこまで引き上げられるかということを、マネージャーとしては追求しなきゃいけない。

みなさんもよくご存じだと思いますけど、ソフトウェアの開発って隣の人がダメなコードを書くとまたその隣の人が迷惑するという構造になってるので、チームワークを必ず発揮しなきゃいけない。それなしには避けて通れないところがあります。

チームとして、いかにきちんと連携してものごとを進められるかを考えます。剣道のような個人競技ではなくて、サッカーのような極めてチーム的な競技なんですね。

例えば、小学生がサッカーボールを蹴りにいくと、11人全員でボールを追っかけにいくじゃないですか。大人になってくると、さすがに11人全員で追っかけてると負けるのがわかってるので、オフェンス、ディフェンス……ナントカって役割に分けますよね。そういう、チームには構造があって、それをきちんと見極めて作っていくのが、マネジメントとしては重要です。

内製開発のチームのよくある組織構造は、だいたいこんな感じになっています。「セールス」「エンジニア」がいて、会社によっては真ん中の「プロダクト」があります。企画やプロダクト……といろいろ言われますけど、ここがない会社もあります。こうしてだいたい横串になっている。

ただ、この横串でやってると、わりと仕事のやりとりが五月雨式になっていきます。人が増えてくると、例えば、セールスの人からエンジニアの人に直接依頼がいって、エンジニアの人がそれを受けちゃって、リソースのコントロールができなくなる。そういうことがわ～って起こります。

この中間にある「プロダクト」みたいな人が間に立つようになって、「1回ここで要望を集めます」とすることもあるんですが、エンジニアがセールスの言うことを聞いてないこともあり、ユーザーの肌感覚がわからなくなったり、間に余計なコミュニケーションが挟まったせいでスピード感が出なくなったりします。

会社の中で「最近、ユーザー像が見えずにものを作ってます」といった悩みが出てきたりします。そういうことを打破しようとして、だいたい縦にユニットを作るようになるんですよね。縦のユニットにセールスの人がいないこともありますが、プロダクトの企画を考える人とエンジニアが役割分担するかたちで一緒になって、こういうふうにチームを作っていきます。

例えば、チームAは、ユーザーインターフェースを作るチーム。チームBは、バックヤードや業務ロジックをきちんと作るチーム。チームCは、技術の基盤を作るチーム。そういうふうに、ミッションを縦分けにして、自分自身がオーナーシップを持って、その領域を見ていけるようにするってことをやります。

逆にスタートアップだと、たまに縦の構造しかない会社もあります。そうすると、今度は横がないので技術標準を作れず、隣のチームと隣のチームが全然別のやり方することがよく起こったりします。そのため、「縦と横の構造をハイブリッドにしてやっていく」という結論に自然と到達しやすい。これが基本的な構造だと思います。

構造がないチームに、学習結果は蓄積されない

どんな構造でも最終的には目的が達成されればいいんですけど、大切なことは、いろんな開発をして、市場に製品を投入して、その製品がユーザーに受けたかどうか……など、いろんなことを学ぶ中で、それがチームに蓄積されていく構造になってるかが重要です。

毎回毎回違うプロジェクトをやるような会社は話が別なんですが、とくに自社でサービスやってるような会社だと、このAチーム、Bチーム、Cチームが、それぞれずっと同じミッションを持ってやっていくわけじゃないですか。そのときに、そのチームのなかに「やったことの学習結果」が溜まっていかない状態になってると、構造を作っている意味がほとんどなくなっちゃうんですよね。なので、ここが重要です。

わかりやすい例が、日経新聞社さんであったことです。

日経さんはもともとシステムを外注して、基本的には作っていた会社でした。外部の会社に仕事を頼んでいる会社と、社内で作っている会社って、放っとくと組織の形がけっこう違うものになるんですよね。

なぜ外部に発注するかというと、リソースの融通を利かせたいからです。自社でリソースを抱えずに外に発注すると、欲しいときにそのリソースが確保できる。それが大きい目的なんです。

そうすると、外の会社さんに作ってもらってる間は別の企画をやろうとなり、1人の社員が2つも3つもプロジェクトを兼務することになるんですよね。どちらかというと、先ほどのようなチームの構造ではなく、いかに1人の人がたくさんのプロジェクトを掛け持ちできるか……という構造になっていくんですよ。

1人の人が兼務でたくさんのプロジェクトを掛け持ちすると、仕事の分担は、横に仕事、縦に人の名前が書かれた表で表現されるようになり、「この人はこれとこれとこれをやってる。この仕事は、この人とこの人がペアでやってるけれど、こっちはあの人とこの人がやってる」といった、不規則なアサインメントになります。

こういう構造では、チームではなく個人に学習結果が溜まります。

例えば、日経さんなので新聞アプリを作ると思うんですけど、「新聞アプリが終わったから、次はパソコン版のあそこ作って……」と言ってる間に、新聞アプリの別の案件が来ると、もともとやってた人はリソースが空いていないから、別の人にアサインされたりするんですよ。そうすると、コンテクストが全部分断されてしまい、ラーニングの結果がきちんと溜まっていかないことが起こります。

日経さんがその後「やはり自分たちでメディア面を作らなきゃいけない」と考えて、内製開発のチームのやり方を始めたんだけれど。会社的には、ずっと外にお願いするやり方だったから、組織を内製的な構造に転換しなきゃいけないことに気づかず、ずっと兼務のまま、内製でプロダクトを開発してたんですよね。

そうすると、今言ったように、せっかくチームで開発してるのに、発見した課題と結果が自分たちの中に溜まっていかない状態が起こりました。そこで、内製開発チームは基本的に兼務を解消するというマネジメントが実行して、「iOSアプリチーム」「PC版チーム」と、先ほどの縦の構造で分けて、1チーム1ミッションずつ持ってもらうことをばっさりやりました。