ずっと考え続けるということ

この本読んで。一つ、考えたことをメモ。

ヤフーとその仲間たちのすごい研修

この手の現実の課題解決をすることを通じて、参加者の学習と成長を狙うっていうの「アクションラーニング」といわれるもの。GE社のワークアウトっていうのが有名。

GE社のワークアウトは、社内課題の解決をコンサルタント的に選抜されたメンバーが行うもの。リーダーシップ教育の一環。要求される価値観とビジネススキルはある程度共通の水準を求められるし、コミットも要求される。

この研修は、そうとうにバラバラな組織から集められてきているし、どこまで対象の課題にコミットするか、もモチベーション維持が難しいもの。最初の設計から、効果的な提案がどんどん出てくるとは企画者も想定していなかっただろう。

そして、「現実の仕事でも、限られた時間の中で結果を出さなければならないのだから」とまあ、失敗も許容する覚悟で実施したという。

限られた時間で答えを出すこと

この研修そのものは様々な狙いがあるのでそれはいいとして、個人的にあまり魅力的に感じられなかった。

それは「自分自身が参加してもいい提案ができるイメージは湧かない。」という至極私的な理由。

というのは、この「提示されたどんな課題に対しても、限られた時間で答えを出す」っていう所謂コンサルタント的な思考は自分はとても不得手だから。

この研修の参加者も、多分「限られた時間で答えをだす」のが得意な人と不得意な人で、相当スキルレベルの開きがあるように思う。

なぜなら、次に書くようにこの研修の題材になっている「地域振興」について「ずっと考え続けている」人はいないだろうから。

ずっと考え続けるということ

普通の仕事では、コンサルタント的な思考が得意な人が、常にそうでない人を圧倒するとは限らない。というのは、所謂優秀な人のカテゴリに、「ずっと考え続けている人」っていうのがいると思うから。

これは、自分が片足を突っ込んでいるソフトウェアエンジニアの世界の優秀なエンジニアたちを思い浮かべている。彼らはずっと考え続けて、ずっと試行錯誤している。よいソフトウェアとは何か、よい言語とは、よい設計とは、よいマネジメントとは。

思考が深くて、実験を繰り返しているから、技術の進歩にもついていける。部外者が全く新しいもの、異なるものと考えていることに対して、自分なりの答えを素早く導き出すことができる。

深くものを考えない人にとって、「限られた時間で答えをだす」人との違いを区別するのが難しいだろう。

DeNAの南場社長の本で、あっという間にエンジニアがとても使いやすいアプリを作ったって話。あれ、多分、休日とかにいろいろ試行錯誤して似たようなもの作ったことがあったんだと思うんだよね。。。

ご本人がどうとらえているのかは分からない。でも、本からはそういう認識は読み取れなかった。

不格好経営―チームDeNAの挑戦

そして、彼らは年をとると、素晴らしい教師になる。「限られた時間で答えをだす」だけしかやってこなかった人はよい教師には多分なれない。

もちろん、この２つの思考タイプは排他的なものではないし、両方備えている人はもちろんいるが、傾向のひとつとして、自分のキャリアを考えたり、人を評価したりするときにちょっと考えてもいいものだと思う。

独断と偏見に基づく非プログラマ向けIT本

こんな本あったので。。。

これはちょっと酷い本だなあ。。。千円以上したけど、勉強料か。。。 次の商品を購入しました：清水 亮 『文系でも知っておきたいプログラミングとプログラマーのこと』 via @AmazonJPKindle http://t.co/IsMxpT1KmK

— 松下正嗣 (@masatsugumatsus) August 3, 2015

個人的なお勧め本を

 ITの基礎知識

ディジタル作法 −カーニハン先生の「情報」教室−

ソフトウェアの20世紀―ヒトとコンピュータの対話の歴史

プログラマとはどんな人か

技術わからなくてもなんとなくわかるもの

プログラミングの心理学 25周年記念版

