ソフトウェア・シンポジウム2016 in 米子

ソフトウェア開発現場での Minute Paper の適用
岡本 克也
有限会社エヌ・エム・エス
okamoto@nms.ne.jp

中谷 多哉子放送大学
tinakatani@ouj.ac.jp

関係者はゴールとなる完成像について同じイメージを共有したい，あるいは違うなら違うで合意形成を計りたいのだが，1.の自覚がないと勘違いは最終的な製品の段階まで持ち込まれることになる．
2.の場合，参加者に関心の濃淡があるのはやむを得ないことであるが，極端に参加意識が低いと発言そのものがされないことがあり，他の参加者も感心の薄いクライアントを薄いまま放置しがちになる．
しかし，クライアントは自身の欲求を持っており，この欲求はリリース直前，あるいはリリース後に表面化する．

要旨
要求工程での打ち合わせにおいてコミュニュケーシ
ョン不良とクライアントの参加意識の低さがしばしば見られる．これらを早めに検出して関係者の参加意識を高め，ベンダーとクライアントが製品に対して同じイメージを共有することが望ましい．その為にアクティブ・ラーニング手法のひとつである Minute Paper をソフトウェア開発に適用し，その結果を横断的に分析することでコミュニケーションの不良を軽減し，参加意識を高めることでその有用性を確認した．

1.

打ち合わせの現場では，関係者全員が揃う会議が持たれる回数は限られており，特に小規模な事案ではクライアント側の担当者が指定されるものの，担当者はいままで通りの業務を抱えており「ベンダー側の仕事」である開発に時間を割きたがらない傾向もある．そのた
め空き時間にベンダーがお話を伺うべく「個別に」インタビューを面接，電話，メールなどで行うことになり，するとクライアントの横方向のすり合わせがどのように行われているか把握しづらく，さらに，個人的な関係の上で情報がやりとりされがちな傾向が生まれる．
それが会議室であれ，一対一のインタビューであれ，コミュニケーション不良と参加意識の低下は起こっている．目の前で話をして出た「それでいいですよ」という言
葉がよく考えた結果なのか，インタビューを切り上げて自分の仕事にあるいは別の話に戻りたいということなのか明確にならないことも事例からは散見された．

序論

筆者は過去に経験した複数の小規模な開発現場で発生した関係者の満足度低下につながる問題の原因について分析を行ったところ，多くの事例で
1.

コミュニケーション不良によってお互いの考えていることが一致しない

2.

クライアントの参加意識が必ずしも高くない

黒須 正明
放送大学
kurosu@ouj.ac.jpという事象が見いだされた．
ここで参加意識を定義する．この参加とは開発工程の全体において製品の開発に関わる他者の考えや行動に変化を与えようとすることである．参加意識とは参加を意図して個人の内で行われる考察や試みである．通常，発言や行動の内容・頻度として発露される．
参加意識が低いとは参加の意図に乏しく開発に対する理解や探索のための考察や試みに費やす時間が少なく，発言や行動に現れない状態を指す．参加意識が高いとはその逆で参加の意図を持ち考察や試みに時間を充て，発言や行動として外部に現れる状態である．

しかし，ここがクライアントの要求を聞き，ベンダーが説明をし，お互いが何を理解しているのか確認する，極端に言えばすべてが行われる“現場”に他ならない．
「打ち合わせ」はベンダーとクライアントの唯一の接点である．
その重要性を考えれば「打ち合わせをデザインする」ことでその価値を高めることが必要となる．

107SEA

ソフトウェア・シンポジウム2016 in 米子

2.

