プログラマー一年目の最大の学びは「手順書を書くこと」

これは「フィヨルドブートキャンプ Part 2 Advent Calendar 2020」の20日目の記事です。

昨日は@beta_chelseaさんの「すばやく確認OKをもらうためのセルフレビュー」でした。 セルフレビュー＆レビュー時に気をつけるべきポイントが具体的にまとめられていて、とても参考になります！どんなに気をつけているつもりでも、どんなに間違えようがないと思っていても、自分のPRを改めて見直すと大体一箇所はtypoとかが紛れ込んでいます。実装者とレビュアー、両方の時間と集中力を無駄にしないよう、自分もセルフレビューを怠らないようにしていきたいです！

はじめに

自分は2020年3月にフィヨルドブートキャンプを卒業して、プログラマーとして株式会社ラグザイアという受託開発の会社に入社しました。

プログラマーになって初めての年末を迎え、この一年を振り返ってみると、色々大変なこともあったにせよ、やっぱりプログラマーに転職してよかったし、そのための勉強の場としてフィヨルドブートキャンプを選んで本当によかったなぁとしみじみ思う今日この頃です。

そしてこの一年は本当に多くのことを学んだ一年だったのですが、今回は自分にとって就職以降最大の学びである「手順書を書く」ことについて、体験談と併せてまとめたいと思います。

ことの始まり

今年の9月くらいからアサインされた案件で、約30個のAPIを作成する機会がありました。

あまり複雑な要件ではなかったのですが、新規の案件だった（既存コードがない）ことや、未経験の要素がいくつかあったため、最初の枠組み作りで思った以上の時間を使ってしまいました。それでもどうにか頑張って大体の枠組みが出来上がり、さああとはバシバシAPIを追加していくぞ、という段階に入りました。

基本的には各API毎に同じようなコードのセットを追加していくだけなので、基本コピペの単純作業・・・と思っていたのですが、いざPRを出してみると、必要なバリデーションが一部漏れていたり、コピペ元の名残が紛れ込んでいたりして、なかなかスムーズにマージされない状況が続きました。

スケジュール的にも明らかな遅れが出始めたので焦りが募り、最終的にはリベースにミスってデグレが発生し、追加作業が発生してさらに遅れて、そのせいで余計に焦って・・・という悪循環に陥り始めました。

面談でアドバイスをもらった

そんなとき、ちょうど月一で実施している社内の先輩との面談があったので、そこで上記の状況を説明して相談してみました。

「自分としてはスクリプト作った方がいいと思うんですが、それはそれで時間かかりそうなので、どうしたもんかと・・・」と言うと、先輩は「スクリプトもいいと思うけど、それより先にチェックリスト作った方がいいかもね」と助言してくれました。

先輩曰く、チェックリストならスクリプトほど時間かけずに作れるし、スクリプトを作るにしてもやることが洗い出されていた方が作りやすいはず、とのこと。

なるほど！！！！！

つくってみたらそれは（結構なボリュームの）手順書だった

アドバイスを受けて、さっそくチェックリストを作っていきました。

仕様書を読みつつ、APIを追加するときの作業を思い浮かべて、必要そうなことを一通り書き出してみたものの、なんかスカスカしている気がします。やっぱり手を動かしながら書いてみないと漏れがありそうだ、と思い、今度は作業しながらひとつひとつ項目を足していきました。

すると、必要な作業が順番にリストアップされた作業手順書が出来上がりました（当たり前ですが）。

自分が書いた手順書を見て自分でびっくりしたのですが、「基本コピペの単純作業」と思っていた一連の作業は、リストアップしてみると実は30を超える手順からなる、なかなかに複雑な作業だったのです。自分は自分の作業を過小評価する傾向があるということがよくわかりました。

そんなわけで、チェックリストを作るつもりがいつの間にか手順書になってしまったのですが、これが絶大な効果を発揮してくれました。

（ちなみにチェックリストを作らなかったわけではなく、手順書の中にチェック項目を箇条書きで埋め込む感じにしました。あと結局スクリプトも並行して書きました。）

