CdCale(O.K.) Advent Calendar 2022

「会議は15分未満」に。小耳にはさんだ話。品質(25)

Last updated at 2024-10-20Posted at 2022-11-30

「会議は30分未満」から15分に。小耳にはさんだ話。
https://qiita.com/kaizen_nagoya/items/55ab43e7f50434156ff4

を書いてから、なるべく会議は15分未満にするようにしてきた。

臨機応変

名古屋の企業、主に製造業で、５年ほど前から「会議時間は30分未満」という張り紙をよく見かけた。

いくつかの組織で打ち合わせをさせていただくことがあった。
それらの組織で、実際に会議の設定は30分で、終わるのは30分未満である。

終わった時に、秘訣をお聞きした。

うまく行っているところの抽象的な印象は、臨機応変。原則に縛られるのではなく、今解決しなくてはいけない問題に焦点を絞っていることかなって感じた。

いくつかの会議は、具体的な内容は違う。
並列で記載するか、範囲を記載するかもしれない。
自分にとって、大事そうな順番に並べなおしてみようと思う。

chat

ソフトウェア開発では４０年くらい前からchatというオンラインの文字だけで打ち合わせをすることがしばしばあった。最近ではSlackというソフトウェア上で行うのが流行りだ。

オンラインのchatでは、ソースコードを書きながら、コンパイルしながら事実上の会合ができる。議事録は終わった時点でできあがっている。議事録を作るという無駄がない。

読み手の状況がわかっていない。どういう誤解がありうるかは想定して書いていない。

この５年くらい、自分が参加している会議がほとんど30分未満で終わっているから書いている。会議時間は30分未満で終わっていない会議があるから書いている訳ではない。
ごめんなさい。

実際に、半分以上の会議は15分で終わっている。　

それまで30分かかっていた会議は２つに分け、　
全員参加の15分と関係者だけの15分にわけることにした。

先に全員参加が来る場合と、あとが全員参加の場合がある。

<この項は書き書けです。順次追記します。>

臨機応変
目次
原則１事前に優先順位をつける
原則２判断できる能力または責任のある人に参加してもらう。
原則３　決定が必要か、様子見だけでもよいか。目的、目標を明確にしている。
原則４　事前に済ませること、事後に済ませること。臨機応変に。
原則５　事前配布した資料の誤字などの指摘は事前に電子的に済ませる。事後でもよい。
原則６　一人の発言は１回１分以内を原則とする。
原則７　意見は具体的に。前の方と同じという発言はしない。理由は具体的に。時間がないという理由は言わない
原則8 大事な打ち合わせの半分以上は事前、事後にオンラインで文字などで行う。
原則9　４人以上の議論は行わない。
原則10　原則はあくまで原則。例外の条件はできるだけ最初に確認する。
質疑
　１。時間無制限
　２。製造業
参考資料
短歌
文書履歴

原則１事前に優先順位をつける

議事内容は事前に優先順位をつける

少なくとも、時間の半分は、主催者の優先順位の高い事項を済ませる。
半分時間が過ぎたところで、残りの事項よりも優先順位の高いことがあるか参加者に聞く。

主催者がやりたいことよりも、参加者がやりたいことを先にするのは、参加者がお客様の場合に限る。後工程はお客様とする。上司、経営者の方が責任をもってお客様、後工程の代弁をしていただける場合はお客様扱いする。

@e99h2121 育児していたからこそエンジニアのお仕事に役立ったこと10選

時間の使い方に妥協をしなくなる

原則２判断できる能力または責任のある人に参加してもらう。

判断できる能力の人に認めてもらうか、
責任を取るつもりのある人に理解してもらうことが大事。

両方いればいいのだろうが、場合によってはどちらかでもいいかもしれない。

製造業だと、誰がどういう能力があるかを体系的に整理されていてい、どういう能力のある人が参加していないと駄目という運用をされている。製造業のソフトウェア部門では、それを援用して、アーキテクチャを書いたことがある人が、設計審査(design review)に参加していて、なんちゃってレビューをしていないことを目撃したことがある。

算譜(program)の見直し(review)に必要な志向・技能・技法・手順、上位７。仮説（188）

原則３　決定が必要か、様子見だけでもよいか。目的、目標を明確にしている。

決定が必要な事項は時間の半分より前に実施する。
様子見だけでよい事項は、時間の半分より後でもよいかもしれない。

決定するかどうかを様子見する必要がある相手もあるかもしれない。
事前の根回しをした方がいいかもしれない。

事前の根回しを習慣づけると、根回しの時間が無駄になるかもしれない。
無駄時間をどうしたら減らせるかは難しい。

目的、目標がはっきりしないと、誰が参加するとよいかがいいかげんになるかも。

原則４　事前に済ませること、事後に済ませること。臨機応変に。

