top of page


AIはプログラマーを駆逐しない。AIは「最高の上流設計者」を必要としている
AIの進化によって、システム開発の現場は大きく変わり始めています。 「AIを使えば、もうプログラマーはいらないのではないか」「要件を入力すれば、AIが自動でシステムを作ってくれるのではないか」「これからの開発会社は、AIで安く・早く作れる会社が勝つのではないか」 このような声を聞く機会が増えました。 たしかに、AIは非常に強力です。コードを書くスピードは上がり、仕様書のたたき台も作れます。テストケースの作成、画面案の整理、データ構造の検討、調査作業など、これまで人が時間をかけていた作業の多くを短時間で支援してくれます。 しかし、私たちは日々の開発現場を見ていて、強く感じていることがあります。 それは、AIはプログラマーを単純に駆逐する存在ではないということです。むしろAIは、経験のあるエンジニア、実力のあるビジネスパーソン、そして構想を実行可能な形に落とし込める「上流設計者」の価値をさらに高めていると感じています。 AIは「答え」を出すが、「正しい問い」は人間が作る AIは非常に優秀です。ただし、AIが力を発揮するかどうかは、入力する問いの質に大

Daisuke Neigisi
5 時間前読了時間: 9分


経営は経営者の「生き方」そのものである
会社とは、何でできているのか。 サービスでしょうか。売上でしょうか。採用力でしょうか。 ミッション、ビジョン、バリューでしょうか。 どれも大切です。 しかし、経営を続ければ続けるほど、私は強く感じることがあります。 それは、会社とは最終的に、経営者の「生き方」そのものが反映される場所だということです。 どれだけ美しいミッションを掲げても、どれだけ立派なビジョンを語っても、どれだけ洗練されたバリューを言語化しても、最後に組織の空気を決めるのは経営者の考え方です。 経営者が何を大切にしているのか。何から逃げないのか。どこまで責任を持つのか。誰と仕事をしたいのか。何を許し、何を許さないのか。 それらは、必ず会社に滲み出ます。 組織は、経営者の言葉ではなく「姿勢」を見ている 経営者は、いくらでも良い言葉を語ることができます。 「顧客第一」「挑戦」「誠実」「成長」「仲間を大切にする」 どれも素晴らしい言葉です。 しかし、組織が本当に見ているのは言葉ではありません。 経営者が、実際にどのような意思決定をしているかです。 苦しい局面で逃げるのか。顧客の課題に最

Daisuke Neigisi
6月10日読了時間: 7分


要件定義の『解像度』が10%上がれば、開発コストは30%下がる。TFが上流工程に執着する理由
システム開発において、最もコストが高くつくものは何でしょうか。 エンジニアの単価でしょうか。開発期間の長さでしょうか。外注先の選定ミスでしょうか。 もちろん、それらも重要です。 しかし、私たちTomorrowFuture株式会社が多くの開発現場を見てきて強く感じるのは、開発コストを大きく左右する最大の要因は「要件定義の解像度」だということです。 要件定義の解像度が低いまま開発を始めると、後工程で必ず認識違いが発生します。 「こういう意味だと思っていた」 「ここまで含まれていると思っていた」 「この例外処理は想定していなかった」 「運用で誰が対応するのか決まっていなかった」 「本番後に初めて業務上の問題が見えてきた」 このようなズレは、開発が進めば進むほど修正コストが高くなります。 逆に、要件定義の解像度が10%上がるだけで、手戻り、仕様変更、認識齟齬、追加開発、運用トラブルの発生率は大きく下がります。実務感覚として、上流工程の精度が上がれば、開発全体のコストは30%近く下げられる可能性があります。 だからこそTFは、上流工程に強くこだわります。.

Daisuke Neigisi
6月4日読了時間: 10分


