アジャイルQAジャーニー#2(情報設計と品質)
1.品質に必要な情報設計
こんにちは。SHIFT技術推進部アジャイル開発推進Gの谷岡です。
品質保証部隊として多くの開発現場に入らせていただきましたが、品質に悩みを抱えているお客様の多くは「コミュニケーションの難しさ」「組織やプロダクトの複雑さ」に苦労されているようです。
品質を高める要素はコミュニケーションやプロダクトの情報整理の中にも存在します。リモートワークが進む一方で、以前と同じ情報量を得るために対面時以上の高いコミュニケーション能力が求められます(※)。
難易度が上がると合意に時間もかかるし認識の齟齬が発生しやすいため、アジャイル開発現場においては致命傷になり得ます。
※：Googleはオンラインイベント「Google I/O 2021」にて、同社が開発中の先進的なオンラインコミュニケーションシステム「Project Starline」を発表しました。まるでそこに人がいるかのような技術です。リモート特有の課題が解決する日は近いかもしれません。
この記事では、本来助けとなるはずの情報が弊害になるのではなく、品質を支える手段となるにはどうすれば良いか、探究していきます。
2.混乱と情報設計
アジャイル開発現場に限らずよく聞く現場の声を並べてみます。
【開発現場での声】
「情報が体系的に整理されておらず、欲しい情報の所在が不明」
「いろんな場所に同じような情報が重複して存在している」
「古い情報が混じっていて何を信じたら良いのかわからない」
「細かい情報は沢山あるが、前段の背景がわからない」
「情報の紐付きがわからず、情報の使い方や(システム等の)影響範囲がわからない」このような状態で高い品質のプロダクトを作ることができるでしょうか。もしこれで上手くいっているとしたら、情報は一子相伝で引き継がれ、属人的に知識を習得して頑張っている誰かのおかげです。その人が倒れたらどうしましょう？
この状態から抜け出すためには適切な情報設計が必要です。
アビー・コバートは「今日からはじめる情報設計 センスメイキングするための7ステップ」のなかで
混乱とは何かがわかりにくく困難を極めているあらゆる状況のこと
と伝えています。
そして、我々が日常生活の中で取り組む混乱には以下があると言います。
・チームや組織の構造
・共同作業への取り組み方
・製品やサービスの説明/販売/配送方法
・お互いのコミュニケーション
ソフトウェア開発の現場課題にそのまま当てはまりますね。同書では混乱に対処するための最初のステップは
混乱に光を当て、その大きさと深さを把握することです。
と書かれています。
まずは混乱を把握すること。そして適切な情報設計を行って整理することでコミュニケーションコストが下がり、プロダクトの難易度も下がることで総合的に品質が高まっていくことが期待されます。
3.情報の分類
それではプロダクトの開発ではどのように情報を取り扱えば良いのでしょうか。混乱の大きさと深さを把握するためまずは情報を分類してみます。
これは持論ですが基本的に人間の認知と効率を考慮したときに情報を取り扱うアクターとしては新規メンバ層、マネージャー層、そしてプレイヤー層(開発者)が存在すると考えています(図1参照)
【図1】
簡単ですが解説すると、
【図1の解説】
1)新規メンバ層：抽象度高の概要レベルの情報から入った方が理解が深まります。
2)マネージャ層：横断的に情報を把握して管理や経営に重きを置きます。
3)プレイヤー層：情報を認知したプレイヤー同士で具体的な情報を詰めた方が効率的に作業できます。
一方で、新規やマネージャは抽象度の低い(＝具体的な)話を初手でされても理解に時間がかかります。どういった対象者に向けて、どんな情報を配置すれば良いのか階層構造で示したのが上記の例です。必ずしも階層構造である必要はないですが抽象から具体に向けて分解することで認知のしやすい構造となっているかと思います。
【図2】
次に図2ではプロダクトを形作るうえで足の速い情報、遅い情報、動かしてはいけない情報を表現してみました。また、それぞれがどういった場面で使われるかも吹き出しで記載しました。こうした情報の速度を分類することで今取り扱っている情報が図1のどのエリアに配置するとより活かせそうか見えてきます。
4.情報の整理
つぎに、分類した情報をどう整理していくのかですが、情報整理についてはこちらの記事が非常にわかりやすくまとめられており勉強になります。
ここではLATCH（以下の分類の頭文字）によって整理するのが望ましいと書かれています。
Location(場所)、Alphabet(あいうえお順)、Time(時間順)、Category(種類別)、Hierarchy(階層化)
興味深いのは、「経験の影響が強い整理方法」や「検索性の良し悪し」、「こうもり問題（どちらにも属する可能性がある）」にも言及しているところです。情報に対する理解が深まりますのでぜひご一読ください。
プロダクト開発現場は開発が進むにつれて経験則が蓄積されていく業界かと思います、またアジャイルで進めた場合にはトライ＆エラーで小さく進めてフィードバックを得て、振り返ってまた前に進みます。
上記の記事をもとにお話を進めさせていただくと、具体的に決めて進めていくような箇所（図1の下層部分）については、
「 Location(場所) 、 Category(種類別) 」
を活用して経験の影響が強い情報整理をしていくのが良いでしょう。
一方で、経験の適用が必要ない分類(図1の上〜中層部分)については
「 Alphabet(あいうえお順)、Time(時間順)、 Hierarchy(階層化) 」
を活用するのが良いでしょう。
5.情報を扱う場合の注意点
情報を作成→分類→整理してきましたが「何故をそれをつくるのか、情報を作ることが目的になっていないか」「誰がそれを使うのか」「一度きりの情報になっていないか」など一度立ち止まって振り返ることも大切です。
これまで私がみてきた中で、これは特に注意したい点として以下を挙げます。
【情報取扱注意点】
■マイクロマネジメントは避ける
・一度作ったもの他者との整合性が必要になる作りとしない。
・同じものは転記やコピーではなく、リンクで管理（ネストに注意）
・動的情報は一元管理して管理元からのリンク紐づけが望ましい。
・更新をかけるものについては定期的なクレンジングを行う。
■属人化を避ける
・特定の技術や情報が欠けても問題なく回るかを条件毎に検討する。
・体制と合わせて役割や問い合わせ先を明文化する。
■説明にはイメージを添付して共有イメージを持つ
同じ話をしていても認識が異なる背景にはイメージの共有ができていないことが多いため、
同じものを見てコミュニケーションをとるとよい。理解の促進につながる。6.テストは情報収集業務
ここまで情報設計について触れてきました。ではいざプロダクトの品質に思いを馳せると不具合がないものか確認したくなります。そう、テストです。
ジェラルド・Mワインバーグは「パーフェクトソフトウェア」の中でテストについての私の認識を正してくれました。その一節を紹介します。
・テストは、製品に関する情報を収集する業務である。その結果間違いが見つかっても、それを直しはしない。テストは製品をよくするものではない。よくするのはテストで見つかったバグを直す人たちの仕事だ。
・プログラムを実際に使ったらどうなるか情報を集めること、それが人々が「テスト」と呼ぶものの一種である
・テストは修正とは違う。テストにコストをかけて収集した情報を「受け取っている」かどうかという問題に行き当たる。
・私の経験では、テストについて不満を言う人の半数は、テスト結果に隠された情報をすべて追求し切れていないマネージャである。収集された情報を使わないなら、テストにコストをかける必要はない。
テストは情報収集業務であって、品質を上げる行為そのものではないのです。わかっていましたが明言されると痺れます。品質をあげたかったら情報を適切に扱い開発者へそのバトンを渡すしかありません。
なるほど、情報を品質に活かすフローはつまりこうなりそうです。
【品質に活かす情報フロー】
1)情報設計を行い、どんな情報をどう分類して配置するかを決める。
2)コミュニケーションを行いプロダクトの方針や詳細について合意を取る。
3)合意内容に沿ってドキュメントに纏め、然るべき箇所に整理する。
4)整理された情報を収集した後、期待値通りかを確認する（＝テスト）
5)テストの結果を情報として開発者に渡す。
6)情報を受け取って開発者は修正を行って不具合を解消する。6)の情報を渡す時まで気を抜かないことも大切です。ブレない確実な修正結果が帰ってくるように情報を渡したいものです。
7.まとめ
情報を捉え直すことで、混乱と対極にある状態に落とし込むための道標を書きました。品質を担保するために行うテストも情報収集の一環であり十分にその結果を活用しない限り品質は向上し得ないということを今回お伝えしたかった次第です。
【品質に活かす情報フロー】にあるプロセスを高速に回すことでアジャイル開発現場の品質確保が期待できます。まずはトライしてみてはいかがでしょうか。本記事が皆さんのソフトウェア開発の一助となれば幸いです。次回は概要だけでなく具体的なエピソードも交えた話を書きたいと思います。
最後に余談ですが、突き詰めると情報設計はコミュニケーションの基本に立ち返ります。結局のところ自分以外の誰かへの思いやりの積み重ねであることに気づかされます。想像力を持って情報を取り扱っていきたいと思います。
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
執筆者プロフィール：谷岡 俊祐
2児の父。SIerにて自治体向けシステム開発に長年従事した後、SHIFTへ入社。エンジニアの知見とQA×SMの観点で業務改善や因数分解、チーム改善が得意。
最近は蓄積された知見や業務を如何に低コストで掬い上げるかをテーマに手法確立に向けて試行錯誤中。
《この公式ライターの他の記事を読む》
アジャイルQAジャーニー#1（リスクベースで見る開発手法判断）
父と子のソフトウェアテスト入門(1)
《NEW!!》資料ダウンロード／動画視聴ページはこちらから
■メディア掲載情報
■SHIFTについて
私たちはソフトウェアテスト(第三者検証)のプロ集団です。
お問合せはお気軽に
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/