ブランチもどきの因果関係探索 ～Qくんを題材に～

きっかけ

子どもたちは、学校でQくんという登場人物が出てくる番組をみているらしい。

NHKで放送されている物らしい。

詳細は、こちらから。

www.nhk.or.jp

息子が、その日に見た番組の内容を覚えていて、夕飯時に話し始めてくれた。

そこで、夕飯時にブレスト、夕飯後にまとめをしてみた。

そのまとめの時に少し意識したのは、「ブランチ」といわれるツール。

ちゃんと学ぶ機会がなかったので、使い方とか間違っているかもしれません。

ご容赦ください。

ブランチの説明はこちらから。

わかりやすいブログでした。

wendosd.exblog.jp

問題について （Qくんの問題）

 Qくんは、宿題をやることが大嫌い。遊べないし、何かが目に入って、そっちのほうが楽しそうだと、今やっていたことを忘れてしまう。

宿題をやらずに遊ぶことに夢中になって時間が経過してしまう。

そこへ、お母さんが帰ってきて、お母さんは怒る・・・。

そんな、どこの家庭でもありそうなシチュエーション。いい題材です。

で、問題をちょっと見える化してみた。こんなイメージですかね。

Qくんがわの状況と、おかあさんのきもち（下写真の？の部分）が重なると、お母さんが怒るというイベントが起きると考えました。 

「？」にしたのは、この番組の中にはなかった要素だからです。

というのも、子供たちから、いろいろ話しているうちに、物事というのは関係者全員の状況が重なってできるから、一方だけを解決しても同じことが起きるリスクはあるよね、という流れになったからです。

Qくんはどうする？

 毎回同じことで失敗し続けるのはおかしいよね、と番組は続くそうです。

「じゃぁ、どうすればいいんだろう？」

それを番組を見た後に、子供たちは授業の中で考えていくそうです。

「気持ちを切り替える」という言葉を、息子はキーワードのように何回も語っていました。授業の中で、頻繁に出てきた言葉なのでしょう。

授業の中では、「気持ちを切り替える」ということを回答？として結論付けたようです。しかし、これだじけじゃ、子供たちはわからないよな、、、と思いました。

そこで、

「気持ちを切り替えるってどういうこと？」

「気持ちを切り替えるにはどうしたらいいのかな？」

と聞いてみました。

娘や息子から、原因を作らないようにしないと同じ事が続いてしまうというような回答がありました。それを、今回の事例にあてはめて具体的な内容を示したのが、

「おもちゃが目に付くからいけない」ということでした。

なので、「めのつくところにおもちゃをおかない」を入れてみました。

みんなで納得のいく内容を四角のなかに入れていくことが大事だね、と結論つけました。

  お母さんの気持ち

上で述べたように、授業の中では、お母さんの気持ちは出てきません。 

Qくんが集中できないだけでお母さんが怒るのかな？お母さんは何をかんがえているんだろう？と、自分たちの状況を振り返りながら考えていただきました（笑）。

まとめ

 学校で取り上げられている題材、教科書だけではやはり少し足りず、補助教材は必要だなと思いました。

道徳や生活、という科目を通じて論理や社会性、この世の無常（汗）などを学んでいく年代が低学年というのが非常にいいなぁと思います。

家庭でも、何かあるたびにこういうことを少しずつ考えていく習慣をつけることで、人の気持ちがわからないという特性をカバーしたり、言葉の意味を事象と結び付けて覚えていくということができたらいいなぁと思いました。

おまけ：学校現場でのTOCfEツール活用について少し考察

 先生方にちょっとインタビューしてみました。

TOCfEのツールとして学んだことはないそうですが、先生の年齢が若いほど、似たようなことを大学の教職課程で実践していたそうです。

理由は、近年の発達障害と判定される子どもの多さなどが起因して、促し方、解決の仕方などを教える標準的な方法を学ぶという流れが出来上がってきているからとのことでした。

ツールの名称が大事なわけではなく、こういったやり方が普及してくれるといいなぁと思うので、もっと先生たちにも広がっていくとよいなぁと思います。

 ブランチもどき振り返り

ブログを公開したあと、速攻で先生たちにアドバイスをいただくことができました！忘れないうちに追加。

TOCfEのロジックブランチで因果関係の原因を見逃さない（１つに決めつけない）話と、因果関係から離れて「そもそもどうしてそうすると良いんだっけ？」と考える話が混ざっているような。

