技術力が並でもそれなりにWebエンジニアとしての単価を維持できる理由 – 常駐型エンジニアの価値

Pocket

始めに、だらだらと「まとまりなく」書きますので、お忙しい方は垂直離脱をおすすめします。
びゅーんって、感じで。

さて、最近、お客さんにいろいろと提案したいなと思うことがあり、どのように提案するかなと考え始めました。
提案を受け入れてもらい、成果があがれば、顧客との関係をより深くでき、継続的な契約や、時には単価上昇を促すと思います。
しかしながら、いくら良い提案だったとしても、お客さんが受け入れてくれなければ、意味がありませんし、費やした時間が無駄になります。
こちらの意図が伝わらず、「なんだかめんどくさい事を言うやつだ」と受け止められてはマイナス評価にもなりかねません。

ですので、あれこれと脳内でシュミレーションを始めるのですが、これはきっと、不動産売買の仲介営業をしていた頃の名残ではないかと思います。
お客さんにぴったりの物件が見つかった際に、どうしたら取りこぼしなく成約まで持って行けるかということをよく考えたものです。

エンジニアに成り立てだと、こうした戦略を持って提案するという事を意識せずに、もったいない時間を過ごすこともあるかもしれないという想いで、少し書いてみたいと思います。
あくまで個人の見解です。
請負ではなく、常駐という、客先の環境で仕事をされるプログラマやエンジニアの方の参考になればいいかなと思います。

また、どちらかというと、大企業での就業よりも、中小企業への就業する方向けかと思います。

自身のマーケットバリューと思う4つのポイント

僕はプログラマとしては10年を超えるキャリアとなったのですが、技術力としては並というか、下手すれば平均以下かもしれないと思う事がたまにあります。
最初にプログラミングを覚えた言語はPerlでして、それからPHPにシフトし、必要があってRubyも少し嗜みました。
上級言語しか書けませんというプログラマにありがちかと思うのですが、C言語が書けないことへのコンプレックスがあったりなかったりします。

OOPという概念を知ったのはMojavi3が登場した頃でした。
クラスやメソッドの設計について妥当であるのかだとか、OOP/MVCの概念への理解が正しく、また使いこなせているか?と問われると、胸をはって答えられません。。
たとえば、デザインパターンなど、その是非があったり(参考:再考: GoF デザインパターンfrom Qiita)しますが、うろ覚えですし、フレームワークを利用しだすと新規の案件でもない限りクラスの設計もあまりしませんし、実装に関する技術力とかに自信があるなどとは到底言えません。

それでもありがたいことに業務委託契約をさせていただき、売り上げを立てさせていただいています。
いったい何がお客さんに対する価値となっているのか、少し整理してみました。

  1. 就業開始直後はとにかく空気を読む
  2. 信頼関係を構築するまでは提案をしない
  3. 作業者でなく、仕事人であるということ
  4. お客さんの課題分析を代行する

ちなみに、3、4に関しては出来ているというよりも、目指して行こうとしているというところです。

以下では、それぞれ解説してみます。

就業開始直後はとにかく空気を読む – 受け入れコストを最低限に

大手の企業になれば、新人の受け入れ態勢はきちんと整っていることが多いと思います。

例えば、就業から2日はPCのセットアップとオリエンテーションだけが予定に組まれていて、マニュアルに記載された通りの手順(スクリーンショット付きのカラー数ページの冊子が作られていたりする)でPCのセットアップや、各種アカウントの申請を行いつつ、事務所やビルの利用規約を読んだりするかと思います。
常駐者向けのメアドの発行であったり、githubのアカウントであったり、グループウェアのアカウントであったり、サーバの鍵であったり、諸々、諸々です。

業務系システムであれば、もしかるすると分厚い辞書のような仕様書を手渡される場合があるかもしれません。

