JaSST_Review'23QA
番号

質問

回答

1

自分より(スキルや立場が)格上の相手とコミュニケーションを取ることに怖気付いてしまいます。 なにか処方箋はありますか？
威圧的なボスがチームのパフォーマンスを抑制してしまっている状態で支援に入った場合、どのようなアプローチを取るのがよいですか？

自分が対等な立場であろうと頑張るのではなく、「全く分からない私に教えてください」という姿勢でコミュニ
ケーションをとってみてはいかがでしょうか？

2

3

4

5
678

910

11

よくあるパターンです。善意で言っているがよくない影響を与えるとか。
自分の立場を表明するのが先ですが、まずは威圧的ボスと人間関係を作る。
どうしてそのような威圧的対応を行うのか？を把握する。
実は「恐れ」からそういうことをしている。
彼も別のところから同じように圧力を与えられている。
ときに悪意を持っている人もいる。その場合はさらに上のランクの方で助けてもらえないかを考える。その人は組織的なリスクなので。
多くの関係者が威圧的な組織であれば、その場から立ち去ることも視野に入れる。
必ずしもそこにいなければならないわけではない。
（講演内で回答）
Lisiさん、講演ありがとうございました！チーム文化が品質に直結する、すごく心に残りま 変化が起きたことを記録に残す。ちょっとしたことをメモる。
した。質問です。チーム文化を変え、それが品質によい影響を及ぼしたとしても、その効 メモ魔。それを拾っていく。定性的なフィードバックが多い。
果を見える化するのはとても難しそうです。Lisiさんはどんな風に見える化しましたか？ 定量的なデータも併せて見せる。視覚的に描く。
（講演内で回答）
完璧主義は、どうしたらやめれますか？言葉ではわかります。ですが、終わりの基準が 終わりの基準を作るのではなく、タスクの分割に注力してみてはいかがでしょうか？
わかりません。どんなことを考えているか、ぜひ教えてください。
細かく区切ったタスクに対して完璧主義を活かして終わらせるようにしてみると良い気がします。
（講演内で回答）
組織図的な、上が下を管理するという傾向が強い組織で、上司（リーダー）があまり「チー リーダーが大事にしていること、困っていることに紐づけてアプローチするのが一つの事例です。
ムで進める」というアプローチに乗り気でない場合に、メンバーの立場からそのようなリーダーを巻き込んで進めていくための良いアプローチはあるでしょうか？
チームのメンバーが自らの意思でチームプレーを実践できるようにすることを重視しているから（それは人Lisiさんが1番に「People First」を持ってきた理由をもうすこし深く知りたいですが考え、判断し、行動すること）なのではないかと思われますが、その真意はLisiさんに直接確認していただくのが良いと思います。
チームがあまりプライベートなことを話さない風潮の場合、どういうアプローチがあり得ま いただいた質問がどのようにレビューに関係するのかが理解できませんでした。その内容次第で回答が異すか？（まず自分のことを話す、というアイディアは思いつきましたがそれ以外に）なりますので、申し訳ありませんが回答を断念しました。
Lisiさん、講演ありがとうございました。めちゃくちゃコミュニケーション力高いと伺えました もともと下手だったので上手だと言われてうれしい。双方向の対話。
が、コミュニケーション力をどうやって身に付けましたか？
バレーボール＝チームスポーツの中で培われた気がします。
チームコーチもやることでさらに磨かれた。
より大きなコミュニティに関わる。
講演するようになった。そうなるとは思わなかったが実践を繰り返しながら学ぶことができる。一つでも持ち帰ってもらえるように努力している。
要は練習です。
（講演内で回答）
アジャイル開発のように、製品のぼんやりしたイメージからスタートするような場合には、 その考えで良いと思います。
詳細なレビュー観点を設定してもあまり意味がないように思います。今回の話を受けて、 ざっくりと作成して、開発を進めていく中でブラッシュアップすれば良いと考えています。
レビュー観点も開発と同じようなライフサイクルで段階的詳細化したり、フィードバックによる改善を伴うものと考えた方がいいのでしょうか？
今研究会の方でまとめられているものは、ある程度抽象化されたレビュー観点と考えて 私たちで一度トライしてみた段階です。各組織での活用方法も含め、継続議論中です。まずは利用してみよいでしょうか？25000シリーズの様にある程度体系化されて整理されたレビュー観点 て、フィードバックを頂けると嬉しいです！
を、各企業各プロジェクトで詳細化するようなイメージと考えてよいですか？
個人的に机上レビューは好きではないし自分に合わないですが、会議を設定してレ決めの問題です。他の方がレビュー好きであればその方に実施していただく、その分自分が好きなことでビューアの時間を取ってしまうのもそれはそれで気が引ける部分があります。どのように 他の方が好きではないことを代わりに実施する、気が引けるのであれば気が引けない方に設定していただ
行えば良いでしょうか？
いて、その分自分がガンガンできることを代わりに担当するといいのではないでしょうか。

