ネットにはクリーンコードなどきれいなコードの書き方や保守性を高くする記事はたくさん転がっています。しかし、急ぎで早く開発する方法の記事はあまりありません。

しかし、早く開発しなければいけない!日本一のウマ◯になるくらい速く開発しなければいけない!!こんな局面に立たされたエンジニアも多いのではないでしょうか。今回は究極の急ぎの局面でどのようにすれば早く開発できるのかを紹介します。

※予め注意書きをしておくと、今回紹介する方法は通常の開発で行うと保守性やサービスの質が落ちてしまい兼ねないので急ぎではない場合はおすすめできません。あくまで急ぎのときの参考程度にお読みください。

目次

①小さく始める

②こまめに確認をする

③デザインにこだわらない

④設計にもあまりこらない

⑤コードは無理にきれいにしようとしない

⑥よく使う機能はコンポーネント化しておく

⑦使えるライブラリは使う

⑧エラー処理(バリデーション)は最低限にする

⑨もはやそのシステムを作らない

方法

①小さく始める

Webサイトやシステムを0から作るとなった場合、あれもこれもと機能が膨らみがちですが、全ての機能を実装するのは時間がない場合は最低限必要な機能に抑えましょう。1つくらい大丈夫だろうと機能を増やすとその実装だけでなく、その後の修正やテストの時間も伸びてしまうので思っている以上に工数が増えてしまうことがあります。

②こまめに確認をする

もし、上司やクライアントへ見せるものであれば途中の段階でも見せられるものがあれば確認してもらったほうがいいです。もし、全て作り終えて修正になった場合修正範囲が大きくなってしまう可能性があります。修正の段階は早ければ早い方が範囲が狭く軌道修正は楽です。

③デザインにこだわらない

よくページの見た目にこだわってしまう方がいますが、そこそこのデザインで最低限ツールとして役立つのであれば、細かい部分にこだわらずそのまま進めてしまう方がいいです。C向けのTOPページなどであれば怪しまれて去ってしまわないようにある程度のデザインは必要になりますが、ログイン後の管理画面や管理者側のデザインは最悪崩れていてもシステムとして機能していれば使えないことはありません。ユーザーからすれば利用価値があればデザインが多少崩れていても使われなくなることはありません。逆に時間をかけて完璧なデザインにしても使われない可能性もあるので、デザインは運用しながら修正していくのがいいと思います。

④設計にもあまりこらない

「このシステムはクリーンアーキテクチャーでつくるんだ!」と考えるのは素晴らしいことです。しかし、時間がない時や小さな0→1サービスの場合はおすすめできません。「ああが良いかな?いや、あの形の方外良いかな?」など考えれば考えるほど時間がなくなってしまうので、ある程度「こんな感じかな?」程度に設計できたら作りはじめてしまったほうが良いです。設計はその後のサービスに大きな影響を与えるため、ある程度大きなシステムであればなるべくきっちり決めた方が良いですが、そもそもそのレベルのシステムであれば時間をとって開発したほうが良いです。

⑤コードは無理にきれいにしようとしない

「プログラムの行数はなるべく少なく、1メソッドには1つの役割のみにする!」と考えてプログラムを書いているエンジニアさん、あなたは保守しやすいコードがわかる人です!ですが、普段から慣れている方でないとどのように処理を分けるかという判断で時間がかかってしまいます。時間がないのであればまずは1つのクラスやメソッドにまとめて書いてしまうのもやむ無しです。メソッドを分けるのはリリース後余裕ができたときにリファクタリングでやりましょう(この方が効率がいい場合もあります)。しかし、自然にきれいなコードがかけるように技術力は磨きましょうね。

⑥よく使う機能はコンポーネント化しておく

とはいえ、よく使う機能はコンポーネント化して共通化しておいたほうが後々早くなります。同じ機能を書いたりつくったりするのは時間がかかるので、もし、共通化したほうが完成が早くなりそうであればしちゃいましょう。

⑦使えるライブラリは使う

既に世の中にあるライブラリが使える場合は積極的に使いましょう!わざわざ0から機能を作るのは大変手間です。0から作ったら通常1ヶ月かかるものでも、ライブラリを使ったら1日でできたなんてことはザラにあります。Java ScriptのカレンダーはFull Calendarを使えば良いんです。ネットに使い方も載っているので誰でも使い方が分かります。積極的にライブラリは探すようにしましょう。

⑧エラー処理(バリデーション)は最低限にする

フォームのエラー処理(バリデーション)を実装する際に、「この項目は必須項目で、数字で、1〜12の中で、さらにDBにはユニークで。。。」など、一つ一つの項目で真面目に考えていたら時間がかかります。中には、「こんなデータが入ることはないけど開発ツールから変えられた場合を考慮して入れておこう」と考える人もいます(私です)が、時間がない場面ではそんなこと考えている余裕なんてありません!エラーチェックはデータ不整合が起きない程度の必要最低限でいいんです。まずはフォームで正常系を登録できる形だけを実装してしまいましょう!

⑨もはやそのシステムを作らない

最後に上記の全てを無に返すようなことをいいますが、最も重要なことは「そもそもそのシステム(もしくはサイト)は必要ですか?」を考えることです。作らないというのも一つの選択肢です。

一度限りのサイトや今後保守しないシステムであれば、急ぎでつくった汚いプログラムでも何の問題もありません。しかし、Webサイトやシステムというものは基本的には保守していくものです。保守にもコストがかかってきます。急いでつくった汚いプログラムであれば修正は大変ですし、そんなプログラムを保守したいと思うエンジニアを探す手間もあり、通常より数倍の運用コストがかかります。そのコストよりも作るメリ ットの方が大きいのであれば作るべきですが、そうでなければ検討し直した方が良いです。

まとめ

さて、いかがだったでしょうか。

こういった記事があまりないのは正直何も考えなければ自然とできることだからかと思います。しかし、最近ではクリーンコードやクリーンアーキテクチャといったものが情報としてたくさんあり、きれいに書かなければいけないという固定概念が開発を邪魔してしまうこともあるかと思います。しかし、開発で1番大切なことはきちんと動くものをリリースしてサービスを提供することです。時には、早く世の中に出さなければいけないときもあるので、その時の参考になれば幸いです。

そして、余裕ができたら絶対にリファクタリングをしましょう!

この記事をシェアする

Laravel開発のお悩み相談・学習サポートはこちら

じゅのきちメンターサービス

じゅのきちメンターサービス