北陸新幹線の直通運転再開の公式発表からJRの危機感を推測する

先週の話になりますが、2019年10月18日に北陸新幹線の被害状況についての公式情報と全線復旧目途と運転本数についてのリリースがありました。

まず被害状況から見てみましょう。

台風19号の影響による千曲川の氾濫等の影響で、北陸新幹線では長野~飯山間の線路、長野新幹線車両センター構内および新幹線車両が冠水するなど設備等に甚大な被害を受けました。

台風19号による北陸新幹線の設備等の主な被害状況について , 2019年10月18日東日本旅客鉄道株式会社 (引用:2019年10月21日)

別紙にある通り、大きく下記3点に分けられています。

(1)本線の被害
(2)長野車両センターの被害
(3)車両の被害

本線は信号用電源設備の交換が必要そうな様子が画像からわかります。車両センターも既報の通り営業車両のメンテナンスができるような状態ではないことがわかります。車両もやはり室内まで冠水し、おそらく構体内部まで浸水していると思われ、安心して運用できる状態ではないのではないかと推測されます。これは主に過去のQA+記事や他の予測情報でも推測されていた内容です。

注目するべきなのは同日発表された直通運転再開に関する情報です。

台風19号の影響 により、 北陸新幹線の一部区間(長野~上越妙高間)で運転を見合わせておりますが、復旧作業および安全確保の見通しが立ったことから、10月25日より北陸新幹線(東京~金沢間)の直通運転を再開する見込みです。

北陸新幹線(東京~金沢間)の直通運転再開見込みについて , 2019年10月18日東日本旅客鉄道株式会社 (引用:2019年10月21日)

過去のリリースで復旧目途は1~2週間、信号関係以外の復旧が必要な場合には更に期間を要するとの発表がありました。

現時点で信号関係の電源装置に甚大な被害が確認されており、この電源装置の復旧には概ね1~2週間程度かかる見込みです。ただし、信号制御装置等このほかの設備に不具合が認められた場合には、設備の復旧まで更に時間を要することになります。

北陸新幹線及び中央本線(高尾~大月間)の現況と今後の見通しについて , 2019年10月15日東日本旅客鉄道株式会社 (引用:2019年10月21日)

これは当初の調査以上の不具合はなかったということでしょう。まさに当初の見積もり通りの復旧目途となります。更に同じリリースの中で東京~金沢間の直通運転についても言及されています。

長野新幹線車両センターにおける新幹線車両の浸水被害により、限られた車両数での運用となり ます。 北陸新幹線の列車本数 は約8割となりますが、東京~金沢間の直通列車については約9 割の運転本数を確保いたします。

北陸新幹線(東京~金沢間)の直通運転再開見込みについて , 2019年10月18日東日本旅客鉄道株式会社 (引用:2019年10月21日)

上越新幹線用のE7系を優先して投入しても8割程度の本数となるということですが、興味深いのは東京~金沢間の直通列車については9割を確保するという点です。

北陸新幹線には富山~金沢間の区間運転列車である「つるぎ」があります。おそらくこの「つるぎ」の運用を減らして、直通列車の「かがやき」「はくたか」として富山以遠へも足を伸ばす形で走らせるものと思われます。その部分が「列車全体の本数は8割だが直通列車に関しては9割」という部分と思われます。

災害対応から復旧する時には暫定的に少ない輸送量から運用を再開し、設備状態を万全の体制まで復旧させるのが最善ではありますが、「つるぎ」は関西方面から北陸方面(富山)へのアクセス改善のために存在する列車です。「つるぎ」の本数が削減されるということは、多少ではあっても大阪~富山間のアクセスを悪化させる施策です。

ではなぜそこまでして直通列車を優先して走らせるのでしょうか。そもそも高速鉄道自体が長距離大量輸送のために存在するので、直通列車を優先するというのが当たり前ではあります。でも今回の判断が取られた背景には理由が2点あると考えます。

[1]航空路線対策

今回の北陸新幹線の被災に対応して、国内航空会社2社から北陸~東京便の増便が行われていました。10月18~19日の2日間にわたってANAは東京(羽田)~富山線で、JALは東京(羽田)~小松線で増便と機材の大型化を実施しています。

台風19号の影響で北陸新幹線の一部区間が不通となり、東京と北陸地方の間での移動に支障が出ていることから、ANA(全日本空輸)とJAL(日本航空)では臨時便を設定するなどしている。

ANAでは、羽田空港~富山空港間で臨時便を運航。JALでは、羽田空港~小松空港間で臨時便を運航するほか、機材の大型化も実施している。

ANAとJAL、北陸新幹線の一部不通に伴い臨時便設定 , トラベルWatch, 2019年10月17日 11:59 (引用:2019年10月21日)

以下の通り、機材変更(大型化)ならびに臨時便の設定を実施いたしますのでご案内をさせていただきます。

東京(羽田)-小松線、機材変更(大型化)ならびに臨時便設定のお知らせ , 2019年10月18日 日本航空 ,(引用:2019年10月21日)

増便・臨時便のお知らせ

ANA, (引用:2019年10月21日)

新幹線は高速での長距離大量輸送が使命で、航空路線が競合になることが多いものですが、おそらく今回も被災時の対応ではあるものの、JRとしてはそのまま航空路線の利用が定着することは避けたいと考えると思います。そのためには一刻も早く全線での運転を再開するべきというのがJRの判断としてあったと考えられます。

[2]東京からの直通乗客の多さ

「被災した北陸新幹線の営業面への影響を考える」でも引用したデータを見るとわかりますが、北陸新幹線の高崎~上越妙高間(JR東日本区間:2018年度:37,056人/日)と上越妙高~金沢間(JR西日本区間:2018年度:23,001人/日)の平均通過人員ではJR東日本区間に対してJR西日本区間は約60%程度になります。

そのデータで北陸本線の平均通過人員を見ると、米原~金沢間で2018年度には25,825人だったことが分かります(データで見るJR西日本: 区間別平均通過人員および旅客運輸収入(2018年度) )。つまり、関西方面から北陸方面への輸送量を考えても東京直通列車を優先した方がよいということになったと思われます。

北陸新幹線の10月中の直通運転再開により、新幹線の便利さと存在感が再認識されたといってもいいのではないかと感じます。これから年末に向けた首都圏からの輸送力の完全復旧に向けて、おそらく製作中の上越用E7系の納入前倒しなども検討されることと思います。

商品を量産して販売したい時につまずくあれこれ

さて、実際に企画を思いついて試作も実施してみて「良くできたからこれを販売しよう!」と思った時に気が付くことがあると思います。特にそれらは一人(自社のみ)でやっていて、しかも今まで商品を販売したことがないとなると特にいざ品物を発送できるようにしようと思った時に気が付く問題だったりします。

そんな問題をいくつかここにリストアップしておきます。「地道に手売りしていくからそんなこと気にしないよ」という方もいらっしゃるかもしれませんが、今はネットでも販売しやすくなっているので、もしかしたらそういうサービスも利用しようとすると何らかの形で影響するかもしれませんので、気に留めておいて損はないかと思います。

  1. 梱包
  2. 取扱説明書
  3. 保証期間と補償範囲
  4. アフターサービス
  5. 環境規制対応
  6. JANコード

1.梱包

何か袋に入れておけばいいだろと思うかもしれませんが、商品がホコリや傷が付きやすかったりするものであれば何らかの保護が必要ですよね。特に静電気を嫌う電子機器などはエアパッキン(プチプチ)も帯電防止用のものを使う必要があります。

手売りなら袋に入れてお渡しすればいいだけかもしれませんが、もしWeb販売などの通信販売を検討されているならば手渡しというわけにいかなくなってくると思います。その場合一般の物流ルートに乗せることになりますが、輸送中の衝撃で壊れないように梱包する必要があります。

箱を用意するにしても中が詰まってないと箱潰れの要因になりますし、上に他の物を積まないように依頼するにしても、自分が同じ商品を複数発送してしまうとそういうわけにいかなくなります。

