真っすぐ生きる

iruka posted by (C)t2y

新卒準備カレンダー 2011春 : ATND という、これから IT 業界に入る新卒入社の方向けへブログエントリを綴ろうという企画に参加しました。私が10日目で、既に書かれたどのエントリも素晴らしい内容なのでぜひ読んでみるのをお奨めします。仕事観にはその人の生き様が表れます。その中から自分の考えにあうものを選択して参考にすれば良いと思います。だから、私もこれまで経験してきたことを書いてみようと思った次第です。

おまえ誰よ？

学生時代にソフトウェア開発のインターンシップをしたことがきっかけで、プログラミングおもしろいなーと思うようになり、新卒で SIer に就職しました。当時はプログラミングするなら、どこの会社でも同じだろうと安易に考えていました。そして、3年間 SIer で流通基幹系システムの開発・運用に携わりました *1 。私は運用部署に所属しつつ特例的に開発をやっていましたが、1日の半分は電話(サポート)、残りの半分は作業とトラブル対応だったので、お仕事での開発は業後か休日にしていました。

つい先日ですが、私が新卒入社した会社がもうすぐなくなるようです *2 。入社した2004年当時は独立系 SIer としては大手でしたが、それから10年も経たずに会社がなくなるのを目の当たりにするのは感慨深いです。いまどき大企業も経営を誤れば数年でなくなります。

転職を決意したときに http://blog.miraclelinux.com/yume/2007/01/post_6962.html を読んで応募して Linux Distributor に転職しました。学生の頃から未来のいつか/hyoshiokの日記を購読していて、とにかく OSS に関するお仕事がしたかったのです。しかし、Linux Distributor は OSS を活用する側で自分たちで開発する機会が少なかったのと、今後のキャリアはプログラマでやっていこうと決心したこともあり、2年間、パッケージャ(RPM のパッケージングをする人)として働いた後に現勤務先に転職しました。

いまは1日の8割はコーディングをしています。自社開発のパッケージを販売する会社なので、開発はスクラッチから、設計も含めたアプリケーション開発ができ、学生時代にプログラミングおもしろいなーと思ってから、お仕事で毎日プログラミングすることが、卒業してから5年を経て辿り着きました。

やりたいことなんかやってみないと分からない

いまの就職活動に関する記事を読んでいると、やりたいこととか自己分析がとても重視されるような雰囲気を受けます。学生の頃にやりたいことを見つけられる人の方が稀じゃないかなと私は思います。自分にとってのやりたいことが本当に分かるときは、やってみて辛くてもがんばれるとか、お仕事以外(例えば OSS 開発とか)でも続けられるとか、そういうもんかなと思います。私なんかお仕事をし始めて7年ほど経ちますが、やってみたらつまらなかったとか、ある程度やったら飽きたとか、やりたいこともその都度コロコロ変わります。それでも、普通にお仕事してやっていけるならそれでいいやと思って毎日を過ごしています。

真面目に自己分析して、会社情報を調査して、OB 訪問して、どこそこの会社がベストな選択だと入社したとしても、実際は会社なんかほとんど関係ありません。配属される部署もしくはチーム、運が悪いと上司という要因でその環境が自分にとって良いかどうかが影響します。入社する前からやりたいことが分からなくてもその方が普通だと私は思うし、興味もなかったお仕事でもやってみたら周りより上手くできて、評価されたら面白くなってきてそのままやり続けてるということもあるでしょう。

私はプログラミングやりたいなーと思って SIer に就職したけれど、1年半ぐらい主なお仕事は電話(サポート)だったわけです。ちょっと忙しいプロジェクトを担当したので、顧客、店舗、ベンダ、物流センタ、仕入先など、色んなところから電話が掛かってきてあれはあーだ、これはこーだと答えたり、運用サポートやトラブル対応をしつつ、その中で空き時間を見つけて開発をやっていました。

とはいえ、そんな運用サポートの経験も全く無駄ではないのです。例えば、いま開発するときは運用のことも考慮して設計するようになりました。運用の大変さが分かるというのは開発において武器になるときがあります。さらに運用は(顧客が解約しない限り)未来永劫に続くので終わりがないという苦しさがあります。それに比べると、開発プロジェクトは必ず納期があります。感覚のお話でしかないのですが、納期があるというのは私にとって希望の光に見えます。どんなに大変でも3ヶ月がんばれば終わる、これって開発しかやっていない人には分からない感覚だと思います。

