社内で誰もがアジャイル普及に気軽に参加できる取り組みをしてみた
☆…..SHIFTアドベンドカレンダー2022……☆
DAY.24 Christmas eve
はじめに
こんにちは、上野です。 今日は社内で誰もがアジャイル普及に気軽に参加できる取り組みをした話をします。
何をやったの？
私は今年の秋ごろから初学者でも親しみやすいアジャイルの物語を作る取り組みをしています。 この取り組みを進めるうえで、ドキュメント管理をもっと楽にできないかと考え、 管理を効率化するとともに、フィードバックを得やすくすることに挑戦しました。
そもそも、なぜドキュメント管理が問題になるのか？
みなさんは、複数名でドキュメントを作成したりレビューを依頼したりするときどうしていますか？ バイナリファイルにバージョンごとのタイトルを付与しますか？ Wikiなどに書いて変更履歴が残るようにしますか？ 潔くテキストファイルに書き殴りますか？
ドキュメント管理なんてなぜWordではいけないのか？ とお思いの方もいらっしゃるでしょう。
一番の難点は変更管理がしづらいことです。
いやいやWordやPowerpointなら変更履歴やコメントをつけられるじゃないかとおっしゃいますか？ 確かにそうかもしれませんが、変更を重ねるほどいつだれがどこを直したのかが視覚的に見づらくなります。
あなたは、こうして変更履歴のつきまくったドキュメントの解読を諦め、変更履歴をすべて承諾、ファイルをコピー、「Version2」などといったプレフィックスを付与してリネームするでしょう。いつのまにかVersion3,Version4...と名の付くファイルが増殖していく地獄絵図を簡単に予想できます。
もっと致命的なのは、どういった意図でその修正を入れたのか記録を残さなくてもドキュメントをアップデートできてしまうことです。修正のレビューがされたのかされていないのか不明なまま、いつのまにかそのドキュメントは正式なドキュメントになってしまうのです。その結果、最新版がわからなくなります。
上記のようなことを避けるために、変更管理は非常に重要になります。
脱バイナリファイル！
ドキュメント管理で陥りがちな例を紹介したところで、アジャイルの物語を作成する取り組みの話に戻りましょう。
この取り組みでは、主に私が文章を作成し、プロジェクトのメンバーにレビューしてもらうことにしていたのですが、最初はバイナリファイルの形式で作成していたためにいくつかの問題が生じました。
まず、レビューが大変なことです。変更差分が見づらいため、指摘に対応した箇所がどこなのか一目ではわかりません。レビュー証跡が確認しづらく、レビュー済のファイルがどれなのかが次第にわからなくなります。さきほど述べた例と全く同じ問題に直面することになりました。
それに加えて、会話文は吹き出し形式にしたいなど見た目に凝りすぎる構想にしてしまったため、文章を書く以外の操作に多大な労力を費やすことになってしまいました。なぜスタイルシートで定義して簡単に適用できないのだろう、という悲しみがこみ上げます。
エンジニアの末席を汚すものとしてあまりにも不甲斐ないため、別のドキュメント管理方法を検討することにしました。
部内の誰もがプロジェクトに参加してもらえる状態を作りたい
せっかく別の方法を検討するタイミングなので、以下の条件を満たせる方法を採用したいと思いました。
レビューが楽にできること
ファイルを渡すことなく最新版にアクセスできること
指摘したい箇所ピンポイントでコメントがつけられること
誰がいつみてその結果がどうだったのか証跡が残ること
指摘に対する修正の履歴が追いやすいこと
文章の装飾が楽に適用できること
社内の人が気軽に読めるように公開できること
間違っているところは気軽に指摘してもらえること
こんな素敵な方法はないかと考えたとき、Code for Japanが主導しているシビックテックの取り組みを思い出したのです。
シビックテックのプロジェクトでは、活動の成果物をPublicなGithubリポジトリで管理しており、誰でもIssueやPull Requestを出すことができます。
もし同じことが社内でできたら、部内のアジャイルに興味を持つ人が読んでくれて、感想をくれるかもしれません。あるいは、アジャイルを教えたくてたまらない人達がレビューして指摘をくれるかもしれません。
Issueを上げてくれれば、そこでのディスカッションが学びになることだってあるでしょう。 アジャイル理解を深める活動に興味のある人が誰でも貢献できる世界を作れるかもしれません。
ということで、文章はMarkdown形式で作成し、社内のGitLabリポジトリで管理することにしました。 Markdownならスタイルシートの適用もできちゃいますしね。 そしてどうせならMergeされたら自動でデプロイされるようにしたいので、CI/CD パイプラインも構築することにしました。
採用した構成は？
弊社の自動化アーキテクトであり公式ブロガーでもある森川氏の全面的な協力を得て、最終的な構成は上図のようになりました。
まず作成者が文章を更新します。このとき、最低限の文章のミスを指摘する労力をなくすためにtextlintという文章校正ツールを実行します。 意図しない誤字脱字や文法の間違いがなければ、Merge Requestを出します。
レビューアがMerge Requestの内容を確認し、指摘がある場合は作成者が修正します。
指摘対応後、問題なければレビューアは変更をmasterブランチにMergeします。それをトリガーとしてMarkdownはHTMLにコンバートされ、S3バケットに配置されます。このタイミングで部内のTeamsに通知が流れるように設定しています。
右側が実際に公開しているドキュメント、左側がMarkdownです。HTMLはチャット形式で一見手が込んでいるように見えますが、Markdownはとてもシンプルに書けます。素晴らしい。
公開した部内の反響は？
社内運用をしてみたところ、部内の方々からいろいろ嬉しいお声をいただくことができました。
まず、アジャイルに興味のある人たちから「面白い！」「勉強になる」という感想をいただけました。中には、チーム内で読み合わせをしてくださった方もいたようです。嬉しい限りですね。
それだけではなく、もっとこうしたらわかりやすくなるのでは、ここの解釈に疑問がある、など現役スクラムマスターたちからのコメントも次々と寄せられるようになりました。 頂いた指摘はGitLabでIssue化して順次対応しています。
ということで、思ったよりも部内で注目を集める取り組みになったようで、嬉しい限りです。
まとめ
社内で誰もがアジャイル普及に気軽に参加できる取り組みをしてみた話、いかがだったでしょうか。こういった基盤を作ることで、参加のハードルがずいぶん下がっていくと思います。基盤を作れるエンジニアだからこそできる貢献ともいえるかもしれませんね。
社内でのアジャイルの普及に対する熱意を感じて、皆さんもっと気軽にアジャイル普及の取り組みに参加できる世界にしていきたいとも思いました。こういった取り組みも、コミュニティ活動の一つの芽かもしれません。別のところでもまた取り組んでいきたいと思います！
☆…..SHIFTアドベンドカレンダー2022……☆
DAY.24 Christmas eve
……☆..….
明日はいよいよクリスマス。
みなさまにとって心温まる素敵な1日となりますように。
さて、ラストの明日の記事もお楽しみに(^^)/
執筆者プロフィール：上野 彩子
QAリードとしてQAチームの立ち上げから育成、プロセス改善に従事。社内やコミュニティでテストやQAの価値、アジャイルの価値を伝える活動をしている。
・一般社団法人 Agile Japan EXPO 代表理事
・JaSST Tokyo実行委員長
・Agile Japan 実行委員
・博士（情報科学）
お問合せはお気軽に
https://service.shiftinc.jp/contact/
SHIFTについて（コーポレートサイト）
https://www.shiftinc.jp/
SHIFTのサービスについて（サービスサイト）
https://service.shiftinc.jp/
SHIFTの導入事例
https://service.shiftinc.jp/case/
お役立ち資料はこちら
https://service.shiftinc.jp/resources/
SHIFTの採用情報はこちら
https://recruit.shiftinc.jp/career/