システム管理者の眠れない夜【新装改訂版】―本当に価値のあるシステムを求めて―

ピープルウエア 第3版

闘うプログラマー[新装版]

オープンソースの思想とかもわかる！

スティーブズ（１）

アート・オブ・コミュニティ ―「貢献したい気持ち」を繋げて成果を導くには (THEORY/IN/PRACTICE)

プロマネ

反常識の業務改革ドキュメント プロジェクトファシリテーション<増補新装版>

アート・オブ・プロジェクトマネジメント ―マイクロソフトで培われた実践手法 (THEORY/IN/PRACTICE)

『研修設計マニュアル』読後感

 これ読んだ。

研修設計マニュアル: 人材育成のためのインストラクショナルデザイン

 読みながらしたツイート

導入課題を読んで

研修設計マニュアル読んでいる。本自体がきちんと設計されていて好感が持てる。

— 松下正嗣 (@masatsugumatsus) May 6, 2015

第１章、第２章を読んで

概念を識別させる練習問題もいい。何故か、こういうのはあまり見ない。普通にIDやっていたら論理的帰結として出てくるものと思うけど。。。

— 松下正嗣 (@masatsugumatsus) May 6, 2015

第３章〜第５章を読んで

KPIとしての読書量っていいな。本当。

— 松下正嗣 (@masatsugumatsus) May 6, 2015

第６章〜第７章を読んで

富士通ラーニングメディアは、研修の事前テストを公開しているから参考にするといい。IT系の研修会社はIDをそれなりに取り入れている場合が多い。それで全てが解決するわけでもないが。

— 松下正嗣 (@masatsugumatsus) May 6, 2015

学習目標の例はいいね。複雑な行動の場合、成果物のレビュー観点を洗い出して、それを学習目標に設定するといい。そこから下位スキル分析ができる。

— 松下正嗣 (@masatsugumatsus) May 6, 2015

Eラーニングをナレッジマネジメントの一貫としてとらえるというのは賛成。集合研修も含めて。LMSとグループウェア辺りを統合できればいい。そういう製品はあるがあまり活用事例ってないんだよね。

— 松下正嗣 (@masatsugumatsus) May 6, 2015

パッケージを入れるより、安価な形でアジャイルに作っていった方が実りがあるのかも。

— 松下正嗣 (@masatsugumatsus) May 6, 2015

訂正。活用事例を自分は知らない。

— 松下正嗣 (@masatsugumatsus) May 6, 2015

プログラミング研修をeラーニングのような個人の学習に還元してしまうのは、ちと、慎重になった方がいい。ワインバーグの『プログラミングの心理学』にあるような相互交流はプログラミングという行為の重要な一部

— 松下正嗣 (@masatsugumatsus) May 6, 2015

感想

人材育成担当になって、当惑している人には、ちと盛り込みすぎで敷居が高い気がする。下記の本の方が良い。

企業内人材育成入門

ある程度わかってきた人が「研修にこだわらないやり方」を模索する時にはいい本。そういうことを書いている本はあまりない。

この本に書いていないこと

どうやって設計するのか、つまり、学習対象の分析については薄いので、別の本を参照する必要がある。

個人的には研修に限らず、人材育成施策立案が有効か否かを分けるポイントは、「学習対象への理解の深さ」だと思っている。

これはいいシステムを設計できるエンジニアがシステム化対象の業務の深い理解が必要とされることと丁度同じ関係。

だから、現場のハイパフォーマーが必ずしも適任ではないし、そのレベルまで必要というわけでもないが、彼らとガチで議論できるだけの知識と技能を教育設計者は持っているべき。

逆に、幾つかの分野でそのレベルの現場で使われるスキルに対する理解がない人がいくらIDを勉強してもあまり効果的ではないと思う。

 

PBLとかアクションラーニングとか、その辺

アクションラーニングやPBL（Project-Based-Learning）の肝は「経験の設計」だ。

