アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
吾輩はリファレンスである。名前はまだ無い -- perlの中の人
相方が壊されるという危惧… (スコア:2, 興味深い)
むしろ、そのような方の相方を頻繁に換える (日に2,3人?) ことで、ペア・プログラミングが実効的に実施されるのでしょう。
それができないのならば、「レベルの揃った外注を使いまわす」という、
“平均的な成果・現状”という名の“低いレベルに足並みをそろえさせることでマネージメント職務者 (だけ) がその場限りの安心を得る”
先のない鬱屈とした停滞気味の国内産業全般に見られる
“参加メンバの実感・実態としては、底なしの価値低減傾向”
が、このまま続いていき、産業構造そのものが
“はい、それまぁ~で~よぉ”
となるのではないでしょうか?
あるいは、こうも言えないでしょうか?
プロジェクトのキックオフ時点で、まず、管理職にコードを書かせてみるのです。
そして、「ここの大将は、この程度のプログラミング能力なんだ」ということについて、
管理者自身から末端のテスタまでの全員のコンセンサスを確立するべきです。
(多分)平均以下の技術レベルの者がマネージメントするという状況で、参加メンバそれぞれが
「それでは、そこに何を提供できるのか」
についてもプロジェクトの早期に明確化するでしょう。また
「メンバ自身が関わった工程での品質に対する責任感」云々
も育まれるのではないでしょうか?
更に、「出来ない君・伸びないチャン」のままでヒューマン・スキルだけを身に付けた者のマネージメントを
受けながら、何をどれだけの値段で提供できるのか?といった“自分の能力の真っ当な値段の感覚”というものも
身に付けられるのではないでしょうか?
「マネージメント」などという基本的には「接待業と同等のテクニック」でしかないものを無批判に「価値の高い能力」と前提することを、技術者全員が捨てるが先決かも知れません。
そこから、生産性云々の課題も真っ当な取り組みが出来るのだろうと予期しています。
市場価値を生むのは「モノを作っている」担当者なのであって、管理職はその価値が外部的要因でムザムザ損なわれないように配慮・対処するという「外向きの作業」での成果を事後的に測られるべき“二の次、三の次”な存在なのだということを広く技術者に認識させていくことが「エクストリーム」や「ペア」の最大の眼目ではないでしょうか?
そうであってこそ、“開けた”開発空間で作業できるのではないでしょうか?