■新製品開発 ３ （No.404）
新製品開発の続き。続いて，部品の開発ではないが，ソフトウェアの開発について述べる。
ソフトウェアの開発
ソフトウェア開発は直接経験したことが無いが，４ビットのマイコンを使ってソフトウェア部分を外部委託で依頼したり，別な場面では大掛かりなソフトウェア開発を開発側と一緒になって品質向上に携わったりしたことがあるので，その経験から述べてみる。
マイコンが部品にも組み込み搭載された出始めは，４ビットマイコンが殆どであった。それまでハードウェアが中心で，カスタムICの設計でもトランジスタの組み合わせで，ハードウェアしか扱ったことのない技術者にとって，ソフトウェアは異質であったため，必要な仕様は提示するものの，外部のソフトウェア会社にその部分の設計は委託して，フローチャートなどで検証するとともに，部品性能として機能が満足しているか，実験を重ねる程度で始まった。当初の苦い想い出は，マイコンが特殊な環境下ではハングアップして（止まったままの不動作状態），市場改修までした苦い想い出があります。ソフトウェアの難しさをしみじみと味わったものです。
ソフトウェア開発の大掛かりな開発に携わったのは，数年前，定年後新たな仕事で，直接のソフトウェア開発ではなく，品質部門で開発側と一緒になって，開発のプロセスをチェックする役割を担っていた。ソフトウェア開発はご存じの方も多いと思うが，品質の善し悪しは開発段階で決まる。即ち，開発のプロセスがきっちり決められた通りに行われているか否かで，品質が決まる。バグ（ソフトウェアの欠陥）はどれほど注意深く設計する人でも，或る確率で発生させる。だから，開発のプロセスの中で，市場問題にまで発展するような致命的なバグを如何にして撲滅させるかが決め手になる。ハードウェアのように，実験評価で問題点をあぶり出すには，ソフトウェアの構造（システム）が複雑で，欠陥を見つけ出すことが不十分になる。
したがって，ソフトウェアの手法として，理想の開発プロセスが提唱されており，全体のシステムから，個々のソフトウェアの部分まで，地道なテストプロセスが設けられており，単体での検証から，結合した状態，システムになった状態と如何に膨大なシステムでも，単体からきっちりとバグを抽出していく方法が取られる。ここで手抜きをすると後で大きな痛手を受ける。したがって，各々のプロセスが確実に行われ，バグの抽出が想定通りになっているかチェックされ，次の段階へ進む方法が取られている。
実際の設計に当たっては，先ず製品全体から見たソフトウェアのアーキテクチャ(基本設計概念）や要となる部分は社員が自ら設計し，その枝葉となる部分は，外部委託（社内に入り込んでいる派遣社員のケースも多い）に任せていることが多い。それは，ソフトウェアの設計が年々膨大化しており，何億円も掛かるような設計もあり，社員ですべてを担当することは，人員も不足しているし，人件費も大きくなるので，安い外部委託に依存していることが殆どである。そうしたケースでは，社員は設計をすると云うより，外部委託のコントロールをする手配師のような役割を担うハメになっている。
以前にも紹介したが，オフショア開発（No.１４８，No.１４９）と称し外部委託を海外に求めて行くケースも多くなっており，それにはいろいろな問題が生じている。ハードウェアの海外への委託は難題が多く，余り行われていないが，ソフトウェアの場合，開発設備も容易に調達でき，ソフトウェア言語と云う共通の言語で開発が可能で，製品仕様を明確に示しさえすれば，開発が進められている。ただ，開発費が安価に抑えられるメリットを得るには，様々な問題点が潜んでおり，十分検討した方がよい。（オフショア開発の問題点 No.１７２，No.１７３）
開発状況は拡大しているが，問題点もいろいろある。リーダには，如何に計画通り（時間・費用・品質性能確保）に進められるかが要求され，プロジェクトマネジメントの上手い運用が必要条件である。ただ，プロジェクトマネジメントの知識がある，或いは資格を取得していることよりも，如何に問題点が整理でき，素早く適切な対策が取れるかが重要である。実際，それがそつなくできるには経験も必要なため，若手のリーダでは混沌としてなかなか解決策が見出せず，初期の目標を達成できない負のループに陥ってしまうこともしばしば見掛ける。
問題点に対して対策を打つことは誰でもできるが，往々にして原因を突き止めず，事象に対する対策しかできず，モグラ叩き状態になることも多い。上手なリーダは，起こっている事象とその原因の切り分けを素早く行い，原因に対する対策，及び再発防止策を的確に打って対処する。ただ，問題点が広い範囲に亘っていることが多く，且つ，事象が複雑に絡み合ったものもあるため，幅広く，且つ高所からの判断も要する事案が増えてきている。
経験した中では，ソフトウェア設計者（リーダを含み）には，顧客から遠い位置で仕事をしている人が多く，顧客に対する配慮が殆どできていない。例えば，プロジェクトマネジメントでプロジェクトの完了後に振り返りをきっちりやることは素晴らしいことだが，その中身は，プロジェクトを通じての反省点を担当者にアンケートを採るなどと云った，どちらかと云えば細部の反省で，満足してしまっていることが多い。それ自体を否定するものではないが，本来プロジェクトの振り返りとあれば，顧客（後工程）に対してどうだったかが一番重要で，それらに対する反省点で，次のプロジェクトの改良ができるわけで，内部の担当者の些細な弁明は，顧客に対する反省点から導かれたものであって欲しい。顧客重視とは名ばかりで，振り返りで，顧客視点の反省を指摘すると，キョトンとしたリーダが居たのには驚かされた。
開発が大規模で顧客から離れたところで，製品全体の極一部を担当することが多いソフトウェア開発のリーダにとって，余りにも目先の問題に終始していることが多い。仕事柄，画面に向かって詳細な検討にばかり神経を使っていることが多く，致し方無い面は理解できるが，上司など高所から，リーダに対しての適切な指導が必要であるように感じる。本来重要な顧客（後工程）に対する配慮が全くできていないのは，私が経験した部署固有のことではなく，ソフトウェア開発に携わっている多くが，そうではないかと心配している。
顧客と離れた形で仕事が進むと技術者は益々技術指向に陥りやすい。つまり，新しいアイディアや新しい機能の追究に溺れ，顧客が求めているものとは違ったものが出来上がってくる。顧客から見た反省が無いと，技術者は組み込んだ技術内容に満足することが多く，自己満足の域を出ない。本来，ソフトウェア開発も顧客の喜びや感動を与えるものに仕上がることが狙いであるべきで，顧客を無視とまでは行かなくても，顧客の声がフィードバック掛からないような仕事運びでは，良い製品は生まれない。
マーケットインはソフトウェア開発者には欠落していることが多く，顧客や後工程のことへの配慮が少ないように感じられる。どれだけ素晴らしい技術を盛り込んだ内容でも，顧客や後工程に喜びや感動を与えないようでは，価値が半減することを胆に明示すべきである。単に顧客に媚びるのでは無く，顧客や後工程の評価を大切にする開発リーダこそが，成長を約束されていると言えるのではないか。
ソフトウェア開発で，顧客重視を実践できているリーダがどれほどいるのだろうか？
[Reported by H.Nishimura 2014.12.22]
Copyright (C)2014 Hitoshi Nishimura