種々の制約から、アクションラーニングやPBLの対象となる経験がそのまま現実世界（real-world）と同じ文脈を用意できることは稀。なんらかの形での妥協が必要になる。その際、その妥協が学習者が体験する経験にどういう影響を与えているのか、期待する学習効果をあげているのかを注意深く検討しなければならない。

妥協した結果、学習効果をほとんど持たなくなってしまう場合も多くあると思われる。むしろ、現実世界で必要となるスキル（どのようにスキルを活用するのか、といういわゆるメタスキルも含む）やマインドの分析/定義を行うことを断念し、PBLの名目で「あたかも実践的」なだけの研修でごまかしていることって多いんではないだろうか。。。

結局のところ、必要なのは分析であり、仮説と検証。体感型の研修で学習目標を明確にしないものであっても「現実世界の意思決定構造」の分析は不可欠のはず。

新人に送る独断と偏見に基づいた「よいソフトウェアエンジニアになる」ために外せない本・著者一覧

自分がよいエンジニアかどうかは別にして。

基本Java屋さん向け。今思いついたもの、、、。

著者

代表的な本を挙げる。

G.M.ワインバーグ

ソフトウェア業界のマスター・ヨーダ。ソフトウェア開発とは何かを教えてくれるはず

ライト、ついてますか―問題発見の人間学

スーパーエンジニアへの道―技術リーダーシップの人間学

システムづくりの人間学―計算機システムの分析と設計を再考する

要求仕様の探検学―設計に先立つ品質の作り込み

マーチン・ファウラー

オブジェクト指向設計・開発についての教祖。オブジェクト指向言語を学ぶならとりあえず、読むべし。

新装版 リファクタリング―既存のコードを安全に改善する― (OBJECT TECHNOLOGY SERIES)

エンタープライズ アプリケーションアーキテクチャパターン (Object Oriented Selection)

 スティーブ・マコネル

プログラミングを学ぶなら、読め！Must 

Code Complete 第2版 上　完全なプログラミングを目指して

CODE COMPLETE 第2版 下

  

DB設計

理論から学ぶデータベース実践入門 ~リレーショナルモデルによる効率的なSQL (WEB+DB PRESS plus)

SQL

SQL実践入門──高速でわかりやすいクエリの書き方 (WEB+DB PRESS plus)

 書籍

Effective Java

 ま、基本だね。

EFFECTIVE JAVA 第2版 (The Java Series)

 オブジェクト指向のこころ

GoF本よりもためになる。

オブジェクト指向のこころ (SOFTWARE PATTERNS SERIES)

 アジャイルソフトウェア開発の奥義

通称「ボブおじさん」の秘伝書。付録の論文は必ず読むべし.「プログラミングは設計である！！！」

アジャイルソフトウェア開発の奥義 第2版 オブジェクト指向開発の神髄と匠の技

ドメイン駆動設計

最近流行ってるけど、流行りに終らない。

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

実践ドメイン駆動設計

オブジェクト指向開発の一つの到達点

実践ドメイン駆動設計 (Object Oriented Selection)

珠玉のアルゴリズム

なんだかんだ言って必要。

珠玉のプログラミング 本質を見抜いたアルゴリズムとデータ構造

人月の神話

「銀の弾丸」の意味は知っとこう。

人月の神話【新装版】

 

ソフトウェアシステムアーキテクチャ構築の原理

古典になると思う。 

ソフトウェアシステムアーキテクチャ構築の原理 第2版 ITアーキテクトの決断を支えるアーキテクチャ思考法

時を超えた建設の道

デザインパターンの考え方を学ぶ

時を超えた建設の道

一般システム思考入門

ワインバーグの本だが、 改めて紹介。一般システム理論は、ソフトウェアエンジニアにはとても有益なアイデアにあふれていると思う。

一般システム思考入門

おまけ

他言語を学ぶことも大事。 

プログラミングGROOVY

プログラミング言語 Ruby

Scalaスケーラブルプログラミング第2版

追加

達人プログラマー

