「ソフトウェアプロダクトラインについて

メリットばかりに目を奪われてしまうと、どんなことが必要とされるかがわからなくなっちゃうかもしれない。
迷ったら原典を見るのが基本ですから、こちらをどうぞ。

これは"Essentials"ということだけれど、これから学べることは多いです。
日本語のサイトも玉石混交で、よさげなものは複数あります。
問題はセミナーの類でこのあたりの現実が聞き手に理解できるように話されるかどうかでしょうね。


上記の原典から無理やり抜き出せば、少なくとも下記が重要そうです。
　1.シートの34/85、損益分岐点の存在がはっきり示されている
　2.シートの41/85、Core Asset DevelopmentがProduct Developmentと独立している
　3.シートの55/85、組織マネジメントをしっかりやるのが先決と言っている

これらのことから、
　1.について
　　・やる意味があるか、考えてから行動しましょう
　2.と3.について（シート47～48に書いてあるけど）
　　・Core Assetは製品開発と分離すべきで、よってまともな要求分析が必要
　　　それなりのエンジニアを充てる必要がある
　　・Core Assetを作っている間は製品に搭載されるという成果がない
　　　そういうものだとわかってやらないと、正当に評価されない
　　　経営層の理解がないと「お前ら何をしているんだ！」となりかねない
程度のことは思いつくはず。

つまりソフト屋だけ乗り気になったって仕方ない。
技術論だけじゃないわけです。
そういうことがセミナーでつたわりゃいいのだけど。

なぜにここまでC言語なんだろ

C言語を使おうとなさってお悩みの方が多いみたい。
そりゃ、CだからこそやりやすいことってのもあるけれどそこまでCに固執しなくてもなぁ。

目的に合わせてプログラミング言語を選ぶぐらいでもいいんじゃないかと。

ダメな組織はやっぱりダメ

「頑張る」というのは日本では美徳なのかもしれない。
実際、「頑張った人には良い評価を」などと査定するぐらいだから。
しかし、方針も決めずにむやみにジタバタすることは「頑張る」とはちがう。
それを理解しない人事権者が査定するソフトウェア開発現場では混乱するばかり。
あわててコンサルタントに相談しても旧態依然たるやり方を捨てたくないばかりに、コンサルタントに見捨てられる。

そしてその人事権者はソフトウェアの生産性向上を目標に掲げる。
いったいどうしたいのか、さっぱりわからない。
それでも人事権者たちは高い給料をもらっている。
まぁ、世の中には理屈で割り切れないこともあると言うことですな。

眠い

眠いと頭が回りません。
しっかり睡眠を取ることも仕事のうちですね。
ちょっと反省

設計思想

エレベータねたを続けるうちに思い出したことがあるので書いてみます。

エアバスA300が名古屋空港で墜落したこういう事故が過去にありました。
これって、着陸復行モードに逆らった操作をしたことで余計に機首が上がり失速して墜落したものです。
ですけどね、今もすっきりしないんですよ。
１．着陸復行モードを維持し続けようとして失速したんじゃ困る
　　何のための自動操縦なのかわかりませんし、機首のピッチ角と機体速度はわかっているはず。
２．操縦士が自動操縦と明らかに食い違う操作をしたなら操縦士を信じれば？
　　操縦士は自動操縦に頼らずとも着陸できる技能を持っているはず。
　　下降の意思表示をしているなら着陸復行の自動操縦を解除するほうがよいと思う。

やっぱりすっきりしません。