Web系でも大手企業で資料が整っている現場であれば、一通りのセットアップが終わると、どこそこのファイルサーバを覗いておいてなど指示されるかもしれません。
システムの概要であるとか、ネットワーク図やシステム構成図、ERD。
これにシーケンス図やクラス図があったりなんかしたら、ちょっとヤバい(レベルが高い)現場と言えると思います。

ところが、これが中小企業で、それも自社サービスを内製している現場になれば、受け入れの業務フローも資料も揃っていないことが多いかと思います。

ERDなんかない。あっても、2年前のものである。クラス図だのシーケンス図だなんて誰も書いた事も無い。機能仕様も概要レベルでさえ用意されていない。資料はあちこちに点在している・・・その他、その他、「あるある」はいくつも想像できます。

このような環境でマネージメント側に立った経験がある方にはわかると思いますが、厚く受け入れの体制をつくる余裕はないかと思います。
受け入れが恒常的な業務でないこともあります。受け入れの業務フローなどなく、そのプロセスが標準化されるわけありません。
また中小企業の開発現場であれば、大抵の場合PM/PLといった立ち位置の人材はプレイングマネージャーであり、主戦力であり、マネジメントだけでなく、要件定義から実装、テストに至るまでの業務に追われていることもあるでしょう。

このような環境で喜ばれる人材とは、なんといっても空気を読んで、少ない情報を頼りに自己解決してくれる能力の高い人物です。
システムや社内の情報を自身で紐解きながら即時に戦力となってくれるエンジニアが有用です。
資料がないと何もできませんなどというエンジニアは現場の指揮者からすれば単なるコスト増、負担でしかありません。

大企業に限らず、メンバーの役割が細分化・分業化・非属人化・業務標準化をされている、または目指している現場でもないかぎり、空気を読みながら、顧客の時間を奪わずに最短で現場に馴染んで行くということは大変重要なことだと思います。

人を受け入れた当初は、その人が実際にどのぐらいの仕事をしてくれそうかということを意識していますので、主体的に課題を解決して、質問を要領よくまとめて聞きにきてくれれば、「頼りに出来そうだなぁ」という印象を持ってもらえるでしょう。

受け入れの体勢が整っていないからといって、「前の現場ではこうだった」みたいなことは間違っても言うべきではありません。
前は前、今は今として、受け入れ時の課題をメモで残しておいて、後日信頼関係が構築された際に、参考として提示するぐらいにとどめたほうがよかれと思います。

特に、受け入れ環境がしっかりしている企業で常駐して来たような方は、そんな現場ばかりではないのだと考えたほうが良いかと思います。

信頼関係を構築するまでは提案はしない – 技術3ヶ月・人柄6ヶ月の辛抱

勉強家であったり、常にアンテナを張っているエンジニアや、いくつもの現場を経験して来たエンジニアであればあるほど、ジョインした現場の課題や粗というものが目につくかと思います。
「あー。。ここをこう改善できたらいいのになぁ・・」であったり、「前の現場で使っていたあのツールが使いたいな」であったり、「うへぇ、まだこんなイニシエの開発手法か・・」などなどと。

時には外部の人間ということで、そうした改善アイディアを求められるかもしれません。
しかし、仮にジョイン直後にそうしたアドバイスを求められても、僕はぐっとこらえて何も指摘しないようにしています。

例えば、好きな人に「好き」と言われれば嬉しいですが、嫌いな人に「好き」と言われると、面倒だなと思うかもしれません。
例えば、尊敬する上司にもらうアドバイスと、嫌いな上司からもらうアドバイスでは、受け取り方に雲泥の差がつきます。

以前のエントリー「異物という意識と、クライアントのための労働なのか、社会の為の労働なのかについて 」でも触れていますが、常駐型のエンジニアというのは、外部の人間だという意識を忘れないことが大事だと考えています。
信頼関係が構築されていれば、聞く耳を持ってもらえると思いますが、そうした基盤が出来ていない状況で、厳しい指摘をしたり、その現場の事情というものを把握しないで提案してしまうと、「外部の人間なのにうるさいことを言うやつだ」「そういうことが聞きたいわけじゃない」と思われる可能性もあります。

