SlideShare a Scribd company logo
1 of 69
大島 將義 / 黒田 樹(@i2key)
オーバーエンジニアリングって何!?
ぶくぶく膨れ上がる仕様、使われない機能、過剰品質、、、突き
詰めたら、その先に真のチームの姿があった。
#devsumi 17-a-6
#devsumiA
俺のプロダクト開発用語辞典
大島 將義 / 黒田 樹(@i2key)
https://www.youtube.com/c/俺のプロダクト開発用語辞典
さて・・・・・
(画像引用元)経済産業省委託事業 みずほ情報総研株式会社,2019年3月,「平成30年度 我が国におけるデータ駆動型
社会に係る基盤整備 (IT 人材等育成支援のための調査分析事業) - IT人材需給に関する調査 - 調査報告書 」
いろいろな立場や役割は有りますが・・・・
(画像引用元)経済産業省委託事業 みずほ情報総研株式会社,2019年3月,「平成30年度 我が国におけるデータ駆動型
社会に係る基盤整備 (IT 人材等育成支援のための調査分析事業) - IT人材需給に関する調査 - 調査報告書 」
2018年に行った2030年のシミュレーション
(画像引用元)経済産業省委託事業 みずほ情報総研株式会社,2019年3月,「平成30年度 我が国におけるデータ駆動型
社会に係る基盤整備 (IT 人材等育成支援のための調査分析事業) - IT人材需給に関する調査 - 調査報告書 」
2018年に行ったシミュレーション
高位:IPA企業アンケート調査の回答より
中位:低位と高位の中間
低位:各種調査会社の市場成長予測・実質GDPの伸び率予測より
113万人にたいして、79万人たりない
(画像引用元)経済産業省委託事業 みずほ情報総研株式会社,2019年3月,「平成30年度 我が国におけるデータ駆動型
社会に係る基盤整備 (IT 人材等育成支援のための調査分析事業) - IT人材需給に関する調査 - 調査報告書 」
11人のチームで19人分頑張る世界・・
高位?それ以上?
(画像引用元)GoogleTrends,2022/02/01参照
↓調査時期
しかし、こんなシナリオが・・
(画像引用元)経済産業省委託事業 みずほ情報総研株式会社,2019年3月,「平成30年度 我が国におけるデータ駆動型
社会に係る基盤整備 (IT 人材等育成支援のための調査分析事業) - IT人材需給に関する調査 - 調査報告書 」
生産性上昇率5.23%
(画像引用元)経済産業省委託事業 みずほ情報総研株式会社,2019年3月,「平成30年度 我が国におけるデータ駆動型
社会に係る基盤整備 (IT 人材等育成支援のための調査分析事業) - IT人材需給に関する調査 - 調査報告書 」
日本のIT、デジタルを支えるDevelopersな皆様。
色々な企業・立ち位置・役割・専門性・・の方々が居ると思いますが。
「113万人にたいして、79万人足りない」世界に挑む仲間として。
すこし、考えてみませんか?
無駄なことやってる場合じゃない。
日本の未来のために。
Over Engineering
Overengineering (or over-engineering,[1] or over-kill) is the act of designing a product or providing a solution to a problem in an overly
complicated manner, where a simpler solution can be demonstrated to exist with the same efficiency and effectiveness as that of the
original design.[2]
Overengineering differs from Planned Obsolescence which seeks to alter a design to produce an artificial limit on a product's lifespan or
otherwise make it unfashionable. Overengineering is often identified with design changes that increase a factor of safety, add functionality,
or overcome perceived design flaws that most users would accept.
Overengineering can be desirable when safety or performance is critical (e.g. in aerospace vehicles and luxury road vehicles), or when
extremely broad functionality is required (e.g. diagnostic and medical tools, power users of products), but it is generally criticized in terms of
value engineering as wasteful of resources such as materials, time and money.
wikipedia(英語版)より
オーバーエンジニアリング(またはオーバーエンジニアリング[1]、オーバーキル)とは、製品を設計したり、問題
の解決策を提供したりする際に、元の設計と同等の効率や効果を持つ、よりシンプルな解決策が存在することを証明
できるのにもかかわらず、過度に複雑な方法で設計することである[2]。
オーバーエンジニアリングは、製品の寿命を人為的に制限したり、流行遅れにしたりするために設計を変更しようと
する計画的陳腐化とは異なります。オーバーエンジニアリングは、安全率を高めたり、機能を追加したり、ほとんど
のユーザーが受け入れるであろう設計上の欠陥を克服するような設計変更と同一視されることが多い。
オーバーエンジニアリングは、安全性や性能が極めて重要な場合(航空宇宙用車両や高級ロードカーなど)や、極め
て広範な機能性が要求される場合(診断ツールや医療機器、製品のパワーユーザーなど)には望ましいが、バリュー
エンジニアリングの観点からは、材料や時間、お金などの資源を無駄にしていると一般的に批判されている。
wikipedia(英語版) → DeepLより
オーバーエンジニアリング(またはオーバーエンジニアリング[1]、オーバーキル)とは、製品を設計したり、問題
の解決策を提供したりする際に、元の設計と同等の効率や効果を持つ、よりシンプルな解決策が存在することを証明
できるのにもかかわらず、過度に複雑な方法で設計することである[2]。
オーバーエンジニアリングは、製品の寿命を人為的に制限したり、流行遅れにしたりするために設計を変更しようと
する計画的陳腐化とは異なります。オーバーエンジニアリングは、安全率を高めたり、機能を追加したり、ほとんど
のユーザーが受け入れるであろう設計上の欠陥を克服するような設計変更と同一視されることが多い。
オーバーエンジニアリングは、安全性や性能が極めて重要な場合(航空宇宙用車両や高級ロードカーなど)や、極め
て広範な機能性が要求される場合(診断ツールや医療機器、製品のパワーユーザーなど)には望ましいが、バリュー
エンジニアリングの観点からは、材料や時間、お金などの資源を無駄にしていると一般的に批判されている。
wikipedia(英語版) → DeepLより
オーバーエンジニアリングとは・・・・
本当に必要だったものに対して、何かオーバーなやりすぎが発生してしまい、全
体として当初想定していたものよりはブクブク膨れ上がる感じ。
オーバーエンジニアリング=作り過ぎて、時間や金を無駄にすること
本当に必要
だったこと
非オーバー
部分
オーバー部分
いろいろあって。
オーバーエンジニアリング=作り過ぎて、時間や金を無駄にすること
本当に必要
だったこと
非オーバー
部分
オーバー部分
いろいろあって。
要求定義 要件定義 設計 コード テスト
オーバーエンジニアリング=作り過ぎて、時間や金を無駄にすること
本当に必要
だったこと
非オーバー
部分
オーバー部分
いろいろあって。
要求定義 要件定義 設計 コード テスト
存在しないユーザを
想定して、仕様を増
やしちゃう
オーバーエンジニアリング=作り過ぎて、時間や金を無駄にすること
本当に必要
だったこと
非オーバー
部分
オーバー部分
いろいろあって。
要求定義 要件定義 設計 コード テスト
大事な気がする仕様
が問題になって、更
なる解決が必要にな
っちゃう
オーバーエンジニアリング=作り過ぎて、時間や金を無駄にすること
本当に必要
だったこと
非オーバー
部分
オーバー部分
いろいろあって。
要求定義 要件定義 設計 コード テスト
必要以上のレビュー
や文書化といったプ
ロセスを行ってしま
う
オーバーエンジニアリング=作り過ぎて、時間や金を無駄にすること
本当に必要
だったこと
非オーバー
部分
オーバー部分
いろいろあって。
要求定義 要件定義 設計 コード テスト
将来に備えようとし
て、備え過ぎちゃう
オーバーエンジニアリング=作り過ぎて、時間や金を無駄にすること
本当に必要
だったこと
非オーバー
部分
オーバー部分
いろいろあって。
要求定義 要件定義 設計 コード テスト
全体の性能ネックで
はないところが、大
事な気がして高性能
にしちゃう
オーバーエンジニアリング=作り過ぎて、時間や金を無駄にすること
本当に必要
だったこと
非オーバー
部分
オーバー部分
いろいろあって。
要求定義 要件定義 設計 コード テスト
直さなくて良いバ
グを直しちゃう
オーバーエンジニアリング=作り過ぎて、時間や金を無駄にすること
本当に必要
だったこと
非オーバー
部分
オーバー部分
いろいろあって。
要求定義 要件定義 設計 コード テスト
存在しないユーザを
想定して、仕様を増
やしちゃう
直さなくて良いバ
グを直しちゃう
大事な気がする仕様
が問題になって、更
なる解決が必要にな
っちゃう
全体の性能ネックで
はないところが、大
事な気がして高性能
にしちゃう
将来に備えようとし
て、備え過ぎちゃう
必要以上のレビュー
や文書化といったプ
ロセスを行ってしま
う
オーバーエンジニアリング=作り過ぎて、時間や金を無駄にすること
本当に必要
だったこと
非オーバー
部分
オーバー部分
いろいろあって。
要求定義 要件定義 設計 コード テスト
存在しないユーザを
想定して、仕様を増
やしちゃう
直さなくて良いバ
グを直しちゃう
大事な気がする仕様
が問題になって、更
なる解決が必要にな
っちゃう
全体の性能ネックで
はないところが、大
事な気がして高性能
にしちゃう
将来に備えようとし
て、備え過ぎちゃう
必要以上のレビュー
や文書化といったプ
ロセスを行ってしま
う
<要求>
ボタンAを押したらべ
ローンとなる
<要件>
ボタンAが押されたら、
べローンとする
<問題>
べローンとしたら、別
のボタンB隠れてしま
った。
大事な気がする仕様が問題になって、更なる解決が必要になってしまう
要件を実現することを阻む障壁。
これ、すごく解決したくなっちゃう。
<要求>
ボタンAを押したらべ
ローンとなる
<要件>
ボタンAが押されたら、
べローンとする
<問題>
べローンとしたら、別
のボタンB隠れてしま
った。
大事な気がする仕様が問題になって、更なる解決が必要になってしまう
<要求>
べローンってなっても、
ボタンBを押せるよう
したい
新たな要求が発生
<要求>
ボタンAを押したらべ
ローンとなる
<要件>
ボタンAが押されたら、
べローンとする
<問題>
べローンとしたら、別
のボタンB隠れてしま
った。
大事な気がする仕様が問題になって、更なる解決が必要になってしまう
<要求>
べローンってなっても、
ボタンBを押せるよう
したい
<要件>
べローンの時は、ボタ
ンBを右にずらす
<問題>
ボタンBが右にズレると、
画面からはみ出る。
これも、
すごく解決したくなっちゃう。
新たに要求が生まれて、・・・・
その新たな要求に対する新たな要件が生まれて、・・・・
新たな問題が発生する。
<要求>
ボタンAを押したらべ
ローンとなる
<要件>
ボタンAが押されたら、
べローンとする
<問題>
べローンとしたら、別
のボタンB隠れてしま
った。
大事な気がする仕様が問題になって、更なる解決が必要になってしまう
<要求>
べローンってなっても、
ボタンBを押せるよう
したい
<要件>
べローンの時は、ボタ
ンBを右にずらす
<問題>
ボタンBが右にズレると、
画面からはみ出る。
<要求>
ボタンBが右にずれても
画面で表示可能に
<要件>
全てのボタンサイズを
小さくして収める
<問題>
・・・・
新たな要求が発生 この地獄のような構造は続いていく・・・・。
要求→要件→問題→要求→要件→問題・・・。
もりもりやることが膨れ上がっていく構造。
<要求>
ボタンAを押したらべ
ローンとなる
<要件>
ボタンAが押されたら、
べローンとする
<問題>
べローンとしたら、別
のボタンB隠れてしま
った。
大事な気がする仕様が問題になって、更なる解決が必要になってしまう
<要求>
べローンってなっても、
ボタンBを押せるよう
したい
<要件>
べローンの時は、ボタ
ンBを右にずらす
<問題>
ボタンBが右にズレると、
画面からはみ出る。
<要求>
ボタンBが右にずれても
画面で表示可能に
<要件>
全てのボタンサイズを
小さくして収める
<問題>
・・・・
新たな要求が発生 この地獄のような構造は続いていく・・・・。
要求→要件→問題→要求→要件→問題・・・。
もりもりやることが膨れ上がっていく構造。
これを発生させないためにはどうすればよかったのだろうか???
<要求>
ボタンAを押したらべ
ローンとなる
<要件>
ボタンAが押されたら、
べローンとする
<問題>
べローンとしたら、別
のボタンB隠れてしま
った。
大事な気がする仕様が問題になって、更なる解決が必要になってしまう
<要求>
べローンってなっても、
ボタンBを押せるよう
したい
<要件>
べローンの時は、ボタ
ンBを右にずらす
<問題>
ボタンBが右にズレると、
画面からはみ出る。
<要求>
ボタンBが右にずれても
画面で表示可能に
<要件>
全てのボタンサイズを
小さくして収める
<問題>
・・・・
<要求>
ボタンAを押したらべ
ローンとなる
<要件>
ボタンAが押されたら、
べローンとする
<問題>
べローンとしたら、別
のボタンB隠れてしま
った。
大事な気がする仕様が問題になって、更なる解決が必要になってしまう
<要求>
べローンってなっても、
ボタンBを押せるよう
したい
<要件>
べローンの時は、ボタ
ンBを右にずらす
<問題>
ボタンBが右にズレると、
画面からはみ出る。
<要求>
ボタンBが右にずれても
画面で表示可能に
<要件>
全てのボタンサイズを
小さくして収める
<問題>
・・・・
「ボタンAを押したらベローン
となる。ただし、ボタンBは隠
れないようにする。」とまで定
義しなければならなかった?
起こりうる問題を事前に全て想
定しきらないとならなくなり、
なかなかの無理ゲー感はある。
影響範囲を全て把握した上での
最強の要求定義要件定義が必要
だったってこと??
・・・現実的ではない。
これはなるべくしてなるオーバーエンジニアリングなのだろうか。
「べローン」って大事なんだっけ?
ベローンを大事なこととしてしまった。
本当に必要だったこと
ホニャララ
情報を見た
い
非オーバー
部分
オーバー部分
いろいろあって。
ベローンに関する全て
ベローンって感じで、
ホニャララ情報の表示は
絶対必要!
ベローンですね。
では、ボタン押したら
ベローンとします。
ベローンの誕生
<要求>
ボタンAを押した
らべローンとなる
大事だとおもったベローンを良いものにしようと向き合う。
本当に必要だったこと
ホニャララ
情報を見た
い
非オーバー
部分
オーバー部分
いろいろあって。
ベローンの美学
ベローンに関する全て
ベローンはしなやかに
動き出し、加速し、ゆ
っくりと・・・止まる。
そういうことじゃない
か?
大事だとおもったベローンを良いものにしようと向き合う。さらに向き合う。
本当に必要だったこと
ホニャララ
情報を見た
い
非オーバー
部分
オーバー部分
いろいろあって。
ベローンの技術
ベローンに関する全て
スムーズなベローンの
実現にxライブラリを入
れるぞ!あ、ココだけ
に適用できない。全画
面で対応しないと。
大事だとおもったベローンを良いものにしようと向き合う。さらにさらに向き合う。
本当に必要だったこと
ホニャララ
情報を見た
い
非オーバー
部分
オーバー部分
いろいろあって。
ベローンによる問題
ベローンに関する全て
ベローンするとBが隠れる。
じゃ、Bを下にずらそう。 そうしたら、
Cが見切れます・・。
Xを左に、Yを右に、Zは消す
大事だとおもったベローンを良いものにしようと向き合う。全員で向き合う。
本当に必要だったこと
ホニャララ
情報を見た
い
非オーバー
部分
オーバー部分
いろいろあって。
ベローンによる混沌
ベローンに関する全て
ベローンにとって、
滑らかさは大事だ!
1年はかかり過ぎだ!
これ以上の滑らかさは無理だ!
全画面対応が
必要だから! しかたがない!
ベローンのために。
大事だとおもったベローンは、実は大事じゃなかった。
本当に必要だったこと
ホニャララ
情報を見た
い
非オーバー
部分
オーバー部分
いろいろあって。
ベローンに関する全て
1年?全画面作り直すの?
ホニャララを表示するだ
けなのに?
いや、ホニャララじゃな
くてベローンですよ。
ベローンの終焉
なに?ベローンって?
ベローンを大事なこととしてしまった。
本当に必要だったこと
ホニャララ
情報を見た
い
非オーバー
部分
オーバー部分
いろいろあって。
ベローンに関する全て
ベローンって感じで、
ホニャララ情報の表示は
絶対必要!
ベローンですね。
では、ボタン押したら
ベローンとします。
ベローンの誕生
<要求>
ボタンAを押した
らべローンとなる
本当にベローンとしたかったのかと言うとそうではなく、
何かの得たい情報がベローンと表示されていればよかったのかもしれない。
仮に「ボタンAを押したら画面上にホニャララって情報が表示される」みたいな要求で
あれば、この問題は起きなかったのかもしれない。
要求の段階で「ベローン」(HOW)を指定してしまったがために、それ以降の工程では、
「ベローン」は大事なものに見えてしまい、要求を受けた側はそれをどうしても実現せ
ねば。となってしまっているように見える。要求を出した本人は、実は、「ベローン」
にはまったくこだわりはないのに。
<要求>
ボタンAを押したらべ
ローンとなる
<要件>
ボタンAが押されたら、
べローンとする
<問題>
べローンとしたら、別
のボタンB隠れてしま
った。
大事な気がする仕様が問題になって、更なる解決が必要になってしまう
<要求>
べローンってなっても、
ボタンBを押せるよう
したい
<要件>
べローンの時は、ボタ
ンBを右にずらす
<問題>
ボタンBが右にズレると、
画面からはみ出る。
<要求>
ボタンBが右にずれても
画面で表示可能に
<要件>
全てのボタンサイズを
小さくして収める
<問題>
・・・・
要求に手段が混じってしまったが故に、その手段が重要だと思ってしまった。
最初の問題以降の 部分は全て、そんなに重要ではないベローンに向き合
ってしまったことになる。その問題を解決してもそもそも重要ではないし、意味
がないし、・・・・・つまり無駄。
要求に手段が混じっている
<要求>
ボタンAを押したらべ
ローンとなる
<要件>
ボタンAが押されたら、
べローンとする
<問題>
べローンとしたら、別
のボタンB隠れてしま
った。
大事な気がする仕様が問題になって、更なる解決が必要になってしまう
<要求>
べローンってなっても、
ボタンBを押せるよう
したい
<要件>
べローンの時は、ボタ
ンBを右にずらす
<問題>
ボタンBが右にズレると、
画面からはみ出る。
<要求>
ボタンBが右にずれても
画面で表示可能に
<要件>
全てのボタンサイズを
小さくして収める
<問題>
・・・・
じゃあ、ベローンじゃ
なくて、ペロンでよく
ね????
と言えたら・・・
以下は発生しなかった
ベローンが重要だと錯覚してしまったことが全てのはじまりなのかもしれない。
<要求>
ボタンAを押したらべ
ローンとなる
大事な気がする仕様が問題になって、更なる解決が必要になってしまう
→ベローンが重要だと錯覚してしまったことが全てのはじまりなのかもしれない。
<要求>
ボタンAを押したらべローンとなる。(けど、
ベローンは実はそんな重要じゃないです。こだ
だりは1ミリもありません。)
が となっていたら
「あ、これそんな大事じゃないだ」となり、錯覚を防げていたのかもしれない。
つまり、・・・・
本来は大事じゃないものを大事だと錯覚した結果、
作りすぎて(やりすぎて)、時間や金を無駄にしてしまう。
ということなのかもしれない。
オーバーエンジニアリング=本来は大事じゃないことを、大事だと錯覚した結果、作り過
ぎて(やりすぎて)、時間や金を無駄にすること
本当に必要
だったこと
非オーバー
部分
オーバー部分
いろいろあって。
要求定義 要件定義 設計 コード テスト
存在しないユーザを
想定して、仕様を増
やしちゃう
直さなくて良いバ
グを直しちゃう
大事な気がする仕様
が問題になって、更
なる解決が必要にな
っちゃう
全体の性能ネックで
はないところが、大
事な気がして高性能
にしちゃう
将来に備えようとし
て、備え過ぎちゃう
必要以上のレビュー
や文書化といったプ
ロセスを行ってしま
う
オーバーエンジニアリング=本来は大事じゃないことを、大事だと錯覚した結果、作り過
ぎて(やりすぎて)、時間や金を無駄にすること
本当に必要
だったこと
非オーバー
部分
オーバー部分
いろいろあって。
要求定義 要件定義 設計 コード テスト
存在しないユーザを
想定して、仕様を増
やしちゃう
直さなくて良いバ
グを直しちゃう
大事な気がする仕様
が問題になって、更
なる解決が必要にな
っちゃう
全体の性能ネックで
はないところが、大
事な気がして高性能
にしちゃう
将来に備えようとし
て、備え過ぎちゃう
必要以上のレビュー
や文書化といったプ
ロセスを行ってしま
う
大きな少数の声が、全
体であるかの様に錯覚
してしまう。
オーバーエンジニアリング=本来は大事じゃないことを、大事だと錯覚した結果、作り過
ぎて(やりすぎて)、時間や金を無駄にすること
本当に必要
だったこと
非オーバー
部分
オーバー部分
いろいろあって。
要求定義 要件定義 設計 コード テスト
存在しないユーザを
想定して、仕様を増
やしちゃう
直さなくて良いバ
グを直しちゃう
大事な気がする仕様
が問題になって、更
なる解決が必要にな
っちゃう
全体の性能ネックで
はないところが、大
事な気がして高性能
にしちゃう
将来に備えようとし
て、備え過ぎちゃう
必要以上のレビュー
や文書化といったプ
ロセスを行ってしま
う
HOWが大事であると
錯覚してしまう。
オーバーエンジニアリング=本来は大事じゃないことを、大事だと錯覚した結果、作り過
ぎて(やりすぎて)、時間や金を無駄にすること
本当に必要
だったこと
非オーバー
部分
オーバー部分
いろいろあって。
要求定義 要件定義 設計 コード テスト
存在しないユーザを
想定して、仕様を増
やしちゃう
直さなくて良いバ
グを直しちゃう
大事な気がする仕様
が問題になって、更
なる解決が必要にな
っちゃう
全体の性能ネックで
はないところが、大
事な気がして高性能
にしちゃう
将来に備えようとし
て、備え過ぎちゃう
必要以上のレビュー
や文書化といったプ
ロセスを行ってしま
う
取捨選択が重要なのに、教科書に
書いてあることは、全部やるのが
正しいと錯覚してしまう。
オーバーエンジニアリング=本来は大事じゃないことを、大事だと錯覚した結果、作り過
ぎて(やりすぎて)、時間や金を無駄にすること
本当に必要
だったこと
非オーバー
部分
オーバー部分
いろいろあって。
要求定義 要件定義 設計 コード テスト
存在しないユーザを
想定して、仕様を増
やしちゃう
直さなくて良いバ
グを直しちゃう
大事な気がする仕様
が問題になって、更
なる解決が必要にな
っちゃう
全体の性能ネックで
はないところが、大
事な気がして高性能
にしちゃう
将来に備えようとし
て、備え過ぎちゃう
必要以上のレビュー
や文書化といったプ
ロセスを行ってしま
う
数年後の状態が、明日
くらいに錯覚してしま
う。
オーバーエンジニアリング=本来は大事じゃないことを、大事だと錯覚した結果、作り過
ぎて(やりすぎて)、時間や金を無駄にすること
本当に必要
だったこと
非オーバー
部分
オーバー部分
いろいろあって。
要求定義 要件定義 設計 コード テスト
存在しないユーザを
想定して、仕様を増
やしちゃう
直さなくて良いバ
グを直しちゃう
大事な気がする仕様
が問題になって、更
なる解決が必要にな
っちゃう
全体の性能ネックで
はないところが、大
事な気がして高性能
にしちゃう
将来に備えようとし
て、備え過ぎちゃう
必要以上のレビュー
や文書化といったプ
ロセスを行ってしま
う
起こるかもしれないことは、全部
起きると錯覚してしまう。
オーバーエンジニアリング=本来は大事じゃないことを、大事だと錯覚した結果、作り過
ぎて(やりすぎて)、時間や金を無駄にすること
本当に必要
だったこと
非オーバー
部分
オーバー部分
いろいろあって。
要求定義 要件定義 設計 コード テスト
存在しないユーザを
想定して、仕様を増
やしちゃう
直さなくて良いバ
グを直しちゃう
大事な気がする仕様
が問題になって、更
なる解決が必要にな
っちゃう
全体の性能ネックで
はないところが、大
事な気がして高性能
にしちゃう
将来に備えようとし
て、備え過ぎちゃう
必要以上のレビュー
や文書化といったプ
ロセスを行ってしま
う
目の前で起こった問題
は、全部大問題と錯覚
してしまう。
オーバーエンジニアリング=本来は大事じゃないことを、大事だと錯覚した結果、作り過
ぎて(やりすぎて)、時間や金を無駄にすること
本当に必要
だったこと
非オーバー
部分
オーバー部分
いろいろあって。
要求定義 要件定義 設計 コード テスト
存在しないユーザを
想定して、仕様を増
やしちゃう
直さなくて良いバ
グを直しちゃう
大事な気がする仕様
が問題になって、更
なる解決が必要にな
っちゃう
全体の性能ネックで
はないところが、大
事な気がして高性能
にしちゃう
将来に備えようとし
て、備え過ぎちゃう
必要以上のレビュー
や文書化といったプ
ロセスを行ってしま
う
大きな少数の声が、全
体であるかの様に錯覚
してしまう。
HOWが大事であると
錯覚してしまう。
数年後の状態が、明日
くらいに錯覚してしま
う。
目の前で起こった問題
は、全部大問題と錯覚
してしまう。
取捨選択が重要なのに、教科書に
書いてあることは、全部やるのが
正しいと錯覚してしまう。
起こるかもしれないことは、全部
起きると錯覚してしまう。
大事であると 錯覚する
大事か大事ではないか明らかにする 錯覚しないようにする。
オーバーエンジニアリングが発生するメカニズムはわかった。
では、オーバーエンジニアリングしないためには・・・・・???
大事であると 錯覚する
大事か大事ではないか明らかにする 錯覚しないようにする。
オーバーエンジニアリングが発生するメカニズムはわかった。
では、オーバーエンジニアリングしないためには・・・・・???
→ 難しそう。だって人間だもの。
→ なんか、こっちは出来そう。
大事であると 錯覚する
大事か大事ではないか明らかにする 錯覚しないようにする。
オーバーエンジニアリングが発生するメカニズムはわかった。
では、オーバーエンジニアリングしないためには・・・・・???
→ 難しそう。だって人間だもの。
→ なんか、こっちは出来そう。
じゃあ、ベローンじゃ
なくて、ペロンでよく
ね????
と言えたら・・・
発生しなかった
←これ言えるかどうかぽい。
つまり、
「それ大事?」「それ必要ですか?」
「それ意味ある?」
といえること。
本当に必要
だったこと
非オーバー
部分
オーバー部分
いろいろあって。
要求定義 要件定義 設計 コード テスト
存在しないユーザを
想定して、仕様を増
やしちゃう
直さなくて良いバ
グを直しちゃう
大事な気がする仕様
が問題になって、更
なる解決が必要にな
っちゃう
全体の性能ネックで
はないところが、大
事な気がして高性能
にしちゃう
将来に備えようとし
て、備え過ぎちゃう
必要以上のレビュー
や文書化といったプ
ロセスを行ってしま
う
オーバーエンジニアリングが発生するメカニズムはわかった。
では、オーバーエンジニアリングしないためには・・・・・???
そのユーザーって
何人いるの?
具体的に、誰?
その仕様いる?
そもそも流行るかも
わからないのに、そ
んな性能いる?
別に致命的でないし、
バグったまんまでよ
くね?
まとめると。
・無駄な事、やってる場合じゃない。
・無駄な事、ついついやっちゃってる。
・大事だと、錯覚してるから。
・ほんとに、大事?と聞くしかない。
「べローン」って大事なんだっけ?
そのリファクタリングって、大事?
問うときもある。
問われる時もある。
大事な時もあるし。
そうでもない時もある。
気になるんだけど、
それって大事?
うん、大事。
これでよくない?
早い方が良いっしょ。
あ、早い方が良いね。
気になるんだけど、
それって大事?
うん、大事。
これでよくない?
早い方が良いっしょ。
あ、早い方が良いね。
異なる視点
(専門性)
共通の目的
(正義)
言い合える関係
(議論)
最良の答え
真のチーム:
共通の正義(ゴール)を持ち、
異なる視点から議論できる人達。
単なる仲良しじゃない。
というわけで・・
本日のまとめ。
2030年
79万人も足りん
無駄な事やってる
場合じゃない
無駄な事?
オーバー
エンジニアリング
大事だと錯覚したこと
錯覚から目を覚ます
目的
定義
何でも言い合える
仲間しかいない
解決
無駄なことやってる場合じゃない。
↑
これのマネ
物じゃなくて
人間模様にフォーカス
https://www.youtube.com/c/俺のプロダクト開発用語辞典
俺のプロダクト開発用語辞典
大島 將義 / 黒田 樹(@i2key)
https://www.youtube.com/c/俺のプロダクト開発用語辞典
Fin

