2021-07-21

『思考法図鑑ひらめきを生む問題解決・アイデア発想のアプローチ60』の読書感想

読書感想

翔泳社が翔泳社ブックアンバサダーを100名募集というサイトにて、翔泳社の本の感想をSNSを通じて発信するアンバサダーを募集していました。前回の第1回も参加させていただき、そのときのレポートはこちらになります。今回の第2回も当選させていただき、非常にありがたいです。

今回は『思考法図鑑ひらめきを生む問題解決・アイデア発想のアプローチ60』を選びました。

f:id:nainaistar:20210718173835j:plain

選んだ理由

意思伝達能力の向上したい
思考法を学ぶことで裏付けとなる根拠を盤石にしたい
新しいビジネスを見つけるためのきっかけにしたい

読んだうえでの本の想定ターゲット

副題の「ひらめきを生む問題解決」「アイデア発想のアプローチ」に悩んでいる人にアプローチする本
社会人1-2年目
思考法の概要を知りたい人

読書時間

4時間程度。

内容を読むだけであれば2時間、必要なポイントに絞れば1時間もあれば十分に読み切れると思います。私の場合は、思考法図鑑を読みながら、実務でどうやって活かすかを考えながら読んでいたために4時間かかりました。

感想

内容について

色んな内容が思考法が入っている点は良い点です。しかし、1つ1つの思考法の紹介ページが2ページ、しかも大きめの図で紹介されるので、理解はしやすいのですが内容は薄いです。「思考法図鑑」という本題だけを読み、副題の「ひらめきを生む問題解決・アイデア発想のアプローチ60」を読まずに本を読んだ方にとっては満足ができないものとなります。逆に言うと、副題を求めていた人に取ってはアプローチできる本です。　　私はソフトウェアエンジニアで、基本的には要件定義も企画もしません。そのため、6-7割くらいは新しく思考法図鑑から学べた思考法もありましたが、もし要件定義や企画系の職にいる場合は自然と学べる環境にいるかもしれません。

総評すると、個人的には星5つ中の4つ。若い人には是非とも読んで欲しい。経験を積んだ人には副題の「ひらめきを生む問題解決・アイデア発想のアプローチ60」に困っている場合に限りオススメします。

各章について

5つの章に分かれています。好きな個所から読んで問題ありません。

個人的には副題に直接アプローチができる第2章、第3章を読んで、もし他の章が気になった時にパラパラとめくるような読み方をオススメします。

第1章　思考の基礎体力を高める（メソッド：10種）
第2章　アイデアの発想力を高める（メソッド：12種）
第3章　ビジネス思考力を高める（メソッド：12種）
第4章　プロジェクトの推進力を高める（メソッド：13種）
第5章　分析力を高める（メソッド：13種）

備考

PowerPointテンプレートが提供されていて、すぐに実践できる点は良いですね。思考と行動は両輪であると思考法図鑑でも謳っており、早期の行動を推奨しています。

また、最後に同社が出している「思考を加速させるビジネスフレームワーク一覧」の概要で35個のフレームワークが紹介されています。詳細はこちらの本を読んで欲しいとのことでしょうが、こちらの方が非常に勉強になります。まずはこちらの本を読み、それから満足が出来なければ思考法図鑑を読むと良いのではないでしょうか。

本のリンク

翔泳社リンク www.shoeisha.co.jp

Amazonリンク

終わりに

正直なところ、本題を読んだ期待値とは異なっています。普段から行っていることに対して名前がついているだけ、というパターンもちらほらあります。

この本一冊があれば十分、という訳でもないので「思考法図鑑」という表現より「思考法一覧概要」の方が合っているのではないかと思ってしまいます。しかし、思考法の名前さえわかっていれば検索できますし、参考文献を載せているので、より踏み込んで調べることは可能です。

全員が持つべき良本とまでは言いませんが、チームや組織に1冊あると便利な本だと思います。

この記事がお役に立ちましたら、各種SNSでのシェアや、今後も情報発信しますのでフォローよろしくお願いします。

2021-07-19

私が好きなアーキテクチャ(ポートアンドアダプター)を説明する

設計技術

新人育成用に自分が知っている知識を棚卸するための記事です。なお、解釈が誤っている可能性は十分にあります。

キーワード

