今回の記事は、お店で売っている「プラモデル」を作る話ではありません。
開発手法で僕が個人的に提唱している「プラモデル開発」というモノについての考え方を書いている記事です。
でも、ガンプラ好きな人は多いと思いますが、僕も大好きです。
ガンプラじゃなくても、お城やバイクや車、プラモデルは誰が作っても、一定以上のクオリティで作り上げることができるので、達成感がありますよね。
同じようにwebサービスを開発する場合に、フレームワークやライブラリをベースに行うことで、一定のクオリティ、効率を担保することは可能です。
僕は個人的にそうした開発のことをプラモデル開発と言っていて、企業においてプラモデル開発が向いてるチーム、向いていないチームがある事に気がついたので、まとめてみました。
プラモデル開発の詳細
今時のIT製品は、オープンソースモデルが盛んで、MITライセンスのフリーコードに溢れています。
Githubでは、これまで有償だった製品が、ソースコード公開されていたり、Codepenの様な、優秀なデザイナーやプログラマーが、クオリティの高いスニペットを掲載しています。
すでに公開されているプログラムを、同じ思考で一からプログラミングするのは、時間の無駄以外に無くないですか？
環境に関しても、AWSというクラウドサービスと、dockerというローカルでのステージング環境があれば、世界中どこでも開発作業が行えます。
こうした、有り物を組み合わせるだけで、大体のサービス開発は出来上がってしまいます。
世の中のスタートアップはこうしたことで、初速でダッシュすることができます。
まさにプログラミングなどほぼしなくても良くなる開発が出来上がりますし、出来上がったサイトは一定以上のクオリティが約束されます。
プラモデル開発のメリットデメリット
聞けば聞くほど魅力的な「プラモデル開発」ですが、もちろんデメリットも存在します。
メリットは前述した通り、スピード早く、誰が作っても一定のクオリティが約束されるというんですが、デメリットとしては、細かなカスタマイズがやりにくい環境になったり、内部の不具合に対する担保が難しいという点です。
実際の製品開発においては、初回に設計図が整っているという現場は数少なく、開発が進んで、モックアップを作った段階で、路線をピポットするケースも少なくありません。
さらに、製品開発の依頼者は、独自性を出したいが故に、通常とは違う、ユニークな仕様を入れたがります。
こうした時に、ライブラリを使用していると、そのライブラリでカスタマイズできないことは、製品での実現が難しくなります。
「そんな事は出来ません」と言うか、「その仕様に見合うライブラリを探してみます」という風な発言に繋がります。
依頼者はその言葉に従うしか無いので、結果不幸になってします開発も少なからず存在するようですね。
プラモデル開発の向いてる組織と向かない組織
ここ数年、若いエンジニアに多い傾向として、世の中に出回っているライブラリをいかに多くの種類知っているかというステータスが存在します。
もちろんpython言語では、そうした便利なライブラリを知ってるのと知らないのとでは、開発スピードが格段に違うので、こうしたことが悪いことでは無いのはよくわかります。
プラモデル開発が向いている組織は、そうしたライブラリ群をきちんと管理して、バージョンアップがルーティーンとして行われているチームは、スピードも早く、安定した作業ができます。
ライブラリをカスタマイズしているケースなどでは、バージョンアップの時に、同じようにカスタマイズ開発が発生するのですが、この時に不平不満が出ない組織であれば、こうしたプラモデル開発向きであると考えられます。
プラモデル開発などやらずに、全てのコードを自分たちで書いて、管理するというスタンスのチームであれば、言わずともフル開発で全てのソースコードを担保できる製品が作り出せるでしょう。
もちろん、どちらが良いという決めつけはしませんが、個人的には、スニペットレベルのライブラリであれば自分で内容を把握して自分コードで書いたものをストックしておくような活動ができると、かなり幅の広い内容に対応でき、且つスピードも早く作業できるエンジニアになることができるでしょう。
もしライブラリがサポート終了になったら
プラモデル開発をやっていて、悲しい事例としては、基盤となるフレームワークが、osやブラウザのアップデートに対してサポートを打ち切ってしまう場合です。
よく聞くのが、phpフレームワークが最新のphpバージョンをサポートしていなくて、泣く泣くフレームワークを別のものに変更しなければいけないという事情です。
この手の話はバージョンアップのたびに聞く台詞なので、最近というわけではなく、昔からよく聞きます。
僕の結論としては、「フレームワークなど自分で作って必要最低限で動作させれば良い。その方が、アクセススピードも速いし、好きなようにカスタマイズできる」という事です。
非技術者はどっちでも良いという判断
結局のところ、こうした考察は、エンジニアが考えなくてはならない事で、依頼者である非エンジニアは、一刻も早く、依頼したモノが出来上がって、さらには安定したクオリティであってほしいと考えるので、その点だけを突き詰めるとプラモデル開発がが選択されがちですが、その後のメンテナンスコストや、回収頻度や難易度を考えられているかどうかも重要ですね。
一度作って終わりという程度の開発であれば、ライブラリ開発で十分ですが、その後にコア部分も含めて拡張がありそうであれば、コアから自分で理解しておく必要があります。
もっともお寒いのは「ライブラリはブラックボックスなので、わかりません」と、言ってしまうエンジニアなのでは無いでしょうか？
スピードとクオリティを上げられるプログラミング術をスキルアップさせる事こそが、エンジニアの質向上であり、彼らのモチベーションのもっとも上がるポイントでは無いでしょうか？
