代表ブログ

今週はプログラムチームの一員として、
デキテルの機能改修に参加しました。

約7年ぶりのデキテルの機能追加の実装なので
かなり苦戦して、追い込まれて、
今日は朝の2時半に起きて3時過ぎから事務所で仕事しています。

残業を禁止しているので、
終業時間外に働くのはあまり褒められたことではないですが、
何とか期限内に形にすることが出来た感じです。意地です。

結果として得るものがとても多かった、
プログラムチームに参加しての感想を書いてみたいと思います。

今のプログラムリーダーはメッチャ頑張っている

 
もともと、
プログラムチームに参加したきっかけは、
現在のプログラムのリーダーから
「必死に、頭を使って、考えて、良いプログラムを書いても評価されないのは嫌だ」
という、もっともな意見でした。
「難しい課題をするだけ損だと感じる」
という厳しい意見ももらいました。

人間は承認欲求を持っていますので、
良い仕事をすればその仲間に褒めてほしいと思うものです。

マズロー的に言うと承認欲求は、
生存欲求や安全への欲求よりも上位の欲求なので、
承認してほしいと思うことはとても健康的なことだと思います。

また、共に喜べる仲間が欲しいと思うのが自然です。
職場に何人、人がいても、自分が仲間と思える人がいなければ、
その人は孤独の中で仕事をすることになります。

自分も一人で仕事をしていた期間が長かったので、
孤独な仕事はつらい、というのを身にしみて体感しています。
（孤独な仕事はストイックになるのでクオリティは上がることもありますが、それはその人が主体の場合に限られると思います。余談です。）

彼は今まで、職場の中で
自分の良い仕事を褒めてくれる人もいなくて
とても孤独だったと思います。
ある意味で仲間がいなかった状態だったのだと思います。
悪いことをしたな、と思います。

今回、デキテルのプログラムソースを
しっかりと触るのはもうたぶん7年ぶり？くらいで、
機能追加をするのは初めてでした。
やったことが無いので、出来るか不安でしたが、
上記の目的のためにチャレンジをしました。

その中で感じたのは、
彼、メッチャ頑張ってるやん
ということです。

キッチリした性格を反映して、とても整ったコードを書いています。
デキテルは8年以上前にリリースしたサービスなので
かなりレガシー（古い）コードなのですが、
そのコードを少しでも分かりやすく書こうと
知恵を絞っているのが分かりました。

これは、コードを見るだけではわからなくて、
実際に彼の作ったコードやメソッドを使って実装してみて
はじめて体感することが出来ました。

また、デキテルは、コードがあちこちに散らばっていて、
思ってもいないところでバグが爆発する、という
ある意味で地雷だらけなサービスなのですが、
うまく地雷を踏まずに実装しているのは素晴らしいと感じました。

自分が書いていないコードを触るのは、
自分が書いたコードを触る何倍も気を張らないと
バグにつながるということも実感できました。

その環境の中で、
とても前向きなエネルギーを割いて頑張ってくれていたんだなぁ、
と痛感しました。

リアルタイムに評価できずにごめんね。
んで、今までのプログラマーのみんな、ごめんなさい。
やってみて、難しさが分かりました。

チームが出来てきた感じがする

 
今までのシステムチームは個人のプログラマーごとに
自分というディレクターとつながる、という仕組みでしたが、
今週からはチームで何件のタスクをこなす、
という目標設定に変えました。

みんなで何件、という目標設定の効果はてきめんで、
全員で目標を達成するために一気にチーム感が出ました。
それまで、活発ではなかった質問や相談が活発に行われ、
課題があれば厳しい意見も率直に述べれるようになって
全員で目標を共有する大切さを痛感しました。

目標を設定してクリアする成功体験を多くしていければ、
さらにチームとしての自信が出来て
より良い仕事が出来るようになってくると感じています。

時間のプレッシャーは想像以上に強い

デキテルは内容も難しいのですが、
それ以上にきついのは時間のプレッシャーでした。

