ryuzee氏・miholovesq氏によるスクラムブートキャンプが開催されました(レポート)

2018/6/25(月)に、吉羽龍太郎氏(@ryuzee (link is external))・永瀬美穂氏(@miholovesq (link is external))にお越しいただいて、1Dayスクラムブートキャンプ(ワークショップ)を開催していただきました！

ワークショップ内容の詳細なレポートは、内容のネタバレになってしまいますので、本レポートでは序盤にワークショップ概要を述べ、主にブラックボックス的に、参加者がスクラムブートキャンプを通じて得た学びを中心に記載します。

ワークショップの概要

ワークショップ全体は以下のような構成でした。

• あるお題に対して複数回のスプリントをチームで実施
• スプリントからの学びを全体で振り返り★
• 座学によるスクラム全体の知識習得 + 質疑応答★
• 習得した知識のアウトプット
• 座学でプロダクトバックログについての学習 + 質疑応答

この中から、★でマークしている振り返りで出てきた参加者の意見、および座学後の質疑応答を紹介いたします。

午前のワークショップから得られた学び

午前中はあるお題に対して、4-5名でチームを組んで、短期間スプリントを複数回まわしていく、というプログラムを実施しました。

スプリント後の振り返りでは、参加者からに以下のような学びが生まれていました。

• 技術の大事さ
• 設計中は技術が不安定になる点
• 共通のゴールを自律的に目指す
• 繰り返しによるゴールの洗練
• プロトタイピング
• タイムマネジメントの重要性
• ペア作業
• 共通理解の重要性
• リリースが重要である点
• リーダを決めればよかった
• 普段のコミュニケーションが大切
• 無駄な作業の見直し
• 成功体験の積み重ねの有効性
• 検証はもっと早くすべき(全てが整うのを待たない)

短時間のスプリント演習でしたが、アジャイル開発で重要となる要素が多く含められており、実体験として学べることがわかります。

質疑応答の中から紹介

プログラムの中では、座学や実習の後に適宜、質疑応答の時間が取られます。以下で、質疑応答で上がっていた内容をいくつか紹介いたします。スクラムはフレームワークに過ぎないので、具体的な進め方（実装）は各々のチームに委ねられており、その辺りも質問に上がっていました。

Q: 残業時間は、見積もり時に考慮すべきか？

• 含めないのがオススメ
• 普段の時間の6-7割程度しか開発に使えないはずなので、それで見積もりするのが良い
• 持続可能なペースで仕事できるスケジュールにして、スコープ(機能など)で調整していく

Q: プロダクトの企画側が予算を決めてくる環境でどう進めればいいか？

• 本来はプロダクトを作っている期間は、開発チームとプロダクト側が一緒にやるのがいい
• 半年先を考えても当たらないので、「一緒に継続的に効果測定しませんか？」と誘うのが良い
• また、作った機能についても、メトリクスを取れるように仕込んでおくと、プロダクト側と一緒に確認できる
• 基本的には、開発とプロダクト（企画）の距離感を近ければ近いほど良い

Q: アーキテクチャはいつ決めるのか？

• 早い段階で決めた方が良い
• 開発言語に何を使う、サーバに何を使う、といった間違えると取り返しがつかないやつは先に決める
• アジャイルではなんでも後回しにするのではなくて、今やらなきゃまずいものは今きめる

Q: 銀行系の基幹系はアジャイルで作れるのか？

• ウォータフォールでやるしかない
• あまりに大きすぎて、あちこちを勝手に変化すると、どこかが壊れる。設計はある程度、密になる
• 基幹系をリプレースする案件だったら、アジャイルはオススメしない
• UI部分だけだったらアジャイルでやるのはアリ
• そもそも、規模が大きいシステムはウォータフォールにしろ、アジャイルにしろ非常に難しい
• スケールさせるなら、理想形はチーム間はAPIだけで話すようにする(AWSで実施されている開発のように)
• また、小規模アジャイルの経験無しに、大規模アジャイルはやらないこと。絶対に失敗するので

まとめ

本記事では、スクラムブートキャンプにおける参加者の学びを中心に紹介いたしました。

NTTコミュニケーションズでは、ソフトウェアエンジニアの育成に力を入れています。今後も継続的にエンジニア向けワークショップなどを通じて、ソフトウェアエンジニアの育成に力を入れていきます。