時に、ジョインした直後に自身の経験や考えをひけらかしてしまうエンジニアの方を見る事がありますが、勿体ないなぁと思います。
どれだけ技術力があり、論理的な指摘であっても、信頼関係の無い中では、不愉快に捉えられたり、正当な提案でさえ素直に受け入れてもらえなくなることもあります。
どれだけ良いボールを投げようと、相手が捕球体勢になっていなければ、単なる無駄骨でしかありません。
どれほど素晴しいキラーパスでも、ゴール前に駆け込んでくれるフォワードが居なければ単なる自己満足でしかありません。

そこで、まずは自身の発言を好意的に受け止めてもらうための素地作りが必要になると思います。
そして、それには2つの信頼の方向があると考えています。

一つは技術的な信頼度です。
当たり前の話ですが、技術力の無い人間、技術的に知見の無い人間にあれこれ指摘されるのは面白くはありません。
履歴書に書かれている内容や、面談の場だけで経験を聞いたところで、実際に一緒になって手を動かしたり、お互いにレビューをしたり、設計や実装に関する意見交換を何度も繰り返していかないと、技術レベルを図るのは難しいと思います。

それは、単に技術力というのではなく、どういった哲学を持っているかということが重要だからと考えています。
「なんでもかんでも最新技術が触りたい」という技術者と「ソフトウェアは信頼性が大事。マイヤーズを読むのは必須」という開発者では、その人物から発せられる提案に対して、受けとり手の印象が異なるのは当然かと思います。
できることなら、現場の決裁権者や現場の上長と思考的に同じ方向を向いていたり、またそうした方々の方向性を充分に把握・理解していることが望まれます。
また、ことあるごとに賛意を示し、「自分はあなたの理解者」だというスタンスを示すことで次第に信頼関係が厚くなるかと思います。

二つ目は人柄の信頼度です。
例えば、遅刻しがちであるとか、就業態度がよくないだとか、チームのメンバーとのコミュニケーションが満足でないとか、そうした事実があれば、その人物からの提案を素直に受け取る方は居ないかと思います。
また、大抵の場合、就業直後はだれしも勤怠に気をつけるでしょうが、人によっては数ヶ月すると乱れて来る場合もあります。
仕事に対して「プロフェッショナル」であるということに信頼を置いてもらうには、それ相応の月日が必要かとおもいます。

また、上述の哲学にも似た部分がありますが、外部エンジニアの発言が自社の利益に向かっているかは顧客にとっては重要です。
PM/PL/PMOといった上位レイヤーの職域で採用されていれば、ビジネス視点は当然期待される要素と思われますが、エンジニアとして採用されている場合、その点についてはそもそも期待されていないかもしれません。

ビジネス上の観点を期待していない人物から提案があった場合、それが妥当なものかを疑うところから受け取りがスタートするかもしれません。
ですが、エンジニアとして採用したものの、月日を追うごとに、単に技術だけでなく、ビジネス視点を持って話してくれているということがわかってくれば、外部の人間の提案でも、疑うよりも検討から始まるでしょう。

一言で表すとすれば、
「○○さんの言う事ならまず間違いない。その提案について検討しよう」
という状況を創り出すことが重要かと思います。

まずは自身技術力と人柄について信頼を得る事に努め、次第に小さな提案から始め、信頼関係を厚くする事で「いつまでも居て欲しい人材」というカテゴリーに分類されて行くようになると思います。

作業者ではなく、仕事人であるということ – 理想像は優勝請負人

前述と被るところが多く、またビジネスパーソンとして当たり前のことだと思いますが、作業ではなく、仕事をすることをいつも意識することが重要と考えています。

