Skip to content

Tag: denso

技術レビューの現場におけるGSNの活用法(2)〜相手と自分の共通理解をつくるには

「モデリングしてますか?」 DENSOクリエイトの小林さんを再度お招きして、GSNを使ってレビューをする際に問題となる「共通の合意の作り方」についてお話ししていただきたいと思います。では小林さん、よろしくお願いします。   前回「議論においては、前提を相手と合わせる事が大切だ」とお話させていただきましたが、今回は、そこについて簡単に紹介させていただきたいと思います。 まずはじめに、相手と自分の、議論の前提の認識が合っているかどうか、という状況を図示すると、おそらくこういう4ディションになるのではないかと思います。  自分と相手が共に知っている状態 1つ目については「自分と相手が共に知っている状態」。ここは、実際の開発現場で考えると、相手がずっと仕事をやってきて、自分も一緒に仕事をやってきた、というのが、このディションになるのではないかと思います。  相手は知らず、自分のみ知っている状態 – しっかり教える 「相手が知らなくて、自分が知っている」所というのは、自分たちの技術に、お客様が非常に関心を持ってくれている、「新しく仕事を始めよう」という状態、あるいは、お客さんの方の窓口が変わった、という場合は、こういう所になります。 ここでは、自分の知っていることを相手にしっかり説明しておかなければ、相手が、いつまで経っても「自分のこととして仕事に取り組んでくれない」とか「中を見てくれない」といったことになるのではないかと思います。  相手のみ知って、自分が知らない状態 – しっかり教えてもらい明文化する 「相手が知っていて、自分が知らない」という領域については、お客さんが長らくやってきた製品開発の中で、自分たちが参入する、という場合になると思うのですが、ここの前提もしっかり合わせておかないと、後になって「なぜこんな事も分からないのか?」というような話があがるかもしれません。 そういうリスクがあるので、ここの領域については、相手にしっかり教えてもらって、明文化するという事が必要になると思います。 前後しますが、ここ (相手が知らず、自分のみ知っている領域)は「教えてあげる」という事がいりますね。  自分も相手も知らない状態 – 一緒に前提を作り上げる 最後に「自分も知らずに、相手も知らない」という領域については、相手と自分が一緒になってまずは前提を作っていくという作業があって、それに基づいて仕事を始めるとうまくいくのではないかと思います。 ここは「一緒に作り上げる」ということが大切ではないかと思います。 議論自体は、こういう形になると思ってます。  議論の周囲にある「相手と合意しているもの」を明らかにしてから議論を形作る 議論の対象がこのスコープだとします。その時に、先ほどのモデル(相手と自分の状態)を念頭に置きながら、どういった前提文書があるか、相手と合意形成されている前提文書や証拠文書、こういったものをしっかりと洗い出すことが、まず大事だと思います。 その上で、議論の対象となるもの、「何を主張したいか」ということ、例えばこの主張が妥当であることを証明したいのであれば、前提文書等を用いて、この主張を分解していき、相手と合意形成をできる証拠文書に基づいて、ここを証明する、と、こんな形で先ほどの議論モデルを念頭においてまとめてくると、GSNでこういった形で伝わるのではないかと。 そこが合ってることによって、共通理解をもったGSNを書いて、相手に納得してもらえるのではないかと、そういうことを考えています。 はい、ありがとうございました。 […]

技術レビューにおけるGSN, D-Caseの現場活用法(1)〜レビューの前提となる基準を作る

モデリングしてますか? 今日は、DENSOクリエイトの小林さんをお招きしてGSNを現場のレビューで活用する、という例についてお話をしていただきます。 では、小林さん、よろしくお願いします。   クリエイトの小林です。今日は、平鍋さんに機会をいただきましてGSN(Goal Structuring Notation)の現場活用についてお話させていただきます。    GSN(Goal Structuring Notation)の記述ルール 先ずはじめに、GSNの簡単な記述ルールですが、GSNとは、トップに自分の主張したいものの状態を置きまして、それを、相手と合意形成している前提に基づいてサブの主張に分解していく、と、最終的に、そのサブの主張が、証拠に基づいて証明される、といった記法になっております。  GSNを使って解決したいこと 実際これを開発現場で、どう活用していこうかという事なんですが、現状は、現場が抱えている問題としまして、皆様もよく感じられる事があると思うのですが、上位の方が、部下の成果を見た時に「この内容って、何でこういう形になってるの?」という事が分からない、とか、そういった話がよくあると思います。又は「僕の思った通りに作ってくれないじゃないか」といったような事もあるんじゃないかと思います。また部下の視点からいくと、上司の人に見てもらったんだけど何回見てもらってもOKがでない、といった事もあるように思います。 それを簡単に図示した絵が、こちらの絵になるのですが、この絵の中では、作成者の方が、成果物を、自分の考えに基づいて作成し、上位の方も、自分の経験に基づいて確認する、といったことになっています。 当然ここで、上位の方と部下の方、作成者の方ですね。ここの考え方というのが合ってるはずがないので、その結果、度重なるやり直しとか、手戻りといったことが発生しているのではないかと考えております。 そうしたものを解決するために、一番簡単なのが「上司の方と部下の方の認識を合わせる」「考え方を共通化する」という事が大事だろうと。 ですので、こちらの図に書かれていますように、色んな基準というものレベルがあると思うのですが、それを上位と会議の担当者の方と合わせることによって、作成者の方はその基準に基づいてものを作り、上位の方は、その基準に基づいて成果物をレビューする、と、そうすることによって、手戻りなく、うまく仕事ができるんじゃないかなという風に考えて、こういった活動を現場に投入していこうと、いま考えております。 GSNを使って解決する方法としましては、こちらの図に示しましたように、相手と自分の考え方を共通化する、という上司と部下の認識を合わせることによって、部下の方は、成果物をそれに基づいて作成し、上司の方は、それに基づいて部下の成果を確認する、という仕組みを作ることで、うまく仕事が回るようになるのではないかと思っております。 ということは、このコンテキストの所に、「基準」というものを書いていく、ということによって全体の考え方が、上司と部下、あるいはレビュイーとレビューワーの間で合意を先に作っておく、ということで、このGSNが、よりレビューしやすくなるという風に考えればいいですね。 この続きについては、次のビデオでご紹介します。