多忙な開発業務の中でも常に意識すべきこと

Engineer Life

日々の開発業務の中で、納期は年々短くなるが、やることだけはどんどん増えていっている。

なので、どうしても目の前のタスクのみに追われてしまうこともありますが、

今回はそのような多忙な日々の中でも、常に意識すべきことを紹介致します。

先に結論を言うと以下となります。

  1. ソフトウェアの修正ネタをメモする
  2. 後輩の面倒を見る
  3. 最低限の設計資料を残す

1. ソフトウェアの修正ネタをメモする

f:id:ki-ki-blog:20191222075454j:plain

コーディングしているとき、こんなことがあるかと思います。

  • 「ここ、なんでこんな実装してんの」
  • 「もっとこうすればいいのに・・・」

例えば、ある機能を実装しているときに、

「その機能自体は実現可能なコーディングはできたのですが、出来上がったソフトの保守性があまりよろしくなく、もう少しここをこういう風に変えればもっときれいなコードになる」、

と、言うようなことがソフトウェア技術者にはよくあるかと思います。

時間があればもちろんコードを修正したいのだが、

  • 納期が迫っている・・・
  • コード変更によるデグレートがこわい・・・

このような時、ひとまずその修正ネタをタスクとして作業メモに残しておくことをお勧めします。

理由:ふとした機会にさっとソフト修正できるから

都度メモをとれば、そのことは一旦忘れて、要求機能の実現など、今やらないといけないタスクに集中することができます。

で、次の納入機会などでそのメモを見返し、すぐやれそうなところからコード修正するとよいかと思います。

具体例:似て非なる機能実装の際に作業メモが役に立った

A製品のID登録機能のコーディングをした後、B製品のIDの登録機能の実装の話が出てきました。

コードとしては、A機能、B機能非常に似ており、先に実装したA機能のコードをベースにできそうです。

そこで、

  1. 作業メモを元にA機能のコードを修正
  2. 修正されたA機能をライブラリ化

このような手順を踏むことで、B機能を無事に素早くコード実装できました。

もし作業メモがなかったら、品質の悪いB機能のコードが新たに出来上がり、より保守性の悪いソフトウェアとなってしまったことでしょう。。。

また、テスターや後輩が、

  • 「動作に影響はないが、今の製品動作はこんな動きになってしまっている」

と、言うような指摘をしてくれることもよくあります。

このような時も、作業メモを残すことで、一旦は今やらないといけないことに集中して、納入が終わったら次の納入までに対応するのが良いかと思います。 

気づいた時点でソース修正すればよいのでは?

よい実装方法が思いついた時点で、即コード修正すれば、メモをとるようなめんどくさいことはしなくてもよいという考えもあります。

もちろん、それが許される環境ならそれに越したことはないです。

とはいえ、やはりそのような

「保守性を高めるコード修正」

よりも、優先度の高いタスクが必ず存在すると思うので、

まずはそのようなタスクから片付けていったほうが良いのかなと思います。

2. 後輩の面倒を見る

f:id:ki-ki-blog:20191222075404j:plain

忙しいとき、こんなことありませんか。

  • 後輩が質問に来る
  • 後輩に仕事をお願いしたが、正直自分でやったほうが早い

多忙なので、正直こんなことしてる余裕ないのはよくわかるのですが、

それでもそれなりに時間を使ってでも、後輩の面倒はしっかりと見たほうがいいと思います。

理由:将来的に自分の助けとなるから

今は仕事ができなても、教育をしながら面倒を見続けることで後輩自身が成長し、結果として自分の作業を肩代わりしてくれるようになるからです。

じゃあ後輩の質問には必ず向き合うのか?

  • 1日中質問だらけ
  • 同じことを何回も聞いてくる

このような後輩はもちろん論外ですが、最初に少し教えて動いてくれるのであれば、いってみれば人材育成の先行投資にあるのかと思います。

なので、忙しい時こそ色々お願いしてみましょう。

3. 最低限の設計資料を残す

f:id:ki-ki-blog:20191222075341j:plain

突然ですが、

  1. 設計書なしでいきなりコーディング開始
  2. 動くコードはできたが、コードの中身は汚い
  3. 修正の度により醜いコードになっていく

こんな感じで、忙しいときの負のスパイラルに陥ったことってないですかね。

これ、最初にきちんと仕様書なり設計書なりを作成しなかったのが原因です。

なので、完璧でなくても良いので、例えば状態遷移図ぐらいは最低でも書いた方が良いかと思います。

また、完璧でなくてもよいので設計書を書いておくと、2つ利点があります。

テスターがテスト仕様をより正確に定義できる

例えば、テスト仕様書作成の際の入力文書が、顧客からの要求しかないと、おおざっぱなテスト検査しか作れず、細かいテストケースが出せません。

もちろん、システムテスト工程まで行けば、客先からの要求書レベルでも可能なのですが、その工程より前、即ちソフトを結合した後で行うテストでは、やはり詳細設計書をある程度参照しながらテストケースを作る必要があるのではと思います。

他チームへの作業ヘルプが容易となる

設計資料がないがために、せっかくヘルプに入ってくれたメンバが、

  • テスト対象製品の動作を理解するのに時間がかかった
  • 上記が理由で限定的な作業しかお願いできなかった

なんてことがありました。。。

なので、こんな苦い経験を今後はしないためにも、こんな時こそ、設計資料を残してみてはどうでしょうか。

もちろん、すべてを網羅した設計資料を何が何でも用意しないといけない、というわけではありません。

 最後に

f:id:ki-ki-blog:20191222080427j:plain

以上、目の前の作業に没頭しつつやるべきことを紹介してみました。

まとめると以下となります。

  • ソフトウェアの修正ネタをメモする
  • 後輩の面倒を見る
  • 最低限の設計資料を残す

全部自分の実体験に基づき、苦い経験を赤裸々に語った内容となりますが、こうならないためにもぜひ参考にしてみてください。