Menlo

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

8章の事例5で
紹介されているメンロ・イノベーション

すごいです！！
まさしく目指すところって感じです。


そしてそして、翻訳者の稲垣さんとの交流で
メンロに関する情報をGet！

それがまた、すごいです！！
とにかくすごいです！！

我々もMVPサービスとして、こんな事例がありますが、
メンロのハイテク人類学者は、
このような事を極めた技術者なのだと想像出来ます。

更には、XPのプラクティスもほとんど実践しているようです。

と、いう事で、
新たな目標が出来ましたね。
メンロを超えるチーム、更には組織を作る！

やったるでぇ～

設計コンセプトを共有しよう！

設計コンセプトを共有しよう！

という事で、
実際に記載したコンセプトマニュアルを参考に
何を共有するのかをまとめてみました。

ここにも複数案が登場します。
結果、セットベース開発にも関係してきます。

複数案のメリット、デメリット比較は
インセプションデッキのやらない事リストにも似ていると感じています。

「やる事」という視点と
「やらない事」という視点での
クロスチェックであり、同時にチームの認識が明確になる。

ですが、なかなか「やらない事」視点って難しいですよね。
複数案の方が比較的容易かと思うのですが.....

セットベース開発へのいざない

セットベース開発へのとっかかりとして
複数案を検討する事から始めては如何でしょうか！？

って事で、
セットベース開発アプローチ
としてまとめてみました。

複数案検討している時間が無い
という場合もあるかとは思いますが、

初期段階でどれだけ検討出来るかが
後々のスピードアップに繋がります。

また、レビューも効率的に作用します。

時間も不確実性の非耐性
により、上流工程での工面が難しいのだと思いますが、

ゴールに向けて、今、何にいそしむべきなのか
という本質思考、目的意識は
常に持っていたいですね。

意識も、1人だと難しいので、チームで補いながら。
がベストでしょうか。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

責任を取る とは？

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

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

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

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

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

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

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

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

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

そして、こう続きます。

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

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

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

という事です。

確かに、そうですよね。

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

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

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

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

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

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

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

と思っています。

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

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

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

美しく、首尾一貫

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

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

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

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

特にここがお気に入り！

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

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


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

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

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

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


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