# SaaS業界で広がるFDEとは──注目されている理由と求められるスキルを徹底解剖（後編） 元のページ: 開発 2026.09.11 今、SaaS業界を中心に注目を集めているFDE。具体的にはどのような仕事なのか、求められるスキルや経験とは何か──後編では、前編のFDE解説に続き、ちょっと社におけるFDEの活躍や求める人材像について、FDE組織づくりに詳しいエンジニアリングマネージメントの久松剛氏、ちょっと社CEOの小島とCTOの伊藤が語ります。 **久松 剛** 合同会社エンジニアリングマネージメント社長 IT組織づくりの専門家として複数社を支援。ちょっと社ではエンジニアチームのマネジメントや、FDEという働き方の浸透を支援 **小島 芳樹** ちょっと株式会社CEO Next.jsを中心としたフロントエンド開発と、次世代CMS「Orizm」の開発・展開 **伊藤 大知** ちょっと株式会社CTO Orizm開発チームのリーダーとして、開発全般を担当 ## **ちょっと社がFDEを始めた背景** **小島**：ちょっと社でも、2026年4月にFDEを目指したいという話をエンジニアメンバーに伝えています。 Next.jsやVercelの導入支援が事業の一つであったことに加え、自社製品のOrizmもカスタマイズを前提とした作りのCMSであるため、案件ごとに作る必要がありました。元々ワンソースで開発するというより、カスタマイズ志向が強かったんです。 AIによってコードを書く時間が減っていく中で、エンジニアの役割はどうなっていくのか。ちょっと社の特性を踏まえると、そのモデルケースの一つがFDEだと考え、会社としてこうした取り組みをすることを決めました。 **伊藤：**小島さんがおっしゃったように、Orizmの弱点とFDEは相性がいい組み合わせだと思います。 Orizm本体は、何でもできるBaaS（Backend as a Service）のような性質を持つため抽象度が高く、それだけではすぐに価値にならない、ツール群のようなものです。Orizmを始めてから3年くらい、そのポイントに苦しんできました。 そこで最近は、Orizmをカスタマイズして提供するところまで含めて「Orizm」だと考えるようになってきています。FDEモデルであれば、顧客の課題を直接引き出しながら、より効果的にOrizmをカスタマイズして提供できるので、非常に相性がいいんです。 **小島**：もともと私たちは受託事業を行っていましたが、扱っていたのはNext.jsという、一般的にはすぐに役立つものではなく、抽象度の高い技術でした。「Next.jsって何の役に立つんですか？」と聞かれても、パッと答えるのは難しいんです。 だからこそ、そこに付加価値をつけて提供する必要がありました。抽象度の高い技術をクライアントに合わせた価値に変えていくというこのやり方が、FDEの方向性と近いと感じています。 加えて、Next.jsに特化してきたことで独自のノウハウが社内に溜まり、そうした人材をプールできたことも、他の受託会社と大きく違う点です。 ## **ちょっと社が考えるFDEの人物像** **久松：**実際に4月から、ちょっと社のFDEとはどのような役割かを、社内で考えながら実践を始めています。これまでは、クライアントから言われたものを実装するのが一般的な契約でした。しかし今後は、クライアントが本当に欲しい数字や機能を先回りして提案しながら進めることが、ちょっと社のFDEなのではないか、という話をしています。 **小島**：ちょっと社では、CTOの伊藤がFDEっぽい動きをしていると思っています。クライアントからの要求に対して先回りで考えられていますし、加えて、クライアントへの説明や提案内容の抽象度もちょうどよく、クライアントが理解しやすいんです。 FDEに求められるスキルの一つとして、この抽象度のコントロールがあると思っています。 エンジニア同士にしか通じない会話と、ビジネスサイドの人に向けた分かりやすい説明、経営層に対しても理解しやすい説明、この抽象度のコントロールをする必要があります。 経営者にとってちょうどいい抽象度で説明できれば、「それならやってみましょう」と判断してもらいやすくなります。これまでは何人もの人が間に入って行っていた通訳的な役割を、スピード感高く1人で完結させる力が必要になってきますが、伊藤はそれを意識してやっているように見えます。 **伊藤**：意識はしていますが、それだけでは無理で、実際にいろいろな立場で仕事をして身につけていく必要があります。平たく言えば社会経験です。マネジメントを経験したり、マネジメント研修で経営者の気持ちに触れたり、個人事業主のようなこともやりながら、エンジニアという枠を超えてスキルを広げようと努めてきました。 そうした経験がないと、エンジニア以外の立場や気持ちは分かりません。ただ、それをすべて1人に期待するのは非現実的です。スーパーエンジニアのようなFDE像もよく語られますが、パランティアはクライアントと折衝するロールと、技術に集中するロールを分けているそうです。ロールを分けることも、現実的な選択肢かもしれません。 **小島**：会社によって専門性や業種も違うだろうし、全てを求められても難しいですよね。それが小さいサービスならよいですが、顧客が大手企業ばかりだとしたら、さすがに1人で全部受けきれないと思います。 **伊藤**：そのFDEを提供する会社によって、やり方は分かれるかもしれません。属人化を避けて、誰が担当しても同じ品質を出せる仕組みを強みにする会社もあれば、少数の優秀な人材に絞り、その分高い単価で勝負する会社も出てくるでしょう。 ちょっと社はどちらかというと、少数精鋭というよりは、非属人化・仕組み化を進めていく方向性だと思っています。 ## **ちょっと社のFDEはどのように活躍しているか** **久松**：久松：ちょっと社のFDEは、言われたことをやるだけでなく、自ら課題を発見し、調査したうえで主導していく傾向があります。たとえば、高く評価されていたのがTさんの事例です。リセールの複数枚申し込み機能の実装において優先順位の高い論点を発見し、業界事例を調査したうえで「まずはこのような形で実装してみませんか」と提案していく姿は、エンジニアという枠を超えていたと思います。 ### **ちょっと社FDE事例** **Sさん（保険業界の管理システム）** 課題：お客様がCMSの編集にできるだけ手間をかけたくないと考えていた 対応：自動で設定を行いつつ、「やっぱり変更したい」となった場合もあとから手直しできる自由度も残す柔軟な仕組みを実装。色んなソフトで経験した使いづらさを、自分ならどうするかを考え提案し、解決した。 **Kさん（HR系SaaSの管理画面）** 課題：画面ごとに色や角丸が微妙に異なるなど、デザインのずれを都度個別に直す状態が続いていた。 対応：共通ルール（デザイントークン）を整備することを自らPMに提案し、全画面のルールを整理。場当たり的な修正ではなく、根本原因から解決した。 **Tさん（チケットサービスの開発）** 課題：チケットの申し込みを1枚限定から複数枚対応に拡張する改修。仕様を詰める中で、既存ロジックだけでは判断できないことがわかった。 対応：類似サービスの事例を調査し、複数の設計パターンを整理したうえで、クライアントのビジネス部門に初期案を提案。実装を受け取るだけでなく、調査から提案までを自ら主導した。 **Aさん（ゴルフ関連Webメディアの運用）** 課題：Vercelの利用コストやGA4のアクセス状況など、クライアントが個別に確認していた複数のレポートがあった。 対応：それらを日次のSlackレポートとして自動集約する仕組みを構築。クライアントの監視の手間を大きく減らし、成果に直接貢献する取り組みとなった。 \---------------------- **久松**：単なるWebサイト制作にとどまっていないところが、素晴らしいと思います。クライアントが「Webサイトを作りたい」と依頼してきたとしても、その裏には「売上を伸ばしたい」「問い合わせを増やしたい」といった、多くの企業に共通する目的があります。2026年現在のWebサイト制作の依頼は、そうした目的につながっていることが多いです。 クライアントの依頼をそのまま受け取るだけでなく、その裏にある本当の目的を常に考え続け、自分から動ける人。それが、ちょっと社が考えるFDE像だと思っています。 ## **自社開発「Orizm」で求めるFDE** **小島：**ちょっと社はNext.jsのフロントエンド開発支援を幅広く手がけており、「Next.jsなら何でもやる」という意識を持ってきました。今後さらに伸ばしていきたいのは、自社製品のOrizmです。 Orizmは以前、技術的なカスタマイズ性の高さを売りにしていましたが、今後は少し方向性を変えていきたいと考えています。 「マーケティングのあり方を見直したい」「DXやAI活用でサービス・システムをより良くしていきたい」といった、顧客のビジネス課題を解決するタイミングで使っていただけるようにしたいんです。 社内で元々「ソリューションチーム」「ソリューションエンジニア」と呼んでいたメンバーたちに、Orizmの開発においてFDEのように動いてもらいたいと考えています。導入企業がどのようなマーケティング活動を行おうとしているのかを理解し、Orizmをそこにフィットさせていく。最近は、そのためにSEOやマーケティングの知識も身につけてもらおうとしています。 **伊藤**：これまでちょっと社では、エンジニアを特定のドメインに縛りつけず、クライアントに応じて柔軟に動いてもらう方針でした。これからは、そこにマーケティングの視点も加わってくると思っています。 **小島：**それぞれの分野のマーケティングの専門家と連携しながら、チーム全体でSEOやSNS、広告運用といった知識を体系的に身につけていきたいですね。また、「AIプランナー」という企画職の求人も出していますが、彼らとディスカッションしながら、クライアントに「こういうメリットがある一方で、こういうデメリットもあります」と説明できるようになってほしいと思っています。 **伊藤：**エンジニアがゼロからマーケティング施策を提案できるようになる、という話ではありません。ただ、マーケティングの世界を理解していないと、技術的な代替案を提示しても効果が低くなってしまいます。社内のプランナーやクライアントと対等に議論できることが、重要だと思っています。 ## **開発体制とシステム強化も同時に進めていく** **小島**：Orizmの開発では、現場からのフィードバックを製品の機能開発に活かしていきたいと考えています。ただ、フィードバックをもっと集めたい一方で、それを実際の開発に落とし込みきれないというジレンマもありました。 最近はOrizm本体の開発体制を強化するとともに、プラグインの仕組みを整備しています。プラグインという形で機能を追加できるようになれば、本体の開発チーム以外のメンバーも関わりやすくなっていくはずです。 **伊藤**：フィードバックといっても、具体的な機能に関するものもあれば、もっと抽象的な内容のものもあり、レベルはさまざまです。そうしたフィードバックが製品に反映されていくには、社内のコミュニケーションフローが整い、人と人のつながりが強い組織構造であることが重要だと思います。 加えて、裏側に優れたプラグインシステムがあり、技術的にカスタマイズしやすい基盤が整っていることも欠かせません。今はまだそのプラグインシステム自体がなく、FDEのモデルに合った使いやすい仕組みを検討しているところです。ここは技術的にも難易度の高いパートですね。 ## **FDEを目指したいエンジニアへのアドバイス** **久松**：現在はさまざまな企業がFDEを求めているので、自分がなりたいFDE像と実際の求人がマッチしているかを、しっかり読み込んで擦り合わせる必要があります。提示金額だけでなく、何をやるのかを納得したうえで入ることがポイントです。 **伊藤**：ちょっと社が求めるFDEとは、顧客の課題に一歩踏み込んで近づける人だと思います。ただ作るだけでなく、クライアントへの提案や選択肢の比較検討が増えてくるので、トレードオフを理解し、説明できることが大事です。 今はAIに任せれば設計もある程度こなしてくれますが、何が失われるのかという判断はまだ甘いことがあります。説明されないままコストが大きくかかる実装を提案してくることもあるので、そこに目を光らせておくことが大切です。FDEという言葉に踊らされすぎず、強い心で成長していってほしいですね。 **小島**：ちょっと社の特徴は、一次請けのクライアントが非常に多いことです。これは強みであり、エンジニアがキャリアを積むうえでの強みでもあります。 クライアントに頼まれていないことでも裏側で調べておき、トラブル時に迅速に対応する。そうした意識高く動くメンバーは、着実に成長していると感じます。こうした対応ができるのは、独自の営業体制や、Next.jsへの特化、自社製品を持っていることが背景にあります。 いきなりパランティアで働くのは難しいので、まずは入門編として2〜3年ほどちょっと社を踏み台にしてもらうくらいの気持ちで、入ってもらえたら嬉しいです。 **伊藤：**ちょっと社の良いところは、クライアントとの距離が近いことです。SaaS企業だとクライアントが遠かったり、契約はしていても使ってもらえていなかったりすることもあります。エンジニアにとって、クライアントが近いというのは、本当に良い経験になると思います。 **久松：**私もさまざまな会社を見てきましたが、ちょっと社はいわゆるアウトバウンド営業（＝こちらから積極的に売り込む営業）による受注ばかりではないケースが多い印象です。そうした経緯で受注しているからこそ、クライアントとフラットな関係を築けている企業が多いのだと思います。 受発注の関係はもちろんありますが、上下関係になっていないクライアントが多いのはとても良い点で、FDEの観点からも活躍しやすい案件が揃っていると思います。 **小島：**クライアントから「この仕様通りに」と一方的に依頼されるのではなく、「こういうことで困っているけど、どうすればいいか」と相談される日々のコミュニケーションが多いです。今求められているFDEのキャリアに近い仕事だと感じています。 **久松：**これはFDEから少し離れますが、エンジニアに求められることとして、AIは書くスピードこそ圧倒的に速いものの、最終的な判断に責任を持つことはできません。 AIのアウトプットを検証してOKを出すマネジメント要素や、AIが出す「こんな方針でどうでしょう」という提案をあえてチェックし、実装されたソースコードを見てOKを出すことが、エンジニアの仕事になりつつあります。その責任を持てるだけのスキルが、これまで以上に求められていると思います。 この記事をシェア ## 関連記事 [開発 2026.09.10](https://chot-inc.com/columns/fde-vol1) ### [SaaS業界で広がるFDEとは──注目されている理由と求められるスキルを徹底解剖（前編）](https://chot-inc.com/columns/fde-vol1) ## 最新の記事 [セキュリティ 2026.10.23](https://chot-inc.com/columns/railway-secret-rotation-incident-october-2026) ### [Railwayが全ユーザーにシークレットキーの失効・再発行を要請 — 事実関係と、鍵を回す順番](https://chot-inc.com/columns/railway-secret-rotation-incident-october-2026) [AI最新情報 2026.10.23](https://chot-inc.com/columns/arc-browser-sunset-december-22-dia-migration) ### [Arcブラウザが2026年12月22日に終了 ― 期限までにやることとDia移行の判断基準](https://chot-inc.com/columns/arc-browser-sunset-december-22-dia-migration) [AI最新情報 2026.10.22](https://chot-inc.com/columns/cloudflare-os-managed-github-gmail) ### [Cloudflare OS がマネージド提供へ — GitHub 接続と Gmail 連携強化で何ができるようになったか](https://chot-inc.com/columns/cloudflare-os-managed-github-gmail) [コラム一覧](https://chot-inc.com/columns)