Lilac（ライレック）イベントRecap: アジャイル開発、スクラム開発の現場経験シェア パネルディスカッション
アジャイル開発、スクラムについて、現場に入らない限り触れる機会が少ないと実感したため、学習中の方から、現役エンジニアまで幅広く参加してくださっているLilac（ライレック）のコミュニティならではの特性を生かし、全てのレベルのエンジニアが学べるパネルディスカッションイベントを開催しました。
Rceap記事なので、内容は全てこちらのアーカイブ動画に基づいています。
動画内のスライドはこちらからご覧いただけます。
パネリストの紹介
Shogoさん（@wada_shogo）
米Goldman Sachsのエンジニア。
【記事】
英語赤点の田舎者が、米Goldman Sachsでエンジニアになるまで: https://zenn.dev/shogo_wada/articles/f7366d750e4db2
斎藤さん（@bohol_engineer）
フィリピン、ボホール島在住、フロントエンドエンジニア。フリーランスにで受託、自社開発、さまざまな企業やチームでアジャイル開発に取り組む。
従来の開発における課題
市場の不確実性 - 本当に売れるのかどうか？
リリースの単位が大きい - リリースしても求められるものと違うリスク。
柔軟性のない開発 - 設計も作ってしまったし、開発着手しているので簡単に変更できない。
プロジェクトに求められること
1. 市場の様子を見る
2. ビジネスの方針を柔軟に変える
3. プロダクトの要件や仕様を柔軟に変更しやすくする
4. 世の中の技術力の工場にも対応
これら4つを踏まえた上で、さらにコストを抑えなければならない。
どうするか？
アジャイルな開発をしよう
1回のリリースの単位を小さくすればよい。
これまでが以下の形式だったのに対し、
市場調査 → 企画 → 開発 → リリースアジャイルなプロジェクトは、以下の形式。（1, 2週間単位）
市場調査 → リリース（繰り返し）アジャイル開発宣言
- プロセスやツールよりも個人と対話を
- 包括的なドキュメントよりも動くソフトウェアを
- 契約交渉よりも顧客との協調を
- 計画に従うよりも変化への対応を
左記のことにも価値があることを認めつつも右記の事柄により価値を置く。
スクラム開発
最も広く利用されている、アジャイル開発を実現するためのフレームワーク。
- スプリントプランニング
- スプリント
- 朝のミーティング（デイリースクラム）
- スプリントレビュー
- 振り返り（レトロスペクティブ）
スプリントとは、上記の市場調査 → リリースの1セットのこと。
大体1スプリントあたり1, 2週間の単位が多い。
価値観の共有がスクラムでは非常に大切で、全員がアジャイルで進める意識を持つことが大前提とされている。
これができないとどうなるか？
お客さん:「この機能こうして欲しい」
社長:「やります」
社長:「これ（かなり難しい問題）やってね。あ、スクラム開発っていうの良さそうだからそれで対応してね」
開発チーム:「？？？！」
プロジェクト炎上の爆誕🔥🔥🔥
注意事項
アジャイル開発は銀の弾丸ではなく、チームや」プロジェクトの成功を保証するものではない。
アジャイル開発は方法論ではなく、思想や文化のようなもの。正解が必ずしもあるわけではない。
イベントディスカッション
アジャイルを取り入れるタイミングはいつ？
すれ違いが起きやすいので、アジャイル開発の基本を全員が理解していることが大切。
その上で取り入れることが最適なタイミングを見計らうコツなのかも。
スクラムは結構たくさんきっちりすることがある。
チームによって結構することをチームなりに変えていることが多い。
「とりあえず2週間スプリントをやってみよう」というのはどうなのか？
全員でアジャイルとは何か？ということに関して理解を深める機会を設けると、その方法は良いと思う。
会社に合う方法を見つけることが大切。
振り返りについてトラブルはあったか？
あまりない。ただエンジニアでもクライアントとコミュニケーションを取るのが苦手な人もいる。
チームに内での信頼がないと、責任のなすりつけ愛みたいになってしまう。
スプリントは何ができて何ができなかったかを振り返るもので、それを元に次に生かしていく方式なので、信頼関係がないと受け取り方にギャップが生じてしまうこともある。
チームを改善しようという話題から逸れてしまい、自己防衛に徹してしまうこともある。
KPT（Keep, Problem, Try）を取り入れるのは、ある意味その解決方法になるかもしれない。
あとはタスクから多少逸れていても人に感謝する、人を褒めるということを実践している。
これは結構効果を感じている。
実践しているチームとしていないチームでは、同じ企業内でも変化が大きく、実践しているチームの方が働きやすい。
いきなり「振り返りをしましょう」となっても「ここが弱みだよね」と言われることで、信頼関係がない場合はムッとしてしまいやすいので、振り返りをしやすくする共通認識を事前にしておくことが非常に大切。
wowだったことを社内全体ミーティングで共有する実例の共有もある。
DEI（Diversity, Equality, Inclusion）とアジャイルの関係性は？
実例としては、本社、支社の表現方法を無くそうとする動きがあって、力の上下関係を無くしたいという意図でのアイディアが出たこともある。
シニア、ジュニアの表現よりも、経験が多くある人に意見を聞こうという表現にするなどの工夫もあった。
クライアントの姿勢がオープンでなんでも言ってくださいという雰囲気を作ってくれる場合は、非常に開発しやすい。
コミュニケーションの手法はどうしている？
なるべくテキストだけのコミュニケーションよりは、顔を見ることのできるビデオ通話、できれば対面でのコミュニケーションを心がけている。
そのほうが早く解決することも多いので、多くの環境で採用されている。
ビデオオンにすることを推奨している環境も多い。
理由ははっきり聞いたわけではないが、ミーティングに参加していてもネットサーフィンをしている場合もあるし、意思表示をすることが安心感につながるので、それが理由なのでは？と推測している。
ただ、人数が多いミーティングの場合、情報量が多くなるので、その場合はケースバイケースのような気もしている。
まとめ
アジャイル開発、スクラムは、企業やチームごとに合った方法を模索して、取り入れていくことが大切であり、開発メンバーだけでなく、企業内、チーム内全ての人がアジャイル開発の正しい認識をすることが、成功の秘訣だと認識できました。
私が働いているStoryblokでも、スクラムを採用して開発チームはプロダクト開発をしており、私の所属するDXチームでも、チーム規模が大きくなってきたので、スクラムでスプリントを設けて作業をする方式を実践中です。
単に良いと言われているものを、自分の環境にそのまま理解せずに放り投げるよりも、理解し、自分の環境に合うように変化を加えていくことで、良い手法を効果的に独自の環境に取り入れることにつながるのだと今回のイベントで理解することができたように思います。
現場に入らない限りは、身近にアジャイル開発やスクラムについて聞く機会や関わる機会が少ないと、メンターをこれまでしてきて思ったので、こうした機会をLialc（ライレック）のコミュニティで設けることができ、私自身お学びも多いですし、コミュニティに還元できているのであれば嬉しく思います。
Lilac（ライレック）では、コミュニティメンバーからのリクエストや、イベントアイディアも積極的に募集しています。
プログラミング学習者向けの無料教材のオープンソースプロジェクトも始動しましたので、興味のある方はぜひ、テックスキル、知見、経験シェアのコミュニティ、Lilac（ライレック）にご参加ください。
この記事が気に入ったらサポートをしてみませんか？