2024年の今、このプロジェクトを振り返る（2024 Advent Calendar 24日目）
この記事は私をシニアエンジニアにしてくれた「真のアジャイル開発」体験記の24日目の記事です。このアドベントカレンダーは「ある機能開発チームでスクラム, XP, DevOps を一度に実践したら真のアジャイル開発ができた」という内容です。執筆者は全てプログラミングをするパンダです。
プロジェクトを振り返る
ここまでスクラム、XP、DevOpsの定義と実践を解説してきました。リリースをした時、チームは達成感に包まれていました。総じてうまく行ったプロジェクトだったとチームメンバーみんなが実感しました。
元々「2,3週間後のゴールデンウィーク明けに出してほしい」と言われていた機能です。その中でも焦りから疲弊したメンバーもなく、ビジネス側も遅いから早く作ってくれと開発陣を責めることもありませんでした。
開発サイドとビジネスサイドが二人三脚で業務フローとそれを支援するシステムを構築したことは疑いありません。アジャイルソフトウェア開発宣言の「個人と対話」「動くソフトウェア」「顧客との協調」「変化への対応」の全てを実現できたと思いました。
さて、この機能のリリースをしてから2年半が経ちました。もう後日談を語れる時期です。リリース後に起きた失敗とよかったことを振り返ることで、また次に繋げたいと思います。
失敗を振り返る
まずは失敗を振り返ります。
本番で想定外のバグが一件出たため、急いで修正パッチを作ってリリースした
自分たちが作った機能は、社内メンバーが社員向けの管理画面から使うものでした。この機能は顧客情報に関わるものだったので、セキュリティチームに早い段階からスプリントレビューに参加してもらい、安全性の高い業務フローを構築したことはスプリントレビューの項目で紹介した通りです。これ以降、どんな機能だったか明言はしていないので想像で補ってお読みいただければと思います。
この機能を社内メンバーが2,3回ほど利用した時でした。この機能専用のalertチャンネルに通知が来ました。エラーが起きたらSlackに通知するようにしていたのです。エラーパターンはいくつか想定済みだったので、エラーメッセージにエラーの原因を記載しており、エンジニアに質問しなくても作業の担当社員が自分で復旧できるように運用フローも整備していました。。
しかし、今回のエラーは毛色が違いました。作業担当者がいくら自分の入力を見ても間違っていないというのです。そこでエンジニアにヘルプが求められました。自分たちから見ても確かに入力データに間違いはありません。コードにバグがあったかなと思って調べても正常に動作しているようです。
みんなでああでもない、こうでもないと議論していたところ、一人のエンジニアが閃きました。彼によると「自分たちはメールアドレスのバリデーションをするときに、RFCに準拠したプログラミング言語の標準関数を使っている。ここでエラーが出てるんだ。docomoやauの古いアドレスは、RFCに準拠していない古いものもあると聞いたことがある」とのこと。チームでさらに確認したところ、彼の説明は正しいことがわかりました。その後、急いでパッチを作ってリリースしました。
自分たちは、文字通り全てのクラスをTDD（テスト駆動開発）で実装しました。しっかりテストを書いているので大丈夫だと胸を張ってリリースをしたものの、それでも本番運用時にバグが出てしまいました。しかし、このバグはどうやったら最初から想定できたのだろう。いや、最初から想定することは無理だったのだろうか。私は自問を続けました。
この問題意識を抱えたままいくつかテストに関する記事を読んでいると、TDDは入力例を元に実装を進める設計手法でありテスト技法ではないため、想定外の入力ではバグが混入するという話や、そもそも本番でバグは起きると考えて、そのバグにいかに早く気づいて復旧するかが重要だというアイデアに出会いました。後者はDevOpsの平均復旧時間の話ですが、リリース前は自分の中でテストと結びついていなかったのです。
このことについて、以下の記事で詳しく解説をしました。
というよりも、以下の記事を執筆できたのは、この古いメールアドレスによって発生したバグがきっかけでした。自分の中で失敗だと思ったものの次に繋がった経験でした。
ビジネス側でスプレッドシートに手順書が作成されていた
これはまだ自分の中で解決策が見当たらないものです。社内の人が使うツールなので、直感的に使いやすい画面を作ろうと思ってUI/UXはかなり工夫をしました。
リリース後にたまたまビジネス側の人がその画面を操作するのを見るタイミングがありました。どうやって使っているのだろうと思って見ていると、なんとスプレッドシートで作られた手順書を逐一見ながら一つずつ慎重に操作をしていたのです。
確かに慎重になる気持ちはわかります。しかし、手順書を作るのも更新するのも手間ではあります。使いやすいように無駄な作業を減らすような画面を作ろうと頭を捻ったのに、フロントエンドに関わるものとしてその姿は少しショックでした。手順書があると画面に表示している説明も読み飛ばされるのだろうなと思いました。その説明も一文一文わかりやすいようにブラッシュアップしたものだったのですが...。
ただ、今から考えると業務で扱うソフトウェアと自分が趣味で使うソフトウェアの操作の重みは違うのだろうと思います。戻るボタンを押して全てをやり直せるものでもなく、担当者としては間違ったらどうなるかわからないがとりあえず面倒なことになると想像して慎重になるのでしょう。また、スプリントレビューに参加してくれていたビジネス側の方の仕事が忙しくなり、その業務が他の人に引き継がれたということも大きな原因だと思います。
この辺りは自分の中で明確な答えは持てていないです。ただ、リリース後に実際にどう使われるのかという視点は持ち続けないといけないと思いました。
それ以降の機能開発では本物の顧客参加を実現できていない
スプリントレビューでは社内のビジネス側の担当者を顧客として、社内ツールを一緒に作り上げていました。しかし、その後のプロジェクトの機能開発ではどれも顧客に開発中のものを見せることができず、またtoCという性質のため顧客と一言でいっても様々な属性の方がいます。その結果、ユーザーインタビューやヒアリングをしているプロダクトオーナーを顧客に見立てて、スプリントレビューでソフトウェアに対するフィードバックをもらうようになりました。
しかし、プロダクトオーナーは仕様策定をする上に、デザイナーとUI/UXの検討をしています。するとプロダクトオーナーは顧客よりも機能について知りすぎている上に、実際の顧客のユースケースと乖離した場面を想定することもあり得ます。頭の中で構築した仮説は、顧客だけが直面している前提を含んでいないtまえ、だいたい間違っているというのが私の持論です。プロダクトオーナーはどうしても顧客の代表にはなれないのです。
自分がエンジニアとして入社したどの会社でもユーザーインタビューは実施されたりされなかったりでした。実施されなかったから誰かがサボっているというつもりは全くありません。ただ、ユーザーに自分たちの開発中の機能を使ってもらってフィードバックを得られることはかなり稀だと感じています。このため、社内ツールの開発で得た経験は貴重だと思うと同時に、機会があればその状況を再現したいと常に思っています。
よかったことを振り返る
他にも良かったことを振り返ります。
機能拡張の際に「改修しやすい」と褒めてもらえた
XPの「インクリメンタルな設計」の項目でリファクタリングについて触れました。自分はプルリクエストをマージした後も、より良い設計はないかと常にリファクタリングの機会を伺っていました。このため、開発全体を通してクラスや処理が追加されてもシンプルな設計を保ち続けられたと思います。
機能のリリース後、ビジネス側から機能追加の要望が上がってきました。エンジニアリングマネージャーはその話を聞いて、優先度の高いところにエンジニアを当てたいから業務委託の人を採用してその追加対応だけやってもらおうと判断しました。
実際、マネージャーは業務委託の方と契約をして機能追加の依頼をし、自分たちはコードレビューを任されました。果たしてどうなるだろうかとアサインされたプルリクエストを見てみると、コードの意図を読み取ってもらえて自然なコードになっていました。自分たちからはこうやって作ってくださいと説明することはなかったのに、です。
元々バリエーションがあるコードだったので、そのバリエーションを追加してくださいという依頼だったこと、明らかにここから処理が始まってここでバリエーションの分岐をしているのだとわかる設計にしていたことが功を奏しました。コードレビューの負担も少なく、些細な点だけを指摘するだけで済みました。何度かコードレビューをするうちに機能は完成していました。
後からマネージャーが教えてくれたのですが、その業務委託の方は「設計がわかりやすかったのでコーディングをスムーズに進められた」と言ってくださったそうです。リファクタリングを繰り返し実施して良かった思えた瞬間でした。
シニアエンジニアとして役職を貰えた
このアドベントカレンダーは「私をシニアエンジニアにしてくれた「真のアジャイル開発」体験記」です。自分はこの機能をリリースした後、シニアエンジニアという役職を貰いました。自分の実力はまだそこまでのものではないと思っていたので、肩書をもらえたことに驚きました。
確かに開発プロジェクトの間のマネージャーとの1on1で、「パンダさんのペアプロの相手が勉強になる、前向きに仕事に向き合える、と言っていましたよ」とフィードバックを貰っていました。しかし、自分はありがたいと思いつつ、それは自分の力でもなんでもなくてみんなで燃え尽きずにうまく開発を進めたいという気持ちと、XPやDevOpsを文字通りエクストリームに全部実践してみたらどうなるのかという好奇心から来たものでした。
このため、自分が何かを成し遂げたのだと思うことは全くなく、ただ偉大な先人たちがこれをやるとうまくいくよと伝えてくれたプラクティスを実践しているだけだという気持ちで望んでいただけでした。その後しばらくはシニアエンジニアが自分の身に余る肩書きだ、何をすればこの肩書きに見合ったエンジニアになれるのかと葛藤しながら仕事を進めていくことになりますが、それはまた別の話です。
とにもかくにも、このように肩書をつけてもらって評価していただいたことには感謝しています。これも良いメンバーに恵まれたプロジェクトだったからだと今でも思っています。
このPJに関わったエンジニア全員が活躍している
実は2024年の末に社内の人事が発表されました。その異動表を見て私は驚きました。なんと、このアドベントカレンダーで紹介してきたプロジェクトで一緒に開発していたエンジニアのうち2人が昇進して役職をもらったのです。
このプロジェクトでは合計5名のエンジニアが参加していました。残りの2人のうち、1人は今年の四半期のMVPを獲得していました。もう1人は業務委託の方で、その方が所属している会社の都合で去年退職されていました。しかし、正社員として残っているエンジニアは漏れなく社内で活躍しているのです。
さらに当時のプロダクトオーナーは、他のプロダクトオーナーのマネージャーに昇進しました（社内ではPdMのマネージャー）。エンジニアリングマネージャーもこのプロジェクトをきっかけに、当時社内でまだあまり実践されていなかったスクラム開発に成功したマネージャーとして一目置かれています。
ソフトウェア開発においては、まずはソフトウェアを使ってくれる顧客の喜びが一番です。開発プロジェクトの成功はそれに左右されると言っても過言ではありません。しかし、作る側も社内で評価されるということはなんとも嬉しいことではありませんか。
自分はプロジェクトで関わった人が幸せになったらいいなと思いながら仕事をしています。このプロジェクトが終わってから時間が経っているため、あの時の影響はどれだけ残っているかわかりません。また本人が頑張っているということが一番大きな理由ではあります。ただ、あの時一緒に働いた人たちが活躍していること、その活躍が人に認められていることほど嬉しいことはありません。良い開発は良い結果につながるのだと改めて実感しました。
今回はプロジェクトのその後を振り返りました。次は今の自分がチーム作りで意識していることを紹介して、このアドベントカレンダーのまとめとします。
Happy Coding 🎉
