Nikkei Advent Calendar 2020の21日目の記事です。

API・バックエンドチームの髙安です。開発以外にもエンジニア採用やエンジニア組織の課題解決に取り組んでいます。 本記事では、デジタル事業に関わる開発チームで実施した「開発プロセス座談会」を紹介します。

開発プロセス座談会を実施した背景

開発組織の健全性を測るために、DX Criteriaを用いて定期的に開発組織診断をしています。DX Criteriaとは、５つのテーマ、８つのカテゴリ、8つの項目で全320個のチェック構造を持つガイドラインです。診断結果が開発プロセス座談会を実施する背景になっているので、最初に診断結果について紹介します。

DX Criteriaの5つのテーマ

項目	概要
チーム	システムに関わるチームがどれだけ生産的に高速な仮説検証や開発を行うことができる状態にあるかをチェックする。
システム	システム自体がレガシー化されずにどれだけ安全かつ高速に改善できる状態にあるかをチェックする。
データ駆動	社内外のデータがどれだけ活用しやすい状態にあるか、また経営や意思決定に活用されているかをチェックする。
デザイン思考	デザインとUXから事業価値を生み出すために必要な仮説設定能力や習慣、効率的に行うための組織についてチェックする。
コーポレート	経営やミドルオフィス・バックオフィス機能がどれだけデジタル戦略を意識した活動ができているかをチェックする。

各チームでDX Criteriaを用いた診断を実施

チームごとにDX Criteriaのチェックシートを入力しました。実施概要は以下のとおりです。

実施概要

• 各チームのリーダーが「チーム」「システム」カテゴリーの128項目を約一時間で入力
• DX Criteriaの使い方は「DX Criteriaの使い方」を参照ください。診断用のGoogle Spreadsheetをコピーしてすぐに始めることができます

結果

チェックシートの採点結果です。チームごとに列が分かれています。チームごとに分かれた表は元々用意されているものではなく、考察用に独自にカスタマイズしたものです。各セルは8点満点で、緑のセルが多いほうが好ましく、赤いセルが多いと課題があります。元々技術ブログで公開する予定で調査を実施していないのと、次回以降の調査でも現状を忌憚なく教えていただくために、チーム名は伏せさせていただきました。

各チームと結果を一緒に見ながら改善策をディスカッションし、順次アクションアイテムに落とし込んでいきました。 列ではなく行ごとの結果に注目すると、同じカテゴリーでもチームによって結果にバラツキが見られました。上手くいっているチームもあれば、そうでないチームもあるということです。そこで、進んでいるチームのやり方を共有してもらい全体の底上げを図るべく、座談会を企画することにしました。

実は「team」カテゴリーのチェックリストで問われていることは、スクラムに則っているとyesと答えられるものが多いです。そこで、座談会ではスクラムを導入している日経IDチームとアプリチームの事例を共有してもらうことにしました。

スクラム導入の先行事例共有

日経IDチームの事例

日経IDチームでは、前職でスクラムを実践していた方が中心となり、スクラム導入を推進してきました。その内容について行っていただいたプレゼンは、大変興味深いものだったので、日経IDチームには別途記事を書いていただけることを期待し、本記事では一部の紹介に留めます。

スクラムは理論が分かっても、実践することが難しいと思っていますが、日経IDチームは色々細やかな工夫を凝らして非常に上手くスクラムを回していました。特に参加者から反応があった部分をご紹介します。

振り返りをFun/Done/Learn + Problemで実施していました。日経IDチーム独自の工夫でProblemを追加するところは、自省的で、着実に改善を重ねる姿勢が素晴らしいなと思いました。他には、メンバーがいいねの意思表示として☆マークをつけるような工夫もありました。チームが一体となって前向きで生産的な振り返りをできている様子が伺えました。

