「どうなっているんだ！」と怒鳴られる経験がプログラミングスキルを成長させる

当社では、IT関連製品を開発し、リリースする前に、まず社内で自分たちが使う、ということを大抵行います。まあ、当然といえば当然です。自分たちが安心して業務に使えないようなものを販売することはできませんので。

昨日から若手メンバーが開発した製品を社内の一部の環境に設置しました。設置直後に問題が出ましたが、まあ、解決したということで夜には設置した状態で帰宅。

今朝、一部のメンバーから「使えない！」という声がちらほら。。まあ、間違いなくそのシステムだろうということになりましたが、当人はまだ出社していません。仕方ないので、一緒に進めている別のメンバーに外すように指示が飛び、とりあえず業務に影響がない状態にしました。

その後、開発した本人が出社し、解析して問題は比較的すぐに判明したようですが、私は「設置した翌日に朝一番に来ていないのはおかしいよね〜」と。まあ、とても頑張っているメンバーなので、責めるつもりではないのですが。。

ちょうど昨晩、私が帰宅する際に、そのメンバーが最後に残っていたので、「自分の製品をリリースするようになるのだから、コンスタントに仕事をこなせる状態が大切だよ。徹夜して仕上げても次の日に体調を崩し、サポートができないようでは駄目だからね。」と話したところでした。

本当のお客さんの環境にリリースする際には、基本的に一定期間張り付いて監視するのは当たり前です。正式リリース前の状態で社内にリリースするときには、問題が出るのは当然というようなものです。問題を出すために社内に設置しているわけですしね。もちろん、他のメンバーも製品が少しでも早く完全な状態になるように、テストにも積極的に協力するわけですが、「協力するのが当たり前」ではありません。他のメンバーもそれぞれ仕事を抱えているわけですから。何か起きたときにすぐに対処して、業務への影響を最小限にするのはもちろん、そうやってすぐに対応できるところを他のメンバーが見ることで、安心して世に出せるだろうと感じるわけです。

趣味のプログラミングと仕事のプログラミングの違いはここにあります。

技術的にハイレベルかどうかとかは、ユーザにとってはどうでも良いことで、目的通りきちんと使えるかどうかがポイントです。逆に凝りすぎたプログラミングをしてしまうと、メンテナンス性が悪くなってしまうこともよくあるもので、作った本人も何が何だかわからなくなることもあるのです。私も長年の間にそんな痛い目に何度もあった末、今では「とにかくシンプルで簡潔なプログラムが最高」という考えになりました。同時に、問題が起きたときにすぐに解析できるようなログの整備はもちろん、そもそも問題に気がついたらすぐに原因が想像できるような状態にしておくことを心がけています。

今どきのITシステムはあまりにも複雑ですので、最初から100%完璧なものなど、なかなかできません。問題が起きても何とかなるようにしておくことと、すぐに解決できることが大切です。そのような様子を周りに毎回見せることで、プロとして安心して仕事を任せられるようになるわけです。

それと同時にもっと大切なことは、自分で完璧と思える状態になるまでリリースしないのは駄目、ということです。自分の完璧と、ユーザから見た完璧は結構違うものですし、自分の想定を超えた問題が起きることなど当たり前です。どんどん協力的な環境で使って評価してもらわないと、一人前の製品にはならないのです。

まあ、そんな経験を積みながら、皆、一人前のプログラマーに育っていくわけです。「どうなっているんだ！」と怒鳴られた経験の分だけ、安全で安定したプログラムを作ることができるようになると考えて、前向きに取り組めばOKです！