新人に送る独断と偏見に基づいた「よいソフトウェアエンジニアになる」ために外せない本・著者一覧
自分がよいエンジニアかどうかは別にして。
基本Java屋さん向け。今思いついたもの、、、。
著者
代表的な本を挙げる。
G.M.ワインバーグ
ソフトウェア業界のマスター・ヨーダ。ソフトウェア開発とは何かを教えてくれるはず
- 作者: ドナルド・C・ゴース,G.M.ワインバーグ,木村泉
- 出版社/メーカー: 共立出版
- 発売日: 1987/10/25
- メディア: 単行本
- 購入: 53人 クリック: 509回
- この商品を含むブログ (193件) を見る
システムづくりの人間学―計算機システムの分析と設計を再考する
- 作者: G.M.ワインバーク,木村泉
- 出版社/メーカー: 共立出版
- 発売日: 1986/07/01
- メディア: 単行本
- 購入: 2人 クリック: 3回
- この商品を含むブログ (4件) を見る
- 作者: D.C.ゴーズ,G.M.ワインバーグ,Donald C. Gause,Gerald M. Weinberg,ヤナ川志津子,黒田純一郎
- 出版社/メーカー: 共立出版
- 発売日: 1993/08
- メディア: 単行本
- 購入: 5人 クリック: 24回
- この商品を含むブログ (25件) を見る
マーチン・ファウラー
オブジェクト指向設計・開発についての教祖。オブジェクト指向言語を学ぶならとりあえず、読むべし。
新装版 リファクタリング―既存のコードを安全に改善する― (OBJECT TECHNOLOGY SERIES)
- 作者: Martin Fowler,児玉公信,友野晶夫,平澤章,梅澤真史
- 出版社/メーカー: オーム社
- 発売日: 2014/07/26
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (6件) を見る
エンタープライズ アプリケーションアーキテクチャパターン (Object Oriented Selection)
- 作者: マーチン・ファウラー,長瀬嘉秀,株式会社テクノロジックアート
- 出版社/メーカー: 翔泳社
- 発売日: 2005/04/21
- メディア: 単行本
- 購入: 10人 クリック: 635回
- この商品を含むブログ (142件) を見る
スティーブ・マコネル
プログラミングを学ぶなら、読め!Must
Code Complete 第2版 上 完全なプログラミングを目指して
- 作者: スティーブマコネル
- 出版社/メーカー: 日経BP社
- 発売日: 2014/04/02
- メディア: Kindle版
- この商品を含むブログ (8件) を見る
- 作者: スティーブマコネル,Steve McConnell,クイープ
- 出版社/メーカー: 日経BP社
- 発売日: 2005/03/26
- メディア: 単行本
- 購入: 16人 クリック: 193回
- この商品を含むブログ (162件) を見る
DB設計
理論から学ぶデータベース実践入門 ~リレーショナルモデルによる効率的なSQL (WEB+DB PRESS plus)
- 作者: 奥野幹也
- 出版社/メーカー: 技術評論社
- 発売日: 2015/03/10
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (17件) を見る
SQL実践入門──高速でわかりやすいクエリの書き方 (WEB+DB PRESS plus)
- 作者: ミック
- 出版社/メーカー: 技術評論社
- 発売日: 2015/04/11
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (1件) を見る
書籍
Effective Java
ま、基本だね。
EFFECTIVE JAVA 第2版 (The Java Series)
- 作者: Joshua Bloch,柴田芳樹
- 出版社/メーカー: 丸善出版
- 発売日: 2014/03/11
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (8件) を見る
オブジェクト指向のこころ
GoF本よりもためになる。
オブジェクト指向のこころ (SOFTWARE PATTERNS SERIES)
- 作者: アラン・シャロウェイ,ジェームズ・R・トロット,村上雅章
- 出版社/メーカー: 丸善出版
- 発売日: 2014/03/11
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (4件) を見る
アジャイルソフトウェア開発の奥義
通称「ボブおじさん」の秘伝書。付録の論文は必ず読むべし.「プログラミングは設計である!!!」
アジャイルソフトウェア開発の奥義 第2版 オブジェクト指向開発の神髄と匠の技
- 作者: ロバート・C・マーチン,瀬谷啓介
- 出版社/メーカー: ソフトバンククリエイティブ
- 発売日: 2008/07/01
- メディア: 大型本
- 購入: 18人 クリック: 586回
- この商品を含むブログ (71件) を見る
ドメイン駆動設計
最近流行ってるけど、流行りに終らない。
エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)
- 作者: エリック・エヴァンス,今関剛,和智右桂,牧野祐子
- 出版社/メーカー: 翔泳社
- 発売日: 2011/04/09
- メディア: 大型本
- 購入: 19人 クリック: 1,360回
- この商品を含むブログ (130件) を見る
実践ドメイン駆動設計
オブジェクト指向開発の一つの到達点
実践ドメイン駆動設計 (Object Oriented Selection)
- 作者: ヴァーン・ヴァーノン,高木正弘
- 出版社/メーカー: 翔泳社
- 発売日: 2015/03/17
- メディア: 大型本
- この商品を含むブログ (2件) を見る
珠玉のアルゴリズム
なんだかんだ言って必要。
珠玉のプログラミング 本質を見抜いたアルゴリズムとデータ構造
- 作者: Jon Bentley,小林健一郎
- 出版社/メーカー: 丸善出版
- 発売日: 2014/02/28
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (1件) を見る
人月の神話
「銀の弾丸」の意味は知っとこう。
- 作者: Jr Frederick P. Brooks,滝沢徹,牧野祐子,富澤昇
- 出版社/メーカー: 丸善出版
- 発売日: 2014/04/22
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (9件) を見る
ソフトウェアシステムアーキテクチャ構築の原理
古典になると思う。
ソフトウェアシステムアーキテクチャ構築の原理 第2版 ITアーキテクトの決断を支えるアーキテクチャ思考法
- 作者: ニック・ロザンスキ,オウェン・ウッズ,榊原彰,牧野祐子
- 出版社/メーカー: SBクリエイティブ
- 発売日: 2014/09/26
- メディア: 大型本
- この商品を含むブログを見る
時を超えた建設の道
デザインパターンの考え方を学ぶ
- 作者: クリストファーアレグザンダー,Christopher Alexander,平田翰那
- 出版社/メーカー: 鹿島出版会
- 発売日: 1993/10
- メディア: 単行本
- 購入: 4人 クリック: 33回
- この商品を含むブログ (16件) を見る
一般システム思考入門
ワインバーグの本だが、 改めて紹介。一般システム理論は、ソフトウェアエンジニアにはとても有益なアイデアにあふれていると思う。
- 作者: ジェラルド M.ワインバーグ,松田武彦,増田伸爾
- 出版社/メーカー: 紀伊國屋書店
- 発売日: 1979/06
- メディア: 単行本
- 購入: 1人 クリック: 22回
- この商品を含むブログ (11件) を見る
おまけ
他言語を学ぶことも大事。
- 作者: 関谷和愛,上原潤二,須江信洋,中野靖治
- 出版社/メーカー: 技術評論社
- 発売日: 2011/07/06
- メディア: 単行本(ソフトカバー)
- 購入: 6人 クリック: 392回
- この商品を含むブログ (155件) を見る
- 作者: まつもとゆきひろ,David Flanagan,卜部昌平(監訳),長尾高弘
- 出版社/メーカー: オライリージャパン
- 発売日: 2009/01/26
- メディア: 大型本
- 購入: 21人 クリック: 356回
- この商品を含むブログ (128件) を見る
- 作者: Martin Odersky,Lex Spoon,Bill Venners,羽生田栄一,水島宏太,長尾高弘
- 出版社/メーカー: インプレスジャパン
- 発売日: 2011/09/27
- メディア: 単行本(ソフトカバー)
- 購入: 12人 クリック: 235回
- この商品を含むブログ (45件) を見る
追加
達人プログラマー
- 作者: アンドリューハント,デビッドトーマス,Andrew Hunt,David Thomas,村上雅章
- 出版社/メーカー: ピアソンエデュケーション
- 発売日: 2000/11
- メディア: 単行本
- 購入: 42人 クリック: 1,099回
- この商品を含むブログ (349件) を見る
実践テスト駆動開発 テストに導かれてオブジェクト指向ソフトウェアを育てる (Object Oriented SELECTION)
- 作者: Steve Freeman,Nat Pryce,和智右桂,高木正弘
- 出版社/メーカー: 翔泳社
- 発売日: 2012/09/14
- メディア: 大型本
- 購入: 4人 クリック: 262回
- この商品を含むブログ (30件) を見る
独断と偏見に基づく人材育成に関わる人への推薦図書
人材育成を考える
- 作者: エドワード・L.デシ,リチャードフラスト,桜井茂男
- 出版社/メーカー: 新曜社
- 発売日: 1999/06/10
- メディア: 単行本
- 購入: 9人 クリック: 77回
- この商品を含むブログ (23件) を見る
- 作者: ドミニク・S.ライチェン,ローラ・H.サルガニク,立田慶裕,今西幸蔵,岩崎久美子,猿田祐嗣,名取一好,野村和,平沢安政
- 出版社/メーカー: 明石書店
- 発売日: 2006/06/02
- メディア: 単行本
- 購入: 1人 クリック: 16回
- この商品を含むブログ (7件) を見る
研修設計
- 作者: ウォルターディック,ジェームス・O.ケアリー,ルーケアリー,Walter Dick,James O. Carey,Lou Carey,角行之
- 出版社/メーカー: ピアソンエデュケーション
- 発売日: 2004/08
- メディア: 単行本
- 購入: 1人 クリック: 13回
- この商品を含むブログ (19件) を見る
- 作者: ユーリアエンゲストローム,Yrj¨o Engestr¨om,松下佳代,三輪建二
- 出版社/メーカー: 鳳書房
- 発売日: 2010/12
- メディア: 単行本
- クリック: 9回
- この商品を含むブログ (5件) を見る
ファシリテーション
- 作者: マイケル・ドイル,デイヴィッド・ストラウス,斎藤聖美
- 出版社/メーカー: 日本経済新聞社
- 発売日: 2003/06/21
- メディア: 単行本
- 購入: 2人 クリック: 28回
- この商品を含むブログ (26件) を見る
コーチング
インナーワーク―あなたが、仕事が、そして会社が変わる。君は仕事をエンジョイできるか!
- 作者: W.ティモシーガルウェイ,W.Timothy Gallwey,後藤新弥
- 出版社/メーカー: 日刊スポーツ出版社
- 発売日: 2003/05
- メディア: 単行本
- クリック: 8回
- この商品を含むブログ (7件) を見る
インストラクション
CompTIA CTT+
http://www.comptia.jp/pdf/CTTplus_jp_ver1.1.pdf
結城浩さんのWeb記事
https://note.mu/hyuki/m/md7abcdf8eaf5
プロジェクトマネジメント
アート・オブ・プロジェクトマネジメント ―マイクロソフトで培われた実践手法 (THEORY/IN/PRACTICE)
- 作者: Scott Berkun,村上雅章
- 出版社/メーカー: オライリー・ジャパン
- 発売日: 2006/09/07
- メディア: 単行本(ソフトカバー)
- 購入: 20人 クリック: 361回
- この商品を含むブログ (184件) を見る
リーダーシップ
- 作者: ピーター・F・ドラッカー,上田惇生
- 出版社/メーカー: ダイヤモンド社
- 発売日: 2001/12/14
- メディア: 単行本
- 購入: 210人 クリック: 8,094回
- この商品を含むブログ (431件) を見る
EQリーダーシップ 成功する人の「こころの知能指数」の活かし方
- 作者: ダニエルゴールマン,リチャードボヤツィス,アニーマッキー,土屋京子
- 出版社/メーカー: 日本経済新聞社
- 発売日: 2002/06/25
- メディア: 単行本
- 購入: 5人 クリック: 45回
- この商品を含むブログ (28件) を見る
- 作者: ルイス・V・ガースナー,山岡洋一,高遠裕子
- 出版社/メーカー: 日本経済新聞社
- 発売日: 2002/12/02
- メディア: 単行本
- 購入: 22人 クリック: 313回
- この商品を含むブログ (94件) を見る
- 作者: マルクスアウレーリウス,神谷美恵子
- 出版社/メーカー: 岩波書店
- 発売日: 2007/02/16
- メディア: 文庫
- 購入: 21人 クリック: 118回
- この商品を含むブログ (152件) を見る
組織開発
- 作者: ピーター M センゲ,Peter M. Senge,枝廣淳子,小田理一郎,中小路佳代子
- 出版社/メーカー: 英治出版
- 発売日: 2011/06/22
- メディア: 単行本
- 購入: 3人 クリック: 89回
- この商品を含むブログ (33件) を見る
レイヤー設計とか、オブジェクト指向とか、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を1枚使うことで、柔軟になる。ちなみに、自分は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。
純粋なドメイン層と言えるのは、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
本が出てしまったので、遅ればせながら、書く。
「納品」をなくせばうまくいく ソフトウェア業界の“常識"を変えるビジネスモデル
- 作者: 倉貫義人
- 出版社/メーカー: 日本実業出版社
- 発売日: 2014/06/12
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (1件) を見る
ソフトウェアの価値の源泉はソースコードとプログラマ
倉貫さんのブログは以前から読んでいたのだけど、根底にあるのは
「ソフトウェア開発において、価値を生む出すのは、ソースコードであり、それを生み出す 有能なプロフェッショナルとしてのプログラマである。」
という洞察だと思う。
これは、『組織パターン』の「中央の生産者」パターンとしても指摘されている。
組織パターン (Object Oriented SELECTION)
- 作者: James O. Coplien,Neil B.Harrison,ジェームス・コプリエン,ニール・ハリソン,和智右桂
- 出版社/メーカー: 翔泳社
- 発売日: 2013/08/06
- メディア: 大型本
- この商品を含むブログ (13件) を見る
結局仕様書があったとしても、その文脈や顧客のビジョン、仕様の抜け漏れも含めて、ソースコードを生み出すプログラマが理解していなければ良いソースは生み出せない。
「プログラミングは設計である。」
良いソースがなければ、結局、どんなドキュメントもゴミ。
プログラマにとっては、大抵のドキュメントは意味のないものにうつる。
不明確である場合も多いし、不正確だったりもする。最近の言語では、かなり文章のように書けるものを内部設計書、外部設計書、要件定義書に同じようなことを書く必要があり、無駄に感じる。
ビジネス価値を生み出すのが、ソースであり、プログラマであるなら、それを現実のビジネスで費用対効果とプログラマの報酬に直結させる仕組みが、開発プロセスであり、ビジネスモデルなんだろう。
ソニックガーデンのモデルは、プログラマの生産性(工数に対するビジネス価値)を最大にするように設計されているように思う。
その一つの側面が「納品のない受託開発」であり、絞り込んだ技術であり、アジャイルなプロセスなんだろう。
プログラマがなにやらコンサルタントのスキルも持たなければならない、ということで「フルスタックエンジニア」問題と同じような印象を受ける人もいるかもしれないけど、よいコーディングをする、というのは、よい問題解決者であるのとイコールだと思う。
そもそも、コンピュータ黎明期のアメリカは、プログラマが要件を聞いて、書いてたっぽい。下記の本に、プログラマが顧客より立場が上になる例が書かれている。
ワインバーグのシステム行動法 ソフトウェア文化を創る (3)
- 作者: G.M.ワインバーグ,大野[とし]郎
- 出版社/メーカー: 共立出版
- 発売日: 1996/06/05
- メディア: 単行本
- クリック: 6回
- この商品を含むブログ (2件) を見る
どちらかというと、ソニックガーデンのプログラマに必要なのは、アプリケーションエンジニアとしてのスキルで、基盤系の知識はクラウドを活用して、職人を抱えなくてもよいようにしている気がする。
既存開発会社の市場を食うか。
現在のソニックガーデンさんのモデルは既存のSI企業と競合しないかもしれないけど、
「ソフトウェア開発において、価値を生む出すのは、ソースコードであり、それを生み出す 有能なプロフェッショナルとしてのプログラマである。」
という洞察はソフトウェアの製品特性に依存するものでない。ここを出発点に、既存のSIの開発について、自分なりに考えてみたい。
- システム特性(社内システム)
- 納品と瑕疵担保責任
- 規模の不経済
システム特性(社内システム)
本の中では、新規事業やコンシューマ向けシステムと相性がいい、とあるが、パッケージ導入した方がいいような基幹システムは別として、大抵の社内システムも、社内ユーザーが顧客みたいなもの。アジャイルに、継続的に改善していく方がフィットするのってかなりある。
ただ、企業内システムで、他システム連携や移行がある場合、受け入れ試験を実施するのが、かなり顧客として負担になる部分もあるね。まあ、それも継続契約の中で解消していけばいい話。顧客としては、そこらへんはPM専門のコンサルタントを使ってもいいかもしれない。
やはり今でも、社内システムに関しては、パブリッククラウドがNGっていう企業も多い。中々難しいけど、最近はDockerやら使えば、環境起因の無駄なコスト増はある程度防げるかも。プログラマからしてみれば、クラウド環境での動作を保証して、デプロイは顧客が責任を持つって形がいいのかな。そこまでやってたら、リーズナブルな価格設定は難しくなるかも。
個人的な意見では、大企業のグループ会社が、グループのプライベートクラウドを利用して、「納品のない受託開発」をやるのが結構いい選択と思っている。課題は、エンジニアの能力とマインドだが。。。
納品と瑕疵担保
- 私見では本で指摘されている問題の多くは「納品」に起因するものではないし、パブリッククラウドでしかできないものではない。通常の製造物と同様な「瑕疵担保責任」を負う事が業務用のソフトウェアの場合そぐわないなら、定額で、顧客資産の開発を進めるという形(変形のSES?)もあり得るだろう。結局、仕様なんて決めきれないのだから、これは、バグか、仕様か、みたいな不毛な議論に工数かけるよりも、継続的に機能追加していくことで培われる「信頼」をベースに修正していった方が双方にとってメリットはあるだろう。(ただ、誰が悪い、という犯人探しをするには、納品というメカニズムは中々便利。)
- 納期がないと、計画が立たない、というのは、ビジネス的なリスクである、という議論は確かにあるが、多分、それは見積もり、ターゲット、コミットメントを混同している。3ヶ月毎にマイルストーンを話し合うというし、もし、発注者がかなり具体的なビジョンを持っていて、ビジネスターゲットが明確なら、ある程度正確な見積もりはできる。コミットメントをしないだけ。どちらかというと、顔の見える、有能な実装者が見積もりを行うのだから、顧客の言われるがままに適当に算出した見積もりよりも正確。発生した問題もアジャイル的に開発するから、早期発見、早期対応ができる。 大規模ではいくらベンダがコミットしても、終盤になってはどんなに残業してもリカバリきかない事も多いのだから、結局は同じこと。リスクを許容し、それをコントロールする能力を信頼するのか、リスクなし、の幻想をそれが破綻するまで見ていたいのか、という問題。もしくは、遅れたとしてもベンダのせいにできるか、できないか、という問題。ビジネス価値を重視するのか、政治的な利得を重視するのか。
- 作者: スティーブマコネル,久手堅憲之,Steve McConnell,田沢恵,溝口真理子
- 出版社/メーカー: 日経BP社
- 発売日: 2006/10/07
- メディア: 単行本
- 購入: 31人 クリック: 472回
- この商品を含むブログ (91件) を見る
また、開発中に、顧客がエンジニアの能力に疑問をもっても、今の契約なら、発覚した時点で「ふざけるな、なんとかしろ」と言えばすむ事を、キチンと受け入れ試験をしたり、エンジニアを評価しなければならない分、顧客担当者の負担は増えるかもね。
結局、顧客、エンジニアとして、正直に、信頼し合う関係で、問題が起こったら、お互いに協力しあいましょう、というスタンスにどこまでついてこられるか、という問題、かな。
規模の不経済
さて、ここでやはり問題になるのが、ソフトウェアの規模との関係。エンジニア一人が担当することで、余分な管理コストの発生を防ぎ、保守性の優れた高品質をリーズナブルな価格で提供しているが、それが許されない規模の案件に対して、どういう絵が書けるのか。
ちなみに、少数精鋭チームと大規模開発の問題は、ブルックスの時代から議論されていたらしい。
- 作者: フレデリック・P・ブルックス Jr.,滝沢徹,牧野祐子,富澤昇
- 出版社/メーカー: ピアソン桐原
- 発売日: 2010/12/14
- メディア: 単行本(ソフトカバー)
- 購入: 10人 クリック: 91回
- この商品を含むブログ (50件) を見る
多分、一人の優秀なプログラマが仕様を理解し、構築までする品質と生産性を基礎数字に、2倍の生産性を出そうとすると、2人ではでずに、3人〜4人くらいは必要になる気がする。人数が増えれば、増えるだけコミュニケーションコストがかかるから。自分たちのために文書も作成する必要がある。その倍の生産性となると、さらに当然8人ではなく、10人〜15人。その時点で優秀なプログラマを確保するのが、怪しくなってくる。。。スクラムチームだと、3〜4チームか。この辺りが、保守性の高いコードをつくる限界な気がする。自己組織化チームも限界か。
それ以上だと、多分、コア機能と周辺機能を分けて品質で妥協しつつ、マネジメントを取り入れる必要がでてくるかなあ。
とはいえ、優秀なプログラマが一人でできる生産性の4倍程度となると、相当な規模のアプリケーションを作れるような気がする。2倍程度でも、パッケージ導入しないようなアプリはかなりカバーできんじゃないかなあ。
問題は、一旦、基本機能を作りきってしまったら、それまでの生産性を維持するほどの需要がないから、同じ金額を払い続けるモチベーションが顧客側にないことかなあ。
ただ、既存の開発案件と比べたら、圧倒的にリーズナブルであるはず。
大抵の請負契約は真のリスクを隠して、お金の問題でなく、担当者個人や組織に責任がいかないようになっているだけな気がする。
それを越えて、シビアにリスクとビジネス価値を考える顧客とそれに答えられるエンジニアが増えていけば、価値あるソフトウェアが増え、価値あるエンジニアが評価されるようになって行く未来が描けるかもしれない。
- 作者: トム・デマルコ,ティモシー・リスター,伊豆原弓
- 出版社/メーカー: 日経BP社
- 発売日: 2003/12/23
- メディア: 単行本
- 購入: 7人 クリック: 110回
- この商品を含むブログ (150件) を見る
その時に、自分が生き残れるかは、また、別の話。
書評+『絶望の裁判所』
長くなりそうだったので、ブログに書く。かなり主観的な感想、うーんと多分人に読ませるものではない。
官僚組織内部の機能不全というのは、ある程度暴露本がでてくれなきゃ、中々普段接する機会のない人には分からない。
人格批判のような記述があるので、拒絶感ある方もいそうだが、官僚化が進行している組織には、こういった小人物が権力を握るのはよく見られることだと自分は思うので、そこまで歪んだ記述ではないと思う。
「かつては、少なくとも若手は優秀な人材が評価されていた」、という記述がある。官僚的であっても、一応なんとか機能している組織は、そういう傾向がある気がする。
骨のある、実力者のうるさ方は、一定レベルまでは昇格し、組織内部でも実力に不相応な待遇とはいえ、一定の尊敬、待遇を与えられ、若手の教育や危機の際の問題解決に腕を振るう。
多分組織トップも、そういった層がいるから何とかなっていて、自分が取り立てているヒラメ人間は組織の保全以外に役に立たないことを知っている場合が多いのだろう。創業時代の重鎮が残る日本の大企業はそうなんじゃないかな。
多分、本当の官僚化は、ヒラメ人間が勘違いして不遇の実力者を排除しはじめた時なんだろう。
とはいえ、正論をはく真っすぐな気骨のある人材がトップに立てない、組織の管理職には決して人間として尊敬できない人がいるって、多分大抵の人の認識の気がするけど、そうでもない組織もあるらしい。
http://blogs.itmedia.co.jp/magic/2014/03/post-6dc8.html
裁判所の官僚化っていうのが、如何にヤバいか、ってあまり一般の人には分からないかもね。文系の基礎教養として、マクロ経済学の他に、基本的な政治思想と初級法学はあっていいと思う。
システム思考についての私見メモ
下記読んで、うーん、ともやもやしてきたので、デトックス
【本棚登録】『思考脳力のつくり方 仕事と人生を革新する四つの思考法 (角川oneテーマ21)』前野 隆司 http://t.co/wHjkQnqKC8 #booklog
— 松下正嗣 (@masatsugumatsus) May 25, 2014
システム思考の簡単な歴史については、自分で勉強した限りで下記に書いた。
http://d.hatena.ne.jp/masatsugumatsus/20120505/1336209556
社会システム論については、あまり、興味ないから知らない。
多分、前野先生の言ってる「システム思考」は多分、シミュレーションを重視する一部の学派の考え方について述べているんだろうと思う。
自分は「システム思考」を自分の視点を時間的、空間的、立場的に吟味し直す事、自分の理解力の不完全さを思い出す事なんかのための便利なツールボックスとして使っていて、かなり定義は緩やか。著書で述べられている「ポスト・システム思考」も「システム思想」も自分の定義による『システム思考』の範疇には入っちゃうんだよね。
システム思考家は、様々な分野の知識をメタで把握するから、異分野の業績を理解するのが早い。自分の考えでは、学問であったり、仕事であったりした時、高い業績を出せる人には、システム思考が出来る人と出来ない人の2パターンがある。
システム思考が出来ない人は、自分の分野の外にはかなり疎かったり、コミュニケーション不全になりがち。システム思考が出来る人は、自分のやっていることをメタに把握しているから異分野での交流ができる。
大きな絵を描くには、異分野との交流が必要である場合が多いから、システム思考が必要なんだろう。
自分は、はてなダイアリーで書いた本でも学んだけど、基本的な素養は大学の時に読んだ下記の本で、基本を学んだ気がする。一体、科学であるっていえるのか、っという批判にさらされがちな学問の方が、科学的であるとはどういうことか、という事に対する哲学的な思索が深まる。
既存権力にいる保守派は、伝統と慣習という強い味方がいる以上、自己の立場について深く思考する必要はない。
- 作者: E.H.カー,E.H. Carr,清水幾太郎
- 出版社/メーカー: 岩波書店
- 発売日: 1962/03/20
- メディア: 新書
- 購入: 14人 クリック: 227回
- この商品を含むブログ (111件) を見る
ホッファーによれば、変化を担うのは、没落する特権階級、下降していく過去の既得権益者。彼らこそ、優れたシステム思考家になる可能性がある。
教育に関するデトックス
別に21世紀型スキルの話ではなく、ICT教育とか、その他色々。
デトックスですので、事実誤認や曲解もあることは理解しています。
タブレットを生徒に配布するのにも批判的。タブレットは、基本、コンピュータを知らなくても操作できるように設計されている。全自動洗濯機のようなもの。すぐ使えるようになるから、教育効果は低い。
それなら、ちゃんとパソコン使えるようになった方がいい。偉大なソフトウェアは、ディスプレイとキーボードから生まれているのだ。
ネット接続端末として利用し、インターネットのリテラシーを学ぶっていうのは、少しはましなアイデアだ。だけど、すぐ消えていく情報とよい情報を選り分けるスキルを身に付けるのにネット使う必要ない。図書館でいい。
できるソフトウェアエンジニアは、一般の社会人より、遥かに多くの「本」を読んでいるよ。
所謂ソフトスキルを身に付けるのに支配的な変数は何か、といったら、ツールや制度より、「教師の意欲と能力」だろう。良い教師に出会えた人は、どれだけ多くのことが、過去の枠組みやツールという制約のなかでも、学習可能かを知っているはずだ。
だとすると、教師個人の能力を高めたり、発揮しやすい環境を整える方が実りがある。
個人の能力にフォーカスすると、不平等や不均衡を批判する議論もあるけど、
第一に 優れたツールや制度でも、ダメ教師はすべてを台無しにする。
第二に、そもそも教師の質に依存しない優れたツールを開発する目処は立っておらず、可能だとしても膨大なコストと時間がかかる。
第三に、十年以上に亘って学校教育を受け続ける学生の立場からすると、良い教師に「当たる」確率は多ければ多いほどよい。学びかた、学ぶ姿勢、人生観、これらは一度学んでしまえば不可逆的で、後戻りはしにくい。良い教師に当たるのが10年のうち、0よりも1が、1よりも2であれば、それだけ学生にとっては明確なメリットになる。ROIはより明確。