パートナー企業と一緒に取り組むスクラム開発のススメ

こんにちは。システム開発部のsonohaです。ニフティ温泉のWEBサイトの開発全般を担当しています。

ニフティ温泉ではパートナー企業様と一緒に開発を行っており、最近スクラムを導入しました。パートナー企業の皆さんとのスクラム開発において見えてきた課題や試みている施策などをご紹介していきます。

この記事は、ニフティ株式会社と一緒に制作し、技術書典13にて無料頒布した『ニフティのスクラム』に寄稿した内容を掲載しています。

目次

スクラムとは

スクラムとはアジャイル開発におけるフレームワークのひとつです。

スクラムは、開発チームが直面する複雑な課題に対して、細かく軌道修正をしながら開発を行うためのマインドセットと、それを実現するための会議体および成果物を定義しています。

スクラムに則った開発プロセスを簡略化して表現すると、次のとおりです。

1. プロダクトオーナーは施策の目的と要求を明確化し、優先順位をつけて一覧に並べる。
2. 開発者は一覧に並べられた要求を上から順に選出し、スプリントという決められた期間の中で開発完了(動く成果物をアウトプットする)できる範囲を目標として掲げ、開発完了に必要な作業を洗い出す。
3. スプリントを開始したら、進捗や課題を都度確認しながら開発を進める。
4. スプリントの終了時に、開発完了した成果物についてはチームおよびステークホルダーが評価を行い、開発のプロセスについてはチームで振り返りと評価を行う。
5. 評価の内容をもとに改善を図りながら、1に戻って新たなスプリントを開始する。
6. スクラムマスターはこれらのプロセスをチームメンバーに守らせ、またプロセスの障害になるあらゆる課題の除去に尽力する。

スクラムはこの手順によって、プロダクト開発のプロセスと意思決定に透明性を持たせ、課題を素早く検知し、それに対して改善を行いやすくすることを目指します。

詳細については、スクラムガイドをご参照ください。

スクラム導入のきっかけ

ニフティ温泉では、弊社から私1名、外部のパートナー企業から3名という4名体制で、ウォーターフォールに近い形で開発を行っていました。

企画メンバー複数名と営業メンバー複数名から開発の依頼が発生するので、それを私の方で要件定義および簡易的なシステム設計まで落とし込み、パートナー企業側にお渡しして開発してもらうというフローを踏んでいました。

このフローにはいくつかの課題がありました。

• 各案件の優先度が一元管理されない。
• しばしば仕様変更が発生するが、その際の調整コストが大きい。
• 案件の数が増えた際や大きい案件が発生した際に、必ず私がボトルネックになる。
• 私を含めた各メンバー間に開発力の差があり、属人化が発生しつつある。
• 不具合対応や運用保守対応が他の開発メンバーや企画メンバーの見えないところで発生し、私がその対応に追われる。

「何を」「なぜ」「どの順番で」を明瞭にしてメンバー全員が理解しながら、急な方向転換にも対応しやすく、かつ振り返りと改善を明確に行いながら開発するスクラムであればこれらの課題を解決できる可能性があるのではないかと、密かに期待していました。

そんな中、プロダクトの価値を最大化するために弊社内で一部体制変更が行われました。
このタイミングで、素早くPDCAを回し、より変化に強い開発チームにしたいという想いから、スクラムの導入を提案し今日まで推進してきました。

パートナー企業とのスクラムならではの3つの課題

私がスクラムマスターを務め、企画サイドからプロダクトオーナーを選任することで、晴れてスクラム開発を開始しました。

弊チームでは1週間を1スプリントとし、現在では12スプリントほどを実施し終えています。

プロダクトに関する全案件を同じ土俵で見渡せるようになった、各案件の優先度が明確になった、よりサービスの価値と目的に意識が向くようになった、など様々な良い効果が見られます。

一方で、パートナー企業とのスクラムだからこそ発生する課題も見えてきました。

1. 組織構造的な隔たり

