Magnolia Tech

いつもコードのことばかり考えている人のために。

『ドメイン駆動設計入門 』という本が出るそうです

ソフトウェアデザイン誌の過去のドメイン駆動設計特集記事がまとまった単行本が出るそうです。

これは読む用、保存用、教育用の3冊以上買いですね。

過去に感想エントリを書いていました。

blog.magnolia.tech

『読み手につたわる文章 - テクニカルライティング』を読んで、レビューテクニックを身につけよう!

booth.pm

mochikoさんが書かれた『読み手につたわる文章 - テクニカルライティング』という本を読みました。

この本はビジネスの現場で必要な「相手に伝えたいことを正しく伝える」ためのテクニックが詰まった本です。

大事なことがコンパクトに詰まっていて、何度も読み返したり、他の人に紹介するのに適しています。この辺はどうしても商業出版だと一定のページ数が無いと出版が難しいので、同人誌として出版するのに向いている構成ですね。

いくつか「そうだよねー」と思ったトピックを拾っておくと...

  • 読者層を決めてから書こう

    自分も何らかの文書を書く時は、「誰が読むのか?」というのを常に一番考えて書いています。特に、特定の読み手が想定できる報告書などの文書は、まずはどこまで相手の理解度を前提条件として想定できるか?ということを考えます。不特定多数の人向けの文書では難しいですが、特定の人向け、特に直接コミュニケーションがとてる相手であれば素直に聞いたり、確認のための質問を投げたり、色々な方法で相手のメンタルモデルが探れます。場合によっては、質問を投げることで相手も”察して”、結果としてメンタルモデルが形成されることもあります。文書の中に全ての要素を書くと冗長になってしまう、盛り込み過ぎになってしまう時に、「結論から書く」方式も有効ですが、それ以上に「メンタルモデル」を形成するためのコミュニケーションを取る、というのも有効なテクニックだったりしますね。

  • いつまでに何をしてほしいのかを書こう

    この人の文書は分かりづらいな、と思う時、自分がチェックするのは、「事実と推測が混ざっていないか?」「いつまでに何をやってほしいのか明確か?」という二つです。 特に後者に関して、ビジネス文書、特に報告書は「誰かの行動を変容するため」に書かれるはずなのに、そこがボヤけてしまうと何の意味もなくなってしまいます(でも案外、結論をボヤかす、何も言ってない文書を書く人って多いですよね...)

あと至るところでCahtGPTや、ATOKなど、道具に頼るところは頼ろう!というスタンスも、実用文を書くためのプラクティスとしてとてもいい姿勢だな、と思いました。そうですよねー、時間は限られていますし、何か名文コンテストをやっているわけでもないですからね。

そして、この本の最大の大好きポイントは、レビューに関する記載が充実しているところです。特に、特に、レビューする側の心得としての「4.1 レビュアー(レビューする側)のコツ」は年齢が高い、役職が上の人ほど絶対に読んで!今すぐ読んで!読まずにレビューしないで!と言いたくなる大事なことが書かれています。

ほんと目的を間違えたレビューだけはこの世から無くなって欲しいですよね...「このレビューの行き着く先は、精神的な鍛錬?」みたいなレビューは存在してはいけないのです。

と言うわけで、ビジネス文書作成に関わるみんなが読むべき1冊なので、みんなすぐに買いましょう!読みましょう!文書を書きましょう!レビューを(適切に)やっていきましょう!

『ドメイン駆動設計をはじめよう ―ソフトウェアの実装と事業戦略を結びつける実践技法』が出版されます

2021年にO'Reilly Media, Inc.から出版された「Learning Domain-Driven Design」の待望の日本語訳『ドメイン駆動設計をはじめよう ―ソフトウェアの実装と事業戦略を結びつける実践技法』がついに出版されます。

www.oreilly.com

訳者は、増田 亨さん!!


2020年代に、ドメイン駆動設計を学ぶための最初の入り口としてどの本を読めば良いかは、かなり悩ましい...というのはよく言われるのですが(元祖のエバンス本はさすがにだいぶ古くなってきたし、回りくどい表現も多いし...)、そんな時におすすめできる1冊です。

2021年に原著が出版された時に買ってざっと読んでいたのですが、パート1で戦略的DDD(主にビジネス面からの分析)、パート2で戦術的DDD(主に実装面のプラクティス)、パート3でそれを使った実践の方法という流れで、それぞれのトピックに集中できるようになっています。

特に後半は現代的なプラクティスや、アーキテクチャとの関係も明示されていて、1冊で基本的な知識をざっと習得する、という目的には丁度良い構成です。