プロとして制作をする以上は納期があるのは当然ですし
プレッシャーの中で仕事をするのに慣れる必要はあるのですが、
時間が迫ってくると頭が全然回らない、
というのも体感することが出来ました。

一応40代半ばで、自営業から初めて独立して18年くらいになり
色々なプレッシャーは経験してきた自分でもきつく感じるので、
20代の人とかは想像を絶するプレッシャーだったんだろうな、
と思います。ごめんなさい。

うちで未経験から成長した人は多く、
独立を果たしている人の割合はかなり高いほうだと思うのですが、
その根本の理由はこの時間のプレッシャーなのだと思いました。
プラスに考えればこのプレッシャーに慣れることで
プロとして成長しやすいとは思います。

ですが、
今まではこの時間のプレッシャーに加えて
さらにプレッシャーを与えていたので
プレッシャー過多になっていたんだと思います。

圧を加えるのではなく、
掛かっているプレッシャーを和らげる
ぐらいのポジショニングを取る必要があったんだと反省しています。

ただ、時間を守れたかどうかについては
数字で客観的に見れるようにしておけばよかったんだと思います。
せっかくタスクタイマーがあるのに
うまく使えていなかったとも感じました。

今のタスクタイマーの改修ではその辺りをしっかり数値化して、
自分個人ととしてはメンバーのプレッシャーを
和らげる立ち位置を取るのも必要だと感じています。
（入社して3か月くらいの間は、研修モードでプレッシャーを強める可能性もありますが、、、）

遅延報告を出すのは めーーちゃ イヤ！

上記の時間のプレッシャーを最大に感じるのが、
遅れた時にチャットで提出する、
「遅延報告」の存在です。

決まったフォーマットに書き込んで
チャットに流すだけなのですがこれがメッチャ嫌です。

一生懸命やってきた目標が達成できないことを突き付けられて、
みんなにそれを伝える、それが遅延報告なので嫌なのも当たり前ですね。

怒られなくても、
何も言われなくても遅延報告を出すのはホントにこたえます。

なので、遅延報告に関しては最初の研修時に、
出すのは嫌なものだ、という認識さえ持ってもらえれば
あまりプレッシャーを与えなくて良いくらい強い仕組みだと感じました。

報告に時間がかかる

上記の遅延報告ですが、書くのにけっこう時間が掛かります。
生産的ではないのであまりここに時間をかけ過ぎるのも良くないので、
タスクタイマーで時間が掛からない仕組みにしようと思います。
その機能が出来上がるまでにフォーマーットを決めて
チームで共有したいと思います。

最後は気合いで喰らいつく

経験の少ない人がプログラムを書くのはメッチャ大変なことですが、
最後はどこまで先輩の書いたコードに喰らいつけるか、
の一点になると思います。

最初は見えなかった答えやロジックが、
見続けて、
手を動かし続ければ、
どこかのタイミングで必ず見えてきます。

まぁ、いろいろと書きましたが、
これも自分がみんなの苦労している仕事を体感できたことで、今
まで得られなかった情報を得て、
いろいろと考えることが出来たことの効果だと思っています。

自分もみんなの感じている厳しい仕事を体感して
ホントに良かったと思っています。

期日と目標を設定して仕事をすると、
プレッシャーがかかって、
逃げたくなる心理状態になりますが、
何とか達成すると
それまで感じられなかった充実感を感じることが出来ます。

仕事は成功すれば楽しいし失敗すればしんどい、ものだと思います。
一人ではなくチームの仲間で達成できれば
その成功の喜びはさらに増えると思います。

みんなで成功を重ねられるチームにしていきたいと思います。

電子書籍にまとめてみました。

「正社員が1年で働く時間は
たった２２％ってご存じですか」

代表ブログでアクセスの多い記事をピックアップしております。

幸せに働くとは何か？ その答えがここにある。
奥野　勝也 (著), シナジーデザイン株式会社 (著) 形式: Kindle版

Amazonで99円で販売中

Kindle Unlimited会員なら0円

書籍の詳細はこちら