— akiyama924🌱 (@akiyama924) 2018年3月11日

私は先ずは因果関係を（ロジックツリーで）分析して今発生している問題の原因を突き止めた後に、「そもそも、この問題だけ解決したら良いんだっけ？ 何が問題なんだっけ？」って順番で分けて考えています。慣れ？

— akiyama924🌱 (@akiyama924) 2018年3月11日

この例なら「お母さんに怒られる」もしくはその手前の「宿題をやらない」が今解決したい問題であって、それは因果関係を明らかにするためにMECEのロジックツリーやTOCfEのロジックブランチを描くことで原因を見逃さないことが大切です。
でもその後で「宿題って何のためにするんだっけ？」も考えたい。

— akiyama924🌱 (@akiyama924) 2018年3月11日

ブランチは先（結果）方向で「どうなる？」、前（原因）方向で「なぜならば？」で問いかけるだけのシンプルな進め方だけ意識しておけばよいと思いまーす。
バリエーションはそのうち身に付くはずっす。

— みずのり（みずののりゆき） (@NoriyukiMizuno) 2018年3月11日

慣れが一番の課題かもしれないです（笑）
順番、たしかにそうですね！
因果関係出しているときに、話が発散してしまうんです。。

とりあえず関係式を作ることに集中して、そのあとにどうすればよかったのかなーと振り返りを入れるのがいいのかもしれませんね！ありがとうございます❤

— あさこ (@acha_821) 2018年3月11日

おわり。

時間が大事な理由・次元を超えて

ちら裏・厨二病シリーズ第二弾。

思ったことをただ綴るだけの内容ですので、お暇な方はぜひお付き合いください＾＾

でも、最初に謝ります。

まとまりがありません。ごめんなさい！！

 いいたいこと

いつも、時間ってなんだろうって考えている。

時空って、重力ってなんだろう、って。

建物や様々な物体の曲率とか考えていても、「美しい」という感性を刺激されるのはやっぱり、3次元なんだよな、と。

二次元だと、個人的に「ものたりない」と感じる。

でも、これは自分自身に課している勝手な制約なのかもしれない。

時間を尺とするものに、価値を見出している。当たり前なことなんだけど、それは根拠を考えると実はものすごく壮大な流れでいうと、自然の摂理なんだろうな、と。

先を予測するなら、すごーくおおきな視野を持つと、もしかするとブレークスルーになるのかもと思う。

じゃぁ、制約の呪縛から出るにはどうしたらいいのかな・・・

と考えたときの思考の流れをブログにしてみた。

自由と制約

わたしたちの生きている世界

当然、地球です。

惑星のなかという限られた「空間」。

これは、もう3次元を超えることができません。

この中で、我々はもがき、よくありたいと願い、行動しています。

よって、行動の基本は空間にあり、制限を設けているし、制約があると思っている。

平等なのは時間

物理の時間に習った、3次元の次の軸は「時間」。

3次元で生きている以上、次の軸には行き来ができない。

よって、生きる上での制約でもあるけれども、過ごす長さは平等。

なので、なにか良い方向へ行くよう、試みを行うとすると、共通の尺は時間になる。

みんなで向かう先、それは「未来」「将来」。

現在のスナップショットではない。

次元のマジック

二次元と三次元

映画「ゼログラビティ」でも言及されていたけど、ワームホールの原理はすごく簡単。

二次元（紙）に線を描く。線の先端同志をくっつける（紙をおりたたみ、重ね合わせる）と、ワームホールの出口と入り口が一つになる。

これが、２⇒３のイメージ。

３⇒４のイメージも付くのかもしれない。

ときの旅人や、転校生なんかは、4次元世界からの旅人なのかもしれない。

体験するもの

 空間になにかの建造物なり、五感を刺激するもので我々は刺激される。

目に見える範囲のものを感じ取る。

当たり前ですね。

自分のいる次元より微分された面・線での表現に反応する。

美しいと感じるのは、こういう表現のものが対象になる。

望むもの

 自分の存在するスナップショットから積分されたところを表現されたものに反応することはあるのだろうか？

そこを見たい。感じたい。

まとめ 

制約を超えて

時間を尺とするものに、価値を見出す流れになっている。 

時間は平等だから、その平等なものに役割を設け、価値をつける。