More Related Content

What's hot

ユーザーストーリー駆動開発で行こう。
ユーザーストーリー駆動開発で行こう。ユーザーストーリー駆動開発で行こう。
ユーザーストーリー駆動開発で行こう。toshihiro ichitani
 
ビジネスパーソンのためのDX入門講座エッセンス版
ビジネスパーソンのためのDX入門講座エッセンス版ビジネスパーソンのためのDX入門講座エッセンス版
ビジネスパーソンのためのDX入門講座エッセンス版Tokoroten Nakayama
 
あなたはPO?PM?PdM?PjM?
あなたはPO?PM?PdM?PjM?あなたはPO?PM?PdM?PjM?
あなたはPO?PM?PdM?PjM?大貴 蜂須賀
 
テスト文字列に「うんこ」と入れるな
テスト文字列に「うんこ」と入れるなテスト文字列に「うんこ」と入れるな
テスト文字列に「うんこ」と入れるなKentaro Matsui
 
SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版)
SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版)SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版)
SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版)Takuto Wada
 
マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!mosa siru
 
事業成長にコミットするエンジニア組織への道のり
事業成長にコミットするエンジニア組織への道のり事業成長にコミットするエンジニア組織への道のり
事業成長にコミットするエンジニア組織への道のりRecruit Lifestyle Co., Ltd.
 
