ログラスに会う。千田浩輝の仕事場 〜AI時代はスピードが命。少数精鋭で挑む開発プロセスの現実解〜
「ログラスに会う。わたしの仕事場」は、カジュアル面談や選考の前に、「この人がどんな仕事を、どんな考えで担っているのか」を知るためのシリーズです。
求人票だけでは見えない、仕事の思想や役割の期待値、日々の判断の難しさ。それを先に知ることで、面談が"見極めの場"ではなく"相互理解の場"になることを目指しています。
今回は、ログラスのプロダクト開発をリードする千田 浩輝さんに話を聞きました。
AI時代のプロダクト開発では、良いものを時間をかけて丁寧につくるだけではなく、変化する前提のなかで、いかに速く仮説を置き、動き、学び、つくり直せるかが重要になります。
一方で、ただ速ければよいわけでもありません。少人数で高い成果を出すためには、チームの意思決定、開発プロセス、AIエージェントの使い方、そして「どこまでルール化し、どこから現場に委ねるのか」という設計が問われます。
千田さんが向き合っているのは、まさにその現実解です。
この記事では、ログラスの開発現場で実際に試行錯誤されている、AI時代のプロダクト開発プロセスについて聞いていきます。
千田 浩輝（ちだ ひろき）プロダクト開発責任者 / Loglass AI IR
エンジニア経験10年。現在は「Loglass AI IR」のプロダクト開発責任者を担当。自らもコードを書くプレイングマネージャーとして、現在7名（エンジニア5名、PdM1名、デザイナー1名）の少数精鋭チームで、AIを活用した新規事業のプロダクト開発全体を牽引している。
最小限のルールで、爆速で動く──プロダクト開発責任者として今やっていること
── 今、チームの中でどのような役割を担っていますか？
千田：「Loglass AI IR」という新規事業における、プロダクト開発責任者をしています。ただ、責任者とは言っても、マネジメント席にどっしり座っているわけではなくて、私自身もバリバリにコードを書き続けているプレイングマネージャーです。
チームは私を含めて7名（エンジニア5名、PdM1名、デザイナー1名）の非常にコンパクトな布陣にしています。というのも、AIの登場によって新規事業はこれまで以上に「スピードが命」になったと肌で感じているからです。世の中の変化の速さは凄まじく、新規事業においてチームを大きくしすぎるとコミュニケーションコストが跳ね上がって致命傷になります。だからこそリソースは無理に増やさず、最小限の人数で回すようにしています。
なお、Loglass AI IRがどのような市場課題に向き合い、どのように「正解のない市場」を定義しようとしているのかについては、新規事業責任者・盛川のインタビューでも紹介しています。開発プロセスの背景にある事業側の思想を知りたい方は、ぜひあわせてご覧ください。
── ルールやプロセスも、かなり絞り込んでいる組織なのでしょうか。
千田：そうですね。スピードを最大化するために、ルールはなるべく最小限にする、というコンセプトにしています。新メンバーのオンボーディングが少し難しくなったり、判断基準がブレやすくなったりするデメリットは当然ありますが、それ以上に「全員が全体像を把握できること」「意思決定が速いこと」「オーナーシップが高まること」というメリットの方が、今の時代には絶対に求められる。
この圧倒的なスピード感の中で、技術とビジネスをダイレクトに結びつけながら、全員がプレイヤーとして自律的に動くチームを目指しています。
全体アジャイル×局所ウォーターフォール。不確実性を乗りこなす開発プロセス
── AI時代において、その「命であるスピード」を担保するために、どのような開発プロセスを組んでいるのですか？
千田：「全体はアジャイル、各開発単位（エピック）はウォーターフォール的に動く」という、両手法のエッセンスを融合させたハイブリッド型のスタイルにチャレンジしています。
プロジェクトマネジメントの三角形において「納期・リソース・スコープ」の3つはトレードオフの関係にあります。スコープを固定するウォーターフォール的な考え方か、納期とリソースを固定するアジャイル的な考え方か、基本的にはどちらかの考え方をベースに選択していくケースが多いのかなと思います。
私たちは、ロードマップ全体では納期とリソースを固定し、優先度を見ながら入りきらない開発単位を落とすことで、アジャイルに、柔軟かつ最速で進めます。
一方で、一度切り出した個別の開発単位、つまりエピックの中では、スコープをある程度固定し、必要なリソースを集中投下してやり切る、ウォーターフォール的な進め方を試しています。
── なぜエピック単位では、そうしたウォーターフォール的な進め方が可能になるのでしょうか？
千田：大きな理由は、AIを開発に組み込むことで、設定した納期に向けてきっちり価値を届け切れる可能性が劇的に高まっているからです。
プロダクト開発における不確実性には、「何を作るか（What）」と、「どう作るか（How）」の2つがあります。現在はAIのサポートによって仕様整理や実装のスピードが圧倒的に上がったことで、Howの不確実性をかなりコントロールできるようになっています。
ただし、どれだけAIが進化しても、対象となるスコープが巨大なままでは固定してもブレるだけですし、狙った通りの納期には着地できません。ですから私たちは、PdMやデザイナーと連携して本当にミニマムな形になっているか徹底的に問い直し、スコープを極限まで削ぎ落として固定するというプロセスを踏んでいます。
「極限まで削って固定したミニマムなスコープ」と「AIによる実装の高速化」が掛け合わさるからこそ、納期を守る難易度が下がり、エピック単位では『ブレずに納期通りにやり切る』という確実性の高いコミットが可能になりました。
もちろん、エンジニアリングの現場において「納期」という言葉を聞くとうっと来る部分もありますが、これは誰かに上から押し付けられるものではなく、開発者自身が「これならタイムライン通りに着地できる」と納得して決めるものです。
プロダクト開発は短距離走ではなく長距離走なので、メンバーが疲弊している状態は絶対にダメなんです。終わった時にしっかり達成感があるかどうかが大切。スコープの適切なコントロールによって、スピードを殺さずに確実性を担保するアプローチとして、このバランスを探る進め方は、直近の波はありつつも、私たちのチームにおいて「今のところ非常にうまく機能している」という確かな手応えを感じています。
ワークフローとエージェントの使い分け。AIをどうプロダクトに組み込んでいくか
── 千田さんは直近、「AIを実際のプロダクトにどう組み込んでいけるのか」という実装イメージの具体化にかなり時間を投資されたそうですね。
千田：そうですね。単なる理想論ではなく、実務で使えるプロダクトに落とし込むための設計思想を徹底的に整理していました。そこで見えてきた一番の核は、プロダクトにおける「非決定論的（エージェント）」な領域と「決定論的（ワークフロー）」な領域をどう切り分け、組み合わせていくかという点です。
AI開発の現場では何でも「エージェント」と一括りにされがちですが、プロダクトとしての信頼性を担保するにはそのグラデーションを使い分ける必要があります。
あらかじめ定義されたコードパスに従って動くシステムが「ワークフロー（決定論的）」であり、予測可能性と一貫性が高いため定型タスクに向いています。一方で、次にどのツールを使うかをLLM自身が動的に決定するシステムが「エージェント（非決定論的）」であり、柔軟に複雑な探索課題を解くことができます。
── その2つをプロダクト内でどう共存させるべきだと考えていますか？
千田：すべてをAIに丸投げするような完全自動化の形は、現時点では現実的ではありません。AIの強みである「非決定論的」な探索プロセスはプロダクト内で大胆に活かしつつも、システムとして「1+1が絶対に2になる」ことを担保すべき「決定論的」な部分の制御に関しては、極めて慎重に組み込む必要があります。
予測可能性が必要な定型業務は「守り」のワークフローで固め、柔軟な判断が求められる探索業務に「攻め」のエージェントの力を借りる。このグラデーション（エージェンティックワークフロー）を使い分ける設計思想こそが、プロダクトの信頼性を生むと考えています。
そして、この境界線をどの粒度で切り出してプロダクトに落とし込むかを見極めるためには、何よりも「顧客の業務（ドメイン知識）」への深い理解が不可欠です。技術が進歩すればするほど、このドメイン知識こそが、エンジニアやPdMにとっても最大の差別化要因になると確信しています。
固定観念にとらわれない。AI時代、SWEとPdMに求められる役割の変容
── この技術的な組み込み思想の変化は、現場のエンジニアやPdMの役割にどう影響してくるでしょうか。
千田：今後、エンジニアの仕事は「仕様を実装する（＝コーディングする）」部分はかなり薄くなり、仕様を整理してプロンプトとして与える部分がより重要になっていきます。
そうなった時、エンジニアやPdM、デザイナーといった職種の境界線はもっと柔軟に混ざり合っていくと考えています。エンジニアは実装の自動化によって生まれた余裕を活かして、プロダクトの要件定義や技術的要件、プロジェクトの推進といった、より上位の役割へと染み出していく。PdMやデザイナーも、AIの非決定論的な挙動をどうコントロールしてプロダクトに落とし込むかという、よりテクニカルな領域に踏み込んでいく必要がある。
固定観念にとらわれず、時代や組織のフェーズに合わせて役割も柔軟に変えていきたい部分ですね。
カジュアル面談では、「正解のない問い」をフラットに議論したい
── 千田さんがカジュアル面談で話したいことは何ですか？
千田：スキルや経歴の確認というよりは、お互いのモノづくりに対する思想をすり合わせる「相互理解の場」にしたいですね。
それこそ、今日お話ししたようなテーマについて、フラットに意見交換ができたら最高です。
AI時代において、打率と「スピード」を極限まで両立させる開発プロセスのあり方
AIプロダクトにおける、ワークフロー（決定論）とエージェント（非決定論）のグラデーションの切り出し方
技術が進化する時代だからこそ、エンジニアやPdMはどうやってドメイン知識（IR実務）をキャッチアップしていくか？
綺麗事だけではない、いま私たちがリアルにコードを書きながら試行錯誤している現在地をそのままお伝えしますので、「自分ならこうする」というアイデアや知見をぜひぶつけ合いたいです。
── 最後に、どんな人と一緒に働きたいですか？
千田：ルールや前例に縛られず、変化を楽しめる人ですね。
チームに掲げる「目標」も、私たちは単に評価のためだけのガチガチな道具ではなく、「大胆に挑戦するためのコミュニケーションツール」だと捉えています。十分に大胆なストレッチ目標であり、事業の成長につながる道筋であれば、その具体的なゴールやアプローチは自分たちの意志で柔軟に決めていいと考えています。
エンジニアであれば、技術の選択が事業の成長にどう繋がるかを考えられる人。PdMやデザイナーであれば、AIが動くプロダクトにおいて、ユーザーの業務にどう価値を先回りして届けるかを一緒に設計できる人。そんな風に、不確実性の波すらも楽しみながら、少数精鋭のチームで自律的に動ける人と一緒に、AI時代の新しいプロダクト開発の形を作っていけたら嬉しいです。
編集後記
千田さんのお話を聞いていて一貫して流れていたのは、「AI時代はスピードが命」という強い危機感と、それを楽しむワクワク感でした。
最小限のルールで回す少数精鋭のチーム体制も、スコープを極限まで削ぎ落としつつAIの恩恵を活かして納期通りに着地させるハイブリッドな開発プロセスも、すべてはそのスピードと確実性を最大化するための必然の選択。
固定観念にとらわれず、AIをどうプロダクトに組み込むかを見極めるロジックの根底には、「顧客のドメイン知識を深く知る」というものづくりへの強いリスペクトがありました。
エンジニアやPdMの枠を超えて、激変するAI時代の最前線で爆速のモノづくりに挑みたい方、ぜひ千田さんの仕事場を覗きに行ってみてください！