手順書を書いた途端作業が楽になった

手順書を用意したことで、一番最初に感じたメリットは、なんと言っても「次にやることを思い出さなくていい」ことでした。手順書がない状態だと、「・・・で、次何やるんだっけ・・・ああ○○を足すのか・・・」という思考を挟まないと作業が進まないのですが、手順書があればその必要がなくなります。手順が3つくらいなら書き出すまでもないかもしれませんが、30以上の手順となると、テキストに起こされているかどうかで全然違うと思いました。

また、無駄な思考を挟まなくて良くなったおかげで、自分の疲労度もだいぶ減ったし、逆に終業間際の疲れていて時間もないという状況でもミスが発生しづらくなりました。疲労軽減により余裕を持ってセルフレビューできるようになり、アウトプットの品質が一定以上に保たれ、PRがスムーズにマージされていくようになりました。

実際、手順書を作る前まではAPI一つ追加するのに一日以上かかることもあったのですが、手順書を用意してからは複数件安定して追加できるようになりました。

また、手順書を作ったおかげで、別の作業をしてから再度APIの追加作業に戻るのもとてもスムーズになりました。例えばあるAPIを作成途中に、前に出したPRにコメントが付けられて、そちらを先に対応したいという場合でも、手順書の今行なっている作業のところに印をつけておけば、一旦手を離してもスムーズに作業が再開できます（製造業で言うところの「仕掛り」のイメージ）。

あるいは、一通りのAPI追加が終わって別の機能追加に着手したのち、仕様が修正されて新しいAPIの追加が必要になった場合も（実際そういう場面がありました）、手順書があれば頑張って手順を思い出す必要もなく、楽にAPIを追加できました。

フィヨルドで勉強してたとき、もっと〇〇しておけばよかった

今回の件で「フィヨルドの時にもっとこうしておけばよかった」ということが２つあるので、それも書いておきます。

まず一つめは、「質問することにもっと慣れておけばよかった」ということです。幸いにも就職した会社に月一の面談制度があったからどうにかなりましたが、もしも面談制度がなかったら？そもそも月一の面談を待たずに誰かしらに相談できていればもっと解決が早かったかもしれません。

自分はまだ質問したり誰かを頼ることにためらいがあって、それはやっぱりちょっと恥ずかしいとか、自分で黙々とやった方が気が楽とか色々な思いからなのですが、仕事する上では早めにヘルプを出せた方がやっぱり効率がいいと思います。特に、コロナでリモート勤務が続く情勢下では、テキストでぽんぽん質問を投げられたら色々楽になると思います。

フィヨルドにはQ&AもSlackもあるし、そういうところでもっと気軽に発言して、慣れておけばよかったなぁと思います。

そして二つめは、「効率化のための工夫を色々試してみればよかった」ということです。フィヨルドのカリキュラムはすごく実践的で、特にスクラム開発はほぼ開発業務そのものですが、実際の業務との唯一の違いは納期がないことです。自分はわりとのんびり勉強を進めてしまってましたが、個人的にでも締め切りを設定して、それに間に合わせるための工夫をしておけば、業務に入ったときに納期に追われて焦る気持ちを和らげることができたかもなぁと思います。

とはいえ、そういうことがちょっと不十分だったにしても、業務をしながらでも改善していけてるので、「まあいっか」とも思います。この二つは個人的な課題として、もっとうまくやれるように来年以降も意識していきたいです。

最後に

以上、手順書を書いたら幸せになったというお話でした。ちなみに案件の方はギリギリでしたが期限内に納品でき、ひとまずめでたしめでたしでした。

ただ、本当にギリギリだったので、やっぱりもっと作業スピードをあげたいし、自分の作業時間の見積もりをちゃんとできるようになりたいです。

色々課題もありますが、それでもやっぱりプログラミングは楽しくて、最初に書いた通りプログラマーになってよかったなぁと感じます。

来年も楽しく仕事して成長していきたいと思います！