Algomatic Tech Blog

Algomaticの開発チームによる Tech Blog です

開発速度よりも大事なものを見つけた話

こんにちは、シゴラクAIカンパニーCTOの菊池 (@_pochi) です。

この記事は、Algomatic アドベントカレンダー2024の15日目の記事です。

algomatic.jp

シゴラクAIカンパニーでは、「シゴラクAI」という法人向け生成AI活用プラットフォームの開発運用に加えて、新たな事業領域でのチャレンジを進めています。 新規事業立ち上げという、最大限に不確実性が大きい事業フェーズ において、エンジニアリングによって事業価値向上に最大限寄与するにはどうしたらいいか?を試行錯誤してきました。

本記事では、そんな試行錯誤の過程である、現在のシゴラクAIカンパニーの開発スタイルについてご紹介できればと思っております。

「開発速度」より「変化への即応性」を重視しています

開発速度は非常に大事ですよね。ソフトウェアによって課題を解決する事業運営において、ソフトウェアエンジニアの開発速度は事業優位性に直結します。わたしも、わたし自身やチームの開発速度を最大限に高めるため、過去にさまざまな創意工夫をしてきました。とりわけ、ソフトウェアエンジニアが高い集中状態(いわゆる「ゾーン」というやつです)に入れた時の開発速度の違いは存外に大きいです。そんなゾーンに入れる時間を最大化することもCTOやエンジニアリングマネージャーの大事な役割です。

しかし、現在のシゴラクAIカンパニーのプロダクトチームでは「開発速度」は重要なテーマと捉えていません。その代わりに、「変化への即応性」を重要視しています。

「変化への即応性」とは

事業開発の初期フェーズにおいては、重要イシューが1日ごと、あるいは1日に何度も変化することは珍しくありません。(むしろ、変化しない状況の方が危険ですらあります。)

そんな状況なので、プロダクトチームにて1週間分のプランニングした直後に計画を全面撤回することもありました。

「もうちょっとうまくやれないの?」 と思われるかもしれませんが、「変化こそ正義」な環境では、事前に1週間先を予見することはそもそも難しいです。また変化が発生した時に、プロダクトチームのリズムを崩さないために「次回のスプリントから対応する」というアプローチは現実的ではありません。1日1日の重みが非常に大きいので、優先度の下がった課題に時間を使う余裕がありません。

さて、そんな朝令暮改をする際、チームやタスクをマネジメントする立場として理想的には以下のようなプロセスを踏むべきかもしれません。

  1. 状況が変化する
  2. 状況に応じてバックログの優先順位を変更する
  3. 変更の背景をドキュメント化する
  4. ドキュメントの内容をチームに展開して再プランニングする

それなりに手間はかかりますが、大前提として「納得感」は非常に大事です。組織が芯を持たずに右往左往する、あるいはそう見えてしまっている状況は、メンバーとしては非常に不安で居心地が悪いものですし、パフォーマンス低下の原因になりかねません。また、何よりも、メンバーと正しく事業状況や意思決定の背景を同期することは、成果物の品質にも直結するため非常に重要です。

しかし、そうはいっても毎回こんな手順を踏んでいては時間がかかりすぎてしまいますので、わたしたちは以下のアプローチで朝令暮改します。

  1. 状況が変化する
  2. 「やっぱりこっち先にやろう!(口頭)」
  3. 着手

え、それ大丈夫なの?

大丈夫じゃないかもしれません。どう考えても乱暴なチーム運営で、リスクがないわけではありません。ただし、これが最速です。

最速の朝令暮改を実現でき、かつ、チームへのネガティブな影響を減らし、意思決定の背景や事業状況を効率的に同期するにはどうしたらいいでしょうか。

正解はわかりませんが、今わたしたちが大事にしている取り組みを3つご紹介します。

  1. メンバーそれぞれが一次情報に浸かる
  2. オンサイトのコミュニケーションによる信頼関係の構築
  3. 感情のボラティリティを共有する

1. メンバーそれぞれが一次情報に浸かる

わたしたちは、プロダクトチームも含め、顧客との商談やCSミーティングの大部分をメンバー全員が聴講します。

商談における顧客の表情や言葉から得られる情報量は膨大で、何が求められているか、なぜ求められているのかの理解が格段に深まります。一次情報を 常に 得ることで、状況変化の発生時に説明不要で理解し、即座に対応できるようになります。これにより、顧客商談後に行われる「やっぱりこっちにしよう」という意思決定における説明は少なく済みます。

2. オンサイトのコミュニケーションによる信頼関係の構築

そもそも、フル出社 or フルリモートは難しい問題ですが、いまのわたしたちは出社によるコミュニケーションを重要と考えています。

もちろん、工夫によってフルリモートでも同様の関係構築は可能だとは思いますが、それも一朝一夕ではいきません。「リモートでもうまくやるための試行錯誤」よりも「顧客への価値提供」に充てる時間を優先するため、今のフェーズでは「全員出社」という選択をしています。

3. 感情のボラティリティを共有する

「売り上げが全てを癒す」とよく言われますが、私たちは売上以外の 小さな成果も全力で祝います 。問題が発生した時はみんなで重く受け止め、改善に努めます。これはシゴラクAIカンパニーだけでなく、Algomaticのカルチャーでもあります。喜びも悲しみも悔しさも共有することで、チームの結束力が高まり、次の成功への原動力となります。

ほしいのは「開発生産性」

前述したような取り組みをしていると、必然的に開発速度は落ちます。プロダクトチームも顧客商談ミーティングに参加するわけで、そのタイミングで開発に向けていた集中は途切れ、再び集中するには多少の時間が必要です。

「開発速度」は落ちますが、「開発生産性」は向上します。朝令暮改のタイミングで細かく説明をする/うける時間も短くてすみますし、日常的なコンテキスト同期によって「不要なものを作ってしまう」リスクが格段に低減するからです。アウトプットの数は減るかもしれませんが、質が格段に上がります。

シゴラクAIカンパニーではこのようなスタイルで開発を進めています。一言でまとめるなら、「泥臭くやっていく」スタイルです。

今後はどうなっていくだろうか

現在の「変化への即応性」重視のアプローチは、現在のわたしたちの事業内容、そして事業フェーズにおいて最適だと判断し採用しています。しかし、事業や組織が成長し、解くべき課題領域が変化し拡大した後であっても同じスタイルが適切かどうかは分かりません。

重要なのは、状況の変化に応じて柔軟に対応できる「変化への即応性」そのものをチームで維持することです。今後も、この姿勢を大切にしながら、最適な開発スタイルを模索し続けていきます。

最後に

長々と書きましたが、つまるところわたしたちは、 限りなく泥臭く、顧客への価値提供と事業成長の実現 に邁進しています。 最先端テクノロジーと泥臭さの掛け合わせ という矛盾を楽しめる人にとって、これ以上面白いことはないフェーズだと思います。

わたしたちが取り組んでいる「未来に面白い仕事を残す」チャレンジにご興味お持ちいただけましたら、菊池 (@_pochi) までお声がけください!よろしくお願いします!

jobs.algomatic.jp