読者です 読者をやめる 読者になる 読者になる

歩いたら休め

If the implementation is easy to explain, it may be a good idea.

【愚痴】新卒入社半年のへっぽこエンジニアが、来年の後輩のためにアドバイスを残しておく

へっぽこ新卒エンジニアの黒めだか(仮名)です。

情報系でない研究室から新卒で入社し、半年間IT(WEBサービス)のエンジニアとして働いてきました。 その間、社内の特殊ルールや何らかの歴史的経緯による変な設計や文化で困ることが多々ありました。 今後入社する優秀な後輩も同じことで悩むんじゃないかなと思い、 アドバイスとして残すための記事を書いてみました。

嘘です。単なる愚痴です。

社内の文化を(必ずしも)是と思うな

あらゆる文化にはいい面もあれば、副作用として悪い面もあります。 つまり、入社時に一番惹かれた部分が、逆に入社後に苦労する部分になるかもしれません。

弊社の場合、「(経営者目線で)先を見据えて物事を考える」という文化があるため、 迅速なWEB開発が可能になっていたり、若い社員でも手を挙げればチャレンジさせてくれる土壌があります。 判断に困ったらユーザー目線に立ち返ることができているので、根本的に間違った、変な開発はないんじゃないかなと思います。

ただしその分、新しい技術やプログラミング言語に興味を持っている先輩が少なかったり、 インフラや運用への投資がおろそかになったいたり、 迅速な開発に特化した(?)分、手戻りや投げっぱなしが多いような気がしています。

なので「Pythonでmap関数とリスト内包表記を覚えたらfor文書きたくなくなったけど、 Haskell勉強したらlambda式を書くことすら面倒になったでござるよwwwコポォwwww」みたいな話をすると、 「それってなんの役に立つの?今PHP使ってるんだからPHPでいいじゃん」って言われることが多くて悲しかったです。

私はインフラの部署でインターンしていたのですが、 その時に協力会社の方から頂いたアドバイスが「社内の文化や運用を是と思うな」です。 インフラの部署は、要するに「歴史的経緯による変な設計」で一番ツケを食らっている部署で、 お世話になったリーダーの方がいつも悲しそうな目をしているのが心苦しいです。

積極的に外に出よう

「社内の文化や運用を是と思うな」と言われても、他に基準が無ければ行動できないと思います。 他の価値観やスキルを学ぶために、外の勉強会などに積極的に参加しましょう。

dots.などを利用するといいと思います。

eventdots.jp

相談できる先輩を持とう

社内のファンタスティックな設計に立ち向かうには、相談できる先輩が絶対に必要です。 弊社の場合、ドキュメントはファイルサーバー上のどこかにあるため、新入社員が自力で見つけ出すのはおそらく不可能です。 諦めましょう。

相談できる先輩として、具体的には

  1. 入社して2〜3年くらいで、
  2. 他の会社を知っていて(おそらく中途採用で)、
  3. 新しい技術への学習意欲の高い人

を探せばいいでしょう。

まず、「1. 入社して2〜3年くらい」ですが、あまりに弊社への勤続年数が長すぎると、 「歴史的経緯による変な設計」に慣れきってしまってこちらが困っていることを理解してくれません。

「2. 他の会社を知っている」ことも重要で、他の会社の運用方針などを知っている人は、 ちゃんと悪い部分に違和感を持っているのでこちらの意を汲みとってくれるはずです。 「3. 新しい技術への学習意欲の高い人」も同様です。

余談ですが、JavaScript部分は社内のすごいJSエンジニアの開発したオブジェクト指向のライブラリを利用し、 ちゃんとした設計思想の基で開発が進められているようなので、比較的闇が浅い気がします。 というか、元々複数のサービスを取りまとめたようなWEBサービスなので、 DB部分に一貫性が無く、それに伴ってサーバーサイドが色々とごちゃごちゃしているんじゃないかなと思います。

JavaScriptパターン ―優れたアプリケーションのための作法

JavaScriptパターン ―優れたアプリケーションのための作法

要するに、「他の会社に行ってもエンジニアとして活躍できそうな人に相談しよう」ということです。

教えてもらうことを期待するな

部署にもよりますが、「じゃあこれをやってみよっか」とタスクを渡され、 そのままなんとな〜くな感じで仕事が始まります。 分からない部分があったとき、自分から積極的に質問しないと放置されるでしょう。

逆に先輩の立場からすると、新人がどんなスキルを持っていて、どこで詰まってしまうかなんて分かりません。 積極的にアラートを出してあげないと「ああ、順調に作業を進めているんだな」と誤解されてしまいます。

分からない点をメモに残しておきましょう。 それがそのままタスクリストになるはずです。 その一つ一つのタスクに対し、先輩に質問するか、自分で調べるか決めていきましょう。

正直、新卒を受け入れて教育する土壌は期待しないほうがいいです。 人事の方も研修等に力を入れてくれているのは分かるのですが、ビジネスパーソン全般の立場のものばかりのため、 エンジニアとしての思想やスキルは自分自身で身につけていくしかありません。 (新卒向けの技術研修もありましたが、あまり実になるものではありませんでした)

少なくとも、「コレさえ押さえれば一端のエンジニアとして活躍できる」という都合のいいものは、 世界中どこを探してもありません。 強く生きましょう。

技術面より先輩への相談や周囲への説明が大事

新卒の研修で「ホウ・レン・ソウ大事!ホウ・レン・ソウ大事!」と耳にタコができてうんざりすると思いますが、 実際めちゃめちゃ大事です。

