Movatterモバイル変換

大島將義 / 黒田樹（@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人材需給に関する調査－調査報告書」２０１８年に行ったシミュレーション高位：IPA企業アンケート調査の回答より中位：低位と高位の中間低位：各種調査会社の市場成長予測・実質GDPの伸び率予測より

１１３万人にたいして、７９万人たりない（画像引用元）経済産業省委託事業みずほ情報総研株式会社,2019年3月,「平成30年度我が国におけるデータ駆動型社会に係る基盤整備（IT 人材等育成支援のための調査分析事業）－ IT人材需給に関する調査－調査報告書」１１人のチームで１９人分頑張る世界・・

高位？それ以上？（画像引用元）GoogleTrends,2022/02/01参照↓調査時期

しかし、こんなシナリオが・・（画像引用元）経済産業省委託事業みずほ情報総研株式会社,2019年3月,「平成30年度我が国におけるデータ駆動型社会に係る基盤整備（IT 人材等育成支援のための調査分析事業）－ IT人材需給に関する調査－調査報告書」

生産性上昇率5.23％（画像引用元）経済産業省委託事業みずほ情報総研株式会社,2019年3月,「平成30年度我が国におけるデータ駆動型社会に係る基盤整備（IT 人材等育成支援のための調査分析事業）－ IT人材需給に関する調査－調査報告書」

日本のIT、デジタルを支えるDevelopersな皆様。色々な企業・立ち位置・役割・専門性・・の方々が居ると思いますが。「１１３万人にたいして、７９万人足りない」世界に挑む仲間として。すこし、考えてみませんか？

無駄なことやってる場合じゃない。

日本の未来のために。

Overengineering (or over-engineering,[1] or over-kill) is the act of designing a product or providing a solution to a problem in an overlycomplicated manner, where a simpler solution can be demonstrated to exist with the same efficiency and effectiveness as that of theoriginal design.[2]Overengineering differs from Planned Obsolescence which seeks to alter a design to produce an artificial limit on a product's lifespan orotherwise 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 whenextremely broad functionality is required (e.g. diagnostic and medical tools, power users of products), but it is generally criticized in terms ofvalue engineering as wasteful of resources such as materials, time and money.wikipedia（英語版）より

オーバーエンジニアリング（またはオーバーエンジニアリング[1]、オーバーキル）とは、製品を設計したり、問題の解決策を提供したりする際に、元の設計と同等の効率や効果を持つ、よりシンプルな解決策が存在することを証明できるのにもかかわらず、過度に複雑な方法で設計することである[2]。オーバーエンジニアリングは、製品の寿命を人為的に制限したり、流行遅れにしたりするために設計を変更しようとする計画的陳腐化とは異なります。オーバーエンジニアリングは、安全率を高めたり、機能を追加したり、ほとんどのユーザーが受け入れるであろう設計上の欠陥を克服するような設計変更と同一視されることが多い。オーバーエンジニアリングは、安全性や性能が極めて重要な場合（航空宇宙用車両や高級ロードカーなど）や、極めて広範な機能性が要求される場合（診断ツールや医療機器、製品のパワーユーザーなど）には望ましいが、バリューエンジニアリングの観点からは、材料や時間、お金などの資源を無駄にしていると一般的に批判されている。wikipedia（英語版） → DeepLより

オーバーエンジニアリングとは・・・・本当に必要だったものに対して、何かオーバーなやりすぎが発生してしまい、全体として当初想定していたものよりはブクブク膨れ上がる感じ。

オーバーエンジニアリング＝作り過ぎて、時間や金を無駄にすること本当に必要だったこと非オーバー部分オーバー部分いろいろあって。

オーバーエンジニアリング＝作り過ぎて、時間や金を無駄にすること本当に必要だったこと非オーバー部分オーバー部分いろいろあって。要求定義要件定義設計コードテスト

オーバーエンジニアリング＝作り過ぎて、時間や金を無駄にすること本当に必要だったこと非オーバー部分オーバー部分いろいろあって。要求定義要件定義設計コードテスト存在しないユーザを想定して、仕様を増やしちゃう

