アジャイルでやってこう!
メモ書きの割にまとまってないけど、それだけ重要な点が多いってことで許してください。
それくらいには、読んでためになる内容が多かった印象です。
「製品開発の知識」という書籍(以降、本書と呼びます)の内容要約、および、自身の感想などを記します。
本書は、2002年に発売の古い本ですが、2016年には第15版が登場しています。
今回は、その第15版を読みました(何が違うかは把握できてませんが、多分ここかなーという目星はついた程度です)。
本書の要約については、である調で記します。
箇条書きについては、次のルールで記述しています。
簡単に書くと、項目自体についてを太字で、項目の説明を常体で、それぞれ書いていきます。
製品開発の現場では、マニュアル的な知識よりも基礎知識の方が重要である。
本書はヒット商品そのものではなく、ヒット商品を生み出す企業体質についてを記述する。
製品価値の役割は、以下の2点。
付加価値の源泉は以下の3点。
付加価値の高い製品開発により、次の対象に大きく貢献する。
以下のバランスが重要。
マネジメントすべき対象は、以下の3点。
以下のバランスが重要。
複雑性を持つ対象は、以下の通り。
不確実性を持つ対象は、以下の通り。
差異化の源泉は、以下の通り。
イノベーション対象という視点でのタイプは、以下の通り。
この枠組みを利用する利点は、次の2点。
イノベーションの判定は、以下の2点。
基準点としては、以下の2点。
変化量としては、以下の2点。
イノベーションを起こすためには、以下の2つの戦略に分けられる。
既存機能の改善を重視する戦略。
既存機能に囚われずイノベーションを重視する戦略。
基本的には、改善重視型戦略の逆を取る。
なお、リーダー戦略およびフォロワー戦略は、どちらが良いというわけで無く、それぞれに一長一短が存在する。
イノベーションを生み出すために乗り越えるべきジレンマとして、以下の3つが存在する。
重要な点は、新旧技術の利点欠点を理解しつつ、どちらかを適切なタイミングで意思決定するリーダーの存在である。
革新的技術の投資は、タイミングを見計って遅すぎない段階に実施する必要がある。
または、競合企業が革新的技術に投資している中、自企業だけ既存技術で優位性を高める戦略もある。
なお、日本企業では、イノベーションの多く(特に、破壊的イノベーションの多く)が大企業から生み出されている。
これは、次の2点を象徴している。
製造業にとって製品戦略は、企業戦略の下位概念ではなく、経営戦略とオーバーラップして考えるべき重要なものである。
外部環境との関係として重要なステークホルダーは、次の3つである。
自社を含めて、通称 4C と呼ぶ。
製品戦略の分野は、次の3つに大別できる。
短期的な視点。
マーケットイン戦略(市場の要求から製品を開発する戦略)より、プロダクトアウト戦略(存在しない市場を生み出す製品を開発する戦略)の方が、最終的に取得できるパイは大きい。
短期的な視点。
長期的な視点。
最初から完璧な設計開発を実現するという発想でプロセスを考えるべきでは無い。
製品開発の業務は、以下の5つに大別できる。
製品コンセプト、技術計画、収益性計画を検討する。
製品開発終了まで常に参照し、実際とのギャップを埋める必要がある。
収益性計画は、原価企画という手法で定めると良い。
原価企画とは、顧客価値の視点から見た販売価格から、経営戦略上必要とされる利益目標を差し引いた金額(目標コスト)を、製品企画の段階で設定する手法のこと。
逆に、コストの積上げ式で最終的な販売価格を決めるのは悪手となる(市場での競争力が失われてしまうため)。
設計者が設計案を創出する必要がある。
その設計案が実際に目標や製品コンセプトにあっているかを検証する。
この「設計案の創出」と「検証」を繰返すことで、設計は具体化する。
キーとなる要素技術の開発は、他の要素技術に先駆けて進める必要がある。
製品設計開始前に、生産条件を製品技術者に提示する。
これにより、生産しやすい製品設計が可能となる。
原価企画によるコスト管理が良い。
製品開発の複雑性の要素は、次のように分けられる。
イノベーションのタイプと部分的に似ている。
組織体勢の種類は、以下の通り。
PM の権限については、以下の通り。
製品開発プロセスのマネジメントをする際に重要となる用語として2点、また、コンカレント・エンジニアリングを機能させるために必要な活動について1点、それぞれ挙げる。
製品開発業務の各工程を、並行して実施する開発手法のこと。
特に設計と生産技術の間における並行化が、製品開発プロ性巣の成否に影響が大きい。
問題解決の前倒し、つまり、後工程で起こりうる問題を、なるべく早期に顕在化させること。
これにより、プロジェクトにおける開発期間短縮、および、工数削減が実現できる。
実際に製品開発プロセスを効率的に促進するためには、関連機能間のコミュニケーションと情報交換が重要である。
設計開始前に、生産技術から設計へ、生産要件に関する情報を十分にインプットすることが大切である。
つまり、設計時に守るべきポイントを提示することで、設計に生産技術の要素を組込むことが重要である。
この時、失敗事例をデータベース化しておくと良い。
ただし、ルールを厳しくしすぎると創造的な設計活動に悪影響をもたらすため、定期的な見直しが必要である。
設計の途中過程であっても、情報を生産技術部門に逐一報告するとよい。
ただし、生産準備が全て無駄になっては意味がないため、未完成であっても有意義な情報である必要がある。
チームとして一体感がなければ、責任問題を問われる可能性を恐れて、前段側は情報を出せない。
共同で問題解決に取組む姿勢が必要となる。
製品開発には複数企業が関わることが一般的になっている。
企業間関係のタイプには、次の2種類が存在する。
内部で開発/製造する部品を選択する際の観点として、以下の3点を挙げる。
企業ネットワークを構築することで、部品調達が優位になる場合がある。
取引企業の数によって、それぞれ以下のような優位点がある。
基本的に、取引企業は多すぎても少なすぎても良くない。
基本的には、2〜3社と取引することが最適だと(本書では)考えられている。
コンカレント・エンジニアリングの組織プロセスに、部品企業を組込む(製品開発プロジェクトに、部品企業を早期から参加させる)こと。
これにより、手戻り削減が期待できる。
デザイン・インを実施するためには、以下の条件が必須である。
かつての欧米企業では、調達供給関係である企業は疑心暗鬼の関係であった。
そのため、デザイン・インの考え方は、欧米企業では一般的ではなかったが、近年では取入れている企業が増えている。
優れた製品開発能力とは、自由と規律、コストと付加価値、繊毛性と統合性、といった、矛盾する目標を高次元で統合的に解決する仕組みによって成立つ。
相反する要素の組合せ、および、解決策は、以下の通り。
二律背反を高度な視点から解決できた企業の例を、以下に示す。
本書が、2002年当時(から2016年までの間)に注目している視点は、以下の通り。
全体的に、ソフトウェア開発ではアジャイルに相当することを、ハードウェアでも実施することが望ましいということが言われていました。
が、これは新製品開発での話である、という前提を考慮すれば、そうでない場合(いわゆる保守/運用)ではどうすべきか、については書いてないと言えますね。
製品開発を会社として本気で取組むためには、会社の文化から変えていかないといけないみたいです。
そこまでちゃんと取組めている会社がどれだけあるのか......?という疑問は残りますが、企業選択の時点では考えるべき観点の1つかもしれません(就職/転職しかり、株式購入しかり)。
また、保守運用チームと新製品開発チームを併用している会社の場合(今の多くの企業はそういう感じな気がしますが)、どのように両立させると良いか、気になりました。
保守運用チームと新製品開発チームの両方が Win-Win になるためには、「ハイブリット型組織」が生かせるような、そうでもないような......
それと、営業チームと開発チームとの関係について、ほとんど書いてなかった点が気になりました。
そこが知りたいところでもあるのですが、製品開発に営業はいらないってことなのでしょうか?
いや、そんなことはないはず......
後、本書でチラッと書いてましたが、デファクト・スタンダードの対義語はデジューリ・スタンダードというらしいです。
Crieitは誰でも投稿できるサービスです。 是非記事の投稿をお願いします。どんな軽い内容でも投稿できます。
また、「こんな記事が読みたいけど見つからない!」という方は是非記事投稿リクエストボードへ!
こじんまりと作業ログやメモ、進捗を書き残しておきたい方はボード機能をご利用ください。
ボードとは?
コメント