Cognitive Complexity でコードの複雑さを定量的に計測しよう
Cognitive Complexity でコードの複雑さを定量的に計測しようCognitive Complexity でコードの複雑さを定量的に計測しよう
Cognitive Complexity でコードの複雑さを定量的に計測しようShuto Suzuki
 
例外設計における大罪
例外設計における大罪例外設計における大罪
例外設計における大罪Takuto Wada
 
テストコードの DRY と DAMP
テストコードの DRY と DAMPテストコードの DRY と DAMP
テストコードの DRY と DAMPYusuke Kagata
 
マイクロサービス 4つの分割アプローチ
マイクロサービス 4つの分割アプローチマイクロサービス 4つの分割アプローチ
マイクロサービス 4つの分割アプローチ増田 亨
 
結果的に組織がAgileな状態であること #agile #scrum #leanstartup
結果的に組織がAgileな状態であること #agile #scrum #leanstartup結果的に組織がAgileな状態であること #agile #scrum #leanstartup
結果的に組織がAgileな状態であること #agile #scrum #leanstartupItsuki Kuroda
 
大企業アジャイルの勘所(ver1.1) #アジャイルマネジメントセミナー
大企業アジャイルの勘所(ver1.1) #アジャイルマネジメントセミナー大企業アジャイルの勘所(ver1.1) #アジャイルマネジメントセミナー
大企業アジャイルの勘所(ver1.1) #アジャイルマネジメントセミナーItsuki Kuroda
 
エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織Takafumi ONAKA
 
シリコンバレーの「何が」凄いのか
シリコンバレーの「何が」凄いのかシリコンバレーの「何が」凄いのか
シリコンバレーの「何が」凄いのかAtsushi Nakada
 
AWSではじめるMLOps
AWSではじめるMLOpsAWSではじめるMLOps
AWSではじめるMLOpsMariOhbuchi
 
Kubernetesによる機械学習基盤への挑戦
Kubernetesによる機械学習基盤への挑戦Kubernetesによる機械学習基盤への挑戦
Kubernetesによる機械学習基盤への挑戦Preferred Networks
 

What's hot (20)

分散トレーシング技術について(Open tracingやjaeger)
分散トレーシング技術について(Open tracingやjaeger)分散トレーシング技術について(Open tracingやjaeger)
分散トレーシング技術について(Open tracingやjaeger)
 
ユーザーストーリー駆動開発で行こう。
ユーザーストーリー駆動開発で行こう。ユーザーストーリー駆動開発で行こう。
ユーザーストーリー駆動開発で行こう。
 
ビジネスパーソンのためのDX入門講座エッセンス版
ビジネスパーソンのためのDX入門講座エッセンス版ビジネスパーソンのためのDX入門講座エッセンス版
ビジネスパーソンのためのDX入門講座エッセンス版
 
