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

 これ読んだ。

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

 読みながらしたツイート

導入課題を読んで

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

— 松下正嗣 (@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などメインモデルを作ってやり切るのは、それぞれの機能でコア要員に技術スキルと業務分析スキルが両方必要なため、ハードルは高い。

「納品のない受託開発」についての雑感

 こんなツイートをしていたら、

これについては、自分の考えをブログにかくか。 顧問弁護士や顧問税理士のような「顧問プログラマ」という仕事と働きかた http://t.co/d04FRlSC9y

— 松下正嗣 (@masatsugumatsus) April 30, 2014

本が出てしまったので、遅ればせながら、書く。

「納品」をなくせばうまくいく ソフトウェア業界の“常識"を変えるビジネスモデル

ソフトウェアの価値の源泉はソースコードとプログラマ

倉貫さんのブログは以前から読んでいたのだけど、根底にあるのは

「ソフトウェア開発において、価値を生む出すのは、ソースコードであり、それを生み出す 有能なプロフェッショナルとしてのプログラマである。」

という洞察だと思う。

これは、『組織パターン』の「中央の生産者」パターンとしても指摘されている。

組織パターン (Object Oriented SELECTION)

結局仕様書があったとしても、その文脈や顧客のビジョン、仕様の抜け漏れも含めて、ソースコードを生み出すプログラマが理解していなければ良いソースは生み出せない。

「プログラミングは設計である。」

良いソースがなければ、結局、どんなドキュメントもゴミ。

プログラマにとっては、大抵のドキュメントは意味のないものにうつる。

不明確である場合も多いし、不正確だったりもする。最近の言語では、かなり文章のように書けるものを内部設計書、外部設計書、要件定義書に同じようなことを書く必要があり、無駄に感じる。

ビジネス価値を生み出すのが、ソースであり、プログラマであるなら、それを現実のビジネスで費用対効果とプログラマの報酬に直結させる仕組みが、開発プロセスであり、ビジネスモデルなんだろう。

ソニックガーデンのモデルは、プログラマの生産性（工数に対するビジネス価値）を最大にするように設計されているように思う。

その一つの側面が「納品のない受託開発」であり、絞り込んだ技術であり、アジャイルなプロセスなんだろう。

プログラマがなにやらコンサルタントのスキルも持たなければならない、ということで「フルスタックエンジニア」問題と同じような印象を受ける人もいるかもしれないけど、よいコーディングをする、というのは、よい問題解決者であるのとイコールだと思う。

そもそも、コンピュータ黎明期のアメリカは、プログラマが要件を聞いて、書いてたっぽい。下記の本に、プログラマが顧客より立場が上になる例が書かれている。

ワインバーグのシステム行動法 ソフトウェア文化を創る (3)

どちらかというと、ソニックガーデンのプログラマに必要なのは、アプリケーションエンジニアとしてのスキルで、基盤系の知識はクラウドを活用して、職人を抱えなくてもよいようにしている気がする。

既存開発会社の市場を食うか。

現在のソニックガーデンさんのモデルは既存のSI企業と競合しないかもしれないけど、

「ソフトウェア開発において、価値を生む出すのは、ソースコードであり、それを生み出す 有能なプロフェッショナルとしてのプログラマである。」

という洞察はソフトウェアの製品特性に依存するものでない。ここを出発点に、既存のSIの開発について、自分なりに考えてみたい。

• システム特性（社内システム）
• 納品と瑕疵担保責任
• 規模の不経済

システム特性（社内システム）

本の中では、新規事業やコンシューマ向けシステムと相性がいい、とあるが、パッケージ導入した方がいいような基幹システムは別として、大抵の社内システムも、社内ユーザーが顧客みたいなもの。アジャイルに、継続的に改善していく方がフィットするのってかなりある。

ただ、企業内システムで、他システム連携や移行がある場合、受け入れ試験を実施するのが、かなり顧客として負担になる部分もあるね。まあ、それも継続契約の中で解消していけばいい話。顧客としては、そこらへんはPM専門のコンサルタントを使ってもいいかもしれない。

やはり今でも、社内システムに関しては、パブリッククラウドがNGっていう企業も多い。中々難しいけど、最近はDockerやら使えば、環境起因の無駄なコスト増はある程度防げるかも。プログラマからしてみれば、クラウド環境での動作を保証して、デプロイは顧客が責任を持つって形がいいのかな。そこまでやってたら、リーズナブルな価格設定は難しくなるかも。

個人的な意見では、大企業のグループ会社が、グループのプライベートクラウドを利用して、「納品のない受託開発」をやるのが結構いい選択と思っている。課題は、エンジニアの能力とマインドだが。。。

納品と瑕疵担保

• 私見では本で指摘されている問題の多くは「納品」に起因するものではないし、パブリッククラウドでしかできないものではない。通常の製造物と同様な「瑕疵担保責任」を負う事が業務用のソフトウェアの場合そぐわないなら、定額で、顧客資産の開発を進めるという形（変形のSES？）もあり得るだろう。結局、仕様なんて決めきれないのだから、これは、バグか、仕様か、みたいな不毛な議論に工数かけるよりも、継続的に機能追加していくことで培われる「信頼」をベースに修正していった方が双方にとってメリットはあるだろう。（ただ、誰が悪い、という犯人探しをするには、納品というメカニズムは中々便利。）

• 納期がないと、計画が立たない、というのは、ビジネス的なリスクである、という議論は確かにあるが、多分、それは見積もり、ターゲット、コミットメントを混同している。３ヶ月毎にマイルストーンを話し合うというし、もし、発注者がかなり具体的なビジョンを持っていて、ビジネスターゲットが明確なら、ある程度正確な見積もりはできる。コミットメントをしないだけ。どちらかというと、顔の見える、有能な実装者が見積もりを行うのだから、顧客の言われるがままに適当に算出した見積もりよりも正確。発生した問題もアジャイル的に開発するから、早期発見、早期対応ができる。 大規模ではいくらベンダがコミットしても、終盤になってはどんなに残業してもリカバリきかない事も多いのだから、結局は同じこと。リスクを許容し、それをコントロールする能力を信頼するのか、リスクなし、の幻想をそれが破綻するまで見ていたいのか、という問題。もしくは、遅れたとしてもベンダのせいにできるか、できないか、という問題。ビジネス価値を重視するのか、政治的な利得を重視するのか。

ソフトウェア見積り

また、開発中に、顧客がエンジニアの能力に疑問をもっても、今の契約なら、発覚した時点で「ふざけるな、なんとかしろ」と言えばすむ事を、キチンと受け入れ試験をしたり、エンジニアを評価しなければならない分、顧客担当者の負担は増えるかもね。

結局、顧客、エンジニアとして、正直に、信頼し合う関係で、問題が起こったら、お互いに協力しあいましょう、というスタンスにどこまでついてこられるか、という問題、かな。

規模の不経済

さて、ここでやはり問題になるのが、ソフトウェアの規模との関係。エンジニア一人が担当することで、余分な管理コストの発生を防ぎ、保守性の優れた高品質をリーズナブルな価格で提供しているが、それが許されない規模の案件に対して、どういう絵が書けるのか。

ちなみに、少数精鋭チームと大規模開発の問題は、ブルックスの時代から議論されていたらしい。

人月の神話

多分、一人の優秀なプログラマが仕様を理解し、構築までする品質と生産性を基礎数字に、２倍の生産性を出そうとすると、２人ではでずに、３人〜４人くらいは必要になる気がする。人数が増えれば、増えるだけコミュニケーションコストがかかるから。自分たちのために文書も作成する必要がある。その倍の生産性となると、さらに当然８人ではなく、１０人〜１５人。その時点で優秀なプログラマを確保するのが、怪しくなってくる。。。スクラムチームだと、３〜４チームか。この辺りが、保守性の高いコードをつくる限界な気がする。自己組織化チームも限界か。

それ以上だと、多分、コア機能と周辺機能を分けて品質で妥協しつつ、マネジメントを取り入れる必要がでてくるかなあ。

とはいえ、優秀なプログラマが一人でできる生産性の４倍程度となると、相当な規模のアプリケーションを作れるような気がする。２倍程度でも、パッケージ導入しないようなアプリはかなりカバーできんじゃないかなあ。

問題は、一旦、基本機能を作りきってしまったら、それまでの生産性を維持するほどの需要がないから、同じ金額を払い続けるモチベーションが顧客側にないことかなあ。

ただ、既存の開発案件と比べたら、圧倒的にリーズナブルであるはず。

大抵の請負契約は真のリスクを隠して、お金の問題でなく、担当者個人や組織に責任がいかないようになっているだけな気がする。

それを越えて、シビアにリスクとビジネス価値を考える顧客とそれに答えられるエンジニアが増えていけば、価値あるソフトウェアが増え、価値あるエンジニアが評価されるようになって行く未来が描けるかもしれない。

熊とワルツを - リスクを愉しむプロジェクト管理

その時に、自分が生き残れるかは、また、別の話。

書評＋『絶望の裁判所』

長くなりそうだったので、ブログに書く。かなり主観的な感想、うーんと多分人に読ませるものではない。

絶望の裁判所 (講談社現代新書)

官僚組織内部の機能不全というのは、ある程度暴露本がでてくれなきゃ、中々普段接する機会のない人には分からない。

人格批判のような記述があるので、拒絶感ある方もいそうだが、官僚化が進行している組織には、こういった小人物が権力を握るのはよく見られることだと自分は思うので、そこまで歪んだ記述ではないと思う。

「かつては、少なくとも若手は優秀な人材が評価されていた」、という記述がある。官僚的であっても、一応なんとか機能している組織は、そういう傾向がある気がする。

骨のある、実力者のうるさ方は、一定レベルまでは昇格し、組織内部でも実力に不相応な待遇とはいえ、一定の尊敬、待遇を与えられ、若手の教育や危機の際の問題解決に腕を振るう。

多分組織トップも、そういった層がいるから何とかなっていて、自分が取り立てているヒラメ人間は組織の保全以外に役に立たないことを知っている場合が多いのだろう。創業時代の重鎮が残る日本の大企業はそうなんじゃないかな。

多分、本当の官僚化は、ヒラメ人間が勘違いして不遇の実力者を排除しはじめた時なんだろう。

とはいえ、正論をはく真っすぐな気骨のある人材がトップに立てない、組織の管理職には決して人間として尊敬できない人がいるって、多分大抵の人の認識の気がするけど、そうでもない組織もあるらしい。

http://blogs.itmedia.co.jp/magic/2014/03/post-6dc8.html

裁判所の官僚化っていうのが、如何にヤバいか、ってあまり一般の人には分からないかもね。文系の基礎教養として、マクロ経済学の他に、基本的な政治思想と初級法学はあっていいと思う。