事例紹介：ADWAYS DEEE App modernizationプロジェクトを振り返る（後編）
こんにちは、Tanzu Labs PMのWataruです。今回は、少し前にこちらの記事で紹介したSWIFTメソッドを使って実際に行われた、アプリケーションモダナイゼーションのプロジェクト事例を紹介させていただきます。
2023年12月から約4ヶ月間、我々と共にプロジェクトを行ったADWAYS DEEE様に、色々とインタビューをさせていただいたので、その内容をベースにご紹介していきます。前編と後編の2本立てを予定していまして、今回はその後編となります。前編をまだ読んでいない方は先ずはそちらから読むことをオススメします。ではどうぞ！
開発スタート
— 年が明けて1月から開発がスタートしました。リモートにも変わりましたが、最初の印象は？
Magariさん：リモートに変わりましたが、チームの一体感などは失われずにずっときてるなーと感じていました。PMがユーザーストーリーを丁寧に書いてくれることで情報共有もだいぶスムーズにいっていたと思います。でも今思うと、やっぱり対面だったらもっと良かった、スピード感出てたかもなぁとも思いますね。
— 今までもアジャイル開発（スクラム）されていたと思うんですが、我々と一緒に始めてみて（XP）何か違うところ、または同じところなど感じるものはありましたか？
Mochiさん：違いの部分で言うと、ユーザーストーリーの切り方ですかね。色んなところで切り方や書き方を学ぶんですけど、実践的にプロダクトにうまく落とし込む、定着させるっていうところまでは正直出来ていなくて。何度もやろうとしては文化が薄れていって、だんだんとユーザーストーリーが「タスク管理」みたいになってしまっているという実態があって。そこを今回きちんとストーリーの視点（Why/Whatなど）や手頃なサイズ感みたいなことを身をもって体験出来たので、これを機にきちんと組織に根付かせたいなと思いましたね。
あと、PMだけで（プロジェクトを）どうにかしようとするのはダメだなというのも大きな学びでした。エンジニアと一緒になって粒度や開発の進め方、イテレーション自体のあり方などを考えていかないといけないな、と。そういうことを体験出来たのは大きかった。やっぱり、ネットに転がっていることを読んでるだけじゃ難しさはあると思いましたね。(Tanzu Labsと)一緒にやることで、例えば「柔軟さ」とか、基本のプラクティスや原則はしっかり抑えてるんだけど、少し崩したり、ここは柔軟に変えても良いんだ、みたいなことがすごく身に染みたところだと思っています。
— IPM（スクラムで言うところのスプリントプランミーティング）の進め方などはどうでしたか？
Mochiさん：スクラムという土台があったので、イベント自体にはすんなり入れました。ただ違いとして感じたのはXPは「期限がない」というところかなって思いました。僕らはスクラムで、期限（イテレーション）に対してどれだけ成果物を作れるかっていうところにコミットしようとしていたけど、でも本質を辿ってみれば、やりたいものを上から順に作っていくという当たり前の流れ、そこはなんというかハッと気付かされた部分はありましたね。
Magariさん：期限というか（スクラムの）スプリントゴールですね。毎回、結構悩んでいました。なんというか毎週スプリントゴール決めたいけど、これだと1.5週間かかるし、どうする？みたいな。なんか変な難しさがあったり、変に囚われたりしていた部分があったのかな。なので、ある意味ではXPの方がスクラムより単純かなと思いました。
— ストーリーのポイント付けなどは？違いはありましたか？
（※Tanzu labsでは「複雑度」を基準に0,1,2,3のみ）
Magariさん：スクラムで僕らもやっていましたが、今回ポイント付けはかなりわかりやすくなったと思います。「経験に基づく」というやり方はしっくりくる。もともとフィボナッチ数列使っていて、大きいと5とか、でもそういうのは2とか3とかに分解されていて、そういう意味では数字の規模感はあまり変わっていないんですけど、今回は作業量ではなく、作り方を「我々が出来そうか/出来ないか」「知っているか/知らないか」ということをベースにしているので・・言葉としては「複雑度」という説明でしたけど、どちらかと言うと僕としては「経験によるスコアリング」という理解で、そこは非常に良いなぁと思いました。そうすると例えば新しいメンバーが多く来たら、同じストーリーでも少しポイント上がるよね、上がることで（Velocityは安定してても）消化としては少しだけ少なくなるよね、でもそれってチームのリアルな実態だよねみたいなことは非常に納得感ありましたね。今まで自分たちでやっていたポイント付けが良くなかったとはあまり思っていないんですが、今回難易度が下がってよりしっくり来たのでかなりコスパの良い方法だなって思いました。結構社内のルールを統一するのは難しいのですが、今回は教えやすい、伝えやすいと思っています。
— ペアプロ・TDDについてはいかがですか？「ペアプロってコスパ悪いのでは？」みたいな質問もよくありますが、実際やってみてどう思ったかお聞きしたいです。
Magariさん：ペアプロは実は僕は今回が初めてだったのですが、1つ思っているのは、「ペアプロ単体」では効果は半減というか、成り立たなくて、それに伴う”徹底さ”が追求できれば、かなりいいと思っています。
”徹底さ”というのは例えば、
- 複数トラックいてメンバーローテーションできる(≒知識の属人化排除)
- エンジニアはプロダクトに集中できる(≒他ミーティングなどの排除)
- PMがストーリーを管理し密接にコミュニケーションできる
など。こういう条件が揃うことでペアプロが発揮できる価値が指数関数的に増えるだろうと思っています。
TDDに関しては、我々としては「今こそやるべきだな」ということを再確認できたなと思っています。「今こそ」にあたる内容としては、
- TDDと生成AIとの相性の良さ
- TDDとペアプロとの相性の良さ
- TDDとユーザーストーリー（主に「受け入れ基準」）との相性の良さ
などを感じています。生成AIは時代的なもので、今回のエンゲージメントの中でも、生成AIがタスクから学習してテストコード書いてくれたりすることもありましたし、テストコードがあったらプロダクトコードのベースも生成AIが書いてくれたりとか、このあたりはかなりテンポの良さを実現できますよね。また、今回ユーザーストーリーでも「価値」(Why)と「受け入れ基準」(What)をクリアにする形式をPMが学んだので、エンジニアとしてはそれに対してどういう振る舞い(How)が求められるか考えると、自ずととテストコードの内容に近づいてくるのでそこもまた相性につながるなと思っています。
まだまだ社内はプルリクエストが多いし、世間一般的にも、例えばGithubとかでもそういう機能が充実していたりしていますが、XPは実は時代的にすごく価値を出しやすいタイミングなんじゃないかなって、今こそやるべきだって堂々と言えると思っています。
— 1月に開始して、最初のThin Sliceを2月中旬、2つ目を3月上旬と、リリースしていくわけですが、もともと思っていた予定・手応えだったり、社内的な評判や評価はどうですか？
Magariさん：リリース自体は「おおー！」とはなっていないです（笑）。
良くも悪くも炎上はしていないし、淡々にという感じですかね。それよりも社内向けの資料やワークショップ、例えば別チームに少しSWIFTやりにいったりとか、あと今回新しいプログラミング言語を採用しましたけど、その辺のアーキテクチャ面での挑戦とか、そういう部分はみんな思った以上に興味ある印象で、反響としては大きいですね。ただ、我々が敢えて一気には広げていかない、という判断もしているので、少しずつにはなるんですが、むしろ社内のメンバーからこちらを覗きに来てくれているので、非常に良い状態だなと思っています。PMのストーリーの書き方や管理なども、今まで社内ではどのチームもデリバリーフェーズに入ったら「PMって何したらいいの？」みたいな雰囲気もあって、アジャイルと言いつつもミニウォーターフォールっぽい感じはあったんです。「共創する」という言葉はあったんですが、どうしてもエンジニアが主体になっておまかせしちゃう感じがあったんですけど、今回ユーザーストーリーの粒度感や確認頻度などの新しい形が見えてきて、社内のPM陣から、「やりたいから教えてください」みたいな声も上がってきているので、良い傾向だなと思っています。
— 逆に取り入れるのが難しそうな要素とかってあったりしますか？
Magariさん：さっきもお話しした”徹底さ”をどう浸透させるか、ですかね。ペアプロ・TDD・ユーザーストーリー、プラス生成AIとの相性やチームメンバーのコミュニケーションなど、その辺の”つながり”をもう少しで図式化できそうなイメージがあり、それを伝えたいと思っています。こういう状態だから今の我々はこれを抑えるべき、全てはつながっているんだよ、というのを、伝えたい。逆に、いくつかが欠けてしまうと不完全感があるなと。
Mochiさん：徹底さで言えば「集中できる環境」が素晴らしかったので、これを続けられるかというところもかなりポイントになってくると思っています。あとは、ユーザーストーリーを通してPMからエンジニアに内容を伝えていく点においても、今回は色々図や絵を多用したと思うんですが、伝える手段は色々あって、「やり方」にこだわらず、「より伝わるために何が出来るか」みたいなことを徹底したい。今回は良い図が書けたけど、常にそれが正解なわけでもない、そういう分かりやすい「形」がない分難しいんですが、「伝える」というマインドみたいなものを醸成していく必要があると思っています。
今後に向けて
— 今回のエンゲージメント、一番大きかった学びってなんでしょう？
Magariさん：2つあります。1つは、ビジネスに対してのモダナイゼーションの考え方、ここは一本の糸口が体験できたな、と。あとはこれを絶やさず考え続けることが大事だなと思っています。基本は抑えつつも我々に完全フィットした形のSWIFTメソッドを模索し続けていこうと思っています。もう1つが、やはり”徹底さ”の部分です。会社として組織として”徹底さ”を浸透させたり体験させたりするということはかなり組織マネジメントにおいて重要だと思いました。
Mochiさん：PMの立場として、最短でリリースに向かうために出来ることがある、ということを学びました。先ほどの「デリバリーフェーズはPM何する？」じゃないですけど、いわゆるリサーチなどの上流工程だけが仕事じゃなく、開発のフェーズも、もちろんチームで動くんですが、どんどんリードするというか、エンジニアに任せきりにしないで一緒にやっていく、といった動きが学べたことが良かったです。
— エンゲージメント終わってまだ1週間程度ですが、チームは今どういう状態ですか？
Magariさん：どうですか？（Mochiさんに）
Mochiさん：社内の仕事が増えてきちゃった（笑）。ここはちゃんとしていかなきゃいけないところですけど、先ほどもあったように、こちらから展開しようと考えている段階で、各プロダクトチームから「学ばせてほしい」とコミュニケーションを取りにきてくれている状態なので、それはすごく嬉しいし、僕らとしてもやりやすいですね。あと、定着にむけては、経営陣やマネージャ陣が「時間がかかる」と理解してくれていて、かなり進めやすい環境にいさせてもらっていると思っています。
— 最後に、今後SWIFTを使ったモダナイゼーションにトライする方々がいるとして、その方々に伝えたいメッセージありますか？
Magariさん：事業の観点とモダナイズの戦略は明確にした方がいいと思っています。今回JANetは良いタイミングだったと思っていて、具体的に言うと、
- 事業の観点
中期的な計画として、ビジネスのコアを見直して進化させようというのがあったが、そのコアを司る部分がレガシーのまま - モダナイズの戦略
インフラ的なクラウド移行などはひと段落していて、環境的に出来ることが増えた状態になり、次に見直すべきはアプリ
という状態でした。事業のコアに変化を与えたい、レガシー側はインフラまではある程度整えた、というこの状態がSWIFTに投資するタイミングとして最適じゃないかと思っています。逆に、事業戦略的に大きな変更予定はない、インフラが全部オンプレ、などだとミッション感が欠けたり恩恵を受ける範囲が狭かったりする部分が出てしまう気がします。なので、一番活きるタイミングと条件を考慮すると、より良いと思います。
以上です。ここまでお読みいただきありがとうございます！いかがだったでしょうか？前編をもし読んでいない方いらっしゃったら是非前編も読んでみてください！
今回の記事、SWIFTもXPも、良いことだけじゃなくて難しかったことやネガティブに感じたことなども、赤裸々に書いたつもりです。我々はプラクティスに自信を持っていますが、必ずしも全てを解決する方程式を持っているわけではなく、原則的な部分が強いです。自分たちの組織やプロダクトに合った形に変化・進化させていくこと、またエンゲージメント中だけでなく、終わった後にももちろん続けていく必要があること、それに加えて文化や人も重要であることも、今回の記事を通してお伝えできたのではないかなと思います。
また、今回の記事ではプラクティスの具体的な内容には触れていませんが、いくつか記事内で出てきた内容とリンクする参考になりそうな記事を載せておくので、良かったら見てみてください。それではまた！
