この記事はユニファAdvent Calendar 2022の16日目の記事です。 🎄
こんにちは。プロダクトエンジニアリング部の安田です。今回は、リリースまでの各段階で自分がやってみている小さな工夫達について書こうと思います。
こんな工夫もあるんだなーというくらいの参考になったら嬉しいです。それでは始めます。 🙇🏻♂️
リリースまでのフローイメージ
要件定義
開発者が最初に触れる部分の工程かなと思います。 最初の部分なのですが、個人的に要件定義ほど難しい作業はリリースまでの一連の作業でないのではないかと思うくらい難しいことだと思っています。 上に添付した図のようにチームが別れている場合ですと、難易度がさらに上がる認識でいます。 ここの部分で開発者としてどういった頑張りができるかですが、
- 優先度の高い機能要件/非機能要件を絞り込むためのコミュニケーションに参加する
- 今あるシステム環境についての状態をきちんと把握し、チームに説明をする
「優先度の高い」というのが難しい点*1ですが、何が作る機能の核となる機能なのかというのを認識が合うまで徹底的にコミュニケーションを繰り返していくのを頑張ると、「結局〇〇があればいいんだよね」「▲▲が無いと■■があっても意味ないね」などとチームの中で作る機能の解像度が上がっていくのを感じます。
一方でこの部分をおろそかにすると、作ったものが個人のイメージに近いものになってしまう危険性があがり、皆頑張ったのに全然リリースまで持っていけないとなることが多いように感じます。
システム環境についての説明をすることによって実現可能性についてや優先度をつけやすくなるため、早めに共有するのが全体のためになるのでこのタイミングで行います。
工数見積もり
ユニファでは、要件定義を行いつつ、大枠が見えた時点で、エンジニアは「見積もり」という作業に入ります。 🚗
どれくらいの期間で、この機能を実装できるかな、の概算になります。 全ての要件定義・仕様の確定が終わってる状態でこの見積もりを出せたらいいのですが、多くの場合そうではありません。 まだ決まってないことが残っていることが一般的かと思います。 自分が行っている工夫としては、
- 自分の得意（もしくは、知見があること）な領域、苦手（もしくは、知見がないこと）な領域を知る
- その時に見積もれないこと、解らないところは、見積もり不可、解らないということを明記する勇気を持つ。*2
- なるべく作業を細かく分けて工数を見積もる。
自分が得意なこと、苦手なことを知っていると、ここの部分はあまり時間がかからなそうだな、とか、ここの部分は時間かかりそうなど、完成までにどこに時間がかかって、どこはサクサク進めそうなのかの道筋が自分の中で見えてきます。
苦手な領域についての作業は「何だか解らないけど大丈夫だろう 」という気持ちで小さな工数をつけるよりも、多めに工数を見積もることで、作業に入ってから全然終わらずリリース期日に影響が出るということのリスクを少しだけ減らせます。でもここの部分は、一緒にサービスを作っている他のチームメンバーの理解*3が必要な部分だと思っています。幸いなことに今のチームでは、ここの部分の理解をいただいており、勇気と責任感を持って正直な数字を共有することができています。
細かく作業をわけると、それぞれの仕様変更の修正も受け止めやすくなりますし、大雑把な見積もりをしにくくなるので、細かく分けます。 ストーリーベースで分けたり、機能ベースで分けたりあると思いますが、自分は機能ベースでわけています。
例）要件：大人一人が乗車することのできる自転車
- タイヤを作る
- ハンドルを作る
- 自転車の枠組みを作る
- ベルを作る
- 座る椅子を作る
- ブレーキを作る
- 自転車を組み立てる
- 大人が乗っても壊れないようにする
- タイヤに空気を入れられるようにする
- ベルが鳴るようにする
- ブレーキがかかるようにする
皆さんだったらどういう風に作業を分けるでしょうか、もっと項目数が多い、もしくは少ないなどあると思います。進めやすいやり方は人によって違うと思うので、これが正解ではないです。 🙇🏻♂️
実装
見積もりが終わって、作業を開始して良い状態になり次第、実際に機能を作るための手を動かし始めます。 🐣
忘れてはならないのは、「後は作るだけ！」という状態ではないこともあるので、「もう自分は開発だけやってたらいいんだ！」ではなくて引き続き、決まっていない要件定義の部分を確定させるためのチームの仕事には一生懸命参加します。 実装に入って序盤ほど、マルチタスクになりがちな期間なので時間の使い方が毎回難しい部分になってきます。
この段階の工夫としては、
- 何をやるか決まっていて難しいところを先に手を付ける
- 何をやるか解らないけど、やるとしたら難しいところの調査を早めに行う
- どれも同じくらいの難易度だと自分が感じるなら、仕様が固まっている箇所から着手する
- 想定より時間がかかるのを感じたら、動くものをまずは作ることに集中する。その後綺麗にするタスクをしっかり残して、QA開始までに後追いで終わらせる。
- 途中経過を定期的にチームに共有する。特に悪い知らせは早めにする。
避けたいのは、時間が経ってリリース日が近づいたけど、終わってない。。という状態なので、それを避けるためにできることを全部やります。
検証環境でのQA実施
リリースまでもう少しになってきました。QA実施によって、しっかりと最後の確認作業を行います。 QAエンジニアの方と、Pdmの方との、どこを見るべきかの擦り合わせにも必要があれば参加します。 この時点では、まだいくつかのエンジニアだけが知っている仕様、つまり仕様書に記載のない要件というものが残されている可能性があります。その部分もしっかりとこの擦り合わせで拾います。
- ここが気になる、ここが不安などは早めに相談する
- 不具合として報告されたものはなるべく早めに詳細を確認し、どれくらいのものかをチームに返答する。その後、修正する。
本番へのリリース
ついにいよいよリリースです！ここまでの皆の頑張りが実る時が来ました！
最後の段階です！やっている工夫としては、
- リリース手順が複雑であればあるほど準備をしっかりする。
- 必要に応じて事前の報連相を各所へ忘れずに行う。
リリース作業に慣れた頃がミスが起きる可能性があると思ってるので、丁寧に丁寧に準備をします。連絡も忘れずに！ 皆でリリースを喜びましょう！
最後に。何よりも大事なこと
ここに記載したものは、エンジニアが書いてるので、エンジニア目線での工夫になりますが、他のメンバーの協力や優しさ、理解なくしては工夫すら満足にできないです。関わる全員の努力の結果としてリリースは行われています。
リリース工程の終盤にいるからこそ、サービスへの情熱と、一緒にサービスを作っている仲間への感謝の気持ちと尊敬を忘れないことが個人的にエンジニアには大事だと思います。
これがなくなってしまうと、どんな工夫をしても、リリースはできても、いいサービスは作れません。 いいサービスを届けていけるいいチームがこれからも世の中に沢山できたらいいなと思います。
ユニファでは新しい仲間を募集中です！！ 🌟
