Ateam Hikkoshi Samurai Inc. Advent Calendar 2017 12日目です。
本日はエイチーム引越し侍の新卒1年目、Webエンジニアの@ueki05が担当します。
みなさん、自身の開発スピードをなかなか上げれずにお困りではないでしょうか？
もしくは、回りに開発スピードを上げれずに困っている人はいませんか？
今回は自分が入社してから開発スピードを上げることに繋がった工夫をご紹介いたします。
※随時更新していきますので「これやると開発スピードあがるよ！」といったご意見やコンテンツをコメントいただけると嬉しいです！
#導入
開発のスピードを上げる前に、まずは「開発」をフェーズ毎に分けてみます。
大枠は以下のようになるかと思います。
- 仕様決め
- コードを書く
- テスト・動作確認
私もそうなんですが、コードを書く以外のところでも結構時間を使います。
これら3つのフェーズをきちんと分けて考え、それぞれを効率化することが、開発全体のスピードアップに繋がると思います。
では実際に効率化に役立ったことをフェーズ毎に紹介し、全フェーズに共通することを最後にまとめていきます。
#開発スピードを上げるために
##仕様決め
###必要なこと・不要なことをまとめる
「PCサイトは対応してたけどスマホサイト対応するの忘れてた。。。」
「これスマホサイトだけでよかったんだ、PCサイトも対応してしまった。。。」
私はこういう経験を何度かしています。
いまだにやってしまうことがあるのですが、これやっちゃうとすごく無駄な時間が増えてしまいます。
どの範囲まで開発をして、どの範囲はやらないのかを予め明確にしておくことが重要です。
これを確認しないと、無駄な開発に時間を使った挙句、戻しの対応もしないといけなかったり、逆に想定していなかった開発が後から増えて、直前の開発に追加の対応をしないといけなくなったりします。
仕様決めや確認の段階で、やること・やらないことを明確にしましょう。
###色んな人に相談しすぎない
私の体験談になるのですが、例えばデザイナーのAさんにとある開発のデザインについて相談したとします。
開発が進んだので、もう一度Aさんに聞こうと思ったら不在で、そのときはデザイナーBさんに相談しました。
すると、Bさんから「xの色はもっと輝度の高い色にした方が目立つ」と言われて、自分でも納得してその変更を適用しました。
すると、今度はAさんから「そこは目立ちすぎない色にしたくて元の色に設定していたので、元の色に戻しましょう」となりました。
複数の人に相談すると、持っている前提条件が違ったりもしますし、各々で考える優先順位も違ったりします。
今回はデザイナーと一緒の例でしたが、これは別の職種でも同様に発生しますし、エンジニア内でも実装の良し悪しで議論することもあります。
議論すること自体は悪いことではないのですが、議論して100点のものを作ろうとすることは、60点のものを作ることよりかなり労力が必要です。
また、WebサービスだとABテストを回して結果が良かったら正式リリース、ダメだったら改善を試みて再度テストを回したりするので、一度60点のものを世に出してユーザーからのFBを得て改善した方が、自分たちの仮説だけで100点を目指すより随分早いし精度も高いと思います。
なので、開発スピードを優先したいのであれば、色んな人に相談しすぎないようにしてみるのも一つの手ではないかと思います。
##コードを書く
###開発言語の理解
かなり当然なことですが、おそらく開発スピードが遅い人はこれができていないと思います。
私自身、振り返るとできていませんでした。
現在仕事ではPHPで開発をしているのですが、学生時代からPHPでプログラムは書いていて、ハッカソンに出たり受託でサイト構築のお仕事をさせていただいていました。
そのときは0->1の開発ばかりやっていたので、言語の知識がそこまでなくても、やりたいことをググって、出てきたプログラムを上手く流用すれば目的が実現できていました。
それが運用しているサービスの改善となると、実際に動ているプログラムを理解して、改修箇所を探して、適切な処理を追加したり、適切な処理に修正したりしないといけないことがほとんどで、そうなるとググっても答えが出てきません。
そうなると頼りになるのはそのサービスのプログラム自体で、それを読み解かないといけないのですが、言語の知識が中途半端にしか理解できていないと、読み解くのにすごく時間がかかります。
なので、一度体系的に使っている開発言語の理解に着手してはいかがでしょうか。
最近だとProgateとかオススメです、すごくわかりやすいです。
###フレームワークの理解
たいていのフレームワークにはチュートリアル的なコンテンツがあるので、それを一度終わらせましょう。
以下いくつか例を載せておきます。
※更新したいので皆さんがおつかいのフレームワークでチュートリアルをコメント頂けると嬉しいです。
###ツールを使いこなす
####エディタ
私の場合はVimを使いこなせることに勝手にあこがれを頂いているので、一旦Vimだけ書きます。
これ一通りできるようになればかなり早くなると思います。
※他のエディアをお使いの方、情報お待ちしております。
####コマンド
こういうの少しずつ覚えていくと、着実に早くなります。
####Chrome Developer Tools
Webエンジニアであれば、ChromeのDeveloper Toolsを使いこなせると爆速でデバッグできそうです。
以下の記事はWindows用で書かれていますが、Macでも別のショートカットキーで同じことができます。
##テスト・動作確認
###テストすべきことを抜け漏れなく考える
いまだにやらかしているのが、改修範囲以外のテストを失念してしまうこと。
例えば、全ページ共通のコンテンツ(ヘッダーとかフッターとか)の改修で、特定のページAのときは表現を変えたいとする。
いざ特定のページAで表現を変えたときに、ページA 以外でも表現が変わっていないかを確認し忘れていることが未だにある。
これは仕様決めのときとも関わるのですが、いざリリースしてみて「ページA以外でも変更されてる。。。」とかなると二度手間なので、抜け漏れのないテストを心掛けましょう。
##共通
###システム仕様を理解する
これは開発全体のフェーズに効いてきますが、特に2番目の実際にコードを書くところに効いてくると思います。
開発を進めていくうちに覚えるという方もいらっしゃるのですが、私自身はなかなか理解が進まず困っています。
弊社でもドキュメントを残す等の色々な試みをしていますが、最近だと@kawanakashotaroさんにシステム仕様のクイズを作っていただいて重要なプログラムを追うようにしています。
自分一人で仕様を理解しようとしても、なにをどう理解したら良いのか分からなかったので、クイズにしてもらえただけで仕様理解が効率化できたように思います。
※皆さんはシステム仕様の理解をどのように進めていますか？ぜひコメントで教えてほしいです。
###悩んだらすぐ人に聞く
これが本当に重要だと思います。
最初は自分で考えて改修箇所を探したり、実装を進めていくべきですが、わからないものはどうしたってわかりません。
手が止まったら詳しい人に聞きましょう。
その結果リリースが早くなるのであれば、それが正義で良いと思います。
#最後に
Ateam Hikkoshi Samurai Inc. Advent Calendar 2017 12日目いかがでしたでしょうか。
明日はエイチーム引越し侍の@ex_SOULさんがTDDに関する記事を書いてくれます(もしかしたら急遽変更するかも)。
お楽しみに。
追伸
株式会社エイチーム引越し侍では、一緒にサイト改善をしてくれるWebエンジニアを募集しています。エイチームグループのエンジニアとして働きたい！という方は是非、以下のリンクから応募してください。
皆様からのご応募、お待ちしております！！