時間より大きい次元は見えないけど、すごく簡単なところ・・身近なところに存在しているはず。すぐ隣に。

早く気が付きたいな、気が付かない大きな存在だけど、身近な隣人。

小並感満載なこんなエントリを読んでくださった方、ありがとうございます。

ゆーちゅーばーモデル（？）と、勉強し続ける理由

昨日の夜。

夕飯中に、子供たちと、ゆーちゅーばーの稼ぎの話をしていて、勉強し続ける理由に（いい方向に）オチがついたので、メモ書き。

チラ裏です。スミマセン。

別に、ゆーちゅーばーに限らず、ですが、子どもたちが、ゆーちゅーぶをよく見ているので取り上げています。

ゆーちゅーばーになるまで？

母「あなた達は、いつもゆーちゅーぶを見ているね。飽きないの？」

息子「だって、毎日違うものがあるんだもん！」

母「すごいね。。ゆーちゅーばーは本当にすごいね。毎日作るには、時間とお金がかかるね。おもちゃとかゲームとか毎日紹介するだけ買わないといけないし、ゲームもしなきゃいけないし」

娘「いくらもうけてんのかな」

母「ヒカキンは年間1億くらい、と聞いたことがあるけど」

息子「すげー！！」

ゆーちゅーばーになるための三大要素？

ここで、ゆーちゅーばーになって、多くの人から見てもらえるようになると、スポンサー契約があったり、そこで契約金などが入る話をする。

そして、流れは契約がない人の話に。

息子「けいやくしてないときはどうするの？」

娘「最初にいろいろ自分で買ったりしなきゃいけないから、大変そう。でも、そのおもちゃとかは売れるって自信があるからやるんだよねー。」

母「そうだね。自信と蓄え。あとは、紹介する能力かな。面白いと思う番組と、ちょっと残念な番組ってあるでしょ？」

二人「うん」

母「能力も、お金も、自信もはじめる前にある程度必要だね。そのために勉強するんだねえ。自分がやりたいことをやれる地面を作るために、やるんだねえ」

娘「学校行かなくなっても、勉強は終わらないね。新しいことをはじめるための自信をつけるために勉強するのかぁ。私も警官になるために勉強してるから、同じだあ。」

母「商品を紹介するには、大事なことが3つ必要なんだね。

自分で商品を買うお金、紹介して見てもらえるという自信、紹介して面白いと思ってもらえるための技・スキル。」

息子「ドラクエと同じ！」

まとめ

業務外の勉強やら、お金がどうのこうのと色々考えた時期があったけど、結局はこのゆーちゅーばーもでるが、基本形なんじゃないかと思った。

• 自分で商品を買うお金…義務教育などで得る知識、基本セット
• 紹介して見てもらえるという自信…自己肯定感などの自己スキル、対人スキル、コミュニケーション
• 紹介して面白いと思ってもらえるための技・スキル…継続的インテグレーション

子供との会話はいつも発見が多い。

自分の考えがまとまるからかなあ。

通勤電車内で10分でかきあげた10分チラ裏劇場でした。

ここまで読んでお付き合いくださった方、ありがとうございましたm(_ _)m

オオカミ少年 ベイズ更新（理論の手書き）

年末にちょっと触れたオオカミ少年の考え方にちょっとふれてみた。

okandayo.hatenablog.com

シミュレーションすると、わかりやすい。

でも、全部手書きｗ

 

便図をつかって表現

ベイズの定理をつかってみる

シミュレーションするとこうなる

次回は本当にscarabつかってやってみようかな。

ベイズ統計、小並感導入編

このエントリは、以下の本を参考に書きました。

「岩波データサイエンス vol1」

https://www.amazon.co.jp/岩波データサイエンス-Vol-1-岩波データサイエンス刊行委員会/dp/4000298518

わかりやすくて、薄くて内容の濃いとてもいい本です♪

今回は、数式は書かずに導入だけ触れることにします。

自分の頭の整理のために・・・。

ベイズ統計とほかの統計の大きな違い

簡単に言うと、下のようなイメージになる。

• ベイズ統計・・・・仮定が多い
• 普通の統計学・・・頻度主義の統計学

ベイズ統計は、データだけではなくてデータの背後にある要素も確率的に生成されると仮定する。

オオカミ少年

ベイズ統計を理解するのによく使われる例は、

「オオカミ少年」の事例でしょうか。

