自分発信のミーティングがノープランすぎて失敗しかけた話

# はじめに

HRBrainでインターンをしています24卒のなかじです！

この記事は、若手あるあるの失敗のお話です！😇

皆さんは、自分発信のミーティングで時間がだけが過ぎ、結論がなかなか出ない経験はありませんか？

そもそも自分の提案内容を言語化できておらず、他人任せにした経験はありますか？

私は、インターンの業務で、自分発信でチームメンバーをミーティングに集めたのは良いものの、準備なしのミーティングを開いてしまい、そもそも何を決めるんだっけ？、進め方は？など、準備不足で集まっていただいたメンバー時間を無駄にしかけた経験があります。

そこで、振り返りをし、自分発信のミーティングについて振り返りをしたので、記事にしようと思いました〜🙆


## 対象読者

- 若手エンジニア

# 😭 まずは自分の体験から

とある開発、登場人物（私、チームメンバー複数、上司）

### **〜ミーティングのマエ〜**

**コーディングルールがバラバラで、統一したい箇所があります、ルールを決めたいです！**

**私**「ここの書き方のルールを決めたいたいです！後ほど、お時間いただきたいです。カレンダーこの時間に設定しました〜」💪
**チームメンバー**「承知しました！」🙆

### **〜ミーティングのナカ〜**

**私**「お忙しい中、お時間いただき、ありがとうございます！」
**チームメンバー**「はい！どう進めますか？」
**私**「とりあえず集まれば決まると思いノープランで集めました。」
**全員**「、、、。。。（沈黙）」
**私**「ここのコーディングのルールを決めたいのですが、どう思いますか？」
**全員**「、、、。。。（沈黙）」
**上司**「この書き方がいいと思いますね、、、」
**私**「ありがとうございます！」😭😭😭
**チームメンバー**「この書き方もあります！」
**私**「ありがとうございます！」😭😭😭
**私**「（自分の意見）」

### **〜ミーティングのアト〜**

**ミーティングの動きについて**

**上司**「自分発信で改善の方向に持っていったのはとてもいい動きでした！」
**上司**「しかし、会の進め方は事前に考えておいたほうが良かったかもです。有意義な時間の使い方ができるように引っ張っていけるとさらに良いです。」
**私**　「そうですね、ノープランで集めてしまったので、ご迷惑おかけしました」🙇‍♂️
**上司**「議事録のドキュメント作って、そこに前もってアジェンダ書いておくと楽です」
**私**　「今回の場合は、どのような議事録を用意しますか？」💦
**上司**「まずはミーティングのゴール設定です。そしてそのために何をするかです。」
**私**　「。。。」💦
**上司**「**自分発信で始める時は、何個か案を事前に出して共有出来ているとスムーズに進みやすいです。**『案を出し合う』を補ってあげることで会を『議論』から始められます。この会開催したらこんな流れになるから、自分でここまでやっておこうみたいな感じがベターですね！」

**私**　「え、そうなの、、、」😨😨😨😨😨

<details><summary>💪 振り返り（成長の記録としてw）</summary>

- [**Keep**]
    - 自分発信で、チームメンバーを集め、主体的に動きミーティングを開催したこと
    - 課題を自分ごとに捉えて、解決しようとした
- [**Problem**]
    - ノープランでミーティングを開催したこと
- [**Try**]
    - 自分発信で始める時は、何個か案を事前に出して共有しておく
    - 議事録のドキュメント作って、そこに前もってアジェンダを書く
</details>

失敗してこんなこと言うのなんですが、インターンの時期の失敗でよかったです！w

何事にも、準備が大事と言うことを気付かされました〜

これを機に、ミーティングの前には、軽く議事録のドキュメント作って、そこに前もってアジェンダ書いてミーティングに臨むようになりました！

毎回フィードバックをくれる上司には感謝しかないです🙇

# 🤔 ノープランでミーティングの何が悪かったのか？

今回の場合で、どこが悪かったのかという話ですよね、、、

悪かった点は、

- **何個か案を事前に出してなかった点**
- **議事録を用意していなかった点**

主に２つだと思っています！

以下では、この２点を軸として説明します！

## 🥺 何個か案を事前に出してなかった点

### 案を事前に出しておかないと？

ミーティングの前に、議題に関する案やその選択肢や解決策を出しておかないと、当たり前に、ミーティングの進行がスムーズに進まなくなります！
事前に案が示されていなかったため、参加者全員がその場で、考える時間が必要になります。

また、参加者それぞれの意見が異なることも当然にあるため、最終的にどのような方向に進むべきかがわからず、結論が出ない場合もあると思います。

### 🤦‍♂️ Problem

今回問題だった点は、、、

> **私**「ここのコーディングのルールを決めたいのですが、どう思いますか？」
**全員**「、、、。。。（沈黙）」
**上司**「この書き方がいいと思いますね、、、」
**私**「ありがとうございます」😭😭😭

