▶平日 毎朝7時に公式LINE@で新着記事を配信しています。友達申請はこちらから！
▶ICCの動画コンテンツも充実! Youtubeチャネルの登録はこちらから！
「ゼロから学ぶITエンジニアリング・チームの作り方」8回シリーズ(その4)は、エンジニアリングチームへの権限移譲について。「“How”は権限委譲したほうがよい」というビズリーチの竹内さんに対して、壇上の意見は2つに分かれます。議論の展開をぜひご覧ください！
▶ICCパートナーズではコンテンツ編集チームメンバー(インターン)の募集をすることになりました。もし興味がございましたら採用ページをご覧ください。
ICCサミットは「ともに学び、ともに産業を創る。」ための場です。毎回200名以上が登壇し、総勢800名以上が参加する。そして参加者同士が朝から晩まで真剣に議論し、学び合うエクストリーム・カンファレンスです。次回 ICCサミット FUKUOKA 2019は2019年2月18日〜21日 福岡市での開催を予定しております。参加登録は公式ページをご覧ください。
ICCサミット FUKUOKA 2018のプラチナ・スポンサーとして、ビズリーチ様に本セッションをサポート頂きました。
▼
2018年2月20-22日開催
ICCサミット FUKUOKA 2018
Session 4F
ゼロから学ぶITエンジニアリング・チームの作り方
Supported by ビズリーチ
(スピーカー)
岩田 和宏
JapanTaxi株式会社
取締役CTO
柴山 和久
ウェルスナビ株式会社
代表取締役CEO
竹内 真
株式会社ビズリーチ
取締役 CTO 兼 CPO
舘野 祐一
WAmazing株式会社
共同創立者 取締役CTO
(モデレーター)
松岡 剛志
株式会社レクター
代表取締役
▲
▶「ゼロから学ぶITエンジニアリング・チームの作り方」の配信済み記事一覧
連載を最初から読みたい方はこちら
最初の記事
1. ゼロからITエンジニアリング・チームを作ってきた登壇者が集結！
1つ前の記事
3. 元財務官僚・ウェルスナビ柴山氏が、最初のITエンジニアを採用した手法とは？
本編
松岡 それではこのトピックを話したいと思います。
「エンジニアに権限委譲したら、エンジニアリング・チームは作れる」。
これはフェーズ2、エンジニアのチームがちょうどできたぐらいの段階ですね。
CEOとCTO、そしてエンジニアが数名いるような、そのくらいのフェーズをイメージしています。
このくらいの段階で、CEOはどの程度エンジニア・チームに権限委譲していくべきなのか。
もしくは権限委譲していったら、いいエンジニア・チームが作れるのか、それともCEOがもっと締めていった方がいいのか。
どのように関与していけばいいのか、これはこのくらいのフェーズの会社では結構悩ましいポイントだったりすると思います。
特にプロダクト寄りのCEOだったりすると、プロダクトのことを一番わかっているのは自分だと考えているはずですし、ゆえにプロダクトに関与し続けたいと考えるでしょう。
権限委譲してみたけれど、ものが全然リリースされないとか、大事と考えている何かが抜けたリリースがされて、結局自分の管轄に戻すなどを経験されることも多そうです。
この辺についていろいろと話していければいいなと思うのですけれども、それこそ社長の圧が一番強そうなところでいうと、やはり僕は岩田さんの顔を見てしまいます。
いや、登壇者の皆さんそれぞれに苦労されていた感じがありますね。
まずは岩田さんから伺いましょうか？
CEOはエンジニアリング・チームにどこまで権限移譲すべき？
JapanTaxi株式会社 取締役CTO 岩田 和宏氏
岩田 CEOの「圧」に関しては、皆同じぐらいだと思います。
どこまで権限委譲したらという話ですよね。
正直、弊社も未だにその答えが出ていない状況です。
基本的には各チーム、各プロジェクトチームがほぼ裁量を持って優先順位を決めて、タスクを決めて、タスクの優先順位を決めて、スケジュールを決めてというようには、うまく流れるようになっています。
一方、「JapanTaxi」アプリは、もともと川鍋（日本交通会長・川鍋一朗氏）がスマホのGPSを活用しピンポイントの場所へピザを届けるという、ある宅配ピザのアプリを見ていて、「これはうちでもやれるはず」と始まったということもあり、CEOの思い入れが非常に強いプロダクトです。
知り合いも含めいろいろな方が使ってくださっているので、CEOに直接フェイスブックのメッセンジャーなどで「ここだめだったよ」というような指摘があちこちから来ることもあり、まだまだプロダクト作りが気になっているようです。
開発チーム用のSlackのチャネルがあるのですが、そこでも、「これやってくれない？あれやってくれない？」というオーダーがCEOから直接、来ることもあります。
このJapanTaxiアプリの開発チームは今20名ぐらいで、サーバーサイドとかiOS、アンドロイドをやっているのですが、PMを立てています。
けれども、やはり特に優先順位を決めるのに誰がプロダクトオーナーなのかという点は、いろいろ紆余曲折しているのが現状です。
PMがオーナーと思っていても、CEOからオーダーが来るのを見ているので、PMからすると結局は役員だろう、と感じているようなところもあったりして、今も生々しいやり取りが起きています。
それが本来あるべき姿かというと、まだ自分の中でも答えが出ていないというのもあって、バランスを取りながら進めていますが、もやもやしているというのも事実です。
CEOは「Where」を示し、「How」は権限移譲せよ
竹内 権限委譲の話には、チームとプロダクトという両方がある気がします。
極論を言えば、サービスがきちんとできて、適切に運用されていて、ビジネスになっていたら、それはいいのではないかと思います。
1人でやっていても、100人でやっていても、別にいいのかではないかと考えています。
開発中のサービスに対して課題を設定する際、CEOはエンジニアでないが故に、リソースや難易度を考慮できていない要望をすることがあります。
たとえば、ウェブの中でメッセージをやり取りするという機能について、「（その機能を）Gmailみたいにしたい」と課題を設定されたとしましょう。
「Gmailにしたい」と書かれた瞬間、もう恐ろしいことになりますよね、エンジニアのモチベーションダウン具合が。
写真中央 株式会社ビズリーチ 取締役 CTO 兼 CPO 竹内 真氏
柴山 ちょっと待ってください、それがどういうことかは分からないです。
竹内 それ分からないでしょう？
柴山 分からないです。
竹内 分からないので、これを理解し合うのはたぶんすごく難しいです。
柴山 たぶんですね、エンジニアのバックグラウンドがないCEO目線で言うと、「Gmailにしたい」というのは、もう最高のインプットぐらいのイメージだと思います。
「こんな分かりやすい具体的な目標設定はないのではないか」ぐらいの発想なのではないかと思います。
竹内 エンジニアからすると、「あのグーグルが、どれほどのエンジニアの量と時間をかけてここに到達しているのか、あなたは計算できますか？」です。
だからそういう問いが来るとね、レスポンスとしてそう言い返したくなるような気持ちなわけです。
やはり「How」への意見を求めると、エンジニアにとっては受け入れがたい要求になりかねないのです。
一軒家に例えると、「やっぱり柱は金がいいよね」と言っているのと同じようなものです。
「そもそも、どこにそんな大量な金があるのか」と思いませんか？
だから、サービスとしてどこに行きたいか、つまり「Where」や、何が必要なのかという話をして欲しいのですが、「How」は権限委譲してもらった方が、成功にぐっと近づくのかなというように思います。
そのうえでいいチームができるかどうかは、ここは人間力だったり、哲学とか文化、誰が作るかということにも依りますよね。
うちの会社でもいろいろなチームがあります。
行動派で、考えながら走って、ちょっと失敗もしちゃう、みたいなチームもあれば、慎重派で、コツコツ仕事を進めていくチームもあります。
でもそれはある意味、トップの人に権限委譲をしているからこそだと思います。
あなたの目指すやり方、やり易いようにチームを作りなさいというと、やはりそうなってしまうものです。
それがいいか悪いかは分からないですけれど、やはりそれぞれですよね。
松岡 「How」の権限委譲をしている方は、どのくらいいますか？……ほとんどいませんね。なるほど。
「How」の権限委譲って、とても怖くないですか？
チームがもしポンコツだったら、「How」を権限委譲したらたぶんモノができてこないですよ、怖くないですか？
大きな方向のすり合わせは早いうちに
ウェルスナビ株式会社 代表取締役CEO 柴山 和久氏
柴山 怖いですよね。
特にたとえば金融のサービスだと、エンジニアで金融出身の人というのはそれほど多くないので、そもそもどういうサービスなのか分からないという課題があります。
それに対して金融の人たちは、「こういうのが欲しい」と言ってきます。
それがまた金融の世界では当たり前だったりするわけです。
しかし、金融の世界の人たちが言っていることをそのままエンジニアに伝えると、まさに「Gmailがいい」「俺っていいこと言ってるじゃん」みたいな展開になり、その結果衝突が起きるという構図に簡単に陥ってしまうと思います。
私たちウェルスナビでも、今から1年前(2017年)にICCのカタパルト・グランプリに登壇した頃は、私は「こういうサービス、こういう機能が欲しい」みたいなことを言っていたと思います。
▶参考：全自動で世界水準の資産運用を実現する「ウェルスナビ」(ICC FUKUOKA 2017)
当時は確か、ユーザー数が1,000人ぐらい、そして預かり資産が10億円ぐらいでした。
今だと当時に比べ両方とも50倍、60倍ぐらいになっています。
預かり資産は600億ぐらい(2018年2月現在)になっているのですが、そうなってくると、もう逆に怖くて「How」を言えないですね。
つまりどういうプロセスでどういう機能を作っていった場合、どのくらいのお客様にどういうインパクトがあるのかということが、エンジニアでないので分かりません。
ですので、大きな方向性の擦り合わせをなるべく早い段階でしておいて、後からビジネスサイドでちゃぶ台返しが起こらないようにするということに努めています。
あとはプロダクト・マネージャー（PM）はあえてエンジニア出身の人にしています。
PMとエンジニア・開発が分かれるというのは、やはり辛いので、そこは統合しておくようにして、極力権限委譲するように、今はむしろ気を付けています。
舘野 よければメンターとして来てください(笑)。
エンジニアチームの「レベル」と「数」によってマネジメント方法は異なる
舘野 今「How」の話が出てきたのですが、何か皆さんが話していたのは、5W1H的な話だと「5W」の方なのではないかという気がしています。
要するに何を誰にどう伝えるのかというのは、会社のビジョンだったり、創業者や社長が実現したいものですよね。
それをチームとしてどう実現するか、どうやるかです。
WAmazing株式会社 共同創立者 取締役CTO 舘野 祐一氏
たとえばそれを実現するためには、「技術的にはこういうアプローチだし、会社の状況やセキュリティを考えると、こういう風にやっていくべきだ」という部分は専門知識が要求されるので、「How」のプロセスはたぶんそのチームに委ねられるというのが最初の一歩だと考えています。
エンジニアリング・チームにしても、会社、社長が求めるもの、あるいはその会社の状況においてそのチームのやりたいこと、やるべきことというのは変わってくると思います。
チームにもいろいろなタイプがあります。
たとえば本当に「How」だけをしっかりこなすチームもありますよね。
要するに、「社長に本当にビジョンがあって、こういうアルゴリズムを適用したら、きっといけるよ」みたいなものがあると、エンジニアは「How」の部分をしっかり実装していくことになります。
さらにその1歩先を行くならば、一番大切なのは、初期においては大抵の場合ユーザー体験であることが多いです。
先ほどはデザインをテーマにしたセッションを行っていたのですが、デザインというのは、いわゆる絵に描いたデザインという意味ではなくて、ユーザーエクスペリエンスのデザインというところが一番大事です。
そこからどう開発チームを構成していって、回していくかですが、チームの中にそれができるようなメンバーがいるのであれば、できる限り権限委譲した方がいいのではないでしょうか。
逆にそれができないようであれば、社長がその「5W」をどんどん伝えていって、それをどう実現するかを現場のメンバーを含めて考えるというのが、数人のエンジニアから成るワンチームのフェーズだと考えています。
写真左より、柴山氏、竹内氏、舘野氏
特に社長がプロダクトオーナーの場合にありがちなのが、マイクロマネジメント的に「いや俺はこういうモノが作りたいんだ」とどんどん出て行くと、チームとしては言われたものを作るだけになってしまったりします。
ただ、チームがある程度の数になるとそのままだとスケールしないので、その状況になるとできる限り権限委譲していくことが求められます。
そのためには、社内のメンバーを育てるのももちろんですが、外部からマネジメントやユーザーエクスペリエンスの定義ができる人を入れてきて、そこの部分を上手く分散して活躍させていく必要があります。
それをせずにある程度のフェーズ以上になると、社長がボトルネックになったり、何か指示されたものをよく分からないけどただひたすら作るみたいなことになり、メンバーのモチベーションに影響すると思っています。
「どういうチームを作りたくて、今いるメンバーだとどういうことが可能なのか」ということを考えて上手くコミュニケーションを取ると、いいチームが初期の段階から作れていく可能性があると、話を聞いていてすごく思いました。
誰がプロデューサーで、誰がクリエイターなのか？
竹内 話を聞きながら思っていたのですが、プロデューサーやクリエイターという概念が混ぜこぜになっているような感じがします。
いろいろな人が触るような、使うようなサービスで何かを作ろうとしているわけですよね。
一般的には、たとえば家を建てるにしても、設計士がいて、一級建築士がすごくかっこいいものを作れるかというとそうではなく、デザイナーズの建築士の方が優れたデザインを描けたりしますよね。
エンジニアというのは建築士や大工さんみたいな感じですが、言葉が1つしかないため全部の役割が入ってしまっているので、一般論として、「とにかくCTOに全部任せておけ」「かつチームもまとめろ」といった議論になっているような気がします。
社長がプロデューサーなのか、エンジニアがプロデューサーなのか、というのが分かっていればいいとは思います。
それから、先程のGmailが欲しいという話ですが、プロデューサーが不在だと聞いていて思いました。
プロデューサーやクリエイターというのは、要はサービスなりプロダクトを作る時にどのくらいのコストがかかっているのかというROIが分かったうえで、やはり現実的な戦略を出していかないといけないと思います。
これがないとやはり溝が深くなってしまうでしょう。
そのため、今の「How」をどう委譲するかという話は、その機能が議論されていないがゆえに、「どっちでもいいけど、うまくいかなかったら潰れる」となっているのかなと思いました。
松岡 ありがとうございます。
セッションが始まってからもう45分消費していることに気が付いてしまいました。
これまで議論したトピックが2つなので、もう少し話せる気もするのですが、皆さんと話したいテーマがあるので次に進ませていただきます。
(続)
次の記事を読みたい方はこちら
続きは 5. JapanTaxiが試みるタクシー業界とITエンジニアのカルチャーの融合 をご覧ください。
▶平日 毎朝7時に公式LINE@で新着記事を配信しています。友達申請はこちらから！
▶ICCの動画コンテンツも充実! ICCのYoutubeチャネルの登録はこちらから！
編集チーム：小林 雅／本田 隼輝／尾形 佳靖／浅郷 浩子／戸田 秀成／鈴木ファストアーベント 理恵
他にも多く記事がございますので、TOPページからぜひご覧ください。
更新情報はFacebookページのフォローをお願い致します。
