こんにちは、エンジニアのづやです。
LIGでは定期的にRuby開発者であり当社の技術顧問を務めている、まつもとゆきひろさんによる社内勉強会を開催し、エンジニアのスキルアップに取り組んでいます。
第8回は「LIGエンジニアからの質問回」です。エンジニアから寄せられたまつもとさんへの質問に対し、一つひとつお答えいただきました。
質問の内容は「エンジニアと英語力」「エンジニアのスキルアップ」「コミュニケーションが苦手な場合のお客さまとの関係構築の方法」など、エンジニアが直面することの多い悩みばかりですので、ぜひ参考にしてください！
|
人物紹介：まつもとゆきひろプログラミング言語Rubyの生みの親であり、一般財団法人Rubyアソシエーション理事長。株式会社ZOZOやLinkers株式会社など複数社で技術顧問などを務めている。オープンソース、エンジニアのコミュニティ形成などを通じて、国内外のエンジニアの能力向上やモチベーションアップなどに貢献している。 |
|---|
目次
英語のドキュメントを読むのがつらい！ まつもとゆきひろからの3つのアドバイス
- Q：特定のAPIを利用する際に公式のドキュメントを参照するのですが、英語で書かれていて読むのがつらいです。どう対応すればいいですか？
まず私の英語力を説明しておきます。
英語はあまり好きではないのですが、Rubyのユーザーは世界中にいて、カンファレンスも海外で行われることが多いため、仕方なくという感じで英語を使っています。
会話力は、Ruby関連などジャンルが限定されれば、英語でのやりとりが可能です。読解力は、辞書を引かなくても英語のままである程度は読めます。ただ英語で書かれている本は、日本語版がでていたら絶対にそちらを読みますね。
さて英語のドキュメントを読むために、私から3つのアドバイスがあります。
ためらわずに機械翻訳ツールを使う
一つ目は、「ためらわずにDeepLやGoogle翻訳などの機械翻訳ツールを使う」です。
ツールに頼ることに後ろめたさを感じる方もいるかもしれませんが、英語が得意ではない方が原文を辞書なしで読めるようになるには時間がかかります。そこで、今目の前にある仕事を進めるためにも便利なツールはどんどん使いましょう。
ただしツールは誤訳もありますので、翻訳結果に疑問を感じたら別の翻訳ツールを試してみたり原文を読んでみたりして、内容をよく確認してください。
ドキュメントは最初から最後まで読まなくていい
二つ目は、「ドキュメントは最初から最後まで読まなくていい」です。
英語のドキュメントを冒頭から読んでいくと、モチベーションが続かず、途中で力尽きてしまいがちです。そうすると結局知りたかった内容がわからないままになり、非常にもったいない。
まずは枠組みに従って自分のやりたいことをどのように実現するかという観点で、目次とインデックスを確認し、必要そうな部分を抽出して読んでみてください。
APIのドキュメントは、サンプルプログラムを見て概要をつかみながら機械翻訳した内容を読んでいけば理解できると思います。まずAPIの基本的な構造を理解し、それを手がかりにボトムアップで読んでいくのがおすすめです。
英語は読解も会話も、場数を踏むことで上達していきます。今後海外で働きたいと考えているのであれば、英語ができないことはハンデになるため、地道に英語の勉強を続けてください。
公式情報と解説ブログの使い分けをする
三つ目は、「使い分けをする」です。
公式のドキュメントはプロジェクトによってクオリティに差があり、ライブラリの使い方などの概要をきちんと説明していないものも少なくありません。これは筆者はライブラリについて深く理解しているために、概要を飛ばして、よりミクロな部分を解説しようとしてしまうからです。
そういった公式ドキュメントに当たってしまった場合には、概要を解説しているブログを探しましょう。ブログはドキュメントと違ってユーザー側の視点で使い方などが書かれているので、読みやすいと思います。
ただやはり個別のAPIに対してどういった制約条件があるかといった細かな情報は、公式情報を参照するのがベストです。APIドキュメントに概要の解説がない場合は補足として解説ブログを活用し、理解できたら公式のドキュメントを読むなど、使い分けをしてみてください。
優秀なエンジニアが公式ドキュメントを読んでいる姿を見て自分と比較してしまうかもしれませんが、そのエンジニアは過去の案件でそのAPIを使ったことがあったり、読解スピードが早くて周囲が翻訳文やブログを読んでいるのを目撃していなかったりするだけかもしれません。焦る必要はありません。
エンジニアに納得してもらえる評価の仕方とは？マネージャーができる解決策
- Q：エンジニアのスキル評価が定性的になりがちです。どういう基準で評価すればいいのでしょうか。どうすれば納得してもらえるのでしょうか。
私はマネージャーとして給与に影響するようなメンバー評価を行った経験があまりないのですが、大前提として、定量的なスキル評価はまず無理だと思います。
とはいえ定性的に評価をすると、どうしても本人の考えと周囲からの見え方にはギャップがあるため、完全には納得してもらえない。そもそも素晴らしいスキルがあっても、アサインされた業務とスキルセットの相性が悪ければ、良いパフォーマンスが出せないこともあります。運も影響するのです。
そこで私が考える解決策は二つあります。
周囲からの信頼度を基準にする
一つは、「その人に対する周囲からの信頼度を基準にする」という方法です。
「この人に任せたら、絶対どうにかしてくれる」という周囲からの信用・信頼は、ある程度数値化できるはずです。いわゆる360度評価のような形式でメンバーから意見を集めるなどして信頼度を可視化すれば、評価に活用できると思います。
プロジェクトのもうけを山分けする
もう一つは、「プロジェクトのもうけを山分けする」ことです。
優れたスキルがある人でも、案件の内容やコンディションによって十分なパフォーマンスが発揮できないことがあります。そこで結果だけを見て評価が行われてしまうと、本人は「本当はもっとできるのに」とくすぶってしまう。
プロジェクトに対する貢献度や信頼度などに応じてもうけを分配すれば、今回はイマイチでも、がんばれば次は多くもらえる可能性があるとわかるので納得しやすく、「このプロジェクトをビジネスとして成功させよう」という気持ちにもなると思います。
企業によっては、特定の資格を取得することで評価が上がる仕組みを導入しているところもありますが、大抵の場合、資格取得は業績アップに直結しません。
タスクの完了数などをKPIとして設定するケースもありますが、タスクのサイズをわざと小さくして完了数を多く見せるといったズルをする人が出てくる可能性がある。そうなるとモラルハザードが起き、逆に生産性が下がってしまいかねません。個人的にはエンジニアのスキル評価にKPIを設定することには賛成しませんね。
エンジニアのスキルアップのために必要なこと、マネージャーの働きかけのポイント
- Q：LIGでは社内でコードレビューを行ったり、ほかの人のやり方をリアルタイムで見る機会を設けたりして、エンジニアのスキルアップを図っています。他社事情にも詳しいまつもとさんおすすめの施策はありますか？
スキルを伸ばすには「時間」「場数」「やる気」が大事です。
やる気は個人でもくもくと勉強しているときより、みんなで一緒に取り組んでいるときの方が高まる人が多いと思うので、LIGで今実施していることは、とても実りのあることだと思いますね。
「取り扱い説明書」をつくってもらう
ここからはエンジニア個人の努力になるのですが、スキルアップのためにはまず自分の得意な分野、モチベーションが上がる技術を自覚することが必要です。見つかったら、そこを伸ばしていきましょう。
特定の分野・技術のスペシャリストを目指すと決めると自然とやる気がわき、専門性も高まると思います。専門性のある人材は、マネージャーにとってもアサインしやすく重宝されます。
「私の取り扱い説明書」をつくるつもりで得意と苦手を明確にしておけば、マネージャーも一緒に仕事がしやすく、Win-Winの関係が築けると思います。
ゴールを示す
メンバーのモチベーション維持に悩んでいるマネージャーは多いと思いますが、自分が子どものころ、学校の先生や親に「勉強しなさい」と言われても、なかなかやる気にはならなかったのではないでしょうか。
ですが実は「これがわかるようになると、夢の実現につながる」といったゴールが見えると、周囲がとくに働きかけをしなくても自発的に学ぶ子は多いんです。
仕事も同じで、「この技術を知っていたおかげで、自分の仕事が楽になった・良くなった」という経験を積み重ねていくと、その人は自然と勉強はしたほうがいいのだと気づきます。
マネージャーはぜひ「この知識を持っていると、こういう場面で役に立つよ」というゴールを示してあげてください。学びへのモチベーションアップにつながるかもしれません。
コミュニケーションが苦手なエンジニアこそ、顧客が本当に望むものがつくれる
- Q：LIGのエンジニアは開発だけでなく仕様決めや設計交渉も行うため、お客さまとのコミュニケーションは避けられません。コミュニケーションが得意ではないエンジニアは、お客さまから信頼されるためにどう振る舞えばいいのでしょうか。
有名な話ですが、フォードモーターの設立者であるヘンリー・フォードは、人々に移動手段として欲しいものを尋ねると「もっと速い馬が欲しい」と回答すると考え、そこから顧客の本当の望みは早く移動することだと気づき、量産車を販売、成功したそうです。
一般的にコミュニケーション能力が高い人は、相手の気持ちを察するスキルが高い傾向があります。そのためお客さまからのヒアリングの際にも、相手の気持ちに配慮してしまいがちです。
ところが、ソフトウェア開発においては「相手がほしいもの」が必ずしもいいものとは限りません。むしろ、要望通りのものをつくるととんでもないものが生まれてしまうことがある。
お客さまとのやりとりにおいて大事なのは「相手が困っている事実」を聞き取ることです。私はコミュニケーションが苦手な人は相手に寄り添い過ぎないため、困りごとを引き出すのが逆に上手だと思っています。
お客さまとの関係では「わからないことは、こちらにお任せください」といえるようにしておくことが大事です。
最初のビジョンは丁寧に説明する必要がありますが、その後についてはお客さまの望みを聞きすぎると、開発にはあまりプラスになりません。要望が多すぎる場合は、開示する情報を絞るのも一つの手です。
ただしお客さまはお金を払って依頼しているのであり「納得感」「満足感」を持ってもらうことが必要です。何をお伝えしたら納得してもらえるのか、よく見極めるようにしてください。
まとめ
今回はLIGエンジニアのリアルなお悩みに対して、まつもとさんの経験をふまえて具体的なアドバイスをいただきました。エンジニアにとってもマネージャーにとっても、すぐに導入できそうな内容ばかりでしたね。
次回も現場で役立つ情報をお伝えできるようにしていきますので、次回のまつもとゆきひろ勉強会レポートもぜひチェックしてください！
