アジャイルエバンジェリストとしてオススメする最初に取り組む3つのステップ
こちらは、公式アドベントカレンダー2024_A IT技術関連トピック Day.22 の記事です。
公式アドベントカレンダー2024_B 仕事術・キャリア・体験記も毎日記事を公開していますので、ぜひあわせてご覧下さい。
★Day21のアドベントカレンダー記事
「Sqlite3のデータベース更新通知をリアルタイムで受信する方法【Unity編】【C#】」（髙橋一生）
どうも！
SHIFTでアジャイルエバンジェリストをやっている佐藤です！
前職で、ウォーターフォールの案件を担当して、毎度最後の方にプチ炎上を経験してきたことで、プロジェクト推進を学び、初めてアジャイル開発に出会いました。
その経験からウォーターフォール開発とアジャイル開発の根本的な違いを考えて、導入できる部分とやるなら自分たちの考え方を考えないといけない部分に注目しています。
そんな経験を元に、今回はアジャイル開発が数多に持つ特徴から「反復」「自律」に着目して、課題になりそうなポイントと明日からできることを考えてみます。
アジャイル開発に取り組むときの課題になりそうなこと
期間内に開発が終わらない
自分のタスクの範囲が不明確になる
出来上がるものが小さい
テストってどこまでやるの？
会議多すぎ
リリース判断におけるメトリクスってどうしたらいいの？
簡単なタスクから始めて、後半に難しいタスクが集中する
いろんな不安があると思います。
それは新しいチャレンジなので当然です。みんなちょっとビクビク、ワクワクしながらやっています。 大事なのは、チャレンジして、合わなかったらすぐに戻せるということです。
組織が求めるスピードはもっと抜本的にというのも理解していますが、今までやったことがないことに対して、人は変わることは難しいです。そして、自律的に動けるチームがアジャイル開発をやることが大事です。命令する人を入れてタスクをやらせるのでは、うまくいきません。
オススメする最初に取り組む3つのステップ
Step1 ふりかえりをやってみる
ふりかえりを1週間か2週間に1回やってみてください。参加者はチームの全員であるのがよいです。
チームの人数が多い場合は、更にチームに分けて3〜4人に分けてみてください（想定は20名くらいまでかなぁ)）。1回で効果が出ることは少ないので、2回以上やってください。
他人が記載したものに対して、人は批判的になりやすいです。ふりかえりでは、記載内容にツッコミを入れるのではなくて、工夫点や課題に注目してください。
KPT（けぷと）とYWT（ワイ ダブル ティー）を組み合わせてみることで、わかりやすく振り返ることができるかと思います。
進め方
その時に、YWTのY（やったこと）、W（わかったこと）で1週間を振り返ってみてください。
複数のYWがあつまるので、それをKPTのK（よかったこと）P（うまくいかなかったこと）で分類してみてください。
1人2票を元に分類したKPに投票をして、KPから上位3つを選択してください。
複数のチームで実施した場合は、3が終わった時点で、それぞれのチームで共有して、再度投票をしてください。
投票後のYWに対して、次の1週間でできることと時間がかかることに分けてください。
次の1週間でできることはチームで実践してみてください。時間がかかることはチームのリーダーや管理者が持ち帰って検討してください。
どうしても、チームでふりかえりをやるとボトムアップ（チームが改善すること）しか対応できないです。
トップダウン（組織として改善すること）があったとしても、自分たちで対応できないことで諦めてしまうことが多いです。
それぞれに注目しながら、改善していくことでチームの改善と組織の改善が進みます。ただし、組織の改善は時間がかかることなので、チームの改善に比べると、効果が大きいが全部を対応できるわけではないです。
狙いはサイクルの意識とチームの改善、組織への改善要求です。
Step2 リリースをしてみる（誰かにプレゼンしてみる）
ふりかえりの前にリリースしてみてください。
リリースと言っても、いきなり顧客にリリースするのは難しいと思うので、管理者にできていることをプレゼンしてみてください。
どこまでできるでしょうか？
チームで仕事をしていると役割分担はよくあります。分担ではなく分割だろうなと思うときもあります。
割り当てられたタスクを実施しきるのは大事ですが、悩む時間はもったいないと思います。
テディベア効果でもあるように、ある程度煮詰まった状態は、整理整頓ができていない状態です。
役割分担をしているからこそ、その後にタスクをあわせると言うタスクが生まれ、ここに手戻りが発生することがあります。
それなら最初からみんなで作ればいいんじゃないですかね（極論）。その考え方がモブプログラミングの要素としてあります。
閑話休題。本題に戻りましょう。
管理者に見てもらうためには、動く状態にしないといけません。最初は誰かの環境でもいいです。一箇所に集めて動く状態にしてみましょう。うまく行かないこともあるかもしれません。この経験には得るものがあります。
設計の課題やコミットのタイミング、もしかしたら動く状態にするためにコミットしたらコンフリクトが発生しているかもしれません。動かしてみたら動かないなど、いろいろな課題に気がつくことができます。
「こんなことするくらいなら、今までどおりでいい」と思うかもしれません。そう思った場合は問題の先送りをしている状態です！
この状態よりも悪い状態で、結合することになります。
狙いは開発の進め方、コミットのタイミング、成果を見せるです。
Step3 チームと自分の経験を共有してみる
チームには自分以外に複数のメンバーがいます。その人のことを興味を持って行くことも大事ですが、最初からそんなチャレンジは難しいです。まずは、自分のできることややってきたことを表にしてみてください。
細かく書きたくなると思いますが、大雑把でよいです。
例えば、Web系ならフロントエンド、バックエンド、DB、インフラ、テストの5つくらいで良いです。最大でも10個です。
その中で得意な部分に◎、◯をつけて、少しだけやったことあることに△、やったことないことに×、興味があることや勉強中に☆をつけてみてください。そして、その時に簡単にどんなことをやったかを語ってみてください。
チーム全員分集まるとどうでしょうか、抜けている部分がないですか？
ない場合はみんなで力をあわせて開発を進めましょう。あった場合は管理者に相談してみましょう。
自分たちの経験をすり合わせて、興味がある部分についてはどんな学習を進めているのか等の会話のきっかけにしてみてください。何人もいる場合は勉強会を30分でもいいのでやってみるのをオススメしています。同じ知識を得ておくと日常の会話もスムーズになります。
最後に
ステップごとの関連はStep1とStep2はぐるぐる回ります。
それらの前提になるStep3が土台になります。
世の中のスピードが早くなり、アジャイル開発を求められることも増えてきています。
どのように推進していけばよいのかと考えて、アジャイルのプラクティスを導入することから始めるチームもいますし、現状の開発の課題に気がついて、アジャイル開発に近づいていくチームもいます。
全部をいきなり変えると適用に時間がかかってしまうので、チームを少しずつでも確実に変わっていく道を辿ってほしいと思っています。一つのやり方をお伝えしましたが、この方法ですべてのチームが良い方向に向かわないことも知っています。この記事を読んだ方が自分のチームの改善のきっかけになることを期待しています。
ぜひとも、楽しんで改善してください！
執筆者プロフィール：佐藤 博之
SIerで要件定義から保守までを経験。テスト工程で炎上するプロジェクトで品質について考えた結果、品質保証を業務とするSHIFTに転職。SHIFTでは、アジャイル開発の品質保証を担当し、短いサイクルの中でのテストエンジニアの活動や品質について考えている日々。
発散は得意だけど、収束は苦手なファンタジスタタイプ。
★SHIFTグループ公式アドベントカレンダー2024【A】 IT技術関連トピック Day23は「開催報告「CloudNative Days Winter 2024 一日で学ぶクラウドネイティブ技術実践ハンズオン」」（武井竜一）
お問合せはお気軽に
SHIFTについて（コーポレートサイト）
SHIFTのサービスについて（サービスサイト）
SHIFTの導入事例
お役立ち資料はこちら
SHIFTの採用情報はこちら
PHOTO：UnsplashのFruit Basket