• 少年が嘘つきである
• 少年が正直者である

上記を「仮定」の条件にして、次に起こりうることを推定する。

嘘つきならば、次に本当のことを言う確率や、うそをつく確率などを用いて求める。

これを考えると、「人狼」というゲームがありますが、データを取得していけば、予測できそうですね～。

結局、一般化すると、

「母数の事前分布」＋「検査データ」　⇒　「母数の事後分布」

ということになります。

予告

2018/2/17に、川崎でベイズ統計の勉強会をひらこうかなと思っております。

ご興味のある方は、connpass立てますので、ぜひご検討くださいませ♪

では、よいお年を～。

2017 振り返り（NaITE＆ちょっと個人）

もう２０１７年もあと1日と半分。

はやいなぁ、と・・・。

NaITEのスタッフになってから2年がたとうとしています。はやいなぁ。

ということで、個人的に振り返ります！

年間振り返り

今年は、勉強会を7回も開いていました。２か月に1回のペースで企画していたのですが、なんだかんだで7回。スタッフも頑張っています！

NaITEは、AgileJapan長崎サテライトや、秋～冬にかけて長崎QDGという大きなイベントも開催しています。

主査の池田さんをはじめ、スタッフのしょーごさん、くまきちさん、つのだくん、ふじさわくん、まつやまくん、てしまくん、うじたくんと皆でがんばっています。

みんな、それぞれの想いを持って活動をしています。

仲もよいけど、礼節もきちんとしている。そんな仲間と出会えてよかったです。

個人的にも、数学勉強会を開いていくことにしました。

ただ数式を追いかけるだけだとただの苦行にしかならない。どうすれば数学を楽しめるかな？これは何に使われているんだろう？どうつながっているんだろう？

そんな目線から、いろいろとご紹介していけるといいなぁとおもっています。

一緒に勉強したい方、声をかけてくださいね！

 2017年1月

2017/1/21　NaITE#19 「数学を学ぼう ～数学の知識を利用したソフトウェアテスト～」勉強会

  数学のパート。ただ、数式を展開するだけの勉強会ではなく、何に使うのか、どういう場面で何（数式・考え方）が使えるのか、というアプローチでの勉強会を開催しました。

naite.swquality.jp

2017年2月

JaSST TOKYO　2017　で、コミュニティブースをだしました！

こういう試み初めてでした。NaITEを多くの人に知ってもらえる機会を得ることができて、本当に感謝です。

JaSSTソフトウェアテストシンポジウム-JaSST'17 Tokyo

ちなみに、ここで事例発表を行いました！（自社の事例発表です）

「品質予測モデルの構築およびプロジェクト管理への適用事例」

2017年4月

2017年4月8日　NaITE#20「プロセスモデル CMMI にまつわるちょっと深イイ話」　勉強会

CMMIというプロセス参照モデルのご紹介をしました。

プロセス参照モデルを使うには、道具（CMMI）を知っている必要があり、詳細を中村こーじくんが紹介してくれました。そして、そのプロセス参照モデルを組織でちゃんとまわしていくためにはどうするか？という視点でのご紹介もさせていただいております。

naite.swquality.jp

2017年4月22日　NaITE#21「PSP概説&体験ワーク（おかわり）」　勉強会

メトリクスのすべての親となるフレームワーク、PSP。

これをしっているかしらないか、で、業務の改善度は格段に違うと思います。

その内容のご紹介を、くまきちさんがしてくれています。

naite.swquality.jp

2017年5月

2017年5月20日 　NaITE#22「はじめてのバグ票システム～導入実践ガイド」　勉強会

ソフトウエア開発にかかわる人は、バグとはきっても切り離せない。そんな情報を取り扱うためには、何が大切なの？バグ票ってなんのためにあるの？といったところからも、バグ票システム導入実践ガイドご紹介しています。

この回には、細川さんが来てくださいました！

医療とソフトの近さを感じるご講演をいただきました。

naite.swquality.jp

2017年7月

2017年7月16日　NaITE#23　「Scrum入門＆Agile Japan 2017 長崎サテライト参加報告」　勉強会

アジャイルしばりの勉強会。AgileJapanの参加報告と、Scrumとは？について、きんじさんにご紹介いただきました！

naite.swquality.jp

2017年9月

2017年9月17日　NaITE#24 「テストカタマリー　ワークショップ＆解説」 勉強会