オーバーエンジニアリング＝作り過ぎて、時間や金を無駄にすること本当に必要だったこと非オーバー部分オーバー部分いろいろあって。要求定義要件定義設計コードテスト大事な気がする仕様が問題になって、更なる解決が必要になっちゃう

オーバーエンジニアリング＝作り過ぎて、時間や金を無駄にすること本当に必要だったこと非オーバー部分オーバー部分いろいろあって。要求定義要件定義設計コードテスト必要以上のレビューや文書化といったプロセスを行ってしまう

オーバーエンジニアリング＝作り過ぎて、時間や金を無駄にすること本当に必要だったこと非オーバー部分オーバー部分いろいろあって。要求定義要件定義設計コードテスト将来に備えようとして、備え過ぎちゃう

オーバーエンジニアリング＝作り過ぎて、時間や金を無駄にすること本当に必要だったこと非オーバー部分オーバー部分いろいろあって。要求定義要件定義設計コードテスト全体の性能ネックではないところが、大事な気がして高性能にしちゃう

オーバーエンジニアリング＝作り過ぎて、時間や金を無駄にすること本当に必要だったこと非オーバー部分オーバー部分いろいろあって。要求定義要件定義設計コードテスト直さなくて良いバグを直しちゃう

オーバーエンジニアリング＝作り過ぎて、時間や金を無駄にすること本当に必要だったこと非オーバー部分オーバー部分いろいろあって。要求定義要件定義設計コードテスト存在しないユーザを想定して、仕様を増やしちゃう直さなくて良いバグを直しちゃう大事な気がする仕様が問題になって、更なる解決が必要になっちゃう全体の性能ネックではないところが、大事な気がして高性能にしちゃう将来に備えようとして、備え過ぎちゃう必要以上のレビューや文書化といったプロセスを行ってしまう

＜要求＞ボタンＡを押したらべローンとなる＜要件＞ボタンＡが押されたら、べローンとする＜問題＞べローンとしたら、別のボタンＢ隠れてしまった。大事な気がする仕様が問題になって、更なる解決が必要になってしまう要件を実現することを阻む障壁。これ、すごく解決したくなっちゃう。

＜要求＞ボタンＡを押したらべローンとなる＜要件＞ボタンＡが押されたら、べローンとする＜問題＞べローンとしたら、別のボタンＢ隠れてしまった。大事な気がする仕様が問題になって、更なる解決が必要になってしまう＜要求＞べローンってなっても、ボタンＢを押せるようしたい新たな要求が発生

＜要求＞ボタンＡを押したらべローンとなる＜要件＞ボタンＡが押されたら、べローンとする＜問題＞べローンとしたら、別のボタンＢ隠れてしまった。大事な気がする仕様が問題になって、更なる解決が必要になってしまう＜要求＞べローンってなっても、ボタンＢを押せるようしたい＜要件＞べローンの時は、ボタンＢを右にずらす＜問題＞ボタンBが右にズレると、画面からはみ出る。これも、すごく解決したくなっちゃう。新たに要求が生まれて、・・・・その新たな要求に対する新たな要件が生まれて、・・・・新たな問題が発生する。

＜要求＞ボタンＡを押したらべローンとなる＜要件＞ボタンＡが押されたら、べローンとする＜問題＞べローンとしたら、別のボタンＢ隠れてしまった。大事な気がする仕様が問題になって、更なる解決が必要になってしまう＜要求＞べローンってなっても、ボタンＢを押せるようしたい＜要件＞べローンの時は、ボタンＢを右にずらす＜問題＞ボタンBが右にズレると、画面からはみ出る。＜要求＞ボタンBが右にずれても画面で表示可能に＜要件＞全てのボタンサイズを小さくして収める＜問題＞・・・・新たな要求が発生この地獄のような構造は続いていく・・・・。要求→要件→問題→要求→要件→問題・・・。もりもりやることが膨れ上がっていく構造。

