朝会が育む内省するスキル


プロジェクトでは、いや、普通のルーチンワークだったとしても仕事をしているなら朝会を始めることをお勧めするし、やらないなら「なんでやらないの?恥ずかしいの?機会を先延ばしするの?」って詰め寄っちゃいますよ。


朝会を毎日決まった時間に全員が集まって短時間にやることには、全員の日程上のポジション、メンバ同士の情報共有、困っていることへの相互扶助、空いている時間の視覚化などなど、書き出したらメリットがキリが無いのですが、一人のエンジニアとしてのスキル向上のメリットもあるんだよなぁ、と常々感じているのです。


内省
内省とは自分の行動をかえりみる行為です。ただ、かえりみるだけではダメでフォローアクションに至るプロセスになっていないと単なる反省になってしまいます。

ない‐せい【内省】
[名](スル)
1 自分の考えや行動などを深くかえりみること。反省。「過去を―する」
2 「内観(ないかん)」に同じ。


朝会は朝にするのだからその時間には共有できる準備が終わっていないといけません
朝会は毎日決まった時間に開きます。朝会ですから、朝会を開くのにお勧めする時間は出社15分後あたりが良いと思うのです。出社して席についてPC立ち上げてメールを眺めて15分。短いように思うならチームで相談してみたらいいと思いますよ。


でも、これまで朝会、昼会、夕会といろいろ試してみて、朝会が良いのはこれから今日やるタスクをリマインド出来るからだし、困っていることがあれば相談する時刻を決めて、それに合わせてログなどをそれまでに揃えておいて相談にのってもらう段取りをつける算段をしたりすることが出来るからなんですね。


で、出社して30分以上後にすると何とな〜くタスクに手を付けてしまって朝会自体を忘れちゃたり、タスクのキリが悪くて気持ちが面倒くさいと言う後ろ向きの気持ちになっちゃ人が多いようです。だから、出社時間の15分後、なのです。


朝会に限らず、昼会、夕会にしても続けていくためには決まった時間に始めるのは鉄則ですが、チームのメンバが集まりやすい時間にするのも続ける工夫の一つです。昼会ならお昼ご飯の後すぐ、っていうのもアリです。夕会は定時帰りの時間の前でもいいのですが、夕会はその場で言いっぱなしで翌日きちんとフォローアクションが出来るかと言えば誰か、端的に言ってプロジェクトマネージャが言いっぱなしのアクションを落ち葉拾いをするようにフォローしまくる必要があるので「チームのアクティビティになりにくいかなぁ。」と思いますね。


昨日のことを共有するには昨日自分がやったことを内省することが必要なのです
朝会では一人が共有するための情報を提供する時間は限られます。だって、全体で15分でおしまいですからね。担当するタスクを前日にやって、その進捗、チームで決めたプロセスのどこまで進める計画だったのか、実際どこまで定義した完了まで漕ぎ着けたのか、一人で解決できないことが出てきたのかなど、要領よく伝える必要があります。


メンバの人数にもよりますが、だいたい1-2分です。どうです?思った以上に短いでしょ?そのくらいで伝えるようとするならそれ相当の準備が必要になります。何を報告しないといけないのか、何を相談事として共有して知らせ相談に乗ってもらわないといけないのか、内省をしたうえで、話し方の段取りも考えておかないといけないんです。じゃなければとてもとても1-2分でなんか話せませんよ。


内省する、自分の行動をかえりみるためには自分がしていることを客観的に把握する必要があるし、誰が聞いても理解できるように口頭で説明しないといけないわけです。説明するためにかえりみる、かえりみる度に自分の行動で上手くいかないところを認識する。上手くいかないところを上手くやろうと気付きを見つけたり、工夫をしようと試行錯誤するきっかけを内省は作ってくれます。


内省がキッカケを作ってくれるのは、あくまでも機会として、です。その機会を利用するしないはエンジニア本人です。朝会で毎日繰り返ということは、自分のやっていることをサマって報告するために自分の行動をかえりみる訓練していることなのですからそれをやっている自分をどう躾けるかも本人次第です。ただ、朝会に出てやっていることを共有しているだけではないのです。



内省をしているかいないかもエンジニアの管理リソースを割り振る判断基準
内省をしている、していないかは、毎日の朝会の報告が上手になっていくか、変わらず下手なままかを眺めていれば自然とわかります。こうした口頭で進捗をわかりやすく話すスキルはシステムエンジニアの経験年数には全く依らないところを第三者の視点で見るのもなかなか興味深いものです。



何が興味不深いかというと、上手になっていくエンジニアは何等か工夫をしているので作業効率、作業品質が向上するのです。片や、朝会の報告が一向に上手にならないのは、毎日の繰り返し作業を面倒だから効率的にできないか工夫したり、楽をするためのチートをしようとしないエンジニアなのです。こうした観点でエンジニアを識別することも限られたプロジェクトマネージャのリソースをどこに重点的に配分するかという判断基準の一つとすることが出来ます。