前書き
という非常に興味深い技術記事が投稿された．私は，その上で設計不要論について話したい．
１つ断っておくが，私自身は設計について肯定派の人間である．実際に，
といった記事を書いている．
しかし，社会でコードを書いている中で，**多くの場合，設計が要らなくなるのではないか．ということを思うようになった．それが，なぜか．そして，一方で設計が必要となるソフトウェアとは何か．**について書きたい．
動乱の時代と第4次ベンチャーブーム
平成も終わりに差し掛かり，令和が始まるというタイミングで1つの大事な発言があった．
日本の労働者のロールモデルの崩壊を示唆した大事件だったと感じている．いわゆる，「良い大学に入り，良い会社に入り，コツコツ生きていれば生涯は安泰である．」といったモデルが，経団連の会長により否定された．これから生きる社会人においては，「令和の日本的な労働者のロールモデル」を模索しながら生きる必要がある．非常に難しい課題を示された「動乱の時代」であると私は感じている．
そんな中で，新たな活路として注目を浴びているのが，いわゆる「ベンチャー企業」である．
引用元によると，昨今のAIブームや出版不況に伴い，大手各社がこのようなベンチャーへの出資を行っており，2017年においては，900社，2,500億円にも及ぶ投資が1年間に行われている．このように近年はベンチャーへの出資が進み，新規でビジネスを始めるにはチャンスがつかみ取りやすい時代である．
ライブラリからフレームワークへ．
私が学生時代，ゲームを良く作っていたのは2007-2008年あたりだった．その頃，よく使っていたのはSDL，DxLib，pygame等のライブラリだった．そういったゲームを，高専祭に展示して，欲しい人にはCDで焼いたり，ニコニコ技術部OFFで展示していた．今，ゲームを作るとなると，UnityやUnrealEngineで制作をし，SteamやBooth，モバイルではPlayストアやAppStoreなどで配布することになるだろう．
この10年ぐらいで大きく変わったことして，「ライブラリの責任範囲の拡大」であろう．
私がゲームを作っていた時代では，SDLは「プラットフォームを抽象化してくれるだけ」であった．そのため，ゲームの基本システムも自前で作る必要があり，タスクシステム，スクリーンの管理，素材のパッケージング．そういった細々とした部分も全部スクラッチしていた．そのため，どうしても規模が大きくなりがちで，すぐスパゲッティコードになった．そういう理由から，GoFのデザインパターンやソフトウェア設計を学ぶ．ということが多かった．しかし，現在のUnityのワークフローを見るとそうではない．GUIでクリックすればCubeが配置される．非常に簡単．入門だけなら，プログラミングの知識も不要だし，線形代数の知識も不要．わからないわからないと言いながらglPushMatrixとかを書く必要もなくなった．
このようにライブラリと呼ばれていたものが責任範囲を広げつつ，フレームワークと呼ばれるものに遷移をしてきた．そして，今まで自作していた部分が不要になり，フレームワークにちょっと追加しただけでも，そこそこ良いものが出来る時代になった．そして，それが簡単に提供できるようになった．
これは，ゲームのみにとどまらない．Webの世界もそうで，Ruby on RailsがWebアプリを簡単に作れるようにし，Herokuが無料でサービスできるようにした．最近，JavaでRest APIを作る．となると色々てんこ盛りのSpringBootが採用されるようになった．Firebaseが出現し，簡単にサーバーサイドが提供できるようになった．
ライブラリの充実により，自作していた時代に比べ，相対的にソフトウェア設計の比重が下がり，フレームワークの流儀に合わせるだけで，そこそこ多機能なサービスが作れるようになった．プログラムによるサービスの開発．そして消費者へのサービスの提供が圧倒的に簡単になり，なおかつ低コストでできるようになってきた．
設計の価値．ビジネスの価値
設計＝スタミナ仮説
http://bliki-ja.github.io/DesignStaminaHypothesis/
という記事がある．これはマーチン・ファウラーというXPの提唱者(アジャイルソフトウェア開発宣言を作った1人)の日本語訳の記事である．そこで取り上げられている図が興味深い．
縦軸は機能の数，横軸は時間を示す．
「良い設計(good design)」のソフトウェアは時間が経っても，順当に機能数を増やすことができる．
「設計無し(no design)」のソフトウェアは「良い設計」より早く成長することができる．しかし，時間が経てば成長が鈍化し，技術負債が頭をもたげてくる．
そして，設計償却線(design payoff line)という段階を超えると，設計の効果が発揮され，「良い設計」されたプロダクトは成長する．
しかし，**「多くのプロダクトは設計償却線を越えられない」**と私は思っている．
例えば，Rovioという会社がある．これはスマホアプリの最初期のゲームとして有名になった「Angry Birds」の会社である．「Angry Birds」は同社が出した52番目のゲームだった．
起業家よ、クレージーな信念を持て--育ての親が語る「Angry Birds」秘話
https://japan.cnet.com/article/35080999/
他には，LIPSというコスメアプリがある．一時期，タレントのローラがCMをしていたことが記憶に新しい．これはAppBrewという会社が運営しているが，1年で5つのサービスを作って閉じている．最初のサービスに至っては2日でクローズしている．
ヒットへの近道は「失敗すること」。 人気コスメアプリLIPSを生んだAppBrewの開発スタイル
https://www.fastgrow.jp/articles/appbrew-fukazawa-matsui
このように速く産み，多く産み，多く死なせながら多くのサービスを作っていくのが，ベンチャーにある常とう手段である．これはなぜか？というと**「ソフトウェアを作ることに意味がないから」である．「ソフトウェアでどのようなビジネスをするか」に意味を求めているため，ベンチャーのように「ビジネスが始まらない」ものに関しては，設計を大事にするより，「ビジネスが始まるか」に注力される．**
なぜ設計不要論が生まれるか．
以上の事柄をまとめると3点になる．
- ライブラリやフレームワーク．PaaSやSaaSによる高品質なサービスの容易な開発・提供が可能になった
- 多産多死により光明を見つけるビジネス開発が重要視されている
- ベンチャーブームの到来による資金調達の容易になった
これらが相互作用を起こしながら進んでおり，特に新規でサービスを作り，ビジネス開発を行う場合は，設計が重要視されない．極端な話をすると，「動けばいい」といったスタイルである．そして，ベンチャーブームにより，これらの動きが加速されるであろう．という考えである．
したがって，「設計なんて不要でしょ」についてで記述されていたように「クリーンアーキテクチャ」のような開発に根差した手法より，「ブロックチェーン」のような次のビジネスの種になるような技術に投資すべきである．といった言説も解釈ができる．
設計が必要なプロダクト
一方で設計が必要なプロダクトに関しても，議論したい．
以下の資料で2種類の人間がいることが書かれている．
ゲーム作りで「第１世代目はなぜ一線級を保ちつづけるのか？」と、そのなり方、落とし穴
https://note.mu/kaerusanu/n/n6a5de71356e8
第１世代：一人で全部やるため全てのスキルを身に着けることができ、全体感を獲得できる
第２世代：第一世代が敷いた分業化のレールの上に乗るため、高い専門性を獲得することができる
今まで，話してきた内容はどちらかというと「第１世代」的な価値観である．ノウハウも何もない状態の中で，どれだけ速く作り，ビジネスを検証できたか．ということが求められる人たちがいる．という話で，そのような人たちを後押しするようにベンチャー企業に投資が走っている．という状況である．
一方で，そうではない人たちもいる．簡単に言えば，「システムのリプレイス」「安定稼働」「機能改善」を求められる人たちだ．これは「第2世代」にあたる．企業に就職をし，既存のソフトウェアを改善．運用するためにチームに参画する形である．この場合は，ビジネスモデルがあり，それを洗練することに注力される．このようなユースケースの場合，「設計」は有用な手段である．第1世代に比べ，ビジネスによる設計の変更が少ない．そして，既存のシステムは性能が劣化していたり，コードが煩雑になっており，技術負債の返済もある．そのため，クリーンアーキテクチャやドメイン駆動開発といった開発に重きを置いた手法は役に立つと考えている．
**私がやってはいけないと思うことは，「プロダクトの立場を間違えること」である．
安定稼働が求められるシステムに対し，アジャイルの名のもとに設計をおざなりにすること．まだビジネスになるか分からないシステムに対し，極度に設計にこだわりすぎること．**である．
感想
天元突破グレンラガンの最終話，主人公シモンの台詞で
「掘った穴を通るのは、もっと相応しいヤツがいる」
というものがある．あなたが「ドリルで穴を空ける側」にいるか．それとも，「掘った穴を通る側」にいるのか．それによって，設計に対する姿勢は変わる．しかしだ．「ドリルで穴を空ける側」にいたとしても，私は設計にこだわりたい．それがやはり技術者としての仁義である．
すこし残念な話をすると，「サービスを通し，ビジネスをするには良い時代」かもしれない．一方で，「アーキテクチャを求めにくい時代」なのかもしれない．「こういうものがあったらサイコーだよね．俺が作ったぜ！」「お，それ，おれも欲しい！」という牧歌的な自然発生的ビジネスではなく，主目的としての「ビジネス」が前にあり，その実現手段として「プログラミング」がある時代．今後はビジネスモデルもガラリと変わる可能性がある．スマホになりWebも変わった．phpでhtmlを吐き出す時代から，REST APIと呼ばれjsonを返す時代になった．そんな中で，スマホのアプリのための簡単なサーバーサイドはfirebaseで足りるようになってきて，そもそもサーバーサイドエンジニアっているんだっけ？というなかなかシビアな現実も感じ始めている．2020年にはプログラミング教育の義務化も始まる．そんな中で，10年後のプログラマーが増える世界で価値が続けて生み出せるんだっけ？と．エンジニアの生存戦略も割とまじめに考えないといけない時代なのかもしれない．