最少人数は２人，時間的にさほど長くならず，事前準備も簡単である．
ジグソー法は，理解したい課題をまず分割し参加者を課題数のグループ（エキスパートグループ）に分ける．エ
キスパートグループは課題について調査し理解を深める．次に，参加者をシャッフルしそれぞれのエキスパートを含む新グループ（ジグソーグループ）を作成し，エキスパートは自分が調査した分割課題について説明を行い，また他の分割課題についての説明を聞いて情報を共有する．最後に元のグループに戻って全体課題についての共有を行う．この方法の特徴はジグソーグループを作成した際に「自分しか知らない」状態が強制的に作り出され，それをグループで共有することがデザインされている点である．「調査」した結果を効果的に共有できるが，ある程度の人数と時間が必要となる．
ポスター法は上記のジグソー法をポスター発表に応用したものである．ポスター制作をエキスパートグルー
プが行った後，ジグソーグループを作成して各ポスターを巡回して討論する．全員にプレゼンテーションの機会があり「ただ乗り」を許さないが，この手法は人数，時間，準備，道具が必要となる．
ピア・インストラクション法は知識獲得型にメリットのある技法で，予習教材を提示した後 Concept Test と呼ばれる多肢選択問題を用意し参加者に実施する．回答率を高中低に分け，高い場合は次の Concept Test へ，中ぐらいの場合はペア・小グループで議論を行い互いに教えあう．低い場合は教師が再度説明を行う．事前に全員に周知しておいて欲しい知識があるときに適しているが質の高い Concept Test を準備するには労力が必要となる．

方法

筆者は MOOC( Massive Open Online Course )サイト
である gacco の「インタラクティブ・ティーチング[1]」(主任講師：栗田 佳代子 東京大学大学総合教育研究センター教育課程・方法開発部門特任准教授 ならびに
中原 淳 東京大学大学総合教育研究センター教育課
程・方法開発部門准教授 )を受講した際にアクティブ・ラーニング手法について，ソフトウェア開発への応用が可能でないかと考えた．
教育分野で近年導入されはじめたアクティブ・ラーニ
ングとは「能動的な学習」の総称である．
教師が一方的にしゃべり，学生が静かに話を聞いてノートを取る．という受動的な学習では課題に対する理解や考察を深めるという目的に効果的ではない．また，学生には授業に対する関心に濃淡があり，特に関心の薄い学生を取り残すことはその学生に対する理解を放棄することにつながる．
アクティブ・ラーニングは学生を積極的に参加させるべくデザインされた授業の技法を含む．
ここで筆者はひとつの見立てを行い，学習を要求獲得のための打ち合わせ，課題をベンダーとクライアントが共有したい要求の形と置き換えてみた．
ベンダー側が単に質問をし，クライアントがそれに答えるという形式では望ましい成果はなかなか得られない．
要求獲得段階でベンダーもクライアントも何を作り上げようとしているのか理解すること・探索することを重視すべきである．とはいえ，クライアントにお願いして開発に参加してもらう場合，時間的制約は常に問題となることもあり，ソフトウェアに対する理解や考察を効率的に深めるために良くデザインされた打ち合わせ技法へのヒントをアクティブ・ラーニングから得られないか，主要な技法からソフトウェア要求獲得への応用の可能性を考えた．

今回，中小企業の伝票管理業務の案件に，アクティブ・ラーニング手法から Minute Paper の技法を適用することを試みた．
この手法を選定した理由は，ひとつには参加者に対する時間的な負担が少ないことが挙げられる．序論に述べたように小規模な開発の場合，関係者が揃った開発会議というのは数回行えれば良い方で，多くの場合，業務を行っているユーザー側の時間の隙間を借りるという形で開発者側が打ち合わせに訪問したりすることになる．
このような状況では参加者の時間的な負担を小さくすることは重要な要素になる．今回は記入時間として５分＋程度を想定した．

教育現場で用いられるアクティブ・ラーニング手法のいくつかをここで紹介したい．
Minute Paper は授業中に配布するペーパーに授業への興味，関心，疑問，自分の理解度などを数分で書いて提出してもらう技法である．事前に用意した質問紙を用いるので実施にかかる時間も少なく，記入する側の負担も小さい．授業規模の大小にも柔軟に対応できる．
これは学生側にとっては授業に求めるもの，疑問の行き先，困難を抱えているかを教師側に伝える方法であり，教師側にとっては授業が意図したように進んでいるかを確認し，今後の授業の進行変更を考える際の資料となる．
Think-Pair-Share は，明確な課題を設定し，「一人で考える」「ペアになる」「考えたことを共有・議論・意見交換する」という順序で行われる「意見交換の前に考える時間を確保する」という 議論への主体的参加を促す構造を持つ技法である．

