IT ニュース＆コラム 2021/12/13 通巻838号 ニュース版

　ソフトウェアデザイン館 Sage Plaisir 21

￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣


■■　過剰設計は多くの製品を殺す　■■

2021年11月16日、シモン・ムニョス氏は「過剰設計は、優れた開発慣行がない場合よりも
多くの製品を殺してしまいました」という意見を Mind the Product 社のブログで公開した。

英語の Wikipedia によると「過剰設計（オーバー エンジニアリング）とは、
製品の設計または問題の解決策を精巧または複雑な方法で提供する行為」と書いてある。
ちなみに日本語の Wikipedia には過剰性能についてのみ書かれており、
複雑さについてはあまり明確に問題視されていない。
Solid Studio 社のパウエル・グロウスキー氏の定義では
「あなたが持っていない問題を解決するコードまたはデザイン」としている。

製品が複雑すぎると、バグの修正や次のバージョンを作ることが非常に困難になり、
場合によっては不可能になるだろう。

過剰設計になる1つの原因は、良い製品、良い解決策を考えるとき、
もし、こんな問題が発生したときはどうするんだ！、
他社製品と差別化するためにこの問題が発生しないから優れている！
と考える当然のことが原因だ。
しかし、実際には全く発生しないかもしれない。

（私の意見）原因は、実際には発生しないある問題が、十分に予想されやすいときだ。
発生しても少ないコストで対策がとれる場合も考えられる。
たとえば、サンプルだけで十分なのに、GoF の Facade パターンのクラスを作って、
そのドキュメントやサンプルがないという状況も複雑性が増していると考えられる。
（私の意見は以上）

エンジニアの学習曲線は、通常、次のようなパターンに従う。
1. シンプルにプログラミングする
2. オブジェクト指向プログラミングなどのパラダイムを発見し、時流に乗る
3. デザインパターンについて読み、あらゆる状況でそれらを実装する機会を探し始める
4. 不必要な複雑さに苦しんで数年後、あなたは簡単なコードを書くことに戻る

もし、不必要な複雑さという苦い経験があれば、過剰設計をしなくなるだろう。

（私の意見）苦い経験ばかりではない。オブジェクト指向のクラスや無名関数などの技術は
本当に必要なときだけ使うようになる。（私の意見は以上）

緩く定義された要件も原因になる。つまり、この問題に対して対処しなくてよいと
要件に書かれていれば、複雑性に繋がらない。

退屈も原因になる。新しいパラダイムを使ってみようとするからだ。

（私の意見）学習する時間は必要だ。学習しなければ未だに Visual Basic を使っていただろう。
しかし、新しいパラダイムは製品とは分けて実験すべきだ。
実験プロジェクトで、大いに効果が出ることについて
最低限の必要な変更内容を学んでから製品に適用するのがよい。（私の意見は以上）

たとえば、マイクロサービスベースのアーキテクチャは、過剰設計になる1つの原因だ。
単純なアプリケーションの場合、モノリシックでよい。

（私の意見）少なくとも2つ以上のサービスで共通となるサービスでなければ、
複数のマイクロサービスではなく、複数のクラスやパッケージを開発すればよい。
（私の意見は以上）

時期尚早の最適化も過剰設計です。まだユーザーがいないときに冗長設計は不要です。
適切な定義には、サービスレベル目標(SLO)やサービスレベル指標(SLI)を使った目標設定を行う。

過剰設計を防ぐ方法は、エンジニアを真の製品エンジニアに変えることだ。
ユーザーとの距離を近くすることだ。
尋ねてください。この機能は私たちの現在のユーザーの問題を解決するのに
どのように役立ちますか？今やらないとどうなりますか？ 

過剰設計を防ぐためのメンタルモデルは YAGNI, KISS, Worse is better だ。
YAGNI は、「You ain't gonna need it(そんなの必要ない)」の頭字語で、
機能は実際に必要となるまでは追加しないのがよいとする、
エクストリーム・プログラミングにおける原則だ。
KISS は、「Keep it simple stupid(シンプルで愚直にする)」の頭字語だ。
Worse is better は、オプションが少ない方が良いという意味らしい。

（私の意見）エンジニアはシステムやリスクについてユーザーや営業よりよく知っているので、
シンプルで良い、その問題は考えなくて良いと言ったところで納得しないだろう。
営業は、うまく説明できなければ、顧客や経営者が責任を取ると約束しなければ止まらない。
逆にエンジニアは気づいた問題の存在の報告まではすべきだ。（私の意見は以上）

まとめると、過剰設計はスタートアップを破壊する可能性がある、のだそうだ。

https://gigazine.net/news/20211126-overengineering/
https://www.mindtheproduct.com/overengineering-can-kill-your-product/
https://ja.wikipedia.org/wiki/過剰性能
https://en.wikipedia.org/wiki/Overengineering
https://ja.wikipedia.org/wiki/YAGNI



■■　注目ニュース 一覧　■■


◇ iPhone、Apple Watch がホテルの鍵に。まずハイアットが6カ所で導入。
https://japan.cnet.com/article/35180623/
… ドア側の鍵を取り替えられるかどうか。またコストがどれだけかかるかが普及の鍵。

◇ MSのスパコン Voyager-EUS2、世界最速トップ10に初登場。
https://japan.cnet.com/article/35179718/
… Azure から使える。

◇ Apple Podcasts の評価がわずか10日で星1.8から星4.6に急上昇。
https://gigazine.net/news/20211122-apple-podcasts-review-trust/
… 評価を求めるプロンプトは星を上げるのに有効。

◇ 指紋認証は500円あれば作れる偽指紋で簡単に突破できることを示すムービー。
https://gigazine.net/news/20211124-fingerprint-hacked-for-5-dollar/
… あと必要なのは対象の指紋が付いた物だけ。



■■　ソフトウェアデザイン館 Sage Plaisir 21　■■


ホームページ >>> http://www.sage-p.com/
メルマガ >>> http://www.mag2.com/m/0000083983.html
ブログ >>> http://blog.livedoor.jp/sage_p/
ツイッター >>> http://twitter.com/Ts_Neko
ダウンロード >>> http://www.sage-p.com/freesoft.htm
サポート掲示板 >>> http://www.sage-p.com/kg_ban09/z6037C8.cgi
東日本大震災 >>> http://www.sage-p.com/saigai.html
メール >>> ts-neko◇sage-p.com ←◇を@に変えてください
緊急メールは件名に「うどんメール」を付けてください。

このメルマガの登録・解除 - http://www.mag2.com/m/0000083983.htm