マネジメントの重要性
飛躍のカギは技術だけではない – ”MOT概論”より
1. イノベーションとは「技術革新」という狭い意味に用いられる場合があるが、企業活動において「新商品の導入」「新市場の開拓」などの「新たな結合」を生み出さなければ、技術への投資が持続できなくなり、やがては、そのことにより技術革新の停滞を招いてしまう。
2. そこで、カギはコンセプトの創造にあり「顧客ニーズ志向、技術主導」などの言葉を耳にすることがあるが、どちらにしても「技術を製品コンセプトに具現化でき、具体的なプランを持って事業化まで推進できるリーダー」が必要である。更に、多彩な人材を生かしてコンセプトに沿った成果をきちんと生み出す「マネジメント」が重要になる。
3. ビジネスモデルやコンセプトが決まってくると、それを実現するために必要な技術が明確になる。それを自社で開発するか、産学連携方式で開発するか、あるいは他社から買ってくるかの検討が始まる。
4. イノベーションを実現するには、国内外、社内外、技術者、非技術者を問わず、多数の人が関与する。成果を上げ、共通のゴールを目指すために、チームを動かす計画 – スケジュール、仕様 / 性能 / 品質、コスト、リスクを常に確認しながら運用するプロジェクトマネジメントが欠かせない。
ジム・コリンズの「ビジョナリーカンパニー2」より引用 …
偉大なる企業への飛躍に当たって、技術革新は勢いの源泉になっていない。偉大な企業への飛躍と没落を歴史の中で見ていくと、技術革新は偉大な企業の勢いを加速する要因にはなるが、偉大な企業への飛躍や没落の主要因になることはなかった。
偉大な企業は、まず、独自の「規律(仕組みつくり)の文化(=マネジメントの活用)」を築き、規律ある人材を集め、規律ある考えを確立し、規律ある行動をする。
5. 一方、デジタル製品の出荷の遅れや不具合の原因は、不幸にも(下流の工程を担っている)組み込みソフトの欠陥や開発の遅れが原因とされており「見えないソフト」がハードウェア王国日本の足を引っ張っているかのように、言われることがある。これは、アーキテクチャ設計とマネジメントの不在が関係しており、大枠が決まらぬまま、泥縄でソフト開発をすすめ、更に、ハードウェアの仕様変更等のリスクを加味しておらず、収拾がつかなくなった結果である。
6. 技術開発の速度が3倍、5倍に加速されている時代において「スキル(技)の標準化」は、企業活動にとって益々重要な課題であり「個人のスキルを多くの技術者が共有できるテクノロジー(技術)」として継承すべきである。スペシャリストではなくプロフェッショナルの存在が「独自の規律(仕組みづくり)の文化」を生み、それを継承することが飛躍のカギになる。
7. また、現在、多くの企業が導入している「目標管理制度」による人事評価制度は、個人、組織を活気づけるはずであったが、特に技術者の評価基準の定義が困難なことから、導入の効果は少なく、技術者のやる気を失わせ、むしろ、一部の企業にとっては重荷になっている。
8. 個人の力量(個性的な魅力)で成果を上げるタレント社員は、高い評価を受けるが、永続する偉大な企業を築くためには「規律(仕組みつくり)の文化(=マネジメントの活用」を定着させ、且つ、魅力的な規律によって組織を活気づけ成長させるべきである。また、現在、問題にされている「人手、後継者不足」「働き方改革」も容易に解決、実現することができるはずである。
9. さてさて、30年来の開発現場でのマネジメント経験から「項-5 プロジェクトの混乱」は、マネジメントだけの問題とは言い難く「ソフトウェアの見える化 (ビジュアル化) が大きく関係」している。
ソフトウェアの開発は、根幹になるアーキテクチャを設計する際に、ハードウェア、ユーザーインターフェイス、利用する技術等の多岐にわたる情報を理解し、最適化を図る必要がある。しかしこの作業は、スキルによって理解の深さ、設計 / リスク分析の細かさが大きく異なっている。
上流工程でのスキル不足は、泥縄でソフト開発をはじめ、当初の予想以上に工数を浪費し、混乱に陥ったプロジェクトは、関連部門との連携も正常のできなくなり、結果的に、もぐらたたきにより品質は守られるものの、当初の目的の仕様 / 性能を達成できなことがしばしばある。
更に、悪いことに、このようなプロジェクトから創出されたソフトウェアは、あちらこちらに応急処置が施されており、再利用のみならずメンテナンスが、非常に困難になっている。
スキル(経験年数)による知識 / 情報の格差は、プロジェクト内にも存在しており、リーダーはその差を埋め開発を前に進めることに多くの時間を費やし、一般的にマネジメントがおろそかになり、更に、プロジェクト内外とのコミュニケーションに支障をきたす傾向がある。
10. そこで、ファームウェア開発に有効である「構造化設計」とソフトウェアアーキテクチャ設計に大きく影響する「リアルタイムOSの活用のガイドライン」を規律の一部として設定すべきである。
- 制御系ソフトウェアの開発工程とその役割
- 必要な設計書(各行手の入出力書類)とその目的
- それらの管理手法 – Redmineの活用など …
- リアルタイムOSを活用したアーキテクチャ
- モジュール間の入出力、メッセージ・パケットの構成
- メカニズム制御モジュールのテンプレート化
- 共通変数の撲滅
- など
以前から、ドキュメント作成ツールやフォーマルメソッドなる記述方法が提供されており、多数の選択肢があるが、大事なことは単純であり「細部まで検討し設計しているか」そしてそれが「ビジュアル化され、プロジェクト内で情報を共有するための媒体になっているか」がプロジェクトの成功のカギになる。
設計技術は「なぜこれが必要であるか」といった「目的とその成果」を理解することで、様々な形態のプロジェクトへ応用が可能になる。また、関係者のスキルの向上は「設計に漏れが無いか」「モデリングによって情報が整理されビジュアル化されているか」等の生産性の高いレビュー / コミュニケーションをもたらすはずである。
マネジメントとは …
- 関係者が120%のパフォーマンスを発揮できる環境を提供する
- 技術、人材、資産などの側面で付加価値を創出する
- 人を大切にし、ものづくりの楽しさ伝える
仕組みであり、そのリーダーには「強い意志」と「根気と謙虚さ」が必要 …