1

JaSST_Review'23QA
12

プロジェクトにおいて十分なレビュー工数を確保できません。どのようにして確保すれば良いでしょうか？

13

今後はAIにレビューしてもらうこともあると思いますが、どういうことに気をつければいいと思いますか？
レビューする側になってまださほど時間が経っていないので、レビューする側としての考え方を知りたいです。

14
15

チームとしてレビューで有効な指摘を出せるようなるためにはどうしたら良いのでしょうか？

16

効率よくレビュアーを育てるためにはどのようなことをすればよいでしょうか。 特にビジネス要求を踏まえて要件定義をレビューできるようになるにはどのような手法を取るべきか気になっています。

17

レビューがエビデンスを残すだけの形骸化した作業となっている事象を解決したいです。
レビューにおける目的化の明示と対応を改善としたいが、この改善項目が効果がないとして拒否されています。 何かしらのアドバイスがあればお願いします。
自分や他レビュアーのレビュー観点の言語化がうまくできないので、なるべく細分化された観点例のリストのようなものがあれば見てみたいです。

1819202122232425

自社の製品に適したレビュー用のチェックリストを作っていきたいがどこから手をつけていいかわからないです。一般的な観点や、最初の一歩を踏み出していくアプローチが知りたいです。
現時点では個々の経験に頼っている状況なので、レビューの具体的手順、指針等があれば知りたいです。

おそらく十分という定義がバラバラなのではないでしょうか。まずは十分な質を定義（重要なことから数段階に分けて可視化）し、時間をどれくらいかけないと何が後でどれくらい困るのかをチームで検討してみると良いと思います。
AIには意図がない（あったとしても人間が善悪を判断していないものや必ずしも良い習慣ではないことが含まれる）ため、あくまでも間違っているかもしれない前提で利用するのが良いと思います。
作成者と一緒によい成果物にしていく、そのことを目指すのが大前提だと思います。
（講演内で回答）
実施前までに「どのような指摘事項を出したいのか＝何が有効な指摘なのか」「それを検出するためのレビュー観点」を明確にして、チームで共有し、役割を決めてレビューをやるのが良いです。
（講演内で回答）
ビジネス要求を理解していないのか、ビジネス要求を理解しているが要件定義でうまくレビューできないのか、どちらに該当するでしょうか？
おそらく、「ビジネス要求を理解していない」のパターンが多いと思います。なので、ビジネス要求を理解するために、お客様が何に困っているのかの情報を取得しようと奔走することが大事だと思います。
簡単な問題ではないと思います。いただいた情報からしか推測できませんが、まずは組織・チームとして”レビューの目的と効果”が何なのかを明確にすることが必要だと思います。どのような効果を得たのかがお互いに異なっているため発生している事象のように感じました。
今回の講演資料が一つの例になると思いますので、じっくり復習してみてください。
またJaSSTのレポートサイトから、「レビュー観点」などで検索してみてはいかがでしょうか。
今回の講演資料が一つの例になると思いますので、じっくり復習してみてください。
またJaSSTのレポートサイトから、「レビュー観点」などで検索してみてはいかがでしょうか。