技術面はその言語の良書を2〜3冊読めばあまり困ることは無かったのですが、 非エンジニアの上司に「言語の仕様上こういうことできません」という説明を怠ると大抵後で落とし穴にハマります。

また、中途半端に他人を手伝ってしまい、相手にその内容を理解してもらえなかったために、 自分のタスクが増えてしまうような事例も(私ではないですが)ありました。 定型作業に何時間もかけている人に「それってバッチ処理でできるじゃん、おれが書いてやるよ」と手伝った結果、 相手がそのコードをメンテナンスできず、自分のタスクを増やしてしまうような人もいました。

楽しくプログラミングに集中できるように、関係者各位に合意を取りながら仕事をしましょう。

kiito.hatenablog.com

技術面に特化して伸ばしていきたい人は、思うように評価されずに悩むかもしれません。

やりたいことはきちんと主張しよう

自分のやりたいこと、できることはきちんと主張していきましょう。 幸いなことに、手を挙げた人にチャレンジさせる文化は根付いています。 その分、普段の業務をきっちり運用できるよう支えている人は評価されづらいのかもしれませんが…。

自分のやりたいことを「これって単純化しすぎじゃね?」ってくらいシンプルにまとめ、端的に伝えられるよう準備しておきましょう。 「偉い人とエレベーターで一緒になったとき、30秒で伝えられる」イメージが目安です (エレベーター・ピッチで調べれば参考になるものがたくさん出てくるはずです)。 詳細は、相手が興味を持って質問し返した時に説明すればいいです。

結局は「技術のある人」ではなく「事業の成長に貢献した(ように見える)人」が評価されます。

ざっくりでいいので、スケジュールをきちんと立てよう

プロジェクトが始まった際、「調査には1週間、この部分の実装には2週間」というように、 ざっくりとでいいのでスケジュールを立てておきましょう。 最初に全てを計画するのが難しければ、ある程度調査した後に引き直しても大丈夫です。

大抵、思いもよらない部分で難しいことが出てきたり、 逆に実装がすんなり進んでしまったり、計画通りに進むことはほぼありません。

しかし、あらかじめプロジェクトを具体的な作業を分解することで全体がイメージでき、 また後で「意外にあの部分が難しかったよね」と振り返ることができます。 また経験豊富な先輩と難易度のイメージをすり合わせることもできますし、 あらかじめ立てたスケジュールより長引きそうな場合に相談しやすくなります。

計画は当てにならないが、計画づくりは必須である」って何かの本に書いてました (何の本かは忘れてしまいました…)。

きちんとスケジュールを立てられていない場合、周囲に相談できずにタスクを長引かせてしまい、 最終的には色々な人に負担をかけてしまいます(最近の私の話です)。 無理やりでもスケジュールを立て、それを基に先輩に相談し、 全体のロードマップを意識できるようにしましょう。

自分以外に事情を知っている人を作ろう

一人で仕事をしていて、ほかの人(特に先輩や上司)に状況や進捗を理解してもらえていない状態は黄色信号です。 全体のスケジュールを意識して、 常に「今〇〇の部分を実装していて、××の部分を難しいと感じています」と説明できる状態にしておきましょう。

これもインターンの時に言われたのですが、「引き継ぎするまでが仕事」です。 「自分だけにしかできない作業を持つこと」が「頼りにされること」だと思っている人もいますが、 あれは作業を属人化させ、プロジェクトの進行にボトルネックを生み出し、周囲に迷惑をかけているだけです。 真似しないようにしましょう。

明日自分が死んだとして、先輩が問題なく続きの作業を始められる状態が理想だと思います。 (急に仕事が増えて途方に暮れるかもしれませんが)

Pythonを勉強しよう

先輩エンジニアの学習意欲が平均として低いので、システム全体のことを考えてプログラミングできる人が少ないです。 そのため、具体的には「アプリエンジニアはアプリだけを見ればいいのでPHPJavaScriptさえ見れればいい」というような思想が蔓延しています。 それが何らかの歴史的経緯による変な設計を次々に生み出しているような気がします。

そのため、部署間でやり取りする際に、お互いの言葉を理解できず、 レベルの低いエンジニアの方に合わさざるを得ない状況が生まれ、 そこでも歴史的経緯(ry が生まれているような気がしています。

つまり、闇を生み出さないためには、 ある程度フロントからインフラまで勉強しておく必要があります。 そうすれば、部署間のやりとりの際に「ああ、あの部署の人が言っているのはこういうことなんだな」と分かるようになります。 その際に、一つ汎用的な言語を知っていれば、学習が少し楽になるはずです。

そのため、私はPythonを勉強することをおすすめします。 その理由を大きくまとめるとこんな感じです。

  1. 学習コストが低い(他の言語を知っていればなんとなく読める)
  2. 開発やデータ解析など様々な用途に使え、汎用性が高い
  3. 小さいコードが書きやすく、日常作業の自動化などですぐに役立つ

別にPythonでなくても良いですが、汎用的に使える言語は身につけておきましょう。 Rubyist先輩も全く同じ理由でRubyを勧めてくると思います。 彼に従っても大丈夫です。

Pythonってどんなことに使えるの?」って話は『Pythonエンジニア養成読本』を、

Pythonエンジニア養成読本[いまどきの開発ノウハウ満載!]

Pythonエンジニア養成読本[いまどきの開発ノウハウ満載!]

言語仕様的なものは『はじめてのPython』を読めばいいと思います。

初めてのPython 第3版

初めてのPython 第3版