65
40

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

欠陥住宅から考えるシステム開発

Posted at

はじめに

仕事で疲れた休日の昼下がり、ベッドに横になったままダラダラとYouTubeをみていると、たまたま下の動画に出くわしました。

20分超えの動画なんて普段は全く見ないのですが、内容がどことなく他人事に思えず、気がつくと全て見終わっていました。
それはきっと、将来一生に一度の買い物である家の購入時に気をつけるべきであることであると同時に、自らが身を置くIT業界にも共通している問題がたくさんあったからなのだと思います。

執筆の経緯

建築とシステム開発における一番大きな違いは、”高さ”や”幅”といった直感的な指標で規模感を測れるかどうかだと私は考えています。

建築)

実物が高さや幅といった指標でわかり、さらに触れることが可能なため、規模感がわかりやすい

システム開発)

実物がディスプレイという平面上でしか把握できず、触れることもできないため、規模感がわかりにくい

結果として、システム開発は建築と同じくらい多額の費用が掛かるにも関わらず、適当な見積もりや仕様、実装が生み出される危険性をはらんでいます。
(家を建てるときに「ここの壁、いい感じによろしく!😇」などと依頼する人はあまりいないと思います。手抜き工事はよくありますが、、、。)

そのため、システム開発と共通項の多く、かつ直感的理解度の高い建築を通じて、システム開発に潜む問題点の理解度を深めることができれば、と思い今回執筆に至りました。

image.png

動画の概要

※文字で読むよりも実際に視聴することをお勧めします。
(なお本動画はテレビからの転載ではないようなので、視聴するのはモラル的にも問題ないと思われます。念の為。)

・施主は某大学の有名教授に新築住宅の建築を依頼した。
・建築中から問題が多発し、追加工事とその費用が発生した。
・途中で裁判に発展。結果は勝訴したものの、賠償金が少ないため実質的には敗訴。
・(多額の費用をかけたであろう)結果出来上がった家は、住むに耐えない代物である。
・しかし、その家に住み続けなくてはならない(この方は10年以上住んでいるとのこと)。

欠陥の内容とシステム開発との対比

以下が本動画における問題点と、システム開発との対比例です。
システム開発に関する記述は必ずしも最適な例ではないかもしれませんが、ご容赦ください。
以下では
建築→ 建)
システム開発→ シ)
とします。

2:22~
建)ガラス張りの部屋に窓が全くなくて暑いので、追加工事を行い窓を作った。
シ)システムの使い勝手が悪いので、追加開発を行い機能改善した。
→ 設計時の考慮不足で追加開発が必要になる可能性があります。なお、場当たり的な対応を繰り返すと、数年後に中身がぐちゃぐちゃのシステムになってしまう危険性があります。

2:44~
建)居住性が全くなく、見た目だけに注力している。
シ)ユーザビリティが低く、デザインだけ考慮されている。
→ システム開発ではさすがにこのケースはあまり無いような気がしますが、一応書きました。

3:09~
建)窓ガラスのサッシに本来はあるべき止水ゴムがないため、雨漏り&カビが発生。
シ)本来あるべきバリデーションを実装していないため、不適切データが入力可能&エラー発生。
→ 想定外のデータが処理されると思わぬ結果を招くこともあるため、その混入を防ぐことが重要です。

4:07~
建)大雨の際、排水口が雨を処理しきれず、玄関にまで流れ込んでくる。
シ)本番リリース後、実運用でのアクセスを処理しきれず、エラーが発生する。
→ 本番を想定した負荷テストを実施することが重要です。

4:40~
建)建築士が排水能力を考えていなかった。
シ)エンジニアがサーバースペックを考慮できていなかった。
→ 4:07~ の問題と似ていますが、本番の負荷を考慮した十分なスペックのサーバーを用意する必要があります。

4:47~
建)住み始めた年から中庭に水が溢れていた。
シ)リリースした年からバグが発生している。
→ 建物が数年経ってから劣化し問題が発生するのに対して、システムはリリース初期はバグが出て、徐々に発生しなくなるものです。ですが、リリースした年であっても致命的なバグの発生は避けたいですね、、、。

5:01
建)追加料金で床の工事を行い、床の高さを下げた。
シ)追加でシステム改修を行い、応急処置を行なった。
→ 2:22~ と同じく、設計時に仕様を十分に考慮することが重要です。

5:15
建)正しい水回りのことを全く知らないとしか言いようがない。
シ)正しい実装の方法を全く知らないとしか言いようがない。
→ グサッとくる一言ですね、、、。こんなことを言われた日には1週間はメンタルが病むでしょう。

7:10
建)笠木を外すと、中は雨水で錆切っていた。
シ)ソースコードを確認すると、中はク○コードで溢れかえっていた。
→ 将来的な保守性まで考慮してコードを書かなければ、後々の担当の人が苦労します。

