借りはコードで返せ、とかを学んだ1年でありましたよ。

先月で転職してから1年がたった。
振り返りの意味を込めて、職場を変えて1年間で実感したこと書く。

僕は元COBOLer(もっと正確に言うとNATURALという言語で開発をしていた)から特定の業者さんが使用するWebサービスをASP提供する会社に移った。
COBOLerがWebサービスに移ったらという苦労話も需要が多いかもしれないけど、具体的にどのような技術や知識を必要としたか、というのは書かない。
強いて言えば、JavaでもPHPでもRailsでもGrailsでもよいから、Linux上でWebアプリを1つでも完成させた経験があると良いのじゃないかと思う。
というか、そういう経験がなかったので、死にかけた。僕は。

ともあれ、おかげさまで、今の職場は楽しいし、やり甲斐のある仕事を楽しんでいる。

◯業務知識重要
転職して一番苦労し、今も悩ましいのは自分の業務知識のなさだ。
業務知識を持たずに仕事はできない。
日々の仕事の優先順位を自分で立てられない。
優先順位を自分で立てられずに働くということは、人に指示されて働くということだ。
人に指示されて働くという状態は、自分をコントロールできないことを意味する。

自分がコントロールできないことのストレスは耐え難い。
なんとか自分のコントロールを取り戻す必要がある。

僕にとって自分がコントールできている状態を端的にいうと、自分で自分の仕事の質、量、期日が調整できるということだ。
もう少し具体的に言うと、取り組むべき最重要な課題と期日を自分で決め、期日通りに終了させられる、ということだ。

自分をコントロールするためには、サービスをどのように成長させてゆくのか、を想像できることが重要だ。
なぜなら、今日取り組むべき最重要の課題とは、自分たちのサービスをどのように成長させてゆくのか、という目的にとって最重要な課題だからだ。
そして、自分たちのサービスの成長させてゆくのか、を考えるためには道標が必要だ。
どういったものが道標になるのか、というと有名なった

アップルで働くまで、イノベーションというのは「今にない、新しいものを作ること」だと思ってた。でもそれは違って、イノベーションというのは「未来にある普通のものを作ること」なのです。この違いを理解できるまでかなり時間がかかった。

という言葉が全てであるように思う。

すなわち、今、僕たちのシステムを使って仕事をしている人たちにとって「未来にある普通のもの」こそが僕たちが作っているサービスの道標になるはずだ。
もしくは、その人たちの未来の普通にあるものを支えるサービスと言って良いかもしれない。

道標の探し方は、話題になっている『ビジネスモデリングジェネレーション』や『SubjectToChange』でも知ることができる。
その中で共通しているのは今の普通を知ることだ。
エスノグラフィとか人間観察とか、現状分析とか言われるものかもしれないが、今をくわしく知ることが、未来の普通を描くことのタネになるのだ。

そして、特定の業界に向けてシステムを作るエンジニアにとって今の普通を知ることとは、業務の商習慣や利益構造などについて詳しく知ること、すなわち業務知識を身につけることなのだ。

以前の僕は、受託開発で枯れた技術を使って開発をしていると業務知識に重きをおきすぎる文化が嫌いだった。
自分がコードのバグと格闘している立場にいると、コードが読めなくても書けなくても業務知識があればよい、という考え方には腹が立つことも多かった。
そして、業界の未来を描く、というと山師的でうさんくさい、業務知識というとおかたくてダサいと思っていた。

ただ業務知識をなくすと何も見えなくなる。
今を詳しく見れない人間には、未来の普通を描くことはできない。
エンジニアにとって一番、良い場所は、未来の普通を描ける場所で、サービスなりを構築することに自分の技術力を存分にふるえる場所なのかもしれない。
それが転職して得た気づきの一つだ。

◯経験の質と時間重要
RubyやAgileという言葉に吸い寄せられる人々だったら37signalsを知らない人はいないと思う。
知らない人はモグリじゃないが、損している。
『getting real』や『小さなチーム、大きな仕事』はシステムづくりを仕事にしているなら読んでみるとかっこいい言葉とともに多くのことが学べる。

その37signalsいわく

(前略)仕事依存症は不必要なだけでなく、バカげている。『小さなチーム、大きな仕事』(p.22)

という。
彼らはこの信念のもと働き、そして成功している。

生産性を仮に時間単位で稼げるお金の額(money/hour)とするならば、生産性を上げる方法は、稼げる額を維持するか伸ばしながら、労働時間を減らすことだ。
37signalsは、労働時間を短縮することは生産性を上げること、優れたソリューションを生み出すことに寄与すると考えている。

そんな経験をしていないのでわからないけど、直感的に37signalsの言葉は正しい。
ただ、僕が転職して直面した問題は、時間を減らしながら稼ぎをふやすということは非常に困難、ということだ。

業務知識がなくなったことも関連しているけど、右も左も分からない状態で期日までに目的を達成することがまず非常に難しい。

もちろん、周囲の人達は聞けば助けてくれる。
でもやり遂げるのは自分だ。そして、やり遂げるには自力が必要だ。