弊スクラムチームではパートナー企業様へ業務を委託していますが、委託元の社員が委託先の社員の業務遂行に対して具体的な指示や監督を行うことを「偽装請負」と呼び、これは労働者派遣法および職業安定法で禁止されています。

一般にパートナー企業とのスクラム開発においてはしばしばこの偽装請負が問題となりますが、厚生労働省から発表された派遣と請負の区分に関する疑義応答集とこれに対する梅本大祐氏による解説によると、スクラムにおける会議体や共通ツールの使用それ自体は問題ではなく、個別のメンバーに業務遂行方法や労働時間についての指示を行う場合が問題となるようです。

スクラムでは全てのメンバーがフラットに協力し合うことが求められますが、一方で指揮系統は完全にフラットにできないこともあり、考え方や動き方に望ましくない差が生まれてしまう可能性があります。

2. 物理的な隔たり

2020年から、弊社における開発業務はリモートワークが中心となっています。

また、パートナー企業側もリモートワークが半分ほどを占めており、そもそも当然ながらオフィスが弊社とは別です。

したがって、スクラムメンバーが対面で一堂に会することはありません。

スクラムで定義されている会議やコミュニケーションは対面で行うことを想定しているため、リモートワークにおいては工夫をしないとそれらを円滑に行えない可能性があります。

3. 心理的な隔たり

Google re:Workのワークショップに沿って、心理的安全性をはじめとする5つの柱についてスクラムチームメンバーの認識を評価したところ、委託元の社員とパートナー企業の皆さんの心理的安全性の認識に差があることが示唆されました。

これには前述の組織構造的な隔たりと物理的な隔たりの両方が関連していると考えられます。

立場や権限が異なることから、リスクとリカバリに対する考え方も異なってきて、結果として、発言や行動をする際の安心感に差が出てきてしまう可能性があります。

いかに心理的なハードルを取り除いて、誰もが安心してアクションを起こせるような環境を作り、プロダクトを良くすることに集中できるようにするかが鍵となってきます。

試してみている7つの対策

見えてきた課題は、コミュニケーションによって改善できるものと考えています。

• 自分を知り、相手を知り、意識の足並みを揃えること
• そのために議論や雑談を増やすこと
• 何か困ったことがあればすぐに会話できる環境を作ること

これらを目的として弊チームでは次の7つを試みています。

1. げんきカレンダー

げんきカレンダーは弊社のkiwiが開発した、チームメンバーの体調見える化ツールです。

リモートワークにおいて雑談を意図的に始めるのはハードルが高いため、デイリースクラムの中で各メンバーにげんきカレンダーを入力してもらい、それを雑談トピックのタネとして活用しています。

調子が良いメンバーには、良かったこと・気分が上がった話・おすすめの生活習慣などを語ってもらい、調子の悪いメンバーには、労いの言葉をかけたり業務の巻き取りを検討したりと、毎日これを用いて会話を広げることができています。

2. 価値観ポーカー

リアルに対面しないメンバーが多く、それぞれのパーソナリティが見えにくいという課題があります。

スクラムはメンバーを個人として尊敬し尊重し合う価値観を大切にしていますから、メンバー同士が互いのパーソナリティへの理解を深め合うことは重要です。

ゲーム感覚でその人の大切にしている価値観を見える化できるワークショップとして、弊チームでは価値観ポーカーを採用しました。

価値観ポーカーでは各メンバーを象徴する単語が5つずつ決定されるので、なぜそれを選んだのか、その価値観は働き方にどう表れているか、どんな働き方が好きかなどを話し合うことで、互いのパーソナリティへの理解を深めていきました。

リモートでもWevox values cardというWEBサービスを使って気軽に試せるので、皆さんも活用してみてください。

3. リリース盛り上げ運動

プロダクトを成長させエンドユーザーに価値を届けることに重きを置くために、スプリントで開発した機能やカイゼンをリリースした際に、大々的に盛り上げるように心がけています。

