「シニアエンジニアとして技術で事業に貢献する方法」全部振り返る

私は現在、Tebiki株式会社でソフトウェアエンジニア（以下、SWE）として働いています。肩書は「プリンシパル」となっています。Tebikiのプリンシパルは、マネジメントとスペシャリストの2つに分かれており、私はスペシャリストです。スペシャリストは、レポートラインにいわゆる部下を持ちません。その役割は、一般的にはスタッフエンジニアと呼ばれるポジションに近いと考えています。

前回の記事では、私のキャリアに対する考え方を中心に、これまでのキャリア選択について書かせていただきました。今回の記事では、Tebikiのスタッフエンジニアとして現在重視している考えや、事業に技術で貢献することについて書きたいと思います。

• keyboard_arrow_down 事に向かうこと
• keyboard_arrow_down 「ビジョン」「戦略」「仮説検証」。創業者に代わり技術的な意思決定を担うための考え方
• keyboard_arrow_down 手段の前に課題にフォーカス。方向性が決まったらあとはリスクを減らすだけ
• keyboard_arrow_down プロジェクトの不確実性をコントロールし、技術で事業貢献する
• keyboard_arrow_down 不要なプライドのせいで傷つく前に。現実を受け入れ、メンタルを維持する秘訣
• keyboard_arrow_down 次回予告

私がスタッフエンジニアとして働くうえで、最も重視している考えは「事に向かうこと」です。

ここでフォーカスしている「事」とは「重要な事」を指しています。今自分にしか出来ない最も重要だと思うことを指しています。逆に言えば、それ以外のことには向かうことなかれという考えです。

Tebikiのスタッフエンジニアは、創業者や他の社員から具体的な仕事が与えられることはほとんどありません。そもそも、スタッフエンジニアに限らず、なぜ組織にテックリード、エンジニアリングマネージャーといったロールが必要になるのかというと、事業と組織の拡大に応じて、創業者が複数のロールを兼任できなくなるためです。スタッフエンジニアの場合、「組織運営における技術的に重要な事」を考える役割を、創業者から移譲されることになります。自分以外には、技術的に重要な事を考える機能が組織に存在しないので、自ら「重要な事」を導き出す必要があります。

一言に導き出すと言っても、具体的にどのようにするのでしょうか。

私の考えでは、まずは次の3点を自分にインストールすることです。

・プロダクトビジョン
・事業戦略
・現状認識

全ての礎となっているのはプロダクトビジョンです。プロダクトビジョンとは、壮大な仮説であり、程よく実現可能性を帯び、顧客が儲かる仕組みを含んでいるものだと考えています。組織が多くの人を巻き込み、そのリソースを活かしていくためには、組織が実現したい世界に対する人々の共感が必要です。Tebikiにおいては、「現場の未来を切り拓く」というミッションを、どのように実現するのか表したものがプロダクトビジョンです。組織のミッションも重要ですが、どのような構想で実現しようとしているか、私はそのロジックに共感できるかどうかが大切だと考えています。

事業戦略は、プロダクトビジョンの実現に向けた短期のロードマップです。事業戦略が、プロダクトビジョンに沿っているかどうかは非常に重要です。一方で、数字によって評価される都合上、具体的な手段がフォーカスされやすい特徴があると考えており、いち従業員の目線からは、事業戦略とプロダクトビジョンの繋がりを見いだせないことがあると感じています。そのため、なぜこの戦略が重要であるのか、プロダクトビジョンに対する整合性を担保しておくことには、非常に価値があると感じています。

私の場合、プロダクトビジョンと事業戦略は、定期的に発信されるCEOの社内報や、CTOとの1on1でインストールしています。

最後に現状認識についてです。現状認識とは、仮説検証を繰り返して物事の構造を理解する行為です。スタッフエンジニアとしてより良いエンジニアリングの意思決定を行うためには、この「現状認識」を通じ、技術課題だけではなく、組織課題も把握することが重要になります。なぜなら、コンウェイの法則が示唆するように、ソフトウェア設計と組織設計は表裏一体であり、組織構成がそのままソフトウェアの構成に反映されてしまいがちだからです。

とはいえ、限られたアセットで、組織構成を柔軟に変化させることが難しい場合も多くあります。そのため、ソフトウェア設計は、将来の組織設計を前提に行うことが重要であると考えています。ソフトウェア設計と組織設計は、いずれもプロダクトビジョンを前提にしたものとなります。私がよく今後のプロダクトビジョンや組織設計を問うのは、全てより良いエンジニアリングの意思決定を行いたいという思いに起因しています。

