2024.12.10
“放置系”なのにサイバー攻撃を監視・検知、「統合ログ管理ツール」とは 最先端のログ管理体制を実現する方法
リンクをコピー
記事をブックマーク
伊藤潤平氏(以下、伊藤):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.12.10
メールのラリー回数でわかる「評価されない人」の特徴 職場での評価を下げる行動5選
2024.12.09
国内の有名ホテルでは、マグロ丼がなんと1杯「24,000円」 「良いものをより安く」を追いすぎた日本にとって値上げが重要な理由
2024.11.29
「明日までにお願いできますか?」ちょっとカチンとくる一言 頭がいい人に見える上品な言い方に変えるコツ
2024.12.09
10点満点中7点の部下に言うべきこと 部下を育成できない上司の特徴トップ5
2024.12.04
いつも遅刻や自慢話…自分勝手な人にイラっとした時の切り返し 不平等な関係を打開する「相手の期待」を裏切る技
2023.03.21
民間宇宙開発で高まる「飛行機とロケットの衝突」の危機...どうやって回避する?
2024.12.03
職場の同僚にイライラ…ストレスを最小限に抑える方法 臨床心理士が語る、「いい人でいなきゃ」と自分を追い込むタイプへの処方箋
2024.12.06
嫌いな相手の行動が気になって仕方ない… 臨床心理士が教える、人間関係のストレスを軽くする知恵
2024.12.05
「今日こそやろう」と決めたのに…自己嫌悪でイライラする日々を変えるには
PR | 2024.12.04
攻撃者はVPNを狙っている ゼロトラストならランサムウェア攻撃を防げる理由と仕組み