リーン開発_第3章_価値
Google社の場合
製品開発にはフィージビリティスタディ(実現可能性調査)が必要である。
システム設計
製品が見えてくるにつれて進化していくものであるという事を心得た上、スムーズに先に進めれるよう
その進化をきちんと考慮に入れられる経験を積んだ設計者によって行われなくてはならないのである。
1．価値 ユーザに焦点を絞れば「結果」は自然についてくる
開発チームの命題はレーザのようにピンポイントでユーザにフォーカスした製品を開発する事だった
その製品が広く使われるようになったら、スタッフは利益を生み出す方法を見つけ出すように求められる。
2．卓越性 1つのことを極めてうまくやるのが一番
グーグルという組織は、彼らが作る検索エンジンと同じように、やるべきことを本当にうまく果たせるように作られている。 高い技術力があればこそ、一度にいろいろな実験をし、試してみる柔軟性がうまれるのだ。
3．民主主義 民主主義はウェブでも通用する。
グーグルでは、新しいアイディアを思いついたら参加者を募り、一定数以上の賛同者を集められれば、 実現へ踏み出すことが出来る。製品は、グーグルラボに掲載され、ユーザの興味を引くことで成長していくのである。
4．スピード 遅いより早いほうがいい
グーグルでは、他社で何年もかかることがすばやく、何日間、何週間という単位で起こっている。
フィージビリティスタディの段階でシステム設計が十分に行われているのなら、たいていの場合、 パイロットの段階で顧客へのソフトウェアリリースは有益である。
喜ぶ顧客
- 機能追加によって性能を向上
- 顧客が気づいてすらいないニーズを発見し、そのニーズを満たして喜ばせる。
満足度を指数的に伸ばしたいのであれば、満たされていないニーズを発見して満たし、
それによって顧客に驚きと喜びを与えなくてはならない。
素晴らしい製品は、ただ顧客の要求を聞いているだけでは生まれてこず、
顧客の世界を深く理解し、満たされていないニーズを発見し、そのようなニーズを満たして
顧客を驚かせることによって、生まれてくるものである。
すばらしい、ソフトウェアはビジネスを理解している人物と技術を本当に理解している 人物との意気投合から育っていく。
顧客を重視する組織
リーダシップ
- チャンピオン(製品統括責任者を指す)
- チャンピオンは、顧客の作業や、顧客に驚きと喜びを与える技術を理解する人物。
- チャンピオンには、製品に関する重要な決定を下す責任と決定した結果に対する説明責任がある。
チーフエンジニアを立てるという、手法には多くの情報を責任ある一個人の頭の中に統合できるメリットがある。 チーフエンジニアにとって、適切な訓練環境がない企業や、チーフエンジニアは知識の統合よりも 業務管理に注力すべきだと考えている企業ではこれが問題となる。
リーダシップチーム
- 二人のリーダーを立てることのが最良の道になることもある。
- 一人は市場を深く理解する人物、もう一人は技術的なリーダー
リーダシップチームのメンバーは、開発チーム全体の方向性をひとつにまとめ、 いわば「一心同体」にならなくてはならない。
共有リーダーシップ
- チーフエンジニアではなく、専門家集団が開発
専属チームが組まれ、メンバーが1ヶ所に集め。多くの時間を進捗具合の見直し、 教えあったり、問題を解決したりするのに費やした。 チームリーダの第一の仕事は、開発プロセスを管理し、メンバーの連携やチームの意思疎通を促したり、 意志の統一を求めたり、チームを正しい軌道から外れないようにすること。
責任は誰にある？
- 市場ニーズを明確にし、ポイントとなる製品特性を決定するために他チームと協業する。
このチャンピオンとビジネス上重要な機能を持つ全ての部署から集結したチームの組み合わせが、
何十年も会社を支える。
トヨタの原則「チームワークは質の高い仕事を成し遂げる鍵になるが、誰かが必ず責任をもたなくてはならない」
的確な意思決定は、有能な組織の証拠であり。意思決定の役割を明確にすることが、
聡明でタイムリーな決定を下すうえで欠かせない。
完全なチーム
- ソフトウェア開発で、製造しやすい設計にあたるのが、「運用しやすい設計」である。
目立ちはしないが、ソフトウェア開発チームには、
コンピュータ操作、ネットワーク構築、保守、顧客サポートという役割がある。
ソフトウェアを実際に製品として使われたときからどのような問題が起こるのか、
そしてそのような問題を避け、問題から復旧するために必要な機能は何かを考え、 チームにつきつけるメンバーが開発チームには必要である。
ソフトウェア企業とIT部門が異なる点
マーケティングというステップを飛ばしてしまう事があまりに多く、
作った製品がビジネス上のニーズに合わないとこに驚かさられることになる。
IT部門には、ソフトウェア企業のビジネス継続に不可欠な、
費用対効果をつり合わせるための施策を実施しようとする動機づけがほとんどない。
開発成果物がビジネスの成功に貢献しない限りIT部門の成功もない。
