意味もない打ち合わせがダラダラと長く続き、しかもそれが何回もある。仕事してて最もイヤなことの１つですね。激しく共感できます。
というわけで「技術職だとどうなのか？」について色々書いてみる記事。
長さの件だけでとりあえず結論を言うと、別に長い会議はいくらでもあります。
会議の質は人に依存するので、どんな業種のどんな会社だろうが内容は千差万別でしょう。ここをひとまとめにすることは何の意味も持ちません。
ちなみになんで「会社に打ち合わせがあるか」という哲学に近い命題に対する僕の意見はこうです。
「なぜアホみたいな打ち合わせがなくならないのか」という永遠の命題に対する僕の最新の見解は「やつらはとりあえず集まることによって互いに仕事しているアピールをするための場を互いに作り上げようとしているのでは」なんですけどいかがでしょうか
— みるみ - みるめも (@milmemo_net) October 13, 2020
どう思います？笑
しかし開かれている会議の種類が違うなら傾向は変わります。
技術的な専門職としての特徴ですが、「レビュー」という概念があります。ものづくりだと特に「DR」といいますね。
それら含む打ち合わせなどについてまとめてみます。
レビュー、デザインレビュー(DR)とは？
「レビュー」という言葉は日本では「クチコミ」みたいなニュアンスで使われがちですが、もともとの意味は「再調査、再検討、再考察」みたいな感じです。つまりもう一度確認する作業ですね。
何を確認するかというと、「誰かが設計した技術要素」。
技術職の現場では誰かが常日頃何かしらの設計を行っています。このときの「設計」という言葉は技術的スキルを使って何かすること全般みたいな意味合いを持ちますね。
これらそれぞれの設計結果、検討結果をチームみんなで再確認するのがレビューです。
言葉の説明としては、
- レビュー：ソフトウェア領域（プログラミング、ITエンジニア）で使われることが多い
- デザインレビュー(DR)：ものづくりの現場で使われることが多い
という違いはたしかにあります。モノが関わるかどうかで区切られていると理解するといいですね！
ちなみにDRはそのまま「ディーアール」と呼んでますよ！
で、レビューで何をやるかというと、実はあまり具体的なやり方は決まっていません。
- 設計/検討担当者がその結果の概要説明を行う
- 各メンバーが気付いた点を指摘していく
- 改善すべき点があれば整理して持ち帰り、また次回へ
という感じ。結局は普通のプレゼンみたいなものとあんまり変わりませんね。
ただし細かい注意点やコツ的なものはあります。発表者だけではなくチーム全体で結果を出すべきアウトプットなので、指摘の方法や全体の雰囲気への影響などまで考えるべきでしょう。
やっぱり空気読めないおじさんとかはいて、若手のDRを根拠なくめった切りにする人もいるんですわ…。僕はそんなこと言われたら徹底的に（言葉で）ぶちのめすけど
僕が思う「発表者側で大切なこと」は２つあります。
- その日のゴール地点、議題の大枠の内容を明確にしておく
- なぜそのような設計にしたのか根拠を語れること
１つめ、会議ならなんでもそうですが、その打ち合わせで期待される結果をあらかじめ決めておくのはとても大切なことです。「こうなったら今日はクリア！」ってやつですね。
これをレビュー・DRにあてはめると、例えば
- 「今日の段階では◯◯が不安だからそこについて自分の改善点を明確化したい」
- 「もう全然どうしていいか分からない、ボコボコにして」
- 「今日は一区切り付けたいことが目的なので、サクッと同意を得られればOKです」
みたいな感じ。これが打ち合わせを短く終わらす一番の効率的な方法だとも思います。
もちろん進行役としてのファシリテートスキル、意味分からんヤツに長く喋らせない（←これ超重要!!）、など根本的なものも必要な要素としてあるんですけど。
２つめ、「なんでそういう設計にしたの？」をちゃんと説明できるようにしておくこと。
これはエンジニアをやるならぜひとも心得ておきたい部分。
- 「なんとなく調べたら出てきた解法だから」
- 「前任者がやっていたことだから」
など、自分が理屈を知らないままレビュー・DRに望むのは地獄への道です。まず間違いなくベテランに見透かされめった打ちにされます。笑
何より、担当者が理解していない設計結果を世に出すおつもりですか？ということには本当に気をつけておきたい（自戒）
それに「根拠を語れる」ことは理解を深めますから、自分のスキルアップにも欠かせない要素ですよね！
理屈で語るべきエンジニアがフィーリングでやってはダメということですな。
その他の技術職ならではの会議、設計確認会など
技術的な要素が求められる会議というのはレビュー/DRが代表的ですが、その他にもたくさんあります。
ここではそれらのうち数個をざっくりと紹介してみます。
DRBFM
Design Review Based Failure Modeの略。DRの進化系みたいなもんです（雑）
「設計の変化点に着目する」という考え方で、「それまで問題がなかった設計なら、新たに変わったところだけDRすればいいだろう」という手法ですね。モデルチェンジ、設変などの際に行われるわけです。
もとはトヨタが始めたものですが、今では業界を問わず使われる言葉・手法になりました。ものづくりに携わる人なら誰でも一度は聞いたことがあるはず。
これはがっつりルールが決まっていて、DRBFMを始める前に用意しておく資料、参加者が確認しておくべき資料、実際の進め方（ワークシート）などがかなりちゃんと定義されています。
体系化されたルールに沿うことでヒューマンエラーを確実に防止できる効果があるということですね！
ま、DRBFMをやろうが設計ミスなんかなくならないんだけど。
FTA・FMEA
これは
- FTA(Fault Tree Analysis)
- FMEA(Failure Mode and Effects Analysis)
という２つの手法を同時に紹介しちゃいます。本来一緒にするのは間違っているというか全然真逆のもの同士なんですが、感覚的には分かりやすいので同じ説明を用います。
これらはなぜなぜ分析です。
故障モードという、システムが正常に動作しなくなってしまう状態からスタートして
- なんでその状態になっちゃうの？→Aだからです
- なんでAになっちゃうの？→Bだからです
- なんでBになっちゃうの？ ……
という風にやっていくもの。
これを
- FTAはトップダウンで
- FMEAはボトムアップで
やっていくのが決定的な両者の違いです。
出典：イプロス
これを繰り返していくことで製品やシステムの不具合となる条件を全て洗い出すことができ、「それを解決できれば故障は起きないよね！」と言えるようにするためのものです。例によってこれを満たしてもなぜか故障は止まらないのだけど。
ここまでの説明だけだと単なるクソみたいな打ち合わせに思えますが、実際には
- 故障モードという概念（故障率(MTBF)など種々の要素への理解が必要）
- トップダウンで下がっていくとき、それぞれの事象へ繋がる可能性があるかをANDゲートやORゲートを使って表記していく
- それぞれの「なぜ」に対する技術的見地からの考察
など、エンジニアが行うものとして十分に意義のある活動です。
なおこれらの打ち合わせがそれなりの頻度で開かれるような状況なら、だいたい既にプロジェクトは暗黒化しているので「打ち合わせが短くなるように」とか祈っている場合ではないことがほとんどです。あしからず。
APQP
Advanced Product Quality Planning、「先行製品品質計画」の略。
技術（開発系）の人だけではなく生産技術、品質管理、品質保証、調達など各部門の偉い人たちが一斉に集まって色々話し合うもの、みたいなイメージです。なんで説明が雑かというと僕自身は参加したことがないからですｗ
出典：日本科学技研
今調べてみて初めて知りましたが、自動車メーカーが言い出したものみたいですね。たしかにうちも自動車部品に関わってはいるけど、全然関係ない製品でもAPQPをやっているのを見たことがあるぞ…。よく分からない。
ちなみに上の図はTDKが出していたものなので、自動車部品に関係なくても実施しているメーカーはやはりあるみたい。
全体の品質を確実に担保するために、設計や開発チームだけではなく関わる人みんなで、それぞれの視点でチェックしていきましょうね、というものだと思っています。
プロジェクト発足時はもちろん、定期的に多くの視点からチェックが入るのはとても良いことでしょう。特に品管・品証の人たちの言及はあとで重くのしかかってきますから、早いうちに「問題ないよ」と伝えておくことは良いことです。
メーカーには技術職としてどんな部署があるか、それぞれが何をしているかは下記の記事で詳しく解説しています。一緒に読むと理解が深まるはず。
部品という「100%」がない世界が絡む以上、ある程度の品質を担保し続けていくのはものづくり業界で永遠に切ることのできない課題です。
ここを以下になくすか、今日本の製造業界にも問われているところでしょう。
おわりに
技術的な側面を持つ打ち合わせ、会議やその手法についてまとめました。
この他にも細かいテクニックというか技法のようなものはたくさんありますが、紹介しやすいのはこんなところだと思います。内容によって随分性質が違うのでまとめて説明するのはちょっと難しかったですね。
技術職というと日々パソコンや数字とにらめっこしているイメージが強いかもしれませんが、人と仕事するのは同じなので当然話し合い・打ち合わせはあります。
最初にも言った通り参加している人がアレなら打ち合わせは長くなるし、運が悪けりゃ変なヤツに捕まることもしょっちゅうです。なのでここは技術職だからといって何かメリットがある点とは全く言えないですね。
ただ、僕はチームメンバーと技術的な話題で討論をする時間はすごく好きです。
それぞれのスキルや知識を使って「ああでもないこうでもない」とやるのはやっぱりエンジニアにとっては楽しい時間でしょう。こういう有意義な時間にしてもらいたいもんですね！！！！（怒）
では今回はこんなところで。
技術職とは関係ない記事ですが、物事を考える手法についてまとめた記事もありますのでこちらもおすすめです。
ありがとうございました～
