社内のある研修に参加した時(とその後)に「良いフィードバックを得るためには…」を考えさせられたので書いてみます。

その研修は、(何度も行われているものですが)私が参加した回はそれまでのやり方を大きく変えたとのことでした。
＃私は「それまで」をあまり知りませんが。

進行役の方が「ぜひ(やり方を変えたこともあって)フィードバックを得たいので、アンケートを後日送るので、忌憚の無い意見を聞かせてください」と言っていました。
本当に忌憚の無いフィードバックが得て、良くしていくつもりなら、その場で声をかけて(10分でも良いので)直接話したりするのが良いのにと思いました。
＃午前中の研修だったので、なんならお昼を食べながらでも。

会話だと受ける側も「なるほど～、じゃあ、こういうのはどう？」と、キャッチボールをしながら進めることができます。
また文章だと当たり障りのない回答になりがちでも、会話を通じて(論理的ではないかもしれませんが)本音を聞けたりします。

話を戻すと、そのアンケート依頼が届いたのが研修から1週間後のことでした。
忙しい現場だと、1週間も経つとせっかく研修で得た気づきやフィードバックも薄れていることが多いです。
「あぁ1週間前の話かぁ、どうやったけなぁ…今、忙しいし、当たり障りのないこんな感じで…」という感じで。

そんな状況だと本来得られるフィードバックの価値が小さくなり、もったいないと思います。
＃私はアンケートの回答に「アンケート依頼が遅いっす」と書きましたが(笑)。

「アンケートを取る/取って分析する」のが目的となっていて、その先にある「研修を良くする」や「参加者にとってより価値があるものにする」意識が弱いのかなと思いました。

※注意：この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。

Photo credit: cogdogblog via VisualHunt / CC BY

今回は、ある会議に出ていて「もう少し効率良く時間を使えるなぁ」と思ったことを書きます。

出席者は地理的に離れている複数チームです。
チームごとのタスクは異なりますが、活動領域には重複する部分もあり協力して動くのが良いという状況です。
日常の情報共有も社内SNSを使って頻繁に行われており、そこに進捗や状況、課題などを書き込んでいます。
会議は、その社内SNSをみんなで見ながら進めていきます。
割とアジェンダもあり、決め事もそれなりに決まっていくのですが、こうしたらもっと良いのになぁと思う改善点があります。

それは報告の仕方…より言うと【報告行為自体をしないで良いのでは？】ということです。
会議の中で、その社内SNSに書いていることを読み上げていくのです。
この時間がもったいないなぁと思うわけです。
＃書き忘れていたことや些末なことは口頭で補足して良いとは思いますが。

タスクの特性上、「報告」をインプットに「どうしたら良いか？」「そもそもどういう方向でするべきか？」など施策や手段を議論する必要があるものが多いので、そちらにより時間を使えればなぁと思います。
＃そういう議論が不要なら、それはそれで会議が早く終わるので、良いことです。

事前に報告を確認できる社内SNSを読んで、質問や意見をそれなりに考えた上で、議論するように時間を使ってみたら…と思うわけです。
「忙しくてそれを読む時間が無くて…」という方もいます。

ただ、報告を読んでそれなりに考えるのは、10分…長くても30分もあればできると思います。
その時間を取れない程、忙しいのであれば、そもそも会議に出るよりも、その忙しさを解消するようなアクションをした方が良いと思います。
＃議事録はその社内SNSを見れば分かりますし。

あと思うのは、その場で初めてその報告を読んで、深い議論をしたりできるんだろうか？と思います。
＃頭の回転が良く、即応性に優れていれば良いのですが、私はこの辺が苦手なので…。

この会議が始まった当初は交流がなく、そもそも「お互い何やってるか全く分からない」状況だったので、お互いを知る目的もあり多くの時間を使い、このやり方をしていたと思います。

最近はそれらの目的も達しつつあるので、もっと「リソースの選択と集中」など議論の時間を増やし、ステップアップを目指しても良いと思います。

※注意：この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。

Photo via VisualHunt

1～3年目のような経験の浅い方が見積もる「レビュー」タスクの工数について思うことがあります。