商品の破損についてはお客様が購入して梱包箱を開けて使い始めるまでは販売者の責任です。お客様が最初に箱を開けた時(=製造業で言えば受入検査に相当)に不備がないようにしましょう。

かといって厳重にすると梱包そのものにかなり高額なコストがかかります。梱包も原価に含める必要がある資材と捉えて販売方法と輸送の計画を立てましょう。

2.取扱説明書

案外おろそかにしがちなのが取説です。「使い方なんて見ればわかるだろ」とは絶対に言ってはいけません。また取説には使い方だけではなく、やってはいけない使い方、その結果起こる可能性のある傷害レベルも記載する必要があります。

これも手売り手渡しの場合は問題になりにくいですが、通信販売で遠隔地に発送する場合はユーザがどんな人か、またどんな使い方をするかが全く想定できません。ですので取扱説明書である程度の指示を出しておく必要があります。

これも全く何も書面での指示がないと何らかの事故が発生した場合に生産者が製造物責任を問われることになりますので注意が必要です。

特に乳幼児が触れるた場合の安全性についても言及が必要です。また実際に触れる可能性を0にすることができないものであれば安全性の確認もしておいた方がいいでしょう。

3.保証期間と補償範囲

通常1年の保証期間を付けることが多いと思います。またその保証期間内であっても生産者の責任範囲の不具合しか補償範囲になりません。買う側でいる時にはそのことを認識しているつもりでも、自分の商品を買った人がすべてその理解でいるとは限りませんので、補償範囲を明示しましょう。

例えば落下による破損などは使用者の不注意で防げる問題なので、通常であれば使用者の責任範囲になると思います。

使用者の環境で起こりそうな事象とその補償のしかたについて決めておくことは自社のビジネスを守る上で必要なことなので、事業を継続する観点からも必ず実施しましょう。

4.アフターサービス

3の話と関連しますが、何らかの故障が起こった場合にどのように対応するかを決めておきましょう。故障した品物を送ってもらう必要があるのか、送ってもらってもどの程度の壊れ方なら修理するのか、もしくはそのまま新品と交換することになるのかなどの基準を作っておきます。

故障に関する問い合わせやクレーム受付窓口も決めて取扱説明書などに記載します。他の商品でも「お客様センター」などの問い合わせ窓口の記載があると思います。

5.環境規制対応

今環境負荷が低くなるように商品を作ることが求められています。欧州のRoHS指令やREACH規則はよく知られていると思いますが、それ以外の各国で規制がかけられていますので、販売対象地域の規制を確認しましょう。

特にREACH規則などは今後追加される予定の物質に対しても徐々に対応方法の検討を各企業に求めます。商品を作ったら一時的に販売して終わることはあり得ませんので、今後の見通しまで含めて確認しましょう。

6.JANコード

これは筆者も知人のデザイナーに言われて気が付いたことでもあります。小売店に卸売り販売する場合はJANコードがないと商品管理ができず受け入れてもらえないことがありますので、事業者登録と商品登録をしましょう。

弊社でもこれから対応予定です。

事業者登録
https://www.dsri.jp/jan/jan_apply.html

商品登録データベース
https://www.dsri.jp/database_service/jicfsifdb/

完成品メーカはこれらの対応をする部門が存在しますが、中小規模のメーカの場合はこれらの対応部門がないことが多いので手さぐりになります。商品を市場に流通させるときには必ず必要になる要素な上、量産開始後では対応が遅いものも多くあります。漏れがあった場合は仕様設計のタイミングまでさかのぼり、設計上対応できているかも含めて確認しましょう。

これらの項目の更に細かい要素はまた別の記事でご説明したいと思います。

被災した北陸新幹線の営業面への影響を考える

2019年10月12日~13日の台風19号の被害は非常に大きいものでした。各地で亡くなられた方にご冥福をお祈り致します。また被害にあわれた方にお見舞い申し上げるとともに、一日も早い復興をお祈り申し上げます。

前回は車両が水没した北陸新幹線の復旧に求められる要件について考えてみました。

JR東日本から復旧見込みについて発表があったようですので、主に北陸新幹線の部分について確認してみます。中央本線についても言及がありますので、発表資料をリンクします。

【北陸新幹線】
○長野~飯山間の線路が冠水した影響で、北陸新幹線は長野~上越妙高間で運転を見合わせております。現在、東京~長野間及び上越妙高~金沢間で特別ダイヤにて折り返し運転を行っております。


○現地付近の浸水が解消されたことから、15日より長野~飯山間の線路冠水箇所の点検を開始しました。現時点で信号関係の電源装置に甚大な被害が確認されており、この電源装置の復旧には概ね1~2週間程度かかる見込みです。ただし、信号制御装置等このほかの設備に不具合が認められた場合には、設備の復旧まで更に時間を要することになります。これらの復旧ができ次第、長野~上越妙高間は運転を再開いたします。

○長野~上越妙高間の運転再開により、北陸新幹線は全線(東京~金沢間)での運転再開となりますが、長野新幹線車両センターにて新幹線車両が浸水したことにより、使用可能な車両が通常の3分の2程度になります。このため、北陸新幹線全線(東京~金沢間)運転再開後の運転本数はこれまでの5~6割程度となる見込みです。

北陸新幹線及び中央本線(高尾~大月間)の現況と今後の見通しについて , 2019年10月15日東日本旅客鉄道株式会社 (引用:2019/10/16)

地上側設備の被災状況と合わせて車両の被災の言及がされており、やはり運用に投入可能なのは2/3程度、全線での運転再開後の本数は5~6割とのことで、実際に運転再開した後の稼働率が2/3を切るのは、前回のでも書いた運用中の定期整備による運用離脱分も含んでの予測でしょう。

営業用車両は当然定期的に点検と整備が必要なため、地上側の設備の復旧が完了するまでは整備待ちの車両は営業に投入できないことになります。

JR東日本が持つ他の設備を使用するにしても、そちらは他路線で運用中の車両も入るので、順番待ちが発生すれば、北陸新幹線用の電車が後回しになることも考えられ、北陸新幹線の営業に対する影響は0ではないでしょう。

2019年台風19号の鉄道被害と、北陸新幹線の復旧要件を考える, 2019/10/15 QA+

・北陸新幹線の営業力の減少による減収分を予測する

車両が被災した影響は運転本数の減少、すなわち旅客数源による収入減少に現れます。北陸新幹線はJR東日本が営業する高崎~上越妙高間とJR西日本が営業する上越妙高~金沢間に分かれます。

【JR東日本区間の減収分】
JR東日本は「路線別ご利用状況」として各年度ごとの一日当たりの乗客数と最新年度の旅客運輸収入についての情報が公開されています。

高崎~上越妙高間の平均通過人員(人/日)
2015年度 37,050
2016年度 35,899
2017年度 36,127
2018年度 37,056

高崎~上越妙高間の旅客運輸収入(百万円)
2018年度 66,299

JR東日本 路線別ご利用状況(2014~2018年度)より2019/10/16引用

(筆者注)2014年度からのデータで2015年からの記載になっているのは北陸新幹線長野~金沢間の開業が2015年3月14日ダイヤ改正からのためと考えられます。

高崎~上越妙高間の平均通過人員(人/日)は2015~2018年度の平均で36533人/日となります。乗車率は時間によってばらつきがあると考えられますが、輸送力の減少に合わせて一様に乗客数も減るとすると全線での営業再開からしばらくは50~60%の約18270~22000人程度となると考えられます。

また2018年度の収入は66299百万円(662億9900万円)となり、一日当たりの旅客運輸収入に均等割りで換算すると約181.6百万円(約1億8160万円)となります。2019年度も何事もなければ2018年度と同程度の収入があったと仮定して、今回の台風分の減収分を試算します。前提条件は以下です。

