日科技連SQiP研究会特別講義(10/14)のチャット質問への解答

この投稿は10/14の日科技連SQiP研究会特別講義のチャットで頂いた質問への回答です。

質問・回答一覧

「しくみを想像できないのはなぜか？」 「FMEAモデルとの関係は？」

FMEAは私も参考にしました。そのうえで、ハードウェア開発に限らず応用できるもっと簡易な方法として「しくみ・事象・対処」を使っています。→続き

三位一体型を「1つも欠かすことができない」ことを強調するために使えるか？

情報に変化があったときのメンテナンスに手間がかかるので推奨できません。→続き

プロジェクト管理のQ・C・Dを三位一体型で表現するのは適切か？

悪くありませんが「スコープ」を加えて立方体にすることをお勧めします。→続き

「しくみ」という言葉の意味が人によって異なってしまいそうです

『しくみ』の意味を形式知として定義するのは難しい（できない）です。→続き

三位一体型は「三要素である」ことをとりあえず覚えるのには向いている？

とりあえず覚えるのには向いていますがそれ以上のメリットがないため、真面目に勉強したい人のための教科書には向いていません。→続き

インストラクションとガイドラインだけで仕事をするのは運用エンジニア？

運用エンジニアは通常の職務ではガイドラインとインストラクションだけで間に合うためそれしか教えられていない傾向があります。→続き

カテゴリー、サマリーは主語、述語のこと？

「主語／述語」は一つの文の中で完結する概念ですが、「カテゴリー／サマリー」は複数の文を横断的にとらえて集約・抽象化を経て導出するので、意識する単位が違います。→続き

サマリーとは要約のことではないのでしょうか？

一般用語としてはサマリー＝要約ですが、情報整理術/ロジック図解では少し違う意味で使っています。→続き

Amazonでパワーポイントを禁止している件についてどう思われますか？

やっていることは本質的にはロジック図解と同じです。会議参加者の理解促進・能力向上に大きな効果があると考えられますがそれが成り立つハードルは高いでしょう。→続き

製造業だと特性要因図やなぜなぜ分析をよくやることがあるのですが、仕組みを考えるという根本は同じだなと思いました

そうですね、その根本は同じです。

「しくみ・事象・対処チャート」を描けない上司のもとでは、絶望的？

「上司」　がその組織の中でどんな役割を果たしているかによると思います。　「しくみ」　をきちんとわかって説明してくれる人がどこかにいて、その知見が組織の中で評価され生かされるような組織であればよいので、それが必ずしも「上司」である必要はないですから。

世の中に溢れているコロナ対応もガイドラインとインストラクションばかりな気がしますね。。

メカニズムを説明するとどうしても長くなります。ガイドラインやインストラクションの何倍、何十倍の文字数を要することが珍しくないので、そこはやむを得ないだろうなと思います。　もちろんそれしかないのでは困りますが……

教訓フレーズをまとめた書籍があればご紹介ください

教訓フレーズは最近使うようになったもので、残念ながら書籍はいずれもかなり前に出したものなので載っていません。
現在、新しい本（来年前半刊行予定）を執筆中ですのでそちらには載せます。　また、Webサイトには順次載せていく予定です。

ITシステムだけでなく、「働くとは何か」に類するような「（社会構造的な）しくみ」に対しての対処法も、「しくみ・事象・対処チャート」に描けるでしょうか？

それはやってみないとわからないので、やってみてください。　おそらくできます。　（個人的にはそれに近いことはやってきましたので）

余計な修飾とは？

色がないと寂しいからカラフルにしよう、真っ直ぐ線を引くと退屈だからひねってみよう、などの、ロジック上の必要性がまったくない理由でつける装飾のことです。　かえってわかりにくくしてしまう場合が多いので、　「論理的必要性のない装飾は全部取る」　ことを基本にします。