どうもしんざきです。曲がりくねったSQLを読んで、モニターを威嚇しつつ不要なjoinを削除しまくる仕事で主に生計を立てています。
こんなまとめを読みました。
某大手企業の本社を辞めるという人『古い会社は社内の体制も古い。癒着してるシステム会社も全然ダメでテキストの左揃えを右揃えに変えるだけで300万取られる』（現在は非公開）
ワイの妹ト○タの本社やめて転職するらしいんだけど、「古い会社は社内の体制も古くてダメ。癒着してるシステム会社も全然ダメで、テキストの左揃えを右揃えに変えるだけで300万取られる上、バグ（仕様）だらけで仕事にならない」って言ってたの印象深い。
これ、もともとの話の情報量が全然なくって、何のシステムの話かも分からなければシステムの規模も分からないので、300万が高いのか安いのか妥当なのか、というのは勿論なんとも言えないです。
もしかするとこれはぼったくり案件なのかもしれませんし、そのシステム会社は実際に全然ダメなのかも知れません。そこについては断定出来かねるところです。
ただ、「テキストの左揃えを右揃えに変えるだけで300万取られる」という言い方については、ちょっと割り切れないものがあるというか。
私自身システムに携わる人間として、似たような文脈に結構何度も突き当たったことがあるので、ちょっと一般論をお話したくなりました。
実際のところ、wordやExcelと同じようなつもりで軽い要件を出してみたら、想像もしなかったような工数を出されてびっくり、なんだこれぼったくりかよ、みたいな話はIT業界あるあるです。ごくごく一般的な話です。
どんなシステムの話かによって多少変わってくるんですが、これは多くの場合、以下の3点のどれか、あるいは複数が原因で発生します。
1.テスト工数というものについての認識がすれ違っている
2.システムがレガシーで、何をするにも影響範囲調査等が必要になる
3.単純にシステム規模がでかすぎて工数感に根本的なミスマッチが発生している
システム業界にあまりなじみがない方の為に、簡単にご説明してみます。
1.テスト工数というものについての認識がすれ違っている
まず、一点目。テスト工数の話です。
大体において、システムを知らない人がシステム案件に触れる時、最初に食い違うのはここです。
つまり、「ちょっと変えるだけなのになんでそんな手間がかかるの？」ということです。
システム業務をやっている方であればいうまでもありませんが、それがどんなに軽微に見える案件であったとしても、「ちょっと変えるだけ」で終わることは基本的にありません。
まず第一に、そこには必ず、例外なく、「テスト」という工程が必要になります。
テストというのは読んで字のごとく、「システムの修正がうまくいったか」ということを試験することです。
「要件通りの修正が行われているか」
「なにか修正に伴うバグが発生していないか」
「修正した以外のところに余計な影響は発生していないか」
といった、様々な観点でのテストをすることになります。この「テスト」をきちんとやらないと、基本的に開発案件は終わりません。
システムというのは案外複雑なもので、外から見るだけではちょっとした変更にみえても、内部では思いもよらないところで思いもよらない箇所が絡んでいたりします。
なので、直す手間だけなら確かに「一行直すだけ」であっても、その一行を直すことによって、訳がわからないところに要らん影響が出たりすることがあるのです。
だから、工数的には「一カ所直すだけ」であっても、「影響範囲を一通りテストする」という工数は必ずセットでついてきます。これがテスト工数です。
このテスト工数は、システムの規模やシステムの構成によって大きく変わってきます。逆に言うと、それ以外の要素によってはあまり変動しません。
つまり、要件がどんなに小さくても、ほぼ一定の工数がかかる傾向があります。
勿論、テスト工数をなるべく小さくする為の工夫というものは色々とあります。
例えばテストの一部を自動化したり、システム同士の関連を整理して影響範囲を小さくすることによって、テストの範囲を小さく制限したり。
ただ、そういう工夫を実施するにもいろいろ手間はかかりますし、システムによってはそういう工夫自体を受け付けないこともありますし、そもそも「テスト」の工程自体を省くことは基本的にできないので、「なんでこれだけの案件でこんなにお金かかるんだよ」というすれ違いを完全に解決することは難しい、という話なのです。
2.システムがレガシーで、何をするにも影響範囲調査等が必要になる
二点目。影響範囲調査の話です。
上記テストの話と絡むのですが、何か開発をする際には、「これを変えることによって、どこまで影響が出るかな」ということをきちんと確認しなくてはいけません。
これをきちんと確認しないと死にます。
例えばソフトウェアで言えば、どこか一カ所のロジックを修正しただけなのに、全く関係ないところでそのロジックを使いまわしており、いきなり要らん挙動ががさっと変わったり。
例えばWebサイトで言えば、修正箇所に適用されているスタイルシートをちょっといじったら、他のページの構成がどさっと変わったり。
上記のような場合、今度は「影響を出さないように変更するためにはどうすればよいのか」という問題が発生して、思いもよらない大手術が発生して2,3人のエンジニアが死亡する、なんてことも発生しかねないわけなんです。
勿論、上記のような悲劇が発生することを防ぐためにテスト工程があるわけなんですが、システムによってはこの影響範囲がよくわからず、事前に見積の為の調査工数が必要になる、なんてことが起きたりします。
特に、
・システムの規模が大きく、かつ開発された時期が古い
・システムの開発ドキュメントがきちんと整備されておらず、属人的なノウハウがある
・開発会社が途中で変わっている
上記のような条件がそろうと地獄が見えます。いわゆる死亡フラグです。
開発手法も昔に比べれば色々と変わっておりますので、近年ではこの影響範囲を小さく抑えるための開発ノウハウというものもちゃんとあるのですが、古いシステムだとそういった開発手法が適用されていないか、適用しようにも無理ということが一般的に起こります。
度重なる追加開発、速度優先の為のドキュメント不足といったことが重なると、「どこ触ったら何が起こるのかさっぱりわからん」なんて状況が発生することもあるのです。というか割とよくあります。
で、これは開発会社が悪いのかというと一概にそういうことでもなく、「とにかく速度優先で！ドキュメント？あとでいいよ！」といったクライアントの要求があったり、あるいはそもそも開発会社や開発チームが途中で変わって引継ぎが不十分だったりといったケースが発生することもありまして、「現場かわいそうです」みたいなことになることもあるわけです。
こういうシステムの場合、「すいませんまず最初に色々調査させてください」という調査工数が発生することになるので、同じく「こんな小さな要件なのになんで！？」という費用感のミスマッチが大発生するわけです。
この調査自体けっこー大変なんですよ、これが。レガシーなシステムでありがちです。
3.単純にシステム規模がでかすぎて工数感に根本的なミスマッチが発生している
三点目。規模感の認識相違の話です。
例えば「テキストの左揃えを右揃えに変えるだけ」という案件があったとして、その手間はただ単にtext alignを一カ所leftからrightに変えるだけで終わりなのでしょうか？勿論そういう場合もあるんですが、そうでない場合も割とあります。
例えばの話、
「ここに大規模システムがあります」
「画面が300画面あります」
「部品の共通化？されてません」なんてケースの場合、そもそも「テキストの左揃えを右揃えに変えるだけ」という作業自体、同じことを300回やらなくてはいけないかも知れません。
古き良きtableタグなんかで細かくレイアウトを作りこんであるWebページだったりしたら、その1ページをレイアウト変更する為にwebデザイナーが3日徹夜するハメに、なんてことも発生するかも知れません。
こういうケースにおいて、「テキストの左揃えを右揃えに変えるだけ」と言われてしまうと、現場の開発者にストレスが200トンくらい加重されて2,3人の重傷者が出る場合があります。
こういうの、当たり前のことなんですが、使っている側にとっては「似たような画面がいくつかある、ただの業務システム」に過ぎないので、その裏でどの程度の規模のソースが動いているか、なんて全く意識しないわけなんですよ。
ただ、開発者側としては正確な手間を割り出さないわけにもいかないので、根本的な「手間の認識相違」というものが発生しかねないわけなんです。
また、システムの構成次第では、「単にリリースするだけでも一仕事」みたいな状況が発生することもありまして、こういう場合要件の規模なんて何も関係なく、リリース案件ごとに一定の工数がかかることになります。
これも、昔から使っているシステムであればあるほど、発生しがちな話だと思います。
＊＊＊＊＊
勿論、費用対効果という話は重要です。
その要件の為にそこまでの費用をかけるのか、それで効果は見合うのか、投資を回収出来るのかということは、常にきちんと検討するべき案件です。
開発費用を抑える為に様々な施策を打つことも必要でしょう。同じSI会社さんであっても、ちゃんとやってくれているのかどうか、パートナーとしてふさわしい会社なのかどうかを継続的に判断することも必要なのでしょう。
ただ、出来ることなら、そこで速攻「ぼったくり！」とか「無能SI会社！」といった言葉を投げかけることには、なるべく慎重であって頂ければなーと思うのです。
もしかすると、その費用によって守られているもの、その費用を削ったら途端に噴出しまくる問題、というものが色々とあるのかも知れません。
もしかすると、そのシステムを扱う為の価値あるノウハウ、そんなノウハウが必要とされてしまう事情、みたいなものが色々とあるのかも知れません。
そういう事情の裏で、「これだけの手間でこんな費用かかるの？」という言葉に、精神的な出血を強いられているエンジニアがいるのかも知れない。
時には、そういうことにも思いを致して頂けると、地球上の優しさ総量が増大して宇宙の平和に寄与するのではないかと。
そんな風に思うのです。
最後になりましたが明けましておめでとうございます。新年早々、新年らしさを12光年くらい後方に置き去りにした記事を書いてしまいましたが、今年もなんとなくよろしくお願いします。
今日書きたいことはそれくらいです。
【安達が東京都主催のイベントに登壇します】
ティネクト代表・安達裕哉が、“成長企業がなぜ投資を避けないのか”をテーマに東京都中小企業サイバーセキュリティ啓発事業のイベントに登壇します。借金＝仕入れという視点、そしてセキュリティやDXを“利益を生む投資”とする考え方が学べます。
こんな方におすすめ
・無借金経営を続けているが、事業成長が鈍化している
・DXやサイバーセキュリティに本腰を入れたい経営者
・「投資」が経営にどう役立つかを体系的に学びたい
＜2025年7月14日実施予定＞
投資と会社の成長を考えよう｜成長企業が“投資”を避けない理由とは
借金はコストではなく、未来への仕入れ—— 「直接利益を生まない」とされがちな分野にも、真の成長要素が潜んでいます。【セミナー内容】
1. 投資しなければ成長できない
・借金(金利)は無意味なコストではなく、仕入れである
2. 無借金経営は安全ではなく危険 機会損失と同義
・商売の基本は、「見返りのある経営資源に投資」すること
・1%の金利でお金を仕入れ、5%の利益を上げるのが成長戦略の基本
・金利を無意味なコストと考えるのは「直接利益を生まない」と誤解されているため
・同様の理由で、DXやサイバーセキュリティは後回しにされる
3. サイバーセキュリティは「利益を生む投資」である
・直接利益を生まないと誤解されがちだが、売上に貢献する要素は多数（例：広告、ブランディング）
・大企業・行政との取引には「セキュリティ対策」が必須
・リスク管理の観点からも、「保険」よりも遥かにコストパフォーマンスが良い
・経営者のマインドセットとして、投資=成長のための手段
・サイバーセキュリティ対策は攻守ともに利益を生む手段と考えよう
【登壇者紹介】
安達 裕哉（あだち・ゆうや）
ティネクト株式会社 代表取締役／ワークワンダース株式会社 代表取締役CEO
Deloitteにてコンサルティング業務に従事後、監査法人トーマツの中小企業向けコンサル部門立ち上げに参画。大阪・東京支社長を経て、2013年にティネクト株式会社を設立。
ビジネスメディア「Books&Apps」運営。2023年には生成AIコンサルティングの「ワークワンダース株式会社」も設立。
著書『頭のいい人が話す前に考えていること』（ダイヤモンド社）は累計82万部突破。2023年・2024年と2年連続で“日本一売れたビジネス書”に（トーハン／日販調べ）。
日時：
2025/7/14（月） 16:30-18:00
参加費：無料
Zoomビデオ会議（ログイン不要）を介してストリーミング配信となります。
お申込み・詳細
お申し込みはこちら東京都令和7年度中小企業サイバーセキュリティ啓発事業「経営者向け特別セミナー兼事業説明会フォーム」よりお申込みください
(2025/6/2更新）
【プロフィール】
著者名：しんざき
SE、ケーナ奏者、キャベツ太郎ソムリエ。三児の父。
レトロゲームブログ「不倒城」を2004年に開設。以下、レトロゲーム、漫画、駄菓子、育児、ダライアス外伝などについて書き綴る日々を送る。好きな敵ボスはシャコ。
ブログ：不倒城
（Photo:Ruiwen Chua）