個人的にはパート1と、パート2の結びつきが大事というか、パート1でユビキタス言語と、境界づけられたコンテキストが揃ったらもう実装に行く?というのは有りますが、この辺は実装例などと比較しながら読み進めた方が良さそうです。DDD百科事典ではなく、あくまで入り口に立つための本だし、そのために必要なところと、そうじゃないところをメリハリつけられているな、という印象でした。

読書会で、それぞれの経験とか、考え方を述べ合うと、その辺りが補完されることでしょう。


と言うわけで、今年の夏の課題図書確定の1冊なので、読んで、読書感想文をみんなで書きましょう!

『「何回説明しても伝わらない」はなぜ起こるのか?』を読んで、「まだ人類はニュータイプじゃないから、そんな簡単には分かり合えません」と言ってたことを思い出した

副題に「認知科学が教えるコミュニケーションの本質と解決策」とあるように、本書はそのタイトル通り、”説明しても伝わらない”が何故起こるのか、そのメカニズムを解説してくれる本です。


この本を読み始めて、昔「まだ人類はニュータイプじゃないから、そんな簡単には分かり合えません」と言ってたことを思い出した。

段々と、そのネタを聞いても分からない世代になってきたので、言わなくなってきたけど。

で、たいていはその後に、「だからこそ相手にどうやって伝わるか考えて、その相手に合わせた情報の整理や、話し方が必要なんですよ」とは言っていたけど、果たしてどれだけの人ができていたのだろう。

よくビジネスにおける会話術で「結論から先に言う」というのが有るけど、あれは割と極端で誤解を生みやすい表現だと思っていて、聴く側にそれなりの準備や共通の前提条件が無ければいくら結論だけ言われても納得はしないので結局「で?」となってしまう。

この本では冒頭で、興味関心に関する枠組みを認知心理学で「スキーマ」と言うとあり、これが合わなければ伝わらない、ということが出発点になっています。

確かに、データベースでもスキーマが合わなければ、データの参照は正しくできないですからね、なるほどね、と思いました。


第2章では、伝わらない場面と、その理由 第3章では、ではどうやって伝えていくか、その方法

が語られていきます。

特に第2章は豊富な事例をもとに解説が続くので読みやすく、すいすい、読み進めることができます...が、果たして、著者の伝えたいことは本当に自分に伝わっているか、それは一度立ち止まって、読み返してみるといいかもしれません。

そして大事なのが第3章の後半です。ここで、正しく伝えるために「抽象」と「具象」を行ったり来たりしながら説明することの大切さが語られます。そして、誤った抽象の方法も併せて語られます。ここがこの本の一番の注目ポイントです。

プログラミングでも、抽象と具象のレベルをコントロールすることで疎結合な、わかりやすく、拡張しやすいプログラムが書けるか?ということが大きなテーマになるのと同じくらいコミュニケーションでも同じように大事なテーマなのです。


blog.magnolia.tech

このブログの前回のエントリで『状況報告、報告を受ける側が知りたいのは尽きるところ「ヤバいか、ヤバくないか」「それで次に行動するのはオレかお前か」というところです』と書きましたが、”ビジネスにおける報告のゴール”は「次に誰が何をいつまでにやるのかを決める」なので、整理していくとこうなるわけですが、だからといって上司に「ヤバい、なんとかして」だけで伝わることはめったにありません(たまに存在する、超絶に察する能力が高い上司は通じちゃいますけどね)。

要約するとそうであっても、それが正しく伝わるためには色々なお膳立てや、工夫が必要になってきますし、報告する相手の思考を十分に考慮する必要があります。

そんな時に、この本を読んでおくと、そのメカニズムが分かって、スムーズに行くと思います。

キングジム『ビジュアルバータイマー』を買った

去年、作業時間の管理にTimeTimerを使うようになって、割り込み無しで10分〜30分くらいの集中度がだいぶ上がるようになりました。

TimeTimerはクルっと測りたい時間をダイヤルで決めて、時間になるとアラームが鳴る、以外の機能が何も無いところがいいのですが、アラーム鳴らないでほしい、みたいな場面もあるのでオンオフできるタイマーを探していたところ、キングジム『ビジュアルバータイマー』が目に止まりました。

見た目通り、時間がカウントダウンのバー形式で表示されるので、TimeTimerと同じで「なんとなくあとこのくらいかー」と感覚で掴めるところが良いところ。

横に正確な時間も出ているけど、敢えて視界に入れない、という選択肢がとれそうなギリギリの大きさ、というのが上手いバランス

4月の発売時には品薄だったみたいで注文から到着までに1ヶ月くらいかかりましたが、今は普通に買えるようです。

10分、1分、10秒という単位を組み合わせて時間を決められるところがデジタルらしい便利さ。

あと、リピートモードという、作業時間と休憩時間を交互に設定できる、ポモドーロ・テクニックに便利なモードが用意されているところもポイント高いです。


