BacklogのWikiとFigmaを活用したら全員ちょっと幸せになった話
2021年3月末から9月頃にかけて、チームでWikiとFigmaを活用した情報連携にチャレンジして、割とうまくいったのでその備忘録です。
目次
スライドでまとめてみたい方はこちらからどうぞ
2021/10/7 に このテーマで JBUG Autumn 2021 で登壇させていただいた時のスライドです。
プロジェクトの悩みあるある
まずは、よくあるプロジェクトの悩みです。みなさんもこんなお悩みをお持ちなのではないでしょうか？
- 発注者から資料がこない・資料が不足している
- 要件定義の中で何が決まって何が決まっていないのかわからない
- あの仕様が結局どう落ち着いたのかわからない
- 情報の発掘に時間がかかって作業が進まない
- そもそも何のためのサイトかよくわからない
私の立場はディレクターですが、デザイナーや開発者の方も思い当たるものはあるんじゃないでしょうか。
何が言いたいかというと、情報連携はプロジェクトにおいてむちゃくちゃ大事だということです。当たり前なんでしょうけどね。
とはいえ、全てのメンバーが沢山のやりとりや資料全てに目を通し、全ての情報を把握するということは現実的に不可能です。
弊社の受託開発プロジェクトにおけるこれまでの状態
前述のプロジェクトの悩みあるあるは、まさに2021年春までの弊社の受託開発チームの状態でした。
要件定義・設計段階
- 発注者から資料がこない・資料が不足している
- どんどん資料が追加されて情報が散っていく
- 更新された資料が届いたけど、更新箇所がパッと見てわからない（つらい）
デザイン・開発段階
- 要件定義の中で何が決まって何が決まっていないのかわからない
- あの仕様が結局顧客とのやりとりでどう落ち着いたのかわからない
- 情報の発掘に時間がかかって作業が進まない
- そもそも何のためのサイトかよくわからない
- 開発者は不明点をディレクターに聞くが、すぐに返事がこない
- ディレクターは、他の案件に手を取られて開発担当者からの質問にすぐ回答できない
社内の検品段階
- テスト前にどんな要件や仕様だったか、膨大な資料を見てインプットしないといけない
- 実装漏れ・考慮漏れなのか、そういう仕様で良いのかがすぐに判断できないケースが多い
- インプットや情報探しに時間がかかり、肝心のテストに時間が割けない
情報連携があまりなされていないことで、各メンバーの経験値による勘とスキルでカバーしている状態で、すごく属人化していたように思います。
お客様に面と向かって言われたことはありませんが、「要件・設計の伝達漏れによる実装・テスト漏れ」からの手戻りもあったかもしれません。が、それも開発者に水際でなんとか防いでもらっていたというのが実情だったように思います。
課題
以下、受託開発チームで課題としたことです。
- 情報連携がなされておらずコミュニケーションコストが発生し、作業時間が非効率な状態に。このため開発がストレスフルな状態になっている
取り組んだこと
期間：2021/4〜2021/9
- 発注者から提供された資料に記載された要件、サイトマップ、要件定義期間で決まった要件はすべてWikiとFigmaに記載
- Wikiベースで開発への申し送りMTGの実施
この2点がメインです。Wikiへの記載はディレクターが、Figmaへの記載は社内のデザイナーが担当しました。（ほんとは、Figmaへの要件記載も私がやろうと思ったんですけどまじで時間を作れなくてできていません、、）
ついでに、この機会にプロジェクトの前提もまとめようと思って、下記も実施しました。
3. プロジェクト概要、プロジェクトメンバー、プロジェクトポリシー等をWikiに記載
これは、開発への申し送りの意味も含みますし、後から自分で見直した時に思い出せるように、また、発注者の担当者が変わった時に見直していただけるように、という諸々の意図を込めました。
BacklogのWikiにまとめたもの
ざっと下記のようなものです。
- プロジェクト概要
- プロジェクトポリシー: このプロジェクトポリシーをコピーしてWikiにも転記しています。よかったら使ってください
- サイトマップ/ URL/ パンくず
- ウィジェット/ ウィジェットエリア
- インストールプラグイン
- 外部SaaS連携
- 広告管理枠
- その他機能要件
- デザインデータ置き場
＊細かい項目は、弊社LabWorksの「要件定義/設計 (RFP作成支援)」紹介ページから資料ギャラリーを見ていただくか、資料ダウンロードくださいmm
WikiとFigmaを活用した成果
1. 開発段階での「情報どこ？」の情報探しコミュニケーションがほぼゼロになった
前述に記載したプロジェクトの悩みあるあるがほぼ解消されたと思います。
というか、この活動をしていたらいつのまにか、いつもなら普通に発生する「XXXの仕様どこ？」「YYYってどう実装するの？」「ZZZないんで、確認してください」みたいなやりとりが、本人たちも気がつかない間にほぼ無くなりました。
2. 社内のテストもWikiとFigmaを元にしたらテスト工数が下がり、テストの網羅性が上がった
こちらは想定外に出た成果です。
当社では、社内のテストはディレクターとデザイナーが行っています。これまでは要件や仕様の情報を探しながらテストをしていたのが、改善後はWikiとFigmaだけ見ればテストができるようになりました。
結果、テストの網羅性が上がり、かつプラスアルファのテストもできるようになりました。 「開発者が楽になればいいな」と思ってWikiをしこしことまとめていた自分にとって、自分も意外に楽になったというのは驚きでした。
体感値でいうと、テスト工数は最大で20％くらい削減できたような気がします。（言いすぎか？）
まとめ
- 情報はなるべく１か所、多くても２か所くらいにまとめるのが吉
- チームの悩みを適切に改善すると、チーム全体がちょっとハッピーになる
とはいえまだまだ理想の状態になっているとは全く思っておらず、課題や改善できる部分は沢山あると思います。要件定義段階でデザインを進めることもよくあるので、デザイナーさんにはいつも迷惑をかけています。Wiki も目下絶賛改善中です。
今後も色々な会社・色々なプロジェクトの改善例を参考にさせていただき、今後も少しずつ現場をよくしていきたいと思います。
