Backlogで挑む、透明化と越境 抽象編
私の携わっている25ヵ月にわたる基幹システム刷新プロジェクトにおいて22ヵ月が経過しました。当記事はその中で得た知見とプロジェクトの進め方についてまとめています。
下記「具体編」の続きです。抽象編と題し、プロジェクト管理にBacklogを導入することで起きた変化を踏まえ、プロジェクト及びチームの目指すべき姿について抽象度を上げた内容としております。
Backlogとはnulab社の提供するSaaS型プロジェクト管理ツールです（製品についてはこちらのリンクを参照）。経済産業省が採用し業務改善結果を出したことは大きな話題となりました。
なぜこの記事を書いたのか？
長い時間をかけプロダクト開発（私の場合プログラムです）に取り組む中で、プロジェクトが一歩前進するために不可欠な三つの要素に自分なりに気が付きました。新たな製品を生み出すという「不確実性との闘い」に明け暮れている方々にとって、日々の業務を見直すきっかけになればと、三つの要素についてここに書きます。
具体編は実際に起きた変化について事例ベースの記事にしました。具体を伴わないマネジメントの手引きを書いたところで理想論止まりだと私自身感じるからです。実際の事例を背景として、抽象度の高い（普遍的な）領域に踏み込んでみましょう。
Backlogで透明化に挑む
こんな経験ないでしょうか？
- いつの間にか、なぜ発生したか不明な修正がプログラムに施されている。
- 仕様書と実装に乖離があり、どちらを信じればよいのかわからない。
- 隣の席のやつは今何をやってるんだっけ？（忙しそうには見える）
透明化とはこれらの問題を解消することを目指した、プロジェクトのあるべき姿と私が考えるものです。ここでは二種類の透明化について書きます。
プロダクトの透明化
プロダクトの現在までの過程を起点となった発言や思想まで遡ることが可能な状態
チームの透明化
プロジェクトの現状についてメンバが共通認識を持ち、それぞれのタスクと着手状況が明らかになっている状態
先頭に挙げた三つの例は透明化がなされていないから発生します。
プロダクトの存在意義は問題解決。そして、問題が存在するのは、誰かが「今よりも良くしたい」と思ったからですよね。完成したプログラムやドキュメントから経緯や想いを汲み取ったとしても、想像の域を出ません。先人達は変更管理表や議事録という方法でそれを残してきましたが、それでは足りないと痛感してます。なぜなら、変更管理表に記載されるのは「AをBに変更」といった表面的な部分だけであることが非常に多いからです。
ゴールデンサークルという考え方があります。
サイモン・シネックにより提唱された「ものごとの核であるWhy(なぜ) から外側のHow(どうやって), What(なにを) と伝えることで人の本能に訴え共感を生む」というものです。シネックはWhyこそが本質に迫ると繰り返し伝えています。
なぜこのプロダクトが必要なのか？なぜこの仕様変更は発生したのか？なぜ私たちはこのプロジェクトに取り組んでいるのか？
プロダクトの透明化は変遷に「なぜ？」を付与することを目的とします。
私は顧客はプロダクトそのものに価値を見出すが、開発元にとっては完成に至る過程にこそ価値があると考えています。プロダクト自身も利用者も環境は日々変化します。現在への変遷が整理されていないとプロダクトの状態を保ち続けることはできません。新規メンバが参画した際にも過去から現在までの道筋が透き通って見渡せないとブラックボックスが出来上がる確率が高まります（某銀行のような悲劇が待っていることに…）。だからこそ、完成形の品質と同じくらい、なぜ今の姿になったかが重要なのです。
問題の起点は会話から生まれることが大半ではないでしょうか。顧客との電話しかり、メンバとの雑談しかり。決定した仕様だけをドキュメントに残すだけでは透明化は果たせません。
Backlogは透明化を推し進める強力なツールです。私たちはnulab社の提供するチャットツールであるTypeTalkで会話し、一連の流れをBacklogに紐づける形で課題登録することで課題発生の起点を追えるようにしています。また、Gitの commit も課題に紐づけ、コードの修正=該当する課題への対応と明示的に示す運用をとっています。会話⇒課題⇒成果物への一連の流れをBacklogで一元管理することで、成果物に「なぜ？」を付与することを実現可能となるのです。
複雑なことはしていません。整った土壌で、決められたルールで日々業務を行うだけです。
チームの透明化はガントチャートやカンバンを使用して「メンバが今何をしていて今後何をするのか」をリアルタイムで共有することで成立します。
それぞれのタスクを明確にすることは自走するチームへの成長につながります。詳しくは具体編に記載していますが、メンバの状況を明らかにすることでマネージャが指示せずとも勝手に助け合うように変化しました。ヒトデ型組織や生物的組織への第一歩とも言えます。
私が参画しているプロジェクトでは原則オープンチャットです。全てのやり取りをメンバが閲覧可能な環境づくりを心掛けています。
必然と隠し事をすることも難しくなります。私自身も「あいつだけが知っている」といった小さな隠し事が、重大な局面で脅威となって襲い掛かってくる経験を何度もしました。隠し事を生まない（意図せずとも）土壌が透明化を実現します。
そのためには、ネガティブなことを素直に言える、心理的安全性が担保されていることは必須です。
プロダクトの変遷を明らかにする。メンバの状況を共有する。そして情報をひとところに集約する。私が重要視する透明化のポイントです。
透明化の土壌が整ってきたら次は越境です！
皆で越境する
2019年のベストセラーFACT FULNESSにこんな一文があります。
人は誰しも、さまざまな物事や人々を２つのグループに分けないと気がすまないものだ。そして、その２つのグループのあいだには、決して埋まることのない溝があるはずだと思い込む。これが分断本能だ。
営業職と技術職、設計者と実装者、企業と顧客、周りを見ても多くの分断が存在します。まあ、お互いを分断することで生まれる一体感は実際ありますよね。。。しかし、良いプロダクトを生み出すために意味があるとはとても思えません。
設計者は綿密な設計書を書くことが仕事でしょうか？
プログラマはバグのないコードを書くことがゴールでしょうか？
顧客は要件の提示と金額の支払いをすれば責任を果たすのでしょうか？
全く違う。皆でよいプロダクトを生み出し活用することで、昨日より良い今日を迎えること。そのために尽力しているはずです。
そのためには分断を越える必要がある。越境です。
設計者は思想を共有し、実装者は技術的観点から議論し、可能であれば顧客にもアクセス可能な場所で公開すればいいと思っています。お偉い方への進捗報告に最年少のメンバが参加し「なぜこんなに遅れているかって？そもそもの要件がおかしいんだよ！！」くらい言ってもいいでしょう。分断によって本当に必要な人とものを作る人の距離が離れてしまい、「なぜこのプロダクトが必要か？」という本質が薄まってるように思えて仕方ないのです。
では、どうやって越境するのか？透明化がなされていれば越境は可能です。
経緯、思想、現状をステークホルダに等しく明らかにし、我々はなぜこのプロジェクトに取り組むのか？に対して共通の認識を持つことさえできれば境界なんて意味を持たないはずです。
Backlogを使う上で心掛けていることがあります。プロジェクトに対して個別に人を追加するのではなく、チーム単位で参加させるようにしています。必要な人間には皆同じ土俵に立ってもらい、同じ情報にアクセス可能な環境をつくる。越境のためには限られたメンバの自己保身なんて知ったこっちゃない。
俺たちが今まで何をしてきたか、何を考えているか、全部見せるから一緒に戦おう！という想いです。皆で越境しなければ、本当にいいものは生まれないと強く感じています。
心理的安全性が全ての土台となる
心理的安全性とは、Googleが提唱する効果的なチームを可能とする条件の中で最も重要とされる概念です。
心理的安全性とは、対人関係においてリスクある行動を取ったときの結果に対する個人の認知の仕方、つまり、「無知、無能、ネガティブ、邪魔だと思われる可能性のある行動をしても、このチームなら大丈夫だ」と信じられるかどうかを意味します。
透明化と越境について書いてきました。しかしこれらは心理的安全性が担保された環境でないと実現しないと断言できます。それほどまでに一人一人は弱く、伸び伸びとした環境でないと力を発揮できないと言えます。
コンウェイの法則に代表されるようにびっくりするくらいプロダクトは人間たちの影響を受けます。それもA君とB君は仲が悪いから、A君のシステムはB君のシステムとうまく連携しないという稚拙なレベルで。
結局どんなに素晴らしい思想や環境を用いても、今のところはうまくいかないというのが残念ですね（とんでもない技術革新が起きればあるいは）。
透明化も越境も同様です。
Backlogで挑むのは結局のところ心理的安全性の担保に帰結します。というのも、Backlogというツールはものすごく人の温かさやちょっとしたユーモアに重きを置いているんじゃないかなと思うのです。
具体編でも述べましたが全体的にかわいくて使うのが簡単です。例えばアイコン。一人一人アイコンを設定することにより画面の向こうには人がいるってことを思い出させてくれます。実際、想像以上の絶大な効果がありました。
ちなみに私が所属するチームはビオレママメーカーでアイコンを作ることが必須条件です。プロジェクトに参画した際に最初に行うことがアイコンを作ることです（協業先にもお願いしています）、このルールを発案した私たちのマネージャは本当に素晴らしいです。プロジェクトではこの顔がバグ報告をしたりします、なんかちょっと楽しいですよね。
↓ちなみにうちのシステムの偉い人です。これで怒られても怖さ半減です。
スター（Facebookでのいいね！に近い）ボタンも気軽に感謝を伝え、モチベーションの向上に非常に良い機能です。Backlogのスターボタンは何度でも押すことが可能です。いいね！ボタンを連打するなんて発想ありませんでした（nulab推奨）。
心理的安全性の担保は非常に難易度が高いミッションだと思います。仕事である以上、結果を出さなければ話になりません。メンバを律しつつ安心感も与える、マネージャの腕前の見せどころです。正解なんてないでしょう。
選択肢の一つとして、プロジェクト管理ツールに頼るのもありじゃないでしょうか。
さいごに
プロダクトを作るというのはなかなかにしんどい仕事です。でも、私は非常に魅力のある、己をかけてもいいものだと思っています。
一人で挑むにはつらい仕事です。透明化で健全な土壌を整えメンバと越境することができれば、今日よりよい明日へ繋がってるはずです。
この記事が日々の業務の進め方に迷う方にとって、小さなヒントになれば幸いです。
おまけ
当記事は私がJBUG岡山#3のLTのアドラーの心理学×Backlogをさらに拡張したものです（↓下記スライド）。Backlogやプロジェクト管理に興味がわいた方がいましたら、ぜひJBUGに遊びに来てください。全国各地でやってます！私は広島の主催者です、お会いできることを楽しみにしています。
おまけとして当記事を書くにあたって影響を受けたものを列挙して終わりとさせていただきます。長文にお付き合い下さり、ありがとうございます。
お付き合いいただきありがとうございました。