＜要求＞ボタンＡを押したらべローンとなる＜要件＞ボタンＡが押されたら、べローンとする＜問題＞べローンとしたら、別のボタンＢ隠れてしまった。大事な気がする仕様が問題になって、更なる解決が必要になってしまう＜要求＞べローンってなっても、ボタンＢを押せるようしたい＜要件＞べローンの時は、ボタンＢを右にずらす＜問題＞ボタンBが右にズレると、画面からはみ出る。＜要求＞ボタンBが右にずれても画面で表示可能に＜要件＞全てのボタンサイズを小さくして収める＜問題＞・・・・新たな要求が発生この地獄のような構造は続いていく・・・・。要求→要件→問題→要求→要件→問題・・・。もりもりやることが膨れ上がっていく構造。これを発生させないためにはどうすればよかったのだろうか？？？

＜要求＞ボタンＡを押したらべローンとなる＜要件＞ボタンＡが押されたら、べローンとする＜問題＞べローンとしたら、別のボタンＢ隠れてしまった。大事な気がする仕様が問題になって、更なる解決が必要になってしまう＜要求＞べローンってなっても、ボタンＢを押せるようしたい＜要件＞べローンの時は、ボタンＢを右にずらす＜問題＞ボタンBが右にズレると、画面からはみ出る。＜要求＞ボタンBが右にずれても画面で表示可能に＜要件＞全てのボタンサイズを小さくして収める＜問題＞・・・・

＜要求＞ボタンＡを押したらべローンとなる＜要件＞ボタンＡが押されたら、べローンとする＜問題＞べローンとしたら、別のボタンＢ隠れてしまった。大事な気がする仕様が問題になって、更なる解決が必要になってしまう＜要求＞べローンってなっても、ボタンＢを押せるようしたい＜要件＞べローンの時は、ボタンＢを右にずらす＜問題＞ボタンBが右にズレると、画面からはみ出る。＜要求＞ボタンBが右にずれても画面で表示可能に＜要件＞全てのボタンサイズを小さくして収める＜問題＞・・・・「ボタンAを押したらベローンとなる。ただし、ボタンBは隠れないようにする。」とまで定義しなければならなかった？起こりうる問題を事前に全て想定しきらないとならなくなり、なかなかの無理ゲー感はある。影響範囲を全て把握した上での最強の要求定義要件定義が必要だったってこと？？・・・現実的ではない。これはなるべくしてなるオーバーエンジニアリングなのだろうか。

「べローン」って大事なんだっけ？

ベローンを大事なこととしてしまった。本当に必要だったことホニャララ情報を見たい非オーバー部分オーバー部分いろいろあって。ベローンに関する全てベローンって感じで、ホニャララ情報の表示は絶対必要！ベローンですね。では、ボタン押したらベローンとします。ベローンの誕生＜要求＞ボタンＡを押したらべローンとなる

大事だとおもったベローンを良いものにしようと向き合う。本当に必要だったことホニャララ情報を見たい非オーバー部分オーバー部分いろいろあって。ベローンの美学ベローンに関する全てベローンはしなやかに動き出し、加速し、ゆっくりと・・・止まる。そういうことじゃないか？

大事だとおもったベローンを良いものにしようと向き合う。さらに向き合う。本当に必要だったことホニャララ情報を見たい非オーバー部分オーバー部分いろいろあって。ベローンの技術ベローンに関する全てスムーズなベローンの実現にxライブラリを入れるぞ！あ、ココだけに適用できない。全画面で対応しないと。

大事だとおもったベローンを良いものにしようと向き合う。さらにさらに向き合う。本当に必要だったことホニャララ情報を見たい非オーバー部分オーバー部分いろいろあって。ベローンによる問題ベローンに関する全てベローンするとBが隠れる。じゃ、Bを下にずらそう。そうしたら、Cが見切れます・・。Xを左に、Yを右に、Zは消す

大事だとおもったベローンを良いものにしようと向き合う。全員で向き合う。本当に必要だったことホニャララ情報を見たい非オーバー部分オーバー部分いろいろあって。ベローンによる混沌ベローンに関する全てベローンにとって、滑らかさは大事だ！1年はかかり過ぎだ！これ以上の滑らかさは無理だ！全画面対応が必要だから！しかたがない！ベローンのために。

大事だとおもったベローンは、実は大事じゃなかった。本当に必要だったことホニャララ情報を見たい非オーバー部分オーバー部分いろいろあって。ベローンに関する全て1年？全画面作り直すの？ホニャララを表示するだけなのに？いや、ホニャララじゃなくてベローンですよ。ベローンの終焉なに？ベローンって？

