完成した家の設計書と実際の家が全然違ったらどう思いますか?

IT業界の闇
この記事は約4分で読めます。
イザベラ
イザベラ

あれ~ここどんな仕様だったけな、設計書見てみよっと!

ふぃる
ふぃる

待って、その設計書信用出来なから実際に動かして確認して!

イザベラ
イザベラ

ええ??設計書通りに作ったんだよね?

ふぃる
ふぃる

建前はね…。

スポンサーリンク

さて、システムを作るときは、設計書とプラグラミングはセットになります。

しかし、これらの内容が全然違うことがざらにあるのです。

理由は「うっかり」と「怠慢」です。


今回はこのあってはいけない「うっかり」と「怠慢」についてお話します。

設計とプログラムが違うことをほかのことで例えてみます。

料理で例える

友人が作ったとても美味しい料理があったとします。

作り方を聞くと、レシピ通りに作っただけなのでこの通りに作れば良いだけと言われてレシピを渡されました。

あなたはワクワクして、レシピに忠実に料理を作りました。

いざ、試食。


…なんだか味が違います。かなりの薄味で味気ないし、香りも全然違います。


友人にこのことを話してみると、


「ごめんごめん、塩大さじ1じゃなくて3に変えたんだった。あとサラダ油じゃなくてごま油に替えたんだよね~、レシピ直してなかったわ

実際の調理をレシピから変えてるならレシピも修正してほしいところですよね。

車で例える

車を作る技術者が設計書通りに車を組み立てていきます。

ところが実は設計書に間違いがあったことが発覚します。


このまま作ると、大事故を起こす危険性がある欠陥へつながります。

でもそこはさすがプロ。設計書のミスにしっかり気付いて、欠陥のない車を製造しました。


しかし、本当は設計書も直すべきですが、「車が動くことが一番大事」であることから後回しにして、そのまま忘れてしまいました。


その結果、設計書と実際の車が異なることによって、後から見た人がどっちが正しいのかわからない状態になってしまいました。




家で例える

大工さんが建築士の設計書を見ながらその通りに家をつくります。

その設計にあなたも納得した上で建築を依頼しています。

しかし、ある大工が思い付きで勝手なことをしてしまいます。


「ここ、納戸あったほうがいいよね、納戸作ってあげよう」



気づけばリビングが、縮小されて納戸がある家になっていました。

あなたはそんな注文した覚えないので、慌てて設計書を確認します。もちろん納戸を作る予定には全くなっていません。

現場の判断で勝手に予定と違うことをされてしまったのです。


設計書通りに作ってくれないってひどいですよね。



システム開発でも当たり前にある

レシピの話はよくありそうな話ですね。

「うっかり忘れてた」です。


車の話も、ありえなくはない話ですね。

「怠慢で後回しにしていたらうっかり忘れてた」です。



家の話はありえないですよね。

「現場で良かれと思って勝手な判断で変更した」です。




うっかり忘れてた。

面倒だから後で。

最初から設計書通りにしない。



システム開発の現場ではどれもありえます。

というか日常茶飯事です。

軽視されがちな設計書

確かにいちいち設計書を直すことって面倒なんです。


プログラミングしている最中に設計書の漏れや誤りに気付くことはよくあることです。

でも、動くものが第一、納期に間に合わせることが第一と考えているエンジニアが非常に多いため、設計書の修正はないがしろにされます。



後でまとめて直そう、とりあえずプログラムを完成させて。そんな指示は当たり前です。


問題は、後で第3者が見た時に設計書とプログラムのどちらが正しいかわからないことです。

ここの調査や判断にも時間がかかり、無駄なコストが発生します。


設計書の逆起こし

こんな言葉があります。

「設計書の逆起こし」

どういうことでしょうか?

それは、設計書をかかずにプログラミングをして、完成した後にプログラムを見ながら設計書を書くことです。


なんかもう設計書の目的を逸脱してますよね。

納品する必要があるから設計書は書くけど、動くモノが大事だから先にプログラミングして設計書は形だけ後から作る


ありえないようでめちゃくちゃよくあることなのです。



エンジニアのたどり着く思考とは

そんなエンジニアがたどり着く思考回路は



「設計書っていらないじゃん」


です。


プログラムを見れば中身はわかるのだからプログラムが設計書みたいなものである。


という考え方です。



ここは度々エンジニアの中でも論争が結構あったりします。


お客様の気持ち

高い費用を出してシステム開発を依頼するお客様からすれば、自社の業務に直結、つまり利益にも影響があるのがシステム開発です。

もっとちゃんと練って、開発してくれ!と思うでしょう。



でもほとんどのエンジニアは

「お客様のことなんて考えていない」


のが現実です。


多重下請け構造の闇のせいですね。

以下の記事でも説明しています。

ーーーーーーーーーーー
いかがでしたでしょうか?

これが、現実です。

スペシャリストが集まったプロフェッショナル集団のイメージのITエンジニアはこんなものなのです。

以上、最後までご覧いただきありがとうございました。


タイトルとURLをコピーしました