2024.10.01
自社の社内情報を未来の“ゴミ”にしないための備え 「情報量が多すぎる」時代がもたらす課題とは?
リンクをコピー
記事をブックマーク
伊藤潤平氏(以下、伊藤):Living Document。“生きたドキュメント”という意味ですが、このアイデアはすごくジャネット先生も提唱していて。ゴイコさんとダンノースさんという人が提唱したものらしいんですが、すごくいいアイデアだと言っていました。
これはアプリ開発のチームの話ですが、アプリ開発のチームはプロダクトマネージャーからパワーポイントで要求仕様書がきます。1スライド1機能くらいに絵でまとめられています。それをバックログに1機能1チケットくらいで情報管理して、そのバックログをもとに、開発やテストをしていました。
しかし、情報量が多すぎて、私が見てもぜんぜんわからない。情報を追っていけない状態でした。「仕様が間違っていたので直しました」とか、「このチャットのここの会話で仕様が変わりました」とリンクがペッて貼ってあったりとか。なにが正しい情報なのか、イチから追っていかないとわからない状態になっていて、すごく苦労しました。
プラス、テストの計画書を作ったことがないチームだったので。であれば、もうテスト計画書を作って、その中で情報を整理しましょうという話をしました。
作ったことがない人が多いので、なるべくシンプルなテスト設計書を作りました。シンプルなものにこだわったのは、実はウイングアーク1stでは、ISO/IEC/IEEE29119-3に準拠したテスト計画書を作っています。
ただ、これはすごく複雑で、たぶん作ったことがない人が見たらわからないだろうなというものがあったので、本当にシンプルさを重視することにしました。テストの目的とか、何をいつまでにという情報をこの中に入れました。
ちょっと見にくいかもしれませんが、我々は100パーセントのうち60パーセントの品質を目指しますよと。この中にはこんなテストタイプを定義していて、優先順位はこうですと。これをスケジュールに落とし込むと、こんな感じになって、テストベースは成果物とマッピングする必要があるという、テスト計画書です。
“生きたドキュメント”と言ったのは、トレーサビリティ。つまりテストベースに対するテスト成果物のトレーサビリティのマッピングです。ちょっと小さくて見にくいんですが、テストベースとテスト成果物というのがあって、テストベースは、要求と設計と実装みたいな感じです。
要求だったらパワーポイントのこのページに書いてあって、設計だったらバックログのこのチケットに書いてあります。テスト計画書はこのドキュメントで、テスト設計はマインドマップのこのノードに書かれていますとか。
テスト実装とテスト実行はGoogleスプレッドシートのこのシートに書かれてあって。テスト分析に関してはバグトラッキングシステムに記入しましょう、という情報を入れていきました。
バックログしかない状態のチームだったので、これだけきれいに見えるのであれば、プロダクトマネージャーはレビューのタイミングを入れやすくなる、という話をしてくれました。
プロダクトマネージャーからすると、チケットを見てもよくわからない状態だったので、できあがったら見るみたいな。プロジェクトの後半でプロダクトマネージャーのレビューのタイミングがあり、よくちゃぶ台返ししていたらしいんですね。
彼も彼ですごく反省していると言っていたんですけれど、よくちゃぶ台返しがあったと言っていました。なので、このテスト計画書を見て、「この機能ができたのならもうそろそろ見ようかな」みたいな。そんなタイミングが入れやすくなるという話。
現場のプログラマーは「割り込み対応やちゃぶ台返しがよくあったので、プロジェクト後半になると、リスクがだいぶ出てきた」と。「ただ、この生きたドキュメントの中で、リスクが発生したら、すぐにチームみんなに共有しやすくなった」と、そんな話がありました。なので、「早いフィードバックプロセスは本当に大事なことですね」という話をしました。
現在は、お客さまから「最近トラブルがなくなってきましたね」と言ってもらっています。私の中ではすごくうれしい言葉だな、と思っています。
おもしろかったのが、BIの開発チームでは、新年になった時に「私は2021年は心を入れ替えて単体テストを完璧な状態にします」と言った実装者がいたことです。
それはなぜかと言うと、やはりいろいろ罪悪感を覚えていたらしくて。単体テストを完璧な状態にすれば、みんなに迷惑をかけなかったんだという意思があって、画面のスクリーンショットをしっかりと残すみたいな。「それはもう単体テストじゃないよね」くらいのレベルのテストを実装者がやっていました。
あと、ユースケースを作ったので、「ユースケースを考えながらテストや開発ができれば、たぶんもっといいものができるね」みたいな話もしてくれました。
これもちょっとうれしかったことなんですけど、「リグレッションテストをけっこういっぱい作って、みんなにやらせたら、これは自動化しないと保たないね」みたいな話があって。やっとこれで、自動化の話ができるなという瞬間でした。
次にアプリの開発チームです。“生きたドキュメント”ということで、テスト計画書を作ったら、これがすごく大事だということがわかった、という声がありました。
あと開発者は、自分のローカル上では単体テストをやっている話で、「この単体テストのプロセスもドキュメントの中で見える化できたらいいな」みたいなことを言っていたので、「ATDDとかBDDとかプラクティスはたくさんあるので、ぜひ一緒に考えていきましょう」みたいな話をしました。
プロダクトマネージャーは「安心で安全な今の品質状態を継続したい」。つまり、「伊藤さんずっといてやってくださいね」みたいな話をしてもらいました(笑)。
Whole-Teamのアプローチは、今私の頭の中ではこんな感じです。お客さまを中心にして、BIチームとアプリチームがありますが、そこには壁はなく、みんな一緒のチームになっているようなイメージ。まだ課題はたくさんあるとは思いますが、解決しやすくなっている雰囲気を感じます。
未来です。最初に失敗談をしました。テストの自動化とQA監査ですね。テストの自動化は、あるメンバーからリグレッションテストは絶対自動化したいという話だったので、そういう人を集めれば、自動化は実現するんだろうなという思いでいっぱいです。
QA監査はやめました。今は、QAとテストエンジニアとSETとSREの三角錐の図。その前はQAファンネルといって、漏斗の絵ですね。QAのロールを可視化したようなものを、QAファンネルと言っています。
(スライドを示し)上からフェーズゲートQAとかQAサービス、インプロセスQA、QAコーチ、QAコンサルタント、QAプロモーター。私は最初、QA監査という言葉をやめてQAコーチとして入りますと言っていました。今はなんとなく、QAコンサルタントの位置くらいにいると思っています。将来は、QAプロモーターとして組織全体にQAを推進していくような役割をしたいと思っています。
QAはスクラムマスターではないとは思います。思うんですけれども、プラクティスはすごく真似できると思っています。QAプロモーターはその名のごとく、QAをプロモートしていく、組織に対してQAを推進していく人です。
それに対してはティーチングやメンタリング、コーチング、障害物の除去、ファシリテーションという、そういったプラクティスを継続しながら、チームを自己組織化していきたいです。
自己組織化というのは、Whole-Teamで品質にフォーカスした開発をする。そういった活動をずっと観察して、自分の手が離れたら、その時は離れ時なんだなと。すごくスクラムマスターに似ている感じがしています。
ということで、ここまでが私の事例発表でした。ご清聴ありがとうございました。
関連タグ:
2024.10.29
5〜10万円の低単価案件の受注をやめたら労働生産性が劇的に向上 相見積もり案件には提案書を出さないことで見えた“意外な効果”
2024.10.24
パワポ資料の「手戻り」が多すぎる問題の解消法 資料作成のプロが語る、修正の無限ループから抜け出す4つのコツ
2024.10.28
スキル重視の採用を続けた結果、早期離職が増え社員が1人に… 下半期の退職者ゼロを達成した「関係の質」向上の取り組み
2024.10.22
気づかぬうちに評価を下げる「ダメな口癖」3選 デキる人はやっている、上司の指摘に対する上手な返し方
2024.10.24
リスクを取らない人が多い日本は、むしろ稼ぐチャンス? 日本のGDP4位転落の今、個人に必要なマインドとは
2024.10.23
「初任給40万円時代」が、比較的早いうちにやってくる? これから淘汰される会社・生き残る会社の分かれ目
2024.10.23
「どうしてもあなたから買いたい」と言われる営業になるには 『無敗営業』著者が教える、納得感を高める商談の進め方
2024.10.28
“力を抜くこと”がリーダーにとって重要な理由 「人間の達人」タモリさんから学んだ自然体の大切さ
2024.10.29
「テスラの何がすごいのか」がわからない学生たち 起業率2年連続日本一の大学で「Appleのフレームワーク」を教えるわけ
2024.10.30
職場にいる「困った部下」への対処法 上司・部下間で生まれる“常識のズレ”を解消するには