こんにちは、リノエッジ代表の原田祥吾＠ベトナムです。
先日、btraxのCEOであるBrandon K. Hill氏がXに投稿していた論考が、頭から離れませんでした。世界中でデザイン会社の倒産が増えている、その原因はAIだけではない、という分析です。締めの問いがこうでした。「デザイン会社は何を売る会社なのか。売るべきものは、たぶんプロダクトじゃない」と。
読んだ瞬間、これはそのままシステム会社に置き換えられる、と思ったんですよね。うちの業界に当てはめると、システム会社は何を売る会社なのか。この記事は、その問いをうちの毎週の仕事に当てはめて考えた話です。先に言っておくと、答えは思ったより地味で、勇ましい話ではありません。
デザイン業界だけの話ではない
デザイン会社限定の話なら、正直そこまで刺さらなかったと思います。でも数字を見ると、これはうちの業界でも起きています。
東京商工リサーチの調査によると、2026年上半期の情報サービス業の倒産は166件。前年同期比18.5%増で、この10年間で最多を更新しました。しかも倒産した会社の8割以上（135件・構成比81.3%）が従業員5人未満で、こちらも前年同期比25.0%増えています。
原因について、東京商工リサーチはこう分析しています。「ノーコード、ローコードツールや生成AIの普及で、簡易なコンテンツ制作・開発業務の内製化が進み、価格競争に依存していた小・零細規模の事業者には逆風が強まっている」
言われた通りに組む、だけの仕事は、発注する側が自分でできてしまう場面が増えてきている。倒産件数の8割が小・零細規模に集中しているのは、そこが一番先に効いた、ということなんだと思います。他人事の数字みたいに書いていますが、うちにも、言われた通りに作る仕事は今もあります。
求められているものが変わってきた
「プログラマーは要らない」と言いたいわけではありません。正確に言うと、言われた通りにプログラムを組むだけのプログラマーの必要性が、少しずつ小さくなっている、という話です。仕組みを作れる人、業界のペインポイントを理解して解決に変えられる人、プログラムがKPIをちゃんとクリアする仕組みになっているか考えられる人は、これからも必要とされ続けます。
アメリカの求人動向を見ても、似たことが起きています。Indeed Hiring Labが算出し、セントルイス連銀のデータベース（FRED）が公開している「ソフトウェア開発の求人指数」は、2020年2月を100とした場合、2022年2月末にピーク233.84をつけたあと、直近2026年7月24日時点で75.48。ピークの3分の1近くまで落ち込んでいます。
ただ、2025年7月24日の底（65.86）からは、この1年でわずかに回復しているんですよね。需要そのものは、消えていません。求められる場所と中身が、変わっただけだと思っています。
システム会社もお客様に求められているのは、仕様通り作って終わり、ではなくなってきています。これを実現するなら、もっとこういうやり方がありますよ、こっちのほうが面白いですよ。お客様が本当に求めていることをちゃんと理解して、期待を超えるものを作れるかどうか。あとは、一緒に仕事をしたいと思ってもらえる人間性。最近すごく大事だなと思っています。で、その人間性が一番あらわれる場所が、実はこのあと書く毎週の定例なんです。
じゃあ、毎週何をやっているのか
ここからが、今日一番言いたい話です。
うちが売っているものの中身は、毎週の定例ミーティングにあります。うちはラボ開発なので、決まった曜日、決まった時間に、毎週やっています。
先週やったこと。いま起きている問題。お客様のビジネス側で起きている問題。そういうものをこちらがどれだけ拾って、次の週の作業に反映できているか。限られた時間と条件の中でトレードオフも当然あって、その中でベストな選択をしていく。それを積み重ねて、一緒にいいものを作っていく関係が、少しずつできていくんですよね。
約束したものを、約束した品質で作るのは、当然やります。じゃあ、その上で毎週期待を超えていけるのか。よく「期待を超え続けろ」と言われますが、毎週期待を超えるのは、現実的には難しいんです。僕らが実際に売っているのは、毎週、期待を下回らない、という積み重ねのほうだと思っています。
「それって無責任じゃないか」と思われるかもしれません
仕様通りのものを、約束した品質で納める。これはシステム会社として最低限守らなくちゃいけないラインです。ここを疎かにして「毎週、期待を下回らないことを売っています」と言うなら、それはただの無責任だと思います。
誤解のないように書いておくと、この「最低限」は、簡単だという意味ではありません。仕様書通りのものを一発で作りきるのは、それはそれで大変なことです。そして、毎週期待を下回らないというのも、続けてみると、それはそれでとても大変なことなんです。
うちは、自分たちを受託の会社だとは思っていません。基本は、ラボ開発の会社です。決められた期間、決められた条件の中で、お客様が求めるものにプラスアルファを出していく。それができるかどうかに、次のプロジェクトでまた選んでもらえるかどうかがかかっている。仕事が続くかどうかも、そこにあると思っています。
発注する側から見ると、何が変わるか
もし今、システム会社を選ぶ立場にいるなら、見るところが少し変わってくるはずです。「何を作れるか」だけでなく、「毎週の定例で、何が起きているか」を見てみるのがいいと思います。
先週の課題をちゃんと拾っているか。ビジネス側の事情まで踏み込んで聞いてくるか。仕様書に書いてあることだけをやる相手なのか、それとも一歩先を提案してくる相手なのか。この違いは、契約書を読んでもわかりません。ただ、契約前でも見る手はあると思っています。初回の打ち合わせで「先週の課題を、翌週どう扱っていますか」と聞いてみる。あるいは最初は1〜2ヶ月だけ小さく発注して、定例の中身を見てから広げる。定例のない受託の会社が相手でも、課題の拾い方そのものは同じように観察できるはずです。発注する前に確認しておく体制の話は、発注側が問うべき5つの問いという記事にまとまっています。
定義し直すタイミングが来ている
Brandon氏の投稿は最後、自分たちが何の価値を提供する存在なのかを根本から定義し直すタイミングだ、という趣旨で締めくくられていました。業界の終わりを嘆く話には、していない。ここに一番グッときたんですよね。
システム会社にとっても、たぶん同じだと思います。倒産の数字が示しているのは、価格競争に依存した仕事の余地が、静かに狭まっていく、という話です。だから、毎週の定例で何が起きているかが、これまでよりずっと重くなっているんだと思います。
うちも、毎週下回らないのがやっとです。同じ業界にいる会社のみなさん、僕らもその真ん中にいます。一緒に頑張りましょう。
よくある質問
システム会社との毎週の定例では、何を見ればいいですか?
先週の課題が、今週どう扱われたかを見るのがいいと思います。議題が毎週「進捗の報告」だけで終わっているか、こちらのビジネス側の事情まで踏み込んだ質問が出てくるか。拾われなかった課題が翌週どうなったかを1つ追いかけるだけでも、その会社の仕事の仕方はかなり見えてきます。
ラボ開発と受託開発は、何が違うのですか?
受託開発は、決まった仕様のものを決まった納期で作って納める契約です。ラボ開発は、決まった期間、開発チームの時間を確保して、その中で優先順位を入れ替えながら作っていく形です。うちはラボ開発でやっていて、毎週の定例で仕様書の外の課題も拾いながら進めます。どちらが上という話ではなく、作るものが最初から固まっているなら受託のほうが向いている、というだけの話です。
発注前に、システム会社の見極めを相談できますか?
15分の壁打ちで、いま検討している会社との付き合い方や、定例で何を確認すればいいかを、発注側の立場で一緒に整理しています。うちに発注するかどうかとは切り離して使ってもらってかまいません。
「毎週の定例で、何が起きているか」を一緒に整理します
システム会社を選んでいる途中でも、いまの開発の回り方にひっかかりがある途中でも、この記事の続きを「御社の場合はどうか」という角度で話します。15分で、次の定例で確認する項目くらいは持ち帰ってもらえると思います。
15分の壁打ちを予約する → お問い合わせはこちら
東京とベトナムの二拠点で、ITオフショア開発・海外進出支援事業を展開。「気合いより仕組み」を信条に、不透明になりがちな越境ビジネスを構造化する経営者。「個人のスキル」ではなく「再現性のある品質」を組織と顧客へ提供することにコミットしています。