■

・管理という名の下スケジュールをいじくるしか方法がないことがしばしばある。
・っという人がいる
・現状を把握し、開発の実態を把握し、注力するポイントや改善点を白日の下に晒してから始まるコトがある。
・でも「がんばってやらなきゃいけない点で同じやん」っていう人がいる

以下の条件を考慮したらそれでも同じと言えるのだろうか。
それともやっぱり想像できないからダメなんだろか。
もしくは「んでどーすりゃええねん」って方法論で行き詰るのだろうか。
・実態を踏まえたことを数値化して発表すると開発者視点ではなんとなくうれしい
・それより短く達成できると単純にうれしいことになるから
・注力ポイントや改善点が周知となることで、堂々とカイゼン作戦を取れることになる
・消化予定工数ってやつを目標にして、この時間内でこれだけのことが出来ればOKみたいなミッションが手に入る
・やっつけるとやっぱり楽しい
・やらされてる感満載の「がんばらなきゃ」ってのと、楽しさと厳しさの同居した「がんばらなきゃ」ってのはモチベーションが違う
・システム開発におけるモチベーションに伴う推進力の差というのは歴然としている

伝統的な開発管理体制にて

プログラムに落としづらい「仕様書」を作るのに時間と労力を割いて
苦労してプログラム作ってバグと戦う姿勢ってマッチポンプだと思う
プログラムに落としやすい資料を作って、そこからプログラムと「仕様書」の両方作れば省力化得られて、
その両方にかかる時間的要員的コストは前者をはるかに下回るのであればやる価値無いなんてことはないと思うんだが、
「そんなに資料が増えたら手間かかりますやん」とか想像力に乏しい感想を言われる。
ボク的には理解に苦しむのだが、ひょっとして苦労そのものをしたいのだろうか。