この記事でわかること
-
ヒューマンエラーをシステムの問題と捉える、プロダクトと組織の設計手法
-
現場の経験を仕組みに変える「脱・属人化」のマネジメント
-
生成AI時代に「作るだけ」から脱却する、次世代エンジニアの生存戦略
生成AIや新たなツールの登場により、エンジニアを取り巻く環境はかつてないスピードで変化しています。技術の陳腐化や役割の変化に不安を覚える若手エンジニアも少なくないでしょう。
検索型AI-FAQシステム「Helpfeel」などを展開し、ARR（年間経常収益）10倍という急速な成長を牽引してきた株式会社HelpfeelのCTO・秋山 博紀氏は、HCI（人間とコンピュータの相互作用）研究という独自のバックグラウンドを経営や組織マネジメントの武器へと変えてきました。
本記事では、秋山氏へのインタビューを通じて、技術選定の土台となる思考法から、現場の泥臭い経験を仕組み化するマネジメント術、そしてAIエージェント時代を生き抜くためのハッカーマインドまで、実践的かつ本質的なキャリアのヒントをお届けします。
秋山 博紀
株式会社Helpfeel 執行役員 CTO
11歳からソフトウェア作家として活動し、2005年経済産業大臣賞を受賞。2008年未踏ソフトウェア創造事業採択。慶應義塾大学大学院でユーザーインタフェース研究を行い、2015年にHelpfeelにジョイン。VP of Engineeringを経て2022年よりCTOとして活躍中。
【X（旧Twitter）】：https://x.com/akiroom
株式会社Helpfeel
2007年創業。FAQシステム「Helpfeel」、スクリーンショット共有ツール「Gyazo」、情報整理プラットフォーム「Cosense（旧Scrapbox）」を展開。独自の検索技術とユーザビリティを強みとする。
【HP】：https://corp.helpfeel.com/
目次
HCI研究から始まった、プロダクトと組織を俯瞰する視点
秋山さんは慶應義塾大学大学院（SFC）で「認知・意味編成モデルと身体スキル」という、工学と人間科学を横断する非常にユニークな学際領域を研究されていました。エンジニアとしてのキャリアを考える上で、このHCI（人間とコンピュータの相互作用）の知見は、現在の業務にどのように活きているのでしょうか？
学問的な理論をそのまま実務のコードや設計に当てはめることは少ないですが、ベースとなる価値観や考え方はかなり活きている感覚があります。例えばシステムで何かしらの問題やインシデントが起きたとき、「ヒューマンエラーではなく、システム側に問題がある」と考える視点ですね。
例えば、ユーザーが誤操作をしてしまったのは、ユーザーの不注意ではなく、そもそも「ミスを誘発するような設計」を放置していたシステム側のせいだと捉えるわけです。
なるほど。ユーザーに責任を求めるのではなく、システムやUIの設計に改善の余地があると考えるのですね。それはプロダクト開発において非常に健全で、ユーザーに寄り添ったアプローチだと感じます。その他にも、学生時代に影響を受けた考え方はありますか？
当時はGUI（グラフィカルユーザーインターフェース）の画面操作から、さらに一歩進んで「ユーザーインターフェース自体を透明にしていく」というトレンドもありました。つまり、「画面を操作しなくても便利に目的が達成できるなら、それが一番いい」という発想です。こうした学問領域で触れた考え方が、今の私たちのプロダクトへの意識に向いている部分は非常に大きいと思います。
操作自体をなくしてしまうという発想は、究極のユーザビリティですね。学生時代からそうした人間中心の視点をお持ちだったのは驚きですが、大学の授業は現在のキャリアや実務に直結するものを選んで履修されていたのですか？
実は、将来の仕事に活かすというより、純粋に興味の赴くままに授業を取っていました。プログラミングについてはある程度自分で分かっていたので、逆に「組織会計論」でPL（損益計算書）やBS（貸借対照表）の読み方を学んだり、現代社会における宗教の授業を受けたりと、自分が全然知らない領域を興味の赴くままにランダムに受講していましたね。
結果的に、そうした幅広い学問に触れたことが、技術以外の多角的な視点を持つ良いきっかけになりました。
プログラミングという確固たる武器があるからこそ、あえて未知の領域に飛び込んでいけたのですね。エンジニアとしてのスキルを深めるだけでなく、そういった幅広い分野に触れた経験は、CTOとなられた現在に活きていますか？
結果的にすごく役立っています。経営に携わるようになってPLやBSを見る機会も増えましたし、多様なバックグラウンドを持つメンバーと接する上で、当時の幅広い学びが対話の引き出しとして活きています。
また、HCIの領域で学んだ「人間とコンピュータの『関係性』によって状況が定義される」という考え方は、組織づくりにもそのまま通じています。誰と誰をチームにして仕事してもらうか、その関係性のデザインによってチームのアウトプットが大きく変わるんです。
システムと人間の関係性が、組織における人と人の関係性に繋がるというのは非常に面白い視点です。技術力だけでなく、人や組織のパフォーマンスを最大化する上で欠かせない観点だと思います。
一昔前は「エンジニアは別世界の人で、技術だけを追求している」というような見られ方が多かったと思うのですが、私は事業計画や経営、他部署としっかり接続された関係性のある開発組織を作り込みたいと意識してきました。開発組織が孤立するのではなく、コミュニケーションの取り方一つで、組織全体の生産性は全く変わってきますからね。
泥臭い導入支援がキャリアの転機に。ARR10倍を牽引した「脱・属人化」の仕組み
組織と事業の接続というお話が出ましたが、秋山さんご自身もHelpfeelの黎明期にはVPoEとして自ら導入支援（CS）を担当し、直接顧客と向き合ってこられましたよね。エンジニアが現場のフロントに立つこの経験は、その後のキャリア形成にどのようなメリットをもたらしましたか？
現場に行くことは本当に良い経験でした。導入支援のフェーズに入り込むことで、顧客が実際に何に困っていて、自社製品を導入する上でのハードルが何なのかを肌で知ることができたからです。
また、表面的には複雑で難しいシステム要件に見える課題でも、対話を通じて「実はこういう運用にすれば解決しますよ」と、一瞬で解決できる問題が発見できることも多々ありました。
エンジニアが直接現場の生の声を聞くことで、開発の解像度がグッと上がるのですね。とはいえ、開発業務から離れてお客様と直接お話しすることに、最初は抵抗はありませんでしたか？
最初は人と話すのが苦手で、正直すごく嫌だったんです。BtoBの顧客に対して「要求が高くて厳しい人たちなのでは」と、勝手に怖い偶像を想像していました。でも実際に現場で蓋を開けてみたら、皆さんとにかく日々の業務の課題を解決したいだけで、すごく優しくていい人たちだったんです。
それは意外な発見ですね！現場の方々の顔が見え、人間味に触れることで、「この人たちの課題を解決したい」という開発へのモチベーションにも繋がりそうです。そうした泥臭い経験が、その後の組織拡大にどう結びついたのでしょうか？
現場で直接対話したことで、顧客が抱えるリアルな課題の「パターン」が見えてきたことが大きいです。事業が徐々に成長してPMF（プロダクトマーケットフィット）が見え始めたタイミングで、それらの共通課題を解決する手段を、属人的な対応から「組織としての仕組み」へと昇華させる決断をしました。
それまではCEOの勘や、個人の頑張りに依存していましたが、現場の解像度が上がったことで「ここはシステム化できる」「ここはマニュアル化できる」という切り分けが可能になり、誰でも同じクオリティの価値を提供できる体制を作れたのです。
ARR10倍という急速な成長の裏には、共通課題を見極めた上での標準化の徹底と、それによって顧客が急増しても品質を落とさずに価値を届けられる「組織のスケーラビリティ」の獲得があったのですね。
標準化を進める上で、あえて人間がやるべきことと、システムで解決すべき本質を見極める基準はどこにあるのでしょうか？
再現性があって何度も繰り返される業務や、複数のお客さんに横展開できるものは、SaaSの機能として取り込んで標準化すべきだと考えています。逆に、ドキュメントや標準仕様がないまま、ただ人を増やして対応しようとすると、SaaSビジネスではなく労働集約的な受託開発組織になってしまうリスクがありますからね。
受託開発的な組織にならないための工夫として、取締役会などでも開発状況をチェックされているとお聞きしました。経営層に対して、どのような指標で開発の健全性を共有しているのでしょうか？
非常に簡易的な指標ですが、「作成した機能数」を分母に、「その機能を使っている顧客数」を分子に置くという計算をしています。この数値が1未満なら、頑張って作って誰も使っていない不要な機能が存在しているというサインになります。逆に1以上なら、複数顧客で使われているSaaS的な価値が正しく生み出せていると判断できるわけです。
「生成AIの価格破壊」の衝撃。技術の民主化を見抜いたCTOとしての即断
2023年3月のGPT-3.5 API公開当日に、開発の優先順位を即座に変更し、生成AIを活用した「FAQ作成支援ツール（FAQの自動生成機能）」の開発へとリソースを全振りされたそうですね。この全社的な最優先事項とも言える決断の根拠は何だったのでしょうか？
最大の根拠はコストです。それまでの常識を覆すような1000トークンあたり0.002ドルという爆安価格を聞いた瞬間、自分の中で強烈なスイッチが入りました。品質の良いものがこれほど安価になった瞬間に、世の中が大きく変わると確信したからです。まさに「一部の専門家や研究者だけのものだったAI」から、「技術の民主化」が起きる瞬間でした。
なるほど。技術の性能そのものよりも、コスト破壊による「民主化」が社会実装を一気に進めると見抜いたのですね。過去のITの歴史を見ても、コストの低下が普及の起爆剤になっていますよね。
おっしゃる通りです。例えば、日本で常時接続のインターネットが爆発的に普及したのは、ルーターが街中で無料で配られたことが大きかったですよね。また、3Dプリンターも価格が安くなったことで一部の専門家から個人制作にまで一気に広がりました。これと同じように、生成AIも誰もが使える価格帯になったことで、産業革命級の波が来たと判断しました。
産業革命級の波ですか。たしかに、これを見逃すわけにはいかないという危機感が伝わってきます。その状況で、CTOとして具体的にどのような未来を予測して即断されたのでしょうか？
価格が下がったことで、GoogleやAmazon、Appleといったビッグプレイヤーが一斉に参入し、激しい価格競争が始まると予測しました。そうなると、AIモデル自体の性能はコモディティ化し、いかに早くプロダクトに組み込んでユーザーへ価値提供できるかのスピード勝負になると考えたんです。
その日の夕方にはプロトタイプを完成させ、翌週には提供開始という圧倒的なスピード感でした。これを実現できた背景には、開発組織内でどのような準備があったのでしょうか？
実はそれ以前から、社内に「Machine Learning Working Group（ML WG）」を立ち上げ、Google BERTやGPT-3を用いた研究・実験を組織横断で進めていたんです。日頃からAIの技術検証という「種まき」をしていたからこそ、API公開のタイミングで最速の意思決定と実装ができたのだと思います。この波を外さなかったのは、技術責任者として非常に重要なポイントでした。
RICEスコア導入とボトムアップで培う、エンジニアの事業貢献力
開発スピードが上がり、組織が拡大していく中で、エンジニアが「言われたものを作るだけ」の役割から脱却することが求められていると感じます。秋山さんご自身も、コードを書くプレイヤーからCTOへと役割を移す中で、視座の変化があったのでしょうか？
はい。私自身、入社当初は一人のエンジニアとして便利な機能を作ること、目の前のコードを書くことに集中していましたが、Gyazoのマネタイズを担当した際に視座が大きく変わりました。会社の資金的な危機感を共有されたことで、「作るだけ」の態度では社内受託になってしまうと気づき、事業の成長や売上に対して責任を持つ意識が強まりました。
プレイヤーとしての視点から、事業を俯瞰する経営の視点へとシフトされたのですね。エンジニアが事業運営にコミットし、自身のキャリアを広げるためには、具体的にどのような行動をとるべきでしょうか？
トップダウンの指示をただこなすのではなく、現場の開発者ならではの技術的解像度を活かして、より良い代替案や改善案をボトムアップで提案していくことが重要です。「開発者の帽子」を被って対等に議論し、ワークフローを逆流させるようなインタラクションを起こすことが、組織全体の最適化に繋がります。
なるほど。Helpfeelでは、そうした組織の最適化のために、RICEスコアなどを導入されていると伺いました。これはどのような効果をもたらしていますか？
組織が成長してステークホルダーが増えると、飛び交うコミュニケーションや優先順位の議論が膨大になります。そこで、感情や声の大きさに左右されない指標として、Asana上でRICEスコア（※1）を自動計算する仕組みを導入しています。これにより、過不足のない実行と、一定の説明責任を果たせるタスクのトリアージが可能になります。
※1 RICEスコア プロダクト開発において機能開発の優先順位を決めるためのフレームワーク。「Reach（到達範囲）」「Impact（影響度）」「Confidence（自信・確度）」「Effort（工数）」の4つの要素をスコア化し、客観的な優先度を算出する。
指標があることで、エンジニアも納得して目の前の開発に集中できそうですね。その他にも、開発組織と他部門の連携をスムーズにするための工夫はありますか？
エンジニアリングの概念は他部門にも移植可能だと思っています。かつて従業員数が数十名の規模までは、全社的にスクラム開発的な運営を取り入れ、職種を横断してデイリー共有やKPTによる振り返りを行っていました。専門性の違いを固定化せず、相互作用で会社全体を良くしていく姿勢が、エンジニアの事業貢献力を高める秘訣です。
2026年「AIエージェント時代」の生存戦略と次世代エンジニアの役割
2026年の現在、AIが自律的に動く「AIエージェント時代」が本格化しています。この時代において、エンジニアが提供すべき本質的な価値や、求められるベーススキルはどのように変化しているとお考えですか？
AIの進化で「どう作るか（How）」がコモディティ化し、開発コストがゼロに近づいています。その結果、ROIが立ちやすくなり、「やるべきか」「いつやるべきか」を見極めるバランス感覚と、それを実行に移す熱量やスピード感がより一層求められるようになります。
技術的な実装力だけでなく、事業インパクトを瞬時に判断する力が問われるのですね。一方で、ユーザー体験の観点ではどのような変化が起きているのでしょうか？
ツールが高度になりすぎた結果、ユーザーは逆に「何をすべきか（What）」で迷子になるリスクが高まっています。これからは、単に機能を実装するだけでなく、ユーザーの潜在的な意志を汲み取り、適切に目的へと到達させる「魅力的なインタラクション」の設計が不可欠になります。
たしかに、機能が増えすぎて使いこなせないユーザーも多いですよね。そういったインターフェースを設計する上で、エンジニアが気をつけるべき視点は何でしょうか？
「何でもチャットUIにすればいい」という風潮には慎重になるべきです。チャットや音声UIは、事前の知識やプロンプトのスキルをユーザーに要求するため、操作負荷が高い面があります。GUIが普及したのは選択肢を可視化できたからであり、エンジニアは「プログラミングができる自分たちは世の中の平均的なユーザーではない」と常に疑い続ける必要があります。
自分たちの感覚を疑い、ユーザーにとって本当に使いやすいUIを問い続ける姿勢が大切なのですね。最後に、これからの時代に市場価値を高め、キャリアを築いていく読者へメッセージをお願いします。
AIがコードを書いてくれる時代になっても、仕事がなくなるわけではなく、新しい産業や役割が増えていくだけだと考えています。最後に残るのは、責任を取り、方向性を示し、情熱を持ってプロジェクトを前に進める人間の役割です。
キャリアを損得だけで計算するのではなく、自分が何に情熱を持てるか、どんな価値を提供したいかを考え、そこにエンジニアとしてどう関与していくかを見極めることが、最も幸福度の高いキャリアに繋がるはずです。
ライター