そんな経験から過度にやりたいことにこだわり過ぎたり、会社がブラックだとやさぐれたり、そういうネガティブな感情を日常的にもつぐらいだったら、年配者のありがたいお話なんか無視して、自分がポジティブな感情をもって毎日が過ごせるような環境作りをしていった方が良いと私は思います。

運用で一番大事なこと

壊れてもすぐに元の状態に直せることです。

トラブルを起こさないことでは？と思う方もいるでしょう。ちょっとずるい言い方をすると、トラブルは起こさなくても勝手に起こります。「トラブル」を「交通事故」に置き換えるとイメージし易いでしょう。もちろん「交通事故」を起こさないために、交通ルールがあり、信号機がありというのは重要なことです。そこを否定しているわけではありません。

具体的な例だと、最近では Doblog の障害ならびにサービス終了が記憶に新しいです *3 。ハードウェア障害でデータを消失してしまい、復旧できずにそのままサービス終了という、会社としてどうなのよ？と話題になった事件がありました。現場にまともなエンジニアがいなかったんだろうなと残念な気持ちになります。

大量データを扱うシステムは、いかに小さな処理単位に分割できるか、個々の処理単位が制御可能かという運用を考慮したシステム設計が求められます。コストのかかる大きな話ではなく、個人レベルでもやれることはたくさんあります。

オリジナルのデータはどこからきて、処理の過程にあるバックアップは何日間保存されているか、トランザクションログはどういう形で保存されているか、システム全体の処理とデータの流れを把握しているか。大量のデータを扱うお仕事をされる方は、作業の途中で今すぐ処理を中止してと言われたときに30分以内に作業前の状態に戻せるかを意識してみると良いと思います。そうは言ってもということがたくさんあるでしょうけど、考えるきっかけにすれば良いんです。

失敗の仕方

自転車で車道と歩道の間を走行しているとき、どう転んでも車道側に倒れないこと。それが失敗の仕方。

どんどん失敗しろというわけではなくて、言い換えると、失敗するということは挑戦することです。

SIer にいた頃に私はデータベースのマスタ関連の基本設計を担当しました。そこで大きな設計ミスをしました。あるコード体系の詳細を確認しなかったために、従来通りに利用するために運用側でコード変換テーブルを設けることになり、その変換テーブルのメンテナンスを運用側で継続するという不要な運用コストを負わせてしまいました。コード体系の詳細について一言確認すれば防げていたし、設計書にコード体系の詳細を書いておけば誰かがレビュー時に気付いたかもしれないというレベルのミスでした。

これは車道側に倒れた失敗でした。

知らなかったというミスを防ぐには誰かの責任にしても解決しないし、それまでと同じやり方をしていても同じミスをするだけです。その後、物流システムの要件定義をする機会があったのですが、顧客や協力会社との打ち合わせのやり方を工夫したり、ドキュメントのフォーマットや内容を分かり易くしたり、何か漏れがあるかもしれないと細心の注意を払う意識が自分の中で違いました。私が初めて要件定義をしたその物流システムはトラブルなくサービスインしましたが、その前の設計ミスを反省した結果でもありました。

挑戦する限り失敗はつきものです。失敗したときに車道側なのか、歩道側なのか反省してみましょう。もし車道側だったら命の危険があるので身を守る手段を考える必要があります。その経験が積み重なっていくと安全に転べるようになります。

開発で意識していること

私が開発時に気を付けているのは処理のロジックを明解に説明できるかどうかです。入力と出力は何か、どういったアルゴリズムとデータ構造で実装しているかを自分で全て説明できるかということです。さらにビジネスロジックと言うと、アプリケーションの対象となる業務に特化した要件を加味することもあります。

自分でコーディングしているのだから当たり前に思うかもしれませんが、私自身、プログラミングの経験が浅いときは取りあえずコーディングして動かしてみるといったやり方を繰り返しましたし、他人のコードを読んでてもこれは本当にロジックを説明できるのかなぁと思うコードに出会うことがあります。

例えば、ロジックの説明にしにくいコードとはこんなカタチをしています。見た目ですぐに分かります。

def wrong_logic():
    while True:
        x, y, z = func(x, y, z)
        if not x:
            continue

        if y >= 3 and y <= 10:
            for i in z:
                 if i == CONSTANT:
                     return ERROR

        if len(z) < 3:
            return ERROR

        if y == 13:
            return ERROR

        if x == END:
            if y == END:
                ret = SUCCESS
            else:
                ret = WARNING
            break

    return ret