レビューはある成果物…提案書や設計書、ソースコードなど…を個人/複数のメンバー…たいていはプロジェクトリーダやプロジェクトマネージャなどの上司や有識者…と行います。
成果物の内容や分量にもよりますが…例えば、(類似機能がない)新規の外部設計書…だいたい「一発合格」はなく、いくつかの指摘事項があるものです。
指摘事項は「て・に・を・は」や語尾の不統一…こういうのはセルフチェックでつぶしておきたいものです…から、設計内容自体に対するものまで色々です。

それらの指摘に対して、対応要否の判断、要であれば対応が必要になります。
例えば「語尾が不統一」と指摘されれば、見直して修正する必要があるでしょう。

また「ここのA機能は、XXモジュールから流用すると書いているけど、YYという視点では確認した？」と質問があり、自分が「YYという視点」で確認していないのであれば、調査(とその結果の報告)が必要になります。

というように考えると、レビュー後にもそれなりの工数が必要になります。また指摘事項によっては、再レビューとなり、そういう工数も必要になります。

そういう特性の「レビュー」タスクを経験の浅い方が見積もると「レビューは一発合格、あっても文字の修正ぐらい」というイメージとなっているように思います。
＃考え方として「レビューでの指摘事項はありません！」という気概で望み、目標にするのは良いことです。

私が「レビュー」タスクの見積もり工数を(作業前に)確認する場合は「どんな作業イメージしてる？」と問いかけるようにしています。
たいがいは「レビュー受けた後はちゃちゃっと修正して…」と答えが返ってきます。
　
そこで、過去に自分のレビューを「そんな感じ(ちゃちゃっとで済む)だった？」と思い返してもらい、その根拠や妥当性を深掘りしていきます。
その結果、なるほど～と納得できるならそれで進めてみます。
＃チームとしては多少バッファを持つようにしますが。

これらレビュー後の対応工数、タスクはスケジュールに明確には乗らないことも時々ありますので注意が必要です。
＃「レビュー」自体に紛れ込んでいたりします。

※注意：この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。

Photo credit: ivyhouse.jesse via Visualhunt / CC BY

仕事関係のタスクを記録しているTodoリストがあります。
このTodoリストを更新するタイミングについて、(自分にとって)より効率良く仕事ができた方法を書いてみます。

Todoリストの更新タイミングを(その日ではなく)「前の日」に行っています。
ここでいう「前の日」とは、帰り際(残業をガッツリする場合は夕方頃)を指しています。

その日の朝、出社してから、前日のタスクを思い出し、その日のタスクを考えて更新する方もいると思います。
＃私も以前はそうしていました。

その日の朝に行った場合、昨日の事を思い出したり…「はて、昨日はなにやってたっけ？」…するのにエネルギーが必要なこともあります。
また、その日に行うタスクも、段取りやポイント…「あ、あのタスクをするならあの資料を探さないとあかんな」…を今から考え始めるので、効率があまり良くありません。

これでは、せっかく元気がある午前中の時間を効率良く使うことができません。

一方、帰り際に更新することを考えてみます。
今日のタスクは覚えているでしょうし、頭も仕事モードなので、明日のタスクも漏れなく洗い出すことが割と容易にできます。
明日のタスクについても、(まったく筋道がないわけでなく)なんとなく…誰と調整が必要なのか？関係する資料はどれか？…の段取りまで組み立てることができます。
これを実際にやってみたところ、出社してからタスクを考えずに、タスクを行うことに集中できたので、効率良く仕事ができたと思います。

さらに、帰宅途中から出勤途中の間に、(帰り際に更新したTodoリストが熟成されるのか)ブラッシュアップ…「あのタスクはこうしたらうまく行くのでは？」「このタスクを先にしないと効率悪いな」…が思いついてくることもありました。
そういう点でも、午前中の時間を有効利用できると思います。

一方、この運用の難点です。
それはガッツリ残業したりして、翌日のことを考えるエネルギーが全然ない場合があることです。
これを回避する方法として、Todoリストを更新する時間…まだエネルギーが残っている夕方の時間…を決めています。
10分でもなんとか時間を取るようにしています。

この夕方に時間を取る方法の副次効果として、残業に入る前にTodoリストを見直すことで「そのタスクは(残業してでも)する必要があるのか？」を再確認できます。

(突発タスクや自分が影響できないタスクもありますが)自分がコントロールできるタスクはこのようにして効率良くしていきたいものです。

※注意：この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。

Photo credit: Mufidah Kassalias via Visual hunt / CC BY-ND