これら3つの観点から、フォーカスすべき「テーマ」、言い換えるとスタッフエンジニアとして仮説検証すべき施策の方向性を選定するにあたっては、課題が具体的であるかどうかが重要だと考えています。

陥りがちなのは、課題が具体的になる前に手段にフォーカスしてしまう状態です。例えば、ここ最近システム障害が多いため、SLOを設定することで開発優先度の参考にしたい、というアイデアがあったとします。少し油断すると手段が目的化し 、SLOを運用するためにはどのように進めればよいかを最初に検討しがちです。しかし、その時点ではシステム障害の多さが、事業や組織に対して、具体的にどのような影響を与えているのか明確でないことがあります。先に何が問題であるかを明確にしないと、他に良い解決策があったとしても気付けなくなってしまいます。

テーマを選定したら、各開発メンバーに方針をアウトプットし、レビューを募ります。このフェーズで重視していることは、誰かにGoをもらうことではなく、リスクを減らすことです。Goは自分で判断します。また、決定した事項に対しては、セルフィッシュであることも重視しています。ここまで来ると、よほどの事が無い限り、やり切ることが重要だと考えています。

とはいえ、現在、Tebikiのスタッフエンジニアは、プロダクトエンジニアとしての顔がメインです。プロダクトを開発することがまず重要です。私も1日の時間の大半をプロダクト開発に費やしています。一口にスタッフエンジニアと言っても、私のように少し俯瞰的に活動する者もいれば、プロダクトに深く根ざす者もいます。これは各スタッフエンジニアの特性によります。特に示し合わせてはいませんが、「事に向かうこと」という価値観は互いに持っていると思います。

プロダクトビジョンを実現する過程においては、思い通りに行かないことがたくさん起こります。開発チームは、新機能追加、顧客要望、競合との星取表、システム障害など多くの不確実要素を抱えながら、プロダクトビジョンの実現に向けて開発、そして価値を生みだす難題を突き付けられます。開発チームは、限られた時間の中でこれらをどのようにコントロールできるでしょうか？

私の結論はシンプルです。それは、開発計画を立てることと、常日頃から納期を長めに取ることです。

困難な状況でも開発計画を立てる

実は、八方塞がりに見える状況においても、開発計画を立てることで開発チームのリソースを必要な箇所に集中でき、物事の優先度をコントロールしやすくなる場合があります。

例えば、今後の開発計画を立てることで、「顧客向けに具体的なプレゼンを作成したい」というセールスチームの要望に応えることができます。顧客に対しては、具体的な計画を約束をするのが難しいことが多いですが、日々小さな機能や改善のリリースを続けることや、開発途中の機能についてのデザインモックを見せることで、多少なりとも期待値をコントロールすることが出来る場合があります。

そんなこと当たり前じゃないかと思われるかもしれません。しかし、事業のフェーズによっては、フォーカスする領域が短期間で移り変わることはよくあり、常に開発計画が有効な状態を維持することは、思っている以上に難しいものです。

納期は思っている2,3倍以上確保する

次に、納期は長めに取ります。経験的には、少なくとも思っている2〜3倍以上が望ましいです。ソフトウェア開発の現場は、予測不可能な問題が発生しがちです。それに対処する最も簡単な方法が、納期を多く取ることだと考えています。なんだそんなことかと思われるかもしれませんね。しかし、以下の理由から私は重要であると考えます。

計画を守ることは、チーム間の信頼関係にも寄与します。セールスチームを含むプロダクトチーム全体は、開発チームの納期を中心に事業オペレーションを回しています。納期のずれ込みは、事業オペレーション全体のずれ込みとなり高く付きます。もちろん、組織やプロダクトのフェーズによるところはありますが、一見多めに見える納期でも、プロダクトに関わる人が多ければ多いほど、計画がずれ込まないことの方が結果的には良い印象です。

「動くものをつくる」を最優先に

当たり前ですが、開発チームは、長めに取った納期を前提とした計画をすると本末転倒です。そのため、真っ先に動くものをつくることが重要になります。納期を20〜30%消化したあたりでまだ動くものがつくれていなければ、個人的には赤信号です。事業オペレーション全体への影響を考え、そのタイミングで納期をさらに伸ばすかどうか、早めに検討するのが良いと思います。

最初は理想ベースでUXを設計をします。顧客課題を具体的なソリューションへ導く最も重要なフェーズです。ここで設計したプロダクト以上のものをつくることは難しいと考え、時間を決めて煮詰めていきます。エンジニアリングの観点は敢えてあまり持ち込まず、UXデザイナーには、制限は無しと伝えて、最高の顧客体験を一緒に設計するのが良いと考えています。というのも、担当するエンジニアが論理的に理解できる機能は、そのほとんどを実現することが可能だからです。その後、リリースする時期に合わせて機能を削り、可能なら少しずつリリースします。

