『プログラマ主役型プロジェクトのススメ』を読み終わった。

プログラマ主役型プロジェクトのススメ ?ソフトウェア開発現場で本来の力を発揮するために?
を読み終わった。
全体に『立ち上がれプログラマ!』という雰囲気があり、元気が出る内容でした。
なんか、かなり感動したので、内容の復習をするために、気に入ったとこをまとめてみることにする。



P.10
100人のプロジェクトリーダーやSEの集団ではプログラムコードを生み出すことはないが、100人のプログラマはプログラムコードを生み出す能力がある。
プログラマ100人のプロジェクトのみがソフトウェアを完成させる可能性を秘めている。

P.12-14
最前線でプログラマがコードを生み出し、リーダーやSEがプログラマをバックアップすべく働いている。
という姿が、ソフトウェアプロジェクトのあるべき姿ではないか。
ソフトウェア会社は熟練したプロぐうラマを育て、プロジェクトリーダーはプロジェクトの性格によって調達するようなことがあってもいいのではないか。

P.25-27
間違っても熟練したプログラマになりなさいとは言われない。
プログラマとしての自覚を持つ前にプログラマを卒業してしまい、最終成果物であるプログラムコードに足のついていないSEやリーダになってしまうポジションの"ねじれ現象"が発生している。

P.29
「プログラミングできるSE」より「SEができるプログラマ」。
プログラマであるかぎり、地に足が着いている。

P.58
ソフトウェア開発はいままでと逆の順序で進める方が理にかなっているのではないか。

P.59
本来ひとりでやるべきものを、多数の人でやるためソフトウェア開発は、最初から原罪のように宿命的な困難さを内在している。

P.91
合理的思考は、個人差を超える。
合理的思考の積み重ねは、だれがやっても同じ結論にたどり着く。
個人差は表面化すべき、合理的思考と創造性(個性)は矛盾しない。

P.119-129
組織の中で語られるチームワークは実際は組織ワーク。
チームワークは、せっぱ詰まった状況における適応形態である。
掛け声ではチームワークはできない。

P.154-158
本来のコードとは別に作ったテスト用のコードを用意して、予想もしていないことを起こさせて、その結果を実際のコードにフィードバックさせるためのテストを実際の開発の前にとりいてるといいのではないか。
そのテストを行うチームは、プログラミング能力に優れた自律的に活動できるプログラマで編成すべき。

P.159
失敗を断面でなくプロセスとしてとらえる。

P.175
イメージすることは、経験することと同じ力がある。

P.180
準備とは、仕事そのもの。

P.203
経済的合理性【経済原理】を追求していくと、次第に価値観(善悪、倫理等)【生存原理】が忘れ去られる。
経済原理を意識的にコントロールする姿勢を持つ。
お金に執着しすぎると、重要なとこで判断を誤るぞ。と。

P.209
プログラミングが好きだ。
お客さまが喜んでくれることがうれしい。
その2つの上にソフトウェア開発の価値観が積み上げられる。

P.280-281
学校パラダイムから決別する。
だれでもなく、自分がそこにいて、自分が自分のためになにかをし、考えている。

以上、とりあえず。
まとめては、みたけどまだまだ、いい文章がある。


少し、仕事への情熱(?)が復活しつつあるかも。。