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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

責任を取る とは？

まだまだ続きます「リーン製品開発方式」 からです。

以下、先月（プロセスorケースバイケース？）紹介した衝撃的な内容に続く
第2弾です。

「責任を取るとはプロジェクト全体の成功に貢献する事」

これはちょっと驚きました。

責任　というと、どっちかというとトラブルが起きた場合の対処や

損害賠償的な事を考えてしまいます。

こう考えてしまうのは、私だけでしょうか？！

しかし、こんな後ろ向きな事ではなく、

必ず成功させる事が責任という事で、認識が真逆な事が衝撃的でした。

そして、こう続きます。

「自分達の専門領域のためだけでなく、

　また言われた通りに行動するだけでなく結果を求める事である。」

つまり、責任を取るとは、結果を求める事

という事です。

確かに、そうですよね。

結果を出さなければ意味が無いですよね。

という事で、最近我がグループでは、

より成果、結果を意識するように「ミッション」を流行語にしました。

まずは、あちこちで、「ミッション」という言葉が飛び交うように

可能な限り、ホワイトボードにミッションを記載する

といった事から始めています。

これが、可能な限り、短い期間でのミッション設定をする事に繋がれば

と思っています。

そして、各自がミッションを達成し、

１つ１つに責任を取る事を積み重ねていく。

その結果は、必ずプロジェクト成功となる筈！

美しく、首尾一貫

またまた「リーン製品開発方式」 からです。

ビジョンの合意を得る為には、
「ビジョンは方向性を示し、努力を統合し、美しく、首尾一貫している必要がある」

先月から、あまり読み進められていませんが、ここまでで一番好きなフレーズです。

美しく、首尾一貫している必要がある

特にここがお気に入り！

やはり美しさを求めないといけませんね。

リボンモデルも1つのビジョンかと思います。
美しくアートな開発を目指して！


それから、これもお気に入り

製品とバリューストーリームに対して明確で論理的なアーキテクチャーを定義する

アーキテクチャー大事ですよね。
この書籍の中のアーキテクチャーとソフトウェアのアーキテクチャーは
若干異なる可能性はありますが、

構造という意味では、ほぼ同じかと思っています。


常に、美しく、首尾一貫したビジョンを示していきたいですね！

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

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

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

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

2番目くらいから。

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

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

と、言い切っています。

すごいですね！

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

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

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

という事なのですが、

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

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

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

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

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

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

それについては、

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

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

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

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

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


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

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

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


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

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

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

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

非マニュアル化

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

そこには

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

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

　お客さんに

　ゆっくり食べてね

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

セットベース開発とA3報告書 と 考える時間

本日、ゴールシステムコンサルティングさんに初めてお伺いしました。

もちもん、

最新手法で開発生産性倍増を目指せ！　TOC/CCPM×リーン開発セミナー

を受講する為です。

受講目的は、リーンを学ぶ為はもちろんですが、
今回は特にセットベース開発でA3報告書を残すという改善について
具体的な事例を聞き出す！　です。


最後のQAでは、A3報告書に関する質問も多く
みなさん興味のあるところなのかな　と改めて感じました。

ですが、今回、一番驚いたのは、
セミナーの冒頭に、西原さんから
どこの開発でも「考える時間」が削減されている」
「考える時間」が無いといった技術者の悩みを多く聞く
という事で、
私の取組も、開発現場の問題解決のヒントになっていれば
と改めて感じた次第です。


以下、本日のセミナーに参加して
今後やってみようと思った事。
#まだ聞いたばかりであまりまとまっていませんが...

セットベースのイテレーション毎に（リーンではIE？）

1)まずは、イテレーション開始時に、A3報告書を残す事を合意する
2)各課題や調査事項ごとに、記載の有無を明示
　（LAMDA表みたいなものに、A3を記載する／しないを追加）
　記載項目は、都度検討し、全部書かなくても良いものとする
　また、記載は、手書きや、ホワイトボードもOKとする
3)イテレーション終了時に、記載したA3報告書を整理、追記
　この時間を出来るだけ短くしたい（1日くらい....）

みたいな感じで出来ると良いかなぁ....
と考えています。

しかし、その後、Knowledge Baseとしてそれを整理したりする事も必要
という事も大収穫でしたが、
こちらは、じっくり考える必要ありですね...


また、最後には、稲垣さんと
組込み開発にはセットベースや因果関係図などリーンが適用可能
といった事もお話し出来ました。

プロジェクトと共に成長する

ASDoQ大会2014に参加しました。

そこで、「アジャイル開発の教科書」などの著者である細谷さんと
お話する機会がありました。

というより、お話したくて参加しました。

ASDoQ大会2014を通して、
改めてアジャイル（リボンモデル含む）とは
プロジェクトと共に成長する
プロジェクトの中で各技術者が成長していく為のアプローチだと感じました。
もしかすると、それがプロジェクトを成功に導く為の大きな要因なのかもしれませんね


成長する要因は以下の3点かと思います。

・その１：能動的となる

プロダクトオーナー（顧客　or　もしくは仮想顧客）
と開発チームが一体となって相互理解の元に意思決定していく事が
開発チームを能動的にする。
能動的な事は成長の大きな要素となります。
更には、能動的な事は無駄な事や後戻りが減る事にも繋がります。

・その２：機会が多い

イテレーションや単体テスト、リファクタリングを繰り返すので
失敗しても、改善する機会が多い
更にはもっと良くする為の改善なども可能となる。
プロジェクトで繰り返しが多い事（機会が多い事）
がプロジェクトの進行と共に自然と成長していく

また、意思決定から動くソフトウェア作成
までを出来るだけ小さくする事で、
意思がダイレクトにソフトウェアに反映される。
という実感を得られる。（何の為の作り込みかが分かる）

そして、サイクルが小さい為に、それを何度も経験出来る。
つまりは、価値の確認やフィードバックなどを何度も得る事が出来る。

・その３：一体感

顧客を含めた一体感の中で開発していく事も
成長には大きな要因となると感じています。
楽しい、役に立っている、ワクワクする
といった感情が、「もっと～したい」、「より～したい」を増殖させて
各々もチームとしても成長していく事に繋がる。