テストカタマリーのワークショップを、みずのりさん、くっきーさんに開催していただきました。

テスト設計時にモデリングをして、テストをする人・開発をする人・顧客の視点などからの気がかりなところもそのモデルに関連付けておけば、なんでそのテストをしたの？というところの根拠にもなるなぁと個人的には思っております。

naite.swquality.jp

2017年11月

2017年11月11日　NaITE#25「欠陥モデリングワークショップ＆解説」　勉強会

森りゅうじさんに、欠陥モデリングのワークショップをしていただきました。

5月に開催いたバグ票とあわせて、バグの内容をモデリングして抽象化すると組織の資産としてかなり有用性の高いものになるので、両方をしっておくとすごくいいなぁと思います。

naite.swquality.jp

来年に向けて

来年は　1/20にNaITE#26、2/2に長崎QDGを開催予定しています。

ぜひぜひご参加下さい！

来年もどうぞよろしくお願いいたします。

ワークプロダクトレビューの技術とプロセス ～レビュー技術・事例と標準化最新動向の紹介～

2ヶ月ほどまえに参加したセミナーについて、ブログってみました。

有料だったのでどうかなと思ったのですが、にしさんから許可（？）もらったので、掲載しちゃいます。

www.ipsj.or.jp

所感 

非常に費用対効果が高いセミナーでした。こんなセミナー、もうないんじゃないかなぁと思うほどの満足度の高さです。ありがとうございました。

森崎さんの講演で、「チェックリストは「やり方が」書かれていない。どうやってそれを確認するのか？が書かれていない。」というお話がありました。

社内でも、「ツール」を使った、そのツールが＊＊です、という報告はあるが「どう使われたのか、使った目的は何か」というところに触れられていないことがあるのとリンクするなぁと思いました。手段・方法は、プロセス・目的と一緒にセットで情報を持っていないと意味がない。そう思いました。

細谷さんの講演では、グランドルールありき、チームビルディングありきの改善かもしれない、とおしゃっられていたことが印象的でした。

個人ではなくチームでルールを作り、自分たちで決めたことは守る、ということを厳しく貫いているところがおおきな成功要因なんだなぁ、と思います。

パネルディスカッションを見ることが一番の目的でした。ここだけで、もう本1冊分の価値があったのではないかなぁと思うような内容でした。「レビュー」と「テスト」って、似て非なるもの。そこを痛感するパネルでした。

開催概要

• タイトル：ワークプロダクトレビューの技術とプロセス　~レビュー技術・事例と標準化最新動向の紹介~
• 日時: 2017年 10月18日(水) 13:15～18:00
• 会場: 機械振興会館 地下3階 研修1号室
• 概要：

ソフトウェアの品質向上のため、要件定義書や設計書などワークプロダクトのレビューは重要です。2017年2月にISO/IEC 20246:2017 (ワークプロダクトレビュー)がレビュー技術やプロセスを定義する国際標準として発行されました。
　本セミナーでは、このISO/IEC 20246:2017発行を機会に、レビュー技術や事例、また標準化最新動向を紹介・解説します。まず、レビューの技術やプロセスについて一般的なものから最新情報など、また、産業界での適用事例を紹介します。さらに、ISO/IEC 20246:2017の解説を行います。最後に、パネルディスカッションを行い、レビュー技術の事例や国際標準の意見交換を行います。

●ソフトウェアプロダクトレビューの基礎と研究動向（森崎さん（名古屋大学））

ソフトウェアプロダクトレビューは実行可能なプログラムが存在しない時点でも実施できる欠陥検出技法です。本講演では、ソフトウェアプロダクトレビューの基礎と研究動向を紹介します。ソフトウェアプロダクトレビューの基礎として、目的、参加者の役割、欠陥の検出例を示し、ソフトウェアプロダクトレビューの原理を理解いただきます。次に、検出した欠陥を早期に修正することによって得られる欠陥の修正コストや欠陥の見逃しリスクの低減といった効果を解説します。最後に、これまで研究分野で議論されてきたソフトウェアプロダクトレビューの技法や技術を紹介した上で、近年注目を浴びているModern Code ReviewやArchitecture Tradeoff Analysis Methodを紹介します。