ベローンを大事なこととしてしまった。本当に必要だったことホニャララ情報を見たい非オーバー部分オーバー部分いろいろあって。ベローンに関する全てベローンって感じで、ホニャララ情報の表示は絶対必要！ベローンですね。では、ボタン押したらベローンとします。ベローンの誕生＜要求＞ボタンＡを押したらべローンとなる本当にベローンとしたかったのかと言うとそうではなく、何かの得たい情報がベローンと表示されていればよかったのかもしれない。仮に「ボタンAを押したら画面上にホニャララって情報が表示される」みたいな要求であれば、この問題は起きなかったのかもしれない。要求の段階で「ベローン」（HOW）を指定してしまったがために、それ以降の工程では、「ベローン」は大事なものに見えてしまい、要求を受けた側はそれをどうしても実現せねば。となってしまっているように見える。要求を出した本人は、実は、「ベローン」にはまったくこだわりはないのに。

＜要求＞ボタンＡを押したらべローンとなる＜要件＞ボタンＡが押されたら、べローンとする＜問題＞べローンとしたら、別のボタンＢ隠れてしまった。大事な気がする仕様が問題になって、更なる解決が必要になってしまう＜要求＞べローンってなっても、ボタンＢを押せるようしたい＜要件＞べローンの時は、ボタンＢを右にずらす＜問題＞ボタンBが右にズレると、画面からはみ出る。＜要求＞ボタンBが右にずれても画面で表示可能に＜要件＞全てのボタンサイズを小さくして収める＜問題＞・・・・要求に手段が混じってしまったが故に、その手段が重要だと思ってしまった。最初の問題以降の部分は全て、そんなに重要ではないベローンに向き合ってしまったことになる。その問題を解決してもそもそも重要ではないし、意味がないし、・・・・・つまり無駄。要求に手段が混じっている

＜要求＞ボタンＡを押したらべローンとなる＜要件＞ボタンＡが押されたら、べローンとする＜問題＞べローンとしたら、別のボタンＢ隠れてしまった。大事な気がする仕様が問題になって、更なる解決が必要になってしまう＜要求＞べローンってなっても、ボタンＢを押せるようしたい＜要件＞べローンの時は、ボタンＢを右にずらす＜問題＞ボタンBが右にズレると、画面からはみ出る。＜要求＞ボタンBが右にずれても画面で表示可能に＜要件＞全てのボタンサイズを小さくして収める＜問題＞・・・・じゃあ、ベローンじゃなくて、ペロンでよくね？？？？と言えたら・・・以下は発生しなかったベローンが重要だと錯覚してしまったことが全てのはじまりなのかもしれない。

＜要求＞ボタンＡを押したらべローンとなる大事な気がする仕様が問題になって、更なる解決が必要になってしまう→ベローンが重要だと錯覚してしまったことが全てのはじまりなのかもしれない。＜要求＞ボタンＡを押したらべローンとなる。（けど、ベローンは実はそんな重要じゃないです。こだだりは1ミリもありません。）がとなっていたら「あ、これそんな大事じゃないだ」となり、錯覚を防げていたのかもしれない。つまり、・・・・本来は大事じゃないものを大事だと錯覚した結果、作りすぎて（やりすぎて）、時間や金を無駄にしてしまう。ということなのかもしれない。

オーバーエンジニアリング＝本来は大事じゃないことを、大事だと錯覚した結果、作り過ぎて（やりすぎて）、時間や金を無駄にすること本当に必要だったこと非オーバー部分オーバー部分いろいろあって。要求定義要件定義設計コードテスト存在しないユーザを想定して、仕様を増やしちゃう直さなくて良いバグを直しちゃう大事な気がする仕様が問題になって、更なる解決が必要になっちゃう全体の性能ネックではないところが、大事な気がして高性能にしちゃう将来に備えようとして、備え過ぎちゃう必要以上のレビューや文書化といったプロセスを行ってしまう

