髪も切れるiOSエンジニアのブログ

元美容師エンジニアの成長と奮闘の記録

ど素人がSES事業に携わり一年過ごして培ったもの

Manhattan Code Inc. もお陰様で本日1周年を迎えることができました。
私は創設の直前にこの会社に入社したので、私にとっても転職を果たしてから1周年ということになります。
この一年間をSESの傭兵として過ごしてきた中で学び感じてきた、SESならではの心構えを綴りたいと思います。
もし同じ立場のSES新人の助けになれば何より。

  • 味方をできる限り増やす
  • 「できる」と「できない」は紙一重
  • SESエンジニアの付加価値

味方をできる限り増やす

弊社マンハッタンコードの方針としては入社から半年は先輩エンジニアと一緒に現場に出る。
半年後問題なしと判断されたら一人で行く現場を探す。
私の場合は若干の手違いもあり三ヶ月で一人で現場に出ることになった。
不安が7割の状態で、「当たって砕けろ」な覚悟を持つことが精一杯だったかもしれない。
実際に一人で現場に出て感じたことはまず「誰にどう質問したらいいのか?」「聞いたらちゃんと答えてくれるのか?」
他力な考えかもしれないが、正直150万ダウンロード越えをしている大手のiOSアプリを単独で開発しきる自信は当時はなかった。
そこでまず「質問しやすい人を増やそう」と考えた。
アサイン初日は環境構築をしながら現場のプロパーさん達がランチに離席するタイミングにアンテナを張った。
今!と感じた時に「ランチですか?ご一緒してもいいですか?」と声をかける。初日に頑張ったのはそれぐらいだ。
ウェルカムランチの風習がある現場に入った人は儲けもの。
自分から声をかけるのは初日だけ、後は毎日ランチに誘ってくれるようになる。
そんな環境が整ったら後はランチの時に自分の話と最近のITニュースの話をふっかける。
自分の場合は長年の美容師を経ての転職というネタもあったので、「今度切りましょうか?」なんて冗談を交えながら。
AppleWWDCまとめサイトとかからネタは常に拾ってきていた。
そんなことを続けていれば自然と「この人は勉強熱心」とか「経験が短いながらも努力家」なんていう印象で見てくれるようになっていた。
弊社には「まずできないエンジニアを目指せ」という教えがある。まさにこのことだ。できないエンジニアほど味方が多い。
普段実装に行き詰まったとしても、もう質問しやすい。「ホントこんな質問するの恥ずかしいんですけど〜」とか「ど忘れしちゃったんで教えて欲しいんですけど〜」とか枕詞で濁しながら。
いやらしい考え方かもしれないが、結果として自分一人で作りあげた納品物とチームに助けてもらいながら作りあげた納品物
納品日にマネージャーから言われる言葉はどちらも「ありがとう。お疲れ様でした。」
事実分からないことが多いなりにも期限が過ぎてしまったなんてことは一度もない。
SESで現場に出る以上、最低限の責任は果たしたい。故に「味方をできる限り増やす」ことは大きな力になる。
その中で私は知識を蓄積していき単独で開発する力をつけることができたと今でも思っている。

「できる」と「できない」は紙一重

よくプロジェクトマネージャーから聞かれることは「これってできますか?」だ。
この受け答えで私が意識していたことは「やったことがないので一旦調査してもいいですか?」だ。
当然当初の自分では「できません」が本音だ。
ただ、「できない」と簡単に答えられてしまったマネージャーの気持ちとしては「iOSエンジニアなんだからなんとかしろよ」になるのが自然だ。
マネージャーとしては実現可能性が閉ざされてしまい、自分としても成長の機会を奪う最も不利益な答えだ。
この「できる」と「できない」は紙一重の状態だとこの一年で実感した。
たまたまTwitterログインを実装したことがある人からすれば、Twitterログイン機能の実装が「できる」だが
たまたまTwitterログインを実装したことがない人からすれば、Twitterログイン機能の実装が「できない」のではなく、「やったことがない」だけで実装手順の調査が必要になる。それだけだ。
「できない」と思っていて15分調査をして15分手を動かした結果、30分後には「できる」と答えることができる自分に変わる。
本当に紙一重だ。
エンジニア歴1年の自分ができてエンジニア歴10年弱の弊社社長ができないことだってあるはずだ。
それはたまたま自分が経験した実装であり、たまたま社長が経験しなかった実装である、ただそれだけのことだ。
この経験から今ではやったことがない実装を要求されたとしてもさほど怖くはない。

SESエンジニアの付加価値

半年が過ぎたあたりでの出来事だ。自分よりも遥かに熟練者I氏がアサインした。
I氏と仲良くなり、もらっている単価を教えてもらった。当然自分よりも遥かに高い。
でもそこで気づいた。もらっている額に差はあるが、実際の仕事内容、機能要件のレベルはそんなに変わらない。
ではなぜI氏の方が遥かに単価が高いのか?I氏を観察することにした。
そこからわかったことは、
機能要件に対しての懸念と代案や打開策を提示していること。さらに打開策のモックも用意して。そのうち客先とのミーティングにも呼ばれるようになっていた。
これが自分にはなくI氏にあるSESエンジニアとしての付加価値だと気づいた。
要求された機能を実装するだけなら自分でもできるようになってはいたが、そんなエンジニアは全国に山ほどいる。
じゃあそんなエンジニア達よりも稼げるエンジニアになるには付加価値が必要だ。
エンジニアリングをするのはお仕事として当然だが、SESの傭兵部隊としてはビジネスをしなければならない。
よく弊社社長が「自分が携わる案件のアプリで常にベストアプリ賞を狙っている」と言うが、これを本気で考えた時に
機能要件を満たすことだけでは足りない。
アプリを企画する側の人間よりもアプリエンジニアの方がアプリのことを知っている。
提示される要件が世の中のニーズからずれていることだって多々ある。そこでSESエンジニアがどう行動するべきか。
懸念点を挙げるだけでは弱い。
代案を出す、もう一息。
実際に作って、当初の案と代案を並べて見せてあげる。
ここまでやって初めて「あなたにお願いしてよかった」なんて言葉が返ってくるのではないだろうか。

まとめ

そんな経験を経て、教訓を得て、
今は一案件のアプリのマネジメントをさせてもらえるようにもなり、客先との仕様決めや設計などの場にも携わることができている。
あくまで持論であり、「そんなの当たり前だ」とか「間違っている」と
十人十色様々な意見があるかもしれない。
でも間違いなく自分の支えの一つになっている経験である。