ソフトウェア設計についても、理想ベースで設計することを重視します。DesignDoc に落とし込む際に、初めて既存システムとの整合性について検討します。ここからは文字通り、動くものをまっすぐつくります。既存のコードベースへの変更が必要になる場合は、必要に応じてリファクタリングします。リファクタリングもまっすぐつくることに含まれます。ただし、想定より多くの時間が掛かりそうならいったん諦め、動くものをつくることを優先します。

不測の例外に備え、トップダウンの意思決定を引き出せる関係性をつくっておく

一方で、どれだけ気をつけていても、事業成長の過程において、システムのリプレースといった大規模な改修を必要とするタイミングが来るかもしれません。開発を止め、開発チーム全体でソフトウェアの品質向上のための期間を取ることは、事業オペレーション全体に影響します。結果的に、ステークホルダーに対する説明責任が発生し、コミュニケーションコストが高いため避けるべきと考えます。

個人的には、納期をしっかり取り、個々のエンジニアが日々プロフェッショナルな仕事を遂行できるようにする方が良いという考えです。大規模改修を専任で担うチームを確保できる場合はそれが良いと思います。それができず開発を止めなければいけない場合は、トップダウンの意思決定を引き出す必要があります。なぜならこれを経営判断なしに進行することは難しいはずだからです。これらがすんなり受け入れられてしまうのはむしろ心配です。反発を受けるほうが健全な状態と言えると思います。

ところで、スタッフエンジニアの立場で、どのようにトップダウンの意思決定を引き出せるのでしょうか。答えはありません。定量的であれ定性的であれ、100人の経営者がいれば100通りの攻略法がある気がします。少なくとも、信頼関係、日頃から何気ないコミュニケーションが取れていることは重要だと思います。

これらが、事業に技術で貢献することだという考えです。つまり、事業オペレーション全体を意識した技術的な意思決定を、理想ベースで進行することだと考えています。

スタッフエンジニアに限らず、組織のリーダーは、その所作が組織に大きく影響を与えます。ここでは、スタッフエンジニアにとって理想的な所作をやってのけるためには、メンタルが安定していることが絶対条件となります。そこで、私の個人的な、メンタルを維持する秘訣を紹介します。

真新しいものは何も無いですが、これが基本の考えです。説明の必要は無いと思います。プライベートの問題は、早急に片付けることが難しいことが多いかもしれません。ですが、自分の中で気持ちに折り合いをつけられるようにならないと、強いメンタルを維持することは難しいと思います。
一方で、そういった状況において、本当に仕事を重視すべきかは要検討ですね。実態としては、24時間、あるいは1週間をどのように分割するかです。

それらに加えて、以下があります。

もし他人と比べて凹んでしまうようなことがあれば、比べない方が良いかもしれません。凹むために比べているようなものです。凹むことをモチベーションに繋げられる人もいるため、誰にでも当てはまるわけではないです。ただ、結局どれだけ比べても、突き詰めてみると、今出来ることをやるだけです。チャンスがあればチャレンジもしてみましょう。実は「メンタルを維持する秘訣1」をしっかりやると、なんか出来ると思えることが増えます。

最後は、失敗を恐れないことです。失敗をしない人はいません。失敗が少ない人と、失敗が多い人がいます。ほらまた比べて。冗談はさておき、失敗は、行動に対する確率的な副作用だと考えます。なので、行動をすれば失敗が発生します。失敗をしないように気をつけるということは、行動を制限することにほかならず、それで良いのかどうかは考える必要があります。絶対に失敗してはいけない領域があることは確かです。その場合、できるだけ行動を制限することが重要であり、失敗を恐れないといけません。

改善が可能な、失敗を恐れることの背景の1つに、他人からよく見られたい、無能だと思われたくないという意識があります。その頭で失敗すると、これがメンタルに突き刺ささることがあります。何か良からぬプライドが育ってしまっていると気づくチャンスかもしれません。プライドの高いリーダーほど近寄りがたい存在も無いですからね。素直に現実を受け入れたいものです。これに対して、私は物事を言い切る習慣を実践しています。発言するときは、かもしれないという含みを残さず、こうですと言い切ります。そうすると、間違ったときに受け入れるしかありません。かもしれないという含みを残すと、間違ったときに、脳が「自分は間違ってはいない」という認識になっているような気がして、それを矯正したいという発想から生まれた実践です。

以上、メンタルを維持する秘訣でした。

次回は、スタッフエンジニアは組織でどのように評価されているのか、という問いに対する私の考え、そして現在抱える悩みについてお話しできればと思います。