スタートアップにおける糞コードとエンジニアの役割について - 表道具
そのエンジニアが経営資源の最適化という観点で最善策を立案できるならいいが、仮にそうでないならそれは絵に描いた餅。あと、リリースの速さで測るものでもない。経営指標にインパクトを与えるか否かで判断すべき。
2015/03/22 22:37
よんだ。
うーん。この指摘はちと視線がずれすぎている。
まず、指摘内容が妥当であるかどうか、それは組織の状況を鑑みて判断すべきこと。
また、その判断が妥当であるか否かは、リリース速度がユーザーの支持に直結し、結果経営指標の底上げにつながるならその選択を進めるべきで、その判断に至る要素が不足しているなら議論の土俵には上がっていないって事。
エビテロの記事はその部分を的確に表現している。
結局、最初にエンジニアが理解する事は、組織はエンジニアだけで構成されていないし、そしてユーザにとっては組織なんぞどうでもいいという事。
確かに後の工程が効率化するという提案は魅力的だが、仮にやらない場合とやった場合の具体的な差はどういったものだろうか？
私はよく、安易に自動化なんぞすんな、ってことを言う。
自動化そのものは素晴らしいし、うまくはまれば効率だけでなく正確性もあがる。
ただ、小さい組織において、日々のルーチンタスクの１つでもかければ会社は止まるし、サービスの一時的な停止であっても、場合によってはターニングポイント（悪い意味で）になりかねない。
例えばこれ。
「済みません，今日は進捗はありませんでした．ここでコードを直さないとこの新しい機能を追加する際に大変なんです」と言ってちゃんと見過ごしてもらえることが重要である．
これは違う。
CTOはこの発言に対して、なぜその判断をしたのかちゃんと確認し、その優先順位が会社の事業上の優先順位とマッチしているかを総合的に議論しないと全然だめ。
どんな技術者でもコードの最適化等の重要性は理解している。
しかし、物事の優先順位を必ずしも技術的側面でみないという適切な判断をできないならCTOなんてやるべきじゃないし、それこそ元エントリーのように、CTOとして足りないものがあった、以外のなにものでもない。
仮に3か月で実現しないといけない機能があって、そこにたどり付くための道筋が複数あり、いずれも可能な中で、その選択肢が存在するのであればそれは選択可能なものだが、例えば、この最適化を含む選択を行うと工期が１週間不足するというなら基本は選択しない。
たかが１週間だが、その1回の判断でリリースを延期するという判断をすれば、そのエンジニアはおそらくその後も常にその判断基準で物事を判断し、会社の優先順位は経営的な判断よりも技術的判断に偏り、結果、企業の寿命は縮まってしまう可能性が高い。
そもそも工期が１週間もずれるということはエンジニア以外のタスクの調整も多数発生するわけで、普通に迷惑以外のなにものでもない。
引用のもので「１日」といっているが、同じ判断内容であれば同様にゆるすなんてことをしていれば技術的負債を完済するまでその話は続く可能性があるわけで、まさに火元の記事にあった「技術的負債を完済するのが早すぎた」という一言に尽きる。
この「技術的負債」との向き合い方について各ブログは言っているのに、彼は突然その話に突っ込みを入れながら一人だけ「技術者としてプライド」の話を中心に添えている。
僕は冒頭にあった「コードを書いている事自体がリスク」という言葉の意味が読み終えて納得できたし、だから彼の記事は「技術的負債」とまったく向き合っていない記事なんだなと思った。
それが理解できていないなら、結構厳しいし、CTOという議論に参加できるレベルではないと思う。
いや、余裕があるなら全然いいんですが、大抵のベンチャーだと、人少ないし、慢性的な人員不足に悩まされている状況なので、手を止めずに行えるものはOK、でも手を止めないといけないものは、基本今は判断をできないってのは普通に行われる事。
で、これを「だめ」って言えないCTOはおそらくたいていサービスを１年や長くても２年で終わらせてしまう。
資金調達という目でみても、サービス開始からおよそ3年目ぐらいが限界値。
自力で収益を上げているサービスで黒字のものは何とかなるけど、大抵のネットサービスは自力での収益性には常に黄色信号がともっているので、常に資金調達とその時の将来性の青写真が必要になる。
結局、最初の２年ぐらいは、極端な事言えば、常に前のめりで進んだとしても手が足りない話になるので、その中で、前に進みながら改善できるものからやるというのがまさに技術的負債の話であって、別に手を止めても会社の経営上は問題もないとCTOが判断できるっていうレベルなら、それはもう、負債の返済に入るべきステージで、既に既存の議論の負債返済の速度とは全然関係ない。
一連の記事は、返済タイミングは技術的側面だけでなく、経営的側面との兼ね合いが重要で、創業期はその重心がどうしても経営的側面に偏らざるえないという話があるわけで、それを否定するのはいいが、ただ単純に「いや立ち止まってやればいいだけの話」というのは、ほかの記事が経営的側面との共存の課題について触れているにも係らず、自らはそれらの前提条件は全て捨てて、唯一「技術者が技術について熱く語って何が悪い」っていう居直りでしかない。
全員そういった葛藤と戦いながら、そうできないことを「負債」と表現しているわけで、それが故のあの記事なんだから、その前提条件を捨てて記事書いて批判とか意味わからん。
まぁ言いたいことは、この話は、エビテロの記事を読んで理解できないんら、もう終わってるかと。
＜追記＞
理解できているのかどうかしらないけど、多くのCTOは常に技術者と向き合いたいと考えているし、というか、向き合っている。
ただ、どうしても技術以外の話もしなければならないわけで、それを「優しさ」とかいう一言で、それがあれば云々なんてのは本質的にはわがままなだけで、周囲の人間の葛藤なんかしらんよと言っているに過ぎないと思うけどね。
＜追記２＞
あと、
それを避けるとしたら考えるしかない．今何ができていて，これから先現状のコードのこの特性からこのような機能を無理なく追加できることが予想できて，一方でコードを改善すれば新たにこういう可能性が産まれて，その結果経営にはどういう影響があって，というのを徹底的に考えていく必要がある．それは全員の責務だ．それをやらないで「とにかく機能をぶち込め」というような経営者やCTOは職務を放棄しているし，理想論に甘んじるエンジニアも然り．
これも結構ひどい。
この話にいたっては、おそらく各記事はそういった葛藤や議論は行ったうえで、それでも難しいものとの板挟みをどうするかというのが「タイミング」の話と言っているのに、彼のみ「必要なんだけどな」って意味不明な事を言い出している。
いや、それみんなやってるから。
やってるけど、物事は常に折り合いがつかないし、そもそも技術なんて技術者毎に美学もあるわけで、それが必ずある答えになるわけもない。
それを一方的に「職務放棄」とか「理想論」とか意味不明な定義でぶった切るとか、どんだけ周りの人間不信なんだよって言いたくなる。
その考え方がおそらく「リスク」って言われたんじゃないのかなぁと思いますがね。