達人プログラマー―システム開発の職人から名匠への道

実践テスト駆動開発 テストに導かれてオブジェクト指向ソフトウェアを育てる (Object Oriented SELECTION)

独断と偏見に基づく人材育成に関わる人への推薦図書

人材育成を考える

人を伸ばす力―内発と自律のすすめ

新・人が学ぶということ―認知学習論からの視点

学校と社会 (岩波文庫)

キー・コンピテンシー

研修設計

はじめてのインストラクショナルデザイン

変革を生む研修のデザイン―仕事を教える人への活動理論

ファシリテーション 

会議が絶対うまくいく法

ファシリテーション入門 (日経文庫)

 コーチング

決定版　部下を育てるコーチング (朝日文庫)

インナーワーク―あなたが、仕事が、そして会社が変わる。君は仕事をエンジョイできるか!

インストラクション

CompTIA CTT+

http://www.comptia.jp/pdf/CTTplus_jp_ver1.1.pdf

結城浩さんのWeb記事

教えるときの心がけ

https://note.mu/hyuki/m/md7abcdf8eaf5

 

プロジェクトマネジメント

アート・オブ・プロジェクトマネジメント ―マイクロソフトで培われた実践手法 (THEORY/IN/PRACTICE)

業務改革の教科書―成功率9割のプロが教える全ノウハウ

リーダーシップ

マネジメント[エッセンシャル版] - 基本と原則

EQリーダーシップ 成功する人の「こころの知能指数」の活かし方

スーパーエンジニアへの道―技術リーダーシップの人間学

巨象も踊る

自省録 (岩波文庫)

組織開発

ダイアローグ 対立から共生へ、議論から対話へ

学習する組織――システム思考で未来を創造する

レイヤー設計とか、オブジェクト指向とか、DDDとか、その辺

自分の指向としては、技術の勉強というとDDDとかOODとか、そういう抽象的方面が好きなのだが、オブジェクト指向否定論もあることは承知している。

---------------追記 2020/09/27

この記事は「ユーザーのメンタルモデルを反映させる」というMVCの本来の設計思想を捉えていません。ただ、巷に流布しているものを元に考えた記事としては資料的には無価値ではないと思いますので、ログとして残しときます。

MVCの本来の考えはOOUIの本や、コプリエンのLean Architecture本が良さそう

-------------------------------

過剰設計の落とし穴

実際、レイヤー構造や業務モデルを頑張って作っているが、実装時に足かせになったり、プログラマがよく規約や方針を理解できずに、ごちゃごちゃに作り、余計に複雑になってしまったりするのは、色々聞く。（自分はこれをやりがち）

また、手続き型でやっていても、所謂「共通処理」にしたが、仕様変更や性能問題が発生し、共通処理が恐ろしく複雑になったりすることもある。そういう時は、コピペの方がまし、という判断もあり得る。

とは言え、フレームワークを使っている時点でモジュール化やオブジェクト指向の恩恵を受けているわけなので、そういうビジョンを全く否定するのはどうかと思う。開発体制やプロセスの現実を無視して理想を追求しても、問題しか起こさないっていうのは当然として。

改めてレイヤードアーキテクチャについて

最近考えているアプリケーションのレイヤードアーキテクチャについて思うところがあるので書く。一つの観点はドメイン知識はどこに表現されるのか。

よく新人研修とかでWebアプリケーションは、MVCで作るべき、と教わる。技術的には

シンプルなMVC

M モデル：POJO。

V ビュー：UI担当。Web技術に依存。JSP

C コントローラ：サーブレット、もしくはフレームワークが提供するコントローラ。Web技術に依存。

で、ここにデータベースアクセスが加わるとDAOパターンを適用する。

DAOパターンはデータソースにアクセスするDAOと取得したデータであるDTOのセット。Daoパターンでは本来はデータベースに依存しないでデータソースからオブジェクトを取得するもののはずだが、テーブルを意識したインターフェースしか提供していない場合が多い。当然、DTOもテーブル構造に依存する。本来のDAOパターンに翻訳するとDTOはデータソースに依存せざるを得ないだろう。

