制度の統一

開発プロセスの統一や標準化を目指す会社や部門は多いようだ。

しかし例えばあるプロジェクトでうまくいったやり方が他でうまくいくとは限らない。

複数の現場に受け入れやすいプロセスが持つ特徴は何か？

そのひとつがスケーラビリティだ。

リスク管理

リスク管理こそがプロジェクト管理の要諦ではないかと思うことが多い。

梅田望夫の講演

少々前のことになりますが、
梅田望夫の講演会に、潜り込んできました。
ちょっとしたツテを使って。

で、感想。

言っていることは、二次情報ばっかり。
この人は「もの作り」したこと無いんじゃないか！？
とにかく薄っぺらいです。
あの程度ならカネ払っていくのは馬鹿らしいですよ。
私といっしょにその講演を聴いた人も同じ印象だそうです。

しかし、そんな薄っぺらい講演をフムフムと真顔で聞いている
偉そうなオッサンがたくさんいたのには驚いた。

人の怒りを買っても、儲けたモンがちってことですね。
とにかく「もの作り」に携わる人はこの人に近づかない方がイイです。
反吐が出そうだ。

プログラミングでメシが食えるか！？その4

＞一流プログラマーは、そのような仕事はしません。
＞（中略）
＞プログラミングをよく知らない人が決めた仕様とはレベルが違う、
＞現実的な仕様を検討することが可能です。
＞（187ページ）

私は（一応の区切りとしては、だが）
プログラマーではなく、SEである。

一流のSEはエンジニアリングをよく知らない人が
設計した仕様とはレベルが違う、
現実的な仕様を検討することができる。

しかし、最近自分はSEではなくSI（インテグレーター）
ではないかと思うようになってきた。

一流のSIerはインテグレーションをよく知らない人が
策定した仕様とはとはレベルが違う、
現実的な仕様を検討することができる。

言ってしまえば何とでも言えるのだが
現実にはキッチリとレベルの差がある以上
逆にその差を見極めるのは大変難しい。
私もSE、SIerのレベル差を見切ることはできても
プログラマーのレベルを見切るのには少々手こずるだろう。

ましてや顧客からは余計見えにくいに違いない。

結論はただ一つ、人月商売からの脱却なのだが
コレがなかなか難しくてね・・・

プログラミングでメシが食えるか！？その3

＞作り直した方が結果的には早く安定した
＞システムが得られる場合が多いものです。
＞（152ページ）

これはすごくよく分かる。
他人の作った物はもちろんのこと、
自分が作った物でさえ作り直した方が早いことがある。

ま、自分が作ったものというのは自分がダメダメなので
致し方ないのであるが。

ここで言うのはドキュメントがそろっていないとか
引き継ぎが上手くいっていないということ以前に
『前任者の仕事の品質が著しく低い』場合に起こること。

なぜそういうことが起こるかというと
単純にその人のスキルがなかった可能性が最も高いが、
そうでなくても（高スキルであっても）、
・納期がタイトすぎた
・サポート体制が整ってなかった
という場合には簡単に発生する。

だからマネジメントをする人は
ドキュメントの整備状況とか、引き継ぎ状況とか
そういうのをチェックするのは目に見えやすくて
やりやすいのかもしれないが
そもそも技術者達に「よい仕事」をやってもらうことに
注力したほうがいい。