エンジニアとして気をつけていること 5選
はじめまして、Monstar Lab Inc.でiOSのエンジニアをしている菊池です。
今回は社会人になって大体6年くらい働いたので失敗、問題の経験を振り返って気をつけて行っていること5個を事例を挙げながらお話しようかと思います。
大きく<プライベート編>、＜仕事編＞に分けて記載いたします。
<プライベート編>
1. 業界関係者以外の人と話す(折衝を含む)際は、専門的な技術的なキーワードはなるべく避けて相手の人が理解できるキーワードに変換して話すこと
Q. 何に失敗したのか?
A. 相手は自分が話したキーワードを理解できなかったので会話のキャッチボールが困難になった。
これは各業界方面の人はあるあるの話なのではないかな?と思います。
失敗例)
Aさん 「菊池さんってどんなお仕事されているんですか?」
菊池 「普段はiOSのエンジニアやってますね。」
Aさん 「iOSって何ですか？」
菊池 「iOSとはiPhoneの中に入っているAppleが提供するオペレーティングシステムでありまして・・・・」
Aさん 「・・・・・(何それ、わからない・・・)」
正直、IT業界の人ならこれで通じますが、iPhoneのシェアが6〜7割ある(日本のiPhone比率は世界一！)日本でもiOSというキーワードがそれほど認知されてないなと感じた出来事でした。私の経験ですが、10人中4人くらいは何それ?的な反応されました。
なので、以下のように変換したら割と伝わりました。
成功例)
Aさん 「菊池さんってどんなお仕事されているんですか?」
菊池 「普段はiPhoneのアプリ開発をやってますね。」
Aさん「そうなんですねーどんなアプリ作ってるんですか？」
こんな感じに会話が続くようになります。「iOS」→「iPhone」これくらいの簡単な変換で伝わり方がかなり違ってきます。iOSよりもiPhoneというキーワードの方が一般的に認知されているからだと思われます。
人に説明するということは自分の話したいことを一方的に伝えるのではなくて、人に理解してもらって初めて成立すると自分は考えています。なので、会話しながらうまく伝わってないかなと思ったら相手に理解してもらえそうなキーワードに変換するということを心がけてみてはいかがでしょうか？
また、逆説的に応用するなら会話する相手の業界のキーワードを覚えると会話がスムーズになると思うので仲良くなれるチャンスが増えるかと思います。
2. セミナーには積極的に参加してみること
Q. 何に失敗したのか?
A. 普段の業務だけだと自分のスキル不足(井の中の蛙)を痛感する。
同じPJに長期間所属しているとどうしてもそこでの運用ルールや開発が優先されると思います。それだけをずっとこなしているとそれで良いかと満足してしまって、どんどん技術が進化していっているのにそのうちレガシー(時代遅れな)な技術を続けることになり置いてかされるかもしれません。
普段の業務以外の技術をキャッチアップしやすくするために勉強会に参加してみてはいかがでしょうか?
私が普段勉強会を探すときに利用しているサービスをここで紹介したいと思います。土日のイベントもよくやってるので平日よりも参加しやすいかもしれません。
connpass - エンジニアをつなぐIT勉強会支援プラットフォーム
Doorkeeper: セミナー・勉強会・イベント管理ツール
dots. [ドッツ] - IT勉強会・セミナーなどのイベント情報サイト
OpenCU | Learning Platform Designed for Creative
<仕事編>
3. 仕事は時間で管理すること
Q. 何に失敗したのか?
A. 複数の仕事を抱えすぎてキャパオーバーを起こす。そして体調を崩して仕事ができなくなる。
これはもしかしたら、私の考え方に反対な意見を持つ方がいるかもしれません。仕事の向き合い方の考え方の1つと捉えていただければと思います。
まず仕事は時間で管理することとか当たり前ではないかと思うかもしれませんが、経験上自分も含めてできない人はたくさんいたと思います。どうしても納期があるとトラブルや割り込み作業があったりして仕事が積み上がってくるとパニックになってきて振り切ってやろうとすると大概正常な判断ができなくなり大きな失敗を起こします。
私が行ったことは改善策は一つ一つの細かいタスクを時間換算すること。それで見積もり上難しい場合はリスケを行う。また、急な依頼や割り込み作業は全て鵜呑みにせず、可能であるならやるができないなら断るくらいをした方が良いと考えています。
自分の仕事のせいだけでなく、ビジネス的な理由で対応を急ぐ場面は遭遇するかもしれません。その場合でもまずは冷静に分析し、次のタイミングで実施するか今対応するかは上長の判断等で柔軟に判断すれば良いかと思います。
時間換算をすることが上長の判断材料になるケースは多いはずです。
4. 説明は図を多用すること
Q. 何に失敗したのか?
A. 会話だけの説明だと仕様を理解してもらえないことが多発する。
これは<プライベート編>.1に通ずる内容なのですが、技術的な内容を会話のみで相手に理解してもらうのは普段仕事をしていて難易度が高いと考えています。
処理が複雑であるならシーケンス図を書くなり、システムの振る舞いを説明したいならユースケース図を書いたりして説明した方が相手に理解してもらえます。エビデンスにもなるので後から入った新規メンバーにも情報共有がしやすいです。
ただ、これらの図を完璧に書く必要はないと考えています。仕様を理解してもらうことがポイントなので伝われば無駄に工数をかけず簡略化して良いと考えています。
5. 挨拶をすること
Q. 何が問題なのか?
A. 開発はチーム戦が多いです。一人で仕事はできるかもしれませんが、多くの人に支えてもらって世の中のサービスは成り立っています。
挨拶をしてください。今までの経験上私も含めてエンジニアのコミュ症率は非常に高いと考えています。無言で出社、退社するよりもちょっとの会話で心を開いてくれて相手と仲良くなれたりするものです。仕事上で仕様的な問題にぶつかったりする際は相談できる良きパートナーになるかもしれません。
意識的にいつも朝、夜、すれ違いで挨拶をしているのですが現状挨拶をしてくれない方も中にはいらっしゃいます。シャイなんだと思ってポジティブに考えています。
「うっす」、「・・っす」、うなずくくらいからでも良いのでぜひできてない人はやってみてください。
次回は技術ネタを書いていきたいと思います。