色々と「むつかしいなぁ」と思ったエントリ、が、元ネタ。
スタートアップに向く人、向かない人（エンジニア編）
https://note.mu/etomiho/n/nd3b3c62bac22
正直「どっちの言い分もわかるなぁ」というのがあるので、おいちゃん的見解をざっくりと。
最終的な落としどころは
https://twitter.com/gallu/status/831398322946453505
おいちゃん的には「設計は"隙間があって隙のない"設計を、ある程度丁寧に」「実装は、いらん部分を切り捨てつつ、必要に応じて雑にスピーディーに」かなぁ。 実装が雑でよいのは「後で容易に修正出来るから」だし、容易に修正出来るように組むから。
なんだけど。
そこに至るまでの考察などを、ちょいと、つらつらと。
その段階では、完璧なものを作るより「とにかく速く世の中に出す」ということが最優先される。
しかし夫は、これまでに何度かそうやって「スタートアップ時に雑に作られたシステム」のせいでひどい目にあってきており、いわば「穴のあいた壺」の穴を埋める仕事をずっとやってきていた。
うんまぁこの時点ですでに「どちらも理解できる」上に、基本的に「埋めにくいレベルで深い溝がある」事もわかる。
旦那さんのまずい所はおそらく
彼が最初から「穴のない壺」を作りたいと思う
ってあたり。
ただ
「穴があいていてもいいから速く壺を作ってくれ」
は、穴の「箇所とレベルと深度と質と種類」に依る、かなぁ。
新しい機能を実装しようと依頼したときの第一声が「拒否（防御）」のスタンスから入られることが多い
については。
正直「エンジニア側の気持ちがよくわかる」のと、だからこそ「信頼関係をしっかりと構築する」事の重要性が、この辺は、もっと声高に叫ばれてもいいんじゃなかろうかなぁ、って思う。
現実問題として「防御が必要な案件」も多いですし、「防御が必要な案件で防御せずに死ぬほど痛い目にあっている」ケースも散見されるので、「防御するな」とは、口が裂けてもいえる状況ではないので。
そして、「どのくらいかかりますか？」と作業工数の見積もりを依頼したときの返答が、やたら渋い（日数が長い）。これはおそらくなのだが、受託のときの癖で「とにかく納期には絶対遅れてはいけない」という思いから、万が一に備えて長めの見積もりを出すようにしているのではないかと思う。
これについても。
一番初め…ではないのかもしれないけど、先頭付近にやるべき一つは「技術者との信頼関係を構築して、安心を与える事」だと思う。
ナウシカが経営者(マネージャ)、キツネリス「テト」が技術者、って言うと、少し伝わるのかしらん？ｗ
で。
そんな中で、私たちのような年長者が若者に打ち勝っていくには、いかに転んだときの「痛みの記憶」を忘れ去るか、にあるような気がしている。でなければ、全速力で走ることができない。
ん……これは違うと思う。
これだと、結局「手痛くすっころぶ」前提での体力勝負、にしかならないし。
「転ぶな」は難しいのかもしれないけど。「ダメージの少ない転び方」とか「受け身の取り方」くらいは、把握しておいたほうがいいと思う。
で。
それなりの炎上案件をやっぱり潜り抜けたおいちゃんが、現時点でお勧めするのが
・設計は"隙間があって隙のない"設計( http://d.hatena.ne.jp/gallu/20100506/p1 )を、ある程度丁寧に
・実装は、いらん部分を切り捨てつつ、必要に応じて雑にスピーディーに
って方針。
設計で「隙間のないガチガチの設計」すると、後での改修が難しいので、そうするとどうしても「水も漏らさぬ穴のない壺」になる…んだけど、そもそもスタートアップ(に限らずビジネス全般)は「ある程度の(高)頻度で流転していく」ものなので、そもそも「ガチガチに組んだ」ら、組んだ瞬間から時代遅れになってしまいます。
また、逆に「設計が隙だらけ穴だらけ」だと。「建物立てた後に基礎工事やりなおします？」ってお話になって、シャレにならん工数がかかるうえにそのかかる工数って基本的に「全くお金を生まない」ので、経営的に大変にシビアな選択となります。
翻って。
実装を「一端雑に」するのは、雑にする箇所と雑レベルにもよるのですが…「きれいなコード」ってのは本来的に「後でいかようにも修正が出来る」ような作りになるので、「とりあえず雑に、後で手直し」って方法が出来るので。
「きれいで雑に組む」と、割合と「スタートアップ向き」のコードになりやすいんじゃないかなぁ、と思うのです。
この方法だと、まぁ「雑に組んだコードを捨てる可能性」はあるにしても、「短時間で組んだコード」なら「早期にチャンスをつかむための捨てコスト」ってみなしても、まぁ、許容できるんじゃないかなぁ、と思うです。
この辺は本当に「さじ加減」なので。
「全部雑」だと、だれかが尻拭いをする…か、サービスが終了します( http://appmarketinglabo.net/kinokore/ とか、当人たちには申し訳ないのですが、好例だと思われます)。
ちなみに「尻拭い」はめっちゃコストがかかるので、割とあっというまにコストセンター扱いされやすい等の不遇の扱いを受けやすいのですが、「本当に尻拭いが出来るエンジニア」は多分ものすごくレアなので、そのレアカードが切れると、多分、色々と死ねます。
ただ一方で「滅多に出てこない例外処理に１週間」とかかけられても、特に序盤でのそれはかなり痛いので。
「滅多にないだろう」については「捕捉可能」にしておいた上で、一端「ざっくりとチェックしたり処理したり」っていう思い切り、は、必要なんですよね。
あと「脊髄反射でコードを思いつかない」場合は「一端、ベタに書いておく」っていう思い切り。「後でよい書き方が天から降りてきた」ら、タイミング見計らって書き直せばよいのです。
でまぁ…
・隙間があって隙のない設計、が出来る
・コードで「手を抜いていい箇所」がわかる(＋、基本的に組むのが早い)
ってのは…多分、ま〜ま〜「ハイレイヤーな要求スペック」で(苦笑
もしかすると、スタートアップで一番しんどいのは「ハイレイヤーな技術者との接点が薄い」「技術者が(技術力＋経営まで見越せる、って意味で)ハイレベルなのか、の判断が難しい」に加えて、ぶっちゃけ「人件費が出ない」ってのが、ある可能性、も、あるんじゃないかなぁ、っと*1。
まぁその辺を考えると。
今日ランチしたうちの弟子とも話をしていたのですが「ビジネスがわかる技術者」ってのは、色々な意味で、必要だし重要だしレアなんだろうなぁ、と。
一方で、経営者って本来的に「金を集めてくる」のが一番初めのお仕事だと思うので、そのあたり、頑張っていただけるとなぁ、と(他人事ｗ)。
なんてことを、色々とつらつらと。
*1:おいちゃんも「内容は面白いんだけど単価があんまりにも合わなくてごめんなさいした」案件とか、割とあるですしねぇ……