あなたはPO?PM?PdM?PjM?
あなたはPO?PM?PdM?PjM?あなたはPO?PM?PdM?PjM?
あなたはPO?PM?PdM?PjM?
 
テスト文字列に「うんこ」と入れるな
テスト文字列に「うんこ」と入れるなテスト文字列に「うんこ」と入れるな
テスト文字列に「うんこ」と入れるな
 
SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版)
SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版)SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版)
SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版)
 
WayOfNoTrouble.pptx
WayOfNoTrouble.pptxWayOfNoTrouble.pptx
WayOfNoTrouble.pptx
 
マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!
 
事業成長にコミットするエンジニア組織への道のり
事業成長にコミットするエンジニア組織への道のり事業成長にコミットするエンジニア組織への道のり
事業成長にコミットするエンジニア組織への道のり
 
Cognitive Complexity でコードの複雑さを定量的に計測しよう
Cognitive Complexity でコードの複雑さを定量的に計測しようCognitive Complexity でコードの複雑さを定量的に計測しよう
Cognitive Complexity でコードの複雑さを定量的に計測しよう
 
例外設計における大罪
例外設計における大罪例外設計における大罪
例外設計における大罪
 
テストコードの DRY と DAMP
テストコードの DRY と DAMPテストコードの DRY と DAMP
テストコードの DRY と DAMP
 