本来であれば議事録を明確にしておくべきであり，それによってトラブルのいくつかは解消されると考えられるが，アクティブ・ラーニングの技法に接して”能動的”にインタラクション（教育現場では授業であり，開発現場では打ち合わせである）をデザインするという視点に気づかされた．この点で従来の議事録とは異なるコミュニケーション改良への効果が期待された．
よってふたつ目の(重要な)理由として打ち合わせ後

108

SEA

ソフトウェア・シンポジウム2016 in 米子に”振り返る”ことによって，なにを目的にした打ち合わせだったのか，ちゃんと意見交換は出来たのか，取りこぼしはないか等を考える時間を参加者に持ってもらうようにデザインしたことが挙げられる．この考える時間は重要であり，打ち合わせが終わったら速やかに関心が消えてしまうことを防止する効果が期待できる．
また，Minute Paper を書くことそれ自体が，開発に対する参加意識の向上に役立つことを期待して本研究ではこの手法を使用することにした．

3.

Minute Paper 配布の２日後，次のような回答を得た．

1.本日の打ち合わせで最も重要だと感じた
こと，印象に残ったことは何ですか？
[クライアントの回答]
必要な時に必要なデータが即時閲覧できる，使いやすいソフトの開発をお願いします．
[ベンダーの回答]
良いものを早くできるように求めてると感じた

今回，この手法を伝票管理アプリの開発の要求獲得段階で適用した．既存の伝票管理アプリのリプレース案件でありソフトウェアの規模も小さい．
また，利用者は経理担当者一人であり開発者も筆者一人という最小限の環境となっている．

2. 言いたいと思ったことはいえましたか？
言いそびれたことがあればお書きください．
[クライアントの回答]
今のところありません，入力ができるようになれば色々と出てくると思いますので[ベンダーの回答]なし

これらことを考慮した上で，次のような項目を設定した．
（付録参照）
1.

結果

本日の打ち合わせで最も重要だと感じたこと，印象に残ったことは何ですか？

2.

3. 相手の話は理解できましたか？ 分からなかったことがあればお書きください．
[クライアントの回答]
大変良く理解できました，分からない所はありませんでした．
[ベンダーの回答]
伝票の税込みの解釈で少し相違があるようだった．わかってくれたようだが，最初どう思っていたのかもう少し確認すべきかも言いたいと思ったことはいえましたか？言いそびれたことがあればお書きください．

3.

相手の話は理解できましたか？ 分からなかったことがあればお書きください．

4.

相手はあなたの話を十分理解してくれたと思い

4. 相手はあなたの話を十分理解してくれたと思いますか，まだ理解が不十分かもしれないと思われるところはありませんでしたか？
[クライアントの回答]
十分理解してくれたと思います．
[ベンダーの回答]
理解してくれたと思う．

ますか，まだ理解が不十分かもしれないと思われるところはありませんでしたか？

5.

次回の打ち合わせで改善して欲しい点，期待することはありますか？

6.

5. 次回の打ち合わせで改善して欲しい
点，期待することはありますか？
[クライアントの回答]
今回の打ち合わせで，ほとんどご理解頂けたと思いますので，次回は是非画面イメージ等を見せて頂き動作検証ができるところまで行けばありがたいです，よろしくお願いいた
します．
[ベンダーの回答]
なし

打ち合わせ後に思いついたアイデアなどがあればお書きください．(文または絵)この Minute Paper を打ち合わせ当日の終業前か，翌日に記入してもらうように依頼する．
配布対象はクライアント・ベンダー双方の関係者全員である
回収後，一回の打ち合わせに対して，あるいは同時期の参加者全員分（今回の例は２名）を横に並べて検討する．スプレッドシートなどにまとめても良い．