・JR東日本発表の全線運転再開後の運転本数がそのまま収入に影響すると仮定する
・ JR東日本発表の全線運転再開後の運転本数が 年度内は維持されると仮定する(他線区からの支援増備が不可能な車両のため、整備が早く終わる以外の補充はなさそうと考えられるため)


全線運転再開後の収入は100%ダイヤ通り運行できた時と比較して50~60%と見積もって収入は約90.8~109百万円(約9080~1億900万円)となり、緩めの見積もりとして60%で運転できたとしても一日当たりの減収額は約72.7百万円(約7270万円)程度にはなりそうです。

仮に2週間後の2019年10月30日で全線で営業再開しても2019年度はあと154日ほどありますので、一日当たり72.7百万円の減収がその全期間にわたり発生したとすると、11195.8百万円(111億9580万円)の収入減となりそうです。これは2018年度の収入の約16.9%に相当することになります。

加えて、2019年10月29日までの15日間は高崎~長野間の区間運転となり、また投入できる車両が限られることからここでの収入減も発生します。高崎~長野間の過去4年度の平均通過人員は約42537人/日で、50~60%の運転本数となると約21268~25522人/日の輸送量となりそうです。

収入に対するこの区間の割合が示されていませんので、ここでは高崎~長野間の収入に関しては計算しません。

【JR西日本区間の減収分】
JR西日本は「データで見るJR西日本: 区間別平均通過人員および旅客運輸収入(2018年度) 」として2018年度の区間別平均通過人員と旅客運輸収入を公開しています。

それによると上越妙高~金沢間の2018年度の情報は以下のようになります。

上越妙高~金沢間の平均通過人員(人/日)
2018年度 23,001

上越妙高~金沢間の旅客運輸収入(百万円/年)
2018年度 42,954

JR西日本  データで見るJR西日本区間別平均通過人員および旅客運輸収入(2018年度)
より2019/10/16引用

JR東日本の場合と同様に、2019年度も何事もなければ2018年度と同程度の収入があったと仮定して、今回の台風分の減収分を試算しようと思いますが、JR西日本については少々状況が違います。その状況の違いを踏まえつつ前提条件は以下のように考えることにします。

・JR西日本の公式発表には上越妙高~金沢間の折り返し運転に関する間引き率の情報がないため、JR東日本の情報を転用する
・ JR西日本区間では金沢~富山間の「つるぎ」があり、また現時点で金沢車両センターにどの程度の車両が留置されているか分からず、またそれらが今後どのように運用されるかの見通しが立たないため、JR西日本区間については実際の運転本数の間引き率はもっと少ない可能性がある


JR西日本区間についてはJR東日本よりも運転本数は多い可能性がありますが、2019年10月16日時点では暫定的にJR東日本と同じ50~60%の運転本数と仮定します。

上越妙高~金沢間の平均通過人員(人/日)が2018年度の50~60%とすると約11500~13800人となります。

また2018年度の収入は42954百万円(429億5400万円)となり、一日当たりの旅客運輸収入に均等割りで換算すると約117.7百万円(約1億1770万円)となります。運転本数を 50~60%と見積もると収入は約58.8~70.6百万円(約5880~7060万円)となり、緩めの見積もりとして60%で運転できたとしても一日当たりの減収額は約47.1百万円(約4710万円)程度にはなりそうです。

JR西日本の営業線区は台風の影響を受けていませんので、すでに運転が再開されています。仮に2019年10月15日から運転を再開し、同じダイヤを維持するとなると2019年度の運転日は169日となります。

47.1百万円の減収が169日間にわたって発生すると、2019年度は約7955.3百万円(約79億5530万円)の収入減となりそうです。これは2018年度の収入の18.5%に相当することになります。

・被災エリアにないJR西日本の特異要素

今回被災しているのはJR東日本エリアでJR西日本エリアについては影響がありません。そのことがJR西日本に与える影響をプラス面とマイナス面に分けて考えてみます。

【プラス面】
・JR西日本エリアは復旧のコストが発生しない
・金沢~上越妙高間の運転は残された車両のみとはなるものの運転区間とダイヤを JR西日本のみでコントロールできる
・W7編成2本がJR東日本エリアで被災していることからJR東日本から何らかの補償 を受けられる可能性がある

【マイナス面】
・東京に直通する「かがやき」「はくたか」の乗客が期待できなくなる
・仮に輸送量オーバーになったり、定期点検で車両が足りなくなったりしても車両 の補充ができない

特にマイナス面のうち、東京からの直通の乗客がいなくなることの影響が読めません。運転本数が維持できても、直通運転がなくなることによる減収の方が大きい可能性があります。

上越妙高~長岡間を特急しらゆきを使用した上越ルートで迂回できますが、特急しらゆきの接続性に依存します。一日5往復の運行ですので乗り継ぎしやすいとは必ずしも言えないように思います。

特急「しらゆき」は、2015年(平成27年)3月14日に北陸新幹線・長野駅 – 金沢駅間延伸開業に合わせ、上越妙高駅での新幹線(主に富山・金沢方面)との接続列車として、1日5往復体制で運行が開始された。新潟県上越地方から柏崎市や長岡市などを経由して新潟市とを結ぶ列車で、このうち3往復が上越妙高駅発着で、2往復が妙高市新井地区方面の利便性確保のため新井駅発着で運行されている。

しらゆき (列車) , Wikipedia, (引用:2019/10/16)

復旧までは、鉄道での東京~北陸方面への移動は長岡・新潟経由か、米原経由かのいずれかで移動するしかなさそうで、北陸新幹線開業以前に戻った感すらあります。

ちなみに筆者はこの運休期間中と思われる時期に北陸方面への移動予定があり、どちら経由で移動しようか検討中です。

・再認識させられた新幹線運行におけるJR西日本の不遇

JR西日本は新幹線の運行において難しい立場に立たされることが多い企業です。JR西日本エリアの新幹線は山陽新幹線と北陸新幹線がありますが、山陽新幹線は東海道新幹線を営業するJR東海の要望から、九州新幹線直通列車の東京乗り入れができません。

東海道新幹線は輸送力に対して輸送量が常にほぼ上限で推移し、編成両数の少ない九州新幹線を乗り入れさせている余裕がないからです。東京駅で東海道新幹線の電車を見ていると16両編成しかないのはそのためで、新大阪まで行けば山陽新幹線区間のみの列車や九州新幹線の列車など種類が増えます。

東京から直通することができている北陸新幹線でも、今回の営業実績を見る限り、北陸のJR西日本区間は東京側よりも輸送量が小さいことが読み取れます。

そのような状況の中直通運転が停止された北陸新幹線は、営業面で被災前に戻るのには少し時間が必要なように思われます。そんな中で特にJR西日本には耐えて頂きたいと思います。

2019年台風19号の鉄道被害と、北陸新幹線の復旧要件を考える

2019年10月12日~13日の台風19号の被害は非常に大きいものでした。各地で亡くなられた方にご冥福をお祈り致します。また被害にあわれた方にお見舞い申し上げるとともに、一日も早い復興をお祈り申し上げます。

台風としては過去に例を見ない規模で関東でも東京都内や神奈川県内で浸水被害があるなどしました。

今回取り上げる鉄道被害でも、神奈川県川崎市での武蔵小杉駅での浸水、長野県での浸水被害で北陸新幹線の長野新幹線車両センターで北陸新幹線用E7系(JR東日本所属車)/W7系(JR西日本所属車)12両編成10本が浸水するというショッキングな映像が流れた他、中央線、両毛線、東北本線の新白河~岩沼間、磐越東線の郡山~いわき間、水郡線の郡山~常陸大子間で運転再開の見通しが立たない規模での被害となっています。

台風19号によるJR東日本管内の設備等の主な被害状況について

2019年10月13日 東日本旅客鉄道株式会社 (引用:2019/10/15)

15日(火)仙台支社管内在来線運転状況について

2019年10月14日 JR東日本仙台支社 (引用:2019/10/15)

