『システム開発の発注前に確認するべきこと – プロジェクトを成功させるために』という記事では、プロジェクトについて確認するべき点をいくつか記載しました。
そして記事中でも少し取り上げましたが、二人三脚でプロジェクトを作り上げる『担当エンジニア』についても、しっかりと確認・調査を行うべきです。
しかしながら、非エンジニアの方がエンジニアのスキルを推し量るのは、難易度が高いでしょう。
今回の記事では、担当エンジニアの『スキルを判断できる箇所』や、『どういった質問を行うことでエンジニアの技量を見抜けるか』といった点をご紹介します。
Githubアカウントの確認
『Github』とは、プログラムのコードをネット上で管理できるサービスです。
詳しい仕組みについては割愛しますが、この『github』というサービスの特色としては『これまでの活動履歴等が可視化される』点が挙げられます。
なのでもし以下の点を確認することができれば、エンジニアとしての技量を見抜く１つの指針になります。
Githubでコミットしている形跡があるか？
『コミット』とはgithub等のシステムにおいて、『コードの変更・保存』をおこなったことを意味します。
もちろん誰でも『コミット』を行うことはできるのですが、
少なくともこの『コミット』の数を見れば『どれだけ自ら手を動かしているのか』を調べることができるのです。
この『コミット』を確認するためには、ユーザープロフィール画面の中段部分を見てください。
左上の『contributions(貢献)』と書かれている部分は、github上でどれだけ活動を行ったかが表されている数字です。
この『contributions』には、コミット以外（レビューや問題提起）も含まれているのですが、それらの内訳は右下の十字グラフに描かれています。
Commitsが66%と書かれているので、この場合は2021年に『約134回コミットした』と見ることができます。
草(contribution graph)を確認する
上記コミット数ですが、もちろん水増しすることも可能です。
小さな変更を何度もコミットすれば、それだけで数字は増えます。
しかし、1年中それらを行って偽装する人はなかなかいないでしょう。
その点を判断できるのが、contribution graph ー通称『草』や『芝』と言われるグラフです。
このグラフがまんべんなく緑になっているのであれば、その人は１年を通じて積極的に活動しているエンジニアということが見て取れます。
ただし、もし担当エンジニアが１年を通じて積極的にコミットしている人な][らば、安心して仕事を任せられるかもしれません。
SNSアカウントの確認
twitter・Facebookのアカウント等からも、担当エンジニアの技量や人柄を見ることができます。
……といっても、見るのはフォロワー数ではありません。書き込みの内容を見て、その人が日頃から何をアピールしたいと思っているのか、それを読み解くのが重要です。
こんな書き込みばかりなら注意
- 自己啓発的なことばかり書いている
- 『稼ぎ方』等ばかり書いている
「自己啓発的な内容」「稼ぎ方」に関して、内容の是非についてはここでは触れませんが、
この２つの題材に共通する点として、『実態が伴わずともフォロワーを増やせる』ことが挙げられます。
その書き込みに実用性や裏付けがなくとも、人々は関心を持つからです。
一方でエンジニアリングとは工学のことであり、工学とは基礎科学をもとに具体的な問題の解決を目指す学問です。
であるならば、本来エンジニアは実績や具体的なスキル・成果等でフォロワーを獲得するのが王道であり、「自己啓発的な内容」「稼ぎ方」といった内容からは遠い職業であるはずなのです。
にも関わらず、「自己啓発的な内容」「稼ぎ方」ばかりツイートしているエンジニアは……違和感を持たれても仕方ないでしょう。
更に、注意したい書き込みとして以下のような例も挙げられます。
- やたらとポジション取りしようとしている人
- 他のユーザーと言い争っている人、好戦的なツイートばかりの人
上記はわかりやすいですね。
一緒にプロジェクトを進める際もポジション取りをしてくるかもしれませんし、問題が起きたときに好戦的な態度を取ってくる可能性があります。
こんなSNSアカウントの人は信頼できるかもしれない
- SNSアカウント上で趣味・エンジニアリングを分け隔てなく呟く
- アイコンがアニメ、猫、犬、自撮り
- 発信がメモ的な人（アピールではなくつぶやきをしている人）
エンジニア……というよりも、『一緒に仕事がしやすい人』のSNSアカウントはこのような傾向になると思います。
要は『飾らずに等身大の表現をしている人』です。
素直に自己表現を行う人とは、お互いに信用しやすくなります。それはあなただけでなく、チームメンバーも同じでしょう。
問題が起きたときも、自分の見え方・評価を気にするのではなく、解決にフォーカスして話し合いを行うことができるかもしれません。
もちろん、これもSNSアカウント一つで完璧に判断できるわけではありませんが、判断材料の一つにはなると思います。
経歴の確認よりも、どの機能・どの部分を開発したか
コンペやプレゼンの際、担当エンジニアの経歴が添付されていることもあるでしょう。
もしくは、linked inやfacebook等でエンジニアの経歴を見ることができるかもしれません。
その際はぜひ、『どのような案件に携わったか』よりも『どの機能・どの部分を開発したか』に着目してください。
もし担当箇所が書かれていなかったなら、本人に質問してみましょう。
例えば大企業の有名なサービスに携わっていたとしても、そのようなプロジェクトにはたくさんの人間が参加しているので『簡単な部分にちょっとだけ携わったエンジニア』というのも珍しくありません。
他方で、以下のような箇所については、広く深い知識を持つエンジニアに任されることが多いです。
- 認証機能、セキュリティ
- データベースのテーブル設計
- ネットワークの設計
『認証機能』や『セキュリティ』は『緻密さが求められる箇所』です。ここを誤ると不正ログインや個人情報流出等が起きかねません。
『データベースのテーブル設計』は、地味な作業に思えるかもしれませんが、『緻密さ』『全体への理解』両方が求められます。
システムとは言ってしまえば『データのやり取り』です。
ここを誤ってしまえばそもそもシステムが破綻するかもしれませんし、そうならずとも『拡張できない』『パフォーマンスが出ない』『不具合が頻繁に起こる』といった事態に陥りかねません。
『ネットワークの設計』は、いわば『正しい知識を持っているか』が試される箇所です。
フロントエンド等の見た目部分や、シンプルなデータの処理等は、ある意味「見様見真似でなんとかなるかもしれない」部分です。
一方で『ネットワーク設計』部分は、「見様見真似」や「なんとなく」で出来る箇所ではありません。
『OSI参照モデル』や『スイッチング』等の正確な知識が必要ですし、トラブル発生時にダメージがなるだけ小さくなるよう、あらゆることを想定する知識も求められます。
もし上記のような箇所を担当・設計したエンジニアならば、経験・スキルともに十分だと判断できるでしょう。
その場で技量を判断できる『魔法の質問集』
ここまで取り上げたものについては、一つ弱点があります。それは判断材料を『自分で探さなければならない』という点です。
紹介された担当エンジニアが「そもそもgithubもSNSアカウントも持っていない、経歴書も添付されていない……」という方かもしれませんし、
多忙により調査する時間を取れないケースも考えられます。
そのような場合のために、以下のような質問を用意しました。
この質問をエンジニアにぶつけるならば、その場で担当エンジニアの技量を推し量ることができます。
セキュリティはどうする？
この質問をするのは、単純に『セキュリティ部分は専門性が求められる箇所だから』という理由です。
作る事自体はゴリ押しでもなんとかなりますが、セキュリティを万全にしようとすると、広範な知識・経験・判断力が求められます。
『ただ作るだけ』のエンジニアには難しい質問です。
将来的なスケールアップ、スケールアウトはどうする？
『事業が人気を博して利用者が増えました！』となれば、当然、最初に用意したサーバでは処理が追いつかなくなるでしょう。
ではそのとき、どのような対処を行うのでしょうか？
この問いに『サーバを増やします』と答えるのは簡単ですが、『サーバを増やす』というのはその実簡単なことではありません。以下のような質問を追加で投げることができます。
- サーバを増やす際のコストはいくら？
- 維持コストはどのぐらい変わる？
- ダウンタイム（増やす際の停止時間）は必要？何時間ぐらい？
また、逆に利用者が少なくなって『スケールアウト』するケースも考えられます。
その想定についても、上記の質問は有効です。
バックアップはどのように行う？その復旧方法・復旧時間は？
『バックアップからシステムを復元した経験』は、長いキャリアを持つエンジニアならば当然持っているものです。
逆に経験が浅いエンジニアの場合、バックアップ方法自体は答えられても、実際の復旧手順・どのぐらい時間が掛かるか、といった点を具体的にイメージするのは難しいでしょう。
バックアップは、「バックアップ」が目的ではなく「復旧すること」が求められる作業です。
この点で経験豊富なエンジニアには頼りがいがあります。
不具合が発生した時にどのように対応してくれますか？
この質問はもちろん、「頑張って直します」という返答を期待している訳ではなく、以下のような点を説明してもらうための質問です。
- モニタリング体制
- どのような報告を、どの時点で上げるのか
- 原因究明と解決に携わる人員
なお、止まった際の影響が大きいシステムの場合は、不具合発生時の連携についてもしっかりと協議しておきましょう。
〇〇ってどういうメカニズムで動いているんですか？
○○には実際開発する機能を入れてもいいですし、一般的なスマホのアプリやクラウドサービス等を入れても構いません。
これは知識を問う質問でもありますが、『複雑な仕組みを単純化するスキル』『非エンジニアに説明するスキル』等を測る質問でもあります。
（エンジニアの面接でも時々用いられる質問です）
なぜ、担当エンジニアについて知る必要があるのか
さて、そもそもなぜこんな記事を書いたかと言えば、
担当エンジニアのスキルやパーソナリティを知ることは、開発を成功させるためにも重要なことだからです。
残念ながら、エンジニアとして出世する人の中には、あまりスキルが無いにも関わらず『口がうまい』という理由で昇進する人もいます。
もちろんコミュニケーションスキルや説明能力は、プロジェクトを進める上で役に立つ能力ですが、
スキルが低い場合は、逆に『問題がごまかされた』『炎上するまでリスクに気づかなかった』という事故が起きがちです。
また、前回の記事でも同じようなことを書きましたが、担当エンジニアについて「良く知る」、「コミュニケーションを取る」事によって、
『認識のすれ違いを避ける』『情報交換を円滑に進める』『欠点を補う』といったことも可能になります。
海外の調査結果によれば『プロジェクトが失敗する理由の３分の１は、コミュニケーションを理由としたもの』であるとのことです。
もし”プロジェクトを成功させるためなら何でもしたい”と考えるのであれば、ぜひ担当エンジニアについて知ることから始めてみてください。
