新卒が学んだ「会議を進めていく上でやっておくと良いこと5選」

はじめに

皆さんこんにちは！開発系の部署に配属された、2022入社新卒R.Mです！
メイン業務はモバイルアプリ開発で、Flutterを使用しています！

学生時は生命科学系を専攻してましたが、3年生くらいからプログラミングに興味を持ち始めて、簡単なiOSアプリを開発してました。
研究はPythonを使って、創薬に関することを色々やってました。技術を学ぶことも楽しいですが、ビジネス関連の話を聞くのも楽しい人間です。
ちなみに、趣味の中で今一番熱いのがK-POPです🔥

背景

この記事を書こうと思った理由・背景なのですが、自分自身配属されてから、触ったことのない技術(Flutter・Dart)を、社内で教えてくれる人がいない中で開発ベンダーさんと協力しながら勉強し、約2ヶ月間過ごしてきました。

はじめは課長とベンダーさん、自分含めて4人で定例会議を行っていましたが、今では一人でベンダーさんと進捗共有などを行い、プロジェクトを進行しています。

新卒でこれらの経験は中々無く貴重であり、得られたものも多かったと思っているので、プロジェクトを進めていく会議上でやったほうが良い！と思ったことを個人の主観でまとめてみました🎉

⚠️やっておくと良いと書いてますが、絶対必要でしょ！っていう意見もあると思うのでそこはご了承ください。
具体的にそれをどうやるかまでは書いてません🙏

【１】情報を同期すること

情報を同期するとは：
会議に参加しているメンバー全員が、プロジェクトに関して知らない情報を共通認識として持つことを指しています！

私達のチームは開発タスクをここで共有しているのですが、この仕組みがあるだけで、

• 新しいタスクはあるか
• 既存のタスクの状況はどうなっているか
  • 未対応・対応中・対応済み
• どのバージョンでこの機能（タスク）を実装するのか
  • ※スマホアプリなので、バージョンごとにリリースする機能を事前に話して決めます
• このタスクにかける時間はどのくらいか
• このタスクは誰が担当するのか

などを決めることができ、その場のメンバーに共有もできます。

これらができていれば、、、

■タスクが終わっていれば順調と判断でき、終わっていなければその原因と課題、次への対策まで検討が可能！

■タスクの管理漏れがなくなる！🔥
→今日、誰が何をしているのかが分かり、PMも全体状況を把握しやすい！

【２】ロードマップを立てること

スマホアプリ開発の場合では、

• バージョンごとに、「いつ」そのバージョンを世にリリースするかを決定
• タスクごとに、「いつ」そのタスクを「どの」バージョンに含めるかを決定
• タスクにかかる時間を元に、1スプリントで完了させるタスクを決定
  • スプリント = 単位の無い一定の期間。私達は1スプリント = 1週間と定義しています〜

これらをロードマップを立てる、として実施しています。

これらができていれば、、、

■いつまでに、何が終わるのかが見やすい！
→臨機応変に、プロジェクト進行の調整を行うことができる！

■次スプリントのスケジュールも立てやすい！
→仮に1週間程度で5個くらいのタスクを終わらせたとすると、次の1週間にタスクにかける時間の目安もすぐ分かる！

【３】パーキングロットを確保すること

パーキングロットとは：
議論する際に、今すぐ話し合うべきではないと判断される話題などを一旦保留しておくために、机やホワイトボードの隅などに設けられるスペースのこと。
▷▷▷会議が終わった後に、話したい議題について必要なメンバーだけ集まって話す流れのこととして定義しています！

私の場合によくパーキングロットで話す内容が、

• モバイルアプリ開発における技術的な質問
• 使用するツール
• 細かい話
  • コミットメッセージの規則
  • タスク要件の再定義など

など、たくさんありました！中でも技術的な質問が一番話していましたね😌

会議が終わった後に、個別でパーキングロットを開きます。話したい人は話して、聞く必要がある人は聞くイメージですね。

