2024.10.10
将来は卵1パックの価格が2倍に? 多くの日本人が知らない世界の新潮流、「動物福祉」とは
リンクをコピー
記事をブックマーク
伊藤潤平氏(以下、伊藤):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.11.13
週3日働いて年収2,000万稼ぐ元印刷屋のおじさん 好きなことだけして楽に稼ぐ3つのパターン
2024.11.11
自分の「本質的な才能」が見つかる一番簡単な質問 他者から「すごい」と思われても意外と気づかないのが才能
2024.11.13
“退職者が出た時の会社の対応”を従業員は見ている 離職防止策の前に見つめ直したい、部下との向き合い方
2024.11.12
自分の人生にプラスに働く「イライラ」は才能 自分の強みや才能につながる“良いイライラ”を見分けるポイント
2023.03.21
民間宇宙開発で高まる「飛行機とロケットの衝突」の危機...どうやって回避する?
2024.11.11
気づいたら借金、倒産して身ぐるみを剥がされる経営者 起業に「立派な動機」を求められる恐ろしさ
2024.11.11
「退職代行」を使われた管理職の本音と葛藤 メディアで話題、利用者が右肩上がり…企業が置かれている現状とは
2024.11.18
20名の会社でGoogleの採用を真似するのはもったいない 人手不足の時代における「脱能力主義」のヒント
2024.11.12
先週まで元気だったのに、突然辞める「びっくり退職」 退職代行サービスの影響も?上司と部下の“すれ違い”が起きる原因
2024.11.14
よってたかってハイリスクのビジネスモデルに仕立て上げるステークホルダー 「社会的理由」が求められる時代の起業戦略