ここで、DTOはモデルなのか、という話がでてくる。

トランザクションスクリプトなら、ビジネスロジックは手続き的なスクリプトで記述されるため、モデルの構造はそれほど気にしない。だから、DTOをそのままコントローラであつかっても問題ない。

この場合、

MVCWithDAO

M モデル：DTOとDAO。データソースに依存。データ取得ロジックにドメイン知識が表現される。

V ビュー：UI担当。Web技術に依存。JSPとか

C コントローラ：サーブレット、もしくはフレームワークが提供するコントローラ。Web技術に依存。DTOを処理するスクリプトにドメイン知識が表現される。

上記の場合、コントローラーの責務が大きすぎるので、少し改良する。

MVCSwithDAO

M モデル：DTOとDAO。データソースに依存。データ取得ロジックにドメイン知識が表現される。

V ビュー：UI担当。Web技術に依存。JSPとか

C コントローラ：サーブレット、もしくはフレームワークが提供するコントローラ。Web技術に依存。

C’ サービス：コントローラからユーザーからのインタラクション（httpリクエスト）毎に呼び出される。DTOを処理するスクリプトにドメイン知識が表現される。

上記のパターンは、PoEEAのサービスレイヤにかなり近いのではないかと思う。ここまで来ると、ある程度、レイヤーに割り振ることができる。

MVCSwithDAO(レイヤー追記)

M モデル：DTOとDAO。データソースに依存。インフラ層（永続化層）。データ取得インタフェースにドメイン知識が表現される。

V ビュー：UI担当。Web技術に依存。JSPとか。UI層

C コントローラ：サーブレット、もしくはフレームワークが提供するコントローラ。Web技術に依存。アプリケーション層。

C’ サービス：コントローラからユーザーからのインタラクション（httpリクエスト）毎に呼び出される。ドメイン層。DTOを処理するスクリプトにドメイン知識が表現される。

上記のドメイン層のサービスは複数処理に分割できる。データベースをキッチリ固めれば、個々のプログラマが考える事が限定される。ドメイン知識はサービスに集約されているので、デバッグ時の可読性もそれなり。ただ、複雑な業務では、サービスが異常に複雑化するし、共通部分を抽出することが非常に難しい。

大抵のSI屋のプロジェクトではこうやっているんじゃないかな。

ただ、これはファウラーのいう「ドメインモデル貧血症」。

MVCSwithDAOにちょっと、工夫をするとかなり改善できると思う。DTOのカラムにValueObjectを利用し、DTOに振舞いを持たせる。これはMyBatisやDoma2などのORMフレームワークとの相性もいい。残念ながら、JPAは微妙。

MVCSwithDAO2

M モデル：RichDTOとDAO。データソースに依存。インフラ層（永続化層）。データ取得インタフェース,DTOが持つサービス、バリューオブジェクトにドメイン知識が表現される。

V ビュー：UI担当。Web技術に依存。JSPとか。UI層

C コントローラ：サーブレット、もしくはフレームワークが提供するコントローラ。Web技術に依存。アプリケーション層。

C’ サービス：コントローラからユーザーからのインタラクション（httpリクエスト）毎に呼び出される。ドメイン層。DTOを処理するスクリプトにドメイン知識が表現される。

pureなドメインモデルから見て足りないところは、モデルの構造がデータソースの構造に制約されてしまうこと。また、ファーストクラスコレクションとか、イミュータブルなEntityとかそういうのは使いにくい。ただ、構造がシンプルであるため、たくさんの開発者が一斉に開発する場合には、かなり有効と思う。変な委譲の連鎖で処理が追いにくくなるリスクも少ない。プロジェクト進行中に、アーキテクチャのガバナンスが弱まっても最低限の品質は保たれる可能性が高い。

データベースの変更には弱いので、DOAで開発すべきと思う。