6. 打ち合わせ後に思いついたアイデアなどがあればお書きください．(文または絵)

109

SEA

ソフトウェア・シンポジウム2016 in 米子

打ち合わせが終わって帰路，あるいは自分のデスクに戻ってから「あ，いま思いついたけど…」と言うのはよくあることなので必要であれば用紙の裏面を使って文章や絵で自由に書ける箇所とした．
このケースでは打ち合わせで出てこなかったクライア
ント側の要望をひとつ，拾い上げることができた．

[クライアントの回答](１１月‐翌年１０末)等，期間を決めて未回収リスト等を作成できるようにして頂けると有難いです．
思い付いた事が出てきましたらご連絡致しますのでよろしくお願いいたします．
[ベンダーの回答]
なし

4-2. 実施に際して4.

その後，複数回（この事例の他を含む）Minute Paper を配布，回収して気づいたことを述べる．
第一に回収されることが最重要の目標となる．回収されなかったということ自体もひとつの情報ではあるが（後日，その理由を確認する），忙しい，あるいは関心が薄く遂に回収がされないことが時々発生する．”特になければ「なし」で構わない”等と説明し，できるだけ回収に協力してもらえるように手を尽くす．解答方法は書面でもメールでも FAX でも…と柔軟に対処する．
非常に大事なこととして，当日の終業前か翌日中に記入してもらうように念を押しておくことである．２日より多くの日数が経過すると回収率ががくんと下がることが実施した事例から散見された．また，日数が経過すると打ち合わせ時に浮かんだ疑問や思いは簡単に霧消してしまうようで，その点からも早めの記入を求めるべきである．

考察

4-1. 回答から得られたものを分析する
1. によると，クライアント・ベンダーはそれぞれ違うことを印象的に考えている．
クライアントにとっては打ち合わせでは，使いやすく，目的とする情報にすぐにたどりつけるソフトウェアについて要望したと認識している．
一方，ベンダーは Minute Paper に関して尋ねたときの「早くできるなら」という部分に反応している，何かするのであれば良い品質につながるのと同じくらい，仕上がりの早さを期待されていると認識している．締め切りを設定されるベンダーの習慣とも言えるが 5. のクライアント側の回答からそれが間違った印象では無いことが読み取れる．

また項目数は４‐ ６が適切と考えられる．A4 用紙１枚で配布する形をとるが質問は表面にまとめた方がよい．実
際，問６は文章や絵など自由に記入して欲しい問いであったので裏面にまわした事があったが，項目がより多く感じられ気後れしてしまうというクライアントの意見があった．解答欄がせますぎると感じる参加者は勝手に裏面なり別ルートで意見を伝えてくれることがある．
問題数を削るのは悩ましいことであるが，おそらくこの６項目は多いほうだという印象を現在の著者は持っている．

2.は打ち合わせ中に言えなかったことを拾い上げる項目である．今回は双方ともに必要なことは発言できたと考えている．
3.4.は，それぞれ相手が自分の話を理解しているかと思うか尋ねている．本当にすべて理解されているかはともかく，「話はしたけれど分かっているのか」という疑念ポイントが生じた場合，早めに解消しておく必要がある．今回の回答ではベンダー側は説明を分かって貰ったと思っているものの，最初の相違はどのようなイメージの違いで生じたものか気にしている．この点についてベンダー側は翌日，電話にて再確認を行った．

