【読書感想ブログ】読書は一冊のノートにまとめなさい[完全版] - 奥野宜之 / ダイアモンド社

読書読書(2023)

この題名を見たとき「書籍1冊につき、ノート1冊分の読書メモをとりなさい」という意味なのかな？と思っていましたが、読んでみると全然違って「本を探すところから、読書メモから全部を一冊のノートのまとめるとよりよい読書ライフができるよ！」という本でした。

去年の5月ごろから始めた読書感想ブログですけど、ブログを書いてもなんだか薄っぺらい感想しか書けなくてどうしたもんかなと思っていて、読書メモを取りながら読んだほうがいいんだろうなぁ～という漠然とした気持ちがあり、去年の後半くらいから読書メモを取るようにしてたんですが、メモのつもりがほぼほぼ写経みたいなことになってしまい、読書するのがただただ辛い修行のようなものになっていました。

この本の中でもそのようなことが書いていて、読書メモはできるだけとらないようにして、「通読」→「再読」→「マーキング」を経てから読書メモをとるようにしましょうと書いてありました。

「通読」はそのままの意味で、本を通読します。ただ、途中で気になったポイントや心に留まったところのページの上端を折っておきます。

「再読」は折ったページを読み返します。その時に、やっぱりここは重要だなと思うところのページの下端を折ります。

ここで「ページの両面にそういうポイントがあった場合はどうしたらいいの？」という疑問があると思いますが、それはどっちかを諦めるという割り切りが必要です。作者はこれも運命と受け入れて先に読み進むことを選ぶのだそう。私はあきらめきれないので、通読の時は右ページであれば上端、左ページであれば下端を折り曲げて、再読のときは折り曲げたページの端を再度折り曲げる方法でやっていこうかなと思っています。皆さんも独自のやり方を編み出してもいいかもしれませんね。

「再読」が終われば次は「マーキング」です。上下端が折られているページを再々読して「ここはやっぱり重要だな！」と思うポイントにマーカーを引きます。

「マーキング」が終わったらいよいよ読書メモを取ります。マーキングした文章を「写経」してノートに写して、その文章に対してコメントを続けて書きます。

これを繰り返すだけです。

私はこの方法プラス、読書メモのはじめにこの本はどういった本かの要約を書くようにしようかなと思っています。そうすることで、この本を人に話すときに説明しやすくなるんじゃないか？とか、読み返すときに「あぁ、こういう本だったな」ということがわかりやすくなるかなと思ったので。

作者は読書メモ以外にも「探書リスト」も読書メモと同じノートに残しておくようにすると良いと書かれています。そうすることで書籍を探す手間を省き、最短で良書に出会うことが可能になり最効率で読書が血肉となるのだということでした。

私はまだその境地まで至っていないので、今は気になった本のタイトルを付箋に書き出して張る。くらいにとどめておこうと思いました。

まとめ

この本を読んで、読書メモの取り方を変えてみました。お試しでこの本に対してこの本に書かれているやり方で読書メモを取ってみましたが、今までやっていた読書メモの取り方と比べて断然やりやすかったです。

しかも、メモの量が格段に少なくなって、濃縮された情報がノートに残されている感じがします。

また、自分のコメントを書くことで読み返したときに「そうそう！そう思ってた！」と読み返すのがちょっと楽しくなることを発見できて、「これはいいぞ」という手ごたえのようなものを感じています。

そのおかげか、このブログもスラスラかけた気がします（内容は稚拙かもですが）

なので、しばらくはこの方法でやってみようかなと思います。

そういうことで、この本は結構お勧めです。

2022-12-26

rb_enc_prev_char の動き

memo.sugyan.com

このブログを見て、rb_enc_prev_char の動きが気になった。

まず、 String#rindex がほんとに HAVE_MEMRCHR がないからかどうかを検証。

linux で ruby をコードからビルド。

$ git clone https://github.com/ruby/ruby
$ cd ruby
$ autoconf
$ ./configure
$ make
$ ruby -e 'p "\x00\x01\x80\x00".rindex("\x01")'

linux では 1 になる。しかし、string.c の str_rindex() の内容を無理やり HAVE_MEMRCHR の false 側にして再実行すると 2 になる。ということは、false側の str_rindex() に問題があることがわかる。

rb_enc_prev_char の実装はここにある。 ruby/encoding.h at v3_1_3 · ruby/ruby · GitHub

rb_enc_prev_char の中では onigenc_get_prev_char_head を呼んでいるだけっぽいので onigenc_get_prev_char_head の実装を見てみる。実装はこちら ruby/regenc.c at v3_1_3 · ruby/ruby · GitHub

onigenc_get_prev_char_head の中では ONIGENC_LEFT_ADJUST_CHAR_HEAD を呼んでるだけっぽいので ONIGENC_LEFT_ADJUST_CHAR_HEAD の実装を見てみる。実装はこちら ruby/onigmo.h at v3_1_3 · ruby/ruby · GitHub

ONIGENC_LEFT_ADJUST_CHAR_HEAD の中では各エンコーディングの left_adjust_char_head が呼ばれているだけっぽい ruby のデフォルトエンコーディングは UTF8なので、実装はUTF8のエンコーディングのソースにある。 ruby/utf_8.c at v3_1_3 · ruby/ruby · GitHub