ポートアンドアダプター
- ヘキサゴナルアーキテクチャ
ミュータブル/イミュータブル
腐敗防止層

ポートアンドアダプター(ヘキサゴナルアーキテクチャ)とは

f:id:nainaistar:20210717183741p:plain

私がアーキテクチャで意識しているのは、次の点です。

アプリケーションの「内側」と「外側」の区別をつける
「外側」の知識を「内側」に侵入させない
「内側」の知識を「外側」に流出させない

アプリケーションの「内側」と「外側」の区別をつける

私は「内側」「外側」を次の定義で表現しています。

内側
- アプリケーションのビジネスロジック
外側
- アプリケーションで完結できない、実行時例外が発生しやすいロジック
- HTTPを受信するController、DBと接続するRepository、他システムとRESTやSOAPで連携、ファイル操作

この「外側全体」を「ポート」と呼び、ControllerやRepository等の「外側の機能1つ1つ」を「アダプター」と呼びます。

ミュータブルとイミュータブル

ミュータブルはインスタンス生成後に設定変更が可能なこと、イミュータブルは設定変更が不可能なことを指します。基本的にはミュータブルだと、NullPointerExceptionを発生しないように操作順序を意識する必要があったり、思わぬバグを仕込んでしまう可能性があるので、可能な限りイミュータブルにすることが求められます。私が踏んだバグの例だと、ログにクレジットカード番号を出力しないように「***」とマスクしていたのですが、元のインスタンスが書き換えられていたので後続の処理が通らなくなっていました。

ポートアンドアダプターを意識しているコードで単体テストを書いていると「外側」の方が「内側」と比べて、HTTP通信やDBの準備が必要で大変なことが多いです。また、「外側」の機能は自分で開発せずに、Request/Responseのマッピング等をライブラリの機能によって担保していることも多いです。しかし、Request/Responseのマッピングする際には、ライブラリの都合でgetter/setterが定義されていたり、空のコンストラクタが定義されていることを求められることが多々あります。

そうすると、マッピングした項目はミュータブルにせざるを得ません。もちろん、自分で開発すればイミュータブルなインスタンスを作成することはできますが、開発工数には合わないと判断することが多かったです。

ここで伝えたいことは「内側」と比べて「外側」はミュータブルにせざるを得ない状況が多くあるということです。

「外側」の知識を「内側」に侵入させない

「外側」の知識を「内側」に侵入させないことは重要です。

その「外側」の知識を「内側」に侵入させないようにする仕組みとして腐敗防止層があります。腐敗防止層についてはこちらの記事を参照してください。

余計なライブラリ情報を流出させないことも重要です。例えば、JavaのDBアクセスするライブラリにMyBatisがあります。このMyBatisにはSQLのOFFSETとLIMITを纏めたorg.apache.ibatis.session.RowBoundsクラスが存在します。ページングが必要なSQLにて重宝しますが、このクラスはControllerで意識する必要はあるでしょうか。おそらく、ありません。

もちろん、判断によってはControllerでRowBoundsを使用しても問題ありません。しかし、Javaのマルチプロジェクトで運用していると、Controllerプロジェクトの依存関係に明示的にMyBatisを読み込ませる必要があります。もし、今後マルチプロジェクトにしたい等の要望があった時に備えて、各アダプターごとに依存を完結しておくとよいでしょう。

「外側」の知識を「内側」でそのまま使用すると大変なことになります。その例としてミノ駆動様のUserクラス動画があります。動画や資料の通り、「User」をそのまま使用するのは危険です。必ずアプリケーションで必要なモデリングを行い、「内側」では「外側のUserクラス」から翻訳した「内側のUserクラス」を使用するようにしましょう。

クソコード動画「Userクラス」 #DXD2021 pic.twitter.com/JOIIl8IuwS
— ミノ駆動 (@MinoDriven) 2021年4月10日

twitter.com

「内側」の知識を「外側」に流出させない

例えば、メールを送るシステムにデータ連携をする場合、メールの元となるデータ作成ロジックはどこに入れるべきでしょうか。

内側
アダプターのメールシステム

こちらは、「内側」で作成するべきです。どんなメール文面にするか、誰に送るかといった情報は「外側」に流出させるべきではありません。「内側」でデータを作成し、「外側」は「内側」から受け取ったデータをメールシステムに連携できるように加工すると良いでしょう。