スタートアップに必要なインシデント管理
スタートアップにとって、最も大切なものは何でしょうか。 スピードでしょうか。資金調達でしょうか。優秀な人材でしょうか。プロダクトのアイデアでしょうか。 もちろん、すべて大切です。 しかし、スタートアップが本当に成長していくために必要なものは、実は「失敗を資産に変える仕組み」だと私は考えています。 スタートアップは、失敗を避けながら成長することはできません。むしろ、失敗や課題があるからこそ、プロダクトは磨かれ、組織は強くなり、事業は前に進んでいきます。 だからこそ、スタートアップに必要なのは、失敗を隠すことではありません。失敗を責めることでもありません。失敗を曖昧なまま流してしまうことでもありません。 必要なのは、発生したインシデントを正しく記録し、原因を整理し、再発防止につなげ、組織の知見として蓄積していくことです。 つまり、スタートアップにこそ「インシデント管理」が必要なのです。 インシデント管理は、大企業だけのものではない インシデント管理という言葉を聞くと、大企業や金融機関、上場企業、あるいはセキュリティ部門が行う厳格な管理をイメージされる

Daisuke Neigisi
5月27日読了時間: 11分


All Star SaaS Fundに参加して感じたこと
― AI時代に求められるのは「開発会社」ではなく、変革を実行できるパートナーである ― 先日、All Star SaaS Fundが主催するAI関連イベントに参加させていただきました。 会場はほぼ満席で、参加されている方々も、新規事業責任者、PM、PdM、エンジニア、CXO、AIスタートアップ関係者など、実際にプロダクト開発や事業推進の現場に向き合っている方々が中心でした。 非常に熱量の高い空間であり、単なる情報収集の場ではなく、今まさにAIをどのように事業へ取り込むべきか、各社が真剣に模索していることを強く感じました。 今回のイベントを通じて、私自身が最も大きく感じたことがあります。 それは、AI活用のフェーズが明確に変わったということです。 これまでは、「AIを使ってみる」「ChatGPTを業務に取り入れてみる」「AIで一部の作業を効率化してみる」という段階でも、十分に先進的な取り組みとして捉えられていました。 しかし、これからの時代はそれだけでは不十分です。 今後求められるのは、AIを前提として、業務・組織・プロダクト・事業そのものを再設計

Daisuke Neigisi
5月20日読了時間: 11分


これからのエンジニアは経験と実績のみが評価される。言葉、技術力、開発言語による壁はAIで補われる
システム開発の世界は、いま大きな転換点を迎えています。 これまでエンジニアの価値は、「どの開発言語が書けるか」「どのフレームワークに詳しいか」「何年経験があるか」「日本語で細かくコミュニケーションできるか」といった要素で判断されることが多くありました。 もちろん、それらが重要であることは変わりません。 しかし、AIの進化によって、これまで絶対的な差だと思われていたものの多くが、急速に補完される時代になりました。 コードを書く力。仕様を整理する力。翻訳する力。ドキュメントを作る力。テストケースを作る力。複数言語間のコミュニケーションを支援する力。 これらは、AIによって確実に底上げされています。 では、これからの時代に本当に評価されるエンジニアとは、どのような人材なのでしょうか。 私たちTomorrowFuture株式会社は、これからのエンジニアに最も求められるものは、単なる技術力ではなく、経験と実績、そして人となりだと考えています。 もっと踏み込んで言えば、これからのシステム開発では、受け身の人材は価値を出しにくくなります。 悪意を持って仕事をす

Daisuke Neigisi
5月13日読了時間: 10分


文化の壁は、海を越えるパドリングで超える。ベトナムの熱量と日本の品質を融合させる技術
「オフショア開発は、コストは安いが品質が不安だ」 「言葉は通じているはずなのに、なぜか期待通りのものが上がってこない」 そんな悩みを抱え、一歩踏み出せずにいる、あるいは現場の摩擦に疲弊している企業の皆さまへ。 こんにちは。私たちは、日本とベトナムの強みを掛け合わせ、数々の新規事業を形にしてきました。今日は、私たちが大切にしている「文化の壁を乗り越え、最高のプロダクトを創るためのフィロソフィー」についてお話しします。 1. 「オフショア」という言葉の先にあるもの 「オフショア(Offshore)」という言葉は、直訳すれば「岸を離れて」という意味です。 多くの企業が、海を越えた先にあるベトナムを「安価なリソースの供給源」として捉えがちです。 しかし、その捉え方自体が、実はプロジェクトを失速させる最大の要因かもしれません。 私たちが目指しているのは、単なる外注関係ではありません。 同じボートに乗り、同じ目的地を目指してパドリング(漕ぐこと)を共にするパートナーシップです。 ベトナムには、かつての日本が持っていたような、圧倒的な「成長への熱量」があります

