CodeIQ MAGAZINECodeIQ MAGAZINE

伊藤直也氏が語る、マネジメントで本当に大事なのは「問題にフォーカスする」である理由

2017.05.11 Category:勉強会・イベント Tag: , ,

  • 736
  • このエントリーをはてなブックマークに追加

ソフトウェア開発の現場やエンジニア組織のマネジメント。実はよかれと思っていることが、エンジニアの生産性向上やビジネスの成果のマイナス要因になっていることもある。一休CTOの伊藤直也さんが「問題にフォーカスする」というテーマで、これまで自身で体得してきたマネジメントのコツを紹介した。 by 馬場美由紀 (CodeIQ中の人)

正しい問題に取り組むことは難しい

今回なぜこのようなテーマにしたかというと、昨年夏のイベント「1人CTO night」で、開発組織マネジメントのコツについて話をしたことがきっかけ。

開発チームのメンバーが正しい問題に取り組んでいる状態を作ることが重要だという話をしたんですが、参加者の反応の多くが、「人のマネジメントは大事」「1on1の面談は大事になる」「心理的安全性、大事だね」というプロセスの部分に関心が集まっていました。

なので今回は「正しい問題に取り組むこと」とは何か、それがなぜマネジメントにとって必要なのかについて、改めて話をしたいと思います。

株式会社一休 執行役員CTO システム本部長 伊藤 直也さん
ニフティ、はてな取締役CTO、グリー統括部長を経てフリーランスとして活動。Kaizen Platform, Inc.、株式会社一休、 日本経済新聞社ほか複数社の技術顧問/技術アドバイザーを務める。著書に『入門Chef Solo』(達人出版会)、『サーバ/インフラを支える技術』『大規模サービス技術入門』 (技術評論社) など多数。2016年4月より、株式会社一休 執行役員CTO システム本部長に就任。

「エレベータの混雑問題」をどう解決する?

仮にあなたがビルの管理者だったとします。そのビルで毎日、出勤の時間になると行列ができるので苦情がたくさん来てしまう。これを解消するにはどういうアプローチがあるでしょうか。

この問いに対して、エンジニアが考えがちなのが以下のような回答です。


  • 配送アルゴリズムを最適化する
  • 物理的にエレベータを増やす
  • 階段を使うなど

実はこれは「ライト、ついてますか」という書籍に載っている問題。そこで有効な解決策として挙げているのが、


  • エレベータの前に鏡を置く

鏡を置くと待っている人たちは鏡を見て、身だしなみを整えたりしている間に勝手に順番が来る、ということなんです。

問題をエレベータのキャパシティの問題と捉えるか、行列している人のストレスを解消する問題と捉えるか。問題は解く前に、どう設定するかで解決策が大きく変わります

先に挙げた方法では、コストも時間もかかる。一方、鏡を置くという簡単でコストのかからない方法で問題が解消できるのです。

同じようなことはソフトウェア開発の場面でも起こっています。例えば、「芸能人の名前を判定したい」というニーズがあったとします。


  • テキストの文字から芸能人の名前を抜き出したい
  • そういうライブラリを作れないか。

エンジニアは自然言語処理をして、人名と思われるテキストを抜き取って、その名前を芸能人のデータベースとマッチングさせ、そして機械学習させるという方法を採りたいと考えたが、そんなに完璧には抜き出せない。

しかもデータベースを常にアップデートしていかないと、将来の新人芸能人には対応できない。

そんな壮大な計画を考えたのに、最終的に依頼してきた会社が採用したのはこちら。


  • ウィキペディアから芸能人データを引っ張ってくる

検索するのはその場限りでよく、しかも8割ぐらい判定できればいいということだったらしいのです。

このように「正しく問題を見極める」ことは非常に大事なこと。ここでいう問題とはプロブレムではなくイシューです。

イシューは模索すべきトピックのことで、僕たちは、まずは十分にイシューを模索し見極めて、そのあとで問題を解く癖を付けることが大事なんですが、それは意外と難しい。

なぜなら、人間は問題が目の前にあると、何とかしなくてはという本能が働くからです。さらにその問題を解き始めると、それを解くことに執着が出てくるから。

結果、問題を理解することにもっと時間を使うべきなのに、解くことにばかり意識がいって間違った問題設定のまま、問題を解こうとしてしまう。

ではなぜ、イシューを見極めることが大事なのか。「イシューからはじめよ」という書籍では以下のように解説されています。

以下のような横軸にイシュー度、縦軸に解の質をとった四象限の図があります。右上の箱が本来のゴール(バリューのある仕事)を目指すべきなのに、人は左側の縦軸、解の質・・・つまりプロセスを良くする方向に注力してしまいがちです。

例えば、開発組織の問題を解決するためのマネージャーの施策として、デプロイを自動化して開発スピードを上げ、試行錯誤できる回数が増やしたり、チームビルディングをしてコミュニケーション不全を解消を図ろうとしたりすることは多いですね。

それはそれで大事なんですが、一方、やるべきことは何なのかをはっきりさせるということが、当たり前ですが実は一番大事です。やらなくても良いことのためにプロセスを良くしても意味はないですから。

