ソフトウェア開発の現場でプロジェクトのマネジメントなどの仕事をしていると、

定例会議でシェアすべきことと個別に相談すればいいことを、

どのように分けるのか、線引きを何処にするか悩むことがあります。

私は元々はエンジニアとして現場で開発をしてきた人間ですが、

プロジェクトのマネジメントや、ディレクションをすることが最近は増えてきまして、

最近では色々と経験値が溜まってきたので、「朝の会議」でシェアすること、しないこと

と題しまして、今日は記事を書いていきます。

主にウェブサービスなどのプログラミング開発などの現場で、

中規模（１０人程）くらいのチームを想定してますので、

そのつもりで読んでください。

朝の進捗確認は５分で済ませる

まず、チームの現場では、毎朝の朝会をやる会社と、やらない会社があると思いますけれども、

私は毎朝の朝会をやるのは賛成です、そして、その朝会では主に、

三つのことをチームのエンジニアにシェアさせます。

• ①昨日やったこと
• ②今日やったこと
• ③今悩んでいること（あれば）

①と②を発言させる意図は、本人が毎日の報告を義務付けることにより、

今の自分がやるべきことを認識させ、エンジニア一人一人のモチベーションとか責任感を向上させ、

チームとしての一体感も増やすことが目的としてあります。

そして③に関しては今自分が少しでも悩んでいることがあれば相談しても良い場所を作ることで、

仕事の相談のきっかけを作りやすくするという目的があります。

大抵、エンジニアが仕事で詰まって時間がかかりすぎる局面は、単純に相談するのが遅れてるだけで、

少し相談すれば迅速にアドバイスをもらえて、後は自走で解決できることはザラにあります。

なので、僕はソフトウェア開発の現場での朝の会議っていうのは、

どちらかといえば、何か全体に伝えることというよりかは、一日のプランを皆んなで合意する感じで、

粛々とやれば良いのかなと思いますし、何か新しいことを試すのは、そんなに頻繁じゃなくても良いと思います。

だって、十中八九、チームではTrelloとかAsanaとか、Click Upとか使ってタスクの管理はプロマネがしてると思うので、

別に、個別にエンジニアが毎日報告する必要は特にないわけですが、チームが一丸となって同じ方向を向くために、

簡単に済ませるにしても、朝のミーティングは敢えて結構大事だと思います。

ていうか、エンジニア自身も、

今これやってて、これが終わったよと報告することで仕事してる感が上がりますし、

最近ではリモートワークも増えてるため、働いてるエンジニアがプレッシャーを感じにくくしてあげる効果もこれにはありますね。

でも大事なことは、見出しにも書いたけれども、

ここの報告で時間を取ると一日の作業時間が減るので、これは原則一人５分以内で済ませるようにしましょう。

それで、各自で何か悩んでいることなどがあれば、「今こういうことで悩んでます」と報告だけして、

全体の朝のミーティングの後、リードエンジニアに個別に相談すると良いです。

私のおすすめはチームにDiscordを導入することで、とても簡単に音声通話や画面シェアが出来るので便利です。

ZoomとかGoogleミートみたいに煩雑じゃないので、軽い相談とかはベストだと思います。

全体MTGでは原則ダメ出しや叱責はしない

僕はエンジニアとして活動してるときに、チーム内でタスクの遅れがそんなに明白でもないのに、

全体MTGで執拗に劣っている部分を指摘されてかなりメンタルが落ち込んだことがあります。

そして、同じような形で叱責されダメ出しを受けてる人を見たこともあります。

それで、そういう人に限って皆んなの前でわざわざ怒られると逆にパフォーマンスが落ちて、

尚更仕事が出来なくなる人も結構いました。

なので、ハプニング的に、皆んなの前で、その人の欠点が明るみになることはあっても、

基本的にタスクの遅れや、コードの実装の問題や、業務のやり方が正しくないなど … etc

その人に伝えれば直る問題に関しては、slackでDMしてもいいし、こちらからちょくちょく声かければ良いと思っています。

これが、僕のプロマネのやり方です。

コーディングや変数名などの規則は全員シェア

チームのエンジニア全員にシェアすべき情報の一つは、

なんといってもコーディングに関するルールだと思います。

基本的な変数の名付け方とか、チームできまってるコードの書き方とかを決めるのは重要だと思います。

どうしても、分かってない人がPRで変数名を指摘されるくらいだと直らないことが結構ありまして、

チーム全員で時間とってコードの書き方や、変数名、コードの読み解き方をリードエンジニアが解説することで、

チームの技術力は格段に上がると思います。

特に変数名とかコード規約は、チームのwikiに書いておくだけじゃなくて、

しっかりチームで時間を作ってミーティングしても良いことだと思っています。

サービス機能に関することは個別に相談した後に社内Wikiに蓄積する

また、サービスを開発していくと、「この昨日の権限規制はどうするか」「この設定画面では何が具体的に出来るのか」など、

色々と分からないことや、追加で決めなきゃいけないことが増えてくると思います。

そういう問題は、私は全体でシェアすべきことではなく、個別でプロマネと開発者が議論して決めて、

プロマネが詳しくサービスの動きに関して社内wikiで書いておくのが良いのではないかと思います。

こういうサービス全体の機能とかは、全員知っておくべきことかもしれないけれども、

注ぎ込める時間があまりなくて、コストを抑えたい場合は、

どうしても全員で一々サービスに実装されてる機能を話し合ってると時間がなくなります。

だから、新人エンジニアとか、忘れた人がいても大丈夫なように、事細かくサービスの機能とかは社内ウィキに書いておいて、

次にその画面をいじる人で、わかってない人や、抜けてるところがあったら、「これ呼んでください」と、

記事を渡すだけにすれば便利で時間も節約できるかなって思っています。

おわりに

以上になりますが、簡単にではありましたが、

朝の会議でシェアすべきことと、個別に相談すべきことを、

ソフトウェア開発の現場を例に考えてみました。

まだまだ色々とあると思いますけれども、今日はこんな感じで終わりたいと思います。