始めから「どう思いますか？」と丸投げしてしまった場面ですw
まずは、自分の考えを伝えるべきなのに、他人任せなところがダメでした💦

今回の失敗では、すかさず上司がファシリの自分をフォローしてくださいましたが、
集めたチームメンバーに対して、即座に「どう思いますか？意見を出してください」と丸投げしても、当たり前に「考える時間くれよ」となります。大学や友人間でやるグループワーク程度の経験しかないの自分は、そのことが全くわからず、他責野郎でした〜🙇‍♂️（反省）

## 🥺 議事録を用意していなかった点

### そもそも、なんで会議に議事録が必要なの？

[会議の議事録の必要性とは？効果的な作成方法も解説！
](https://www.ricoh.co.jp/service/toruno/column/minutes-necessity)では、「議事録の必要性とは？」について以下のようなことが書かれていました。

> - 会議内容を記録する
> - 意味のある会議にする
> - 決定事項を共有する
> - タスクを明確にする
> - 責任の所在を明らかにする
> - 過去の会議の流れを理解する
> - 法律要件や業界ルールを満たす

当てはまるものは多いのですが、今回の場合で言うと、一番は**意味のある会議にするため**かなと思っています。

### 🤦‍♂️ Problem

今回問題だった点は、、、

>**チームメンバー**「はい！どう進めますか？」
**私**「とりあえず集まれば決まると思いノープランで集めました。」
**私**「、、、。。。（15秒ぐらい沈黙）」

ノープランで集めて、困ってしまった場面ですw
最初に、議事録の構成（ミーティングのアジェンダ）を書き、あらかじめ共有しておくべきでした💦

この失敗からもわかるとおり、チームメンバー（上司も含む）は時間を割いて、集まっていただいているので、その人の手を止めて、参加してくれています。そのため、とりあえず自分発信（自分がファシリであれば）、最低限、議事録を用意して、アジェンダを書いて共有するべきだったなと、反省しています🙇‍♂️（反省）

あとは、自分からで「話し合いしましょう！」と言って、進行など何も考えておらず、自分の責任感の部分もよくなかったのかなと思っています。チームの決め事なため、自分ごとに落とし込み考える力も養っていかなければいけないと思いました🙇‍♂️（反省）

## 💪 Try

反省したということで、
さてここからは、二度と同じ失敗を起こさないようするため、これからどうするか（Try）のお時間ですね🙌🙌🙌

反省だけして、Tryをしなかったら同じ失敗は起こしてしまします（人間なので）

では、自分がしたことを紹介します。

**社内の議事録をあさり、テンプレート化をした**

今回のコーディングルールの会議であれば、具体的な複数の提案(ケーススタディ、ベストプラクティスの例示など)を準備して参加者と共有するのがゴールです。

そのため、他のミーティングでは、どのような資料が事前に用意されているのかを確認したり、実際先輩エンジニアが案を提案するときに、どういう資料を用意しているのか聞くことなどをしました〜

議事録に関しては、複数の案とそのメリット、デメリットが伝われば、そこまで凝る必要は全くないです！

ChatGPTに書いてもらいました〜、仮ですが

```
案１　タイトル
説明
- メリット
- デメリット

案２　タイトル
説明
- メリット
- デメリット
```
```
案1: golangci-lintによる自動ルールチェック

説明: golangci-lintは、複数のlintツールを統合したGo用の高機能lintツールです。
非常に多くのコーディングルールをカバーしており、CIに組み込むことで自動的にコードをチェックできます。

メリット
広範なコーディングルールをカバーできる
CIに組み込めば自動でチェックされるので人的ミスを防げる
レビュアーの手間が省ける
デメリット
ルールが多いので、カスタマイズや設定が複雑になる可能性がある
一部のプロジェクト固有のルールはカバーできない
案2: Goコーディングスタイルガイド策定

説明: チーム内で統一したGoコーディングスタイルガイドを策定し、
そのガイドラインに従ってコーディングする。コードレビュー時にガイドラインに沿っているかチェックする。

メリット
プロジェクトの要件に合わせてカスタマイズできる
ガイドラインさえ明確にしておけば判断が容易
デメリット
ガイドラインの作成・維持が手間
レビュアーの手動チェックが必要で人的ミスが発生する可能性がある
```

# おわりに

何事にも、準備は大切ですね！

普段、友人と開発しているだけでは、簡単な話し合いで大丈夫ですが、業務で話し合う上では、準備がすごく大事と学びがありました〜

失敗した時こそ振り返りは大事ですね！

振り返り記事は、書いていて恥ずかしいですが、これを読んだ誰かの参考になれば良いなと思っています！

精進します！💪

では、次回の記事でお会いしましょう！👋