分析は一度の実施単位で回収したデータを表計算ソ
フト等を使ってベンダー側参加者，クライアント側参加者を共に横に並べる，複数回の実施データは同様に時系列で縦あるいは別シートに並べる．このようにすると活発な参加者・消極的な参加者がわかりやすい．消極的な参加者も開発の関係者でありその意見は「ない」のではなく共有されていない状態だということに留意する．
また横方向・縦方向に繰り返される意見の塊ができることがある．開発の進み具合でそれらは移り変わっていくが，ここに開発の進み具合以外の変数が隠れていることがあり，なにが発生しているか読み取る努力が求められる．
回答は上記のようにまとめられ，プロジェクトの「現在」として共有される．ただ，筆者は集まった分析は次の提示物やインタビューになんらかの形で必ず反映させることとして直接生データをクライアント側に現状公開してい5.は次回打ち合わせの改善点を尋ねている．実際は次回の打ち合わせではこんなことを話したいという議題の予告になっている．
ここでクライアントは次回では動作するものを見せて貰い検証ができることを期待している．行いたいことは 2.の入力ができて操作周りを確認することだと思われる．
ベンダー側は特になにも回答していないが，1.で受けた早くできることが期待されている印象が間違っていないことが読み取れる．実際，次回で動作検証というのは無理であったので，ベンダー側は定期的な進捗の間隔を少し密にしてみることを検討した．
6.は打ち合わせ後の落ち穂拾いである．

110

SEA

ソフトウェア・シンポジウム2016 in 米子

ない．集まった回答の中にはプロジェクトの成否によって事業の継続が変わってくることや，責任論などの問題や，具体的な個人名を挙げた意見なども含まれるためである．いずれも大きな示唆を与えてくれる意見であるが公開には注意を要する．また，このようなアンケート形式の質問票の場合，回答者は暗黙の了解としてそれが直接公開されることは想定していない．公開する方針で実施する場合は Minute Paper 上にその旨，明示しておく必要があるだろう．

「振り返って考える時間」を持つことを働きかける．筆者の Minute Paper の場合，参加者にとって「この打ち合わせで重要だった事」はなんだったのか．言いそびれた事，伝わったか不安なこと，次回への期待などを意識してもらうようデザインした．
そして記入して提出するというアクションを求める．自分が打ち合わせに参加しているという自意識を強化するとともに，プロジェクトは参加者を必要としているというシグナルを送る．
この点で Minute Paper は単なる議事録を超える「打ち合わせをデザインする」能動的な文書だと捉えられる．

回答には直接顔を合わせたインタビューでは言いにくかったこと，インタビュー後に考えを整理して初めて出てきた意見，時に厳しい指摘などが この機会がなければずっと遅くなったであろう早いタイミングで出てくる．適
切にフォローしていくことが問題の早期発見や合意形成に役立つと考える．

5.

結論

本研究では，要求工程の打ち合わせがベンダーとクライアントがその認識を確認する非常に重要な場であるということから，打ち合わせをデザインしてその価値を高めるために能動的な文書としての Minute Paper を適用した．

4-3. 議事録との比較
開発現場ではさまざまな形で打ち合わせが繰り返されるが，その内容はメモとして保管されるか，もう少しまとまって議事録(Minute)として関係者に配られる．

4-1 の分析にみるように・解釈の相違を電話で確認している・定期的な進捗の間隔を少し密にするよう検討している（これは実際に実施された）・クライアント側の要望をひとつ，早期に拾い上げたと，打ち合わせ後の参加者の考察や試みが MinutePaper を通じて発言や行動として表現され，参加者がどのように現状を認識しているかという事柄は次の打ち合わせの参考すべき情報として利用された．

議事録は多くの場面で作成されるので馴染みがあると思われる．ここで，改めて議事録と Minute Paper の比較を行いたい．
議事録は既に行った打ち合わせで明らかになった内容をまとめ，その決定事項とそれに至る経緯を記して会議参加者および参加できなかった関係者に配布し保管されるもので，良く書かれた議事録は第三者が見てもその流れが把握できるものになっている．
特に，後から「言った・言わない」のトラブルが発生したときには非情に効果的に働くので，コミュニケーション不良を抱えているプロジェクトでは議事録の制作と配布で問題が改善される事柄も多い．
しかし，会議を終えて参加者に回ってきた議事録はその後どう参加者に働きかけるだろうか．参加者はデスクに回ってきた議事録を一瞥してファイルに綴じてしまわないだろうか．保管された議事録が再び読まれるのは問題が発生したあとではないだろうか．ある人にとって打ち合わせは自分のデスクに戻ってきた時点で「終わった」ものになっていないだろうか．
つまり関心の薄いまたは議事録を常に確認する習慣のない参加者に対して，議事録はなにも行わない．参加者をコントロールするすべを持たない．打ち合わせ中に覚えた違和感や疑問の行き先は確保されていない．

