2．競争領域の変化と持つべき視点

自動車をはじめとする工業製品の電子化・電装化は時代を表わす奔流とも言え、その話題は枚挙に暇がありません。ハードウェアのものづくりからソフトウェアのものづくりへの軸足の移動が進むのは、自然な流れとは思われますが、潮流の速さは「自然」と呼べるようなレベルにとどまりません。ネットワークを介した情報の海（インターネット）への窓口は、IoTというキーワードであったり、コネクテッドというキーワードであったりもします。しかし、それは無限の事象や不確定要素が想定されるパンドラの箱を開けるが如き挑戦のようにも思えます。

ここで、ソフトウェアのものづくり（システム開発）を考えてみます。システム開発では、要件定義と言われる「何を実現しようとしているのか？」というゴール設定の工程に重きがあります。残りの工程は、その内容の実現に向けて機能構成を決め、その機能が実現できるプログラムの構成を決め、というブレイクダウンが行われて進むものです。

プログラムの集大成となるシステムは、要求される個々の機能の実装とそれらの統合によるユースケース（要件定義で決めた利用シナリオ）の実現という目的達成が第一義ですが、それだけでは一般にシステムは日の目を見ることができません。システム開発に関わった方なら、ご存じかも知れませんが、システム性能（操作レスポンス）などの非機能要件（目的とする機能以外のものであるが、システムとして実現せざるを得ないもの）も作り込みが必要です。これは、内部的な品質の一つとされるもので、広くはRASIS（Reliability：故障しにくいという信頼性。Availability：高い稼働率を維持できる可用性。Serviceability：障害が発生した場合に迅速に復旧できる保守性。Integrity：データが矛盾を起こさない保全性・完全性。Security：機密性が高く、不正アクセスされにくい安全性 ）と呼ばれる５つの観点が要求されます。少し大雑把な喩えですが、一般の工業製品では、素材や部材の持つ特性として具備されている様なものを、ソフトウェア開発では知恵を凝らして作り込む必要があるということを意味しています。

システムの機能を構成する１つ１つの要素（プログラム）は、関係者の決め事の中で生まれてくるものであり、ここで言う非機能要件も含めて、様々な仕様検討や設計・開発・テストが必要になります。 かくして、システム開発は機能要件の規模が大きくなるほどに、幾何級数的に時間とお金がかかるという様に、難物化するのですが、プロジェクト当初に正確な作業見積をすることは難しく、トラブルも起きがちです。特に大型のプロジェクトは、開発者のコミュニケーションや知識レベルに依存した問題が付きまとい、失敗するリスクも大きくなります。従って、リリース後（提供した後）にソフトウェアの修正を行うという必要性に迫られるわけで、認証を受けてから量産を始められる自動車などの工業製品とは性質が異なります。

この様な、一般のものづくりと比較して進め方の難しいソフトウェア開発を主役として、今後のものづくりが拡がるとしたら、どの様な対策を打てば良いのでしょうか。製品開発において、年々大きなコストを占めるようになっている（中核となる）ソフトウェア開発を、どう品質向上していけばよいのでしょうか。

3．これからのものづくりの在り方

ものづくりは人づくり、という言葉がありますが、その視点から考えてみます。

社会的な話題から入りますが、働く人の健康を守るという目的で、平成27年12月から50人以上の会社にはストレスチェックが義務付けられました。この時代は、メンタルヘルスの不調が起きることは珍しくなく、それが重篤な状況まで進むことを食い止めることが必要とされており、この対策としての制度が求められたわけです。

残念ながらストレスチェックは単にチェックであり、治療にはならないことを認識しておく必要があるかと思います。個々人からアプローチするなら、レジリエンス（抵抗力）の強化や、マインドフルネス（今の自分の心に気付き、受け入れる）といった手法が話題になっています。組織の中では、仕事の指示（業務命令）も、コーチングやアサーティブといった気持ちを動かす会話テクニックを使うことが望まれます。業務上の活動の方向性についても、成果を追求するMBO（Management By Objects）ではなく、MBB（Management By Belief）といった人の「思い」を重視した内容にすることで、個々のメンバーの内発的動機を育むことを狙います。

