プロセス or ケースバイケース ？

やっとこ「リーン製品開発方式」を読み始めました。

まだ1/4程度でしょうか。
しかしながら、冒頭から衝撃的な事が次々と....

そのうちの1番は、もう少し整理してからじゃないと....
という感じなので、

2番目くらいから。

「最も注意深く詳細まで定められた開発プロセスを持つ会社が
　なぜ一番大きな問題を抱えてしまうか。
　その理由の1つは、
　文書化されたプロセスは開発者に非効率な手法を使う事を強いるためだ。」

文書化されたプロセスは非効率

と、言い切っています。

すごいですね！

それに対して、トヨタでは、

「トヨタ標準プロセスを突き止めようと開発者に聞くと、

　毎回「ケースバイケースだ」との答え返ってきた。」

という事なのですが、

こちらも、「ケースバイケースだ」と言い切ってる事がすごいと思います。

前回の非マニュアルと同じく、要するに

受動的なプロセスではなく

主体的なカスタムプロセスが無駄を無くす。
（リーンでは無駄を無くす、非マニュアルでは感動を生むという感じでしょうか）

という事だと思うのですが、
説得力というか、力強さに圧倒されますね。

しかし、ケースバイケースで、どうやって品質を確保するのか
というツッコミがありそうですが、

それについては、

「トレードオフ曲線に埋め込まれた知識を用い

　知られている問題を設計から除外しながら

　更に問題が発生することを予想して新たな解析や試験を開発していた。」

という事で、
プロセスとは別に、
データに基づいて品質を確保する方法を確立している。

という事です。
すごいとしか言いようがないですね。


で、これをソフトウェア開発に適用出来るのか？！
という事ですが、

トレードオフ曲線はやりたいですが、
ソフト開発では難しい気がしています。

因果関係図くらいは作成出来るとは思いますが、
それと品質を結び付けられるか
という点では、これまた難しい気がしています。


とにかく、A3報告書で知識を蓄積してみる
などと考えましたが、
再利用されなければ無意味ですし、
これまでも文書で残したものが再利用された事など皆無な気がします。
なので、ただ蓄積してもダメな事は明白です。

そこで結びついたのが、
以前紹介した、複数案。
これを蓄積すれば再利用も可能では？
と考えています。

現状でも、デザインパターンは考え方として再利用出来ているので、
これをメリット、デメリット、適応性などと共に蓄積すると
再利用し易くなるのではないか！？

などと日々考えています。

非マニュアル化

先日、新聞で
フジオフードシステム社長　藤尾政弘さん
の記事を読みました。

そこには

「チェーン店を出すにはマニュアルは必要だけど

　マニュアルで感動は生まれない。

　お客さんに

　ゆっくり食べてね

　と話しかけられる距離感が大事。」

これ、ソフトウェア開発でのプロセスも同じかも！？

と思いながら読んでいました。

同じように開発プロセスも必要ではありますが、

そこからは感動は生まれないと思います。

昨今では、プロセスがある故に考えなくなっている

いわゆる思考停止状態でしょうか。
というような事を聞く機会が増えたように感じます。

必要なのは、顧客の要望に合わせて

基本（プロセス）を抑えつつどのように利用するか、

どのようにカスタマイズするか

という事が重要なのだと思います。

更に、記事には、こんな事も

「従業員がマニュアルでなく笑顔になるには

　日ごろのリーダーのコミュニケーションが大事です」

ソフトウェア開発でも同じかと思います。

笑顔だけでなく、モチベーション、ゆとり、などなど　

は日ごろのリーダーのコミュニケーション次第ですよね。