システム技術者が「ちょっと変えるだけでしょ？」という、ユーザーからの注文に辟易する理由。

どうも、

「単純な要件でも、システムの作りによって大きく難易度が変わる」

「システムは決して規格品ではなく、作る人によって全く出来が異なる」

ということが直感的に理解しにくいところが、色んな問題の根本原因の一つなんじゃないかなあ、という気が最近しています。

しんざきは、システム開発関連の仕事をしています。元々の専門分野はDB屋なんですが、まあ他にも色々やります。

で、当然のことながらユーザーと色々やりとりをして、仕様を固めて設計して開発して、みたいなことも何度もやっているのですが、その際何度も何度も聞いた言葉の一つに、

「ちょっと変えるだけでしょ？」

という言葉があるんです。

恐らく、システム開発に携わったことのある人であれば、何度となく聞いた言葉ではないでしょうか。

この「ちょっと変えるだけでしょ？」という言葉は一種の呪いの言葉、パワーワード・キルのようなものでして、ユーザー側と開発側の断絶を表す、一つの端的な象徴だと言っていいと思います。

いや、実際のところ間違ってはいないんですよ、この「ちょっと変えるだけでしょ？」っていう言葉。

要件的には、確かに「ちょっと変えるだけ」なんです。

・webページの文字のレイアウトを「ちょっと変えたい」

・帳票に表示されている文言を「ちょっと変えたい」

・レポートの一つの項目の数式を「ちょっと変えたい」

・自動生成しているテンプレートのヘッダを「ちょっと変えたい」

それぞれ、ユーザーにしてみれば確かに「ちょっと変えたい」だけなんだろうなあ、と思うんですよ。

それは理解出来る。「Excelだったら5秒じゃん」という言葉も、私実際に、この耳で聞いたことがあります。

ただ、システム開発をする側から見ると、「ちょっと変えるだけでしょ？」という言葉には多種多様な罠が含まれているんです。

・本当に「ちょっと変えるだけ」なのかどうかは、要件とシステムをきちんと精査してみないと分からない

・場合によっては、「ちょっと変えるだけ」なのにとんでもない工数がかかってしまうケースもある

・たとえ実際に「ちょっと変えるだけ」であっても、テスト工数を省くことは基本的に出来ない

・その為、ユーザーの規模感と実際の工数の乖離が非常に発生しやすい

・システムの作りによっては実際に小さな工数で収まる場合もある為、ユーザーが間違った学習をしやすい

・「ちょっとした変更」である為に対応に小回りを求められる場合も多く、「概算だけでもすぐ教えて」などと言われることがある

なんか書いてるだけで頭痛がしてきました。

まず第一の問題点として、「システムの作りによって、同じ修正案件でも改修の難易度や手間がまるで変わる」という点。経験則なんですが、これがどうもシステム開発に馴染みのない人にとっては凄く分かりにくいことのようなんです。

例えばの話、とある値を計算する為に使っている計算式を、ちょっと変えなくてはいけないとする。

ただの例なんですが、日次売上累計の金額について、

売上累計 = 売上単価 * 売上数量

だったところを、

売上累計 = 売上単価 * 売上数量 * 税率

に変えなくてはいけない、ということにしましょう。あくまで例なんで細かいところは勘弁してください。

これ

「システムAでは当該ロジックを一か所に集約して共通化していました」

「システムBでは、帳票ごとに計算ロジックが個別に実装されていて、同じような処理が10か所に書かれていました」

なんてことになった場合、単純に改修する手間だけでも、システムAとシステムBでは10倍違います。テスト工数を考えるともっと極端な差が開くでしょう。

問題なのは、この「システムAとシステムBの違い」というものが、実際にはもっともっともーーっと多岐に渡っていること、またこれくらいの違いはどんなシステムでも普通に起こり得ること、なんです。

ただ上の文章だけ読むと、システムBはとんでもなくまずい作り方をしているように見えるかも知れないですが、これくらいの「作り方の違い」は、ちょっと大きなシステムだったら内部でも全然普通に発生します。

システムの箇所によって開発業者が違って、それぞれ開発のレベルも違う、なんてことも珍しくもなんともありません。違うシステムであれば何をかいわんや、です。
で、この「作り方の違い」というものも、ちょっと確認すればすぐわかるようなものではないんですよね。

システムの規模次第では、ただ影響範囲を調査するだけでも一週間くらいかかったりする。

