SaaS事業においてサービス開発の核となるのがエンジニア組織。強い組織を作るために試行錯誤しているCTOも多いでしょう。
今回はエンジニア組織の拡大に成功した先駆者でもあるSansan株式会社のCTO※・藤倉成太さんに、「成功するSaaSエンジニア組織の作り方」をお話しいただきました。2021年に事業別組織から機能別組織へと体制を変えた理由や、組織の生産性を測るために必要なこと、マネジメント層に求められるコミュニケーションのポイントなどをうかがっています。
聞き手は、ALL STAR SAAS FUNDマネージング・パートナーの前田ヒロです。
※役職は2022年4月時点。現在は執行役員／技術本部 海外開発拠点設立準備室 室長
SaaSプロダクトは、開発を止めてはいけない
前田：最初に藤倉さんご自身のことと、Sansanの現在地点を教えていただけますか。
藤倉：Sansan株式会社の執行役員とCTOを務めています。Sansanには2009年に入社し、エンジニアとして営業DXサービス「Sansan」の開発に携わったのち、開発部長を経てCTOに就任しました。
Sansanの現在の全従業員数は1,200名ほど。エンジニアや研究員だけだと約300名が在籍しています。これまでにクラウド請求書受領サービス「Bill One」やクラウド契約業務サービス「Contract One」など多数のプロダクトを展開してきましたが、中でも「Sansan」のプロダクトが一番長く、2007年6月の創業時からもう15年作り続けています。
「今はメンテナンスフェーズですか」「完成しきってますか」と聞かれることもあるのですが、そんなことはありません。SaaSのプロダクトは進化が止まると事業が止まってしまうので、開発し続けなければならないんです。
進化しながら開発を続けるには、ただ機能を追加していくだけでは足りません。2019年は「名刺管理から、働き方を変える」、2021年は「名刺管理から、営業を強くする」、2022年は「営業を強くするデータベース」。このように、「Sansan」は毎年のようにプロダクトのタグラインを変えています。
これはマーケティングメッセージであると同時に、プロダクトのコンセプトを表現しています。コンセプトが変わることは、世界観が変わること。エンジニアリング的に言うと、ドメインのモデルが変わることですね。SaaSが進化し世界観がアップデートされていけば、システムの規模やデータベースのスキーマ、アーキテクチャも変わる必要がある。そのため、開発はプロダクトがクローズするまで永久に終わらないものと言えます。
マルチプロダクトなら“機能別組織”が効率的
前田：Sansanは2021年7月に会社の組織体制を大きく変えたそうですね。
藤倉：もともと「Sansan事業部」「Bill One事業部」といった事業別組織だったのを、機能別組織に変更しました。プロダクトの増加にともない会社の戦い方を変えていくためです。
事業別組織は営業やマーケティング、プロダクト開発、カスタマーサクセスといった全メンバーが一つのプロダクトに集中して携われるのが利点。一方で、現在のSansanのようなマルチプロダクト戦略の場合、縦割り体制の事業別組織では余計な調整が増えてしまいます。
事業ごとの「点」ではなく、オールSansanの「面」で戦う。そのための組織変更だと僕は解釈しています。実際、以前と比べて注力したいプロダクトのためにエンジニアリソースやマーケティング予算を割きやすくなりましたし、プロダクト同士の連結がスムーズになりました。
また、事業別組織では事業部長がプロダクトと同じ数だけ必要になりますが、責任の多い役職をそれだけ揃えるのは大変。縦割り組織はマネジメントも複雑になっていくので、機能別組織にすることで社内体制をシンプルにする狙いもありました。
藤倉：具体的に変更後の組織をみてみます。
マーケティングセールスやカスタマーサクセスを行なうのがビジネス統括本部、プロダクトマネジメントやプロダクトUXデザインを行なうのがプロダクト組織。そして社内のあらゆるエンジニアリングを一手に引き受けているのが技術本部です。
技術本部にはプロダクトごとのエンジニアリングユニットが存在しています。人数は「Sansan」が一番多く、現在50〜60人ほど。「Eight」は30〜40人、「Bill One」は40人ほどですね。加えて、全プロダクトのモバイルアプリケーション開発を行なう部署やクオリティアシュアランスを行なう部署があります。「Sansan」であれば、全体で70〜80人が開発に携わっているような規模感を想像していただくといいでしょう。
前田：事業別組織から機能別組織に切り替えた時、現場からはどんな反応がありましたか？
藤倉：現場のメンバーは、最初はすごく不安だったと思います。組織体制が変われば、誰に何を報告するかといったレポートラインも全部変わりますから。ただ、そこで混乱を生みたくなかったので、現場のみんなには「コミュニケーションする相手も、業務の内容も変わらない。ソフトランディングさせて必要な変化を後から追いつかせるから、自分のペースで適応してほしい」と繰り返し伝えていました。
結果的に、変更から1〜2ヵ月が経った頃にメンバーから「組織変更する意味ありました？」と聞かれたことがありました。これは、ソフトランディングがうまくいった証拠だと捉えていますね。その上で現在は次の段階として、ばらばらだった開発レポートのフォーマットやパフォーマンスの測定方法を揃えるなどの整備を進めています。
前田：振り返ってみて、最初から機能別組織を採用していたほうがよかったと感じますか？それとも、事業別組織体制のフェーズがあったからこそ今の成功があるのでしょうか。
藤倉：事業別組織の体制も必要だったと思っています。当社の場合、例えば「Sansan」のローンチ直後は世の中に類似のプロダクトがありませんでした。かっこいい表現をするなら、当時は市場を作りにいかなければならなかったんですよね。
「こんなプロダクトは見たこともないし、誰が買うんですか」と言う顧客に、「僕らはこれがある未来を作るんです」と伝え続けるプロセスです。そこではメンバーが一丸となれることが重要で、事業別組織だからこそ突破できたフェーズはあると思っています。
生産性の測定で重要なのは、同じ基準であること
前田：ここからは、具体的にエンジニア組織の作り方をうかがっていきます。まず、藤倉さんにとって「マネジメント」とは一体、何なのでしょう。
藤倉：開発組織のマネジメントに焦点を当てれば、その意義は開発力の最大化と効率化に尽きるでしょう。メンバーの活躍を測定し、評価することがマネジメントです。個々のエンジニアの生産性向上やその評価方法を考えるとともに、ヘッドカウントを増やすことで戦闘力が上がるなら採用もやるべきだと考えています。
前田：組織の生産性を高めるために意識していることはありますか？
藤倉：前提として、エンジニアの生産性を測ることは深遠なテーマで、そこに答えはありません。もちろん評価をしなければうまくいっているかわからないですし、きちんと測定すればメンバーの手応えにもつながります。だから、必ずやるべきですが、完璧な精度で測定するのは難しいでしょう。
生産性を測る際に重要なのは精度の高低ではなく、常に同じ基準であることです。
開発プロジェクトの工数の見積もりを例にとると、僕が開発部長の時はすべて自分が見積もりを行なっていました。他には、信頼のおけるトップエンジニア1人にお願いしたり、担当者を3人にして合議制にしてもいいですね。体制は色々考えられますが、メンバーを固定すれば、基準ないし精度は一定を保てます。
見積もりをもとに各開発チームに仕事をお願いすると、いつも早く完了するチーム、遅く完了するチームが出てくるはずです。早いチームは背景を理解できていたり動きが素早かったりするでしょうし、遅かったチームはできていないことがあるでしょう。一定の精度で測定し続けることで原因がわかり、結果としてエンジニアのパフォーマンス向上につながります。
前田：なるほど。他に何か工夫はありますか？
藤倉：エンジニアには、1日でどの作業にどのくらい時間を使っているか記録してもらっています。1日8時間働くとして、そのすべてを開発業務に当てられる人はいません。会社が大きくなるほど、全社会議、採用面接、事業部門のミーティング、SaaSとしての運用作業も出てきます。そこで、開発以外に割く時間が増えている傾向にあれば、それらを減らせないか考えます。
あとは、運用コストが30％を超えるものがあればアラートが出る設定も取り入れています。システムが複雑な場合などやむを得ないと判断するケースもありますが、その際も30％というひとまずの基準があることで、「アーキテクチャに困難があって運用コストが上がっているなら、先に技術的な投資をすればトータルコストは安くなるね」といった話ができる。見える化、数値化のメリットですね。
CTOも、採用のOKRを持つ
前田：続いて採用についてうかがいます。藤倉さんはSansanがまだ本当に少人数の時から在籍していますが、採用のフェーズが変わったと感じた時期はありますか？
藤倉：私は入社から13年で、社員番号は18番。エンジニア採用も長年見続けてきましたが、常にアクセルべた踏みという印象ですね。カルチャーフィットや経験を考慮しながら、いつも採れるだけ採用してきました。
十分なリソースで開発が行われなければ事業はグロースしないので、当然、採用には力を入れるべきです。
前田：「採れるだけ採る」という考えをもとに、特に効果的だった取り組みはありますか？
藤倉：状況が一変するような画期的な取り組みはありません。エンジニアは売り手市場でどこも取り合いですし、今も苦労の連続です。
Sansanの場合は、エージェントからご紹介いただくケースが一定数あります。エージェントに足繁く通って、自分の気持ちや事業で成し遂げたいことをしつこいくらい、細かく話していると、他にないスカウトの情報をいただけることもあるので、それは効果があったかなと。
あとは露出を増やしてSansanの名前を覚えていただくなど、細かな努力を積み重ねて少しずつ採用のクオリティを高めていきました。
前田：エージェントも含め、エンジニア以外の方へ自社の魅力を伝えるために、CTOとして工夫している点はありますか？
藤倉：一つは当社のミッションである「出会いからイノベーションを生み出す」がベースにあって、『Sansan』といった営業DXサービスがある、という全体像を伝えること。
Sansanは、人と人の出会いの証しである名刺だけにとどまらず、企業と企業の出会いの証しである請求書や契約書といった領域でも事業を展開、「ビジネスの出会いの価値」に向き合い続けている会社です。
日本国内においては「つながり」ができる瞬間の代表的な行為が名刺交換だから、それをサービス化しただけです。僕も「名刺交換サービスとして大きな企業を目指したい」と言われたら、きっと入社していないと思うんですよ。僕自身も一人のエンジニアとして、それだけのサービスだったら作りたいとは感じないでしょうから（笑）。
もう一つは個人的な感情に基づきますが、日本のソフトウェアやビジネスが国外でも結果を出せるようにCTOを務めている、という意志を伝えること。前職時代にアメリカで仕事をしていると、日本のサービスはグローバルで全然知られず使われない現状があった。でも、僕は日本のエンジニアが優秀だと思っているし、それを証明する事例を作りたいのです。
ソフトウェアならば、国内だけでなくグローバルで何百万人、何千万人に使ってもらえる可能性があって、そういったサービスに携われたら楽しいはず。それこそが醍醐味だとも思っているんですね。特に、エージェントに対しては「藤倉CTOはこういった気合いを胸に臨んでいるんだ」と感じてもらい、他社との差別化ポイントになるように意識しながら話しています。
前田：早い段階から、藤倉さんは採用のKPIを持っていたんですよね。
藤倉：当時は取り組みを重ねて3ヵ月でようやく1人採用できるような状況だったので、KPIと呼べるものではありませんでしたけどね。僕が採用に関わるようになったのも、たまたまです。
ある時、応募してくれたエンジニアについて当時の上司から「技術はたしかだけれど、カルチャーフィットが心配で。どう思う？」と意見を求められたのがきっかけで。それからも都度意見していたら、だんだん採用に関与することが増えていきました。
前田：そうだったんですね。CTOが採用のOKRを持つことについてはどう考えますか？
藤倉：CTOのミッションによりますが、僕は開発のパワーを最大化することを自分のミッションとして持っています。開発能力を高めるためにヘッドカウントを増やすのは一つの手段ですし、「これは人事の仕事だよ」と切り離すことはできないと考えていました。人事と密に連携しながら、人事のOKRと、エンジニア組織としての採用のOKRを合わせて進めています。
面接は「エンジニアの市場価値が高まるか」で見極める
前田：藤倉さんが採用ラインの見極めにあたって意識しているポイントはありますか。
藤倉：面接って、「人間が人間を評価する」というおこがましさが備わるもので、さらには人生に多少なりとも影響を与えてしまう仕事ですから、真剣にやらないといけませんよね。だからこそ採用時には、会社の卒業後までを見越して、Sansanでエンジニアとしての市場価値にプラスできるか、を心がけています
「この人がSansanを選んで仲間になってくれたら、すごく良い経験をしてもらいたい。もし、将来は卒業することになっても、Sansanの仕事をレジュメに書くと、エンジニアの市場価値が高まるような経験をさせてあげたい」と考えます。そして、僕の責任でその機会が提供できるのならば「合格」を伝えるでしょう。
能力の高低ではなく相性の問題です。Sansanでは市場価値の高まる経験が積めない、その人が望んでいるものでない、と考えれば、僕としては別の道を勧めたい。これが採用の軸といっていいかもしれません。
前田：そんなスタンスを持つ藤倉さんが、オファー面談などの最終局面で、さらに「この人
のキャリアにとってプラスになる」と思えたときに、必ず伝えているメッセージなどはありますか？
藤倉：社内外の事情も含めて、正直なことを言います。
「僕はあなたの人間性を評価しました。正直なことを言うけれど、社内にはこういった課題が今あって、あなたの能力が生かせるはずだし、その問題を解決することにやりがいを覚えて、楽しく取り組めると思います。もし解決できれば、エンジニアとしての経験になるし、レジュメにも堂々と書けるものになる。だから、僕はあなたを求めて、期待をしています」
……といったように伝えますね。どういう点を評価したのか、なぜ合格になったのか、何を期待しているのかといったことが、シャープに伝わってないケースが多いと思いますから。もちろん、技術的な知識や経験も評価しているのですが、それらは1次面接や2次面接で十分に評価されているでしょうから、最終面接では素直に、内面的なことにも言及します。
前田：ここまでのお話を聞いていても、エンジニアの方々とCTOである藤倉さんが信頼関係を結び、大切にしているように感じました。信頼関係を構築するために日々気をつけていることはありますか？
藤倉：信頼関係、とても重要だと思っています。極端に言えば、信頼されていなかったら、自分の仕事を進める上でも説明がたくさん必要になるなど、ややこしくなってしまいます。
前提として、信頼関係とは双方向的なものであり、自分が相手のことを信頼していなければ、相手に自分を信頼してもらえません。ただ、相手に信頼してほしくても、相手の感情を変えるのは難しい。よく言われることですが、それでも自分を変えることなら可能ですから、僕はとにかく無条件で絶対的に信頼するというポリシーで生きています。
Sansanに入ってきてくれるようなすばらしい仲間であれば、「藤倉のことはまだ信頼に至っていない。でも、何だかわからないけれど、藤倉は自分をものすごく信頼してくるぞ」と見えているはずです。信頼されたいのなら、自分から信頼する。それが何より手っ取り早いという考えです。
Sansanに入ってくるメンバーは、仕事はちゃんとやりたくて、自分だって成長したいし、評価も受けたい、という「真面目さ」を備えています。もちろん、真面目にすれば何かがすぐ上手にできるわけでもないけれど、「上手になりたい」とは思ってくれている。
現場のエンジニアには「エンジニアの正義」があるし、やりたいことだってある。それは絶対に間違っていないと僕は考えています。それならば、上手にやれるような訓練の機会を設けるなどして、結果的にメンバーのレベルが上がってくれば、おのずとCTOである僕は余力ができて、次なる課題なりチャンスなりに取りかかっていける。
「人との信頼関係が自分の人生を豊かにする」みたいなウェットな感情はまったくなく、やるべき仕事をちゃんとするための合理的な選択なんです。
Sansanの評価は「ミッショングレード制」を採用
前田：エンジニアの評価についても、うかがいたいです。やや抽象的な問いで恐縮ですが、Sansanはどのような評価制度で運用されているのでしょう？
藤倉：当社も創業以来、いくつかの評価フレームワークを試してきていますが、現在は「ミッショングレード制」を採用しています。要するに「持っている責任に対してグレーディングする」という仕組みです。
以前には、いわゆる「コンピテンシー評価」を使っていた時期もあります。ただ振り返ってみても、やっぱり人の能力は数値化できるわけがないな、と（笑）。一方でミッショングレード制は「役割への期待」ですから、どんな能力を持っていても構わないわけです。どんな手段を使っても、どんな強みを生かしても、役割を果たすことだけに期待します。
人それぞれ得意不得意があります。たとえば、力強いリーダーシップがあってもいいし、支えていくサーバントリーダーシップでもいい。僕らは「ある工数や人数で構成されるプロジェクトを、常にリードし続けられる責任を持ってください」と伝え、個々人がそれを成功に導くために活動する。
エンジニアなら「自分はコーディングが得意だから、重要な部分を率先して書いて背中を見せる」というリーダーシップでもいいし、「自分はピープルマネジメントが得意だから、自分でコードを書くよりも周りを鼓舞していこう」といったリーダーシップでもいい。ただ、プロジェクトを成功させるというミッションだけに向き合えるようになるんです。
前田：コンピテンシー評価から切り替えられたのは、制度が合わないと感じたフェーズが来たからなのか、具体的に何かしらの課題が起きたのか、どういった理由でしたか？
藤倉：課題ドリブンで変えたわけではないですね。全社で給与体系や評価システムを考えたとき、特にセールスやマーケターはミッショングレードのほうがマネジメントしやすいのではないか、と人事から提案があったんです。聞いてみると、エンジニアにも使えそうでした。職種によって評価システムが違うのは運用が大変ですから、揃えたかったんです。
同じスキームで、期待する役割のディスクリプションを変えれば運用できるイメージがわいたので、実際に導入してみたところ、逆戻りすることなく続けているという流れです。
前田：そうなると、ミッションに対する理解と、それに対する納得感が大事になってきそうです。その擦り合わせに時間を割かれているんでしょうか？
藤倉：おっしゃるとおりで、コンピテンシー評価に比べると、ミッショングレード制がやりやすい面はあるけれども、「ミッションのサイズ感」を形式化・定量化することは極めて難しい。特にスペシャリストとしての技術者のグレーディングは困難を伴います。
これがマネジメントのラインなら、わかりやすいんです。「メンバーが何十人いて、ビジネスインパクトがこのくらい出せるであろう部署をきちんと回してほしい。人数規模やメンバー構成を見ながら1年後に作るべき体制を築き、仕事をつつがなく進められるような組織長として結果を出してください」……と、これなら定量化もしやすい。
ただ、僕の考え方としては、スペシャリストとマネジメントであっても、同じグレードにいれば責任の大きさも同じでないとおかしいと思っています。なぜなら、ともに「ミッション」に対するグレーディングだからです。スペシャリストは技術や開発に対して責任を持ち、マネージャーは組織や業務が回ることに責任を持っています。
対象が違うので手段こそ変わりますけれど、ミッションとしてのサイズは同じである、ということはできるだけ伝えるようにしています。たとえば、「50人ぐらいの組織の部長」と同じ責任を持つスペシャリストは、金額感で言えば、「年間売上が数億円から20億円程度あり、予算も付いている規模感のプロジェクト責任者と同等である」と想像しやすいはず。
そういった責任を持ってほしいのです、といった伝え方はよくしますね。
前田：わかりやすい説明ですね。スペシャリストに進むか、マネージャーに進むかは、どれくらいのタイミングで分かれ道を決めてもらうのですか？
藤倉：当社のミッショングレードのフレームは、一番下のグレードがスタッフの「S」で始まり、グレード1から5まであります。「S5」の上がマネージャーの「M」かプロフェッショナルの「P」に分かれ、グレード1から7まであるという、トータル12段階です。
ですから、「S5」になるところが岐路ですね。「S5」は5人ほどで回すプロジェクトのリーダーとして、エンジニアならば中堅として立派に仕事ができ、マネージャーが手取り足取り指導をするよりも、基本的には任せる体制が取れるレベル感です。
前田：評価のフィードバックは、どれくらいのサイクルで回していますか？
藤倉：人事が運用してくれている全社共通のルールでは、年に1回の昇給や給与査定のサイクルがあります。ただ、フィードバックが少ないですから、「中間レビュー」を必ず実施するようにオフィシャルで決まっています。でも、現場感で言うと、半年に1回でも期間が長いようには感じるので、僕らの技術本部では「月に1回、少なくとも3ヵ月に1回」は途中成果の1on1を組みましょう、というガイドを出しています。
あくまでガイドであって、現場とマネージャーの関係性やチームの大きさによってアレンジして構わないのですが、「3ヵ月に1回」のレポート義務は設ける、というサイクルです。
ハイパフォーマーは内部から引き上げたほうが早い
前田：組織の生産性を高めるために藤倉さんが行っているコミュニケーション術があれば教えてください。
藤倉：最適なコミュニケーションは状況により異なるので、具体的な方法よりも「なぜそうするか」を考えます。例えば、退職者が出そうな時や、個々のエンジニアの成長が叶えられていない時、コミュニケーションは有効な手段になるでしょう。
まずは何の目的で、どの観点からコミュニケーションを取るのかを明確にすることが大切です。それさえできれば、あとは適したサイクルやニュアンスを考えればいいんです。
コミュニケーションの重要性は心理的安全性や健やかに働ける環境づくりと紐づけてよく語られます。ただ、組織運営や経営の観点から言えば、ドライな表現になりますが、心理的安全性や健やかに働ける環境はなくてもいいんですよ。エンジニアが開発できて、きちんと成長するステップがあり、人が辞めない状況が作れるなら、あってもなくてもいいんです。もっと言えば、給料がパフォーマンスと見合っていてペイしているなら、エンジニアの成長すらなくて構いません。
でも、組織を強くしていこうと思ったら、ハイパフォーマーが絶対に必要なんですよね。ハイパフォーマーを作るには外から採用するより内部の人員を引き上げ、成長してもらったほうが効率的。そのための成長を作るには、目標へのチャレンジと進捗のフィードバックの繰り返しが欠かせません。そこでコミュニケーションが重要になってきます。
前田：ハイパフォーマーを育成するコミュニケーションについて、詳しく教えてください。
藤倉：エンジニアに成長を期待する時、「設計の能力を上げてください」というオーダーは難しいんですよ。なぜなら、その方法がわかってるならとっくにやっているはずだから。どう努力していいかわからないから行き詰まっているんです。なので、「このケースでこう判断できるようになったらゴールです」と、具体的に目標を伝える必要があります。
僕の場合、半年の中で少なくとも3回は機会を与え、できたかどうか都度フィードバックします。1回でも「よくできた！」と評価できるものがあれば、それは能力が上がった証拠。だから次のレベルを目標にしてチャレンジしましょう、と噛み砕いて伝えています。そうすれば、どう努力すればいいかわからなくなることはなくなるはずです。現場のマネージャーみんなが、こうした丁寧なコミュニケーションができるようになるといいですね。
僕たちの仕事の意義は「判断すること」にある
前田：続いて、マネジメントの権限委譲についてです。それぞれのユニットに権限を委譲していく際、気をつけていることはありますか？
藤倉：気をつけているのは、セーフティーネットを張ってあげることですね。委譲される側からすれば新しいチャレンジなわけで、「自分がやっていたのと同じことを再現してくれ」というオーダーでは難しい。特にマネジメントのような上位の業務ほどオーダーの抽象度が上がり、明確な答えがない中で模索してもらうケースが増えます。そこでは挑戦と失敗を繰り返さないと学べないこともあるので、「失敗しても僕がカバーするから、やってごらん」と言えることが重要だと考えています。
資料を作ってもらう場合は、前倒しで期日を設定して僕がレビューする。「OKだったらそのまま経営会議に上げるし、直すべきところがあればこちらで書き換えます」とあらかじめ伝えておく。当たり前かもしれませんが、そうして心理的安全性を保ちながら手を離していくことを心がけています。
俗に言う「報・連・相」ってキーワード、僕は響きがダサくて嫌いなんです（笑）。でも、確かに重要だし、それでいて難しいことだとも感じます。どんな内容を、どのタイミングで、誰に報告や相談するのか、少なくとも僕はまったく得意じゃないんです。
そういう僕を基準に考えると、報告を逸してしまったとしても、どこかのタイミングで拾ってあげられれば、そのミスは致命傷にはなりません。それが僕なりのセーフティーネットであり、適切な報告内容とタイミングを一緒に作っていければいいと思っています。
たとえば、「報告は2週間に1回の定例会で、このプレゼンのテンプレートを使って、2人で議論しながら、この項目が埋まっていればリスクがなさそうだね」とわかってくれば、報告に対する不安のない状態が作れます。そこまでくれば手放せますよね。
技術系の話で言うと、「設計」はソフトウェア開発で必ず行なう作業ですが、押さえるべきポイントを押さえれば絶対に間違わない、なんていう設計のノウハウは存在しません。常に状況やチーム、創造したい未来によって、使う技術でさえ変わっていってしまうものです。
ただ、設計を失敗すれば将来の開発効率やメンテナンス設定も変わるので、外してほしくはない。それでも時間的な制約があって、僕がすべての設計をするわけにはいかない。そこで時々に、可能な限り言語化して、具体的なルールを設けます。「この範囲を超える設計は必ず僕にレビューを出してほしい。それ以下のものは事後報告で構わない」といったように。
絶対に間違いのない設計のノウハウやパターンはないけれど、意識しなければいけないポイントなら絞れる。それをどういったエビデンスで判断したのかを言語化していけば、レビューもどんどん短くできます。最初は1回の設計レビューで1時間も2時間もかけてきたものが、最終的には30分で収まったり、さらには10分で済んだり。
そこまでいけば「基準をもう少し上げるから、この範囲内においては自分で判断していいよ」と言える。これもある種の権限委譲かもしれないですね。
前田：ここでもコミュニケーションが重要になっていますね。では、エンジニア組織の「評価」で注意すべき点を教えてください。
藤倉：エンジニアに限らずどんな職種もそうですが、評価は育成と表裏一体。評価することは、より大きな影響を与えられるようになってほしいと会社が期待することだからです。開発者なら、より大きく難易度の高いプロダクトが作れるようになったり、複雑な意思決定ができるようになったりしてほしいという期待があるから評価するわけですよね。
なぜ自分が評価されているのか、されていないのかわからない状況は避けるべきです。グレーディングで評価するのであれば、何ができればこのグレードであるときちんとマッピングし、階段を明確にしましょう。そして、やはりメンバーと目標をきちんと共有して、途中経過をなるべく細かくフィードバックすることが重要です。
前田：最後に、エンジニアが顧客目線で考えることがなぜ重要なのか教えてください。また、そのために藤倉さんが工夫していることはありますか？
藤倉：顧客目線はもちろん、事業目線、ビジネス目線で考えることが重要です。なぜかというと、そうでなければ意思決定なんかできるわけがないからです。
期待された作業をできるだけ正確にスピーディーにやっていく仕事とは違い、僕たちの仕事の意義は「判断する」ことにあります。不確実な未来のことを、事業としての制約や条件、期待値が絡まった複雑なパラメータを参照しながら判断するからこそ、多くのサラリーがもらえるんです。
ビジネスの状況がわかっていなければ、難しい意思決定を正しくこなすことはできません。顧客目線を持つことは、エンジニアとしてちゃんと仕事をするということ。ただそれだけのことだと考えています。