今回の講演資料が一つの例になると思いますので、じっくり復習してみてください。
またJaSSTのレポートサイトから、「レビュー観点」などで検索してみてはいかがでしょうか。
経営層に「レビューの効果」を示すために、今まで実践した中で一番伝わった、納得感が レビューの効果を経営層に説明する機会は体験したことがありません。この事例がいただいた質問への回得られた指標はありますか？
答に相応しいかはわかりませんが、組織的な品質保証活動の効果を示す際に、導入前後の検出欠陥数や手戻り工数の変化を年単位で報告したことはあります。
今までで一番良かったレビュー（フィードバック）の体験はありますか？
作者に対して納得しやすい、受け取りやすいフィードバックをもらえることを重視する人や作者が気づいていない”より相応しい”技術的な代替案をもらえることを重視する人、その場で楽しく対話できることを重視する人など色々な方がいらっしゃいそうです。その意味で特定の個人的体験の提示は控えさせていただきます。
私は、レビュー対象に対する自分自身の好奇心や、疑問点を解決することに視点がずれ 好奇心があって疑問点を解消したいこと、質問攻め、そんなに悪くない、逆に良いことだと思います。
ることが度々あります。その結果、レビュー対象のドキュメント作成者やチームメンバーに 質問攻めで相手が本当に困っているのかは相手に聞いてみないとわかりません。単に時間がないのか、質問攻めしてしまいます。自分本位にずれてしまった視点を戻すために、レビュー目的に 痛いところを突かれているのかによっても、相手の対応、こちらの対応が変わってくるでしょうから、まずは集中するために、どのような行動、問いかけを自分に行なっていったら良いでしょうか。 話して聞いてみましょう。
また、好奇心や疑問点がないことについては、他の方が解決していてくれるのならベストですが、そうでないのなら、興味はあまりないけれども後で困りそうなので割り切ってお仕事するコーナーを意図的に設けましょう。
タイマーなどを活用して、時間軸で強制的に割り振るのも一つの手です。
一つの例として、同じロケーションに関係者がいて、比較的集合することが可能であれば同期的レビュー
同期的なレビュー(MTGを開いてその場でレビューする)方法と非同期的なレビュー(レを、関係者のロケーションがバラバラだったり、集合してレビューを行うのが（関係者のスケジュール調整ビュー対象物にコメントを入れて返す)方法の使い分け方があるのであれば知りたいでが）難しい場合は非同期的レビューを選択する、という考え方はあると思います。
す。
組織全員のレビュースキルをある一定レベルまであげるにはどうすれば良いでしょう
まずはレビュースキルを定義して（例えば４段階、4:名人（事業部や部門で一番） 3:リーダ一（チーム一番）か？
2:メンバー（一通りできる） 1:アシスタント）、誰が今どの段階でどこまで上げるとどんないいことがあるのかを検討し、期間を定めて目標設定されてはいかがでしょうか。必要となるスキル自体をいくつか設定（例えばセキュリティとか機能連携、〇〇業務など）してマトリクスにするのも手段として良いと思います。

2

JaSST_Review'23QA
26
272829機能仕様書に対してどのようにレビューを行えば良いでしょうか？

今回の講演資料が一つの例になると思いますので、じっくり復習してみてください。
またJaSSTのレポートサイトから、「レビュー観点」などで検索してみてはいかがでしょうか。
レビューで重視すべきはバグの発見でしょうか？それとも拡張性、可読性等のコーディン プロジェクトや状況によると思います。レビューによってそもそも何を達成したいのか、すなわち目的を定めグフォーマットのチェックでしょうか？
ることをおすすめします。
多重確認で指摘が漏れが増えるのは、認知バイアス（フリーライダー：ただのり）によるも 多重確認ソロ確認にかかわらず、指摘漏れが存在するのは、確認するポイントや視座が似ていたり、レのでしょうか。
ビューの目的や何を見つけたいのかが議論・合意されてないまま、レビュー実施しているからではないでしょうか。
ドキュメント(主に機能仕様書)のレビューを行い、指摘件数を記録しては振り返りを行っ 指摘件数に加えて、どのような指摘があり、それは本来どこで見つけられるべきで、指摘されなかったらどれくらいチームや顧客に影響するのか、そこをどう改善していくのかといった質も含めて経営陣に報告してていますが、経営陣にわかりやすい品質指標ってありますか？
みてはいかがでしょうか。

3