オーバーエンジニアリング＝本来は大事じゃないことを、大事だと錯覚した結果、作り過ぎて（やりすぎて）、時間や金を無駄にすること本当に必要だったこと非オーバー部分オーバー部分いろいろあって。要求定義要件定義設計コードテスト存在しないユーザを想定して、仕様を増やしちゃう直さなくて良いバグを直しちゃう大事な気がする仕様が問題になって、更なる解決が必要になっちゃう全体の性能ネックではないところが、大事な気がして高性能にしちゃう将来に備えようとして、備え過ぎちゃう必要以上のレビューや文書化といったプロセスを行ってしまう大きな少数の声が、全体であるかの様に錯覚してしまう。

オーバーエンジニアリング＝本来は大事じゃないことを、大事だと錯覚した結果、作り過ぎて（やりすぎて）、時間や金を無駄にすること本当に必要だったこと非オーバー部分オーバー部分いろいろあって。要求定義要件定義設計コードテスト存在しないユーザを想定して、仕様を増やしちゃう直さなくて良いバグを直しちゃう大事な気がする仕様が問題になって、更なる解決が必要になっちゃう全体の性能ネックではないところが、大事な気がして高性能にしちゃう将来に備えようとして、備え過ぎちゃう必要以上のレビューや文書化といったプロセスを行ってしまうＨＯＷが大事であると錯覚してしまう。

オーバーエンジニアリング＝本来は大事じゃないことを、大事だと錯覚した結果、作り過ぎて（やりすぎて）、時間や金を無駄にすること本当に必要だったこと非オーバー部分オーバー部分いろいろあって。要求定義要件定義設計コードテスト存在しないユーザを想定して、仕様を増やしちゃう直さなくて良いバグを直しちゃう大事な気がする仕様が問題になって、更なる解決が必要になっちゃう全体の性能ネックではないところが、大事な気がして高性能にしちゃう将来に備えようとして、備え過ぎちゃう必要以上のレビューや文書化といったプロセスを行ってしまう取捨選択が重要なのに、教科書に書いてあることは、全部やるのが正しいと錯覚してしまう。

オーバーエンジニアリング＝本来は大事じゃないことを、大事だと錯覚した結果、作り過ぎて（やりすぎて）、時間や金を無駄にすること本当に必要だったこと非オーバー部分オーバー部分いろいろあって。要求定義要件定義設計コードテスト存在しないユーザを想定して、仕様を増やしちゃう直さなくて良いバグを直しちゃう大事な気がする仕様が問題になって、更なる解決が必要になっちゃう全体の性能ネックではないところが、大事な気がして高性能にしちゃう将来に備えようとして、備え過ぎちゃう必要以上のレビューや文書化といったプロセスを行ってしまう数年後の状態が、明日くらいに錯覚してしまう。

オーバーエンジニアリング＝本来は大事じゃないことを、大事だと錯覚した結果、作り過ぎて（やりすぎて）、時間や金を無駄にすること本当に必要だったこと非オーバー部分オーバー部分いろいろあって。要求定義要件定義設計コードテスト存在しないユーザを想定して、仕様を増やしちゃう直さなくて良いバグを直しちゃう大事な気がする仕様が問題になって、更なる解決が必要になっちゃう全体の性能ネックではないところが、大事な気がして高性能にしちゃう将来に備えようとして、備え過ぎちゃう必要以上のレビューや文書化といったプロセスを行ってしまう起こるかもしれないことは、全部起きると錯覚してしまう。

オーバーエンジニアリング＝本来は大事じゃないことを、大事だと錯覚した結果、作り過ぎて（やりすぎて）、時間や金を無駄にすること本当に必要だったこと非オーバー部分オーバー部分いろいろあって。要求定義要件定義設計コードテスト存在しないユーザを想定して、仕様を増やしちゃう直さなくて良いバグを直しちゃう大事な気がする仕様が問題になって、更なる解決が必要になっちゃう全体の性能ネックではないところが、大事な気がして高性能にしちゃう将来に備えようとして、備え過ぎちゃう必要以上のレビューや文書化といったプロセスを行ってしまう目の前で起こった問題は、全部大問題と錯覚してしまう。

