はじめに
本記事はNSSOL Advent Calendar 2024の6日目の記事です。
私は5年目のSEです。最近アジャイル案件に初めて入ったのでこの記事に所感を記します。
前置き。やりたいことがあることが積極性なのか？
新入社員時代、配属面談で答えたことがやけに記憶に残っている。人事の方から入りたい事業部や、やりたい分野について聞かれた。私は、「配属にあたって私の興味関心のようなものが考慮されるべきではないと思うし、事業部に優劣がないのであれば、どこでもいいです」みたいなことを答えた。
正直、当時はこう答えたことについて少し不本意だった。明確にやりたいことや担当したい業界のある人がかっこよく見えたし、それが積極性だと思っていた。「どこでもいいです」が消極的な態度に思え、そう評価されていたら嫌だなとも思っていた。
配属されて数年後にアジャイルをやってみたいと思えたときは、自分にもやりたいことができたと嬉しく感じた。その時から仕事の進め方やユーザーとの接し方に興味を持ち、今も継続している。今でもどういう分野や業界の仕事をしたいかはどうでもいいけれど。積極的な人事へのアピールが功を奏し、アジャイル案件の実行やアジャイル人材の育成をしている部署に異動することができた。そのころは資格を取ってみたり本を読んでみたり、研修に参加したり、社内のコミュニティでドキドキの中初めて発信してみたりと、ある種、衝動だった。
ところが最近、できること（CAN）、しなければならないこと（MUST）を無視して自分のやりたいこと（WILL）を押し通すような人に対して警鐘を鳴らすような議論を見かけた。
過去の、会社から期待されたMUSTを重視した自分が報われた気持ちになったと同時に、ようやっと手にした積極性は誤っていたのかとも考えるようになった。そこら辺は、まぁアジャイルをやっていくことは会社としても求めていることでしょ、と私のWILLとMUSTはニアリーイコールだろうと思い込みむことで片づけた。この考えで合っているといいなと思いながらここに残している。
（余談）また、最近は仕事なんて楽しくも、やりたくもある必要ないなと思い始めている。楽しかったりやりたいことを仕事にしても、どうしても絶対楽しくなく、やりたくない仕事は発生する。それでもやらなければならない。お金を貰ってやっている仕事だから。楽しくなくてやりたくない仕事をやらないようになってしまうくらいなら、最初から楽しくなくていいなと思えてきた。もちろん、今の仕事は楽しくてずっとやりたいくらいだけど、それらを優先することの危険性も見えてきた。楽しくはないし、積極的にやりたいとは思えないけど、決してつまらなくはないし、やりたくないわけでもない仕事をあえてしてみるのもありだな。
アジャイル初めてみた
きっかけ
入社から3年半はWFの案件に参画していた。大きい声では言えないが、正解のWFをやっているとは思えなかった。下流工程に入っても度々発生する仕様変更に、これはWFを正しくできていないのか、WFという手法の限界なのか、と頭を巡らせていた。仮に限界的なことであれば、他の手法ならどうなるのだろうと、選択肢を増やす意味で別の手法に興味を持った。実態として製作中も頻繁にユーザーと会話をして仕様を決めて（変更して）いたのだが、これはWFとして正しくないだろう、それであれば正しく柔軟に変更を受け入れる手法を取りたい、といった次第だ。
やってみてどうだったか
一口にアジャイルと言っても様々な手法がある。そもそもアジャイルはマインドであって具体的な開発手法ではないのだが。私は今スクラムを適用（適用という言葉がふさわしいかは疑問。使用？）した案件に開発者として参画している。
使用する技術要素から担当するシステムの内容から、進め方から何もかもが今までと異なるため、1年目に戻った気持ちで仕事をしている。今までと異なることはたくさんあるが、いくつか絞って紹介する。割と月並みな内容になってしまった気がする。
振り返りがとても重要である
やはりアジャイルの醍醐味というか特徴の一つはフィードバックループにより改善をし続けることだろう。今まではめったに振り返りなんてしていなかった。個人単位の振り返りは半年に一度上司とだけだし、チーム単位の振り返りはやった覚えがない。
スクラムでは毎スプリント末にスプリントレトロスペクティブで今回のスプリントがどのように進んだかを検査し、⾃分たちの効果を改善するために最も役⽴つ変更を特定する。
要は振り返りによる改善なわけだが、定期的な振り返りをやる効果は絶大だと感じている。振り返りをしなければ問題の把握ができないため、改善に至ることができない。また、問題を何かしらのタイミングで認識できたとしても、チームとしての問題と受け止められない可能性が高い。以前の案件でもチーム開発はしていたが、フェーズによる分業が前提の開発だと個人の問題として捉えられていた気がする。
ユーザーからのフィードバックを受け柔軟に変更ができる
スクラムでは毎スプリント末にスプリントレビューを実施する。ここではスプリントでの作業の結果をユーザーに提示する。ユーザーからのフィードバックをもとに、バックログを調整することも多々ある。
前述のとおり、以前のアジャイルではない開発でも実態としてユーザーと頻繁に会話をしてある意味"柔軟な変更"はしていたが、正しい姿ではなかったし、そのほとんどができたプロダクトを介したものではなかったので空中戦だった。改めて記憶を呼び起こすとこれは単純に要件定義が遅れただけで、プロトタイプを見せることでイメージアップができたという利点すらなかった。（完全に余談。私は解像度が上がる、イメージしやすくなるの意でも「イメージアップ」を使うのですが、これは正しい日本語なのでしょうか）
求められるスキルはとても高い
スクラムの開発者に求められるスキルとして、機能横断と自己管理がある。
どちらも文字通りだが、機能横断は特定スキルに偏らず必要なスキルなら何でも身に着けること。自己管理はプロジェクトマネージャーや上位者に管理されるのではなく、自分自身で管理をすることである。
機能横断の観点でいうと、今の私は全く機能横断的であるとは言えない。インフラ周りの知識は全くなく、分かる人がやれば30分で終わる作業に1日費やしていた。以前はアプリとインフラで分業がなされていたため、あまり意識していなかったためでもある。従来のアプリの範囲でも、今ままで私が使用してきた技術とは一部異なるのでキャッチアップはかなり大変だった。ここはあまりアジャイル関係ないところではある。
自己管理については以前も誰かに管理されていた気がしないので問題はないと思っている。いや、今までに入った案件のほとんどが納期に遅れてごにょごにょしていたので管理が機能していなかったという話かもしれない。そうであるならば、いまも自己管理は効いてないかも。
おわりに
もっと書けることはありそうだけど、時間的にここまでにする。思いついたら追記します。
来年はアドベントカレンダーに書くネタを探しながら生きる一年にしたい。