そして、自力をつけるためにも時間を投資する必要がある。
学習したい内容に最大限の時間を投資するのだ。
学習の対象が業務知識であり、自社サービスのプロダクトのことであるならば、仕事に時間を投資することは理にかなっている。
ワーカーホリックは馬鹿げているのはわかっているけど、右も左も分からない状況ならどっぷりと仕事につかるのは悪くないと思う。

もちろん、学習の方法は色いろある。
本を読む、写経をする、自分でアプリケーションをつくる、勉強会を開く(もしくは参加する)などだ。
ただこれらの学習方法は、実戦経験の補助に過ぎない。他社の経験の追体験でしかないからだ。
追体験は、仕事のような実践に活かしてこそだ。
結局、実践のための時間が必要になる。

ただ、陥りやすい罠は1つある。
やはり、37signalsがいうとおりだ。すなわち、

仕事依存症者は、ほどよい時間にしか働いていないという理由で、遅くまで居残らない人たちを能力に欠けているとみなす。これは罪悪感と士気の低下をはびこらせる。さらには実際には生産的ではないのに、義務感から遅くまで残るのような「座っていればいい」というメンタリティを生み出してしまう。『小さなチーム、大きな仕事』(p.22)

自分の仕事を果たして、時間通りに帰る。それが普通のことだ。
長時間働いていることは自分で選んでいることであって、人から強制されるものではない。
ましてや他人に強要するものでもない。

経験には時間だけでなく、質も関係する。
これも感覚でしかいないけれど、「仕事」という漠然にたいして長時間、投資を行うのは不毛だ。
不毛なことの1つの基準としてルーチンワークに落とし込めたらそれは時間を投資する価値がないもので、自動化の対象だ。
自動化できることを繰り返し自分の時間を投入するのは良い経験ではないし、時間の無駄だ。

また、質という点では人間の限界もあるだろう。
人間の集中可能な時間をこえて仕事に取り組むことは果たして良い経験になるか、ということだ。
たとえば1日8時間しか集中ができないとしたら、それ以上の時間を注ぎ込むことが良い経験になるだろうか。

僕の実感からだと、
・学んだことをメモに残せる
・1週間ないし2週間のイテレーションの計画を立てる時間がある
・週に1度ジムにいき、酒を飲みいける時間がある
これを満たせないとどんなに仕事に時間を投入してもムダになる。
作業のミスや抜けが多くなるし、経験したことを記録しておけないのでやったことを片っ端から忘れてゆく。
ようするに経験が蓄積されていない状態になる。経験をムダにしているのだ。

もちろん、これは僕の場合であって他の人に当てはまるかどうかはわからない。

働き過ぎは37signalsが言うように間違った価値観を生む。
あと、なんにせよ、他人の命令や指示で長時間労働することは馬鹿げている。
もしも、時間を仕事に投資するなら最低でも、その投資に自分が納得している必要がある。

◯借りはコードで返せ
そんなこんなで、一緒に働いている人たちには今もたくさんの迷惑をかけながら仕事をしている。
周りの人たちができるのに、自分がいまいち利益や仕事で貢献できていないのは肩身が狭い。
周囲の人たちに比べてできない自分が情けない。
そういう状況に陥ると、「他の人の邪魔をしちゃいけない」と考えて、優秀な人たちの時間が空くように雑用を巻き取る事を考えたりする。

ただ、それは逃げの思考だ。
よく言われる通り、組織の強さは最弱の部分に依存する。
もしも、組織の開発力を考えるのであれば、自分が底辺かつ成長しないのであれば組織の開発力は上がらないままだ。
組織を強くするためには、自分を鍛え、やることを増やし、質を上げるという正攻法の努力が必要になる。

自分ができなくて周囲の人たちに頼りっきりの状況は非常に情けないし、申し訳ない気持ちにさせられる。
でも、優秀な人たちと働くと自分の実力以上の仕事ができる。
そんな経験は何にも代えがたい。
自分から進んで会社をやめたくはないけれど、やめたほうが会社のためになるのではないか、という非常に悩ましい状況だ。

そんなさなか、いわれたのが

借りはコードで返してください

という言葉だ。

ようするに仕事の借りは仕事で返せ、ということだ。
仕事を進めていると、相手の邪魔をしたり迷惑をかけたり、はたまた時間を作って手伝ってもらったりすることがある。
そんなときには、ありがたいとか申し訳ないとか思う以上に、自分ができることをしっかりやり遂げることが一番の借りの返し方になる。

エンジニアの仕事は単にコードを書くだけではないけれども、仕事のうえので貸し借りや自分に求められる仕事へのコミットの仕方が端的に現れている言葉だと思う。
だから僕はこの言葉が好きだし、実践したいと考えている。

今までの借りはコードで返すのだ。

◯今後やりたいなぁと思うこと
ということで、1年分の借りを今年は返して行きたいと考えている。

広告

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中


%d人のブロガーが「いいね」をつけました。