20代初めは、小売業に居まして、店舗で就業していました。
当時の店長に「作業はアルバイトで出来ること。仕事とは、作業が適切であるかを常に考え、その枠組みを考えること」と教わりました。
標準化されていたり、ある程度手順化されていたりするような活動は作業です。プログラミングもそのほとんどが作業と言えるかと思います。
しかし、いつまでもただ作業をしているだけではエンジニアとしての価値は高まらないでしょう。

単純に、いつまでも同じやり方でプログラミングをするのでなく、その手法や業務に使用するツールを常に見直して生産性を上げて行くことは自身の価値を高めます。
例えば、ツールやフレームワーク、業務フローなどを改善していくことで、それまで一人の作業で2ヶ月かかるものを1.5ヶ月で終えたというだけでも、人件費は数十万円浮くことになります。
実際には単価の見直しが起きることはないでしょうが、それだけ単価の高い人材になるという事であり、仕事をしたと言えるかと思います。

また、仮に3人で構成されたチームに属していたとして、生産性を向上する自身の取り組みが就業現場で認められ、自分以外の2人に波及すれば、改善される生産コストは3倍に高まります。
これは顧客にとっては大変ありがたい話です。浮いた時間やコストを更なる機能開発に割り当てることができます。

この、「自身が生産性を上げる手法を身につけているという価値」がチームに波及するという事象は、受託エンジニアやリモートエンジニアではなかなか実現できないことではないかと思います。
新しいツールや手法の効果を打ち合わせの中で耳にしたという経験よりも、社内でその効果を目の当たりする経験のほうが、説得力や影響力が強いだろうことは想像に難くありません。

常駐型のエンジニアとは、社外の人間ではありますが、チームの内部に居ます。
チームに属し、チームの一部です。
チームを改善して全体の生産性を上げて行くことが可能なポジションにいるとも言えます。

黙々と依頼された作業をこなすのは当たり前であり、そこから一つ前に進んで、自身の生産性を上げていくという仕事、更に一歩踏み込んでチーム全体の生産性を上げて行く事までを視野に入れて就業を続ける事で、顧客へ期待以上の価値を提供する事に繋がるかと思います。

技術のスペシャリストを目指すのもエンジニアとしての一つの形かと思いますが、こうしたチームカイゼンを意識することは大きな価値の一つだと思っています。

これはチームスポーツで考えるとわかりやすいかもしれません。
例えば、あるサッカーチームに非常に優れた選手が一人居たとしても、そのことがチームの勝利に結びついていなければ、全く意味がありません。
システム開発現場も多くの場合、チーム活動であって、必要なのはチームとしての成果、更にはビジネスの成功に繋がらなければ無意味となってしまいます。
こうした意識を持っている人材と持っていない人材の有用度、つまりは価値に差が出るのは当然の事だろうと思います。

顧客の課題分析を代行する – 常駐型だからできるコンサルという価値

今まで記述して来た事のまとめに近いのですが、常駐型社外エンジニアだからこそ持てる最大の強みであり価値とは「現場の中で改善を行うコンサルテーション」ではないかと、本稿を書きながら思い始めました。

例えば、僕の場合ですと、以下のような環境での就業経験があります。

  • 10名未満の企業
  • 近年の上場を具体的に目指している企業
  • 上場している社員数4万人以上(連結)の大企業
  • グループ企業のシステム部門

システムの種別もWebに限らず、業務系や社内システムを経験しています。
Webもポータルから、EC、B to C、B to Bであったり、職域もディレクター、プログラマー、インフラエンジニアをそれぞれ経験しています。
こうした大小様々、業界も、職域も様々な場所で就業できる事がなんといっても常駐型エンジニアの面白さだと思っています。

社外の人間ですから、その企業の全てを見る事ができるわけではありませんが、長く常駐すれば企業文化や人間関係も把握するようになります。

単なるメンバーでなく、PLなどに就けば所属以外の部署とコミュニケーションするようになり、やがて様々なレベルでの組織的な課題が見えたり、人の課題が聞こえたりするようになります。