開発と企画と営業とその他大勢が参加しているSlackチャンネル上でリリース物の概要を発表し、それに対して皆んなでリアクションやリプライを付けてリリースを讃えます。

最近のチーム内アンケートで「普段の業務の中で一番テンションが上がるのはどんなときですか？」と質問したところ、リリース時という声が多かったので、モチベーションアップのイベントごととして上手く機能しているように思います。

また、この運動は社内の誰もが閲覧可能な場所で実施しているので、他のチームからも反応をもらえたり、あるいは他チームでもこの運動を取り入れ始めたりと、全社的に好影響が波及していっています。

4. ファシリテーター持ち回り

スクラムの思想やプロセスをメンバーに理解させ遂行させることがスクラムマスターのひとつの大きな役割ですが、究極的にはスクラムマスターが存在しなくても回る状態が理想という話もあります。それはメンバー全員がスクラムの思想とプロセスを完璧に理解し、組織が完全に自己管理化できていると言えるからです。

弊チームでは、メンバー全員がスクラムに慣れたであろうスプリント10あたりから、レトロスペクティブのファシリテーターを持ち回り制にしています。

これにより、スクラムマスターが一方的にプレゼンテーションするようなコミュニケーションを避け、振り返りが毎回新鮮味のあるワーキングセッションとなるようにしています。

振り返り手法はファシリテーターが自由に決められるので、遊び心のあるような手法も試しながら、振り返りが有意義かつ誰しもが前向きに発言できる場になればと思っています。

5. アポなしショートミーティング

リアルに対面しての会話が無い分、メンバー同士のやりとりはどうしてもテキストに寄ってしまいます。

しかし課題が複雑であればあるほどテキストによるコミュニケーションのコストは上がっていくので、高コストがゆえに課題の報告を後回しにしてしまい、検知が遅れるという事態が発生しかねません。

そこで、少しでも複雑性を含んでいそうな話題は、その場ですぐにビデオ会議に移行するようにしています。

5分、10分、15分と短い時間をタイムボックスとし、課題の解決よりも課題の引き出しと整理に重きを置いて会話します。課題が整理され細分化されれば複雑性が解消され、残りはテキストベースでの会話で間に合うからです。ビデオ会議の中で会話した内容は必ずSlack上にメモとして残しておき、後から誰もが見返せる状態にしておきます。

この取り組みによって、開発メンバーから「作業中に出てきた迷いや不安をすぐに払拭できるのでありがたい」という感想をいただいており、実際にスクラムイベント以外のビデオ会議の回数が直近3ヶ月間で3倍に増えているので、フランクに直接会話できる環境があることの必要性が伺えます。

6. 調査スレッド

前述のとおり、リモートのスクラムではテキストベースでのコミュニケーションが中心になります。

リアルであれば困ってそうなメンバーに助け舟を出しやすいようなシチュエーションも、リモートだと課題が表に出てこず翌日にならないと検知できないことが度々あります。

これを防ぐために、何か懸念点や調査事項が出てきた際にはSlack上にそれ専用のスレッドを立て、他のメンバーが横からコメントやリアクションを入れられるようにしています。

7. ペアプロ、モブプロ

属人化の解消とチームワークの向上を目的として、適宜ペアプロやモブプロを実施しています。

開発メンバーからは「他人のコーディングスキルを吸収できる」「その場で議論しながら書けるのでコードの信頼性と品質が上がる」「できれば続けていきたい」との声をいただいています。より効果的な方法を模索しつつ続けていければと思います。

まとめ

ニフティ温泉ではパートナー企業様と一緒にスクラム開発を導入しました。

開発案件の透明性や優先度、目的意識についてメリットは享受できつつも、パートナー企業とのスクラム特有の「組織構造的な隔たり」「物理的な隔たり」「心理的な隔たり」という課題があらわになってきました。

これを改善するために、げんきカレンダーや価値観ポーカーなど様々な施策をもってコミュニケーションを活性化させようと奮起中です。

似たような境遇のチームのご参考になれば幸いです。