品質からビジネスと経営を考える
今まで顧客からの発注に対して、材料を加工して納品してきた加工メーカが自社で製品を作り販売し […]
マーケティング 中堅社員向け 企画者向け 品質保証 外注先との連携 技術者向け 新製品を開発する 管理者向け 経営者向け 製品を販売する今まで顧客からの発注に対して、材料を加工して納品してきた加工メーカが自社で製品を作り販売しようとするといろいろな壁に直面します。今まである会社に勤めていた方が新しい職種、職場に転職しようとすると、実際に内定を得るまでに多くの企業が要求するスキルとミスマッチがあることを実感します。
今までにやったことがないことをやろうとすれば絶対にそこには足りないことがあるはずです。そして、特にビジネスにおいてやりたいと思い実際に足りないことを痛感するのは新しい領域に手を出そうとする時だと思います。
筆者は今初めて自分の会社で企画した製品のリリースに向けて活動していますが、その過程で感じたはまさにことを今のタイミングで簡単にまとめておこうと思います。
・一番どうにかなるのは方法=技術
自社製品を売り出そうにもまずは企画を考えなければいけません。実は今進めている企画はある材料と出会えたことで発想したものでした。つまりその材料との出会いがなければ思いつかなかったものでした。シーズベース、プロダクトアウトから始まった企画と言えますね。
そしてその企画を思いついた私はメーカからもらったサンプルを使用して機能試作品を作りました。それを自社が出展するあるイベントでプロトタイプとして展示しました。
そうしたらそれを見たイベント参加者はかなりの確率で私の製品に目を留めました。足を止めて見るまではいかずとも、「あれなんだろう」という表情で見ながら通り過ぎたり、時にはプロトタイプの前で立ち止まり「へー」と言って立ち去る人がいたりしました。
その中の何人かは「これどうなってるんですか?」とか「これはなんですか?」と質問して下さり、「それだったら自分はこういう時に使いたいです」と、それぞれが想定した使用シーンの話をして下さいました。
企画は思いついただけでは実行を判断するだけの情報になりません。実際に市場にリリースした時のお客さんがいなければそもそもビジネスにならないのですから、企画を思いついたらその企画にお客さんが付くかどうか確認しなければなりません。私はそれを自分が出展するイベントで実施しました。
「お客さんがいるか分からなくて不安」であれば実際に探してみればいいのです。自分が思いついた企画が本当に自分が思ったニーズがあるかどうかを確認していなければそれはビジネスではなく趣味でしかありません。
一方でその企画を思いついて、お客さんがいるとしてもそれを自社が作れるか分からないというケースもあると思います。その場合はその機能がどのように構成されるのかを考え、それを何らかの形で形作るものがこの世の中にないのか、探せばいいのです。案外やってくれる人や企業がいると思います。つまり、実は思いついたことを実現するための方法(=技術的なこと)は、案外どうにでもなるのです。
方法論が問題になるのは実際にリリースした後、コストと工数(納期)が見合わないとか、品質を市販レベルにするのに要求される作業がものすごく難しくてコストも納期も圧迫してしまうとか言う場合です。これは単純に工程設計が甘いだけなので、リリースを公表する前に量産性確認をすればいいだけです。
ちなみに量産後に量産性不良で困る人のタイプは大体決まっています。全部誰かに任せて自分では手を動かさない人です。企画を考えたのがあなたなら、あなた自身が一度は必ず手を動かしてみましょう。実現可能かどうかすぐわかるはずです。
・プロダクトアウトかマーケットインか
一応簡単に説明しておきますと、プロダクトアウトとはシーズベースで製品開発を始めることです。製品や技術が先にあって、その活用先を考える企画の立て方です。中小企業、特に製造業の方が商品開発をするときはどうしてもこの形になりがちです。元手をあまりかけないようにするため、自社にある材料と機械で開発しようとするからです。
一方でマーケットインとはニーズベースです。使い手がいて、どういう時にどういう使い方をする道具を作りたいかで、商品企画をします。
個人的にはこのどちらかで迷う必要はないと思います。理由としては買い手がつく可能性が未知数の企画に対して元手を掛けたくないのは誰でも同じで、一方でユーザがいるかいないかはどこかのタイミングで必ずわかることだからです。
上に書いたように私自身最初は品物を見てアイデアが浮かびました。その後、機能試作品を人に見せたことで、そこで聞いた意見でマーケットがあることを理解しました。ちなみに買い手になりそうな業界は複数あることが分かりましたので、今後それぞれの業界に合わせてプロモーション戦略を立てなければいけないという状況にあります。
技術が分かるというのは大きな強みです。企画さえ思いつけば実現への段取りを構築するのは早いはずです。一方でユーザの存在を見つけられていないというのはビジネスとして致命的です。
・常に新しい世界を探しに行く
歳をとればとるほど職場と家の往復で日々が過ぎていくようになる人が増えます。これは仕方のないことですが一方で新しい世界に触れないと自分の技術が必要とされる世界が他にないのか見つけることができません。かといって、違う業界の見本市や展示会にいきなり出展したところで新規の顧客が付くとは限りません。既にある業界は特に国内の業界の場合は既存の企業で成立していて新規の参入が困難なことがほとんどです。
そんな中で新しい企画と新しい顧客を発見するにはもっと思い切って視点を変化させる必要があります。今まで何気なく帰っていた自宅、自宅で生活している家族の様子から何か家事で使える物が作れないかとか、自分の趣味に通じるもので何かできないかとか、業界から、場合によっては仕事からも視点を変える必要があるかもしれません。
しかし「そんな小さい商品では自社の売り上げ構成比率が変わらない」と言って新規事業に踏み出さない企業も多いのが現状です。でも考えてみて頂きたいのは、そもそもあるかどうかすら分からない市場に新しい製品を持っていくんですから、はじめから売り上げが立つことを期待する方が間違ってるはずです。何らかの動きを起こす方が先ではないでしょうか。
技術の不足の話、ユーザの発見、企画の見つけ方と3つに分けて大雑把に書いてみました。足りない、分からないということが分かってるなら十分にアクションを起こす理由になります。
それさえクリアできれば、先へ進めるはずです。
毎年、年一回開催されるあるイベントの撮影を担当させて頂いております。今年もそのイベントが終 […]
マーケティング 中堅社員向け 人材 企画者向け 技術者向け 新入社員向け 現場向け 管理者向け毎年、年一回開催されるあるイベントの撮影を担当させて頂いております。今年もそのイベントが終わり、納品も完了してほっとしたところです。
その写真はイベントの主催者が広報素材としてSNSやパンフレット、フライヤーにしたりするのですが、イベントの現場写真というのはいくつかの意味で撮影することが多いです。
1はご理解頂けると思いますが、「開催しました!」という形でSNSなどに掲載される写真ですね。参加者がみんな笑顔になっている集合写真などと合わせて投稿されるとそれなりにインパクトがあります。
3は意外かもしれませんが実際に要望があることもあります。今では講師がそれぞれご自身のSNSやWebサイトなどで発信されることも多いので、それに使うためにご要望があります。
大事なのは2です。2の難しさは2つあります。ひとつはその写真を見て「この会おもしろそう!行きたい!」と思わせないといけないこと。ふたつめは次回以降も同じ状況や構成で開催されるか分からないのにその時にもある程度対応できる必要があることです。
・PRのためにイベントを撮る
実際の所、「次回で大幅に構成を変えることになったので前回のは使わなくなった」と言われることもあります。ですが会の構成が変わっても会場のセッティングが近ければ会場風景として使える可能性がありますし、聴衆が講演内容に聞き入っている顔や懇親会などの談笑風景は汎用性がありますので一通り押さえるなど工夫します。
※この時には必ず主催者に参加者に対して撮影される可能性がある事、その写真が公開される可能性があることは必ず周知することを依頼します。依頼できていない場合はどんなに主催者のためになるシーンであってもカメラを向けないなど撮影しないようにします(念のためと思って撮影してあって、一応注釈付きで納品した場合、万が一その注釈がクライアント側で周知されず公開されてしまうと大問題になるのでそもそも撮影も納品もしません)。
「行きたい!」と思わせるには参加者が楽しそうにしているか、体験する価値がある(イベント側が売りにしている)ワークなどが含まれている必要があるので、ある程度聴衆の雰囲気も含めて撮影します。この時、上の※の内容がフォローされてないと聴衆の表情が撮れないので、やはりある程度参加者への周知とカメラマンへの配慮というのは必要になります。
・カメラマンとカメラはイベントにとって「異物」
イベントというのは主催者と参加者がいて成り立ちます。他に必要な物はどこかしらの会場だったり、主催者以外の出演者や登壇者、講師などの人たちです。
お分かり頂けるようにイベントを開催するための構成要素にカメラマンは存在しません。つまり、イベントを撮影する目的が上に書いた1~3のどれであれ、またイベントを撮影するカメラマンがプロであれ、主催者側のスタッフが撮るのであれ、イベントそのものには不要なものです。
不要なものが入る以上イベントの参加者が得る体験価値自体をカメラマンが毀損する、下げてしまう可能性があります。カメラマンはその価値を下げない努力をすべきです。
そのために一番必要なことは何か?その答えはものすごく簡単なことです。カメラマン自身がイベントの価値を理解し楽しむことです。その場の講師や出演者の熱意、参加者の雰囲気に合わせることです。最低限の態度として、その場の雰囲気を乱すような行動や表情は絶対に出してはいけません。
・自分が笑顔でいれば相手も笑顔になる
少なくともカメラを持って人前にいる時点で、自分は他の参加者やスタッフよりも目立つ存在であることを自覚することです。そんな自分がふてくされてたり、眉間にしわを寄せていたり、ましてや無表情でずっと会場前方で液晶モニターをのぞき込んでいたりしては参加者が持つ印象は悪くなるばっかりです。
またイベント中はどんなことがどのタイミングで起こるか、それによって参加者がどんな表情をするかを常に見ていなければなりません。仮にタイムテーブルが決まっていてもそのタイムテーブルに沿って起こることを撮るためには会場全体を観察している必要があります。
そのためには顔を上げて会場を見ていなければいけないのですから、参加者はカメラマンの顔を見られる状態になるわけです。そこで不機嫌そうな顔をすることは参加者の気分を悪くします。結果として、参加者がカメラマンが持つカメラに対していい表情を向けることはあり得ません。
それを逆手に取り、どんな時にも笑顔で(笑顔が不自然な時もありますが)、前向きさが感じられる表情でいれば参加者は違和感を感じにくいですし、それに伴って場に溶け込むことができます。
笑顔の相手が撮りたければ、まず自分が笑顔になることです。
なぜ突然こんなことを書き出したかというと、やはり時々会場に溶け込めずにいるカメラマンを、参加者として訪問したイベントで見かけることがあるからです。
特にその主催者(企業)のチームのうち、若い人が記録係を受けていたりすることもあり、ご苦労されているシーンもよく見かけます。
ただせっかくカメラを持ってその場にいる以上は、その方がプロであるかどうかに関わらず、いい写真を持って帰って今後に活用して頂いた方がよかろうと思い、こんなことを書きました。
写真は企業にとってPR素材です。品質の高い素材を多く揃えて自社をアピールできるようにしましょう。
ミスをした時やアウトプットが想定よりも低かった場合、「ちゃんとしなさい」とか「きちんとしな […]
中堅社員向け 企画者向け 品質保証 外注先との連携 技術者向け 新製品を開発する 現場向け 生産プロセス 管理者向けミスをした時やアウトプットが想定よりも低かった場合、「ちゃんとしなさい」とか「きちんとしなさい」とか言われた経験がある人はたくさんいると思います。子供のころテストの点数が低かった時、「ちゃんと勉強してないからだ」と親に叱られたり、大人になってからご自身の子供が部屋を片付けない時に、「きちんと片付けなさい」と注意したり。
ではなにができてたら「ちゃんと」しているのでしょうか。どうなっていたら「きちんと」したと言えるのでしょうか。テストであれば100点に近ければ近いほど「ちゃんと勉強した」と評価されやすくなりそうですね。部屋の片付けであれば余計なものが床や机に出ていなければ「片付いている」と判断されるかもしれません。
ご自身が叱られた時、また誰かを叱った時、この「ちゃんと」や「きちんと」の中身を定義して叱ったことがある方はいらっしゃいますか?仕事の時はこれを定義しないとアウトプットに悪い影響を与える可能性があります。
・バラつきは言葉から生まれる
品質は製品開発と製造から得られるアウトプットです。アウトプットは製造された品物であったり測定されたデータです。それらは工程中の作業で作られ、工程中の作業は作業手順書に従って行われます。その作業手順書は製品の設計書から作られますから、帳票類の表現がそのまま落とし込まれます。
品質を安定させるためには帳票類に記載される文言のブレをなくす必要があります。そのために、まず最初に形容詞や副詞を排除し道具と方法の指示(名詞と動詞)と数字もしくは画像などによる設定値や出力値の明示を行います。
それぞれの帳票を作る時もそうですが、前工程で作成された帳票を参照して次の帳票を作る際にも解釈が人によってブレそうな部分は前工程の担当者に確認した上で書き換えます。
・曖昧さやわからないことは形容詞や副詞の使われ方から判断する
他の業務を担当する人が話す内容で曖昧なことやわからないこと、また外部に業務の一部を委託する上で不明点を明確にしたかったり、事前の確認をしたい時もあると思います。ではそのような時も含めて、会話をしている中で曖昧な所、わからない所があるかどうかを判断するにはどのようにしたらいいでしょうか。
これは筆者がよくやる方法なのですが、相手の言葉の中で形容詞や副詞を使って表現されている部分について、確認するようにしています。例えば「ちゃんとやります」と言われた場合、その「ちゃんと」というのはどういう状態のことを指すのかを確認します。「何がどの程度にどのような状態になっているのですか」とストレートに聞いてしまいます。
聞き方としてはちょっときついように聞こえてしまうかもしれません。ただここに至るまでには、その周辺の業務や作業の状況整理(仕様書や図面、作業手順書など帳票類の版管理の確認、整理や内容確認など)、残っている記録の確認などをし終わっていることがほとんどです。
その上でわからない部分をお聞きすることになるので、かなり細かいポイントにまで絞り込まれていることが多いです。そうであれば事細かに聞くような聞き方でも必ずしも相手はきつめには感じず、一緒に曖昧な点を明確にしようというという姿勢になって頂けることもしばしばです。
・「○○性」という言葉を疑う
「○○性」という接尾辞があります。「○○」という名詞に「性」という漢字一文字を付けることで「○○という性質を持つ」という意味になります。形容詞や副詞を書き換える時には「○○性」という言葉も一緒に書き換えます。
【例1:可能性】
例えばある装置の仕様書に「出力がXとなる可能性がある」という表現があるとします。「出力がXとなる可能性がある」ということは「出力がXとならない可能性もある」ということですよね。つまり出力がXとなる条件と出力がXとならない条件があると言っているわけです。ということは大きく以下の3パターンの条件と出力の組み合わせが存在します。
出力がXにならないといけないならば、1の条件以外を選択できないように動作制限を掛ける必要があります。XにならなくてもいいならX以外の出力値が得られる条件とその時の出力値を示します(もしかしたらこの時の条件と出力値の組み合わせはものすごく種類が多いかもしれません)。
仕様書の段階ではこのすべての条件か、出力値をXにするための動作制限が明示されている必要があります。動作制限が入るのであれば制限のトリガーになる条件も明示されていないといけないのですが…
【例2:耐熱性】
今度は性能の様に読み取れる「耐熱性」で考えてみます。
例えば容器として販売しようとしている製品の取扱説明書に耐熱性に関する記載をするとします。その時「この製品には耐熱性があります」と書くより、「この製品は150℃まで対応します」と書かれていれば通常生活で使用する上では沸騰させたお湯までは対応できるということが分かります。
さて、それだけで大丈夫でしょうか。150℃の温度に達する熱量が製品に均一にかかるなら大丈夫だけど、局所的な温度上昇がある場合は製品が破損するとしましょう。容器として販売する予定の製品ですので、以下の使われ方が想定できます。
1つ目と2つ目は製品に均一に熱がかかると思われるので、破損はしないでしょう。しかし3つ目に関しては局所的な加熱ですし、4つ目については耐熱温度を超えています。つまり後半2つは使用方法として不適切ということになります。
実際に容器として販売されている製品の記載を読むと「直火にかけないでください」などと書いてある場合があります。おそらくその製品の仕様書にはこの様な指摘があるのでしょう。
「曖昧なことをしない」ようにしようにも、何が曖昧かわからないと表現が変えられません。曖昧さは閲覧者の誤解や困惑につながります。
これは曖昧さを検出して排除するための一つの方法ですので、念頭において帳票類を眺めると、その帳票の閲覧者が困る箇所が検出しやすくなるかもしれません。
筆者は社会人になってから一度大学院に入学していまして、“Trust, but Verify […]
中堅社員向け 人材 企画者向け 品質保証 品質管理 外注先との連携 技術者向け 改善活動 新入社員向け 現場向け 生産プロセス 管理者向け 経営者向け筆者は社会人になってから一度大学院に入学していまして、“Trust, but Verify(信ぜよ、されど確認せよ)”はその講義の中で聞いた言葉です。それが何の講義だったかは記憶が定かではないのですが、経営者から従業員に対して仕事などの取り組みの中で使われると聞いた記憶があります。「あなたのことは信頼しているよ。でも、だからこそ確認はさせてもらうよ」という風に言うような事がある、との事でした。
私はこれを聞いた時に「あぁ、外注先の会社さんにお仕事をお願いする時や工程監査などに伺う時、自分もそんな気持ちだったなぁ」と思った記憶があり、それからずっと頭の中から離れない言葉です。
そのことを、サウスピークという英語学校のインタビューを受けた際に答えたことがあります。
–品質保証部の方から確認されるということは、責められているかのような感情を抱かれることはありませんか?
信ぜよ、されど確認せよ。品質保証の経験者に聞いた目的を実現するための仕事術 , サウスピーク(https://souspeak.com/ks/hinsho-shigoto/),引用日:2019/10/3
そのような感情をいだかれる方もいらっしゃいます。
ですので、こちら側が信頼していることを伝えることが大事だと思いました。海外では「Trust, But Verify」(信ぜよ、されど確認せよ)という言葉があると聞いたことがあります。相手に対して「あなたと一緒に仕事をしたい」「あなたには一定の技術力があることを評価している」と信頼を伝えること、その後に認識の齟齬を確認していく、という順序が必要です。
相手は、別の会社であれ、別部署であれ、自分たちの製品を作ることに協力してくれている仲間です。良い製品を作り、広くお客様へ届けて、使っていただくことで価値を社会に広めることが目的であることを忘れることはありません。
・もともとはロシアのことわざ
改めてこの言葉を簡単に検索してみたら、元はロシアのことわざだそうです。
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企業がいらっしゃったので、そのコラムから引用させて頂きました。
そもそも自分にできないことだからこそできる人にお願いする意味があるわけですから、この考え方は外注先と取引する時に絶対に必要な考え方です。
しかしここで相手先企業と積極的にコミュニケーションをとる人はどの程度いるでしょうか。加工屋さんに部品の加工を依頼した時、「頼んだ先に細かいことを聞くのは失礼じゃ…」とか「図面も出したし頼んだんだからいちいち細かいこと言わせないでちゃんとやって来てくれよ」とか思ったりしていませんか?
受託事業を営んでいる会社さんでは発注後何も聞いてこないし確認もしてこないで、品物を納めた時に文句を言われた経験のある方はいらっしゃいませんか?または明らかに知らなさそうなのに知ったように言ってくるなぁと感じたことや、コスト面で有利になりそうな施策が講じられていない図面などが顧客から送られてきたことなどはありませんか?
製造業などの受発注関係でも、コミュニケーション上の緊張感があるんですよね。
・曖昧な点は必ず聞いて確認する習慣をつける
もしわからないことや曖昧な点があるのであれば必ず聞いて確認する習慣をつけることをお勧めします。受注する側であればこの部品が搭載される予定の製品が要求している性能はどの程度で、要求仕様や図面に書かれている内容が製品として妥当なものであるのかを確認してしまってもいいでしょう。図面が受け取れるということは機密保持契約は済んでいると思いますので、逆に業務上聞いてはいけない内容ではないと思います。聞いてはいけない内容なら相手先から「そこについてはお話しできません」と言われるはずですし。
発注側であれば、「自分はできないから頼んでるんだ」とか「頼んでるんだからちゃんとやれよ」とかではなく、頼んだ内容が理解されているか、実現のための道筋が立てられているかを確認する責任があります。その確認をしないまま出来上がったものを見て指摘するのは筋が違いますし、確認を怠った結果そのまま製品が納入されてしまえば修正が必要な場合もあり得ます。
発注するということは自分側にできない理由があることになります。時間的に自社の工程が空かないとか、自社にその設備がない、技術がないというケースもあります。特に設備や技術がなく自社でできない仕事であればわからないことや知らないことがあるのが当然です。であれば、相手側に質問する大義名分ができるのです。その大義名分を活用して、相手側に教えて頂き、勉強させてもらいましょう。その勉強は、必ず次回の発注に役立つはずです。
あえて大雑把なくくり方で書きますが、「日本人」は「行間を読む」ことや「空気を読む」ことを要求しがちです。また空気を読んでしまって、不思議に思ってもその場をやり過ごしてしまうこともあるでしょう。
その行間を読むことは、お互いが協力関係にあり、何らかの目的のために前に進まなければいけない開発の現場であれば、むしろない方がいいものかもしれません。
これからの未来のために、自分の状況を表明しためらわずに声を上げましょう。
仕事に関連する中でもあまりお話しする機会のない話というのがいくらかあります。せっかくなので […]
マーケティング 中堅社員向け 人材 企画者向け 品質保証 外注先との連携 技術者向け 改善活動 新入社員向け 新製品を開発する 管理者向け 経営者向け 製品を販売する 開発プロセス仕事に関連する中でもあまりお話しする機会のない話というのがいくらかあります。せっかくなのでそんな話をこのサイトに書き残しておくようにしようかなと思います。
製造業の業務範囲というのはその企業それぞれで大きく変わります。完成品メーカであれば部材の調達もしくは生産、社内での仕上げ加工や組立て工程を持ち、エンドユーザが使用する上で品質上問題が起きないことを保証しながら販売しなければなりません。
部品加工を受託した会社は顧客の要望を満たしながら部品の出荷品質を安定させ、常に同じものを出荷しなければなりません。
その受託する会社も、機械加工品の様な社員数名~数十名で一社で一つの材料を加工し出荷している会社から、社内で複数工程を持ち、外注先と連携しながらいくつかの組立てを担当することもできる会社さんもあるでしょう。クライアント一社への依存率や業界への依存度も会社さんによってかなり異なるのが現状だと思います。
・大企業の発注をあてにできない
日本製品が必ずしも売れる時代じゃないのは今(2019年10月現在)これを読まれている皆さんもお分かりだと思います。また、今まで製品を出荷する形でビジネスを続けてきた会社が大規模なITサービス系企業と連携したり、場合によっては競合したりもしています。
トヨタ「ライバルはもうホンダではない」の真意 全ての企業の競争相手はGAFAである - PRESIDENT Online
製品販売以外の事業を展開したりして、相対的に製造業の部分のウェイトが下がっている企業もあります。日本だとソニーなどがいい例で、製品を作るだけでなく、音楽や映画、金融に手を広げ、売上高や営業利益などを見ると、そちらの方が製造業が関連する事業よりも額としては大きいものも見受けられます。
ソニー 2018年度決算説明資料 2019年4月26日
製造業の海外流出というような、生産現場が海外に移転したり、人件費の安い海外の会社に発注されてしまうという状況ではなくなり、そもそも日本国内での製造業の仕事が減っているのが現状です。その中でもなんとかまだ世界レベルで製品を売って歩ける会社があるのでいいのですが、でもそのような企業が危機感を抱いており、そのために作戦を考えて行動したことにより徐々に結果を出しているのが2019年の今と言えます。
・自分のやっていることを伝える
日本の中小の製造業の方(他の業種の方もそうかもしれませんが)、大きな企業から仕事を受けている会社が多いと思います。もちろんそれが悪いことなのではありませんが、その流れてきている仕事がなくなる、細くなるのが現在ということになりますし、その風を一身に受けている会社が非常に多いはずで、危機感を募らせてらっしゃると思います。そのために自社の技術を活用して製品を作ろうと思う会社さんが多いのも存じ上げております。
しかし、本当に数名で受託事業を行っている会社さんはこれをやる事すら厳しい状況にいらっしゃると思います。そのような会社さんが取り組めること、それが実は社内に品質保証体制を構築することだったりします。
なぜなら、品質保証体制というのは技術的な対応と開発管理、生産管理、それらを通じた品質管理の意味と内容を整理して、作り始めから販売までを網羅することだからです。つまり元手が0円で済みます。
それらの取り組みを自社のパンフレットでもポスターでもいいです、TwitterなどのSNSやもしお持ちであれば自社のwebサイトでもいいです。それらを公開しましょう。公開することで、「弊社は、ものづくりをこのように捉えて取り組んでいる会社です。」という説明ができます。
それができると自社で製品を作りたいと思った時にもいいことがあります。それは自社の製品がどの程度の生産数量でどの程度の納期なら対応可能なのか整理ができるからです。
実はQA+で今までの記事の内容の様な事を延々と書いているのは、その品質保証体制を構築する上での参考情報にして頂きたいからです。
「うちはISO9001取ってるよ」とか「○○という大企業の要求にずっと応え続けてきたから技術力はあるよ」とか説明できる会社さんはたくさんあると思います。ただそれらのもったいないところは、それだけでは皆さんがどのようなお仕事をしているか、どのように案件に取り組まれているかは説明しきれていない点です。これらの説明ができると、外部からの理解はものすごく高まります。
QA+を運営している株式会社コルプの目的は、ご自身の会社と事業がどのようなことができるのか、改めて見つめ直して頂くための機会のご提供なのです。
なぜなぜ分析は何らかの事象に対して真因を探る際に用いる手法としてよく聞くと思います。そして […]
中堅社員向け 品質保証 品質管理 外注先との連携 技術者向け 改善活動 新入社員向け 現場向け 生産プロセス 管理者向け 開発プロセスなぜなぜ分析は何らかの事象に対して真因を探る際に用いる手法としてよく聞くと思います。そしてインターネットで検索するとなぜなぜ分析に関する情報ややり方の説明、その歴史などはたくさん出てくるので、読んだことがある方もたくさんいらっしゃると思います。
では、みなさんは実際にお仕事の中でなぜなぜ分析を使ったことはありますか?またはどのようにやるかと言われたらご自身は普段自分でやっているやり方を説明できますか?もしくはなぜなぜ分析を受けた時というのはどういう時でしょうか。
・仕事で「なぜ?」と聞かれると答えづらい
「なぜ?」と聞く時は基本的に原因や理由を知りたい時です。「なぜそれをしたの?」とか「なんでそこへ行ったの?」とかですね。
筆者自身、かつても今も、いろんな方とお仕事をご一緒させて頂く際によく「なぜ?」「どうして?」と質問することはよくあります。またされることもよくあります。
でもですね、普通に考えて仕事中に「なんでこんなことやってるの?」「どうしてこんなことになったの?」と聞かれて気分がいい人はいないと思うんです。仕事でわざわざ質問されるときというのは何か問題が起こった時です。しかもそれが実際にお仕事を頂いている顧客から「なんで?」「どうして?」と聞かれて怖くないわけがないですよね(笑)。
ただ業務上「なぜ?」と問われて答えづらいときにはただ嫌な気分だからとは言い切れない部分もあります。なぜなら、相手が抱えている案件は自社が発注したものだけではないからです。発注側と受注側で機密保持契約と取引基本契約書を取り交わしているとしたら、受注側は他社とも同じ関係を結んでいます。
しかし使う設備や場所は同じ場所だったりするわけです。もしかしたら「どうしてこんなことになったんですか?」と問い質されている仕事の前には別の顧客の案件の対応をしていたのかもしれません。そうであればそこに関連する話題の一部は言えないものかもしれません。
筆者の場合、もし自分が質問する側で、回答する側が答えに詰まるようなケースが起こったとしましょう。そういった場合には「なぜ?」と聞くのを一回止めます。その代わりに「もしかしてこういうことですか?」という一言を挟むのです。
・「もし」が意味するもの
なぜなぜ分析を実施する上でのポイントとして、「質問の回答が得られたらその前段階の疑問が解消すること」というのがあります。
この時、「もしかしてこういうことですか?」とか「もしかしたらこうじゃないんですか?」とか聞くというのは「質問する側としては回答の方向性をこういう風に予測しているよ」という表明になります。そうすると回答者はそれに対して同意する場合は「そうですね」と言いながら実際の状況の様子を教えてくれたりします。違う場合には「いえ、そうじゃないんです」と言いながらやっぱり実際の状況を教えてくれます。つまり「もしかして」という一言は回答を誘発(誘導じゃないんです)するための切り札になります。
この時の「もしかして」というときの注意点としては、自分からあまり話し過ぎないことです。例えば「もしかしてこういうことですか?そうじゃなければこんなことになるなんてありえないですよね?」などと言ってしまった日には「はい、その通りです。申し訳ありません。」で話が終わってしまいます。
たまにここで話過ぎてしまう人がいます。そうするとそれに対して Yes か No の答えしかなくなってしまって、回答者が実際とは違う答えをすることも可能になってしまうので、話過ぎは禁物です。あくまで目的は相手が置かれてる状況を理解し、事象の原因・真因が何なのかをつきとめることです。
・本当に求めるべきもの
なぜなぜ分析の目的として冒頭でも書いたように「事象の真因を求めること」と言われます。まず最初に起こった事象の真因という意味で何が起こったのかを知りたいのはそうだと思います。しかしそれは本当に求めるべきことでしょうか。また実際にその事象を起こした組織が求めたいのはそれでしょうか。
本当に求めたいのは開発する際に、または生産する工程を設計する際に同じようなミスを再発しないことではないのでしょうか?製品の不具合の再発は一回事故を起こせば修正を入れることは可能ですが、そこを次回以降の製品開発時も活用可能な情報にできたらその方が理想的です。
そのためにはその製品もしくはその工程を作っている際に何を考えてそうしたのか、その時に何が漏れていたのかを明らかにしておく必要があります。顧客に対する回答としてはその製品に関する原因究明でも十分かも知れませんが、実は組織内では次回以降の製品開発の効率が上がっていくことが理想ですから、製品開発の活動全体に対する改善活動になる場合が理想です。
すなわちなぜなぜ分析を通じて、実際に業務にあたる際に想定された判断ポイントの条件分岐を想像することが求められます。そのためにはなぜなぜ分析に入る前にすることがありますので、それについては別の記事でご説明します。
過去3回にわたって「品質とは」という記事を書き続けました。 品質とは定義されるべきもの品質 […]
中堅社員向け 企画者向け 品質保証 品質管理 技術者向け 新入社員向け 新製品を開発する 生産プロセス 管理者向け 経営者向け 開発プロセス過去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つのこと
ここまでのことを反対から捉えれば、ハードウェアの作りを十分に理解しないままソフトウェアを作る事は非常に困難なことばかりか、ハードウェアを破損する、最悪の場合にはその破損によりユーザの身体の安全を脅かす事故を起こす可能性があります。
同じ製品に搭載されユーザに価値を提供する以上、ソフトウェアとハードウェアの相互理解と技術的特性を生かした役割分担は必ず有効に働くはずです。またその技術的特性の違いがあっても、その技術的アプローチには学ぶところが多いと思います。
自分の担当する技術分野以外の情報を集める意味でも、その特性を理解することは意味があると思います。