多忙な開発業務の中でも将来への「仕込み」をしよう【後々楽になる】
エンジニアの方：
いつも仕事が忙しい。すぐに人が増えたり、優秀な人がくるといいんだけど、そんなことは
さすがに非現実的。でも、日々の業務を少しでも楽にする方法はないかなぁ？
日々の開発業務の中で、納期は年々短くなるが、やることだけはどんどん増えていってしまいますよね。
なので、どうしても目の前のタスクのみに追われてしまうこともありますが、
今回はそのような多忙な日々の中でも、常に意識すべきことを解説致します。
現在も数々の開発をこなす日々の中で、自分及びチームをより楽にするべく、極力新人や後輩を育てたり、ドキュメントを残すことを意識、行動している
多忙な開発業務の中でも将来への「仕込み」をしよう【後々楽になる】
先に結論を言うと以下となります。
- ソフトウェアの修正ネタをメモする
- 後輩の面倒を見る
- 最低限の設計資料を残す
ソフトウェアの修正ネタをメモする
コーディングしているとき、こんなことがあるかと思います。
- 「ここ、なんでこんな実装してんの」
- 「もっとこうすればいいのに・・・」
例えば、ある機能を実装しているときに、
「その機能自体は実現可能なコーディングはできたのですが、出来上がったソフトの保守性があまりよろしくなく、もう少しここをこういう風に変えればもっときれいなコードになる」、
と、言うようなことがソフトウェア技術者にはよくあるかと思います。
時間があればもちろんコードを修正したいのだが、
- 納期が迫っている・・・
- コード変更によるデグレートがこわい・・・
このような時、ひとまずその修正ネタをタスクとして作業メモに残しておきましょう。
なぜなら、ふとした機会にさっとソフト修正できるからです。
都度メモをとれば、
- そのことは一旦忘れる
- 今やらないといけないタスクに集中する
- 次の納入機会などでそのメモを見返す
- すぐやれそうなところからコード修正する
こうすることで、多忙な時にはできなかった作業を、後々に行うことが可能となり、以降のソフトの保守性が増します。
実体験：似て非なる機能実装の際に作業メモが役に立った
A製品のID登録機能のコーディングをした後、B製品のIDの登録機能の実装の話が出てきました。
コードとしては、A機能、B機能非常に似ており、先に実装したA機能のコードをベースにできそうです。
そこで、
- 作業メモを元にA機能のコードを修正
- 修正されたA機能をライブラリ化
このような手順を踏むことで、B機能を無事に素早くコード実装できました。
もし作業メモがなかったら、品質の悪いB機能のコードが新たに出来上がり、より保守性の悪いソフトウェアとなってしまったことでしょう。。。
「動作に影響はないが、今の製品動作はこんな動きになってしまっている」
と、言うような指摘をしてくれることって、普段開発業務をしていてよくありますよね。
このような時も、作業メモを残すことで、一旦は今やらないといけないことに集中して、納入が終わったら次の納入までに対応するのが可能となります。
なので、低優先なテストNG項目もきちんとメモで残すことで、以降で対応が可能となります。
気づいた時点でソース修正すればよいのでは？
ここまで書くと、
「そんなメモを残して、あとからそれを対応するのでなく、低優先項目でも、即コード修正すれば、いちちメモをとるようなめんどくさいことはしなくてもよいのでは？」
と、いう考えもでることが予想されます。
もちろん、それが許される環境ならそれに越したことはないです。
その場で即修正したほうが早いので。
とはいえ、やはりそのような
「保守性を高めるコード修正」
よりも、目の前にはもっと優先度の高いタスクが存在するのではないでしょうか。
まずはそのようなタスクから片付けていったほうが良いのかなと。
なので、やはりこれまでに解説した作業メモを残すことは有効ではないでしょうか。
後輩の面倒を見る
忙しいとき、こんなことありませんか。
- 後輩が質問に来る
- 後輩に仕事をお願いしたが、正直自分でやったほうが早い
多忙なので、正直こんなことしてる余裕ないのはよくわかるのですが、
それでもそれなりに時間を使ってでも、後輩の面倒はしっかりと見たほうがよいです。
なぜなら、後輩を育てることで、それが将来的に自分の助けとなるからです。
今は仕事ができなくても、
- 教育をしながら面倒を見続ける
- 後輩自身が成長
- 自分の作業を肩代わりしてくれる
このように、最初は苦労しても、結果としてそれが実となり、結果として自分にいい意味で返ってきます。
- 1日中質問だらけ
- 同じことを何回も聞いてくる
このような後輩はもちろん論外ですが、それを注意して矯正しつつ、人材育成の先行投資として、できるだけ後輩にどんどん仕事を教えていきましょう。
そうすることで、先ほど書いた通り、それが実となる日がきます。
なので、後輩には、忙しい時こそ色々お願いしてみましょう。
体験談：質問ばかりで手の遅かった高卒新人が化けた
職場にこんな子が入ってきました。
- 高卒
- 作業遅い
- 質問多い
- とにかく石橋を叩いて渡る
こんな感じの子です。
そして、配属されたのは、客先イベント前の超多忙な時期。
とりあえず、テスト作業をお願いしました。
最初は上記のような性格なので、正直いらっとしながら一緒に仕事してましたが、そこをぐっとこらえて、多忙でも質問にはなるべく答えるようにし、お願いできることはどんどんお願いしてみました。
その結果、１年足らずで、テスト仕様さえ出せば、きっちり、かつ素早くその内容通りにテストできるようになり、今では大変重宝しています。
多忙な時期に、イラっとして何もしなかったら、今頃どうなっていたことか。
この経験から、多忙でも後輩の面倒は見た方がよいと考えるようになりました。
最低限の設計資料を残す
突然ですが、
- 設計書なしでいきなりコーディング開始
- 動くコードはできたが、コードの中身は汚い
- 修正の度により醜いコードになっていく
こんな感じで、忙しいときの負のスパイラルに陥ったことってないですかね。
なんでこうなるか。それは、最初にきちんと仕様書なり設計書なりを作成しなかったのが原因です。
なので、完璧でなくても良いので、例えば状態遷移図ぐらいは最低でも書いた方が良いでしょう。
また、このように完璧でなくてもよいので設計書を書いておく利点は2つあります。
- テスターがテスト仕様をより正確に定義できる
- 他チームへの作業ヘルプが容易となる
もちろん、システムテスト工程まで行けば、客先からの要求書レベルでも可能なのですが、その工程より前、即ちソフトを結合した後で行うテストでは、やはり詳細設計書をある程度参照しながらテストケースを作る必要があるのではないでしょうか。
テスト対象製品の動作を理解するのに時間がかかった
上記が理由で限定的な作業しかお願いできなかった
なんてことがありました。。。
なので、こんな苦い経験を今後はしないためにも、こんな時こそ、設計資料を残してみてはどうでしょうか。
とはいえ、すべてを網羅した設計資料の作成はキビシイ
ここまで書くと、
「他者からヘルプしてもらったときや、テスターのために、仕様書や設計書はきちんと詳細レベルで必要ではないのか」
と、いう考えがでることが予想されます。
確かに、詳細で完璧な仕様書なり設計書があるに越したことはありませんが、日々の開発業務で、そのレベルのドキュメントを残す余力は果たしてどれだけありますでしょうか。
きっと、そんな開発ってあまりないのでは。。。
なので、やはりまずは、最低限の設計資料を残すことを意識すればよいのかなと。
と、いうことで多忙な開発業務の中でも将来への「仕込み」をしよう
以上、目の前の作業に没頭しつつやるべきことを解説しました。
まとめると以下となります。
- ソフトウェアの修正ネタをメモする
- 後輩の面倒を見る
- 最低限の設計資料を残す
全部自分の実体験に基づき、苦い経験を赤裸々に語った内容となりますが、こうならないためにもぜひ参考にしてみてください。
今回は以上です。