例えば、特定のクエリパラメータが存在しないとき、デフォルト値で検索するシステムがあったとします。その場合、デフォルト値で補完するロジックは次のどこに入れるべきでしょうか。

アダプターのController
内側
アダプターのRepository

こちらは判断が分かれます。「内側」と言いたいところですが、API仕様書にデフォルト値で補完する旨を書いているのであれば、そのロジックは「外側」の持ち物なのでアダプターのControllerで行っても良いと考えています。

終わりに

松岡様のQiita記事によると、ポートアンドアダプター（ヘキサゴナルアーキテクチャ）とオニオンアーキテクチャ、クリーンアーキテクチャは本質的に同じものだそうです。個人的にはオニオンアーキテクチャに寄せていきたいのですが、DDDをチーム全員に理解してもらう必要があるので、導入には二の足を踏んでいます。特に私がドメインサービスとアプリケーションサービスの違いを明確に理解していないので不安です。

アーキテクチャに正解はありません。しかし、同一の理解をしておくことで、どこにロジックを入れるべきかを話し合うことができます。心理的安全性を確保して知的コンバットでより良くしていきたいですね。

この記事お役に立ちましたら、各種SNSでのシェアや、今後も情報発信しますのでフォローよろしくお願いします。

参考

類似

腐敗防止層を意識して綺麗なドメインを保ちたい - きり丸の技術日記

f:id:nainaistar:20210717184207p:plain

2021-07-16

Mavenのproxy設定は1つしか有効に設定できない

Java 技術

タイトルの出オチ記事。これを知るためだけに4日くらい無駄にしました。参考先のブログに感謝です。

環境

Maven
- 3.6.0

結論

Mavenでproxyを通す設定は、~/.m2/settings.xmlに設定する必要があります。

ただし、~/.m2/settings.xmlに複数定義できても、設定は1つしか有効にできません。そのため、~/.m2/settings.xmlにhttp, httpsの両方とも設定すると片方だけしか有効になりません。

settings.xmlのproxy設定

項目	設定内容
id	一意な値を設定する
active	settings.xmlで有効にしたいproxy設定。1つしか設定できない
protocol	`http`または`https`
host	プロキシのIPやドメイン
port	プロキシのポート
username	プロキシへのログインユーザ名
password	プロキシへのログインパスワード
nonProxyHosts	プロキシを通さないIPやドメイン

具体的な例としては以下の通りです。

<settings>
    <proxies>
        <proxy>
            <id>id01</id>
            <!-- 1つだけしかActiveにできない -->
            <active>false</active>
            <protocol>http</protocol>
            <host>proxy-domain</host>
            <port>80</port>
            <username>proxyUser</username>
            <password>proxyPass</password>
            <nonProxyHosts>localhost|127.0.0.1</nonProxyHosts>
        </proxy>
        <proxy>
            <id>id02</id>
            <active>true</active>
            <protocol>https</protocol>
            <host>proxy-domain</host>
            <port>80</port>
            <username>proxyUser</username>
            <password>proxyPass</password>
            <nonProxyHosts>localhost|127.0.0.1</nonProxyHosts>
        </proxy>
    </proxies>
</settings>

HTTPもHTTPSも有効にしたい

もしHTTP, HTTPSの両方ともproxy設定も有効にしたい場合は、環境変数のMAVEN_OPSにて、VMの起動オプションに設定する必要があるようです。（未検証）

# Windows
set MAVEN_OPTS=-Dhttp.proxyHost=<host> -Dhttp.proxyPort=<port> -Dhttps.proxyHost=<host> -Dhttps.proxyPort=<port>
# Mac/Linux
export MAVEN_OPTS=-Dhttp.proxyHost=<host> -Dhttp.proxyPort=<port> -Dhttps.proxyHost=<host> -Dhttps.proxyPort=<port>

終わりに

MavenのProxy設定する記事はたくさん見つかりましたが、1つしか設定できないという記事を見つけるのは大変でした。もし、HTTPSだけしか設定していなければここまで苦労しなかったですし、HTTPS, HTTPの順番で設定していたなら最初からうまく行っていたと思います。

proxy設定は難しいですね…。

この記事お役に立ちましたら、各種SNSでのシェアや、今後も情報発信しますのでフォローよろしくお願いします。

参考

f:id:nainaistar:20210715171702p:plain