マイクロサービス 4つの分割アプローチ
マイクロサービス 4つの分割アプローチマイクロサービス 4つの分割アプローチ
マイクロサービス 4つの分割アプローチ
 
結果的に組織がAgileな状態であること #agile #scrum #leanstartup
結果的に組織がAgileな状態であること #agile #scrum #leanstartup結果的に組織がAgileな状態であること #agile #scrum #leanstartup
結果的に組織がAgileな状態であること #agile #scrum #leanstartup
 
Lean coffee
Lean coffeeLean coffee
Lean coffee
 
大企業アジャイルの勘所(ver1.1) #アジャイルマネジメントセミナー
大企業アジャイルの勘所(ver1.1) #アジャイルマネジメントセミナー大企業アジャイルの勘所(ver1.1) #アジャイルマネジメントセミナー
大企業アジャイルの勘所(ver1.1) #アジャイルマネジメントセミナー
 
エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織
 
シリコンバレーの「何が」凄いのか
シリコンバレーの「何が」凄いのかシリコンバレーの「何が」凄いのか
シリコンバレーの「何が」凄いのか
 
AWSではじめるMLOps
AWSではじめるMLOpsAWSではじめるMLOps
AWSではじめるMLOps
 
Kubernetesによる機械学習基盤への挑戦
Kubernetesによる機械学習基盤への挑戦Kubernetesによる機械学習基盤への挑戦
Kubernetesによる機械学習基盤への挑戦
 

