2018年の11月頃から始まり、開発手法としてScrumを採用したとあるプロジェクトは、2019年の6月に予定通りサービスのローンチを行うことができました。

このプロジェクトはお客さんとのユーザーストーリーマッピングでのMVP検討から始まり、まずはサービスの背骨にあたるMVPの実装を1ヶ月で完了。その後4ヶ月間はリリースできる状態をずっと維持し続けながら、毎スプリント着実に機能を追加していき、ローンチの1ヶ月以上前にはお客さんが希望する機能の追加を完了。ローンチ前にはいくつかのメディアに取り上げられたこともあり、多少注目されながらローンチ当日を迎えましたが、そこでも拍子抜けするほどなんのトラブルも起きず、お客さんからも開発チームからも、これほど安定したプロジェクトは今まで経験したことがないといったようなポジティブなフィードバックをもらうことができました。

その結果、お客さんからの期待値が想定以上に高まってしまい、同じやり方を他の複数プロジェクトにも早急に導入することが決定。開発者を含む関係者が一気に倍増したことで、チームは混乱状態に陥ってしまいました。

今現在も混乱中ですが、RSGT2020が開催される頃までには何とかなってると思うので、私達がこれからどのようにして再び練度の高いチームを作り上げていったかについてお話しできればと考えています。

「ほかの企業が採用している方法やプラクティスをコピーしようとしたり、専門家がデザインしたモデルをそのまま実行してはならない。」アジャイル界隈では、このような考え方が定説となっていると感じてます。もちろん、ほかの企業とあなたの現場では状況や制約も違いますし、各プラクティスについてもその本質を理解しないまま闇雲に導入したところでうまくいく可能性は低いでしょう。そこで先述したような定説が述べられるのはもちろん理解できますが、一体どれほどの人達が最初の段階から本質を理解した上で、現場の状況や制約に合わせてアジャイルを導入できるでしょうか。

『禅とオートバイ修理技術』という書籍において、人間の理解は、本質に着目する"古典的な理解"と、表面的な現実しか見ることができない"ロマン的な理解"に分けられると記述されています。アジャイル開発を実践している"古典的な理解"の人からすると、本質も理解しないまま手段としてのアジャイルプラクティスを盲目的に実践する"ロマン的な理解"の人を理解することができず、そういった振る舞いのことを"プラクティス厨"、"スクラムの奴隷"と揶揄し、「状況に合わせて自分の頭で考えよう」と言いますが、"ロマン的な理解"の人はいくらそのように言われたからといって理解して実践することは難しいです。なぜならば、両者は全く異なる理解様式だからです。

当セッションでは、よりよい開発方法を見つけだそうと必死に頑張ってる"ロマン的な理解"の人ががいかにしてアジャイル開発、スクラムに取り組み、結果としてアジャイルになれるかをフェーズと理解様式の二軸から説明したいと思います。

RSGT2015では日本側の立ち位置でチャレンジしたアジャイルオフショア開発導入事例についてお話しさせて頂きました。

RSGT2016ではフィリピンに滞在し、現地の多国籍チームの中に入って実践したアジャイル開発導入事例についてお話しさせて頂きました。

そして今回のRSGT2017ではベトナムに半年間滞在し、ベトナム側の立ち位置でチャレンジしてきたアジャイルオフショア開発導入事例についてお話ししたいと考えています

• 実際にベトナムで実践した事
• 受け入れられて定着した事
• 受け入れられずにやらなくなっちゃった事

現地でチャレンジしたからこそ得られたこれらの経験をお伝えできればと思います。

また日本側、ベトナム側それぞれの立ち位置で3年以上取り組んできたアジャイルオフショア開発の目指すべき方向性についてもお話しする予定です。