セットベース開発と品質データと見えない力

リーン製品開発方式
先日の人間ドックで、やっとこ全て読み終わりました。

前半には、衝撃的な事ばズバズバと書かれていて
とても爽快です。

改めて、ソフトウェア開発においては、
セットベース開発と
品質をデータで示す事と
チームワークや熱意のような見えない力を成長させる事
が
これまで、おろそかにされてきた気がします。

見えない力については、
序章のヘンリーフォードと豊田喜一郎の比較はとても印象的で、
共に学習し成長する意識が、全てを解決に導いてくれる気がしました。

ですが、この意識改革が最も難しい点かもしれません。

セットベース開発については既に取り組んでいますが、
その成果が残せず、模索中です。

セットベースとしての試作はもちろんの事、
複数の設計案、実装案を考える事も、
セットベースの1つとして少しずつ広めています。

これが、最適設計、最適実装を見つける事に繋がる筈ですし、
最適を模索する事が品質向上になる筈ですので。

しかし、複数案についても
何をどのように検討したのかが残せていません...

ここ数年、どのように残すかを検討中で、

現状では、セットベース開発にて
設計技術として解決した課題を一般化し、
品質データと共にドキュメント化したい！

という野望に成長しています。

設計と紐づけした品質データを残す方法については
まったく何も思いつきもしませんが、
とにかく考えてみたいと思います。

プロセス VS チームワークと熱意

2015年一発目も、もちろん「リーン製品開発方式」 からです。

あと最後の8章を残すのみとなりました。
以下が、一番のお気に入りの言葉となりそうです。

「従来の開発プロセスの考え方は膨大なムダを生む。
　プロセスをやめて、代わりにチームワークと熱意を入れると
　直ちに劇的な改善効果を生み出す。」

「従来の」がポイントでしょうか。
前回の通り、ケースバイケースで考えられていれば
プロセスも効果がある　という事かと思います。

最近、チームワークや熱意と品質、生産性には
相関関係があると感じる事が多くなりました。

そして、従来の？プロセスの最大の欠点は
チームに決断させない事ではないかと感じています。

チームで決めた事は
能動的な行動になり易いと思います。
しかし、プロセスとして決められたアクションは
なかなか能動的になり難いのかと思うのです。

逆に、プロセスもチーム内で、目的達成の手段として必要という決断をすれば、
共通認識となり、能動的になるのかと。

「リーン製品開発方式」にも、
具体的な方法の1つとして、プロセスから解放する
といった記載がありましたが、
何かと制約が多いと、熱意があっても徐々に失われますよね。
そうなると、受け身になり、
決断もしなくなるのかと思います。

品質においてもチームで目指す品質や、
その品質を確保する具体的な手段を決める（決断する）事で
能動的になり、達成する事が可能になる気がします。

プロジェクト管理においても、
マネージメントすべきはチームワークや熱意なのかもしれませんね。

本来、プロジェクトが成功すれば
どんなやり方でも良い筈ですから。

まぁ、ソフト開発だと、
それだけ管理しても成果物としてどの程度完成しているのか
などの進捗判断が出来ないので、
そうなっていないのでしょうけど。

そうなると、やはり動くソフトが見える状態を
可能な限り早く作って
チームワークや熱意のマネージメントに注力すべきな気がしますね。