この記事でわかること
-
定石に流されない技術選定の具体的な判断基準と実践方法
-
エンジニアが事業視点を持つための「3本の矢」思考法
-
ドッグフーディング文化の実践と課題の乗り越え方
急速に変化するテクノロジー環境において、エンジニアは単なる実装者から事業価値を創出するプロダクトエンジニアへの転換が求められています。この変化に対応するため、技術選定から組織運営まで、従来の「定石」にとらわれない独自のアプローチが注目されています。
株式会社Helpfeelで執行役員CTO/開発本部長を務める秋山博紀氏は、11歳からソフトウェア作家として活動し、優秀な若手クリエーターを発掘するIPA未踏事業の採択者でもあります。同社では3つのプロダクト（Helpfeel、Gyazo、Cosense）を開発組織で運営し、「定石を安易に採用しない」技術選定や独自の組織文化を築いています。
本記事では、秋山氏へのインタビューを通じて、技術選定の判断基準から自走する開発チームの作り方、そしてAI時代におけるエンジニアのキャリア戦略まで、実践的な知見をお伝えします。
秋山 博紀
株式会社Helpfeel 執行役員 CTO/開発本部長。11歳からソフトウェア作家として活動し、2005年経済産業大臣賞を受賞。2008年未踏ソフトウェア創造事業採択。慶應義塾大学大学院でユーザーインタフェース研究を行い、2015年にHelpfeelにジョイン。VP of Engineeringを経て2022年よりCTOとして活躍中。
【SNS】：https://x.com/akiroom
株式会社Helpfeel
2007年創業。FAQシステム「Helpfeel」、スクリーンショット共有ツール「Gyazo」、情報整理プラットフォーム「Cosense（旧Scrapbox）」を展開。独自の検索技術とユーザビリティを強みとする。
【URL】：株式会社Helpfeel
目次
複数のプロダクトを扱うことで顧客解像度が高まる
技術に対する考え方について、11歳からソフトウェア作家として活動されてきた中で、一貫してどのような価値観をお持ちでしょうか？
子供の頃から今に至るまで、技術に対する考え方はそんなに大きくは変わってないんです。自分にとっての技術は、自分が実現したいことや世界観を実現するための「手段」です。
パソコンを触る前だと、絵画教室に通ったりプラモデルを組み立てるのが好きだったりと、何かを作ること自体が好きだったんです。その後、パソコンという一つのプラットフォームでいろいろなことを実現できるようなシステムを目の前にしたとき、その中で「何を作るか」ということに創造的な興味が湧いて触り始めました。
幼少期から一貫して「作ることへの興味」が軸にあったというのは、エンジニアとしての原点を感じます。現在のHelpfeelの開発組織はどのような体制になっていますか？
現在、開発部は私を含めて53名（うちフルタイム従業員39名）の組織です（※2025年10月時点）。当社ではAIを活用したFAQシステム「Helpfeel」、スクリーンショット共有ツール「Gyazo」、ナレッジベース「Cosense」を開発組織で運営し、Gyazoが8名、Cosenseが2名、Helpfeelが25名、その他イネーブルメント系の業務をしているメンバーが数名という構成です。
人数の多いHelpfeelの開発・運用では、3名から6名ぐらいの小さいユニットを組み、そのユニット単位で日常のマネジメントが機能しています。
小規模のユニット制は機動力がありそうですね。3つのプロダクトがそれぞれ異なる市場を狙っていますが、エンジニアが自社の事業領域や顧客ニーズを理解することで、技術的な判断にどのような影響があるのでしょうか？
3つのプロダクトは、それぞれビジネスモデルが違うんです。法人向けのHelpfeel、個人ユーザー中心のGyazoと、ターゲットが全く異なるプロダクトになっています。売上構成も、Gyazoは海外が8割、Helpfeelは国内が9割以上と対照的です。
エンジニアにとって、こうした異なるプロダクトに関わることの価値はどこにあるのでしょうか？
技術力だけでなく、顧客解像度の高さと事業理解の深さを持ちながら、複合的な視点を持てることが、エンジニアの資質として大事だと思っています。異なるプロダクトに関わることで、その幅が広がっていきます。
例えば、Gyazoはプロダクトレッドグロース（PLG）※1の色合いが強く、Helpfeelがセールスレッドグロース（SLG）※2に近いんですが、社内でPLGで磨いた知見をHelpfeel側に活かしたり、逆にHelpfeel側で得た知見をGyazoに輸出したりするなど、相互のインタラクションがあります。
※1 PLG（Product-Led Growth）：プロダクト自体でユーザー獲得・成長を促進する手法
※2 SLG（Sales-Led Growth）：営業活動を中心とした成長手法
「エンジニアの直感」から始まる技術選定
「定石を安易に採用しない」という価値観について、具体的にはどのような判断基準で技術選定を行っているのでしょうか？
まず入口としては、エンジニアの「この技術で進めた方が良い解決になりそう」という直感を最初に重視しています。トップダウンで技術を決めるのではなく、現場のエンジニアが「この技術を採用しよう」と考えているところから議論がスタートします。
技術選定する上では、安定性、金銭的コスト、保守コストという人的なコスト、そもそも将来的にその技術を選定したときに人材を確保できるのかというサステナビリティといった複合的なところを、総合的に決めていくことになります。
そうした複合的な判断の具体例として、Elasticsearch※3とローカル検索の使い分けについて、その思考プロセスを教えてください。
※3 Elasticsearch：大量のデータを高速で検索・分析できるオープンソースの分散検索エンジン。企業のWebサイトやアプリケーションでよく利用される。
例えば、Gyazoの検索エンジンでは、毎月3000万件ずつ動画や画像がアップロードされているんです。その中で自分の所有してる動画像を検索対象にするような実装になるので、基本的に検索対象がすごく大規模になる。その場合はElasticsearchがいいよねということで、これはいわゆる定石に近い発想です。
一方で、HelpfeelのFAQの場合、大体400件から600件ぐらいのページ数が多くなっています。数百件の検索対象だけのために、Elasticsearchを使うのか、自社で検索エンジンを作るのかという選択肢があります。
規模によって判断が変わるということですね。Helpfeelではどのような判断をされたのでしょうか？
Helpfeel事業そのものは、検索のアルゴリズムが先にあって、これをどう展開すると価値を生み出すかという順番で決まってるので、その検索アルゴリズムを使いたいというのが起点にあるんです。そこで、いくつかモックアップを作っていく中で、フロントエンドで作ったモックアップが一番高速に動いて、実際に便利だったということから、フロントエンドでの実装という着地になりました。
フロントエンドでの実装のように、一般的ではない技術選択をする際、チーム内でのコンセンサス形成はどのように進めていますか？
当社の場合だと、技術面で意見がかみ合わないということは少ないですね。理由はCosenseを使って論点を整理していくと、だんだん議論としては収斂していくことが多いからです。
議論がかみ合わないということは、恐らく曖昧な言葉で議論しているか、あるいは決めきれない何かがまだ残ってるかのどちらかです。例えば「定石が安全」という言葉が出てきたときに、その発言者は何らかの不安や懸念を抱えているはずなんです。ただ、その懸念が具体的に言語化されていない状態なんですね。
その懸念を具体化していくプロセスを教えてください。
「定石が安全」と言う人が本当に心配しているのは、例えば将来的な保守で人手が足りなくなることなのか、予算の見積もりが立てられないことなのか、それとも社内に経験者がいないため運用で問題が起きることなのか。こうした具体的な懸念を一つずつ明確にしていくと、チーム間での認識のズレが見えてくるんです。そのズレを埋めるための対策を検討していけば、技術的な議論は自然と収斂していきます。
一気通貫で推進できる「プロダクトエンジニア」の重要性
エンジニア採用において、「プロダクトエンジニア」を重視するようになった理由を教えてください。
『言われたものを作って置いておけば誰かが使う』という従来の世界観では、もはやプロダクトが真価を発揮しづらい時代になってきたからです。技術的な実装力だけでなく、ユーザーの課題を理解し、それを技術で解決する一連のプロセスを一人で回せる人材が必要になってきています。
特に当社のように複数のプロダクトを展開している環境では、技術力と事業理解、顧客解像度を同時に持つ人材でないと、本当の意味でプロダクトの価値を最大化できません。そのため、企画から実装、リリース後の運用まで一気通貫で推進できるプロダクトエンジニアを重視するようになりました。
なるほど、単なる実装者ではないということですね。ちなみに、フルスタックエンジニアとプロダクトエンジニアの違いは？
フルスタックエンジニアが技術的な万能性を重視するのに対し、プロダクトエンジニアは技術以外の領域にも積極的に視野を広げられる人材だと考えています。
実は当社も元々はフルスタックエンジニアという募集の仕方をしていたんですが、ずっと違和感を感じていました。フルスタックという言葉からは、あらゆる技術領域に精通した高度なスペシャリストをイメージしがちですが、当社が本当に求めていたのは技術的な万能性ではなく、技術以外の領域にも積極的に視野を広げられる人材だったんです。
そこで着目したのが個人開発の経験です。個人開発では必然的に企画から実装、リリース、そして市場での反応の受け取りまでを一人で完結させる必要があるため、技術力だけでなく幅広い視点を身につけた人材が多いと考えています。実際に当社では、個人開発の経験を持つ人材を中心に採用してきました。
個人開発経験を重視される理由は何でしょうか？
個人開発を経験した人は、ユーザーからの正負両方のフィードバックを直接受け取り、それを次の改善に活かす判断力を身につけています。また、反応が得られなかった場合でも、「単にプロダクトをリリースするだけでは価値は伝わらない」という現実を体感として理解している人たちです。
私自身や当社のCEOも、そうした個人開発の経験を積み重ねてきたメンバーなので、同じような価値観を持つ人材に来てもらいたいと考えています。結果として、個人開発経験者の特性は、当社が求めるプロダクトエンジニア像と非常に親和性が高いんです。
事業価値を生む「3本の矢」思考法とは
メンバーが自分でタスクを選び、問題を発見していく働き方を実現するために、どのような仕組みを整備していますか？
Helpfeelのプロダクト開発では「3本の矢」というものを定義しています。経営視点、顧客視点、開発者視点という3つの領域を、開発者がバランスよく見ていく必要があるということを、社内外に説明しています。
経営視点では、中長期のロードマップ策定、新規プロダクト開発、営業支援材料の提供を担います。例えば、2023年3月2日にChatGPTのAPIが公開された際は、当日中にプロダクトを開発し、翌週にはお客様への提供を開始しました。
驚異的なスピード感ですね。顧客視点ではどのような取り組みをされていますか。
顧客視点では、お客様の課題発見と解決策の提案を行います。要望をいただいた際も、その背景を深く調査し、お客様が本当に求めている解決策を見極めることを重視しています。
ここで興味深いのが、独自の遅行指標を設定していることです。実装済み機能数に対する利用社数の比率を算出することで、1機能あたりの利用社数を把握しています。この数値が1を超えると複数社で共有される汎用的な機能群、1に近いと特定企業向けの受託的な機能群、1未満だと使われない機能を多数作っている状態と判断できます。
その指標は非常に興味深いですね。開発者視点についてはいかがでしょうか？
開発者視点では、UI/UX改善、セキュリティ対策、技術活用による業務効率化に取り組みます。例えば、生成AIを活用した業務効率化では、社内の課題と新技術を結びつけて案件処理の高速化を実現しています。
また、アクセシビリティも重要な要素として位置づけており、デジタル庁のガイドラインを基準とした定期的な棚卸しを実施し、必要に応じて再投資を行っています。
「ハッカー4象限」で高めていくエンジニアの総合力
技術力・美的センス・デザイン思考・実装力などを兼ね備えた人材という独自の「ハッカー定義」について、なぜこの4つの要素が重要だと考えているのでしょうか？ここでいうハッカーは、サイバー攻撃のイメージではなく、技術的な問題を創造的に解決する人という意味でお使いになっていると思いますが。
その通りです。当社では、システムを深く理解し革新的なソリューションを生み出す、ステークホルダーに対して責任を果たすという意味で、ハッカーという言葉を使っています。
具体的にはどのような能力が求められるのでしょうか？
まず幅広くいろんなことに興味を持って欲しいというのがベースとしてあります。専門性があるというのは非常に大事なんですが、その専門性をどんどん価値に変換していかなければいけないのが開発組織のミッションだと思っています。
技術だけでバリューを出そうとすると、結局周りの人がどう技術を使うか次第に依存するところがあります。一方で、総合的な考え方を取れる人は、自分の持ってる技術を自分で価値に変換することができるんです。
なるほど、依存しない自立性が重要ということですね。具体的な4象限について教えてください。
ハッカーの4象限として、テクノロジー、アート、デザイン、クラフトという4つの領域を設定しています。これらは、プロダクトエンジニアや個人開発者が価値を生み出すために習得すべき領域です。
株式会社Helpfeel 秋山氏のコラム記事「ハッカーで行こう！」より転載
まずテクノロジーは基礎となる技術力、アートは美意識と創造性を表します。技術を価値に変換するのは簡単ではなく、相当な熱意が必要だからです。ポール・グレアムの『ハッカーと画家』でも指摘されているように、ユーザーが何を必要としているかを理解する「共感能力」も、アートの重要な要素です。
デザインと最後のクラフトについても詳しく教えてください。
デザインは審美的な部分だけでなく、構造設計や業務フロー設計も含む広い概念です。アートだけでは自己表現に終わってしまうため、実際に使えるものにするデザイン力が重要なんです。
クラフトは実装力と職人的な倫理観を意味します。評論家ではなく自分で手を動かす人であること、そして「儲かれば何でもいい」ではなく、クラフトマンシップを持って欲しいという思いを込めています。
例えば、デザイナーがiPhoneアプリをデザインする際、Appleのヒューマンインターフェイスガイドラインを理解せずに進めると、どれだけ美しくても単なる自己表現になってしまいます。プラットフォームの制約や特性を理解してこそ、本当に価値のあるデザインができるのです。
「ドッグフーディング」による改善力とスケールの壁
自分たちで作ったプロダクトを自分たちで使う「ドッグフーディング」を組織文化として根付かせるために、具体的にどのような取り組みを行っていますか？
基本的には、プロダクトを日常の業務フローに組み込むことから始めています。その上で、もし使用していないメンバーがいれば個別にヒアリングを行い、「こういう便利さがあるのに、なぜ使わないのか」を確認します。そこで判明した課題については、必要に応じてプロダクトの改修を行うという地道な文化づくりを継続しています。
Cosenseについては、もはや社内のOSのような存在になっており、ほぼすべての情報がCosense上に蓄積されています。日常業務を進める上で、Cosenseに触れない日はまずありません。
「社内のOS」という表現が分かりやすいですね。具体的な効果はありましたか？
GyazoのFAQをHelpfeelで構築したところ、問い合わせ件数が大幅に減少し、テクニカルサポートチームから高く評価されました。ドッグフーディングの最大の効果は、自分たちが使うからこそ、使いやすく改善しようというモチベーションが自然に生まれることです。
ただし、最近はドッグフーディング文化による課題も見えてきました。自社と全く異なる状況については、ドッグフーディングでは課題を発見できないのです。例えば、当社は200名規模の組織ですが、数千名規模の組織での利用状況は、ドッグフーディングだけでは把握できません。
確かに、スケールの違いは体験できませんね。その課題にはどう対処されていますか？
ドッグフーディングは文化的な基盤として維持しつつ、それだけでは全てを理解できないという認識のもと、顧客の声により一層フォーカスを当てる取り組みを強化しています。
なるほど。世の中にある開発手法やフレームワークを導入する際、そのまま採用するのではなく自社に合わせてカスタマイズする判断基準を教えてください。
最も重視しているのは、手法やフレームワークの導入自体をゴールにせず、「課題解決」をゴールにすることです。これは意外と見落とされがちですが、マネジメントにおいて非常に重要な視点だと考えています。
まず解決したい課題を明確化し、それが実際に発生している、または発生する可能性があるタイミングで初めて手法やフレームワークの導入を検討します。その際、チームメンバーそれぞれの特性や得意不得意を考慮して、手法の選定やカスタマイズを行っています。
具体的な事例があれば教えてください。
私が当社に転職してしばらく経った頃、スクラム開発の導入要請がありました。理由を確認したところ、人数増加により当時のCEOだけでは開発状況の把握が困難になったことが課題でした。スクラム開発にはさまざまな効用がありますが、当面の課題である「状況把握」に焦点を絞り、毎日の短時間での進捗共有ミーティングのみを導入しました。
当時から当社では、開発者が自由にタスクを選択し、個人の裁量で開発を進めるバザール型開発の文化が根強くありました。一方、スクラム開発は決まった期間でのスプリント実行や、明確な役割分担、定期的なミーティングなど、より構造化されたアプローチです。 この文化的な違いが大きすぎると判断し、スクラム開発は部分的な導入に留めたのです。
AI時代に必要とされる「技術のオーケストレーション」
生成AIツールの導入や検証は、どのような方針で進めていますか？
この領域は変化が非常に早いため、慎重に検討するよりも小さく早く試すことが重要です。現在は金銭的なコストも比較的安価なサービスが多いので、コストが低く取り返しのつかない事態にならない限り、積極的に試行することを重視しています。
例えば、年初にDevin（デビン）という開発AIエージェントがリリースされた際、社内のエンジニアから強く推薦されてすぐに契約しました。当時月額約10万円のサービスでしたが、実際に使ってみることで初めて分かることが数多くあります。
実際に試してみて、どのようなことが分かりましたか？
フルスクラッチ開発と既存システム改善のどちらに適しているか、また、指示出しに一定のマネジメントスキルが必要であることが分かりました。 全エンジニアが毎日使用するようなツールではなく、むしろ指示出しが得意な既存のマネージャー層が活用すべきシステムだと判断し、対象者を絞って配布しました。
AI時代においてエンジニアが提供すべき価値をどう考えていますか？
エンジニアにとって重要なのは、現在と将来の専門性を組み合わせて、最大限の価値を創出することです。具体的には、予算制約の中で、リスク許容度に応じた技術選定や、迅速な実装が可能な技術の組み合わせを判断する能力、つまり技術のオーケストレーション能力や広義の技術活用力が重要になります。
最後に、今後のエンジニア市場を見据えて、技術者が長期的に価値を発揮し続けるために重要だと考える要素を教えてください。
技術的な深掘りは当然重要ですが、機会があれば積極的にさまざまな領域にチャレンジすることをおすすめします。自分の業務範囲を限定せず、「エンジニアなのでここまで」という線引きをせずに、機会があればさまざまな領域に「ズカズカ」と踏み込んでいくことが長期的には有益です。
多様な領域への挑戦により、異なる分野の掛け算が技術者としてのユニークネスや特異性につながります。一つの領域で縦に深掘りしつつ、横にさまざまな分野に踏み込んでいくことで、縦横の展開を通じてAIが参入困難な特殊な人材になれると考えています。
ライター
