どうもしんざきです。曲がりくねった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光年くらい後方に置き去りにした記事を書いてしまいましたが、今年もなんとなくよろしくお願いします。
今日書きたいことはそれくらいです。
「成果を出す」オウンドメディア運営
5つのスキルと全48タスク
をプレゼント。
これからオウンドメディアをはじめる企業さま、現在運用中の企業さま全てにお役に立つ資料です。ぜひご活用ください。
資料ダウンロードページはこちら↓
https://tinect.jp/ebook/5skills48tasks/
メールアドレス宛てに資料が自動送信されます。
ティネクトの事業・サービス詳細はこちら
【プロフィール】
著者名：しんざき
SE、ケーナ奏者、キャベツ太郎ソムリエ。三児の父。
レトロゲームブログ「不倒城」を2004年に開設。以下、レトロゲーム、漫画、駄菓子、育児、ダライアス外伝などについて書き綴る日々を送る。好きな敵ボスはシャコ。
ブログ：不倒城
（Photo:Ruiwen Chua）