また、中小企業に特徴的な課題、大企業に特徴的な課題、成長企業における特徴的な課題といった、それぞれのステージにおける課題もあるでしょう。
それぞれの組織規模や構成に置ける善し悪し、課題というものを自分なりに分析するようになります。

課題を解決するためのアプローチも様々ですが、それも企業文化や体制によっていろいろとやり方が変わるものかと思います。

僕自身はコンサルタントとして実務をしてきたことはありませんが、業務システムの設計をすることが度々ありましたので、業務の課題分析をしてきた経験があります。
ですので、新しい現場に入ってしばらくすると、単に開発の効率化における課題だけでなく、組織的な課題や、業務課題に目が向きやすいのかもしれません。

そして中小企業の場合、多くの課題のキードライバーが採用であったり、社内の人材育成であったりと、「人材の人財化」という課題行き着くようにも思います。

一人一人が意識改革を行い、個々の生産性を高めて自ら能力開発をするだけでなく、ビジネス全体を見通しながら常に業務改善をしていく人財になってくれれば、管理者としてはありがたい限りかと思います。
けれどもそうした積極的な人材ばかりであれば良いのですが、なかなかそうともいかないのが中小企業の現実ではないでしょうか。

この点については改めて分析したり、学んだりして自身の経験を体系化していずれアウトプットしたいと思います。

マネージメントする側からすると、メンバーの中に課題分析をする人間が居てくれるのはありがたいものかと思います。

というのも、メンバーが思っている率直な意見や、課題というものが管理者側に伝わって来ないが故に、管理者が課題を認識できずに改善に向かわない状況も起こりがちでしょう。
また、課題が見つかったにしても、中々マネージメント側から・・つまり上から意識改革を仕掛けたりするのは非常に難しいと感じます。

一方でメンバーの一員とし参画していた場合、コミュニケーションを取る頻度が高かったり、一緒にランチをしたり、フラットな関係で本音を聞ける機会もあるかもしれません。

そこで、メンバーと同じ立ち位置のエンジニアが生の声をヒアリングして課題を収集し、それをマネージメント側に提示し、連携して改善していく実行部隊となるのは大きな価値を提供できるかもしれないと考えています。
特にフリーランスのエンジニアともなれば、なんらかの目的意識を持って就業されている方も多いかと思います。

生活の為になんとなく働いているエンジニアで、あまり向上心が見られないだとか、意識が無いわけではないけれど積極性や主体性に欠けるメンバーに手を焼いている現場があるとします。
そうした現場のエンジニアに対して、自身が何故目標を捉えて動き出したかであったり、自身が「意識が変わった理由」を紐解いて、エンジニアの意識改革に繋げるといったアクションを試すのも面白いかと思います。

提案のタイミングは注意する

いつもの通りだらだらと書きましたが、まとめ的なことを書いてみたいと思います。

長々と書きましたが、一言でいえば
「するっと滑らかにジョインして、瞬く間に順応し、開発だけでなく、ビジネス視点で有用な提案ができるエンジニア」
というエンジニアになることが、常駐型エンジニアとして価値を高めていくことになるのではないかというお話でした。

実際的なところでいうと、僕自身はビジネス上の大きなインパクトを与えられるだけの提案までは出来ていないと思っていまして、今後はその辺りを意識して活動してみようかと思います。

特にメンバーの意識改革にスコープしてソリューションをつくることには興味があります。 

また、提案について一つ注意しなければいけないのがタイミングだと思います。

こちらが見つけた課題をマネージャークラスが意識している場合、意識していない場合では対応方法が異なります。
こうした具体的な手法に付いては、また別の機会に整理して、だらだら長々と書いてみたいと思います。

以上、最後までおつきあいいただきありがとうございました。

何かしらインスピレーションに繋がれば書いたかいがありますが、いかがでしたでしょうか。

Pocket