仕事のふりかえり

先週の金曜日、一人遅くまでオフィスに残っていて静かに考え事ができたので、仕事のふりかえりをした。日報に送った内容だけど、気づきを忘れないように記録としても残しておく。

−−−

今週はシステムの設計部分に時間を割きすぎたなと反省しています。
手戻りや変更が少ない完璧に近い設計を追求することと、ある程度は開発者の裁量に任せて走りながら考えるという状態を許容すること
の2つのバランスにおいて、前者に比重が傾いていたなと思います。
PMの業務をやりながら感じることは、コミュニケーションや進捗・タスク管理というアウトプットが見えづらい仕事に自分の時間が多く割かれるなということです。
自分の仕事としてアウトプットが形に残りづらいので、「これだけ働いたのに形として残っていない」と焦る気持ちもあるのですが、
かといって自分が手を動かしてアウトプットを残そうとすると、他の人に作業を振ることが出来ないでスケールしないしリソースの使い方も全体で見ると非効率になります。
そのうえ本業の橋渡し役が務まらないで自分がボトルネックになりがちになってしまいます。
「プロジェクトをマネジメントするためにあれもこれも把握しておかないといけない、自分が全ての作業に関与していないと不安だ」
と考えてしまうのが現状の自分の悪い点なので、全てを知る必要はないとある程度達観することと、作業に携わって状況を知るという方法ではなく、
自分が何もしなくても作業者のほうから進捗が報告されるような仕組みをつくることが、PMの本業に集中するためには必要だなと感じました。
ひとまず今日はタスクと進捗を整理しなおし、自分の立ち位置とプロジェクトの状況を再認識しました。

====

あとはいち技術者として思うことは、学生のときに身につけた技術周りのスキルは所詮アマチュアレベルだったなということです。
今まで自分のなかでは、仕様どおりにとりあえず動くプログラムは作れるな、という自負が少なからずあり、
万が一不具合があっても軽微な修正を行う程度だったので、そこまで下手なプログラムを作っているとは感じませんでした。
しかし対価としてお金をもらうレベルのプログラムを作るためには、目に見える要求仕様を越えて、
複雑なビジネスの手続きそのものやロジックの変化を吸収できる仕組みを、裏側に作れるようにならないといけないなとこのごろ感じています。
(拡張・変更・例外に耐えうるシステム設計、万が一障害が発生しても一秒でも早く復旧できるような仕組み、その障害の原因を特定できる仕組み、etc)
そういう意味でアマチュアとプロの違いは、
・アマチュアは仕様通りに動くものは作れても、何かが起きると都度自分が動かないといけない、自分の時間を奪う技術的負債を作る
・プロは仕様を越えて、どんなことが起きてもほぼ自分の動くコストがかからない、あるいは自分の時間を使う場合であっても正当な理由をもって顧客からお金を請求できる、お金を生み出す資産を作る
かなと思いました。
このあたりの設計のスキルは、ある程度経験がものをいう部分だろうと思って、焦らずに今後じっくり身につけていきたいです。

LINEで送る
Pocket

コメントを残す

*