日経IDチームは社員4名、協力会社の方2名からなるチームです。日経では内製開発が進んでいますが、SES、フリーランス、副業の方にもサポートいただいて開発を進めています。社員と協力会社の方で一定の距離感があったり、カルチャーの共有が難しかったりすることが多いかと思いますが、チームとして継続して高いパフォーマンスを発揮するために、モチベーション向上やカルチャーの整備に気を配っていました。

アプリチームの事例

アプリチームはスクラムを導入し始めて2ヶ月程度で、日経IDチームに比べると試行錯誤しながら進めているフェーズです。日経電子版サービスでiOS/Androidアプリは重要なプロダクトであるが故に、様々な施策からの要望がアプリに集中しがちです。加えて、チーム外からの要望だけでなく、チームとして取り組むべき課題も存在します。 そういった状況の中で、一定のリリースサイクルを保ちつつ、プロダクトとして優先度が高いものから確実にリリースするために、スクラムを導入しました。

バーンダウンチャート

見積もりポーカー用シート

導入初期のため、スクラム用のツールは導入せずにスクラムマスターがGoogle Spreadsheetでぬくもりのあるバーンダウンチャートを作成、運用しています。スクラム導入のハードルを下げることで、スクラムでやっていくと合意したのちすぐにスプリントを開始でき、2スプリント目くらいから各メンバーがスクラムでの開発に順応できました。現在ではメンバーがスクラム開発になれて継続できそうなので、スクラムに適したプロジェクト管理ツールの導入を検討しています。

実際、効果は出ており、ベロシティが可視化されリリースのスコープ調整がしやすくなりました。開発者からは次に何をやるのか迷うことがなくなり、自発的に動ける余地が増えたという声もありました。

各参加者が考えたアクションアイテム

有意義なディスカッションができても、それで終わってしまってはもったいないので、各参加者になにか一つでも良いのでチームに持ち帰ってアクションすること、もしくは感想を挙げてもらいました。結果として、多くのアクションアイテムを挙げていただくことができました!

• タスクの粒度を合わせて、一か所にまとめるところから始めたい
• 各々の気づいたissueを作る時間を用意し、見積り・共有できるようにまとめる
• 成果物のデモをやりたい。KeepよりFUNは良いですね。issueの細分化とプランニングはとても参考になりました。一方で明確なサービス実装タスクのないSREはどう運用していくべきか…
• バーンダウンチャートを真心込めてつくります
• NikkeiID チームのスクラムイベントを見学してみたい
• 日経IDチームの「スクラム開発で気をつけていること」はとてもいいと思ったので自分も気をつけようと思いました
• 見積もりを小さくしたい！
• ツール入れて楽にしたいおきもち。ZenHubはマイルストーン周りが今のプロセスに合わなそうだなーというところで検証がおわってしまっている
• issueの中身をもっとしっかり書くようにしたい。タイトルだけしか書かないときとかあるので...
• 単純なKPTだけでなくFun/Done/Learn等メンバーのモチベーションを考慮した振り返りも取り入れたい
• こういったチーム横断での勉強会、いいですね！月1のプレゼン会(月1回各開発チームが取り組みを紹介する会があります)も同じテーマで複数チームが話す座談会方式もありかと思いました
• チームの開発状態を見えるようにするために、各種メトリクス(見積・実績、静的解析指標諸々...)を収集するところから着手しようと考えています
• チームの役割と特性を鑑みて、スクラムを導入した方がよいのかを含めてチームで議論を開始していきたい
• 見積もりポイントをつけることからやってみるとよさそう。見積もりすることで、タスクを評価したり、考えるきっかけになって、その他全般を改善するキッカケになる気がする
• ドキュメントの集約・ツールの統一、NikkeiID/アプリチームの開発プロセスをアレンジして各チームに展開する方法を考える

さいごに

開発チームが一堂に会して話す機会が実はあまりなかったので、まずはそういう場を作れたことは良かったです。 引き続き、チーム横断的な取り組みを継続し、改善アクションを積み重ねていきたいと思います。そして、開発者が快適に、のびのびと活躍して、事業が成長していく環境をみなさんと作っていければ嬉しいです。