Similar to オーバーエンジニアリングって何? #devsumi #devsumiA

デジタル時代の企業変革 2019
デジタル時代の企業変革 2019デジタル時代の企業変革 2019
デジタル時代の企業変革 2019Ikuo Misao
 
Agileツール適合化分科会(第7回)議事録
Agileツール適合化分科会(第7回)議事録Agileツール適合化分科会(第7回)議事録
Agileツール適合化分科会(第7回)議事録masanori kataoka
 
Software Frontloading and QA
Software Frontloading and QASoftware Frontloading and QA
Software Frontloading and QAYasuharu Nishi
 
Connect 2021郡山: 街づくりのためのデジタル技術 IoT – Data - AI その先に考えたいコト
Connect 2021郡山: 街づくりのためのデジタル技術 IoT – Data - AI  その先に考えたいコトConnect 2021郡山: 街づくりのためのデジタル技術 IoT – Data - AI  その先に考えたいコト
Connect 2021郡山: 街づくりのためのデジタル技術 IoT – Data - AI その先に考えたいコトDaiyu Hatakeyama
 
脆弱性スキャナVulsの紹介とMackerelメタデータと連携した脆弱性管理
脆弱性スキャナVulsの紹介とMackerelメタデータと連携した脆弱性管理脆弱性スキャナVulsの紹介とMackerelメタデータと連携した脆弱性管理
脆弱性スキャナVulsの紹介とMackerelメタデータと連携した脆弱性管理Takayuki Ushida
 
Software Engineering And Role of Agile
Software Engineering And Role of AgileSoftware Engineering And Role of Agile
Software Engineering And Role of AgileKenji Hiranabe
 
20131213 itサービスに求められる人材像
20131213 itサービスに求められる人材像20131213 itサービスに求められる人材像
20131213 itサービスに求められる人材像jun_suto
 
デジタル時代の企業変革 - 2020
デジタル時代の企業変革 - 2020デジタル時代の企業変革 - 2020
デジタル時代の企業変革 - 2020Ikuo Misao
 
屋内測位システム開発&応用:住友電工IoT研での事例
屋内測位システム開発&応用:住友電工IoT研での事例屋内測位システム開発&応用:住友電工IoT研での事例
屋内測位システム開発&応用:住友電工IoT研での事例Kurata Takeshi
 
クラウド時代のアーキテクチャ ~クラウド時代のプロダクトマネジメントとアーキテクト~ - TechFielders Architect Night
クラウド時代のアーキテクチャ ~クラウド時代のプロダクトマネジメントとアーキテクト~ - TechFielders Architect Nightクラウド時代のアーキテクチャ ~クラウド時代のプロダクトマネジメントとアーキテクト~ - TechFielders Architect Night
クラウド時代のアーキテクチャ ~クラウド時代のプロダクトマネジメントとアーキテクト~ - TechFielders Architect Night満徳 関
 
俺プロ オーバーエンジニアリング
俺プロ オーバーエンジニアリング俺プロ オーバーエンジニアリング
俺プロ オーバーエンジニアリングOre Product
 
【16-E-4】残業ゼロで開発スピードが10倍に!もう元の開発体制には戻れないデンソー流のアジャイル開発
【16-E-4】残業ゼロで開発スピードが10倍に!もう元の開発体制には戻れないデンソー流のアジャイル開発【16-E-4】残業ゼロで開発スピードが10倍に!もう元の開発体制には戻れないデンソー流のアジャイル開発
【16-E-4】残業ゼロで開発スピードが10倍に!もう元の開発体制には戻れないデンソー流のアジャイル開発Developers Summit
 
エンジニアの未来サミット for student
エンジニアの未来サミット for studentエンジニアの未来サミット for student
エンジニアの未来サミット for student真一 藤川
 
ビジネスとデザイン ~ビジネスは悪くない~
ビジネスとデザイン ~ビジネスは悪くない~ビジネスとデザイン ~ビジネスは悪くない~
ビジネスとデザイン ~ビジネスは悪くない~Ken Azuma
 