left_adjust_char_head では utf8_islead()じゃなかったらポインタのマイナスを繰り返す。

utf8_islead() の実装はこちら ruby/utf_8.c at v3_1_3 · ruby/ruby · GitHub

#define utf8_islead(c)     ((UChar )((c) & 0xc0) != 0x80)

文字を 0xc0 でマスクして 0x80 じゃなかったら true

ということは、0x80 ～ 0xBF ならポインタがマイナスする。

str_rindex は pos を返すが、pos自体は1つずつしか減らないのに対して、rb_enc_prev_char はエンコーディングによって 2バイト以上減る可能性があることから問題が発生している。

ちなみに、Ruby3.2 ではこの点が解決されていて、 pos を返すのではなくて、検索している文字列のポインタの位置から文字列の最初のポインタの位置を引いた値を返すようになっているので、ちゃんと 1 が返るようになっている。

ちなみに、 ruby 3.2 であっても、以下のようなコードは動作しない。

ruby -e 'p "\x00\x01\x80\x00".rindex("\x80")'

これは、検索文字列の \x80 が rb_env_prev_char でスキップされてしまうので検索文字列としてヒットしないため。

こういう場合はちゃんとエンコーディングを合わせるようにしないといけない。

ruby -e 'p "\x00\x01\x80\x00".b.rindex("\x80".b)'

まとめ

Ruby の文字列をバイト文字列として扱うには、そのままではダメ。ちゃんと String#b を使おう。

2022-11-27

【読書感想ブログ】ドメイン駆動設計(モデリング/実装ガイド)

読書(2022) 読書

参考図書

little-hands.booth.pm

設計なんもわからん

みなさん開発してますか？開発してるとぶち当たるカベがありますよね？

そうです設計です。

「このシステムどうやったら奇麗に作れるんだろう？」と日々思い悩みながら

あーでもないこーでもないと手探りで開発を進める日々ですよね？

一昔前であれば「デザインパターン」を覚えたり、GitHubの人気リポジトリのコードを

真似したりするのが主流でしたが、最近はドメイン駆動設計(通称:DDD)なるものが

巷で噂になってますよね？

私がDDDという単語を耳にするようになってからもう数年たちます。

なにやら難しそうだな～という感想を持ち幾星霜。いよいよ重い腰を上げて勉強してみようと思った次第です。

ドメイン駆動設計とは？

ドメイン駆動設計を説明するためにまずは「ドメイン」について説明しなければならないでしょう。

ドメインと聞くと、hatena.ne.jp のようなものを想像しますがこれではありません。

ドメインとは、「ソフトウェアが解決しようとしている問題の対象領域」のことを指す言葉です。

ドメイン自体は英語で「領域」とか「分野」なんて訳され方をするので単純に「問題の対象領域」と思っておけばいいかと思います。

そして、ドメイン駆動設計とは

ドメインに対してモデリングによってソフトウェアの価値を高めることを目指す開発手法 のことを指します。

モデル

「モデリングによってソフトウェアの価値を高める」ということですが、じゃぁ「モデリング」ってなんぞ？という話になりますよね？

「モデリング」はモデルを作成することです。「モデル」とは、問題解決のために物事の特定の側面を抽象化したもの になります。

ようは、家を作る前に設計図を引きますよね？その設計図のことをモデルという言葉で表現してると思ってもらえばいいと思います。

良いモデルとは？

「設計図ってことは外部仕様書や詳細設計仕様書ってことだろ？そんなのとうの昔からやっとりまんがな」という人もおられるかもしれません。

でもその仕様書、本当に役に立ってますか？

良いモデルとは 問題解決ができるモデルのこと をいいますが、その仕様書で問題解決できているならよい仕様書という事だと思います。

もし、そういう仕様書を作成できていない、もしくは今の仕様書に不満がある、もっというと仕様書なんて書いてなかった。。。という人にはこの本は役に立つ情報が乗っているかもしれません。

良いモデルを作るには

良いモデルを作るコツがあります。それは

ドメインエキスパートと会話し、ドメインについての理解を深めモデルを作成
そのモデルを元にソフトウェアを作成
運用してみて気づいた問題を再度ドメインエキスパートと会話しモデルを改善
改善したモデルを元にソフトウェアを作成
運用してみて問題に気づく→3に戻る

というサイクルを回すことです。

ドメインエキスパートとは、ドメイン(問題領域)に詳しい人のことです。

採用管理アプリなら人事担当者とかのことですね。

はじめは設計担当者にドメイン知識がなくともエキスパートに聞きながら作成することで

大きな間違いを犯すことなく開発が進められるというメリットがＤＤＤにはあります。

なので、できるだけサイクルは小さく早く回すのがよいでしょう。

アジャイルとの親和性

この作成→改善のサイクルを回すという流れはアジャイルととても親和性が高いです。

というのもこのDDDの提唱者のエリックエヴァンスはアジャイルを意識してこの設計手法を考えているからですね。

