かざいむ日誌

IT関係で知ったことなどを記事としてあげていきます。内容に不備や質問などあればぜひコメントをよせてください。

設計Nightに行ってきました。 #sekkei_n2018

先日設計Nightというトークイベントに行ってきました。これは元々、 @shinpei0213 さんがBuildersconで話した内容についてのスピンオフ企画。忘れてしまいそうなのでメモがてらアウトプット。まずは登壇者の方々の資料を貼る。

nekogata.hatenablog.com

YouTubeに講演動画上がってました。

 

@moznion さんの発表資料

speakerdeck.com

 

@magnolia_k_ は公開資料作成中らしいですが、確かにこの1枚に凝縮されてます。

 

 

追記。資料公開されたようなので貼っておきます。

speakerdeck.com

 

@sona さん

medium.com

 

@moznion さん『ソフトウェア開発における「設計」と「パフォーマンス」の相互作用』

パフォーマンスを上げるための取り組みを垂直、水平、その他という切り口で分けていて分かりやすかった。スライド中に何度か「ゼニや」というえげつない言葉が出てくるが、ビジネスを見ろと言う大事な指摘だと思う。技術的負債という言葉と同じで、パフォーマンスもコストという物差しがあることで、妥当なラインを判断できるということを学んだ。まずはコストに見合わない「早すぎる最適化」をせずに、素直に設計する。インプレッションやユーザ体験、サーバの有効活用の観点から必要に応じて、パフォーマンスを向上させる設計を行う。設計のきれいさやパフォーマンスといったそのままでは比較できないものを「ゼニ」で判断するというとても面白い発表だった。

 

@magnolia_k_ さん『ドメイン知識の暗黙知を形式知にするためには』

仕事で業務システムを作っているので個人的には一番身近に感じたトピック。ドメイン知識がなぜ暗黙知になるのか、どうやったら形式知とできるのかについての発表。暗黙知を3つに分けてそれぞれになぜ形式知とならないかを説明されていた。事実は起きた時にいた人には当然のことになっているから明示的に共有しない。関係はある視点から見た時に浮き彫りになるものだから視点を持つことなしに明示化できない。原則はそもそも意識しない、例外は書ききれないから共有されない。これはとても納得感があった。関係を明示化する方法として、何かしらかのフレームワーク（例えばAs-Is、To-Beモデル）に当てはめてみることを提案されていてなるほどと思った。原則を形式知にする方法がちょっと記憶が飛んでる。

ここで思い出したのが、国際協力のファシリテーションの本。この本の考え方がヒントになるんじゃないかと思った。

途上国の人々との話し方―国際協力メタファシリテーションの手法

途上国の人々との話し方―国際協力メタファシリテーションの手法

 

『途上国の人々との話し方 国際協力メタファシリテーションの手法』
和田信明、中田豊一（2010年）
みずのわ出版

 

これは国際協力で、援助対象の地域の人に課題を聞き取る時のヒアリングについて書かれた本だ。いくつか引用やメモを紹介する。

「私」は、村人に「問題は何ですか」と、聞いてはいけなかったし、「原因はなぜですか」とも決して尋ねてはならなかった。  

現実を構成する3要素：事実、観念・考え・意見、感情・情緒・気持ち
すべての質問が次の３つのタイプに分けることが出来る
１．「朝ご飯は何が好きですか」→好み＝感覚、感情
２．「朝ご飯はいつも何を食べますか」→思い込み、考え、意見
３．「朝ご飯は今日は何を食べましたか」→事実
WhyとHowを使った質問は現実を浮かび上がらせない
事実質問に徹するということは、「観念」「概念」を尋ねる質問は控えるということ。こちらは事実を知りたくて質問しているのに、相手は、こちらに合わせて自分の考えを交えて答えることになり、やり取りに食い違いが生じる、つまり現実認識を共有できない、あるいは、思い込みと事実を区別しないままに、「思い込み」のほうを答えてしまう、という混乱を避けるということであった。

 

本当の原因を知りたいのであれば、「なぜ？どうして？」と当人に聞かないほうがいい。卑近な例でいえば、「先生、お腹が痛いんです」と言う患者に対して、医者が「どうしてですか？」と聞くはずがないということことだ。患者の自己分析など尋ねないで、医者は、「いつからですか？」「今朝は何か食べましたか？」という具合に問診、すなわち事実質問を重ねていくことを私たちはよく知っているではないか。
課題分析を手助けするためには、問題そのものについても、こちらからは尋ねないのが対話型ファシリテーションの原則である。逆に、もし相手がこちらに聞いてほしい問題があるのであれば、必ず相手から語り始めるはずだ。だから、こちらは、何でもいいので、相手の周辺で目に付いた物の中から意味のありそうなものを選んで、「それは何ですか？」「何でできているのですか？」「いつ手に入れたのですか？」などと単純に聞き始めればよい、ということである。

ちょっとずれているかもしれないけど、、、。

 

@sona さん『マイクロサービスと設計原則 』

FiNCでのマイクロサービスの実践を設計原則に照らし合わせてどのようにマイクロサービスを構成するのが良いかについての発表。マイクロサービスやったことないので、こういう課題があるのかというのが、FiNCでの事例で具体的に分かってとても面白かった。基準の立て方で、方針や構成が変わるというのがとても面白い。「実装のDRY」ではなく「作業のDRY」を目指すというのが名言。

今気づいたけど（いまさら）、マイクロサービスこそDRYの理想の体現で、マイクロサービスで出てくるDRYにまつわる問題は、DRYの根本的な問題と言えると思う。発表では横断的な関心事をDRYでどう解決するか、視点によってDRYの切り口が変わるという問題をどう解決するかという本質的な話をされていた、と今さら気付いた。それぞれ、横断的な関心事は「実装のDRY」ではなく、「作業のDRY」を目指すことにより解決する、視点によってDRYの切り口が変わる場合は、それぞれを１つのビジネスとみなしてマイクロサービスを設計する。なるほど。

 

とても楽しいトークイベントでした。ありがとうございました！