これができていれば、、、

■議論の混乱や、無駄な議論を避けることができる！

■話を聞かなくても良いメンバーの時間を奪うことがない！

【４】変化があったものは記録を残すこと（その場で）

イメージは、議事録という「誰に見せても分かるようなテキスト」ではなく、「話した内容が思い出せる粒度のメモ書き」みたいなものを想像してもらえると嬉しいです！！
それを、会議の最中に書いてしまいます！会議後ではなくです！

これができていれば、、、

■メンバー間で共通認識が常に取れる！
→専門的な話でも、言語化して記録されているので、どのような内容かはざっくり把握できる

■後から証拠として出せる！
→相手の認識に齟齬がある場合に、メモを見せれば即解決！

■図や画像なども乗せることができて、イメージしやすい！
→これも口頭で説明するより図で説明したほうが圧倒的にすぐ終わる

※記録がないと、後から再度聞くという二度手間になりますし、見返したい！と思った時に見れない、図が合ったほうが良い時に分からない、という最悪なことになります😇新卒研修の際にも可視化することの重要性を知りました。

【５】認識の齟齬がなくなるまで会議を終わらせないこと

これは、曖昧な理解のままで会議を退出するなあああああ！！！！って意味ですね😇
チームでやることというより、個人で意識してやっておくと良いことになります。

分からない、と思ったまま退出するのが、自分にとってもチームにとっても危険です、、
ちょっとした疑問でも、その会議中で質問して解消するまで行うとGoodかなと、個人的には思ってます！

これができていないと、、、💦

■自分がこれから何をするのか分からない状況に陥ってしまう、、
→会議終了後にすぐ動ける状態になっていないのは、自分が一番困ってしまいます！席に座ったら何をしたらいいか想像できるくらいまで、理解の粒度を細かくしましょう〜！

■後から分からない点を聞くはめに、、
→自分のも、相手の時間も奪ってしまいメリットありません！（手戻りってやつですね）わかってはいるものの実行に移すのが難しいのですが😇

【※】開催頻度は毎朝☀️

これは、自分がプロジェクトを進めるにあたってスムーズに進められている要因の一つでもあ
ったので書きました！

毎朝開催すると、、

■プロジェクトの進行状況が1日置きで分かる！
→何が進んで何が進んでいないかが明確！

■手元にきた重要な情報もすぐ共有できる！
→共通認識がとりやすい！

■分からないことがあれば、直接聞ける！
→テキストで聞くより圧倒的に早いから工数削減につながる

逆に毎朝開催しなかった時に一番困ったことは、自分目線、「分からないことを聞くこと」でした。
技術的な質問なんて、細かいところを文章で書き起こさないといけない場面がいくつもありました。
それを長文で返して、長文で返ってくる、それをまた長文で返す、みたいな繰り返しでほぼ1日経ってるやんけえええ！！って思った日もあります。
毎朝であれば質問があれば聞く機会が既に設けられているので、心理的安全性もありますし、聞きたいことがない日はそれでOKなので非常に助かっています！

最後に。

以上です！
（書いた内容がMECEにそってないかもしれませんが、追々意識します、！）
見返すと、意外と当たり前なことやな🥱って思った方も多いかもしれません！
ただベンダーさん会議とは別で、社内の会議にいざ参戦！してみると、そんなこともなく、バラバラでした。

「会議」って一言で表せるけど、かなり奥深くて大変ですね😇
ベンダーさんもいつまでも契約が続くわけではないので、この当たり前は自分の中でも維持して、プロジェクトをスムーズに進めていきたいな！と思ってます！

※余談ですが、この間ちょうど社内の会議やコミュニケーションの最適化について議論する場に参戦したのですが、少し似たような話も上がってたので、少しは考え方が共通しているのではないかと思いましたっ

閲覧いただきありがとうございました〜！🥰