なので、開発プロセスにアジャイルを取り入れるとDDDがやりやすくなるかもしれません。

ユビキタス言語

DDDの設計アプローチの一つに、「発見したモデルの言葉をすべての場所で使う」というものがあります。

例えば「商品」というモデルがあった時にそれを開発者だけではなくビジネス側の人間とも同じ言葉として使用するということです。

先ほどの「ドメイン」に複数の意味があってはならないということですね。

ある人はDDDの「ドメイン」を想像しているけど、ある人はURLの「ドメイン」を想像している。

その状態で会話をしてもいわゆる アンジャッシュのコント状態 になります。

なので、使用する言葉は関係するすべての場所で同じ認識をもって使うことが重要です。

それはコード内でも同様で、「商品」というモデルはコード中でも「商品」として扱います。

コード内に日本語が使えないのであれば、対応表を作成し、「商品」はコード上では「Goods」と表現することを明示してあげることが重要です。

そういう意味では英語圏の人たちは対応表を作成しなくてもいいのでDDDを取り入れやすいかもですね。

ユビキタス言語が必要な理由

DDDではモデルを何度も継続的にアップデートします。

そのアップデートの中でモデルとコードが乖離してしまうと変更に時間がかかってしまいます。

そしてバグも埋め込まれやすくなります。

そこで設計したモデルをそのままコードに落とし込めれば認識のずれがなくなり変更に強いソフトウェアとなります。

なので、極力モデルをそのままコードに落とし込むことを心がけましょう

DDDを実装するためのアーキテクチャ

DDDを実装するためのアーキテクチャは世の中に色々ありますが、

作者がオススメしているのは「オニオンアーキテクチャ」です。

DDDを行うための必要最小限のレイヤのみで構成されていながら

強力なアーキテクチャとなっています。

モデリング

作者はこの書籍の中でユースケース図とドメインモデル図を使ってモデリングを行っています。

これは作者の YouTube の中で紹介されている sudoモデリング の構成要素の一つです。

この書籍が出てから約2年後の YouTube で紹介されている sudoモデリングのほうが

より良いモデリング手法となっているのは明らかなので、そちらを参考にされたほうが

もしかするとよいかもしれません。約10分() の動画なので、サクッとみられてよいですよ (^^)

↓↓↓ 作者の YouTube 動画はコチラ ↓↓↓

さようなら軽量DDD。10分でわかるドメインモデリング - ドメイン駆動設計 - YouTube

DDD固有のモデリング手法

集約

集約とは「必ず守りたい強い整合性を持ったオブジェクトの集まり」のことです。

集約を設計・実装する時のルールとして以下の2点があります。

強い整合性の確保が必要なオブジェクト群を1つの集約にする
トランザクションを必ず1つにする

集約オブジェクトを扱う時親となるオブジェクトを集約毎に1つ決めます。

その決められたオブジェクトを「集約ルート」と呼びます。

また、集約は必ず集約単位でリポジトリから取り出し、格納する時も集約単位で行います。

こうすることで整合性が保証します。

どの単位で集約を決めるかというのは機械的に決めることはできず

システム全体のバランスを考えて決めます。

集約は整合性を「強く」確保したいものを1つの集約とします。

整合性を求める全てのオブジェクトを1つにするわけではないので注意が必要です。

集約の境界の決め方はある程度経験と知識が必要になってくるので

一度決めてもおかしいと思ったらモデルを修正してより良い方向に改善し続けるサイクルを回すのが良いと思います。

また、トランザクションの範囲も考慮しながら集約の境界を決めるとよいでしょう。

集約を大きくしてしまってトランザクションのロックも不必要に広くとってしまうようなことになると

システム全体の性能劣化も起こってしまいます。適切なトランザクションの範囲となるように

集約のサイズを決定することが重要です。

境界付けられたコンテキスト

境界付けられたコンテキストとは「特定のモデルを定義・適用する境界を明示的に示したもの」です。

例えば「商品」というものをイメージする時、販売部と配送部ではイメージが異なります。

販売部では「商品」は販売するものであり、配送部では運ぶ対象です。

販売部で欲しい情報ややりたいことがそのまま配送部でも必要だとは限りません。

それぞれにやりたいこと、欲しい情報があったとして、それを一つのクラスで表現すると

複雑で混沌としたクラスになりがちです。

そうするよりも販売部用の商品クラスと配送部用の商品クラスを分けて実装したほうが

クラス自体の複雑さは抑えることができます。

設計の基本原則（高凝集・低結合）

コードを高凝集・低結合にした場合のメリットとして以下のようなものがあります。

コードを読んで理解しやすくなる
コードを修正・拡張しやすくなる
修正時にバグを埋め込みにくくなる
同じコードを別の場所で再利用しやすくなる
テストを実施しやすくなる

昔、私が新入社員のころ、会社で言われていた「みんなが使える部品的なコード」を集めて

開発効率を上げようという取り組みを思い出しました。ようは「コードのモジュール化」を行いましょう。ということですね。

凝集度

凝集度とは「責務・データ・ふるまいの関連の強さ」の尺度です。

