_ 某所の研修&トンデモ
「いいと思ったことを、より広めよう」という姿勢自体は、むしろ望ましいことだと思いますがねえ(実行可能性の議論はその後でやればいい)。それよりも、アイデアが自分から涌き出るような姿勢でないことのほうが問題だと思う。ま、へたにトップダウンアプローチすると崩壊しますから、下々の実情から、ネタになるものを巻き取っていると、すこしだけポジティブに考えてみました。
_ その前の、トンデモ
コンテキスト不明ながらもコメント。お客様と話をすれば、「じゃあこの費用をもっと積めば/減らせばその分ほげほげになるよね」というやりとりは日常茶飯事。なぜトンデモになるのかな？
議論のし方として、費用とか、使うものから決めていってしまっているのなら、言語道断ですが。
_ 使うものから決めるといえば
これ。どこぞのコメントに成果物がどうこうとあった。成果物って設計書とか手順書かな。
設計書は、要件とソースコードを段階を追って接続するものだから、それだけ取り出せばきっとどこのSIerの設計書もナンセンス。設計書は検討項目票とか、要件整理/設計思想と合わせ読めるようにせねば。
とはいっても、そもそも出発から無意味な作業もある。世の中には無意味なPG設計/関数仕様をドキュメント化しろとか、よくわからん仕事が山のようにある。
別の意味で、時間軸が過去の複数の時点の記述の寄せ集めになっていて、過去の一時点とか、現在(これが一番望ましい)の時点の記述になっていない設計書がある。これはこれで腐ってるね。
これらは発注者が自らの力量/才覚でコントロールするもんなんだけど。
んー。もちょっと読み込んで&想像力を働かせてほしいなぁ。
↑ そうですか…。ま、わたしに想像力などないし、深読みも出来ませぬゆえ…。精進が足りませんね。この程度の人間だとあきらめていただくのも手かもしれませぬ。
「これ」って初めて聞いた。
うちの上司がいつもやられてくると思ったら、こういう結末か。なさけねぇ。
それはおいといて。
「うちの最新仕様はソースを見てください」って言われるの
かなりムカつくんだよね。ソースはバグだらけのくせに。
「あのぉ同じメールが何通も送られちゃうんですけどぉ」
「仕様です」
「画面に???って出てくるんですけどぉ」
「その対応はしていません、仕様です」
なわけねーだろ！！！！！
がはは。面白い < 「それはおいといて」