施設側、特に土木施設は天候が落ち着いてから復旧作業を進めるしか方法がないですが、車両と整備施設が浸水した北陸新幹線については被害状況の想定が多岐にわたることから現時点で一度想定し、今後JRの対応と照合してみたいと思います。

また、北陸新幹線は2019年10月15日現在、長野駅を挟んでJR西日本側の金沢~上越妙高間とJR東日本側の東京~長野間での運転に留まっています。

・北陸新幹線の路線の特徴

北陸新幹線は、東京~長野間の先行開業まで在来線最急勾配だった信越本線が横川~軽井沢間で越えていた碓氷峠を路線内に含み、また北陸方面で電源の周波数が50Hzと60Hzで切り替わるなど設備上特殊な条件を含む路線です。

勾配は高速走行の妨げになることから最急勾配を15 ‰までとするが、延長2.5 km以内に限り18 ‰・2.0 km以内に限り20 ‰とする。用地や地形の関係から規定以上の勾配を必要とする区間では特別認可の形で設置されており、東北新幹線東京 – 大宮間では25 ‰、北陸新幹線では30 ‰、九州新幹線鹿児島ルートでは35 ‰の勾配が含まれている。

新幹線 Wikipedia (引用:2019/10/15)

北陸新幹線用のE7系/W7系はこれに対応するための性能を有する車両で、設計最高速度は275km/hに留まるものの北陸新幹線内での運用に特化している車両です。E7系が19編成(228両)、W7系が11編成(132両)の30編成(360両)が在籍しています。

翻っていえば、北陸新幹線は他線区の車両を持ち込むわけにいかず、あくまでE7系とW7系を運用する必要があるということです。今回水没したのがE7系8編成とW7系2編成の10編成ということで、総数の1/3が被害を受けたことになります。

JR東日本によりますと、長野市内を流れる千曲川が氾濫した影響で、長野市赤沼にある「長野新幹線車両センター」が浸水し、留め置いていた北陸新幹線の10編成、あわせて120車両が水につかりました。

北陸新幹線はJR東日本が所有するE7系とJR西日本が所有するW7系の合わせて30編成ありますが、今回の浸水でE7系の8編成とW7系の2編成が被害を受けていて、北陸新幹線の全車両の3分の1が被害にあったことになります。

北陸新幹線 車両浸水 全体の3分の1 専門家「最悪 廃車か」 , NHK NEWS WEB, (引用:2019/10/15)

・復旧のポイントと課題と想像される点

土木設備の復旧はその他の路線と同じく天候が回復してから工事が進捗すると思いますのでここでは置いておき、車両とその他設備面で必要となりそうな事項を考えてみたいと思います。

(1)被災車両の整備

まず考えられるのはこれだと思います。しかしこれには上に引用したニュースでも書かれているように課題があります。

多くの北陸新幹線の車両が浸水被害を受けたことについて、鉄道のシステムに詳しい工学院大学の高木亮教授は「新幹線がここまで大規模に水没した事例は今回が初めてではないか」と述べました。

そのうえで「車両が汚れた水につかってしまうと乾いたとしてもそのまま運転すると火が出る可能性があり、完全にきれいにする必要がある。しかし、電子機器などを隅々まで完全にきれいにするのは現実的には難しく、映像を見たかぎりでは、少なくとも床下にある機器類はすべて交換する必要があるのではないか」と指摘しています。

さらに「床上にある空調の配線なども痛んでいた場合は最悪、廃車という事になるかもしれない。ただ、新幹線の車両120両をこれからすぐに製造するというのは難しく、仮に廃車となった場合の影響は利用者にとっても会社にとっても甚大だ」と話しています。

北陸新幹線 車両浸水 全体の3分の1 専門家「最悪 廃車か」 , NHK NEWS WEB, (引用:2019/10/15)

泥水は乾いても土や不純物が残るのでほぼ導体と一緒です。今の電車はインバータで制御するのでその制御機器は半導体装置です。そのまま車両に通電することはこの指摘の通り漏電と火災を引き起こすでしょうし、清掃はほぼ不可能でしょう。

これらに加え、今回は車両がほぼ屋根まで浸水しています。屋根から妻面には架線電源から制御機器に動力用電源を送るための高圧母線が通っています。ですので制御用の主回路から車内の空調や水回りを駆動するアメニティ用の低圧回路までほぼ全て引き直しになると考えられます。

それに加えて今の電車の車体はアルミを使用したダブルスキン構造(Wikipedia 引用2019/10/15)が採用されています。これによって自動車のモノコックボディの様な剛性の高い構体を実現しています。

新幹線はトンネル走行中の気圧変動に対応するため気密構造を持つ車体になっていますが、留置線に置かれている電車は電源が落ちているため、開口部になるドアの気密が維持されていません。ということは車内も浸水していると考えられます。車内の内装はプラスチックパネル等を用いたはめ込み内装も多いため、車内に入り込んだ水はその隙間や窓枠などから構体に流れ込んでいる可能性があります。

その構体に流れ込んだ水や不純物を清掃することは現実的でしょうか。仮に清掃が不十分なまま組立て、走行中にそこに残った乾いた土やゴミが他の箇所に移動し悪さをしないとも限らないとも考えられます。

この様な想像が実際に起こる可能性があれば、JR東日本とJR西日本は被災車両を廃車にせざるを得ないでしょう。廃車分の補充はすぐには難しいでしょうが、2019年現在、JR東日本は上越新幹線用にE7系を増備中です。

上越新幹線への新車投入について   2017年4月4日 東日本旅客鉄道株式会社
(引用:2019/10/15)

これらを北陸新幹線で優先的に運用する可能性は高いと思います。また、仮に電装系統のみ乗せ換えるという判断をするとすれば、やはり上越新幹線用で調達している装置を整備後の既存編成に投入すると思います。上越新幹線で使用する分も含めて追加調達という形になるかと思います。

いずれにせよ上越新幹線のE4系の引退時期は伸びることになるように思います。E4系の延命とともにE7系の補充を続けることになり、E7系/W7系が運用に十分な数に戻るまで、北陸新幹線のダイヤは間引きになる可能性があると思われます。

(2)地上側整備施設の復旧

車両の復旧もそうですが、今回ニュースで流れている映像では7編成分しか見られていません。しかしニュース本文では10編成120両という情報が多いです。残り3編成が整備用庫内で被災していたとしたら、もしかしたら建物や整備用設備と車両が接触して破損している可能性もあると思います。

営業用車両は当然定期的に点検と整備が必要なため、地上側の設備の復旧が完了するまでは整備待ちの車両は営業に投入できないことになります。

JR東日本が持つ他の設備を使用するにしても、そちらは他路線で運用中の車両も入るので、順番待ちが発生すれば、北陸新幹線用の電車が後回しになることも考えられ、北陸新幹線の営業に対する影響は0ではないでしょう。

ここでも北陸新幹線が間引き運転となる要素があることになります。

恐らく、北陸新幹線の復旧に際して大きな課題となる2点について考えてみました。JRの調達計画によってこれらが実際にどのようなペースで実施されるのか、また技術的に別の考察が考えられ、別の方法が取られるのか、今後の状況も注視していきたいと思います。

日本人に足りないのは “Trust, but Verify” かもしれない

筆者は社会人になってから一度大学院に入学していまして、“Trust, but Verify(信ぜよ、されど確認せよ)”はその講義の中で聞いた言葉です。それが何の講義だったかは記憶が定かではないのですが、経営者から従業員に対して仕事などの取り組みの中で使われると聞いた記憶があります。「あなたのことは信頼しているよ。でも、だからこそ確認はさせてもらうよ」という風に言うような事がある、との事でした。

私はこれを聞いた時に「あぁ、外注先の会社さんにお仕事をお願いする時や工程監査などに伺う時、自分もそんな気持ちだったなぁ」と思った記憶があり、それからずっと頭の中から離れない言葉です。

そのことを、サウスピークという英語学校のインタビューを受けた際に答えたことがあります。

–品質保証部の方から確認されるということは、責められているかのような感情を抱かれることはありませんか?

