職業プログラマの休日出勤

職業プログラマによる日曜自宅プログラミングや思考実験の成果たち。リアル休日出勤が発生すると更新が滞りがちになる。記事の内容は個人の意見であり、所属している(いた)組織の意見ではない。

葛藤:自分にしかできないこと

何か新しいものを作るとき、自分にしかできないことを実行して上手く進んで行くという状況は最高に楽しく、有意義に感じる。自分にしかできないことが存在するとき、需要と供給のバランスが崩れ、売り手市場を闊歩する状態になる。
「自分にしかできないこと」の存在は正義である。

既存のものを守り育てて行くとき、自分にしかできないことが存在すると、自分が死んだらコイツも死ぬということが容易に想像できるようになり、その状況は大きなストレスになる。対象物が重要なものであればあるほど、ストレスは積み重なる。
「自分にしかできないこと」の存在は悪である。

自分自身が情報処理界隈に身を置いているからソフトウェアの開発や情報システムの保守運用を思い浮かべながら書いたが、きっと他の業界でも同じようなことは観測できるだろう。


自分が小学校高学年から高校卒業までの間、独りでプログラミングをやっていたときは、確実に前者、新しいものを作る時の感覚しか持っていなかった。1学年で300人とか400人とかいる学校だったけども、学校中見渡しても同じ能力を持った人間なんて誰も居なかった。当時としては珍しく、自作PCっぽいことをやっている友人は居たが、プログラマというよりはコンピュータの熱心なユーザという立ち位置だった。もちろん仲は良かった。

2005年、就職してから最初の仕事は、通信機器の遠隔管理をするためのWebアプリケーションを作ることだった。設計、開発、テストの実施と、これらの実行のための4人程度のチームのマネジメントが、自分に課されたタスクだった。自分にしかできないことは多くあった。
9ヶ月ほどの間の努力の末、様々な困難を乗り越え、テストも無事に終了しそうになった頃、発注元企業の運用チームへの引き渡し、言い換えれば受け入れ試験の支援をするチームへ異動になった。そこで自分が見たものは、「システムが死ねば会社が死に、俺らも死ぬ」という気概を持った4人のサーバ管理者たちだった。
仕事に対するその姿勢は「命を懸けている」と言っても過言ではなかったが、命を懸けているからこそなのだろう、決められた業務時間が終わればさっさと帰って行き、しっかりと休息を取っていた。チーム内での情報共有も極めて活発で、ある一人にしかできないことが発生しないように最大限の活動が日々実行されていた。
その様子を見た当時の自分はただ「すごいなー」「教科書通りの、いい感じの冗長性だなー」などと思っているだけだったが。
派遣元企業の意向により、自分はそのシステムが本番稼働開始する前にその場を立ち去ることになった。


それからおおよそ2年が経過した頃から、サーバ管理の仕事を少し手伝うようになった。
最初はまだ開発者としての気持ちが圧倒的に強かったが、仕事の中の保守運用の割合が増し、対象としているシステムの重要度がどんどんと上がって行く中で、「開発にしろ保守にしろ、自分にしかできないことをこれだけ沢山抱えてるのは本当にヤバい」という気持ちが芽生えた。当然ながら開発者としての「これは俺にしか作れない、ドヤァ」という気持ちもあった。自分にしかできないことに対して2つの矛盾する気持ちが無視できない大きさで衝突する訳である。葛藤の発生だ。


歳を取ったら、この葛藤に対して何らかの決着をつけることができるのだろう、と安易に考えていたのは事実だ。
しかし、実際には、歳を重ねるごとに開発者としての役割も保守運用担当者としての役割も、どちらも重いものになっていき、葛藤は激しくなる一方である。

もしも葛藤を避けることを最重要と捉えて行動した場合、言い換えれば、自分の役割が100%開発者、または100%保守運用担当者だったとしたら、どうなるだろうか?
それはそれで、身に付くスキルの範囲が狭くなってしまい、この先生きのこることができるのかどうか、不安な状態に陥ってしまう。


じゃあ、どうすれば良いのか?


企業や製品の状況に合わせて、チームの構成や動きを変えるべきである、ということを5年ほど前から考えている。
本当に新しいものを作る時、特にプロトタイプを作る時は、一人の人間が誰とも協議せずに集中して作った方が良いものができる。もちろん、プロトタイプの評価は複数の人間を交えて実施した方が良いだろうが。
製品が形になって、世に出すか出さないかの頃(この時期は製品の性質や規模によって変わる)、誰か一人にしかできないことを極力減らして行くように取り組んで行く。
そしてある程度の時間が経ったときに、また新しいものを作れば良い。

言うのは簡単だが…