■非プログラマな会社的には

プログラマと呼べるようなスペシャリストが不在で、

多少書けるけど絶対に「プログラマです」とは名乗れないゼネラリストたちで構成されている会社。

そんな会社だと、プログラムでなるべく解決する（コードが業務プロセスを頑張っちゃう）ために頑張るよりも、

業務プロセス・開発プロセス全体で最適化するよう頑張った方が、

たいていはハッピーであることに気づいた。

プログラムで頑張ろうとすると、

学習コストがかかりすぎるか、

外注するのに設計しようにも結局学習コストがかかりすぎるとか、

外注とのスムーズな協力関係に無駄に気を使うとか、

外注が逃げるとか、

引き継ぎ先がいなくて死ぬとか、

そんな余計なことが多かった。

反復性・正確性が求められるものはプログラム化に適しているけれど、プログラムは解決の一手段だし、一分野にしか過ぎない。

プログラムによる生産物を主要な糧にして事業をやっていると、

ともすればプログラムのスペシャリストでないことに大きなコンプレックスを抱くけど、

生産物が割合ライトで公共性も低い（例えばエンタメ系スマホアプリ）だったら、

無理にスペシャリスト風にやる必要はない。

身の程わきまえて、他の業務パラメータも見て総合的に結果を最大化しようというシンプルな結論に至る。

オブジェクト指向の本を読むのも結構だけど、もっと大きな見地から比較して

ライトなフレームワークを選択して、ライトな開発プロセスでやる選択がもっと歓迎されていいと思う。

そして、アジャイルとかTDD/BDDとかももちろんいいんだけど、開発現場からのボトムアップ的な思想やツールでなく、

マネジメント視点や経営視点から自分たちがライト層として開発するなら、という発想がもっとあっていいと思う。

元プログラマが経営層になっての話は近年よく聞くけど、非プログラマが経営層でかつ開発もある程度やるよ、というスタイルもそれなりにあるのに。

こういう情報が出回りにくい理由は、そもそも人数が少ないか、文章に書く魅力/余裕がないか、文章化が難しいか、まだ分野的にこなれていないか、のどれか。

暇ができたらまとめたいなあ。。

その前に売上UP（白目）

Permalink | 記事への反応(1) | 21:45

ツイートシェア