ただのタイマーといえばそれまでなので、あとはどんどん使っていきましょう、という以上の話も無いのですが、気になった点を挙げると...

  • 置き場所の都合もあるけど、机の上に置いた時に角度が付けられないのでちょっと見えづらい

    裏にマグネットが有って、冷蔵庫とかに貼る使い方ならいいけど、机の上だと手元にあると、その大きさと相まって絶妙に液晶が見えない(バックライトとかもないし)

  • 電池別売りはもう少しパッケージとか説明に大きく書いておいてほしい

    届くまで別売りに気づかず、数日放置になってしまった

  • 無音か、大きめのアラート音の2択なので、音量が調整できると良い

  • 設定の変え方は分かりづらい...一回リセットしないといけないのが最初戸惑った...直感的じゃない


最初だけ使い方に戸惑うところはありますが、慣れてしまえばそんなに気にならないレベルなので、次世代機は改善されるといいな、くらいでしょうか。


自分の使い方だと、日常的な作業管理は今後もTimeTimerをメイン使って、午後いっぱいリピートモードで管理したい、みたいな時に使うかな、というところです。

状況報告、報告を受ける側が知りたいのは尽きるところ「ヤバいか、ヤバくないか」「それで次に行動するのはオレかお前か」というところです

振り返ると定期的に同じことを書いているんですけど、「報告を受ける側」が期待することって、「ヤバいか、ヤバくないか」「それで次に行動するのはオレかお前か」を素早く判断して、行動に起こすための情報が欲しいわけです。

報告資料が単に「状態」だけを延々書いていて、「で、この状態に対するあなたの見解は?」ということを表現していないと全然意味が無い(いや、たまに意味が有る場面も有るんですけどね)わけですし、それが元々想定された状況と差異が有れば何らかの意思決定と、行動がそこにつながるはずで、報告する側が「誰にどんな行動を期待しているのか?」ということを表明しないと、そこがボヤけてしまいますよね。

意外と、ブログに書いてなかったので、もう一回書いてみました。


一度間違えて、吉祥寺.pmのイベントブログに投稿してしまったので、個人ブログに再投稿です

『エフェクチュエーション 優れた起業家が実践する「5つの原則」』に見た振る舞いと、アジャイルと、ウォーターフォール

先日、人との会話の中で、「Affordable Loss(許容可能な損失)」という言葉が出てきた。全然知らない単語だったので、なんだっけ?と思って調べてみると、「エフェクチュエーション」という理論の中に出てくる用語だということが分かった。

「エフェクチュエーション」に関する本を検索してみると、なかなか分厚い、読むのに苦労しそうな本ばかり出てくるのだけど、去年『エフェクチュエーション 優れた起業家が実践する「5つの原則」』という入門書が出ていることを知って購入。


冒頭に書かれていることをそのまま引用すると、「エフェクチュエーション」とは、”熟達した起業家に対する意思決定実験から発見された、高い不確実性に対して予測ではなく、コントロールによって対処する思考様式”とあります。

当然、この考え方の通りにやれば成功するという方法論ではないのですが、自分が行動を起こすときの前提を変えるきっかけにはなる理論と言えます。

その理論を構成する5つの原則は、以下のように命名されています。

  • 手中の鳥
  • 許容可能な損失
  • レモネード
  • クレイジーキルト
  • 飛行機のパイロット

一見すると何のことだか分からないところがいいですね。具体的な内容は解説されているサイトや、本を読んでみてください。


エフェクチュエーションに対応する、反対の考え方は「コーゼーション」と定義されていて、事前に目標を定め、それに合わせて成功確率を上げるための計画、戦略を定め、必要な資源を確保し、実行に移し、計画通りに実行されていることをモニタリングしながら、当初目標を達成することを目指します。

そして、エフェクチュエーションは、その逆で、手持ちのリソースと、状況に合わせて、素早く行動していこう、という考え方になっています。

つまり、アジャイルと、ウォーターフォールの対比に似ていると感じました。

具体的な方法論は全然異なりますが、結果とそのフィードバックに重点を置くのか、計画/予測に重点を置くのか、という対比は極めて、アジャイルウォーターフォール的だなと思いました。

この本では、エフェクチュエーションと、コーゼーションのどっちが優れている、どちらを採用すべき、どちらか一つしか採用できない、みたいなことは当然書いてなくて、不確実な状況が減れば、当初はエフェクチュエーション的なやり方からコーゼーション的なやり方に変わっていくよね、ということも書かれています。

それはそう。

極端な思考の両端を理解/経験することで、手持ちのカードを増やし、適応できる状況を増やしていくことが、我々にできることじゃないかと。

コーゼーションに振った組織の振る舞いでも階層を変えていくと全然エフェクチュエーション的な考えで運営されていたりしますしね。