Daisuke Neigisi
5月6日読了時間: 4分


「憧れの大人」を増やすことが、日本のIT業界を救うと信じている理由
はじめに:IT業界に足りないのは、エンジニアだけではない 日本のIT業界では、長年「エンジニア不足」が叫ばれています。 システム開発をしたい。DXを進めたい。新規事業を立ち上げたい。ベトナムオフショア開発を活用したい。でも、社内に進め方がわかる人がいない。 このような相談を、私たちTomorrowFuture株式会社、通称TFは日々いただいています。 もちろん、エンジニア不足は大きな課題です。しかし、私はそれ以上に深刻な問題があると感じています。 それは、IT業界に「憧れの大人」が少ないことです。 若いエンジニアが、「あの人みたいになりたい」「あの人と一緒に働きたい」「あの人の考え方を学びたい」と思える大人が少ない。 そして、その結果として、現場はただの作業場になり、エンジニアは疲弊し、離職率が上がり、プロジェクトの品質も安定しなくなっていきます。 TFが大切にしているのは、単なるシステム開発ではありません。人が育ち、チームが育ち、顧客の事業が育つ開発体制をつくることです。 そして、その中心にあるのが「憧れの大人を増やす」という考え方です。...

Daisuke Neigisi
4月29日読了時間: 11分


なぜTFのベトナム拠点は、離職率が低く「当事者意識」が高いのか?——人格者経営の輸出
ベトナムオフショア開発を活用したい。しかし、実際に始めてみると、こんな悩みにぶつかる企業は少なくありません。 ・担当者がすぐ辞めてしまう ・引き継ぎのたびに品質が落ちる ・言われたことしかやらない ・日本側が細かく指示しないと進まない ・結果として、安いはずのオフショアが高くつく これは、ベトナムオフショア開発そのものが悪いのではありません。多くの場合、原因は「開発体制」ではなく「経営の輸出」に失敗していることにあります。 Tomorrow Future株式会社(以下、TF)は、単に日本の仕事をベトナムに流す会社ではありません。企画、要件定義、システム開発、運用監視までを一気通貫で支える中で、日本とベトナムの間にある見えない断絶を埋めることに強みを持っています。 その中でも、よく驚かれるのが、TFが運営するベトナム拠点の「離職率の低さ」と「当事者意識の高さ」です。 なぜ、同じベトナムでも、ある会社では人が定着せず、ある会社では現場が自走するのか。その答えは、仕組みだけではありません。 根本にあるのは、代表・根岸大輔の人間性を軸にした経営そのもので

Daisuke Neigisi
4月22日読了時間: 8分


なぜ、優秀なエンジニアを揃えてもプロジェクトは失敗するのか?——PMOが「防波堤」になる理由
システム開発の現場で、こんな声を聞くことは少なくありません。 「優秀なエンジニアを集めたのに、なぜかプロジェクトがうまく進まない」「開発会社の技術力は高いはずなのに、納期も品質も想定通りにならない」「ベトナムオフショアを活用しているのに、逆に管理が難しくなっている」 実は、こうした問題の本質は“エンジニアの能力不足”ではないケースがほとんどです。 むしろ多いのは、優秀な人材がいるにもかかわらず、プロジェクト全体を前に進める仕組みがないことです。そのとき、表面化しやすいのが次のような症状です。 要件が曖昧なまま開発が始まる。意思決定が遅れる。関係者ごとに言っていることが違う。優先順位が途中で変わる。開発チームが毎回“解釈”で動かざるを得ない。 この状態では、どれだけ優秀なエンジニアを揃えても、プロジェクトは安定しません。 そこで重要になるのが、PMOの存在です。 PMOは、単なる進捗管理役ではありません。経営、事業、現場、開発、運用のあいだに立ち、プロジェクトを崩壊から守る「防波堤」の役割を果たします。 今回は、なぜ優秀なエンジニアだけではプロジェ

