
2025.02.12
職員一人あたり52時間の残業削減に成功 kintone導入がもたらした富士吉田市の自治体DX“変革”ハウツー
リンクをコピー
記事をブックマーク
伊藤直也氏(以下、伊藤):「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ミッションずつ持ってもらうことをばっさりやりました。
そのへんの詳しい話は、日経さんから直接プレゼンが出てるので、見てもらったらおもしろいと思います。
君のチームに「構造」はあるか? 伊藤直也が語る、学びが蓄積されるマネジメント
「人間より組織構造にフォーカスを」伊藤直也が解く、チームなのに“1人”になってしまう謎
ぬるま湯 or 過重負荷のチームを脱却せよ–伊藤直也が「1人CTOナイト」で話したヒント
「ビジネスvsエンジニア」の構造に持ち込むな チーム内外の信頼を勝ち取るマネージャーの処世術
「指示待ち人間はマネジメント側の責任」メンバーが常に挑戦できる環境づくりのヒント
「リーダー=時間に追われる」を覆せ--伊藤直也と玉川憲が指摘する、マネジメント職の線引き
「雰囲気がいい=いいチーム」ではない! “仲良しグループ化”が優秀人材を逃す罠
全員が“勉強マン”でなくていい--伊藤直也が説く「多様性ある組織の強さ」
2025.02.13
“最近の新人は報連相をしない”という、管理職の他責思考 部下に対する「NG指示」から見る、認識のズレを防ぐコツ
2025.02.06
すかいらーく創業者が、社長を辞めて75歳で再起業したわけ “あえて長居させるコーヒー店”の経営に込めるこだわり
2025.02.13
AIを使いこなせない人が直面する本当の課題 元マッキンゼー・赤羽雄二氏が“英語の情報”を追い続ける理由
2025.02.12
マネージャーは「プレイング3割」が適切 チームの業績を上げるためのマネジメントと業務の比率
2025.02.12
何度言っても変わらない人への指示のポイント 相手が主体的に動き出す“お願い”の仕方
2025.02.13
「みんなで決めたから」を言い訳にして仲良しクラブで終わる組織 インパクトも多様性も両立させるソース原理
2025.01.07
1月から始めたい「日記」を書く習慣 ビジネスパーソンにおすすめな3つの理由
2025.02.10
32歳で「すかいらーく」を創業、75歳で「高倉町珈琲」で再起業 「失敗したからすかいらーくができた」横川竟氏流の経営哲学
2025.02.14
報連相ができない部下に対するコミュニケーションの取り方 「部下が悪い」で終わらせない、管理職のスキル向上のポイント
2025.02.10
A4用紙を持ち歩いて殴り書きでアウトプット コクヨのワークスタイルコンサルタントが語る、2種類のメモ術
着想から2か月でローンチ!爆速で新規事業を立ち上げる方法
2025.01.21 - 2025.01.21
新人の報連相スキルはマネージメントで引きあげろ!~管理職の「他責思考」を排除~
2025.01.29 - 2025.01.29
【手放すTALK LIVE#45】人と組織のポテンシャルが継承されるソース原理 ~人と組織のポテンシャルが花開く「ソース原理」とは~
2024.12.09 - 2024.12.09
『これで採用はうまくいく』著者が語る、今こそ採用担当に届けたい「口説く」力のすべて
2024.11.29 - 2024.11.29
【著者来館】『成果を上げるプレイングマネジャーは「これ」をやらない』出版記念イベント!
2025.01.10 - 2025.01.10