「このクラスは何をするクラスなのか？」という問いに対する答えがすべてのクラスで明確になっていれば高凝集であると言えるでしょう。

それをなすためには日ごろから責務について設計の段階で常に考えておく必要があります。

結合度

結合度とは「複数のクラス動詞が依存している度合い」の尺度です。

インターフェースや依存性の注入によって結合度を下げることができそうです。

オニオンアーキテクチャ

※ 図は新卒にも伝わるドメイン駆動設計のアーキテクチャ説明(オニオンアーキテクチャ)[DDD] - little hands' lab より引用

オニオンアーキテクチャは

プレゼンテーション層
ユースケース層
ドメイン層
インフラストラクチャー層

の4層からなるアーキテクチャです。

レイヤードアーキテクチャの問題点をインフラ層とドメイン層の依存関係を逆にすることで解決しています。

プレゼンテーション層

ここはクライアントとの接点となり、エンドポイントの定義や Http Request で渡された値とユースケース層に渡す値とのマッピング、入力値の一部検証を行う責務があります。

ユースケース層

ユースケース層はドメインオブジェクトの生成・使用・永続化依頼を行います。

ドメインオブジェクトからプレゼンテーション層に渡す値の変換もこの層の責務です。

ユースケース層では「何をしたいか (What)」を書き、「どのように実装を実現するか(How)」はドメイン層に記述します。

ユースケースがそのまま記述できていることが理想です。

ドメイン層

ドメインモデルの知識を対応するオブジェクトに記述します。

常に正しいインスタンスしか存在させないことが重要です。

そうすることで、常に整合性が保証されます。

そのような実装にするには以下の2点を行います。

生成条件の強制（デフォルトのコンストラクタを使わずに、値が保証されるコンストラクタを定義したり、ファクトリメソッドを定義します）
ミューテーション条件の強制（オブジェクトの整合性を保証して変更できるメソッドのみ公開します）

インフラ層

インフラ層はリポジトリを実装したり、ドメインオブジェクトの永続化・検索の実装が責務となります。

外部入出力とのコネクション

外部とのコネクションはプレゼン層やインフラ層にアダプタクラスを作成してアダプタクラスを経由してクライアントやデータベースとやり取りを行います。

テスト

DDDは繰り返しモデル・コードがアップデートされます。そのためテストコードは必須です。

ユースケースやドメインオブジェクト単位でテストを書き、CIを回すのが理想です。

境界付けられたコンテキストの実装

先ほど境界付けられたコンテキストは個々のグループでクラスを持つという話をしました。

個別にクラスを持つということはデータの同期が必要になるということです。

それを実現するために、グループ毎にアプリを作成しインフラ層のアダプタ間を接続して行う方法があります。

※ 図は『ドメイン駆動設計モデリング実装ガイド V1.0.3 P64』より引用

1アプリでやりたい場合は、パッケージで切り分けるという方法もあります。

ドメイン層の実装

ドメインモデルを表現するもの（ドメインオブジェクト）は以下の3つが存在しています

