今週、弥生会計などで知られる弥生さんで行われたもくテク（勉強会）に参加してきました。
今回のテーマは「ふりかえり」で、弥生さんでもご紹介くださった misono さんでもうまくやれているようでうらやましい限りですね。
ふりかえりの問題は、今年のソフトウェア品質シンポジウムで発表されたテーマの中にもありました。
振り返りを力強く推進する「 FOPA 振り返りプロセス Ver.2 」の提案
- 効率的で納得感の高い振り返り分析と、 TRY 実行支援活動の具体化 -
田中 桂三 氏 オムロン株式会社
https://www.juse.jp/sqip/symposium/detail/day2/#A3-2
発表の原点としての問題となるところは、ふりかえりで決定した改善策が実施されないという悩みでした。
一方、今回一緒に参加された方の中で筆者の隣に座られた方の悩みは、ふりかえりが一部の人の発言の場になってしまっているという悩みでした。
ここから先は個人的な想像を交えた見解ですので、異論があって当然とは思うのですが、言った人が「自分のやる事が増えて損」とか、何か改善することは「自分が失敗したことになる」などの考えがそこにあるのではないかと勝手に推察したのですが、あっているかどうかは神ならぬ身の上では、分かる事はありません。
ふりかえりをどう扱うかではありますが、組織やチームの最適化の側面を少し抑えて、ふりかえりの恩恵を少し個人に振り分けるような方策を考えてもいいのではないかと、元「プロセス改善屋さん」は思ったのでした。
例えばですが、ふりかえりの位置づけを「自分がもっといい仕事するために、周囲に協力をお願いして良い場」という定義を持ち込んでみるとかしてみても面白いかもしれません。
＃提案に対して、自分のできる範囲での協力は何か、それぞれが考えて返答するみたいな・・・。
組織にも個人にもメリットがあるものにしていければ、継続性と活性化が見込めるかもしれません。
まあ、これは思いつきのレベルなので、もう少し工夫して実践出来ればアイデアとしては良さそうな気がします。
終わってから、こんなことを考えながら家路を辿った筆者でした。
さて、もくテクのネタがどうこう、言われていた気がします。
やるためにやるものではないので、基本的には弥生さんが知りたい事ベースで良いとは思います。
それでもあえて書くとすれば、ソフトウェアの品質に関するところでは少し絞り目にすればそこそこ出そうですが・・・
今までの内容を把握していないので被っているかもしれませんが・・・
ソフトウェアの要求をどう捌くとか
リスク分析とその結果の活用とか
テスト設計とリスク分析結果の関係とか
テストの優先度とリスクとか重要度の関係とか
テスト後のリテスト範囲の決定方法とか（影響度判定）
テスト時の不具合管理とか
不具合分析と開発への FB とか
クレーム分析と開発への FB とか
品質目標の設定方法と品質の計測手段とか
今思いつくのはこんなでしょうか。
全部が知りたいということでもないですが・・・。
今年は 2 回お世話になったので、思いつくままに書いて見ました。
＃見てもらえるかも、わかりませんが・・・。それもひっくるめて縁というものでしょうか。
―――――
おまけ
不思議な感じですがメンタルが弱いという話が、勉強会の中でよく聞かれました。
自分でそれを言える人は、言うほど弱くないと個人的には思います。
失敗してもいい場所でなければ、楽しむのは難しいので、成功を目指すのはいいのですが、みんなで失敗を許容することを前提にして集まるのがいいと感じています。
善意で解釈する、好意的に解釈するという（この場だけの）グランドルールがあってもいいとなんとなく思ったことも付記しておきます。