Daisuke Neigisi
4月16日読了時間: 8分


ベトナムオフショアは『安さ』の時代から『パートナー』の時代へ。デュアルショア最適化の極意
「ベトナムオフショア」と聞くと、いまだに多くの企業が最初に思い浮かべるのは“開発費を安く抑える手段”ではないでしょうか。 もちろん、コストメリットは今でも重要です。しかし、2026年のいま、企業が本当に求めているのは“ただ安く作ること”ではありません。 求められているのは、事業を前に進めること品質とスピードを両立すること開発後も安定して運用できること複雑な社内調整や運用課題を含めて成功確率を高めることです。 つまり、ベトナムオフショア開発は、もはや「安さ」の時代から「パートナー」の時代へ移っています。 特に、新規事業、既存システム刷新、業務改善、DX推進、AI活用、運用保守まで見据える企業にとって重要なのは、単なるオフショア活用ではありません。日本側とベトナム側、それぞれの強みを最適配置する「デュアルショア最適化」こそが、成功の鍵になります。 今回は、なぜ今「ベトナムオフショア=安い開発会社探し」という考え方では通用しなくなっているのか、そしてなぜ「デュアルショア最適化」が企業成長に効くのかを、実務目線で解説します。 なぜ今、ベトナムオフショアに

Daisuke Neigisi
4月8日読了時間: 9分


人材不足をチャンスに変える!ベトナム活用の最前線
日本のIT業界において「人材不足」は、もはや一時的な課題ではありません。 エンジニア不足、PM不足、企画人材の不足。そして、その影響で遅れる新規事業、進まないDX。 しかし、私たちはこの状況を「課題」ではなく、 大きなチャンス だと捉えています。 なぜなら、今こそ「開発のやり方」を変えることで、企業の成長スピードを一気に引き上げられるタイミングだからです。 人材不足が企業成長を止めている現実 多くの企業様から、以下のようなご相談をいただきます。 開発したいが、エンジニアが採用できない 外注しているが、コントロールできていない ベトナムオフショアを使っているが、品質が安定しない 新規事業の進め方がわからない これらに共通するのは、単なる「人材不足」ではなく、 👉 “開発の仕組み不足” です。 ベトナム活用は「安く作る手段」ではない 多くの企業が誤解しているのがここです。 ベトナムオフショア開発は❌ 安く作るための手段ではなく⭕ 競争優位を作るための戦略 です。 実際、ベトナムは今や以下の強みを持っています。 若く優秀なIT人材が豊富 学習意欲が高

Daisuke Neigisi
4月2日読了時間: 4分


ベトナム人の履歴書は「1社の就業期間」を見よ
ベトナムオフショア開発を検討している企業、あるいは既に活用している企業から、よくこんな相談をいただきます。 「優秀なエンジニアの見分け方がわからない」「履歴書を見ても判断基準がない」「採用してもすぐ辞めてしまう」 結論から言います。 ベトナム人エンジニアの履歴書で最も重要なのは、“1社あたりの就業期間”です。 これは単なる採用の話ではなく、**プロジェクト成功率を大きく左右する“本質的な判断軸”**です。 なぜ「就業期間」が重要なのか? 日本企業はどうしても以下を見がちです。 ・学歴・スキル(言語・フレームワーク)・プロジェクト経験 もちろんこれらも重要です。 しかし、オフショア開発においてはそれ以上に重要なのが、 「継続して価値を出せる人材かどうか」 です。 そして、それを最もシンプルに表すのが、 👉 1社でどれだけ働いているか なのです。 ベトナム市場のリアル:転職は当たり前 まず前提として理解すべきことがあります。 ベトナムIT市場は、 超売り手市場です。 ・優秀なエンジニアは引く手あまた・給与アップのための転職は一般的・キャリアアップ=

Daisuke Neigisi
3月25日読了時間: 4分