エンティティ
値オブジェクト
ドメインイベント (この本の範囲外）

ドメインオブジェクトを使用するものには主に以下のものがあります

リポジトリ
ファクトリー
ドメインサービス

値オブジェクト

値オブジェクトとは、世の中にある値をオブジェクトとして表現しているオブジェクトです。

たとえば「日付」だとか「金額」だとかがそれにあたります。

Date型やint型がすでにあるプログラミング言語であっても

業務内容によって制限があったりルールがあったりする場合は別途その用途に合った型を

値オブジェクトとして定義してあげることが重要です。

エンティティ

エンティティは値オブジェクトと似ていますが、同一性の判定は識別子で行われ、不変性も可変です。

値オブジェクトは同一性の判定を属性値で行い、普遍性は不変です。

ドメインサービス

ドメインサービスとは「モデルをオブジェクトとして表現すると無理があるもの」を表現するときに使用されます。

例えば、メールアドレスの重複チェックがそうです。複数のオブジェクトを操作してチェクする必要があるので

ドメインオブジェクト単体ではモデルを表現できません。

ただし、ドメインモデルは極力エンティティ・値オブジェクトとして表現するようにして

どうしても避けられない場合にのみドメインサービスを使うようにしましょう。

ドメインサービスはどうしても手続き型の実装になりがちで1サービスがファットなクラスになってしまいます。

リポジトリ

リポジトリとは「集約単位で永続化層へのアクセスを提供するもの」です。

リポジトリに渡すもの・返されるものは必ず集約ルートのエンティティになるように設計・実装します。

リポジトリを設計するときはリポジトリを List のように扱います。

List に具体的なメソッドが生えていないように

リポジトリにも抽象的なメソッドのみを生やし

ドメイン知識は別のクラスで実装するようにしましょう

ユースケース層

ドメイン層が整合性を保証できるメソッドのみを公開していれば

ユースケース層はそれを組み合わせて安心してユースケースを実現できます。

この組み合わせを行うことがユースケース層の責務になります。

ユースケースからの戻り値クラス

ユースケース層からプレゼンテーション層に返す値の型は

専用の戻り値クラスに詰め替えて返しましょう

ドメインオブジェクトをそのままプレゼンテーション層に渡してしまうと

往々にしてドメインオブジェクトにプレゼンテーション層のメソッドが生えてしまって

責務違反になってしまいます

CQRS

CQRSは Command Query Responsibility Segregation の略です。

CQRS は「参照に使用するクラスと更新に使用するクラスを分離する」というアーキテクチャです。

※ 図は『ドメイン駆動設計モデリング実装ガイド V1.0.3 P83』より引用

更新系のモデルはドメインオブジェクトをそのまま使用し

参照系のモデルは特定のユースケースに特化した値の型を定義し、

その値を取得する為のサービスも独自に定義します。

プレゼンテーション層

プレゼンテーション層はクライアントトアプリケーションの入出力を実現します。

HTMLテンプレートやルーティング設定もこのレイヤの責務です。

クライアントとの入出力に関するすべてのことはこのレイヤの責務と思っておけばいいでしょう。

WAFに依存する内容をこのレイヤに閉じ込めておければ

ユースケースレイヤ以外は依存なく実装が可能です

表示書式に関することもこのレイヤの責務で

"1,000円" という文字列を 1000 という数値に変換するのがこのレイヤです。

まとめ

DDDについて今までは新しい設計手法で、理解するのにすごく敷居が高いというイメージでしたが

この本を読んでDDDのエッセンスが知れた気がしました。

また、CQRSのような更新系と参照系を分離してクラス化する方法や

インフラ層とドメイン層の依存関係を逆転させるという方法が目からうろこで

この本を読んでよかったなと思えた点でした。

この本を軸にして別のDDD本も読んでDDDの理解を深めたいと思いました。

2022-11-25

AWS IoT MQTT に Ruby で接続する

AWS IoT にモノを追加する

AWS IoT にアクセスして「モノ」を選択

「モノを作成」をクリック

「１つのモノを作成」を選択して「次へ」

任意のモノの名前を入力して「次へ」

※ ほかの項目はデフォルトでOK

「新しい証明書を自動生成（推奨）」を選択して「次へ」

「ポリシーを作成」をクリック

任意のポリシー名を入力して、以下のようにポリシーを設定して「作成」

「ポリシーをアタッチ」のページに戻って作成したポリシーを選択して「モノの作成」をクリック

証明書をダウンロードし「完了」をクリック

以下の3つをダウンロード

デバイス証明書
プライベートキーファイル
Amazon 信頼サービスエンドポイント CA1

※ オプションでパブリックキーファイル、Amazon 信頼サービスエンドポイント CA3 も落としておくと良いかも？

「AWS IoT > 管理 > モノ」にモノが追加されていたらOK

エンドポイントの取得

AWS IoT の「設定」ページを表示する

※ 左のメニュー欄の下のほうにある。

「デバイスデータエンドポイント」に表示されている「エンドポイント」をコピーする

ruby-mqtt を使ってパブリッシャーを作る

ruby-mqtt をインストール

gem install mqtt

ruby スクリプト

require "mqtt"

params = {
  host: "amkpd3vnlnx3d-ats.iot.us-west-2.amazonaws.com",
  port: 8883,
  ssl: true,
  cert_file: %q(<デバイス証明書>),
  key_file: %q(<プライベートキーファイル>),
  ca_file: %q(<Amazon 信頼サービスエンドポイント Amazon ルートCA1>),
}

MQTT::Client.connect(params) do |client|
  client.publish("test", "message")
end

実行

MQTT テストクライアントページを表示

※ トピック test をサブスクライブする

ruby スクリプト実行

※ 各証明書は実行ディレクトリと同じ場所に配置しておくこと

ruby main.rb

結果がテストクライアントページに表示される

おまけ

無限に pub しながら sub するスクリプト

require "mqtt"

params = {
  host: "*****",
  port: 8883,
  ssl: true,
  cert_file: "*****",
  key_file: "*****",
  ca_file: "*****",
}

t1 = Thread.new do
  MQTT::Client.connect(params) do |client|
    client.get("test") do |topic, message|
      puts "#{topic} : #{message}"
        end
  end
end

sleep(3)

MQTT::Client.connect(params) do |client|
    loop do
    client.publish("test", "message")
    sleep(1)
    end
end

t1.join

2022-11-06

【読書感想ブログ】下町ロケット

読書読書(2022)

書籍

下町ロケット (小学館文庫) | 池井戸潤 | 日本の小説・文芸 | Kindleストア | Amazon

いきなり苦難で畳みかけてくる

JAXAのエンジン研究員が佃が主人公で、初めは新型ロケットの発射実験を行うシーンから始まる。

ロケットが発射され、うまく軌道になるかと思われたが、あえなく失敗に終わる。

その責任から、佃はJAXAから去り、今は父親の町工場の佃製作所を継ぎ社長業に専念していた。

佃製作所は小型エンジンやその周辺部品を作る会社で、継いでから7年、業績も順調に伸び、順風満帆。。。

かと思われたが、大手取引先京浜マシナリーからの突然の契約終了宣言。売上の3割を失う事態になる。

その3割を銀行からの融資で補填しようとメインバンクに赴くが、渋い顔をされ追い返されてしまう。

そこに、追い打ちをかけるかのようにライバル会社のナカシマ工業からの特許訴訟が届く。

ナカシマ工業は特許訴訟に強く、技術に詳しい弁護士も多数取り揃えている。

佃の会社にも顧問弁護士はいるが、技術は門外漢の老弁護士。

第一回口頭弁論会でも相手の質問にしどろもどろ。目も当てられない結果となった。

裁判にもお金がかかるが、すでに売上の3割は失い、銀行にもそっぽを向かれている状態。

こんな状態ではいつ倒産するかわからない。どうなってしまうのか。。。

佃は妻とは離婚していて、家に帰ると娘が一人、テレビを見ている。声をかけてもろくに返事もしない。そういう関係。

悲しすぎる。。。

JAXAのエンジニアとして第一線を行っていたあの頃はどこへやら、不幸が不幸を呼びえらいことになっていた。

逆転裁判

そこに一本の電話が、元妻からであった。

元妻は佃の会社が訴訟を受けていることをニュースで知り、心配になって連絡をしてきたのだった。（なんだかんだで夫思いなのか？かわいいかよ・・・）

妻も佃と同じJAXAの研究員をしていた。妻は研究所に残り、佃は抜けた。その溝が埋まらず離婚という結果になった。

なので今も妻は研究所つながりで技術に強い弁護士を幾人か知っているらしい。その一人を佃は紹介してもらった。

その一人はナカシマ工業お抱えの弁護士事務所から喧嘩別れした弁護士らしく、相談に行くと二つ返事でOK。

なんだかんだあって、ナカシマ工業との裁判もその弁護士のおかげで勝つことができ、和解金56億円を手にすることとなる。

一難去ってまた一難

時間は少しさかのぼり、佃製作所がナカシマ工業と裁判で争っているときだった。

帝国重工の制作している新規開発ロケットのエンジン部分が佃製作所が保有している特許に抵触することが分かった。

社長の意向でキーデバイスとなる部分は自社製造することになっており、

特許使用料を払って自社で製造するか、

特許を買い取って自社で製造するか、

その二択だったが、佃製作所は裁判で資金がすぐにでも欲しいだろうと踏んで、特許を買い取ろうという流れになる。

しかし、佃は特許を手放してしまうことは避けたかったため、その要求を突き返す。

帝国重工側は打つ手がなくなりどうしたものかと考えていたところ、裁判の決着のニュースを知り

結局、特許使用の方向で依頼することになる。

しかし、ここもで佃は特許使用ではなく、佃製作所で部品を製造して納品させてくれないか？という提案をする。

社内でも大部分の社員が反対した。特許使用であれば、年間5億の売上があがるが、部品製造の場合、納品後に不良が見つかった時の

巨額賠償のリスクがある。場合によっては数百億円の賠償になる可能性すらあるのである。それを考えたとき

安全に儲けられる特許使用のほうがいいというのが、ほとんどの社員の意見だった。

「社長は会社を私物化している」「社長は我々社員のことなんでどうでもいいんだ」

そんな声がどこからともなく聞こえてくるありさまだった。

しかし、佃はその意思を曲げず、部品製造を帝国重工に提案するのであった。

帝国重工側でも意見が分かれたが、最終的には佃側の意見を受け入れ、バルブシステムを外注する形となる。

途中で、社員とも和解し、会社を上げて、バルブシステムを帝国重工に納入することとなった。

ロケット打ち上げ

佃製作所のバルブシステムを組み込んだ帝国重工が手掛けた新型ロケットが、幾多のテストを潜り抜け、発射当日。

佃製作所の社員一同 + 佃の家族が見守る中、ロケットのカウントダウンが開始。

3, 2, 1, リフトオフ!

ロケットは轟音とともに宇宙の彼方へと消えていく。

順調に第一エンジンの切り離し、第二エンジンへの点火を行うアナウンスが流れ

その後、ロケットは無事衛星軌道に乗ることができるアナウンスが佃の耳に届く。

佃製作所のバルブシステムを積んだロケットは無事成功したのであった。

感想

はじめの大口顧客からの契約終了 & 特許訴訟のダブルパンチ + 銀行の貸し渋りという

3重苦で、この後どうなるんだ感がすごかったです。私としてはこの話は特許問題の話を

解決させて終わりかなと思ったら、そこはまだ序の口で、その後、大企業相手に

中小企業の佃製作所が一歩も引かず、部品納入までして、なおかつちゃんとロケットも

飛ばして見せるという離れ業を繰り出して　ジ・エンド。

この大団円を最高と言わずしてなんというのか。という気持ちでした。

下町ロケットはいくつかシリーズがあるようなので、他のシリーズも見てみようと思いました。

2022-11-05

【読書感想ブログ】宇宙兄弟とFFS理論が教えてくれるあなたの知らないあなたの強み

読書読書(2022)

参考書籍

宇宙兄弟とFFS理論が教えてくれるあなたの知らないあなたの強み【自己診断ID付き】 | 古野俊幸 |本 | 通販 | Amazon

FFS理論?

人によってストレスになる要因は異なります。つまり、環境や刺激に対するとらえ方は人それぞれということです。

その感じ方やとらえ方を5つの因子に分類して、自分を理解することができるのがFFS理論になります。

5つの因子

FFS理論で定義されている5つの因子は以下の通りです。

凝縮性　→　こだわりが強く、他人に流されることが少ない、頑固者
受容性　→　優しくて面倒見がよい。経験豊富な場合は頼れる存在
弁別性　→　合理的で計算的、ドライな性格
拡散性　→　活発で行動力があるが、飽きっぽい
保全性　→　コツコツタイプ。慎重であるが故行動が遅い面も

自己診断

この書籍には簡易自己診断もついていて自分がどの因子が高いかを知ることができます。

この書籍では診断で点数化された因子の上位3つが自分の因子として考えるようです。

日本人に多い因子

上位1,2番目に受容性がくる人の割合が日本人は64%、その次に高い因子が保全性と拡散性です。

凝縮性

他人から見たポジティブな面

決断力があってグイグイと推進している
責任感があって、頼んだことも最後は自分で引き受けている

他人から見たネガティブな面

独善的
支配的
排他的

ストレスと感じる物事

頭ごなしに否定されること

受容性

他人から見たポジティブな面

柔軟な対応力で成果につなげている
面倒みよくかかわって、気配りしながら動いてる

他人から見たネガティブな面

介入的
自虐的
逃避的

ストレスと感じる物事

反応がないこと、役に立っていない時、存在がないがしろにされること

弁別性

他人から見たポジティブな面

最短距離で無駄なく淡々と進めている
判断は合理的で、結論を出すのが早い（情報がない時は、判断しない）

他人から見たネガティブな面

機械的
詭弁的
ドライ(冷たい)

ストレスと感じる物事

理不尽さ、割り切れない状態、感覚的な時

拡散性

他人から見たポジティブな面

大胆な発想で変革を進めている
誰もしないことを平気でやっている

他人から見たネガティブな面

衝動的
破壊的
攻撃的

ストレスと感じる物事

動けない状態、拘束されること、団体行動を強いられる時

保全性

他人から見たポジティブな面

きちんと計画通りに進めて、精度は高い
みんなができることを、自分もできるようにしようとする

他人から見たネガティブな面

追従的
妥協的
拒絶的

ストレスと感じる物事

明確な指針がない時、先が見えない時、急な変更

ストレス

ストレスが適切にかかっているときは、反応・行動の良い面がでるがストレスが少なすぎたり、多すぎたりすると、因子の悪い面が出てしまいます。

まとめ

自分がどの因子が強く、負荷はどの程度かかっているのかを見極め適切に行動すれば、人間関係もうまくいくのではないでしょうか？

また、他人についても分析することで、どのように対応すればストレスをうまくコントロールして良好な関係が保てるのかも見えてくるかもしれませんね。

2022-11-03

【読書感想ブログ】読みたいことを、書けばいい。

読書読書(2022)

はじめに

最近読書感想ブログを書くようになって思うことは「俺、文章力底辺やな」ってこと。

「こんなんじゃ、誰も俺のブログ読んでくれないのでは」という焦燥感を感じているときに

ふらっと本屋さんに立ち寄った時に、俺に囁きかけてくる本が一冊。

その本がこちら↓↓↓

Amazon.co.jp: 読みたいことを、書けばいい。 eBook : 田中泰延: 本

著者の田中泰延さんは元電通の社員で24年間コピーライター・CMプランナーとして活動されていました。

その膨大な年月に裏打ちされたテクニックが濃密に記述されている一冊。。。

と思いきや、

この本の表紙には「文章術」と明記してある。
しかし、書くためのテクニックを教えようというものではない。
そうではなく、書くための考え方を示す本である。

という書き出し。。。私が知りたかったのはテクニック。。。

私はそっと本を閉じ、この本をカップラーメンができ上がるまで蓋を抑える重し代わりに使うことにしました。。。

ということはなく、「考え方も重要だよな」という気持ちで読ませていただきました。

序章の最後は以下のように締めくくられていました。

この本は、そのような無益な文章術や空虚な目標に向かう生き方よりも、
書くことの本来の楽しさと、ちょっとのめんどくささを、あなたに
知ってもらいたいという気持ちで書かれた。

そして同時に、なによりわたし自信に向けて書かれるものである。
すべての文章は、自分のために書かれるものだからだ。

「すべての文章は、自分のために書かれるものだからだ。」

最後まで読んでみて思うのは、これがこの本の全てな気がします。

なにを書くのか

「文章術」とは何か、そもそも文章とは何でしょうか？

書物には「文書」と「文章」の2種類があります。

「文書」は報告書、論文、企画書といった「問題解決」や「目的達成」のためのものであり。基本的に面白味もないので、読みたいと思えるものではありません。

「文章」は書きたい人がいて、読みたい人いる（かもしれない）というもののことを指します。その中でも「随筆」という分野がネット上の9割を占めると言われています。

「随筆」とは「事象と心象が交わるところに生まれる文章」です。

事象とは見聞きしたことや知ったことで、世の中の全ての物事を指します。

心象はその事象に触れて、心が動かされ、この気持ちを誰かに伝えたいと思うことを指します。

事象を客観的にとらえて書かれた文章は「報道」寄りとなり、心象を強く押し出した文章は「創作」「フィクション」寄りとなります。

今あなたが書きたいと思っているものは何ですか？「文書」でしょうか？「文章」でしょうか？それとも「随筆」でしょうか？

「随筆」ならその中でも「事象」寄りでしょうか？「心象」寄りでしょうか？

自分が何を書きたいか、もっと言うと自分が何を読みたいか。それをはっきり意識しておくことは文章を書く上では重要なこととなります。

カマクラ・ミリタリー・ガバメント

「幕府」とは？というくだりがこの本の中にはあります。「今書いている文章の言葉一つ一つに対して、その言葉の意味をしっかりと定義しよう」という文脈の中で「幕府とは？」という問いかけがなされます。「鎌倉幕府」「室町幕府」「江戸幕府」各時代にそれぞれ出現するこれらのワードの正体は一体なんなのか？著者が英語辞書を開いてみると「ミリタリー・ガバメント」と記載されていたそうです。つまり「軍事政権」の意味で「幕府」が使われていたということでした。私はそれまで「幕府」は日本のトップ、政治を司る場所、くらいの意味かと思っていましたが、この言葉でずいぶん理解が深まった気がしました。これがワードをしっかり定義しようということの意味なのです。ざっくりとした解釈で言葉を使って文章を書いていると、やはりその文章もざっくりとした軽いものになりがちですが、定義をしっかりとしておくことで文章の重みが変わってくるのだと、この章で理解させられました。

だれに書くのか

読み手など想定して書かなくていい。その文章を最初に読むのは、間違いなく自分だ。
自分で読んで面白くなければ、書くこと自体が無駄になる。

では自分が読みたい文章とは何でしょうか？

「わたしが言いたいことを書いている人がいない、じゃぁ自分で書くしかない」

そうです。誰も自分が読みたいと思う文章を書いていないとき、読みたいのに読めない。じゃぁ書こうとなるのです。（ならない人もいるかもだけど）

だが、「いまさら書かなくてもいいことは書く必要がない」という事はある意味、ラクなことだ。
特段の新しいものの見方も疑問もなく、読み手でかまわないなら、読み手でいよう。
どこかで読んだ内容を苦労して文章にしてもだれも読まないし、自分も楽しくない。

書きたくないなら、書かなくてもいいよ。そういうメッセージが込められていますね。

でも、私は書きたい。何より未来の私のために。

どう書くのか

随筆とは、結局最後には心象を述べる著述形式だということは述べた。
しかしそのためには、事象を提示して興味を持ってもらわなければならない。
事象とは、つねに人間の外部にあるものであり、心象を語るためには
事象の強度が不可欠なのだ

以下、事象の強度の上げ方

ライターの仕事はまず「調べる」ことから始める。そして調べた9割を棄て
残った1割を書いた中の1割にやっと「筆者はこう思う」と書く

つまり、ライターの考えなど全体の1%以下でよいし、その1％以下を伝えるために
あとの99%以上が要る。「物書きは調べることが9割9分5厘6毛」なのである

むちゃんこ調べて、そのうち1割を要点としてまとめて、まとめの1％に心象を足す。

心象はカレーでいうところの福神漬けですね。

調べ方

著者は「ネットなどの二次資料ではなく、図書館などで一次資料を当たれ」と書いています。

ネットはまた聞きのまた聞きが跳梁跋扈している場所なので、ちゃんとしたソースをもとに話をしよう。ということのようです。

言葉とは、文字通り「葉」である。好きなことを好きに書いた葉を繁らせるためには、
「根」が生えていなければならない。それが一次資料である

しっかりした文章とは、しっかりしたソースをベースにしていて信頼感が違うということなんでしょうね。

調べることは、愛することだ。

自分の感動を探り、

根拠を明らかにし、

感動に根を張り、

枝をはやすために、調べる。

愛と敬意。これが文章の中心にあれば、
あなたが書くものには意味がある

愛と敬意だけが友達さ。

この章のまとめ

さて、この「どう書くのか」の章も最後である。
わたしがこの章で述べたことを要約すると、こうなる


事象に出会った時

そのことについてしっかり調べて

愛と敬意の心象を抱けたならば、

過程も含め、自分に向けて書けばいい。

書く形式は起承転結でいい

起：実際の経験だという前置き
承：具体的に何があったか
転：その意味はなにか。テーゼ化(※)
結：感想と提言。ちょっとだけ

(※) テーゼとは、コトバンクには「ある観念をまとめて表現・主張する文章。」とあります。起承に対するまとめのようなものを書くということかな？

テーゼとは - コトバンク

感想

何事もそうですけど、「愛と敬意」を持つことは重要ですよね。

若い時は何かと物事を否定してマウントを取ることをしていた身分としては耳の痛い話でした。

でも、自分の読みたいものを書けたらそれでいいんだよ。というのはなるほど感あります。

一年後、このブログを見返したときに、楽しく読めればいいな。と思いました。

感想が薄い (・ω・;)