• レビューは、ソースコードがない状態でも欠陥を検出できる。
• だれがやっても同じようにできる必要がある。レビューは準備が大事。
• レビューは、「どのような条件がそろうと、達成されるとやった意味がある、と思われるか」を考えよう。
• テストの場合は、あまり属人性があると聞いたことがないけど、レビューは人のスキルに依存することが非常に多い。
• レビューで、特殊なタイミングや競合、バッファオーバフローやセキュリティなどはレビュー時点で検出したほうが良い。⇒　病気と一緒
• チェックリストは「やり方が」書かれていない。どうやってそれを確認するのか？が書かれていない。
• モダンコードレビューというものがグーグルで行われている。
• 目的は協調であり、欠陥検出ではない。ペアプログラミングの代替手段となっている。

●狙いの明確化によるレビュー改善事例（細谷さん（三菱電機（株）））

ソフトウェア開発において、ドキュメントやコードのレビューは、品質向上のために重要な活動ですが、開発現場では、レビューに投入したコストに見合った効果が得られている実感がないという課題がありました。そこで、レビューで検出したい欠陥を明確化し狙いに合わせたレビューの実施時期、実施方法を定めることにより、開発現場が効果を実感できるレビューに改善しました。本セッションでは、レビュー観点の分類、レビュー技法の使い分け、実施シナリオなど改善活動の中で定めた実施方法について紹介します。

•  産学連携して行ったカイゼンで、Melcoグループ内のガイドラインとして作成した内容を紹介。
• レビュー技法は使い分ける。
• 序盤は、例えば運用シナリオ、ユースケースなど、多く記述しそうなものであれば、最初でやり方・書き方の合意をレビュー内で行う。
• 残りのものに水平展開する。後半は工数を削減することができる。
• 中盤は、重要と思われる機能の部分など、ピンポイントで見るべきものに絞ってレビューを行っていく。
• レビュー観点とレビューの仕方を関連付ける。
• 4象限で観点を明確化することは効果がある。
• プロジェクト内で合意を得ながら実施する。
• ナレッジメンバーを任命。ナレッジメンバー＝レビューの有識者。
• 有識者だからといって、レビューができるとは限らないので教育をする。教育の中には、演習も入っている。
• いくつかシナリオを用意して、人格攻撃をしない、とかディスカッションを交えた教育を行っている。
• グランドルールありきの改善かもしれない。チームビルディングありき。

●パネルディスカッション「レビュー技術の研究と活用」

パネラー：森崎さん（森）/増田さん（増）/細谷さん（細）/西さん（西）

１．V&V　V字の左側でもやるべきだということが言われているが、妥当性確認について　どう考えているのか？レビューで妥当性確認ができるか？どうやればいいのか？

• 森：最後に言われても困るので、途中でいうことに意味がある。スクリプトテスト・探索的テストに代わるものがレビューにもあると思っている。終盤にいわれても直せない、ということになってしまう。どのタイミングでどういう指摘を行っていくか、をレビュー計画で合意することは大事。 ⇒細谷さんの事例に重なる
• 細：事前にレビューしてほしい観点を渡してレビューしてもらったりした。
• 増：ただしくつくったか？つくったものはただしかったか？を確認するのがV&V。正しく作っているか？というところにたいして、定義しているのが20246である。つくったものはただしいか？という観点でのチェックまでは言及していない。
• 西：V&Vは時代遅れ。妥当性確認としてどういう観点で確認したらいいかを分解しておいて、テストでは何を確認すればいいのか、を合意していくべきである。

２．オフショア・ニアショア　品質確保（検証）の良いやり方を教えてほしい。

•  森：共同研究内容。発注工程の前工程でのQ&A（＝ドメイン知識）の内容に着目する。前提知識が同じになっているかどうかでわかってくる。受注側からの質問の質で受注側のスキルを測るとよい。実績も大事。技術力がない受注側をレビューで何とかするのはむり。発注先を変える勇気も必要。ドメイン知識と技術両方ないとうまくいかない。オープンクエスチョンで聞いてくる人は、ちょっと危ない。YES/NOで聞いてくるところは安心できるかも。
• 細：契約の序盤でレビューしたりする仕組みを入れないと難しいと思う。そういうことを盛り込めるような契約にしていくべきだと思う。ワークショップ的なものを一緒にやる。ユースケース的なものを一緒に作ったりして、やり方を教えたりしている。内部品質に着目するのであれば、機能設計を一緒にやるとかを考えないといけない。
• 増：レビューのトレーニングとしてレビューを捉えることも大事。有効な手段。ツールで効率化するなども、選択肢の一つである。国際標準規格は、受注側の技術力が低い場合にも、「こうやるとうまくいくよね」というものを想定して作られている。重量級の国際標準は発注側の視点で考え方や技術などが細々と書かれているので有用である。

