bon now

ありのままの現実を書き殴る吐き溜め。底辺SEの備忘録。
Written by bon who just a foolish IT Engineer.

振り返ろう

Created Date: 2018/10/17 23:22
Updated Date: 2023/11/05 03:00
目次:

皆さん仕事で失敗した時どうしてます?
僕はしょぼんとしています。しばらくしょぼんとして、家に帰って何が駄目だったのかとか、 どうすればよかったのかとか、悩みながら寝ます。起きたら大体回復しています。 それの繰り返しで一応なんとか学習しているつもりになっている。

僕の前職では振り返りというか、ひどい障害や失敗をしてしまったときは特別会議みたいなやつで、 原因分析と今後の施策、アクションプランを出し、次のプロジェクトで活用することを義務付けられるようなものが開催されていた。 出席者も普段は会話もしたことのないような取締役とかも出てきてワイワイがやがやとなんかある意味楽しい会議だった。 というのも、普段何考えてるか分からん人たちの意見を直接生で聞けるチャンスってそれしかなくて、 若手なりにも多くのことを学ぶことはできたと思う。
まあ、大抵の場合は形骸化した施策がそのまま風化していって数年後に同じような過ちを犯すみたいなこともあるんだけど。

入社してからずっとそういう環境にいたので、ある意味チョンボしたときの振り返りの重要性というのは身にしみて分かっていたし、 それをするくらいの覚悟を持って仕事をしなきゃ駄目だというのもまあ精神論として教わったと感じている。 でも、今の会社に来てみてそういう気概って意外と無いんだなってことに気づくことになった。

例えばアジャイルやスクラムでは、必ず「型」の中に「振り返り」が含まれている。 この振り返りは視聴者参加型であることが条件で、そもそもリーダーやマネジャーがただ現実と予定の差を喋って終わりみたいな クソみたいなことは許されない。 学びは必ずチームで共有されるべきだし、個々人が振り返りの場で挙がった内容を帰り道や風呂場で反芻することで、 新しいしごとへのイメージを持ってもらわなきゃ困る。 特にベンチャーや中小企業の少ないチームであればあるほど、 チームの協力体制を以て個人の生産性を上回ることが絶対条件として存在しているはずである。 そうでなければ無理に人を増やす必要はないし、より少数のチームで徹夜でもしながら製品を作り上げればいい話だ。

そのためには、チームは1つのベクトルを持つことが重要だ。そしてその内積は当たり前のようにプラスでなければならない。 ベクトルが散らばっていればいるほど、組織の在り方は負の要素を抱えることになる。 このベクトルを合わせるためにも振り返りは重要なタスクなのだ。

過去を振り返ると何が見えてくるだろうか。 失敗、栄光、成功、改善・・・・そして、統計。そう、データである。 ある程度同じメンバーで繰り返しプロジェクトを推進していくと、ある程度のデータが集まる。 データにはテスト項目だったり不具合件数だったり不具合内容だったり作業工数だったり様々だ。 これらのデータを利用するだけで、チームの能力やプロジェクトの成功具合を定量的に評価することができる。

そもそも株式会社は貸借対照表や損益計算書を作らざるを得ないわけで、それは投資家が投資判断をするための目に見える定量的なメトリクスである。 当年度分だけの経営数値で判断する投資家はさほどいないだろう。ここでも定量評価は行われている。 見積もり嫌いな多くのエンジニアにとって会社は勝手になんやかや回っていると感じる面もあるんだけど、そんなことはない。 エンジニアの適当に見積もったプロジェクト予算を信頼して予算を組むし、作業が偏ってしまって暇になってる人がいるにもかかわらず、 そいつに仕事を適正に振れるような状況にないため、 当人は規定労働時間を満たすためにWebを見ながらサボった時間をプロジェクト工数として計上するしかないみたいなときでも、 そのデータを信頼して実績値として算出するわけだ。間接的どころかかなりダイレクトに経営数値に影響を与えているんだということを、 そういう人たちはもう少し理解する必要がある。
プロジェクトそのものだけでなく、組織の健全性や会社のそれを外部に示すためにも、正しい振り返りはめちゃくちゃ重要なのだ。

なんか前だけ向いていれば大丈夫!とか、目の前の問題課題をエンジニアリング技術でクリアしていけば大丈夫みたいな人もいるけど、 それはあちこちに地雷をばらまいて前に進んでいるようなものだ。 エンジニアフレンドリーな例だと、技術的負債と言われる長くやってきたコーディング作業にて発生する「この改修したいけどXXが原因でできない」っていうやつは良い例だろう。
こうならないためにエンジニアは何をすべきだろうか。答えは簡単だ。 良いことを続ける。ガイドライン(型)を作る。悪いことを改善する。たったこれだけである。

じゃあ、これらを明確にチームに対して白日の下に晒すにはどうすればいいだろうか。これも簡単だ。 みんなで振り返る、みんなで決める、みんなで守る。たったこれだけである。

なぜそんな簡単なことができないかって?これもまた簡単だ。 人は一人ひとり違う、チームは人ではない、みんなの考え方が違う。たったこれだけである。 このうち外の力で矯正できそうなのは、正直に「みんなの考え方が違う」しかない。

自治体によってゴミを捨てる日は決まっていると思う。 火曜日が燃えるゴミの日と決まっていれば、みんなそれに従う。従わない場合はゴミは回収されないし、 場合によっては「XXさんはゴミ出しルールを守ってない」とハブられる。ルールが決まると道徳心も一様に定まることが多い。 ただ、何をやってもルールを守らない人はでてくる。
会社の場合は懲戒すればいいんだけど、そういうこともできにくい世の中なので、 この場合はルールを守れない理由を問いただすしか無いかもしれない。 もしくはチームの外に飛ばすかだ。どこかの会社がこのような話で裁判沙汰になっていたけど、 正当な理由さえあれば何ら違法なことでもないだろう。その証拠をしっかり残すためにも統計は重要である。

まとめ

みんなで振り返ろう。未来のことばかりじゃなく、過去から学ぶことはたくさんある。
僕らの使うコンピューターだって過去の失敗と成功の研究があったからこそ成り立っている。

素早く振り返って素早く切り替えて、少しずつでも改善して前に進む。そのスピード感こそいまの社会に求められているものだ。

local_offer
folder blog