Minute Paper は，その問いの空欄を埋めるために短くとも時間を取り，振り返って考えることがデザインされている．また，書くというアクションを定期的に求めることで関心の薄い参加者に参加を即し，また参加が求められているというシグナルを送る．これらは個人の内で考察や試みの時間を確保し発言として外部に表現することに他ならず参加意識の向上を果たしている．
ごく小規模な環境から適用可能であり，クライアント・ベンダーを問わず参加者全員の意見を横断的に見渡せる．その結果，打ち合わせに潜んでいた個々人の関心や理解度を分析するソースとなる．
Minute Paper の分析結果は次回の提示物や打ち合わせの議題としてフィードバックされ，なにを共通認識として持っているのか，合意を図るべき課題はなにかをというコミュニケーション不良に基づく問題を改善する．
現在は主に教育の分野で用いられる手法であるが，以上のような有効な効果からソフトウェア開発にも必要な従来にない手法であると考える．

それに対して Minute Paper は打ち合わせで明らかにならなかったことを記録する文書である．
Minute Paper は打ち合わせを参加者がデスクに戻った時点で終了させない．これを使用することで参加者に111SEA

ソフトウェア・シンポジウム2016 in 米子

6.

今後の課題事例を収集し，Minute Paper のどのような記述から現在何が発生していると読み取れたのか，またプロジェクト終了後に開発全体を振り返り，発生する問題が打ち合わせの際にどの時点でどのように兆候として表れていたかを Minute Paper から検出することが可能であるのかを集め，読み取る際のポイントとして分類・整理したい．
ただし，この「回答から読み取る」という分析の形は，読み手の着眼点や経験に左右されるのは否めない．多くの実施者による多様な分析は経験的なセオリーとして価値があるものと思われるが，昨今の質問紙調査の自由回答テキストからのデータ分析を参考により定量的な分析が行えないか試みることも考えたい．
それらの為には最初に述べたように事例の収集が必要なのだが，筆者個人が年間に携わるプロジェクトの数は限られており，どうしても多くの実施者による実例の報告が不可欠である．もちろんその結果は報告者にフィードバックして共に考えるものとしたい．
もし，本研究に興味を持っていただけたなら実施して筆者に連絡をいただけると幸いである．
また，その他アクティブ・ラーニング手法の中にも開発現場への応用の可能性が見いだせると考えており，その方面でも研究を継続したい．

参照文献

[1]

栗田香代子 他, “インタラクティブ・ティーチン グ , ” 2015. [ オ ン ラ イ ン ]. Available:
https://lms.gacco.org/courses/coursev1:gacco+ga017+2016_04/about. [アクセス日: 1505 2016].

112

SEA

ソフトウェア・シンポジウム2016 in 米子

付録 Minute Paper
場所
日時

氏名

1. 本日の打ち合わせで最も重要だと感じたこと，印象に残ったことは何ですか？

2. 言いたいと思ったことはいえましたか？言いそびれたことがあればお書きください．

3. 相手の話は理解できましたか？ 分からなかったことがあればお書きください．

4. 相手はあなたの話を十分理解してくれたと思いますか，まだ理解が不十分かもしれないと思われるところはありませんでしたか？

5. 次回の打ち合わせで改善して欲しい点，期待することはありますか？

6. 打ち合わせ後に思いついたアイデアなどがあればお書きください．(文または絵)（必要であれば裏面もお使いください）
返送方法：手渡し,または Email:okamoto@nms.ne.jp , FAX:088-679-7099
この回答は今回のプロジェクトの改善および技法の研究に使用します。

113

SEA