- アシスタントマネージャー
- オフショアPJマネージャー
- 業務改善(BPR)
- Other occupations (76)
-
Development
- オフショアPJマネージャー
- Web Engineer
- エンジニアオープンポジション
- Javaエンジニア(楽楽明細)
- ブリッジSE(大阪)
- ブリッジSE/オフショア開発
- エンジニアリングマネージャ
- テックリード(大阪/PHP)
- プロジェクトマネージャー
- PM(楽楽シリーズ)
- Webエンジニア(大阪PHP)
- フロントエンドマネージャー候補
- フロントエンドエンジニア
- Webエンジニア
- フロントエンド(リーダー)
- Android/iOSアプリ
- 社内SE(大阪/セキュリティ)
- インフラエンジニア
- 社内SE(大阪/インフラ)
- インフラエンジニア/マネージャ
- DevOps Engineer
- 社内SE(データエンジニア)
- 戦略企画・データマネジメント
- データマネジメント・戦略企画
- AI/機械学習エンジニア
- QAリーダー/マネージャー
- システム企画
- 品質管理/技術支援チーム
- 社内SE(業務改善推進)
- UI/UXマネージャー
- UIデザイナー(リーダー)
- UIデザイナー
-
Business
- アシスタントマネージャー
- PdM(楽楽シリーズ)
- 開発マネージャー
- PMMプロダクトマーケティング
- 導入支援/導入コンサルタント
- プロジェクトマネージャ(大阪)
- プロダクトセキュリティ
- プロダクトマネージャー(AI)
- プロダクトマネージャー
- ドメインエキスパート
- プロダクトマネージャー(UX)
- 経営企画/事業分析
- 経営企画
- データマネジメント・マーケ戦略
- 法務
- 内部監査(業務監査)
- セールスマネージャー
- 法人営業/カスタマーサクセス
- 営業企画オープンポジション
- 営業企画(イネーブルメント)
- ITセールス(広島)
- ITセールス(名古屋)
- フィールドセールス
- フィールドセールス(名古屋)
- フィールドセールス(法人営業)
- 法人営業
- フィールドセールス(東京)
- 営業企画(戦略立案)
- ITセールス
- ビジネスオープン
- ITセールス経験者
- ブランド企画
- CSマーケティング
- オンラインマーケティング
- マーケティング担当
- マーケティングリーダー
- オフラインマーケティング
- 営業推進リーダー(楽楽精算)
- 製品企画/プロダクトマーケ
- ブランド企画・ブランディング
- 製品企画/法要件(楽楽明細)
- 企画マーケティング
- Other
開発をアジャイルに!スクラムトレーニング から始める最初の一歩
こんにちは。楽楽精算開発チームの堀内です。
先日、ryuzeeさんこと吉羽さんに社内でスクラムトレーニングを実施して頂きました。最初から最後までアジャイルで、全てが楽しく、得るものが多いトレーニングでした。
今日はその紹介です。
前置き
ラクスではプロダクト開発の改善活動の一部にアジャイルの考え方を取り入れて進めています。
実のところ、この改善活動の後ろで我々を支援してくれるのが吉羽さんです。
始まりとしては、プロダクトをもっと良くするにはどうするのが良いかと頭を抱えている頃に、チームメンバーの1人が「改善やチームビルディングに詳しい吉羽さん」に相談してみるのが良いのではないか、と言ってくれたことでした。
「なるほど!」と思い会社に掛け合ってみたところ、タイミングも良かったこともあり、すんなりとOKしてくれました。
早速吉羽さんに相談してみると「目的、ゴールを明確にして、アクションを決めたら一覧にして優先順位を決めて並び替えて、、、」とアドバイスを受けました。アクションを実施するためにチームを組んで少しずつ進めていると、良い感じで改善が進み始めました。そのことを吉羽さんに伝えると、「それがスクラムと言うんです」と。
それを言われて正直なところ「へぇ」という印象でした。スクラムというものが良くわかっていなかったんです。でも、その言葉をキッカケにスクラムやアジャイルで今でも色褪せることのない良書とされるものを読み漁り「なるほどっ!」と思うようになりました。
改善活動も持続的に続けることができており、今では開発チーム全体に改善の文化が根付いてきたように思います。
そんなアジャイルのやり方を開発以外の方々にも知ってもらいたい、そう思って企画したのが吉羽さんによるスクラムトレーニングです。
トレーニングの流れ
実施して頂いたのは半日コースのトレーニングでした。 全体の流れは下記。
全体説明
トレーニング内容の全体を最初に説明して頂きましたが、中でも最も印象に残っているのは次の言葉でした。
「16時に終わります。終わることをコミットしますので、安心してください。16時から通常業務に戻れます。質問は常に受け付けます。好きなだけ聞いてください。ただし、質問が多ければ予定しているトレーニングの内容が最後までいかないことになります。」
捉え方によっては、最後までトレーニングの内容を受けたければ質問はほどほどに、とも思えますが、アウトプットは途中の状況に応じて変わるということを示してくれていたと感じます。アジャイルで言う「スコープの調整」ということなんだろうなと。
つまり、16時に終わることをコミット(タイムボックスを固定)し、トレーニングの内容(スコープ)は質問の量(状況)に応じて調整する、という事なんだなと。
スクラムの概要説明
これは教科書的というか、ryuzee.comのブログに書かれているような内容で、馴染みのない人にも分かりやすく説明して頂きました。
紙飛行機を使ってスクラムを体験
今回の醍醐味とも言うべき、ゲームを通じてのスクラム体験です。
5〜6人に分かれて、チームで飛ばした紙飛行機の数を競い合うもので、以下のように進めました。
- 見積もり、計画、紙飛行機製作、振り返りを1セットとして4回繰り返す(つまり4スプリント実施)
- 紙飛行機を作る上でいくつかのルールが決められている
- 決められた距離以上飛ばして始めて成果となる
- 最後に全体の振り返り
各スプリントが始まる前に、何機製作できそうか、各チームが目標となる数字を公表します。
1回目は大体の見積もりは当たっていませんでした。
2回目の見積もり精度はかなり改善されました。
やってみないと分からなかったことが、1度実施して振り返ることで見積もりも製作も上手くなり、改善したということなんだと思います。
3回目は紙飛行機を製作する上で決められていたルールを1つだけ取り除くことができます。これはどのチームも同じルールを外しました。そのルールがボトルネックとなる「制約」と全員が考えていたんですね。3回目はどのチームも良い数字を叩き出します。
4回目は3回目に外した制約がもと通りになり、1、2回目と同じ制約のもとで紙飛行機を製作します。
途中で発生するルール変更が開発で言うところの「ビジネスの状況変化」を表すわけなんですが、ルールを変えることで成果も変わることが体感できました。
制約を外すことで成果が変わることが体感できたことは良かったのですが、それ以上に重要なことは「ルールに書かれていないことは禁止していない」と言うことでした。
例えば、製作に必要なハサミは1つだけというルールはなく、複数必要なら予備があるので使っても良かった、他のチームの紙飛行機を分析してはいけないルールは無い、などです。他にもいくつかあったのですが、決められたルールに縛られると新たな考えを「発想」する事が出来なくなるんだと気づく事ができました。
実際の開発の現場に置き換えるなら、ボトルネックと認識されている「制約」を外すことも重要ですが、「制約」になっていないことに目を向けて工夫することも重要、ということになります。
最後に
トレーニングは予定通り16時に終わりました。全体を通じて要所要所で質問もありました。紙飛行機のワークショップでは時間が若干押しているようでした。でもきっちり16時に終わりました。
トレーニング内容のスコープが吉羽さんにより調整されたのか、予め想定されていたバッファに収まったのかは分かりません。
ただ、私たちの学びや満足が成果だとすると、私たちは間違いなく成果を得ることができましたし、予定通り16時から通常業務に戻ることができたため、全て計画通りでした。
アジャイルの原理原則を全体を通じて体感できる有意義なトレーニングでした。
その後
後日、参加者にアンケートを取らせて頂いたところ、皆が満足感を得られていたことが改めてわかりました。
また、開発以外の方々とスクラムの考えを共通認識として持つことができたため、ちょっとした会話の中でも「価値」「サイズを小さくする」といったキーワードが聞こえ始めています。
今では改善活動だけでなく、開発をアジャイルで始めることができるようになりました。まだまだ始まったばかりですが、大きな一歩を踏み出しています。
募集
お陰様で順調に伸び続けているラクスは、アジャイルを取り込むことで更に改善し、飛躍していきます。
この変化の真っ只中で成長を実感されたい方、ぜひ一緒に働きましょう!楽しさとやりがいは保証します!