デバッグやメンテナンスで不具合があったからと、安易に if 文をぽこぽこ入れて取りあえず動きました的な修正を見ることがあります。こんなことを繰り返していると、次にこのコードを拡張するときに非常に難しくなります。

確かにまず動くものを作るというのはとても大事です。実際に実行して試しながら開発することも、良くはないけれど実際にはあるかもしれません。動いた後でも良いから、この処理のロジックは自分で説明できるかを考えてみると良いです。そうしているうちに、いきなりコードを書いても、後でたくさん書き直すことになるというのが経験で分かってきます。例えば、私は3ヶ月の開発期間があったら、1ヶ月〜1.5ヶ月は関連技術の調査と設計に時間を割いて、開発対象の実装は開発期間の半分ぐらいでやります。

創造性を発揮する

私の場合、必ず調査・設計期間を設けるようにしているので同じ開発対象であっても品質レベルは期間によって変わります。要求仕様、工数、納期、保守性、拡張性、自身の技術力を考慮して、その時にベストな設計を行い開発します。ただ技術力には個人差があるので、自分にとってのベストな設計が他人にとってはそうではないこともあります。しかし、そんなことを気にする必要はありません。分相応に高度なことをやろうとしてもロジックを説明できなくなるだけです。お仕事で一番おもしろいのは創造性を発揮することで、私にとっては設計を練るときがそういうお仕事です。

このアプリケーションはこういう方向に拡張していくはずだから、こういう設計原則でやってみようと開発したものの、未来は予測不能なので当たるかどうか分かりません。当たればノウハウが得られて自信がつきます。外れれば「そうか、そういう可能性があったのか」と新たな気付きが得られ、次の開発の糧になります。どっちに転んでも自分にとってはメリットがある、そういう考え方や判断基準でお仕事するようになってくると、ポジティブな日々を過ごせるようになります。

すごい人に聞いてみる

Linux Distributor に転職した頃、周りにはすごい人がたくさんいて、自分は本当にちっぽけな存在だなと萎縮していた頃がありました。あるとき「エンジニアは適正が重要なんでしょうか？」と質問した人がいました。

Linux カーネルハッカーの小川浩史さんの回答が心に残っています。

とことん突き詰めてやるか、やらないかだけだ。

このお話を聞いてからは、興味をもったことをやっていればそれで良いやと思うようになりました。周りと比較して焦ったり不安になったりすることもなくなりました。すごい人が社内にいなくても IT 業界は勉強会やコミュニティ活動を通して社外の人と交流しやすい稀な業界です。そこで、すごい人を見つけたらいろいろ聞いてみると良いです。きっと分かり易い答えが返ってくるはずです。

誰も責任なんか取らない、自分がやるかやらないかだけの主観

許可を求めるな謝罪せよ。(Don't ask for permission, beg for forgiveness) にも近い考えですが、伸びる人とそうではない人との1つの壁になるんじゃないかと思うようになってきました。

お仕事を始めると「責任」という言葉をよく聞くようになります。

責任は2つの意味で使われます。顧客から対価を頂いてお仕事している以上、その価値に見合ったサービスを提供しなくてはなりません。言わば、顧客に対する責任です。しかし、会社は利益を出さないと倒産してしまうので予算(納期)の範囲内で求められる品質レベルを提供しなければなりません。言わば、自社に対する責任です。しばしばサービスの品質レベルとコストとの兼ね合いで衝突や矛盾が起こることがあります。

色んな立場の人が、異なる意味合いで責任という言葉を使うけれど、そもそも責任って何なのさ？具体的に何をすれば良いのかを考えたとき、

逃げない
嘘をつかない
人のせいにしない

私にとっての責任というのは、こういった行動を取っているかどうかで判断しています。安全なところから見てるだけの人、手を動かさずに不満ばかり言う人、そういった人たちの行動を見ていると分かってきます。そして、自分自身がいつもこういう行動を取ってきたかと言うと、そうではないケースも実際にはあります。人間なので完璧にはできないし、弱気になるときもあるし、うまくいかないときもあります。

こういった行動を取るために最適な職業を考えたとき、自分で設計して、自分で開発して、自分で直せるプログラマという職業が私には一番あってそうだというわけです。