2017.10.02

開発進捗を加速させるための小さな工夫

業務改善, 残業減らしましょう!

次世代システム研究室の データストア 好きの Y.I. です。
今回は、開発PJを少しでも速めるための工夫を3点ほどご紹介します。私が試行錯誤したもので、実際に自分が関わっているPJで適用してみて、少なからず効果がありました。大きな仕組みではなく小さな工夫ですが、実際に一緒に取り組んでくれた同僚の評価も良かったのでブログにまとめます。
なお、レビューして貰う人を Reviewee 、レビューする人を Reviewer と以降に記述します。

3つの工夫

  • コーディングはまず動くものを作りその直後にリファクタリングしましょう!
  • Reviewee が説明しながらレビューしましょう!
  • PJにおける最初の作業はレビューではなく共有してもらいましょう!

▼ コーディングはまず動くものを作りその直後にリファクタリングしましょう!

開発者の心情として

  • 誰しもがキレイなコードやカッコイイコードを書きたい
  • 少なくとも人に見られて恥ずかしくないコードを書きたい
  • だがキレイなコードをいきなり書くのは大変で時間がかかる
というところがあると思います。

改善ルール

  • まず動くものを作る!
  • どんなに汚いソースコードでもOK!コピペ歓迎!
  • 必ず動いた後でリファクタリングする!
こちらをPJ共通認識として開発に取り組むだけです。

効果

  • 動く事だけに集中するため短期間で動くコードを作れる
  • 動くコードが完成すると心理的に楽になる(要件を満たしているのでギリギリ合格点のはず)
  • 自分が ”直前” に実装したソースコードをリファクタリングするのは非常に簡単
=>心理的に楽になった上で直前まで開発していたコードを修正するのは、一から開発する事や歴史ある(過去の人が書いた)ソースコードを修正するよりも非常に簡単です!

▼ Reviewee が説明しながらレビューしましょう!

設計レビューやソースコードレビューどちらでも有効ですが、ソースコードレビューをベースにまとめます。

Reviewer心情

  • 自分のタスクがいっぱいある時にシンドイ…
  • 仕様を把握していないレビュー依頼だとシンドイ…(仕様をあまり把握していない箇所なのにレビューしなければいけない状況は多々ある)
  • 大量のライン数のレビューをいきなり投げつけられてもレビューに時間がかかる、時間がかかりそうなのでなかなか見る気になれない、レビューする気持ちを作るのに時間がかかる…
  • シンドイし自分作業もあるので余裕と気持ちが出来てからレビューしようと後回し、もしくは忘却して放置…

Reviewee心情

  • やっと開発が完了したがレビューはまだかな?
  • 忙しそうだからレビューをせっつくのはやめておこう
  • なかなかレビューしてもらえない……
  • いつレビューしてくれるのかな???

改善ルール

  • Reviewee と Reviewer が対面でレビューする
  • ソースコードレビュー対象が多い場合、 Reviewee が説明しながらレビューを行う
  • ただし、レビュー対象が少ないときや Reviewer が説明不要と判断した場合は pull request を投げつけてレビューよろしく!できる

効果

  • Reviewer が1人でコードを読み取って確認するよりも作った人に説明してもらう方が圧倒的に速い
  • レビューコメントを通してやり取りするだけよりも直接説明した方が正確に速く伝わる
  • 把握していない仕様は対面レビュー時に仕様書を元に説明してもらえばいい
  • 事前の準備が限りなく減る
  • Reviewer の負担軽減になり、結果レビューを早めに対応してもらえる
  • レビューMTGのアポイントを取るので後回しや放置されることがなくなる
=>レビューのための事前準備が限りなく減り、精神的負担も減り、レビュー時間自体も減り、レビュー完了まで速く進みます!

▼ PJにおける最初の作業はレビューではなく共有してもらいましょう!

心情

  • レビューされるとなると Reviewee が構えてしまい作業完了まで精度を上げるために時間をかけすぎてしまうことがある
  • 正直なところ Reviewer も知らないことは沢山ありいつでも改善につながる指摘が出来るとは限らない

ルール

  • 設計やコーディングの最初のタスクはレビューする形式ではなく共有会として実施してもらう
  • PJで最初に実現した人に教えて頂くつもりで取り組む

効果

  • ミスを指摘するネガティブの場ではなく技術や知識を共有するポジティブな場になる
  • レビューだと指摘するのに知識が求められ、詳しくないと発言しにくくなる
  • わからないことを質問しやすくなる、少なくとも質問しやすい雰囲気になる
  • 開発したコードをレクチャーしてもらうことで各メンバーの技術力が短期間にあがる
=>メンバー全員がそのPJで必要なスキルを短期間に身につけることができます。また、教えてもらっても恥ずかしいと思わない雰囲気を実現できてレクチャーし合う文化につながります!

最後に

実際のPJで試してみて、効果があった小さな工夫を紹介させていただきました。今後も効果があった改善案が生まれましたら紹介させて頂きます。

次世代システム研究室では、グループ全体のインテグレーションを支援してくれるアーキテクトを募集しています。アプリケーション開発の方、次世代システム研究室にご興味を持って頂ける方がいらっしゃいましたら、ぜひ 募集職種一覧 からご応募をお願いします。

皆さんのご応募をお待ちしています。

  • Twitter
  • Facebook
  • はてなブックマークに追加

グループ研究開発本部の最新情報をTwitterで配信中です。ぜひフォローください。

 
  • AI研究開発室
  • 大阪研究開発グループ