それに対して、「取り敢えず規模感だけでもすぐ出してよ」「概算でいいから見積もりしてよ」と言われても、正直「ムチャ言うな」となってしまう訳なんです。

これ、何度説明しても、ユーザー側にすごく伝わりにくいんですよ。

どうも、システムに馴染みがないユーザーは、工業製品のように「同じようなシステム・同じような機能なら中身も同じ筈」と思ってしまうようなんです。

だから、「経験的には大体どれくらいで出来そう？」なんて聞かれたりする。

同じようなシステムを過去いじっていたからといって、それと同じような規模感、同じような開発手法でうまくいく保証はどこにもないのに、それを求められたりするんです。

＊

ちょっと話は変わります。

昨年来、「システム開発側」と「ユーザー側」の意識の違い、認識の差異が、重大な問題になってそうだなーと感じるケースに何度か遭遇しています。

新元号公表、改元１カ月前＝「平成」残るケースも＝政府の連絡会議が初会合

サマータイム制度の導入について

例えば元号の変更とか、サマータイムについての話です。

それぞれ、何がどう問題になるのか、どんなところに手間がかかるかについては、色んな解説記事が出ているのでここでは繰り返しません。

ただ、一つ絶対に抑えておかなくてはならないことが、

「サマータイムにせよ元号変更にせよ、システムによって実装の方法は全く異なるし、楽な場合もとんでもなく手間がかかる場合もある」

ということです。

こういうことを決定、ないし提案する層は、恐らく「それなりに改修コストがかかる」ということまでは認識していると思います。

しかし、これは断言していいと思うんですが

「改修コストの多寡はシステムの作りによって全く、完全に異なる」

「その為、社会全体における改修コストをある程度以上の妥当さで見積もることは不可能」ということはまず認識していません。

「ちょっと変えるだけだろ」とまではもしかすると思っていないかも知れないけれど、「過去の同ケースと同じようなケース・規模間で対応できるだろ」とはかなりの確率で思っていると考えます。

でなければ、「時計をずらすだけ」なんて言葉は出てきません。

悪いことに、「システムの作りの違い」による差分というものは、時間を経れば経る程その度合いを増していきます。

昭和が平成に変わった30年前と今では、システムの規模も、その複雑性も、開発手法も、開発者のレベルの幅も、遥かに大きくなっています。

つまり、「ちょっと変えるだけ」による影響度合いというのは、昔より更に見積もり困難になっている、ということになります。
これはまた別のURLなんですが、こんな記事も観測しました。

仕事で「技術的には可能です」と言うと「可能ならやってください」と言われてしまうので誰にでも分かる表現を考えたい

これもですね、まあ伝え方は色々あると思うんですが、「〇千万かかるって一緒に言えばいいじゃん」みたいな反応をしてる人も結構いるんですね。

これも上記のような事情をご存じない方の誤解で、「どの程度の規模・工数になるか」ということすら、ある程度誠実に答えようとするならちゃんと調査をしないといけないわけです。

ぱっとその場で答えられるようなことではないんです。まあ、その場で答えを求められることも多いんですが。

確かに、上のような諸々をなるべくわかりやすくユーザーに伝えるのは、システム開発をする側の仕事の一つではあります。

ただ、ユーザーの皆様にも、出来ればこれだけは覚えておいて頂ければなーと思うんです。

繰り返しになりますが、

「一見単純な要件でも、システムの作りによって難易度は全く違う」ということ。

「そしてそれは、ぱっと調べただけですぐわかるようなことではない」ということ。

「システムは規格品でも工業品でもなく、作る人によって全然中身が違う」ということ。

恐らく、これをちゃんと認識しているかどうかで、システム部門とのコミュニケーションは飛躍的に楽になるのではないかと。そう考えるわけです。

世の中のシステム開発担当者が、建設的な仕事に日々取り組めることを願ってやみません。

今日書きたいことはそれくらいです。

【お知らせ】

Books&Apps及び20社以上のオウンドメディア運用支援で得られた知見をもとに、実際我々ティネクト（Books&Apps運営企業）が実行している全48タスクを公開します。

「成果を出す」オウンドメディア運営　 5つのスキルと全48タスク
をプレゼント。

これからオウンドメディアをはじめる企業さま、現在運用中の企業さま全てにお役に立つ資料です。ぜひご活用ください。

資料ダウンロードページはこちら↓
https://tinect.jp/library/5skills48tasks/
メールアドレス宛てに資料が自動送信されます。