つまり、責任を明確にして問題の原因を問うことで人が鍛えられた時代は終わり、チームで課題を考えて解決したり、仲間のために頑張ったり支え合う時代になってきたのだと思います。余裕のない世の中でもありますし、新しい時代なりの温かさや信頼感を育てることが重要になっているとも言えるような気もします。

そもそも、考えてもみれば20年、30年前と比較すると企業経営のことにしても「株主経営」や「ガバナンス」、「ISO導入」や「コンプライアンス」、「リスク管理」と格段に煩雑な状況になってきています。それらが組織内に波及・伝搬した結果として、現場の担当者に要求されることも増え、新人でさえも、多種多様な社内システムの操作を学ぶ必要があります。私自身の経験からも、30年ほど前の入社の頃の「本業に打ち込めた感覚」が、昨今の職場では得られ難くなっていると感じます。この複雑化した環境の中で、乱暴に力技で課題を解決しようとしたり、他人に課題解決を強いると、様々なハラスメントさえも起きます。

ソフトウェア開発の話では「様々なルールや決め事に縛られる仕組み作り」、「成果物が容易には目に見えない」、「頭で考えることが多い」という特徴があり、気持ちを内側（下側）に向けてしまう人や、深く考え過ぎる傾向の人は、いとも簡単にメンタルな問題に傾きます。そうなるとチームの中で問題が起きがちになり、当事者であるエンジニアの現場からの離脱が起き、残る人の仕事は増え、問題の連鎖やプロジェクトへの悪影響が広がります。そんな場面では成果物であるソフトウェアの品質問題なども起きがちになります。

当然ながらソフトウェア開発においても、品質の可視化と指標の管理メソッドはありますが、それは作業した結果や作ったものの計測であり、実体を測ることとは異なります。実体が見えないために、その内容を表した数値を多面的に管理していくことが重要になります。旧来のものづくりでも、品質の作り込みを前倒しすることが重要ですが、ソフトウェアのものづくりでも問題が起きる前に対策する、という未病に取り組むアプローチが求められます。昔のものづくりでは、4M（Man、Methods、Machines、Materials）の管理という見方がありますが、ソフトウェアのものづくりでいう4Mは「Man、Motivation、Methods、Measurements」の管理といった方が的確であるような気がします。思いによって動機付けされている人とチームで、手法やルール・指標を明確化して取り組み、結果を測る、というアプローチです。

一般に「人を育てる」ということを考えると、責任を持った仕事を渡し、権限を委譲し、失敗することを受け入れて、となりますが、今時は「責任を持たせた時点で、ストレスに耐えられなくなる」という話も多いものです。当然ながら意識付けをして進めるのですが、必要以上と思える程にハードルを下げたり、個人でなくチームの責任とすることも考える必要があります。働き方改革で言われる様な多種多様な人材活用を考えると、我々自身が不可避の意識改革を突きつけられているかの様です。これからは、「セイフティネット（悩みを持つ人を救う安全網）」を準備し、道具や技術の面だけでなく、課題に臨む気持ちもサポートしながら、ひな鳥の巣立ちを見送るような、手厚いサポートが必要な時代である様に思います。

山本五十六の言葉を振り返ってみると、「やってみせ、言って聞かせて、させてみせ、ほめてやらねば、人は動かじ」というものがあり、この言葉の後には「話し合い、耳を傾け、承認し、任せてやらねば、人は育たず。 やっている、姿を感謝で見守って、信頼せねば、人は実らず」というくだりもあります。70年ほども昔の方の言葉ですが、当時からも感謝や信頼、見守る上司といったものが実際に必要だったのでしょう。そう言えば、昔のものづくり現場では、兄貴分の班長さんや作業長の姿がありました。何か問題が起これば、親父役の課長さんに一緒に相談に行くシーンもあったかと思います。その意味では、本質は今も昔も変わっていないのかも知れません。

現在は、スマートなものづくりとして、現場は整然と無人化され、データを元に開発と製造を進める姿が求められています。IoTもIndustrie4.0の是非を議論することも重要ではありますが、これからの日本のものづくりを考えた場合には、何よりも思いを持った仲間が支え合う仕組みを最優先に考えるべきなのかも知れません。