TFが提案する“攻めのQA/QC”で品質はここまで変わる
システム開発の現場で、「品質管理」と聞くと、どうしても最後のテスト工程を思い浮かべる方が多いのではないでしょうか。 バグを見つける。不具合を直す。納品前にチェックをかける。 もちろん、それも大切です。ですが、私たちTomorrowFuture株式会社(以下、TF)は、QA/QCをそのような“最後の守り”だけで捉えていません。 むしろ、これからの開発において品質管理は、 開発を止めないための仕組み であり、 事業スピードを上げるための武器 であり、 投資判断の精度を高めるための経営機能 だと考えています。 特に、ベトナムオフショア開発を活用したい企業、すでに活用しているけれどうまくいっていない企業、新規事業を立ち上げたい企業、そして企画から要件定義・開発・運用監視まで 一気通貫で任せたい企業にとって、QA/QCの考え方次第で成果は大きく変わります。 今回は、TFが提案する**“攻めのQA/QC”**とは何か、なぜ品質がここまで変わるのかを、現場目線と経営目線の両方からお伝えします。 なぜ多くの開発プロジェクトは「品質」で苦しむのか...

Daisuke Neigisi
3月11日読了時間: 8分


オフショアを超える―ベトナム×日本のハイブリッド型開発の真価
「ベトナムでオフショア開発を始めたけど、思ったより成果が出ない」 「コストは下がったけど、品質やスピードに課題がある」 「そもそも何をどこから頼めばいいのかわからない」 こんな声を、私はこれまで何度も聞いてきました。 ベトナムITオフショア開発は、コスト削減の手段として多くの日本企業に注目されています。しかし、「オフショアを活用しているのにうまくいかない」という企業が後を絶たないのも事実です。 その根本原因は何か。そして、それを解決する「ハイブリッド型開発」とは何か。 本記事では、ベトナム×日本のハイブリッド型開発が持つ真の価値と、企画から運用まで一気通貫で進める具体的な方法をお伝えします。 なぜ「ベトナムオフショア開発」は失敗するのか よくある失敗パターン3選 ① コミュニケーション不足による要件のズレ 「伝えたつもり」が最大の落とし穴です。日本側がざっくりとした要件を渡し、ベトナム側がそれを独自に解釈して開発を進める。完成物を見て「これじゃない」と気づく頃には、時間も費用も大きく消費されています。 ② 仕様書・ドキュメントの不備...

Daisuke Neigisi
3月4日読了時間: 7分


弊社はシステム開発のプロデューサーである
(※この記事でわかること: 「開発会社に頼む」と「プロデューサーに頼む」の違い /ベトナムオフショアを“武器”に変える進め方/炎上を未然に防ぐチェックポイント) システム開発って、実は 映画制作 にそっくりです。 脚本(企画・要件)が曖昧だと、撮影(開発)が始まっても迷走する キャスト(エンジニア)を集めても、演出(設計・意思決定)が弱いと作品が崩れる 公開(リリース)後に、配給・宣伝(運用・改善)が回らないとビジネスにならない ここで重要なのが「プロデューサー」です。プロデューサーはカメラを回しません。演技もしません。けれど、 作品の成功確率を最大化する責任者 です。 そして私たちTomorrowFuture株式会社(TF)は、まさに “システム開発のプロデューサー” として伴走します。 (開発そのものだけではなく、 投資判断・統制・複雑性・運用 まで含めて成功に導く、という立ち位置です。) 「開発会社に頼んだのに、うまくいかない」本当の理由 ご相談で多いのは、こんな状態です。 ベトナムオフショアを使いたいが、 進め方が分からない すでに使

Daisuke Neigisi
2月18日読了時間: 5分


AI駆動開発会社と弊社の違い
――「速さ」と「安さ」に惹かれたあと、最後に効いてくる“勝ち筋”の話 最近、「AI駆動開発」を掲げる開発会社が増えています。見積りが早い、提案が早い、開発も早い。スピード感のある言葉が並ぶほど、経営者や事業責任者にとっては魅力的に映ります。 ただ現場で何度も見てきたのは、こういう構図です。 作るところまでは早い でも、 合意形成・運用・統制 で止まる 結果、 安かったはずなのに高くつく この記事では、AI駆動開発会社(以下「A社」とします)と、TomorrowFuture(以下「TF」)の違いを、できるだけ大衆向けにわかりやすく整理します。 まず、A社(AI駆動開発会社)が評価される理由 A社の魅力はシンプルです。 1)意思決定が早くなる 「概算」「たたき台」「プロトタイプ」がすぐ出てくると、会議が進みます。“何から始めればいい?”が解消されるのが強い。 2)初期費用が抑えやすい AIや自動化の活用で、要件整理・設計・テストなどの工数を圧縮しやすい。特に「型がある開発」ほど効きます。 3)スピードで勝負できる 短期で形にして、ユーザーに当てて、改