オーバーエンジニアリング＝本来は大事じゃないことを、大事だと錯覚した結果、作り過ぎて（やりすぎて）、時間や金を無駄にすること本当に必要だったこと非オーバー部分オーバー部分いろいろあって。要求定義要件定義設計コードテスト存在しないユーザを想定して、仕様を増やしちゃう直さなくて良いバグを直しちゃう大事な気がする仕様が問題になって、更なる解決が必要になっちゃう全体の性能ネックではないところが、大事な気がして高性能にしちゃう将来に備えようとして、備え過ぎちゃう必要以上のレビューや文書化といったプロセスを行ってしまう大きな少数の声が、全体であるかの様に錯覚してしまう。ＨＯＷが大事であると錯覚してしまう。数年後の状態が、明日くらいに錯覚してしまう。目の前で起こった問題は、全部大問題と錯覚してしまう。取捨選択が重要なのに、教科書に書いてあることは、全部やるのが正しいと錯覚してしまう。起こるかもしれないことは、全部起きると錯覚してしまう。

大事であると錯覚する大事か大事ではないか明らかにする錯覚しないようにする。オーバーエンジニアリングが発生するメカニズムはわかった。では、オーバーエンジニアリングしないためには・・・・・？？？

大事であると錯覚する大事か大事ではないか明らかにする錯覚しないようにする。オーバーエンジニアリングが発生するメカニズムはわかった。では、オーバーエンジニアリングしないためには・・・・・？？？→ 難しそう。だって人間だもの。→ なんか、こっちは出来そう。

大事であると錯覚する大事か大事ではないか明らかにする錯覚しないようにする。オーバーエンジニアリングが発生するメカニズムはわかった。では、オーバーエンジニアリングしないためには・・・・・？？？→ 難しそう。だって人間だもの。→ なんか、こっちは出来そう。じゃあ、ベローンじゃなくて、ペロンでよくね？？？？と言えたら・・・発生しなかった←これ言えるかどうかぽい。つまり、「それ大事？」「それ必要ですか？」「それ意味ある？」といえること。

本当に必要だったこと非オーバー部分オーバー部分いろいろあって。要求定義要件定義設計コードテスト存在しないユーザを想定して、仕様を増やしちゃう直さなくて良いバグを直しちゃう大事な気がする仕様が問題になって、更なる解決が必要になっちゃう全体の性能ネックではないところが、大事な気がして高性能にしちゃう将来に備えようとして、備え過ぎちゃう必要以上のレビューや文書化といったプロセスを行ってしまうオーバーエンジニアリングが発生するメカニズムはわかった。では、オーバーエンジニアリングしないためには・・・・・？？？そのユーザーって何人いるの？具体的に、誰？その仕様いる？そもそも流行るかもわからないのに、そんな性能いる？別に致命的でないし、バグったまんまでよくね？

まとめると。・無駄な事、やってる場合じゃない。・無駄な事、ついついやっちゃってる。・大事だと、錯覚してるから。・ほんとに、大事？と聞くしかない。

そのリファクタリングって、大事？

問うときもある。問われる時もある。大事な時もあるし。そうでもない時もある。

気になるんだけど、それって大事？うん、大事。これでよくない？早い方が良いっしょ。あ、早い方が良いね。

気になるんだけど、それって大事？うん、大事。これでよくない？早い方が良いっしょ。あ、早い方が良いね。異なる視点（専門性）共通の目的（正義）言い合える関係（議論）最良の答え

真のチーム：共通の正義（ゴール）を持ち、異なる視点から議論できる人達。単なる仲良しじゃない。

本日のまとめ。２０３０年７９万人も足りん無駄な事やってる場合じゃない無駄な事？オーバーエンジニアリング大事だと錯覚したこと錯覚から目を覚ます目的定義何でも言い合える仲間しかいない解決

無駄なことやってる場合じゃない。↑これのマネ物じゃなくて人間模様にフォーカスhttps://www.youtube.com/c/俺のプロダクト開発用語辞典

Movatterモバイル変換

Change Language

オーバーエンジニアリングって何？ #devsumi #devsumiA

Embed presentation

Recommended

More Related Content

What's hot

Similar to オーバーエンジニアリングって何？ #devsumi #devsumiA

オーバーエンジニアリングって何？ #devsumi #devsumiA