資料の事前配布または、資料の事後配布。

事前に配布できるものは事前に配布する。事後でもいいものは、無理にその場では配布しない。

わざわざ印刷したりして配布すると、どうしても説明したくなるらしい。

事前配布する場合と、事後配布する場合の仕分けに暗黙の了解があればよい。
なんでも文書化するのは、無駄になることがある。

組織の規模と、意思決定の行き違いの頻度などに応じて、何を文書化するかを決めるとよい。

事前に済ませることを規則にしない。規則にする場合は例外規定を記述する。

また、質問事項の大まかな事項は事前に、細かな事項は事後に。

延々と質問し続けるのは、時間の無駄の場合がある。

ある一人が理解していないだけで、参加者の時間がどんどん減っていく。

会議の最中にコンパイルしていたりすれば、その時間は無駄ではないかもしれない。

原則５　事前配布した資料の誤字などの指摘は事前に電子的に済ませる。事後でもよい。

誤字ではない場合もあるかもしれない。
誤字の指摘の時間が無駄だし、誤字だと思って指摘して誤字じゃない時の無駄もいやかも。

重要そうでない場合には、事後に誤字の指摘を済ませてもよい。
事前じゃなきゃいけないって決めなくてもいいかも。
時間内にしなきゃいい。

原則６　一人の発言は1回1分以内を原則とする。

2分でもいい場合、3分がいい場合もあるかもしれない。

デブサミ2022 で、15 秒でというのがあった。
すこし練習してみて、15秒がいいかも。

今日デブサミ2022懇親会に出て決めたこと

原則７　意見は具体的に。前の方と同じという発言はしない。理由は具体的に。時間がないという理由は言わない

意見は具体的に。前の方と同じという発言はしない。
前の人と同じ意見を持っていたとしても、その次に優先順位の高い意見をすぐに言う習慣をみにつける。

「前の方と同じ」という発言をしたら、前の人に1000円払うというような仕組みが導入できる雇用形態は未確認。

理由は具体的に。時間がないという理由は言わない
時間がないのではなく、優先順位の低いものを先にやったのかもしれない。

優先順位が高いものからやっていれば、優先順位の低いものはやらなくてもよいかもしれない。

時間がないという発言をしてしまった場合は、相手の仕事が優先順位が低いものだと言っているか、自分が優先順位をつけまちがえたと言っているかどうちらだかを表明してもらうとよいかも。

時間がないという理由は言わないと、会議で優先順位の低そうなことを最初に話題にすることはないらしい。

原則8　大事な打ち合わせの半分以上は事前、事後にオンラインで文字などで行う。

チャット、slack, GitHub/Gitlab/Bitbucket 上で、文字などで半分以上の打ち合わせは済ませる。事前に終わっていない事項は、事後にまわしてもよければ事後に調整する。

会議中に、みんなでキーボードを叩いて分担することがあってもいいじゃないか。
遊んでいる人がいないのであれば。

遠隔の映像で会合していても、昔ながらのChatを併用していれば、会議が終わった時点でChatを保存すれば議事録は完了している。chat に議事録に必要なことを書く習慣がみについていればよい。４０年近く続けてているとbuild in 機能があるかも。GAFAもその延長線上にあるだけってわかるかも。

VZエディタ移植に当たって実施したことと成果。仮説(115)

原則9　　四人以上の議論は行わない。

議論する必要があれば、３人ごとに分けて議論する。
４人の場合は２人づつに分ける。
４人以上の議論と言わないのは、場合による境界はあいまいにした方がいいことがあるからかも。

原則10　　原則はあくまで原則。例外の条件はできるだけ最初に確認する。

原則は、あくまで原則で、例外の条件は、管理者はそれなりに把握している。

命に関わることであれば、全員の確認を取る必要がある。

例外の条件はできるだけ最初に確認するのがよい。

会議の途中で、重大事項が発覚して時間を超過した方がいいか、
参加者を限定して継続するかを決める必要がある局面に出くわすかもしれない。

人数を限定する場合には、誰が参加必須かを想定しているとよい。

参加人数から最初から時間に終わらない場合もある。
何人かの班に分けて、それぞれの班からの報告を短時間でしてもらう方法などもある。

プログラマの会議方法が昔に戻って短くなった件

質疑

Q1. 時間無制限

時間無制限で徹底的に議論する会議が有っても良いと思います。

プログラマでは、合宿形式で議論するだけでなく、その場で全員が手を動かして合同で設計しちゃうこともあります。

プログラマのためのキャンプ特集（準備中）

Q2. 製造業

製造業では物理的な実験が必要だからソフトウェアみたいなことは無理ではないでしょうか。

製造業でもソフトウェア技術者がしてきたように無駄な会議をせずに設計できることに気がついてもらえてきました。

