全社共通の開発ガイドラインを作った話
はじめに
こんにちは。「メタルは全てを解決する」a.k.a.メタル先輩です。今日から年度が改まるタイミングで、新しい取り組みを始める方も多いのではないでしょうか。
私たちナビタイムジャパンでも、本日から新しい開発ガイドラインの本運用が開始しています。今回は、この開発ガイドラインについて紹介させていただきます。
なぜガイドラインを作ったのか
今回、ガイドラインを作成した狙いは以下のとおりです。
有用なプラクティス、フレームワークが共通言語となり全社の生産性が底上げされる
組織間のコミュニケーション方法が規定され良質なコミュニケーションを育む
フラットな組織から生まれる課題
弊社では2012年に組織がフラット化され、それまで以上にメンバーひとりひとりの自主性が尊重され、また自ら考えて行動を起こす姿勢が求められるようになりました。
フラットな組織の中で、自然と「短い期間で繰り返しながらつくる」文化が醸成されていきました。一方で、長い歴史の中で積み上げられたノウハウは暗黙知として蓄積されることが多くなっていきました。そのため、あるチームで育まれた有用な方法論が他のチームではまったく活用されていない、チームごとのスタイルが全然違うので新しいフォーメーションを組んだときの学習コストが高い、といった課題が生まれていきました。
現場の学びを組織の形式知にする「ガイドライン」
せっかく現場で育まれたノウハウを他の現場で活用しないのはもったいない、組織間での交流ハードルを下げたいーー。そのために考えられる方法としては大きくわけて2つありました。
ひとつは、開発プロセスを厳密に定義すること。
もうひとつは、望ましい行動をガイドラインとして定義すること。
今回は後者のアプローチをとりました。弊社のメンバーは、全員が「経路探索エンジンの技術で世界の産業に奉仕する」という経営理念のもとで働いています。けれども、その理念を体現するためにとるアプローチはそれぞれの現場で異なっています。乗換案内、カーナビ、事業者向け動態管理、地方創生…ビジネスもプロダクトも異なります。そして、そのときにとるべきアプローチというのは時を経るごとに変化していきます。
基準を示しながらも、現場での学びや気付きを活かして自分たちでやり方を選びとっていく。そういったチームの在り方を想定し、ガイドラインという形を選択しました。
どのように作成したのか
全社共通ということで、まず各事業でどのような違いがあるのかヒアリングするところからはじめました。そこから共通項を抽出しガイドライン初版を作成し、協力チームにパイロット実施を依頼。フィードバックをもとに改善…というプロセスで練り上げていきました。
また、作成中のガイドラインはパイロット実施しているチーム以外にも共有し、誰でもフィードバックできるようにしていました。
3ヶ月間かけて実際にガイドラインに基づいた開発を行ってもらい、そこからフィードバックをもらうパイロット運用では貴重な知見がたくさん得られました。Jiraのスクラムボード活用のノウハウが知りたい、ファシリテーションのやり方がわからない、プロダクトレビューを全員で実施するのはとてもよかった、などなど。
ガイドラインの内容
本ガイドラインは、大まかに3つの要素で構成されています。
アジャイルベースの開発プロセス
事業間連携を促進するコミュニケーションルール
ソフトウェア品質のガイドライン
ひとつひとつ、簡単に紹介していきます。
アジャイルベースの開発プロセス
まず、ガイドラインの主軸にアジャイルを置きました。これにはいくつかの理由がありますが、何よりアジャイルソフトウェア開発宣言で提示されている価値観が、今わたしたちが大切にするべきものだと感じているからです。
また、既に多くの現場で一部のアジャイルプラクティスが採用されていることも理由のひとつでした。例えば、社内ではスクラムをベースとした開発スタイルでありながら、あえてスクラムと呼ばずに自分たちの文脈に落とし込んでいるチームがあります。
このようにして作成された開発プロセスに関するガイドラインは、以下のようなコンテンツとなりました。
なにをつくるか考える（デザイン思考のエッセンス）
チームの共通理解をつくる（インセプションデッキ、ワーキングアグリーメント）
計画づくり
デイリー
プロダクトレビュー
ふりかえり
社内報告会
この中で、社内報告会というのはもともと10年以上前から社内に存在していた仕組みです。これは月に一度、誰でも参加できる形で事業・チームの成果を報告する場となっており、反復的な開発のリズムと報告会のインターバルを明示的に同期させよう、ということをガイドラインで提示しています。
事業間連携を促進するコミュニケーションルール
2本目の柱がコミュニケーションルール。ガイドライン自体は「知っておくことはマストだけど採用するかどうかは現場に任せる」という性質のものですが、ここだけは「ルール」としています。これは、コミュニケーションルールについては採用しているところとしていないところがまだらになると正しく機能しないためです。
事業間で連携する際には、単一の事業内で業務を行う場合より認識の齟齬がおきやすくなります。これは文化として形成された暗黙知が事業ごとに異なるからで、責任の所在だったり完成の定義だったりがずれやすくなります。そういったずれをなくすために、ここで定義したルールは以下のとおりです。
責任者をRACI図などを用いて明確にする
情報をConfluence上に集約する
DoD （Definition of Done)を定義する
ソフトウェア品質のガイドライン
3つ目がソフトウェア品質のガイドラインです。イテレーティブかつインクリメンタルに開発を進めていく中でソフトウェア品質の維持は重要な役割を果たします。
このパートは、弊社で長年Quality Managementの役割を担っている方を中心に作成してもらいました。
テスト、コードレビュー、モニタリング、設計についてまとめられたこのパートでは、レガシーコードとの向き合い方についても記述されています。
レガシーコードに直面した時、多くの人はこれを
ゼロから作り直したいという衝動に駆られると思います。
ところがこの選択でうまくいくことはそれほど多くはありません。
ナビタイムジャパンは2000年に創業。これまで、多くのシステムが開発され、運用され、また改善されてきました。作り直しに挑んだことも何度もあります。そういった経験の中から得られた成功、そして失敗をもとにガイドラインはつくられています。
世の中に標準的なガイドラインやベストプラクティスがあるというのに、なぜわざわざ自社でガイドラインをつくるのか。その大きな意義が、このような「その組織の歩み」を言語化するところにあるーー。メタル先輩は、そのように考えます。
ガイドラインを活用してもらうための取り組み
このように作成したガイドラインは、本日4月1日から本格的に運用を開始しています。ガイドラインの作成という観点ではいったんゴールを迎えたわけですが、ガイドラインの活用という観点では今日からがスタートとなります。
学びを深化させる
一部を抜粋したnoteでも、これだけの文章量になっていることからもわかるとおり、ガイドラインはそれなりのボリュームとなっています。通して読むだけでもそれなりに大変です。
ではどのように浸透させていくか。今、検討しているのは研修形式でのインプット。昨年度、社内でアジャイル開発研修を実施しましたが、同様の形式で実施しようと考えています。
また、いくつかの現場ではガイドラインの草稿が共有された段階から自主的に読み合わせを実施しています。自分たちなりに解釈し、落とし込むためには読み合わせはとても有効なアプローチです。
現在地を見える化する
ガイドラインへの適合度を測るチェックリストを作成し、定期的にチームごとの適合度をアセスメントしていきます。
そうすることでガイドラインへの向き合い方がどのように変化してきたか、動的に捉えることができます。
ひとつ気をつけたいのが「とにかくチェックリストを埋める」という行動につなげない、ということです。ガイドはガイド。内容を理解したうえで、自分たちで違う道を選ぶならそれでいいのです。ここは口を酸っぱくして、「あくまで現在の状況を知りたいだけで評価などに使うわけではありません」と伝えています。
おわりに
ざっくりとナビタイムジャパンの開発ガイドラインについて紹介してきました。
アジャイルベースの開発プロセス
事業間連携を促進するコミュニケーションルール
ソフトウェア品質のガイドライン
この3軸を明文化し、社内での共通認識をつくりあげ、今よりももっと世の中の移動に貢献できる開発を行っていきます。2022年度のナビタイムジャパンも、よろしくおねがいします。