20190119triz for STEM LEADERS
20190119triz for STEM LEADERS20190119triz for STEM LEADERS
20190119triz for STEM LEADERS芳徳 高木
 
ものつくりでのAI活用 2020
ものつくりでのAI活用 2020ものつくりでのAI活用 2020
ものつくりでのAI活用 2020Ikuo Misao
 
智を集約しツラみを乗り越えたリピート推定の開発現場
智を集約しツラみを乗り越えたリピート推定の開発現場智を集約しツラみを乗り越えたリピート推定の開発現場
智を集約しツラみを乗り越えたリピート推定の開発現場Yuta Nakagawa
 
スケーラレーター: スタートアップとのオープンイノベーションに向けて
スケーラレーター: スタートアップとのオープンイノベーションに向けてスケーラレーター: スタートアップとのオープンイノベーションに向けて
スケーラレーター: スタートアップとのオープンイノベーションに向けてTakaaki Umada
 

Similar to オーバーエンジニアリングって何? #devsumi #devsumiA (20)

デジタル時代の企業変革 2019
デジタル時代の企業変革 2019デジタル時代の企業変革 2019
デジタル時代の企業変革 2019
 
Agileツール適合化分科会(第7回)議事録
Agileツール適合化分科会(第7回)議事録Agileツール適合化分科会(第7回)議事録
Agileツール適合化分科会(第7回)議事録
 
Software Frontloading and QA
Software Frontloading and QASoftware Frontloading and QA
Software Frontloading and QA
 
Connect 2021郡山: 街づくりのためのデジタル技術 IoT – Data - AI その先に考えたいコト
Connect 2021郡山: 街づくりのためのデジタル技術 IoT – Data - AI  その先に考えたいコトConnect 2021郡山: 街づくりのためのデジタル技術 IoT – Data - AI  その先に考えたいコト
Connect 2021郡山: 街づくりのためのデジタル技術 IoT – Data - AI その先に考えたいコト
 
脆弱性スキャナVulsの紹介とMackerelメタデータと連携した脆弱性管理
脆弱性スキャナVulsの紹介とMackerelメタデータと連携した脆弱性管理脆弱性スキャナVulsの紹介とMackerelメタデータと連携した脆弱性管理
脆弱性スキャナVulsの紹介とMackerelメタデータと連携した脆弱性管理
 
Software Engineering And Role of Agile
Software Engineering And Role of AgileSoftware Engineering And Role of Agile
Software Engineering And Role of Agile
 
SIAI2020
SIAI2020SIAI2020
SIAI2020
 
20131213 itサービスに求められる人材像
20131213 itサービスに求められる人材像20131213 itサービスに求められる人材像
20131213 itサービスに求められる人材像
 
デジタル時代の企業変革 - 2020
デジタル時代の企業変革 - 2020デジタル時代の企業変革 - 2020
デジタル時代の企業変革 - 2020
 
屋内測位システム開発&応用:住友電工IoT研での事例
屋内測位システム開発&応用:住友電工IoT研での事例屋内測位システム開発&応用:住友電工IoT研での事例
屋内測位システム開発&応用:住友電工IoT研での事例
 
クラウド時代のアーキテクチャ ~クラウド時代のプロダクトマネジメントとアーキテクト~ - TechFielders Architect Night
クラウド時代のアーキテクチャ ~クラウド時代のプロダクトマネジメントとアーキテクト~ - TechFielders Architect Nightクラウド時代のアーキテクチャ ~クラウド時代のプロダクトマネジメントとアーキテクト~ - TechFielders Architect Night
クラウド時代のアーキテクチャ ~クラウド時代のプロダクトマネジメントとアーキテクト~ - TechFielders Architect Night
 
俺プロ オーバーエンジニアリング
俺プロ オーバーエンジニアリング俺プロ オーバーエンジニアリング
俺プロ オーバーエンジニアリング
 
経営関連学会
経営関連学会経営関連学会
経営関連学会
 
【16-E-4】残業ゼロで開発スピードが10倍に!もう元の開発体制には戻れないデンソー流のアジャイル開発
【16-E-4】残業ゼロで開発スピードが10倍に!もう元の開発体制には戻れないデンソー流のアジャイル開発【16-E-4】残業ゼロで開発スピードが10倍に!もう元の開発体制には戻れないデンソー流のアジャイル開発
【16-E-4】残業ゼロで開発スピードが10倍に!もう元の開発体制には戻れないデンソー流のアジャイル開発
 
エンジニアの未来サミット for student
エンジニアの未来サミット for studentエンジニアの未来サミット for student
エンジニアの未来サミット for student
 
ビジネスとデザイン ~ビジネスは悪くない~
ビジネスとデザイン ~ビジネスは悪くない~ビジネスとデザイン ~ビジネスは悪くない~
ビジネスとデザイン ~ビジネスは悪くない~
 
20190119triz for STEM LEADERS
20190119triz for STEM LEADERS20190119triz for STEM LEADERS
20190119triz for STEM LEADERS
 
ものつくりでのAI活用 2020
ものつくりでのAI活用 2020ものつくりでのAI活用 2020
ものつくりでのAI活用 2020
 
智を集約しツラみを乗り越えたリピート推定の開発現場
智を集約しツラみを乗り越えたリピート推定の開発現場智を集約しツラみを乗り越えたリピート推定の開発現場
智を集約しツラみを乗り越えたリピート推定の開発現場
 
スケーラレーター: スタートアップとのオープンイノベーションに向けて
スケーラレーター: スタートアップとのオープンイノベーションに向けてスケーラレーター: スタートアップとのオープンイノベーションに向けて
スケーラレーター: スタートアップとのオープンイノベーションに向けて
 

オーバーエンジニアリングって何? #devsumi #devsumiA