8:55~
建)管がつまることを避けるため、普通は家の外にすぐに出す排水管を、見た目にこだわって配管を家の中に収めた。その結果、雨漏りが発生し、追加工事で排水管を外に出した。
シ)独特な仕様を追求した結果、後々になってバグが発生し、追加改修で一般的な仕様に変更した。
→ 無理な開発を行ってなんでもかんでもシステムで実現するのではなく、時には運用をシステムに合わせることも重要です。

9:55~
建)エレベーター下にも水が溜まり、使用不可能な状態が続いた。
シ)致命的なバグにより、リリース後も使用不可能な状態が続いた。
→ 多額の費用をかけて開発した機能も、使えないのでは意味がありません。

10:15~
建)コンクリートの蓄熱により、夏は暑く、冬は寒い(コンクリートは好きな形になるため、建築士が好んで使用した)。
シ)独特なこだわりがあるコードが原因でバグが発生。
→ オリジナリティを追求するのではなく、他のエンジニアのことも考えて可読性・保守性の高いコードを書くことが重要です。

13:20~
建)階段の手すりに転落防止用のバーがない。
シ)適切なバリデーション、セキュリティ対策を実装していない。
→ システムが使えなくなるにとどまらず、重大なセキュリティインシデントに発展する危険性があります。

15:09~
建)建築士、施工会社のレベルの低さ。
シ)ベンダーのスキルの低さ。
→ こんなことを言われないためにも、エンジニアとして日々スキルアップすることが重要です(自戒)。

15:58~
建)建築中は追加工事が続出(予算は約5000万円も増加)。
シ)開発中に追加開発が続出。(予算はxxxx万円も増加)。
→ ベンダー任せにしないで、ユーザー側も初期見積もりを精査することが重要です。

16:14
建)施主は建築費の支払いを拒否→裁判に発展。
シ)ユーザーから損害賠償請求→裁判に発展。
→ 有名な裁判事例だとこの辺りでしょうか。
・IBMに74億円の賠償命令、スルガ銀裁判の深層
・システム開発の失敗を巡り裁判に至るまで、旭川医大とNTT東の2010年
・野村-IBM裁判でユーザー側が逆転敗訴、「あの裁判」との無視できない共通点
必ずしもユーザー側が勝つわけではないのがポイントです。ユーザーはお金を払っているからといって、無茶な要求ばかりしていいわけではありません。

17:33~
建)それでも、この家に住み続けなくてはいけない。
シ)それでも、このシステムを使い続けなくてはならない。
→ システム開発は決して安い投資ではありません。ちょっと使いづらいからといってすぐ買い替えというわけにはいかないでしょう。

18:25
建)設計を頼む段階、施工会社を頼む段階で十二分な配慮が必要。
シ)ベンダー選定の時点で十二分な配慮が必要。
→ 有名なベンダーだからといって即決するのではなく、スピード感を失わない程度に(👈ここ重要)慎重に検討することが大事です。

18:35
建)建築士には、デザイン専門の建築士と設備設計専門の2つの種類の建築士がいるが、この建築士は(デザイン専門にも関わらず)全て自分で担当した。
シ)デザイナーとエンジニアの2つの種類があるが、デザイナーが全て担当した。
→ システム開発においてこのパターンはほぼないと思います。ですが、逆のパターン(エンジニアがデザインも担当)はあるように思いますので、もしUIに強いこだわりがあるのであれば、デザイナーさんを雇う必要があります。

19:04
建)デザインと設備設計の両方の体制が十分か、チェックする必要がある。
シ)ベンダーの体制が十分か、チェックする必要がある。
→ 繰り返しになりますが、全てベンダー任せにしてはいけません。ユーザー側にもプロジェクト体制が十分かチェックする責任があります。

20:53
建)時間がなかったのが今思えば悔やまれる。もう少し時間をとって建築の勉強をして、分からないところを解消すべきであった。建築について知らないと設計者・施工会社の勝手になってしまう。
シ)開発に十分な時間をとるべきである。ユーザー側もITの勉強をして、システム開発を理解すべき。システム開発について知らないと、ベンダーの勝手になってしまう。
→ バッファを設けて余裕のあるスケジュールで開発を行いましょう。また、本業が別にありITが専門ではないユーザーも多いかと思いますが、専門でないからといってベンダーに任せるのではなく、多少なりともシステム開発というものを理解することが重要です。

おわりに

大事なことはざっくり以下の2点です。
・ユーザー側はベンダーに丸投げにするのではなく、システム開発とは何たるかを勉強し、理解する。
・ベンダー・エンジニアはITのプロフェッショナルとして恥じない仕事をする

システム開発の経験が浅く慣れていない人は、各作業やバグの影響度がわかりにくいかもしれませんが、上記のように建築における問題に置き換えて考えてみると、理解度が高まっていいかもしれません。

65
40
1

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
65
40

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?