それをせずにチームビルディングやプロセス改善に邁進するのは、プロセスばかりに注目して問題に注目していないということになります。

イシューをきちんと見分けないと罠に陥る

最近のマネジメント分野は、チームの心理的安全性を高めていこうというトレンドがあります。

それは、他の人が作ったものがいまいちだったときにも気兼ねすることなく指摘できたり、建設的な議論ができるような環境であれば、よい成果に繋がりやすいだろうというところから来ています。

確かに働きやすい職場はいいし、建設的な議論ができることと生産性には相関関係があることは、数値を調べなくても明白です。

一方で、心理的安全性が高ければそれだけで「良いプロダクト」ができるかというと、そんなことはない。当たり前ですが、「良いプロダクト」を作るには「良い企画、良い問題設定」が必要です。でも、そのことに多くのマネージャーは気付かない。

僕も働きやすい職場を目指し、働きやすさを追求したことがある。採用も上手いくようになり、優秀なエンジニアも採用できた。フラットで働きやすいし、不安を取り除くことにも一生懸命だった。

しかし高揚感が湧き上がらないというか、すごく良いプロダクトを作っているチームにあるような熱気や情熱を演出できなかったんです。

そして退職する人もポツポツと出てくるようになった。退職者に話を聞くと「職場環境には不満がないけど、でもなんか、う~ん…」と言う。悩んだ末にようやくわかったことは、心理的安全性と責任はセットで考えなければならないということ。

心理的安全性を高めるだけでは責任が伴わないので、ぬるま湯になるだけ。働きやすさばかりを追求した結果、ぬるま湯になりかけていたのです。

そうではなく、これこれこういう問題を解消してほしい、プロダクトの成果に責任を持って欲しいという「責任」の軸を忘れてはいけない。チームビルディングばかりしていても、プロダクトも業績も良くはなりません。

僕はリアルタイムストラテジー(RTS)という戦争ゲームが好きなんですが、この類のゲームでも似たような場面をよくみかけます。

RTS は生産行動をして軍事力を高めて戦争をするゲームなんですが、弱いプレイヤーや初心者プレイヤーはいつまでも生産ばかりやっていて軍事行動を取らない。

生産行動を続けていると、たぶん安心感が得られるんでしょうね。でも、当然ですが守る一方なので勝つことは絶対にない。

一方、強いプレイヤーは常に攻撃をする。相手の陣地に攻めて行くので、相手の行動がわかる。

世界の強豪プレイヤーの動画を見ると、攻撃し合いなら、お互いに陣地が広がっていく様が見てとれる。「打って出ることが大事」なのです。

とにかくチームビリディングをして、環境を良くすれば勝てるわけではない。チームビルディングをするなら勝つための戦術を実行して、そこで分かった状況に応じてチームの現状課題を分岐する、ということが大切です。

「イシューからはじめよ」でもまさにこのことが書いてあります。プロセスを良くしてから正解にたどり着こうとすることを「犬の道」と呼んでおり、解の質を高めることがいつしか仕事になってしまい、大事なことにたどりつけないことが起こる。

正しいアプローチは先にまず打って出て、状況にたどり着いてから質を上げていけばよいのです。

いい兄貴にならないこと、嫌われる覚悟を持つ

もう一つマネジャーにありがちな罠が、「いい兄貴問題」。

チームを任されたときに、ついついいい兄貴になって細かいことや雑用、面倒なことを引き受けてしまい、プロダクトや事業のことができなくなり、ビジョンの提示や意思決定ができなくなるという問題です。

みんなの生産性を上げようと思って、面倒事をみんなの代わりに引き受けてマネジメントしている気になる。

でも、それは実際には小さな問題にばかり頭を使っていて、チームがどういう問題にフォーカスすればいいかとか、事業やプロダクトを伸ばすために何をしなければいけないかという大事な問題から目を背けていることに等しいんです。

大事な問題について考えるのが大変だから、ついつい目の前の雑用にばかり目がいってしまう。そして長く大事な問題から目を背け続けていると、事業やプロダクトがわからなくなる。

でも仕事をしている実感が欲しいから、ますますいい兄貴になろうとしてしまう。マネージャーは「いい兄貴」になりたがる自分に打ち克つ必要があります。

僕は一休に入って約1年になりますが、入ったばかりの頃は組織マネジメント周りが弱かったので、まずはそのあたりの評価制度などのてこ入れを行いました。組織的なマネジメントから先に入ったんですね。

ところで一休は、Web系の会社の中では比較的古い会社です。当然技術的負債もたくさんあります。その解消はCTOである僕にとって大きなテーマでした。

技術的負債を解消しようと、どちらかというと引き続き組織面でのサポートから取り組んだのですが、問題の周辺ばかりが解消される一方、一番大事なレガシーアーキテクチャーの問題には誰も手がつけられなかった。つまり、組織的なマネジメントだけで問題を解消しようとしたけれども思うように行かなかった。

ある日それに気がついて、反省して、最も大きなリスクを取れる権限を持っている僕が、間接的にではなく、もっと直接的にコミットしなければと思い直しました。