３．再現性・・・属人性排除、次回も同じようにできる、などについて

•  増：できる。そのために規格を作成している。再現性があるのか、品質があがるのか、という条件に関しては、組織それぞれでの前提条件などがあるとおもうので、それを文書化していくとよい。
• 細：属人性の排除。レビューの仕方はやり方があるので、できる。役割の設定、レビュー技法も取り入れられるはず。その人たちの能力の範囲でできると思う。能力の質の属人性は別の話。組織としてのいいところは狙えるけど、ひとのスキルに依存するばらつきは排除できないと思う。「組織のスキルの限度において」よい仕事ができる。
• 森：着眼点が一緒、属人性の排除。前提条件の抜けが認識できていなければ無理。　結果を予測できるようなものになるというのも、属人性の排除には重要。技術力が低いのであれば、「ないものねだりをしない」のが大事。 

文化、マインド・・・の話：

• 森：素質、再現性、プロセスを定義する、マインドの話・スキルの話。マインドがあるけどスキルがないからうまくいかない、スキルがあるけどマインドが低いからうまくいかない・・四象限的。
• 細：細かく繰り返すというのに重要視している。どこを目的としていて、どう改善していくか、が大事と思っている。　　
• 増：F2Fでやったほうが効率が高いと聞いて、実行している。すべてがトップダウンで行っているわけではなく、プロジェクトのアウトプットが高まる行為であればOK。ツールであろうが、マインドにかかわる話であろうが、上記の効果が期待できるものであれば実施する。

４．レビュー文化：個人主義の国（欧米とか）・組織・エンジニアは、レビューのような皆のための仕事はしないので、枠や型が必要なのではないか？

•  森：レビューを手伝った人は人事評価をよくするなどの仕組み的対処が必要。レビューで後ろから打たれるような状況を作ってはいけない。
• 増：自分が書いた試験に自分で回答して自分で丸付けして100点というのは本当かどうかわからないから、確認が必要。欧米ではテスト専門の職業などがあるけど、日本ではなかなか受け入れられない。　　　
• 西：組織の方針と仕組みは国とか個人の考えをオーバーライドするので、そういうマネジメントをしてしまっているだけなので、マネジメントの怠慢だと思います。

　　　⇒森：レビューは社風が出る。けん制しあって向上するという文化とか。文化が異なる同士のレビューはそれぞれ違和感を感じるだろう。

５．改善内容の適用スコープは、全プロジェクトに共通というわけではないとは思う。レビューの目的やプロダクトの特性などによって改善内容を変えるべきか？レビュー設計はしているのか？

•  細：変えているが、全プロジェクトに適用しているものもある。（インスペクションに有識者を入れるというのは100％）。レビュー設計としては、目的・観点を決めるなどのレビュー計画は行っている。
• 森：細かいレビュー設計は、細かくすればするほど形骸化しやすい。コストが下がらなくなる。
• 増：チェックリストはどうやってつくるの？⇒過去の障害を一般化する一般化抽象化して、全プロジェクトに適用、とか。

６．国際規格などを隠れ蓑にして形式的に仕事に文句をいうひとにはどう対応すべきか

• 細：内部品質に対する意識を組織的に共通にしていくとかに使う。レビューのタイプで使い分けましょう。
• 森：バディチェックで回避できる。
• 増：標準は厳密に従うものではない。良いところどりをすればよい。特に20246は意識を高めてやっていこうというもの。

７．この30年間でレビューは何が変わったのか？一言で。

• 増：ほとんど変わっていない。ソフトウエアの複雑度・テクノロジーが高度になっているので、相対的には変わっていない。
• 細：若い人に「変わっていない」ということが伝わっていない。若い人は、「はじめてききました」という。それを伝えていく手段として、標準化された規格は使えると思う。
• 森：本質は変わっていないが、対象範囲が広くなり、考え方もいろいろ出てきている。反復型の開発が一般敵になってくると、レビューの役割も変わるだろう。未熟な自分を理解していこう。
• 西：テストも同じ状況だった。この先、おカネや技術が流入してきたら、変わると思う。

 以上！