そのような感情をいだかれる方もいらっしゃいます。

ですので、こちら側が信頼していることを伝えることが大事だと思いました。海外では「Trust, But Verify」(信ぜよ、されど確認せよ)という言葉があると聞いたことがあります。相手に対して「あなたと一緒に仕事をしたい」「あなたには一定の技術力があることを評価している」と信頼を伝えること、その後に認識の齟齬を確認していく、という順序が必要です。

相手は、別の会社であれ、別部署であれ、自分たちの製品を作ることに協力してくれている仲間です。良い製品を作り、広くお客様へ届けて、使っていただくことで価値を社会に広めることが目的であることを忘れることはありません。

信ぜよ、されど確認せよ。品質保証の経験者に聞いた目的を実現するための仕事術 , サウスピーク(https://souspeak.com/ks/hinsho-shigoto/),引用日:2019/10/3

・もともとはロシアのことわざ

改めてこの言葉を簡単に検索してみたら、元はロシアのことわざだそうです。

Trust, but verify (Russian: Доверяй, но проверяй; Doveryai, no proveryai) is a Russian proverb. The phrase became internationally known in English when used by President Ronald Reagan on several occasions in the context of nuclear disarmament discussions with the Soviet Union.

Trust, but verify , Wikipedia,(https://en.wikipedia.org/wiki/Trust,_but_verify),引用日:2019/10/3

「アメリカのロナルドレーガン大統領がソ連との非核化協議の中で度々引用していることから国際的に知られた」とあります。

どういう経緯で元の言葉がことわざと言われるほどに頻繁にロシアで使われるようになったのかはわかりませんでしたが、国際的に使われるようになったのはいつ実弾を交えることになってもおかしくない東西冷戦下の非核化協議です。その経緯は、どう考えても和気あいあいとした穏やかな雰囲気ではなさそうです。

当時のアメリカとソ連は、お互いのバランスを崩さないようにただいつ攻められても対応できる戦力を残しながらギリギリの交渉を進めていたと思います。「信頼しているよ」と言いながらその心境はものすごく大きな恐怖心と、かついつ何らかの決断を下す必要が出てくるか分からない緊張感を伴うものだと思います。

・製造業の受発注関係も緊張感を伴うもの

筆者がその言葉を聞いた時、その「信頼している」と表明しながらも「だけど確認はさせてもらうよ」という強さ、「その信頼を実際の形として見せてほしい」と表明する意志が、実は製造業における受発注関係にも求められているし個人的には相手先企業に求めていたことだったなと思い至ったのです。

文化や習慣の違いを前提としたコミュニケーションこそが他社を巻き込むプロジェクトチームに必要な考え方です。

Vol.39 ITプロジェクトこそ、”trust but verify”(信ぜよ、されど確認せよ) , スフィアシステムコンサルティング株式会社,(http://sphere-sc.co.jp/column/2350.html),引用日:2019/10/3

同じ言葉をテーマにコラムを書かれていたIT企業がいらっしゃったので、そのコラムから引用させて頂きました。

そもそも自分にできないことだからこそできる人にお願いする意味があるわけですから、この考え方は外注先と取引する時に絶対に必要な考え方です。

しかしここで相手先企業と積極的にコミュニケーションをとる人はどの程度いるでしょうか。加工屋さんに部品の加工を依頼した時、「頼んだ先に細かいことを聞くのは失礼じゃ…」とか「図面も出したし頼んだんだからいちいち細かいこと言わせないでちゃんとやって来てくれよ」とか思ったりしていませんか?

受託事業を営んでいる会社さんでは発注後何も聞いてこないし確認もしてこないで、品物を納めた時に文句を言われた経験のある方はいらっしゃいませんか?または明らかに知らなさそうなのに知ったように言ってくるなぁと感じたことや、コスト面で有利になりそうな施策が講じられていない図面などが顧客から送られてきたことなどはありませんか?

製造業などの受発注関係でも、コミュニケーション上の緊張感があるんですよね。

・曖昧な点は必ず聞いて確認する習慣をつける

もしわからないことや曖昧な点があるのであれば必ず聞いて確認する習慣をつけることをお勧めします。受注する側であればこの部品が搭載される予定の製品が要求している性能はどの程度で、要求仕様や図面に書かれている内容が製品として妥当なものであるのかを確認してしまってもいいでしょう。図面が受け取れるということは機密保持契約は済んでいると思いますので、逆に業務上聞いてはいけない内容ではないと思います。聞いてはいけない内容なら相手先から「そこについてはお話しできません」と言われるはずですし。

発注側であれば、「自分はできないから頼んでるんだ」とか「頼んでるんだからちゃんとやれよ」とかではなく、頼んだ内容が理解されているか、実現のための道筋が立てられているかを確認する責任があります。その確認をしないまま出来上がったものを見て指摘するのは筋が違いますし、確認を怠った結果そのまま製品が納入されてしまえば修正が必要な場合もあり得ます。

発注するということは自分側にできない理由があることになります。時間的に自社の工程が空かないとか、自社にその設備がない、技術がないというケースもあります。特に設備や技術がなく自社でできない仕事であればわからないことや知らないことがあるのが当然です。であれば、相手側に質問する大義名分ができるのです。その大義名分を活用して、相手側に教えて頂き、勉強させてもらいましょう。その勉強は、必ず次回の発注に役立つはずです。

あえて大雑把なくくり方で書きますが、「日本人」は「行間を読む」ことや「空気を読む」ことを要求しがちです。また空気を読んでしまって、不思議に思ってもその場をやり過ごしてしまうこともあるでしょう。

その行間を読むことは、お互いが協力関係にあり、何らかの目的のために前に進まなければいけない開発の現場であれば、むしろない方がいいものかもしれません。

これからの未来のために、自分の状況を表明しためらわずに声を上げましょう。

「なぜ」と一緒に「もし」を考える

なぜなぜ分析は何らかの事象に対して真因を探る際に用いる手法としてよく聞くと思います。そしてインターネットで検索するとなぜなぜ分析に関する情報ややり方の説明、その歴史などはたくさん出てくるので、読んだことがある方もたくさんいらっしゃると思います。

では、みなさんは実際にお仕事の中でなぜなぜ分析を使ったことはありますか?またはどのようにやるかと言われたらご自身は普段自分でやっているやり方を説明できますか?もしくはなぜなぜ分析を受けた時というのはどういう時でしょうか。

・仕事で「なぜ?」と聞かれると答えづらい

「なぜ?」と聞く時は基本的に原因や理由を知りたい時です。「なぜそれをしたの?」とか「なんでそこへ行ったの?」とかですね。

筆者自身、かつても今も、いろんな方とお仕事をご一緒させて頂く際によく「なぜ?」「どうして?」と質問することはよくあります。またされることもよくあります。

でもですね、普通に考えて仕事中に「なんでこんなことやってるの?」「どうしてこんなことになったの?」と聞かれて気分がいい人はいないと思うんです。仕事でわざわざ質問されるときというのは何か問題が起こった時です。しかもそれが実際にお仕事を頂いている顧客から「なんで?」「どうして?」と聞かれて怖くないわけがないですよね(笑)。

ただ業務上「なぜ?」と問われて答えづらいときにはただ嫌な気分だからとは言い切れない部分もあります。なぜなら、相手が抱えている案件は自社が発注したものだけではないからです。発注側と受注側で機密保持契約と取引基本契約書を取り交わしているとしたら、受注側は他社とも同じ関係を結んでいます。

しかし使う設備や場所は同じ場所だったりするわけです。もしかしたら「どうしてこんなことになったんですか?」と問い質されている仕事の前には別の顧客の案件の対応をしていたのかもしれません。そうであればそこに関連する話題の一部は言えないものかもしれません。

筆者の場合、もし自分が質問する側で、回答する側が答えに詰まるようなケースが起こったとしましょう。そういった場合には「なぜ?」と聞くのを一回止めます。その代わりに「もしかしてこういうことですか?」という一言を挟むのです。

・「もし」が意味するもの

なぜなぜ分析を実施する上でのポイントとして、「質問の回答が得られたらその前段階の疑問が解消すること」というのがあります。

この時、「もしかしてこういうことですか?」とか「もしかしたらこうじゃないんですか?」とか聞くというのは「質問する側としては回答の方向性をこういう風に予測しているよ」という表明になります。そうすると回答者はそれに対して同意する場合は「そうですね」と言いながら実際の状況の様子を教えてくれたりします。違う場合には「いえ、そうじゃないんです」と言いながらやっぱり実際の状況を教えてくれます。つまり「もしかして」という一言は回答を誘発(誘導じゃないんです)するための切り札になります。

この時の「もしかして」というときの注意点としては、自分からあまり話し過ぎないことです。例えば「もしかしてこういうことですか?そうじゃなければこんなことになるなんてありえないですよね?」などと言ってしまった日には「はい、その通りです。申し訳ありません。」で話が終わってしまいます。

たまにここで話過ぎてしまう人がいます。そうするとそれに対して Yes か No の答えしかなくなってしまって、回答者が実際とは違う答えをすることも可能になってしまうので、話過ぎは禁物です。あくまで目的は相手が置かれてる状況を理解し、事象の原因・真因が何なのかをつきとめることです。

・本当に求めるべきもの

なぜなぜ分析の目的として冒頭でも書いたように「事象の真因を求めること」と言われます。まず最初に起こった事象の真因という意味で何が起こったのかを知りたいのはそうだと思います。しかしそれは本当に求めるべきことでしょうか。また実際にその事象を起こした組織が求めたいのはそれでしょうか。

本当に求めたいのは開発する際に、または生産する工程を設計する際に同じようなミスを再発しないことではないのでしょうか?製品の不具合の再発は一回事故を起こせば修正を入れることは可能ですが、そこを次回以降の製品開発時も活用可能な情報にできたらその方が理想的です。

そのためにはその製品もしくはその工程を作っている際に何を考えてそうしたのか、その時に何が漏れていたのかを明らかにしておく必要があります。顧客に対する回答としてはその製品に関する原因究明でも十分かも知れませんが、実は組織内では次回以降の製品開発の効率が上がっていくことが理想ですから、製品開発の活動全体に対する改善活動になる場合が理想です。

すなわちなぜなぜ分析を通じて、実際に業務にあたる際に想定された判断ポイントの条件分岐を想像することが求められます。そのためにはなぜなぜ分析に入る前にすることがありますので、それについては別の記事でご説明します。

品質とは、制御されるべきもの

過去3回にわたって「品質とは」という記事を書き続けました。

品質とは定義されるべきもの
品質とは設計されるべきもの
品質とは管理されるべきもの

品質とは、つまるところ制御されるべきものと言えます。その制御の主体とはその品質を持つ製品やサービスを作っている企業、組織です。企業や組織は、企画した製品やサービスの品質を定義して、それを実現するのに必要な知識や技術、材料を集め社会に提供できる形にします。

「そんなことわかってるよ。うちはちゃんといい品質に維持できてるよ」と思われた方、ちょっと待ってください。「いい」とはどういう意味でしょうか。

・品質はよければいいわけじゃない

よければいいわけじゃないと書いたもののよくするのは実際大変なのでなかなかそこまで行けないんですが…

少なくとも顧客企業から部品の製造を頼まれ、何らかの部品の加工と製造のみを担当するのであれば、顧客の要求を実現することができればそれは「いい」品質と言えます。実際に顧客の要求を実現するのも大変なことがたくさんあると思いますし、その状態を維持するのも簡単なことではないと思います。

しかし、自社で製品やサービスを企画しそれを社会に対してリリースする場合にはちょっと事情が違ってきます。

品質をよくするために何をすればいいでしょうか?
材料をよくしますか?そうすると価格が高くなりますよね。
加工を丁寧にしますか?そうすれば時間がかかります。すると一日の稼働時間を同じにするのであれば一日に作れる個数が減ります。稼働時間を伸ばすのであれば加工の前後の段取りのために作業者を付けなければいけないかもしれません。すると人件費が上がります。

つまり、品質を変えることによってコストと納期が変わります。

・自社におけるQCDの相互作用を理解する

もうお分かりいただけたと思いますが、品質(Quality)というのはQCDの他の二つのパラメータであるコスト(Cost)と納期(Delivery)と相互に影響しあう関係にあります。

コストを削減し、納期を早めたければ品質も抑えることを検討せざるを得ませんし、納期に余裕があれば加工の手間もかけられるかもしれません。むしろ品質を上げることが最優先事項で、多少納期がかかったり販売価格が上がったりすることも許容できるケースもあるかもしれません。


むしろ高級ブランドなどは価格が高くても、納品に時間がかかっても、場合によっては生産数量が少なくてもそのブランドとその商品に見合った品質になっていれば顧客が待ってくれるビジネスというのも存在します。この場合にはむしろ品質は下げてはいけないパラメータになります。

では自社におけるQCDの相互作用というのはどのように見極めればいいのでしょうか。そのための情報は要件定義に落とし込まれる前の企画段階にあります。企画を作った時には以下のようなことが念頭にあるはずです。

  • その企画は誰に向けたものか
  • どのように提供されるのか
  • どのくらいの期間使えるものなのか
  • ユーザはどのように使うものなのか
  • ユーザはそれにいくらくらい払うと考えられるのか

つまり、製品やサービスとして出来上がった時、品質はこれらの項目をすべて含み、すべて合致していなければならないのです。

子供向けの商品であれば子供が使用した時に怪我なく使用できるように、高齢者向けのサービスであればユーザの対象年齢に合わせたサービス内容になっているようにしなければなりません。同じ商品で大人も子供も使う場合が考えられるならば、使用条件がどちらかに偏っていてはいけません。

そして開発され、生産が決まった商品は販売期間中ずっとその企画を実現するために品質が維持された状態で出荷されなければいけません。

しかし「出荷検査で不良がなくても良品率100%にはならない」でも書いている通り、工程に投入される部品の品質は変動するものです。変動するからこそ管理が必要なのですが、品質はその管理によって企画当初に想定された状態に制御されるということになります。

つまり、品質というのは組織によって「制御(Control)」されなければいけないのです。

・“ Quality Control ”を「品質管理」と訳す不思議

どういうわけか日本ではQCというと品質管理と訳されます。でもここまでの話の通り、品質とは「定義」され「設計」され「管理」されることによって「制御される」ものなのです。

ちゃんと品質管理している、いい状態を維持しているということは素晴らしいことですが、その内容はこの順番に従って制御されている結果であることが本来は求められています。

そして組織は品質が制御された結果目標としていた企画を実現するものとなっていることを、品質管理し続けることを通して社会に対して「保証」します。

ISO9001を取得している企業では、組織は品質マネジメントシステム(QMS)を構築し運用することを求められています。システムというのは入力の結果何らかの出力を得るもののことを言います。企業というのは企画をインプットすることで商品やサービスを出力するシステムですと言えます。

つまりこの「品質マネジメントシステムを運用する」ということが、「品質に対して管理値(制御対象となる値)を用いたフィードバック制御を行う」ということを意味するのです。

もしこの話を読んで意外な感じがした方は、ぜひ今一度「自社で行っている品質保証や品質管理は品質を制御できているか?」と立ち止まって考えてみてください。

もしかしたら今まで想像もしてなかったことができる余地があるかもしれません。

品質とは管理されるべきもの

ここまでで新製品の品質を定義し、設計してきました。

品質とは定義されるべきもの
品質とは設計されるべきもの

その品質を管理し、維持するためのシステムを構築するのが生産工程の設計です。
部品の発注先を選んだり、製品設計中から製品の構造から組立工程の構成を考えたり、量産に移行する前に試作品を使って性能や信頼性を評価をしたり、量産に移った後も工程内管理や検査や定期的な信頼性試験を実施するのも全て品質を管理して維持するための行動です。

これらが欠けたら生産する製品の品質は維持できず、歩留まりが下がるか、最悪のケースでは開発中や生産中の品質不良を検出できず市場に流出させることになります。

・開発中の品質管理

開発中の品質管理はまさに「品質の設計」で書いたような部分になります。開発中の品質管理は、製品の品質そのものは作り上げる最中なので、その製品品質を作るためのプロセスが想定通りに稼働しているかどうか、開発プロセスの業務状況が適切かがその管理対象になります。

自社がどのような開発業務を設定し、それに対応するためにどのような組織を作り、開発プロセスを運用しているか(=製品開発のためにどのような段取りをしているか)を決めておき、その通りに業務が進んでいることを確認します。

開発中の業務を通して品質を管理しますが、生産中と異なり、数値で確認するのが難しいように感じるかもしれません。そうであれば、内部監査の結果や日々作られる書類、帳票類の内容の機能に関する項目などを数えるなど、定量化する方法を検討して何らかの指標にするという手もあります。

・生産中の品質管理

生産中の品質管理の目的は開発終了し量産移行した時の品質を維持することです。

工程が当初設計した通りに稼働していることは設備の日常管理で取得できるデータや、各工程間で行われる工程内検査のデータで行っていると思います。
出荷検査で不良がなくても良品率100%にはならない

生産中の管理はこれだけではなく、製品によっては量産中にも信頼性試験を実施します。これも製品の特性や生産数から内容や対象となる抜き取り数が設定されることが多いようです。

・販売後のケア

販売後、不良品が流出していた場合には顧客の手元でその不良が顕在化することもあり得ます。その時のために問い合わせ窓口と修理対応や不良品交換の準備をしておきます。

いわゆるアフターサービスやサポート対応になりますが、この話を管理の所ですることにも意味があります。ユーザの手元で発生した不良品は、そのユーザの使用環境と使用方法によって故障が発生しています。それらは合わせて貴重なマーケティングデータであり設計データです。ですので、ユーザからの問い合わせやクレームをただ面倒なものとせず、その中から使用環境と使用条件、使い方、壊れ方を情報として収集できる体制が必要です。

特に使用環境や使用方法については注意を払って確認します。ユーザは作り手が想像もしなかったような使い方をしたり、想定していなかった使用環境で動作させたりするものです。メーカとしては「そんな使い方しないでくれよ!」と思うこともあるかもしれませんが、逆のことを言えば、ユーザは「こんな場所でこんな風に使えたらこの製品はおもしろいかも、意味があるかも」と感じているということですので、その使われ方をする市場にニーズがあるということです。もし製品仕様として対応できる方法であれば対応させることでビジネスを拡大することができます。

一方で本当に使ってはいけない方法や環境で使っている場合、取扱説明書やパッケージに記載する注意書きの内容が不足している可能性もあります。修理対応の件数によってはその問合せ数に対応して取扱説明書に記載する注意喚起の書き方などをより分かりやすいように変更する必要があります。これらは製造物責任に関連する問題ですのでより注意深く対応します。

ユーザの使用方法や環境が問題ないのに故障が発生している場合、単純に設計上弱い部分が顕在化していることになりますので、市場での不良発生時は開発担当者や設計担当者にも必ず情報を共有し、組織的な改善活動を行います。

これらの管理内容に対応するためには企画時、開発時に適切に品質が設計されていなければ生産時、最悪の場合には市場に向けて販売を開始してから問題が発生した場合に、対応する方法がなく製品を回収(リコール)するしかなくなるというケースも考えられますので、注意しながら進めます。

品質とは設計されるべきもの

製品開発において、定義された品質は今度製品設計に落とし込まれます。要件定義が済んだ状態であれば仕様設計に、仕様設計が済んでいれば詳細設計に移行します。この時、要件定義の結果は要件定義書にされ、仕様設計時の参照書類になります。仕様設計の結果は仕様書にされ、詳細設計時の参照書類になります。

製品や機能の仕様設計や詳細設計が進むと製品に搭載する実際にどんな機能にするか、その機能の性能を適切に発揮するためにどのような構造にするか、技術的にどのようになっていればいいかが整理されてくるはずです。もし整理されていないならその仕様と設計はやり直しです。

・設計プロセスを保有するということ

「これは品質ではなく設計の話では?」と思われる方もいるかもしれません。確かに作業としては設計者の担当作業です。

しかし品質保証担当者はその設計部門内でプロセスがどのように定義されているかを知っておかなければいけません。またその結果としての仕様書や設計書の(当然その前段階の要件定義書も含めて)品質保証担当者は必要な項目が決定されているかを確認しなければなりません。

特に「対象の機能」が「すべての設定条件と設定値」に対して「動作」が決められ期待される「出力値」が定義されているかを確認しなければいけません。この中で一つでも決められていないものがあったり、他の条件の時の被っていたりする場合には設計上不備がないか、製品の動作上問題にならないか確認しなければなりません。

また各条件への分岐点がすべて洗い出せているのかを確認しなければなりません。つまり「書かれている条件だけで大丈夫だ」と無条件に考えてはいけないのです。「もしこうなった場合はどうなるのか」とか「この分岐点にはAとBという条件設定がされているがCは本当にあり得ないのか。Cのような状態が設定されてしまうことは本当にないのか」という問いを、書類に書かれていなくても自分で立て、設計者に問い合わせることが必要です。

「そんなことは設計者がやるべきだ」と思われるかもしれませんが違います。その問いを立てないまま形になった製品はその後工程で誰にも気づかれなければ不具合を内在したまま市場にリリースされます。その結果、その製品はエンドユーザのもとで品質事故を起こします。これはプロセスの適切な運用と管理、製品に対する業務遂行状況と管理が行われていることを確認しなければいけない品質保証担当者にも責任があります。

何より、自分が担当している仕事であっても作業をしている本人が見落としていて、周囲にいる人が気が付いて指摘するなどという場面はいろいろな局面であります。製品の設計作業も同じで、設計者がやったことに対して周囲の目も含めて確認するという行為が意味を持つことは多いので、必ず他職場の関係者を交えたレビューは行うようにします。

その設計書を元に製品設計が進みますが、ソフトウェアを動かすためのプログラムであればソースコードとして文字として書かれるでしょうし、製品に内蔵される機構であれば各条件分岐が物理的に存在します。それらが適切に設計されるプロセスを持っていることが必要になります。

・常に戻れる状態にしておく

どんなに慎重に確認したとしても何らかの見落としや思い込みが組織やチーム全体にある可能性は否定できません。ですので、設計が完了していても後工程で不備が発覚した時には、必ず要件定義書や仕様書、設計書に戻れるようにしておく必要があります。

とはいってもある段階においてはもう戻ることができなくなっている要素が出てくる可能性があります。ですので、重点的に確認するべき機能や要素の洗い出しもしておき、「開発期間のいつまでならこの箇所の修正は可能」という風に修正の締め切り日を設定します。これをしないとある機能aができていることを条件に稼働する機能bが存在した場合、最初の機能aの遅れが2番目の機能bの完成に大きく影響します。

もしソフトウェアであれば関連する箇所を明確にして機能aの遅延の影響範囲を小さくしたりするなどの工夫もできるかもしれません。ハードウェアの場合は構造的に積層される場合は影響が避けづらいので上記のように開発時期を分けるなどして対応します。

開発計画も戻ることを前提に入れて作成します。特に戻ることになった場合の作業内容や対象要素によりある程度作業工数を見積もっておきます。これは開発時に見積もりを作成しているはずなので、その該当箇所を参考にするといいと思います。また実際に手戻りが発生した場合は、状況に合わせて見積もりを元にしながら調整します。

品質保証担当者は修正箇所に対して修正作業が適切に完了したか検証する必要があります。検証作業を品質保証担当者が実施してもいいですし、設計者による検証結果を確認することで代替してもいいでしょう。これは修正箇所の重要度と修正作業の重さによります。

ここで注意するべきは修正が品質に与える影響を明確にするということです。直さなければいけないという事態が発生した場合、「直せばいいんだろう」とか「ほらこれでいいだろ?」とかいう形でただ修正しただけでは品質上の影響範囲が拡大する可能性があります。それを防ぐために品質保証担当者は修正作業の内容を把握しておく必要があります。そしてその作業方針の影響範囲が大きい場合は、検証範囲を調整します。

これらの段取りは開発を進めながら作るものではなく、先にある程度想定しておくべきです。製品も作るし開発プロセスも作るのでは抜けや漏れの発生は必ずあります。開発プロセスの整備は製品開発で可能な限り抜け漏れをなくしQCDをスムーズに作り込むためのものですので、事前にあるべきです。

また、品質面においてこれらの内容で不備があれば自社内であっても工程監査を実施すべきです。それは品質保証担当者が実施するのでもいいですが、製品開発を常に行っているようになったら内部監査部門を作って、社内の業務状況を常に管理しておくといいと思います。これは生産工程での日常管理と同じように業務状況を把握するためのものだからです。

この内部監査部門では開発部門の業務状況だけではなく、製品の環境対応の管理状況やISO9001などの認証を受けている企業の場合はその認証を満たしていることを管理することも業務に入ります。開発プロセスの業務状況の管理はISO9001の認証を受けている場合、ISO9001対応のみ帳票類の内容などの確認が不足するなど自社の業務に不足することも考えられるので注意してください。ISO9001に加えて自社の監査プランが構築できることが理想です。そしてこれらの評価は経営者が業務状況を管理するのに使用します。

ソフトウェアの品質とハードウェアの品質

ソフトウェアやシステムの世界で働いている人にお聞きすると品質についての認識が (加工メーカ、完成品メーカ問わず) ハードウェアの人と違うことに気づかされます。

ハードウェアを作っていても制御にソフトウェアを使うので、ハードウェアの人もソフトウェアから逃れることはできませんし、ソフトウェアの技術者もハードウェアに関連した業種で働いている人も多いと思います。

また、ソフトウェアの技術的な特徴から、その開発の仕方から作り込みのプロセスに関していろいろな方法論が検討されています。その結果、品質や開発プロセスに関しても明文化されている知識が多く、それらを学習することはソフトウェアが搭載される製品を作ってるハードウェア担当の方、またソフトウェアと関連がない(機械加工のみなどの)分野の製品を作ってる方もその考え方は参考になる部分が多い(というか基本的な意味は同じ)と思うので、今後時々話題に上げていきたいと思います。

今回は、私がソフトウェア開発の技術者の方から聞いた中で理解できたその特徴と、ハードウェアの技術者の方が理解しておくと相互理解が進みそうなポイントの概略を簡単に書いておこうと思います。

・ソフトウェアは目に見えない

ハードウェアでも回転しているエンジンの中や走行中の自動車の構造などを見ることはできませんが、ソフトウェアでも同様に動作中の回路の中でプログラムがどのように動作しているか見ることができません。しかもどんなに簡単なプログラムであっても動作させてみるまでちゃんと動作するかわかりません。

ハードウェアの場合は試運転した後分解して動作の状況を確認しますが、ソフトウェアは動作した後の痕跡がプログラム上に見える形で残らないことが多いです。そのために、実際にどのように動作したかはその結果を見ないといけません。動作した時のログを残すようにすることも可能ですが、そのログをどのタイミングで残すかというのもソフト開発上の管理ポイント次第になりますので、管理ポイントの設定ミスがあった場合には本来欲しい箇所のログが記録されないことになります。

また、動作させたプログラムが途中で止まった場合は、止まったところから先の部分に関しては確認ができませんので、その部分は先送りになります。かつソフトウェアで恐ろしいのは、書かれているコードがどのように書かれているかでどこに影響するのかがわからないケースがあることです。

これはものすごく恐ろしくて、動作が想定されていないタイミングである機能が動作した場合、想定されていない事故が発生する可能性があります。それがないように機能の動作仕様を丁寧に決め、製品の状態において各機能がどのような状態にあればいいか整理した上で設計し、実際にそれに則ってプログラムが書かれるようになっていなければならないのです。

逆に言えばソフトウェアに関してはこれらの、何をしたいかを決める要件定義、どういうものを作ればそれが実現可能かを示す仕様設計、その仕様をどのように形にするのかの詳細設計、詳細設計を実際に形にする作業が明確に分けられ、丁寧に実行されます。

これはいろいろな開発プロセスの形がある今の時代でもそれぞれが何らかの形で存在し運用されるプロセスです。

・ソフトウェアを作るのは全部手作業だけどコピーは容易

特に部品の製造をやられている会社などでは、加工機の自動化が進んだ現在では製造は自動化され、CADから読み込んだ図面データから機械の動作を決め加工するのが一般的だと思います。

しかし、まだ多くの場合ソフトウェアは人の手で作られます。そして不具合を直すのも人手です。その分それだけの時間がかかりますし、ミスも発生します。かつ先にお話しした動作させないと分からないという問題があるので、検証用の環境を使いながら作られます。ハードウェアだと各個人が検証設備を持つなど考えられませんが、それが可能であり、それをやらなければいけないのがソフトウェアの世界でもあります。

よくAIの活用が取り上げられますが、そのAIが何をどのように学習するのかも人間が決めますので、そもそも最初に作る時に想定していなければ、自動で学習してくれることはありません。つまり、どんなに技術が進歩しようと、何をしたくてどういう道具と方法でそれを実現しようとするかは結局人が考える部分として残る可能性があります。

その一方で一度作ってしまえばソフトウェアはコピーが容易なので、今まで手作業で実施していた社会の中のある仕事は一瞬で自動化できます。自動機を使用する上でのノウハウは各社お持ちだと思いますが、そのノウハウというのはすなわちそれぞれが仕事をしてくる中で「顧客の要望に応えるためにはこのように工夫しておいた方がいい」という知見です。

その知見こそが、自社の「人が考える部分」になります。もしこの部分がなくなってもいい物であればその会社は消滅し、その会社に勤めていた人は別の仕事で手を動かす必要が出てくるでしょう。この話題はこちらの「カン・コツを明文化する」と同じ内容になりますので省略します。

カン・コツを明文化する
カン・コツを明文化しないと、カン・コツの要らない世界になっちゃいますよ?

・ソフトウェアはハードウェアの制約を受ける

どんなにいいものを作ってもソフトウェアは実装されるハードウェアの制約を受けます。「新しいOSを導入したらパソコンの動きが遅くなった」という経験をお持ちの方も多いでしょう。これはOSがパソコンというハードウェアの影響を受けているからです。

ソフトウェアを動作させるハードウェアの仕様や性能を決めておけばある程度使用環境に対して融通がきく部分もあります。例えばMicrosoftが作るWindowsは市販のWindows用のパソコンに搭載できる部品であればある程度交換しても動作可能です。それはもちろんそのWindowsのバージョンによって要求された動作仕様と性能を満たしていることが条件ですが。

実はここでは機能、動作、構造を分類して一般化、規格化することによって会社をまたいでも共通の認識を作ることが役に立っています。会社の中や組織内部に関してのそのような話については以下の記事で書いていますので参考にしてみてください。
組織を機能させるために必要な3つのこと

ここまでのことを反対から捉えれば、ハードウェアの作りを十分に理解しないままソフトウェアを作る事は非常に困難なことばかりか、ハードウェアを破損する、最悪の場合にはその破損によりユーザの身体の安全を脅かす事故を起こす可能性があります。

同じ製品に搭載されユーザに価値を提供する以上、ソフトウェアとハードウェアの相互理解と技術的特性を生かした役割分担は必ず有効に働くはずです。またその技術的特性の違いがあっても、その技術的アプローチには学ぶところが多いと思います。

自分の担当する技術分野以外の情報を集める意味でも、その特性を理解することは意味があると思います。