ActiveRecord

自分の中では、ActiveRecordは上記のパターンMVCSwithDAO2とかなり近いと思う。ただ、ActiveRecordはテーブル構造がモデルにそのまま反映されてしまうのに対して、DAOを１枚使うことで、柔軟になる。ちなみに、自分はJPAとActiveRecordは使う側にとって、殆ど違いはないと思っている。Spring のCrudRepositoryは自分の中ではDAO。JPAのEntityはDTO。

非正規化をやっていたり、過去の遺産のカラムが色々ある場合はJPAやActiveRecordを利用するのは、やめた方がいいと思う。

じゃあ、ここにPureなドメインモデルを導入するとどうなるのか。結構整理が難しい。ちなみに、Pureなドメインモデルのメリットはモデルがテーブル構造などのデータソースが持つ構造や複雑性から自由になること。

ドメインモデル

V ビュー：UI担当。Web技術に依存。JSPとか。UI層

C コントローラ：サーブレット、もしくはフレームワークが提供するコントローラ。Web技術に依存。アプリケーション層。

M ドメインモデル:データソースにも、アプリケーション層にも依存しない。純粋なドメイン知識の表現。

I インフラ:データソースへのアクセス等を提供する。

ドメインモデルとしてのRepository

DDD本にあるRepositoryはEntityのCRUDなどを提供する。その意味で、DAOに近いし、実装内容は殆ど同じ。多分、DAOパターンが書かれたころは、基本はデータソースに依存しないEntityを提供する役割を持たせるもので、同じ概念だったのだろうと思っている。

自分の中での整理は、DAOが扱うオブジェクトはデータソースに依存し、Repositoryが扱うオブジェクトはデータソースに依存しない純粋なPOJO。

gist35d6d4bfed3fe9d1615f

純粋なドメイン層と言えるのは、Repositoryのインタフェースまでで、実装はデータソースに依存せざるを得ない。

アプリケーション層でRepositoryは呼べるのか？

Java界隈では、アーキテクチャの一つの定石として、コントローラからはRepositoryを呼んではいけない、っていうのがある。（これは海外でもあるっぽい。）代わりにServiceを呼ぶべきであると。アーキテクチャ設計でのServiceって言葉はドメインって言葉と同じく色んな使われ方をしているので、解釈は難しいが、自分の意見は下記。

・ここでいうサービスがPoEEAにおけるServiceLayerなら、同意。そもそも、ドメインオブジェクトのインタラクションはServiceLayerに委譲するので、Repositoryどころか、他のEntityの振舞いとかドメイン層の振舞いはどれもやってはいけないはず。コントローラの役割はServiceLayerの結果をビューに渡すなどの処理のみしか許されていない。（と自分は思っている。）

・ServiceがDDDにあるような1ドメインモデルとしてのServieならRepository禁止はDAOと混同しているからで、純粋なドメインモデルとしてのRepositoryはコントローラで呼んでもいいはず。Serviceをかぶせることを強制してしまうと、それこそ、どこで何をやっているのか分からなくなる。

一般的なEntity問い合わせの責務はRepositoryに集約されるべき。業務ルール上、フィルタ等が必要なら、Repositoryのインタフェースでそれを表現するか、Repositoryで取得した後、適切なAggregateなり、Serviceなりがフィルタするインタラクションをコントローラで実装すればいい。

ドメインモデルのインタラクションがコントローラで書かれようと、PoEEAにおけるServiceLayerで書かれようと、ビジネスロジックの重要部分が1モジュールのコードに表現されていなければいけないと思う。

フレームワークが前提としているのは？？？

Seaser2にしろ、Springにしろ、基本的にフレームワークが前提としているのは、自分の整理におけるMVCSwithDAO2だと思う。個人的にもこれが現実解だと思う。Pureなどメインモデルを作ってやり切るのは、それぞれの機能でコア要員に技術スキルと業務分析スキルが両方必要なため、ハードルは高い。