まず行ったのは問題を正しく把握すること。既存の実装と仕様を読んで分析。はやる気持ちを抑えてコードを1カ月ぐらいかけて読み込みました。

そして、マーチン・ファウラーの著書「エンタープライズ アプリケーションアーキテクチャパターン」で書かれている構造と一休のアーキテクチャと比較し、それをヒントに問題の構造を整理して言語化することを行いました。

問題の理解が進むと、現実的な打開策が見えてきた。大きく見える問題も、理解することで小さく分解できることもわかったのです。しかし、開発には時間がかかる。そこで時間の使い方を変えました。

開発にフォーカスするために権限移譲し、まとまった時間を作った

従来は面談やミーティングで使っていた時間を開発する時間に充てることにしました。結果的にマネージャーである自分自身が問題について深く理解することで、大きな問題を解消する道筋を見極めることができました。

当然ですが、CTO が自ら開発をリードしていれば、周りのエンジニアからの信頼感も変わってくる。やはり、打って出たことが状況を好転させるんだなと実感しました。僕自身が、いい兄貴になりかけていたんですね。

これまでにいろいろと経験した結果僕が辿り着いたマネジメントスタイルの特徴は、とにかく重要な問題にフォーカスする/させることを大事にしていること。大事な問題から自分も、組織も目を背けないために何をするべきかということを常に考えることです。

そのため組織・ヒューマンマネジメントはマネジャーのスコープの一部であり、自分がエンジニアとして開発をリードすることもスコープの一部。つまり、マネジメントのスコープはあまり狭めないようにしています。

そして、チームビルディングよりも問題にフォーカスすることがチームの状態を良くすることがあることを理解すること。そのスタイルを貫くと、場合によっては嫌われることもある。それも受け入れる覚悟は必要だと思っています。

いずれにしても、自らの役割を限定しないこと。いちばん大事な問題にフォーカスするためには、臨機応変に自分の役割を変更できる必要がありますから。これを自分自身に言い聞かせてこれからもやっていきたいと思っています。

  • 736
  • このエントリーをはてなブックマークに追加

■関連記事

及川卓也・増井雄一郎・白石俊平・湊川あい──新しい言語・フレームワークは何を選ぶ?どう学ぶ?... 得意な言語と好きな言語 本セッションのファシリテーターを務めたのは、及川卓也さん。増井雄一郎さん、白石俊平さんがエンジニア枠、そして湊川あいさんはデザイナーという立場で語っていただいた。 ☆登壇者プロフィール プロダクト・エンジニアリングアドバイザー 及川 卓也さん早稲田大学理工学部卒業後...
スタートアップ企業で入社一人目エンジニアに誘われたら、気をつけるべきことは何ですか?... パネラー、ファシリテータを務めた3人のプロフィール テクニカルなスタートアップは、技術のわかるエンジニアとビジネスを考える人材がセットとなって始まる。つまりそういう企業には必ず、「一人目のエンジニア」が存在する。 一人目のエンジニアにどんな経緯でなったのか。また一人目のエンジニアに向いているのは...
アドテクは新しい技術の宝庫!?──ヨッピーさんがインターネット広告の未来、面白さを探る... 1994年のバナー広告から始まったアドテク発展の歴史 今回インターネット広告とアドテクをテーマを選んだ理由は、「アドテクに携わっているエンジニアがすごく少ない」」っていう話を聞いたからなんですね。でもインターネットにおける広告の役割はビジネスにとってすごく大事なことだし、新しい技術もあれこれ入っ...
ドワンゴ塩谷啓氏が明かす──アンチパターンから探る、採用担当者が読みたくなる職務経歴書って?... フォーマットに気をつける 今回のセッションテーマは「採用担当者が読みたくてたまらなくなる職務経歴書を書くために絶対に外せない3つのポイント」。このようなテーマを掲げてはいるが、実は「読みたくてたまらなくなるポイント」というものはない。 それは応募書類自体に、価値があるわけではない。価値があるのは...
これからのマネジメントは面白い!?─多様化するエンジニアのキャリアパスのその先を考えてみた... エンジニアのタイプはさまざま。現在の職種と役割について 9月16日に開催されたCodeIQ感謝祭で、「多様化するエンジニアのキャリアパス、その先を考える」というテーマで行われたパネルディスカッション。 登壇したのは、2017年6月に独立し、現在はプロダクト・エンジニアリングアドバイザーとして活躍...
【CodeIQ感謝祭】豪華ゲスト&ギャル電もサプライズ登場して盛り上がりました!#codeiq39... エンジニアの"最先端"を見て学ぼう!をテーマに開催 2017年9月16日にCodeIQ感謝祭を開催しました。あいにくの雨にもかかわらず、たくさんのエンジニアの方にご来場いただき、本当にありがとうございました。 司会はきゃんちこと、CodeIQ MAGAZINEの公式アイドルレポーター喜屋武ちあき...

今週のPickUPレポート

新着記事

週間ランキング

CodeIQとは

CodeIQ(コードアイキュー)とは、自分の実力を知りたいITエンジニア向けの、実務スキル評価サービスです。

CodeIQご利用にあたって
関連サイト
codeiq

リクルートグループサイトへ