シェア
はてブ
ソフトウェアエンジニアには、多種多様なキャリア戦略があります。組織に長く所属し、信頼を積み重ねて中核を担う人もいれば、「あの技術なら、あの人」と評されるほど特定分野に特化する道もあるでしょう。そんな中、「流しのエンジニア」として活動し、企業からの依頼を受けては数々の現場の課題を解決してきた仕事人がいます。
彼の名はuzullaさん。PHPカンファレンスやPHPerKaigi、YAPCなどで数多く登壇しており、エンジニアコミュニティ内で広く知られる存在です。uzullaさんは学生時代からエンジニアとして働き始め、以来30年以上、仕事が途切れたことがありません。では、どんなスキルを磨けば「指名されるエンジニア」になれるのでしょうか。その秘訣を聞きました。
技術力や知名度以上に大切なのは、信用されること
――uzullaさんが「クライアント企業から問い合わせを受けて、案件を受託する」という働き方になった経緯を教えてください。
この働き方を始めたのは、学生時代にさかのぼります。30年ほど前、まだWindows 95が出たばかりの頃です。インターネットも一般家庭にはほとんど普及していませんでした。私はもともとコンピューターが好きだったので、中学時代からプログラミングやインフラ関連のアルバイトをしていました。その働き方を、高専に進学してからも続けていたんです。
そして、あるとき知り合いのプログラマーが一部上場の大企業から仕事を受託して、「石田（uzullaさんの本名）、一緒にやろう」と声をかけてくれました。そこから一緒に会社を立ち上げたんです。ただ、15年ほど前にその会社の仕事が少し減ったタイミングがあり、固定費を下げるために私が外に出てフリーランスになりました。
するとありがたいことに、知り合いの方々から「仕事をお願いできる？」と声をかけてもらえるようになりました。これは必ずしもIT業界の知り合いに限らず、昔どこかの飲食店で会った人や、インターネット掲示板で交流していた人など、属性はバラバラです。
そうして仕事を受けるうちに、さらに知り合いを紹介してもらう流れが生まれて、「声をかけられて仕事をする」というスタイルがずっと続いています。これまで、いわゆるエンジニア向けのエージェントに登録したことはないですね。
――指名で仕事が来るようになるために、何が有効だったと思われますか？
こういう話をすると「知名度が大事なのかも」とか「技術力を磨いて指名されるようになろう」と思われる方もいるかもしれません。でも実際には、そこが一番大事なポイントではないんです。業務委託の発注権限を持つ方から「あの人に依頼しよう」と思ってもらうには、OSSを作って公開するとか、技術カンファレンスで良い発表をするとかだけでは足りないんですよ。もちろん、加点要素にはなりますけれど。
正直、「ある程度有名らしいけれど、直接のつながりはない人」を、担当者が自分の判断だけで契約することはほとんどありません。重要なのは、第三者からの推薦や評価です。つまり「知り合いの誰々さんが良いと言っているから、きっと信頼できるエンジニアなんだろう」と思ってもらうことが欠かせません。
――信頼できる口コミが、指名での案件獲得につながるということですね。その信頼を得るために、エンジニアは何から始めるべきでしょう？
おすすめしたい最初の一歩は、コミュニティの中に知り合いを作ることです。たとえば技術カンファレンスに参加したら、そこで人と話して友だちになる。セッションの登壇や視聴だけしてそのまま帰ってしまうと、コミュニティに加わったとは言えないんですよね。人とのつながりができていないからです。
カンファレンスを例に挙げましたが、知り合いを増やす方法はもっとたくさんあります。たとえばブログやYouTubeなどで情報発信をして、興味を持ってくれた人とSNSでつながるのも良いですね。ただ、このとき大事なのは、信頼できる立ち振る舞いをすることです。いくら知り合いでも、「ちょっと信用できないな」という人に仕事を頼もうとは思わないじゃないですか。
リファクタリングでは「完了の定義は何か」を明確にする
――uzullaさんのもとに、さまざまな依頼が来ると思いますが、仕事を請ける・請けないの判断基準はありますか？
特に、明確なルールはないんですよ。私はよく「PHPの人」と思われるんですけれど、実際にはPHP以外の仕事もいろいろやっています。強いて言えば、フルタイムで客先に常駐する案件はやらないとか、支給のパソコンではなく自分のパソコンを使わせてほしいといった条件はありますが、それ以外は特に制約を設けていません。
――プロジェクトの性質ごとに、大事にしているポイントはありますか。たとえばレガシーコード改善の場合はいかがでしょう？
レガシーコード改善では、「何をどのような状態にすれば改善できたと言えるのか」を最初に決めることが大事だと思っています。すごく単純な例なら「特定のプログラミング言語やライブラリをバージョンアップする」とか、「静的解析ツールで検出されるエラーがどれくらい減ったかを計測する」といったものですね。
もちろん、そんなにシンプルに定義できないことのほうが多いですが、要は「誰が見ても納得できる基準を設けること」が重要です。基準がないと、修正の結果が「そのエンジニアのこだわりコード」を作るだけになりがちなんですよ。自分の理想を形にするためにやっているわけではありませんから。
それから、レガシーコード改善では他のエンジニアに「こうやればできるんだよ」という姿を見せることも大事です。基本的にレガシーコード改善は現場のエンジニアにとって気が重い仕事なので、私がファーストペンギン的に飛び込んで前に進めるのが主な役割になります。自信を持って働く姿や具体的なアウトプットを見せつつ、プロジェクトメンバーを巻き込んでいくことが大事です。
逆に、うまくいかないパターンもはっきりしていて、それはクライアント企業がコミュニケーションの窓口を絞っていて、私が特定の方を経由しないとメンバーと会話できないケースですね。これはコミュニケーションが閉じた状態になってしまうので、なかなか成功しません。
――新規開発系のプロジェクトはいかがでしょう？
新規開発の場合は、当たり前ですがスケジュールに間に合わせること。そして、もし遅れているならば、遅延の理由が何にあるのかを見極める必要があります。
「機能が多すぎること」が原因なら、削ってもらわなければなりません。削るのにもスキルが必要なんですが、それは今回のインタビューの趣旨から外れるのでいったん置いておきます。
機能を削るための実践的なアドバイスとしては、プロジェクトのキーマンと直接話すことですね。そういう方とやり取りできるかどうかで、仕様を変えられるかどうかは大きく変わります。ただその際にも「uzullaさんがそう言うなら」と納得してもらう必要があるので、日々の仕事で信頼関係を構築しておくことが重要です。
「技術的に難易度が高いこと」が原因の場合は、私が難しいところだけ担当するとか、知人のエンジニアを紹介するなど、やり方はいろいろあります。ケースバイケースですが、「今回はこの方法で行こう」と提案できるのは、長くやってきた人間ならではの強みだと思います。
新しい技術も古いコードも。すべてを受け入れる姿勢が武器になる
――先ほどのレガシーコード改善の話に戻りますが、古いコードを触るのを嫌がる人も多いですよね。uzullaさんが抵抗を持たないのはなぜですか？
理由は2つあります。ひとつは、私は仕事を好きに選べるような“スター”ではないこと（笑）。もうひとつは、レガシーコードには価値があるからです。そのコードが会社に売上をもたらしているからこそ、現在まで残っているわけですよ。そして、価値のあるコードを任されるということは、クライアントから信頼されている証拠でもあります。そういう仕事ができるのは、大きなモチベーションになりますね。
――コードを読み解いていく際、「ここから見る」というルールはありますか？
あります。私の場合、Webアプリやバッチ処理なら、まず処理が開始する入り口部分を探します。そこから処理が完了するところまで、デバッガで一通り追っていく。最初は単純な箇所から入り、慣れてきたら複雑なところに移ります。
読んでいると、そのプロジェクト特有の“癖”が見えてくるんです。「このオレオレフレームワークはこういう発想で作られているな」とか「もともと別の言語を使っていた人が書いたPHPだな」とか。その癖さえつかめれば、他の部分もスムーズに読めるようになります。
でも、その前に心が折れる人が多いんですよね。きっと、技術的負債が溜まっているプロジェクトの8割くらいは、コードの癖を読み解くのが大変だから放置されているんじゃないかと思います。私は30年以上いろんなコードに携わってきたので、「この時代はこういう書き方あったよね」と考えながら読めるんです。
――他の人にコードを引き継ぐ際に、意識していることはありますか？
自分が書くコードでは、オーバーエンジニアリングを避けています。ハイスキルな人でないと理解できないような複雑なことはしないし、DRY原則にもこだわりすぎない。多少冗長でも、読みやすいコードを心がけています。一緒に働く人には「入社初日の新人でもすぐに理解して修正できるくらい、シンプルにしよう」とお願いしています。
――長くエンジニアとして働き続ける中で、変わらない軸はありますか？
変わらないことはないですね。むしろ、変化を受け入れることが大事だと思っています。私が仕事を始めた1995年当時は、Perl製のCGI一枚でWebサイトを動かす時代でした。そこから、ものすごいスピードで技術は進化しました。変化を受け入れられなければ、とっくに私の仕事はなくなっていたはずです。
「これしかやらない」というスタンスだと仕事の幅が狭くなるので、私の場合はとにかく選り好みせず、何でもやっています。新規開発もレガシー改善もやりますし、最近はAIを用いたコーディングのコンサルティングもしています。顧客の規模も、大企業からスタートアップまでさまざまです。
それから、キャリアが長いからといって他の方に「自分のほうが上だ」という態度を取らないこと。むしろ、私が詳しくない技術については、相手に「教えてくれない？」と素直に聞くようにしています。そうすると、より良い関係性を築けるんですよ。
――なんだか、uzullaさんが業界で長く活躍されてきた理由がわかった気がします。最後に、「指名で仕事が来るエンジニア」になりたい読者へアドバイスをお願いします。
一番大事なのは、礼儀正しくあることです。もし私が誰かに仕事をお願いするとき、その人が礼儀を欠いていたら、どれだけ技術力があっても依頼したくなくなります。エンジニアはみんな学び続けているので、「この勉強をしなさい」と言うつもりはありません。それよりも、人として信用できること。これが何より大事だと思います。
取材・執筆：中薗昴
撮影：山辺恵美子