物理的な実験が必要な業務でも、複数のカメラを使った画像で、シミュレーションの時との差を表示するようにして、遠隔会議もできるようにされている組織もあるかもしれません。

小松製作所さんが、遠隔情報収拾で成功されたとお聞きしています。
情報収拾が遠隔であれば、会議も遠隔で可能。製造業とIT企業との連携をうまく組織化するのをIT企業主導でまかせてみませんか。

製造業における機械学習

トヨタ自動車、アイシン精機は、IT系子会社を、親会社に吸収されているとお聞きしています。

トヨタの会議は30分～GAFAMやBATHにも負けない最速・骨太のビジネスコミュニケーション術～ Kindle Edition

トヨタの会議が｢30分で終わる｣超合理的な理由。少しの差を積み上げ最終的に大きな時間を作る

テレビ会議で何か変わりましたか？

まだ、うまくテレビ会議システムを操れていません。ごめんなさい。
特定のシステムだけに限れば、時間を短くしたり、記録はチャットを利用するなど、
効率はあがっています。

ローム　動画アーカイブ
https://techweb.rohm.co.jp/movie/

動画の再放送の時に、チャットで質問を受け付けていて、セミナ時間中に質問への回答を講師が返すというのがすごいなと思いました。再生中は講師は時間があるので、チャットの回答を作成できる。しゃべっているのは自分だけど、今じゃないので。ああ、常時流すのではなく、時間をきめえ、あつめて返事するというのもありだなと思った。

多種類のテレビ会議システムの操作に馴染めなくて

チャットだけでやりとりしていた習慣がすこしづつもどりつつるような気がします。

プログラマの会議方法が昔に戻って短くなった件

参考資料

@e99h2121「女性こそエンジニアになるべきだ？」デブサミウーマン登壇記録

@ohakutsu 新卒2年目から見た達人プログラマーの振る舞い

@torifukukaiou 私のAdvent Calendar 2022 ーーはじめたきっかけ、1月のふりかえり、今後の展望

@kazuo_reve 新人の方によく展開している有益な情報

@kazuo_reve ワークショップ「ソフトウェア開発におけるHAZOP入門」の結果

@kazuo_reve 私が効果を確認した「小川メソッド」

自己参照

「５さいじがわかるcyber security（サイバセキュリティ）」

「５さいじがわかるcyber security（サイバセキュリティ）」のかんがえかた

自分の頭で考えるようになるには

「自分の頭で考える」ということ。

「@ohakutsu 新卒2年目から見た達人プログラマーの振る舞い」から学ぶこと

新人(学生)を指導するよりも新人(学生)に指導してもらった方が効率的

安全分析（HAZOP）の際の声かけ。安全（２０）

「@kazuo_reve ワークショップ「ソフトウェア開発におけるHAZOP入門」の結果」の分類

「@kazuo_reve 新人の方によく展開している有益な情報」はじめ記事を参照して頂いた時にしていること。

凡人は天才、秀才と違うことをして生きていく

人間が計算機に勝てる３つのこと。忘れる、あきらめる、やめる

「知っている」ことと「実現する」こと

プログラマの「日報、週報、月報、年報」考。仮説(73)

プログラマにも読んでほしい「QC検定にも役立つ！QCべからず集」

権利と義務の前に。仮説（147）

国際規格のNormative Reference

凡人網(ordinary person network: Bonjin mou)をつくる

データサイエンティストの気づき『勉強だけして仕事に役立てない人。大嫌い』それ自分かもってなった。

短歌

４日間１万viewsを超えました。閲覧、いいね、意見ありがと。

9977viewsで作りました。嘘つきです。

「会議時間は30分未満」。小耳にはさんだ話。臨機応変。 https://t.co/J9GyQ6oJV5 #Qiita @kaizen_nagoya
４日間１万viewsを超えました。閲覧、いいね、意見ありがと。#短歌 ver. 0.06 短歌追加 20200221 夜
— naokiakutagawa (@naokiakutagawa) February 21, 2022

最大の会議３０分未満から１５分に切り替えましょう

最大の会議３０分未満から１５分に切り替えましょう #短歌
— wocs2017 (@wocs2017) November 5, 2022

個人的には、プログラミングの打ち合わせはうん十年chat だけでしてきた。
chatって、コンパイル時間の暇つぶしにするものか、コンパイル時間の間に次の仕様を取り入れる打ち合わせにするものかどちらかだと思ってた。
プログラム組むだけなら、会合そのものは、あまり必要としない。会議の専用時間は0 分でいいかも。

個人的には会合は原則不要かもと思うことがある。

つまんないことばかり言う人がいると、うんざりする。
つまんないことを言っていることを仕事だと思っている人がいる会社とは原則仕事したくない。