クローン開発と、それが生み出すゴミクズシステムについて思うところ。
仕様が把握できていない
これが一番問題だと思っているところです。
クローン元を全く知らなかったり、ユーザとして使っているだけであったり
自分が携わっていないプロジェクトのサービスであったりした場合、
必ずそこには把握することのできない隠れた仕様が無数にあります。
ある程度はクローン元の担当者あるいは前任者に聞くことで把握することができますが
結局作られた大きなシステムがすでにあるのでそれをごそっと持ってきた場合
ソースコードを読んで把握することが必要になります。
仕様を決定するプランナーは、1行のコードに隠された大きな仕様を把握することができますか？
当然コードを読むのはエンジニアの仕事なので、調査をすることになります。
そして仕様を元の作りのまま踏襲するのか、それとも変更をするのかプランナーに確認をします。
流れにすると、
プ「クローン元のアレの機能作りたい」→エ「ああアレか、その機能ごそっと持ってきて作るよ」
→エ「...うわあアレってこんな作りなのか、、この仕様どうする？」→プ「...仕方ないからそのままで」
という具合になるのだけれど
→エ「じゃあこの仕様は？」→プ「んーそれはアレをアレに変えたい」→予定の工数より伸びる
ということも当然あります。
サービス開発において仕様変更なんて当たり前なのでそこに関しては言うことはないですが
何が言いたいのかっていうと
”サービス開発の企画の根幹にいるプランナーが仕様に関して先導できていない”ことが
ものすごく危ういと感じています。
（ちなみにクローン開発だとプランナーさんもまたツライというのがわかりましたが、、）
すでにできているものをごそっと持ってきて作るクローン開発の仕組みだと
新しいものを生み出す機会が損失されて
プランナー（プロデューサー？）の醍醐味である（と思われる）新規企画が創出されにくくなると思います。
もちろんここで言っているのは能力のお話ではなくて、
クローン開発という仕組みと環境が起こす弊害のことを指摘しています。
だれが悪いとかではなくて仕組みが悪い。
「これはすでにあるからクローン開発しよう」がどれだけ悪影響か。
「これはすでにあるからクローン開発しよう」→「作りが汚くて仕様が把握しづらい」
「これはすでにあるからクローン開発しよう」→「この機能、本当はいらなそうだけど増えちゃった」
「これはすでにあるからクローン開発しよう」→「決断した、この機能は削ることにする」→「削るとなると逆に工数かかるよ」→＼(^o^)／
これがゼロベースの新規開発なら
「企画できた、こんなものが作りたい」→「最小限の動くやつ作ってみた」→「理想に近づくように徐々に機能追加しよう」
となるのではないかと。
理想にすぎないけれど、それでもやっぱり一番問題なのは、
”作り手さえも不要そうだなと感じるたくさんの機能を盛り込んだクローン開発”によって
ユーザが定着するのだろうか、というところ。
何のために作っているのか？何を作ろうとしているのか？
クローン開発だとこれを見失う確率が極端に上がると思います。
だからクローン開発をするなら文字通り完全に元のまんま持ってきて
画像とマスタデータを変更するだけにすれば良いと思います。
だってハナからそういうつもりで作るってことでしょ？
少しでも独自で作りたいものがあるのなら、ゼロから作ろうよ。
ちなみに、僕は車輪の再開発は好きなので
Twitter真似してこんなサービス作ろうよ！とかはノリで結構テンション上がって
おもしろそうだと賛同できるタイプです。日本人は改良する能力が高いらしいので。
しかしシステムの丸コピー、てめーはだめだ。
設計が変更できない
さて、少しエンジニアよりの話になりますが
元の作りが汚いとは言えどもエンジニアらしく古い技術を新しい技術に置き換えて
改良すれば良いではないかという声があがります。日本人は改良する能力が高いらしいので。
僕も最初はそう思っていました。汚いと思うなら気合で直せば良いと。
結論から言うと手が届きませんでした。
改良の妨げになった一番の要因は、上記にもある仕様の把握に関連しています。
システムを開発するエンジニアは、3000行の1クラスに隠された大きな仕様を把握することができますか？
まあ正直3000行と聞いても、ハンパなく長すぎだろｗｗｗっていう感覚にはならないのですが
それは書く時の感覚な気がしていて（自分で書いていたら1クラスに3000行も書かないけれどｗｗ）
これがすべて自分の書いたコードではなくて、当然その1クラスに限らずパスタなコードなわけで
読んで理解するのは本当にしんどいです。
読まないと仕様把握できないから読む、コードがきたなくて理解に時間がかかる、
期日が迫る、リファクタリングに費やせる時間がなくなる、＼(^o^)／
よくある話かもしれません。
コメント内にタイポで”画像パスタ”って書いてあった時はたしかにパスタだなと思いましたが
それもよくある話かもしれません。
ただ、直すことに手が届かなかったのは恐怖による面もありました。
自分で作っていない、完璧に仕様を把握していない、テストコードのないシステムを
・改変することでバグが起きてしまうことが無く
・もともとの仕様を満たしていて
・期日に間に合う
ように果たして自分はできるのか。。。
僕は静かに、そしてひたすらにCtrl+C Ctrl+Vを叩きました。
ちなみに、ソースコードの綺麗さは命名の正しさの影響がとても大きい
というのはよく聞く話で僕もそのように思っているので
バカみたいにCtrl+C Ctrl+Vを叩いていたわけではなくて
適切なパッケージに適切なクラス名、できれば適切なメソッド名、変数名etc
のようにクローン開発の最中で改善していました。まあ当然なんですけど。
ただロジックを大きく直すところには至らなかったなと。。
また、テストコードが無いならクローン開発するときに最初に書けよ、という話ですが
テストコードを正しく効率よく書ける人間が（自分も含めて）果たしてチームにいるのかという点と、
クローン元から仕様が変わるとわかっているのに汚いコードをテストするコードを書かなければいけないという点、
そしてテストコードを書く工数の確保ができない点から踏み切ることができませんでした。
クローン開発の仕組みの悪さを指摘しているものの、自分の能力の足りなさももちろんありますね。。
底辺プログラマ
そんなわけで、日々クソコードとにらめっこしてクソコードを書いていたのですが
どうにもこうにも絶望的な時期がありました。
「俺はなぜこんなものを作っているんだ...」
「クソだと思っているのに直せずにいる自分はエンジニアとしてどうなんだ...」
「コピペで作れると思われているなら、もしそうならだれでも作れるし、別に他の誰かでいいじゃん...」
ぶっちゃけ、もう辞めようかと思いましたね。繋ぎとめているものが責任感だけだったので。
そんなので成長できる気がしないし、クローン開発と言えど今回の場合は単にコピーで
完成できる状況じゃなかったのもあり作業時間が増えてデスマになり、
何より楽しくないと思ってしまった。
仕事が、技術が、好きなので入社一年目とかは成長できると感じてプライベートなど気にせず働いていたし
その後も好きなだけ働ける環境って良いなと思っていてそれは今も変わりません。
激務だろうが別にいいと思います。
しかし、成長できない&&開発楽しくないみたいなことになるともうだめぽです。
人としては底辺でもいいし、
フェイスブックでリア充ポストしている人たちに
人間的に負けていようと全然かまわないけれど、
負けたくないし本気でやりたいと思っている技術のことで底辺ともなるといよいよ終わったなと思うわけです。
そんなことならニートになって自分のやりたい開発をする方が良いですね。
僕の中での底辺プログラマの定義は勤務時間ではなくて
自分の技術の範囲を広げようと、成長しようとせずに、与えられたコードを”書かされ”続けることです。
エンジニアの真髄ってなんでしょう？
職種が混在している会社に関して言うと、エンジニアの真髄はシステムの将来を見通す力だと僕は思います。
システムの将来は、他の職種や技術屋でないお偉いさんからは到底見えないエンジニアらしい部分だと思っています。
そういった、求められているべきレベルは重要で、そのレベルが極端に低い場合に底辺プログラマに成り変わります。
これが技術主導の会社であれば、そもそも底辺の話にはなりませんし、
エンジニアの真髄ももっと別なことにあるでしょうけれど。
とは言ったものの技術主導の会社がどういったものなのか、逆に問題点は無いのかなど
僕には想像がつかないのであまり皮肉を言ってもしょうがないですね。
GitHubは60%がリモート勤務でマネージャーがいないのに
あんなに素晴らしいプロダクトを世に生み出していることには憧れてしまいますが。
GitHubの組織が成長する過程で変えたことと変えなかったこと
http://wazanova.jp/items/675
話はそれましたが結果どうなったかというと、投げ出さずに開発しています。
どうやってモチベーションを保てたか、正直わかりません。
例えばリリースが近づいてもうやりきるしかないって思えたこととか、
例えばホリエモンのゼロを読んだこととか、まあいろいろなんだと思います。
今はとにかくリリース後うまくいけばいいなと心から願っています。
クソコードでも自分が作ったものだから。もちろん一人で作ったわけではないけれど。
ちなみに、システムに関してはゴミクズとかクソコードとか言っていますが、
サービスに対しては否定的なことは思っていませんし
一生懸命サービスを生み出そうとしているプロジェクトのメンバーに気を悪くはしてほしくないです。
なぜなら僕も一生懸命作っているうちの一人ですから。
じゃあどうすればうまくクローン開発をできるのだろう
さんざんdisってきましたが、自分が作っているものをdisることは良いことかなと思っています。
disるだけで改善しないのは意味がないですが。
まとめとして、じゃあどうすればクローン開発ってうまくいくのさ？という部分についてです。
これを書かないとただの愚痴で終わって、何も残したことにならないので。
うまくやる方法としては
・クローン元のプロジェクトメンバーがそのままクローン先のプロジェクトメンバーとなる
・クローン元が安定稼働している状態からクローン開発する
・ソースコードやシステム構成を一切変更せずにクローン開発する
・クローン元ソースコード読解の工数を確保する
このような点があげられると思います。
けれど基本的に上記のことは守られないので
元も子もないことを言うとシステムのクローン開発はすべきでないと思います。
また、クローン開発のメリットについてですが、1つだけありまして
すでにできている風のものがあるのでプロジェクト立ち上げの段階で
実際は何も決まっていなくても、仕様が詰められていなくても何とかなりそうと甘えることができる、
管理する立場の人間にとって心のどこかに安心感が生まれることでしょうか。
このしわ寄せがのちのち機能追加や運用で荒波のように押し寄せてくるでしょう。
というわけでシステムのクローン開発を経験して何1つ良くないなと思いました。
感情的に言うと、もう絶対こんなゴミクズシステム開発フローはやらないな、という感じ。
ついでにもう1つエントリ書いてみました。
http://ameblo.jp/wavecantstop12/entry-11722200965.html