社長をやりながらでも、コードを書き続けるためにやってること

先週流行ってたこの辺りの記事が面白かったので自分のスタイルを。

プログラミングの生産性を上げるには
コードを書き続けるためにやってること


時間がなくて乗り遅れたけど、6日遅れで書いてみた。
すごいエンジニアな人たちが書いているので、僕はちょっと違う視点で。

小さい会社ですが社長をやっていると、営業やら総務やら経理やら他のメンバがやっているプロジェクトのマネジメントやら、コードを書く以外の仕事がバカにできないくらい色々あって時間がない。でも、やっぱりコードを書くのが好きなので、そんな中でもコードを書き続け、成長するためにやっている工夫を書いてみます。

要件を聞きながら(考えながら)DB設計とプログラムのざっくりロジックを頭のなかで書く

主に受託開発でやっていること。

お客さんから要件をヒアリングしながら、同時に頭の中で大まかなDB設計とざっくりロジックを組み立ててます。
どれだけ要件をちゃんと考えたり設計したりしても、いざ実装してみると抜け漏れがあったり、想定通りにならなかったりすることが意外と多く、それで、再度お客さんと議論したりしている時間は、意外と多いように思います。
その時間を出来るだけ少なくするために、お客さんとの打ち合わせの中で、一度、頭の中で擬似的に開発するようにしています。

どれだけ頑張っても、コードを書く時間自体を短縮するのは限界があるので、それ以外の余計な時間を出来るだけ短縮しようとしています。

要件を理解するのではなく業務を理解する

これも主に受託開発でやっていること。

よくあるのが、お客さん側の担当者が現場からヒアリングして要件を取りまとめているケース。ただ、担当の方も必ずしもそれのプロではなく、また各業務に精通しているわけではないので、その要件を鵜呑みにしてしまうと、後で手戻りが発生しがち。

必ず業務をセットで理解するようにして、業務的に違和感がないものになるようにしています。そうすると、大きな問題が起こりにくく、トータルでスムーズに進めることができます。


開発する機能を細かい単位に分割する

僕の場合、1時間まとまった時間を取れることが少ないので、開発する内容を1時間未満で終わるくらいの粒度に分割してタスク管理ツールに全部登録します。そして、大体1週間単位に予定と照らし合わせて、いつどのくらい時間を取れそうかを整理して、細かく分けた開発内容を分配していきます。

こうすることで、1時間以上まとまった時間がないと開発できないものも明確になるので、それを考慮したスケジューリングをしてます。
 

移動中に頭の中でコードを書く

打ち合わせや営業などで移動が多いので、移動中に頭の中でコードを書くようにしています。それで、打ち合わせ後、カフェやオフィスで頭の中で書いたコードを一気に書き出しています。

ドキュメントを読んで要件を把握していたり、どう実装するか悩んでいたり、そういうコードを書いている時間以外の時間が意外と多いので、移動中に済ませておくようにしています。

重要度を大胆に分ける

要件の優先順位付けはよくやると思いますが、僕はかなり極端に、大事な部分にフォーカスするようにしています。逆に大事でない部分は、多少実装が甘かったりバグがあってもテストの中で簡単に潰せるので。

ただ、重要な部分が大きなバグがあったり仕様に問題があったりするとテスト進捗の大きなボトルネックになってしまうので、中途半端な優先順位付けではなく、極端に力のかけ具合を変えています。

テストは後回し

コードファースト、検証セカンド。あとで必要な分だけテストを書く。

自社サービスの場合は特にそうで、プロトを作って検証して、その後もう少し踏み込んだプロトを作って検証する。それの繰り返しで作っていくよういしています。テストから書いていたら、検証スピードが落ちてしまうので。

やる気がない時にやるタスクを残しておく

絶対にやる気や集中力の波はあるので、そういう時のためのタスクを残しておきます。デザインの調整や入力チェック系、テストデータの準備など。

電車の中でコードを書く

さすがに受託案件の開発はしませんが、自社サービスはよく電車の中で書いてます。通勤時間が長いので、かなりいい感じで開発できます。

例えば、この前公開したboardという新サービスの多くの機能は、電車で座れた時に開発してました。

新しい要素を仕事に絡める

基本的に何かしら新しい要素を入れることが好きなので、受託の仕事においても積極的に新しいことを取り入れています。もちろん、ワーストケースを想定して、自分でちゃんとリカバリできる範囲で。
それの積み重ねで、常に毎年、何かしら新しいことを実践の場で使えるようにして、成長が止まらないようにしています。

勉強するだけしても実際に使わないとダメだし、実際に使う方がはるかに学習効率がいいので、「実際に使う」ことを強く意識しています。

これについては、僕自身が営業もしているので、仕事を取ってくる段階から意識し、必要に応じてお客さんにも説明して了解を得るようにしています。

Posted 9 years ago 4 notes


このエントリーをはてなブックマークに追加
【board】請求書・見積書・発注書作成から、売上見込等の経営管理まで
請求書・見積書・発注書作成から、売上見込・キャッシュフロー分析等の経営管理まで

Notes:

  1. sibukixxx reblogged this from velc
  2. pirapira reblogged this from velc
  3. mersy reblogged this from velc
  4. velc posted this

About me:

ヴェルクの社長 田向(@fw_tx76129)のブログです。
受託開発と自社開発の両立に取り組んでいて、その取り組みなどを書いてきます。