Daisuke Neigisi
2月14日読了時間: 4分


提案型のエンジニアのみ採用する
(Note掲載用|TomorrowFuture株式会社) 「ベトナムオフショア開発を使ってみたいけど、進め方がわからない」「すでに使っているけど、品質・納期・コミュニケーションが噛み合わない」「新規事業を最短で立ち上げたいのに、要件が固まらず手が止まる」 こうした相談を受けるたびに、私たちは“ある結論”に戻ってきます。 オフショアか国内か、国籍か言語か、よりも先に、採用すべきは「提案できるエンジニア」だけ だということです。 本記事では、オフショア開発がうまくいかない本当の原因と、TomorrowFuture株式会社が「提案型のエンジニアのみ採用する」と決めた理由、そして失敗確率を下げるための実践的な方法をまとめます。 オフショア開発が失敗する“根本原因”は「技術力不足」ではない 多くの企業が、オフショアの課題を「言語の壁」や「スキル差」と捉えがちです。しかし、現場で10年単位で日越ハイブリッド体制を見てきた立場から言うと、もっと本質的な原因はここです。 ゴールが曖昧なまま走り出す 仕様が未確定なのに、作るフェーズに入ってしまう...

Daisuke Neigisi
2月4日読了時間: 5分


スタートアップが短期間でMVPを形にする秘訣
――「速い・安い」だけでは生き残れない。勝つのは“合理的に当てにいく”チームだ。 スタートアップにとって、時間は通貨です。資金が潤沢でない以上、プロダクトは「早く」「安く」形にしなければ、マーケットに辿り着く前に息切れします。 ただし、ここに落とし穴があります。早さと安さだけを追うと、**“使えないMVP”**が出来上がり、結局やり直しで時間もお金も溶けます。 スタートアップに必要なのは、最短距離で「検証可能なMVP」を作り、学習サイクルを回し続けること。 この記事では、 短期間でMVPを形にし、投資家・顧客・チームの期待に応えるための秘訣 を、実務目線で解説します。 そして、なぜその実行において TomorrowFuture(TF)が“合理的な最適解”のパートナーになれるのか を明確にします。 MVPの本質は「最小」ではなく「最速で学ぶ」こと MVPというと「小さく作るもの」と誤解されがちですが、本質はそこではありません。MVPの目的はただ一つ。 “最速で仮説検証を回し、次の意思決定を正しくすること” つまりMVPは、見栄えの良い試作品ではなく

Daisuke Neigisi
1月28日読了時間: 6分


開発が止まる会社に足りない“POC文化”
「要件は決まったはずなのに、開発が進まない」 「作ってみたら違った。手戻りで疲弊した」 「オフショアを使っているのに、なぜかスピードも品質も上がらない」 こうした“開発停止”の根本原因は、技術力や人手不足よりも 「POC(検証)を前提に意思決定する文化=POC文化」 が欠けていることにあります。 そしてこのPOC文化がない組織では、 シニアエンジニアの選び方 がそのまま成果を左右します。特にベトナムオフショアを活用する企業にとっては、シニア採用の方針が「コスト最適化」なのか「停滞の固定化」なのかを分ける分岐点になります。 そもそもPOC文化とは何か? POC(Proof of Concept)は、ざっくり言えば 「作る前に、確かめる」 ための短期検証です。ただし重要なのは、POCそのものではなく、POCを回す前提で意思決定する“文化”です。 POC文化がある会社では、こんな会話が当たり前になります。 「この仕様、実現できる?まず3日で検証しよう」 「ユーザーが本当に使う?1週間で仮画面と計測だけ入れよう」 「性能が怖い。負荷の当たり方だけ先に

Daisuke Neigisi
1月21日読了時間: 5分
bottom of page