ふるまいやセキュリティ意識など技術以外も磨け！N高講師が教えるプロエンジニアに必要な要素

「N予備校 プログラミングコース」では、中学を卒業したばかりの高校生やゼロからプログラミングを学びたい初心者に対して、Web技術の基礎を通じてプログラミングを教えています。コースを進めていくことでWebアプリやスマホアプリ、Scalaによる大規模Webアプリケーションを開発するための技術を習得できます。

そして、N予備校の教材は習得した技術を最終的に、ソフトウェアエンジニアとして就職する際に生かしたり、実際の業務で生かしたりできるように作られています。

今回はエンジニアHubさんの協力をいただきまして、この「N予備校 プログラミングコース」では教えていなかった、プロのエンジニアに必要な技術以外の部分についてまとめます。

プロと突然いわれても実際の仕事をする上で気をつけなくてはならないことというのはなかなか勘所が分からない部分もあります。問題が起こってから初めて知る場合も多いのです。そして正直な話をいうと、実際に組織やチームの中で働く場合には、技術以外の要素もとても重要なのです。

重要な点は3つあります。

1. エンジニアとしてのよいふるまい
2. セキュリティを順守する意識
3. チーム開発のための心がけ

今まで趣味や学習用途でのプログラミングはできていた方が新社会人になり、プロのエンジニアとして組織やチームの中でプログラミングをする上で、どういったことが重要になってくるかをお伝えできれば幸いです。

エンジニアとしてのよいふるまい

学習や趣味からステップアップし、プロのエンジニアとしての役割を果たしていくために重要なふるまいが4つあります。

1. 自慢する
2. 褒める
3. あいさつする
4. 日々、技術ニュースを取り入れる

【ふるまい 1】自慢する

謙虚であることを尊ぶ日本において自慢をするなんて失礼なやつだ、と思われるかもしれませんが、実は「自慢する」というのはエンジニアにおいて非常に重要なふるまいのひとつだといえます。

「自慢する」ことにはいくつかのよい点があります。ひとつは、組織の中でエンジニアが少数の場合に技術の啓発をすることができます。大学の研究などでもそうですが、よい研究者というのはアピールが非常に上手です。どんなによい技術を持っていても、その技術が関わる人に知られなければ組織で活用されることはありません。それは非常にもったいないことだといえます。

そしてもうひとつ、自慢は自分自身のモチベーションアップにつながります。自慢して反応が得られれば、それは次のプロダクトを作るときの心の原動力になるのです。特にプログラミングというのは高度な集中力を必要とします。そのため、その時のやる気がプロダクトのクオリティーに反映されやすいのです。

自慢して自らのモチベーションアップにつなげるということは、組織にも自分自身にもよい影響を与えます。エンジニアは、発表する機会があったらどんどん自分が作ったものや調べたこと、失敗して得た知見を発表し、公開し、自慢していくことが重要です。しっかりと自分の行った技術的な活動の成果をアピールしていきましょう。

【ふるまい 2】褒める

これは「自慢する」と対になるふるまいです。そしてこのふるまいは、特に同じエンジニア同士の中で重要なふるまいとなります。

もし、他のエンジニアが何かしらの技術アピールをしたり、自慢をしている際には、必ず褒めましょう。褒めるのはタダなんです！褒めた方も褒められた方もよい気持ちになります。

エンジニアの組織というのは放っておくとあっという間に、相手を尊敬する気持ちが薄れてきたり、謙虚な気持ちを忘れたりして、摩擦が生じてしまうこともあります。

この「褒める」というふるまいには、相手を尊重するという効果もあります。褒め合う文化がある組織の中では、エンジニアは高い心理的安全性を感じながら、非常に気持ちよく開発や研究を進めていくことができます。またこの心理的安全性が、組織にとってよいプロダクトを作るためには重要であるといわれています。

心理的安全性という概念は、Googleが2012年に「心理的安全性がチームの生産性向上のポイント」として報告したことをきっかけに、注目を集めました。メンバーの一人一人が、チームに対して「気兼ねなく発言できる」「対人関係を損なわず本来の自分をさらけだせる」と感じられ、認識している環境・状態・雰囲気などを指します。

そして、ビックリするかもしれませんが「褒める」ということを実践すると、相手をやっかむよりも、褒めた方が自分自身も気持ちよく開発していけるようになります。直接口頭で褒めたりするのが難しければ、チームのSlackなどのコミュニケーションツールで行われた自慢に対して「すごい！」とか「素晴らしい！」とか、SlackやGitHubのリアクション機能（発言に絵文字を付ける機能）を利用して、カジュアルに褒める気持ちを伝えてみるとよいでしょう。それが自分自身のためにも、相手のためにも、ひいては組織の文化づくりのためにも非常に重要なことなのです。

【ふるまい 3】あいさつする

「あいさつなんて社会人としての常識である」と思う方も多いかもしれないですが、エンジニアにこそ、あいさつというのは非常に重要なのです。

エンジニアは無愛想でコミュニケーションが取りにくいと、非エンジニアから思われていることが多いのです。ましてやコーディングに集中して作業していると、特に声をかけづらい雰囲気が漂いがちです。

人は普段からコミュニケーションを取っていない相手との間では、なかなか信頼関係を築けないものです。信頼関係がない中で一緒にプロダクトを作った場合どうなるでしょうか？ それは最終的に「確認事項」が増え、コミュニケーションコストが増大するという形で表れます。

例えば普段からあいさつをし合っている相手に何かを頼むのと、全くコミュニケーションを取ったことがない人に何かを頼むのと、どちらが安心できるでしょうか？ 安心できない相手に作業をお願いするとき、やはり入念に確認項目を増やしてしまいますよね。これは、相手の人となりや行動の原理などが分かりづらいといった不安によるものです。本来なら論理的に不必要な確認事項が、信頼関係が無いことによって生じた不安のために追加されるということがよくあるのです。

このように、信頼感が無いことを原因として不必要な工数を増やさないようにするために、仕事で関わる可能性がある同じ組織の人の中では「おはようございます」「お疲れさまです」「お先に失礼します」といった基本的なあいさつはもちろんのこと、チャットツールなどでのあいさつも徹底的にしておくとよいでしょう。

日々のあいさつの積み重ねで醸成された信頼関係が、組織におけるコミュニケーションを円滑にし、生産性を高めてくれます。今まであいさつをしていなかった方は、すれ違いざまのあいさつを徹底するようにしてみて、その効果をぜひ実感してもらえればと思います。

【ふるまい 4】日々、技術ニュースを取り入れる

ソフトウェアエンジニアリングの世界では、技術が目まぐるしく変わっていきます。一年前の技術があっという間に古い技術になってしまうというのはWeb業界ではよくあることです。

特に、所属する組織と運営するサービス、ユーザーへの影響などが大きいセキュリティ関連のニュースやそれへの対応などを知らないということは、組織に所属するプロのエンジニアとしてあってはならないことです。プロのエンジニアとしてやっていく限り、これら最新の技術ニュースを継続して取り入れる必要があります。

主にWeb関連のITニュースを取り入れる際、このサイトがおすすめというのを以下に挙げておきます。

• はてなブックマークのテクノロジーカテゴリ
• Qiitaのトレンド
• Twitter上の自分が関わるテクノロジーのエンジニアたちのツイート
• GitHubで自分が関わるリポジトリのWatchの通知

この4つが筆者のおすすめです。

はてなブックマークは、有名エンジニアや最新の動向に詳しい人たちがニュースサイトや勉強会で発表された情報などをブックマークしてくれているため、情報ソースとして非常に優秀です。Qiitaも技術的な知識やトレンドの情報の底上げに役立ってくれます。気になる人がいればフォローもしておくとよいでしょう。

一般的な技術に関しては、はてなブックマークやQiitaで十分だと思いますが、より自分に関わる分野の最新情報を入手するためには、Twitterでそのテクノロジーに関わるエンジニアをフォローしたり、関係するGitHubのリポジトリをWatchするのもよいでしょう。そして、自分が取り入れたニュースは社内Slackなどのチャットツールで共有するとよいでしょう。

以上、エンジニアとしてのふるまいに必要な4つのポイントは、

1. 自慢する
2. 褒める
3. あいさつする
4. 日々、技術ニュースを取り入れる

でした。逆に「自慢しない」「褒めない」「あいさつしない」「日々、技術ニュースを取り入れない」というエンジニアが組織にいたとしたらどうなるか想像できるでしょうか。そういった人は、エンジニアとしての存在感が薄く、信頼関係も希薄で、最新情報に疎いエンジニアになってしまうのではないかと思います。そんなエンジニアは、組織において価値を出すことが難しくなってしまうでしょう。

セキュリティを順守する意識

ふるまいに続いて、セキュリティを順守する意識について説明します。まず、組織において最終的にセキュリティを守るのは誰なのでしょうか？ 受け入れテストを行ってくれる品質管理部門でしょうか？ 情報管理システム部門？ それとも会社にいるセキュリティスペシャリスト？ いえ、最終的な責任者はこれらの人ではありません。プロダクトを開発しているソフトウェアエンジニアが、セキュリティに対して最終的に責任を持たなくてはいけないのです。

まず、受け入れテストをする人がソフトウェアの設計上の脆弱（ぜいじゃく）性を指摘できるでしょうか？ UIからの操作や脆弱性検知ツールだけではそれらを見つけることはかなり難しいでしょう。情報システム部門やセキュリティスペシャリストの方が、業務要件として存在している秘匿情報の流出の脆弱性を指摘できるでしょうか？ 正直な話、彼らがソフトウェアの業務要件として外部に漏れ出してはいけない情報をちゃんと把握できているとは思えません。例えば、アプリ内の抽選システムのロジックが漏れている部分に関して、そのロジックが漏れ出してよいものなのか悪いものなのかは、その要件を定義し開発したソフトウェアエンジニアや他の要件も含めて考えている企画者しか判別できない情報だということもあるのです。

つまり、ソフトウェアのセキュリティに関して責任を持てるのは、最終的に企画者と擦り合わせて実装を行ったソフトウェアエンジニアであるあなたしかいないのです。

「N予備校 プログラミングコース」の入門コースにおいては、基本的な脆弱性であるXSS脆弱性、CSRF脆弱性、ユーザー情報管理に関する脆弱性などを、自ら構築したWebサービスに攻撃したり対策したりすることで学んでいます。しかしながら世の中には他にも数多くの脆弱性が存在していますし、突如新たな脆弱性が発見されることもあります。またこれらとソフトウェア独特の業務要件が絡むこともあります。それらに対して問題がないか検証の計画を立て、レビューし、設計的にも要件的にも問題が無いかを確認していく仕事は、実はソフトウェアエンジニアのあなたしかできないことでもあるのです。

プロのエンジニアとしてやるべきことはこのような脆弱性に対しての意識をしっかりと持ち、それを担保するためのアクションを取って、しっかり責任を持つことにあります。

昨今は脆弱性が残されたまま悪意のある攻撃をされ、サービスの正常な運営が難しくなったというWebサービスやスマホアプリの事例もあります。そのような問題が起こってしまわないように、ちゃんとエンジニアとしてプロダクトに対してのセキュリティの責任を持って、開発するべきだと思います。

チーム開発のための心がけ

小さい組織では、エンジニアは自分しかいないということもあるので、チーム開発のための心がけは、必ずしもプロのエンジニアに重要なことにならない可能性もあります。ただ、過去に在籍していたエンジニアや自分の後任として引き継ぎをするエンジニアたちと非同期で仕事をすることも「チーム開発」であると考えると、この心がけが有効になる範囲は非常に広くなるのではないでしょうか。ここにまとめた考えは、チームとして成果を出していくための心がけでもあり、複数人で開発する上で重要なことです。

大きく分けて以下の4つになります。

1. ITツールの活用
2. みんなでチームのノウハウを作る
3. 機械にやらせて楽をする
4. 価値のある成果を毎週必ず届ける

【チーム開発のための心がけ 1】ITツールの活用

想定されるITツールとしては、

• GitHubのようなソーシャルコーディングツール
• Slackのようなチャットツール
• Trelloのようなタスク管理ツール
• G Suiteのようなドキュメントツール
• CircleCIのようなCIツール

以上のようなものがあります。これらを使いこなすということが、チームでの開発の生産性を高めるためにとても重要です。

プロのエンジニアとしてチーム開発するのであれば、これらのITツールを完全に使いこなすことができなければ、2018年に生きるソフトウェアエンジニアとしてはやっていけないでしょう。これらのITツールは、特に開発におけるチーム内外のコミュニケーションコストを低減してくれます。つまり、ツールを活用することで、コミュニケーションが本来集中すべき開発の足かせになるのを防ぐことができるのです。

もし、チームとしてこれらのツールをうまく活用できていないのであれば、チーム全体でそれらを課題として取り扱ってもよいでしょう。

【チーム開発のための心がけ 2】みんなでチームのノウハウを作る

ソースコードしか存在しないプロダクトというのは、メンテナンスしてくれる人がいなくなるとあっという間にチームで利用されなくなってしまいます。

GitHubのREADME.mdやWiki、Googleドキュメントなどでしっかりとソフトウェアのドキュメントを残す開発をしていきましょう。特にWeb業界においては、人材は流動的であり、1年でチームの半分のメンバーが変わるということもあります。ただしプロダクトやツールは1年以上稼働し続けるということはよくあるのです。

そんな時にコードを読むことでしか仕様を理解する方法がないと、コードが間違っているのか、仕様が間違っているのかの判定もつきませんし、そもそも設計意図などを知るための手段がなくなってしまいます。

チームが開発の中で得てきた知見を、資産として組織やチームに蓄えていくためにも、ドキュメンテーションは重要な取り組みといえます。

あとドキュメントを作成する際に重要なことですが、メンテンナンスをしやすいようにしておくというのも重要です。例えばスクリーンショットのような画像が多い場合や、複雑なビルドツールを利用して作るドキュメントは、更新が大変であるためメンテナンスされない可能性があります。このような問題を避けるため、できるだけ単純なテキストやMarkdownなどで書かれたドキュメントの方が、チームの資産としてメンテナンスしやすいものとなるでしょう。

【チーム開発のための心がけ 3】機械にやらせて楽をする

エンジニアなのですから、よくやる単純な作業や確認などはツールで自動化してしまいましょう。

自動化はソフトウェアエンジニアの特権ともいえる能力のひとつだと思います。自動化することによって、その作業を正確に、高速に行うことができるようになります。ただし、そのメリット以上に重要なのが、属人性の排除です。チームで開発を行う場合、特定の作業を専門的に担当するようになってしまうメンバーが生まれることがあります。そのような特定のメンバーにしかできないが作業が存在する状況は大変危険なのです。

特に昔は「ビルド職人」といったような、ビルドに関する特殊技能を持っているメンバーが退職してしまったために、二度とアプリケーションがビルドできなくなってしまったという事件が起こることもありました。退職とまではいかなくても、長期の体調不良などで特定のメンバーが稼働できないような状況はどんなチームでも発生する可能性があります。このようなことを避けるためにも、しっかりと自動化し、さらには自動化ツールがドキュメント化された状態になることは非常に重要です。結果、属人性が排除され、チームが安定してアウトプットを出せるようになります。

ただし自動化に関しても考慮するべきことがあります。自動化することでメリットがある作業かどうかの見極めです。作業によっては柔軟性が要求されるため、手でやった方がよいという場合も存在します。しっかりと判断した上で自動化を行っていきましょう。

また、自動化ツールを作った際には、そのことをチームにちゃんとアピールして、ドキュメンテーションを行い、多くの人に使ってもらうということも大切です。当然のことですが、自動化ツールは自分のものだけに留めておくのではなく、できるだけチームの資産となるようにしていきましょう。

【チーム開発のための心がけ 4】価値のある成果を毎週必ず届ける

これはアジャイルソフトウェア開発というの考え方のひとつで、1日または数日で終わる小さな単位で成果が残るようにして仕事をしていこうという考え方です。組織がその他の開発プロセスを採用しているという場合にも、短期間で考えればこの考え方は、役に立つのではないかと思います。

1. 大きな問題は小さくする
2. 本当に大事なことに集中してそれ以外のことは忘れる
3. ちゃんと成果物を届ける
4. フィードバックを求める
5. 必要とあらば進路をかえる
6. 成果責任を果たす

仕事をしていくうえではこういった考え方が重要です。

大きな問題を小さくして、それに集中し、ちゃんと毎週の区切りで何かしらのアウトプットが出るようにします。例えば3カ月で達成するような長期タスクを誰にも報告しないまま行っていると、自分自身のモチベーションの維持も難しい上に、今やっていることが合っているのか間違っているのか判断しづらいことが多くあります。このようにならないように、小さなゴールを設けしっかりとフィードバックを得ながら仕事を進めていきます。

またマルチタスクでの仕事は非常に効率が悪いものです。ひとつのことに集中して、他の事を忘れ、しっかりひとつのアウトプットを出しましょう。プログラミングは特に高度な集中力が求められる仕事だと思います。そのような仕事に取り組む際には、別の心配事を考えないでよいように、まずはひとつに集中しながら仕事をしていきましょう。

そして最終的に、仕事の依頼者にアウトプットの内容を確認してもらい、そのフィードバックを得て、次の内容をタスクの進め方に反映させていきましょう。

プロとして開発していないのであればもちろん成果責任は発生しません。しかし、プロのエンジニアとしてお金をもらって開発している限りは成果責任が発生します。細かくフィードバックをもらいながら着実に成果責任を果たして行くことが、プロとして働き、チームで評価されるために必要なふるまいとなります。

実はこの考え方は、アジャイルソフトウェア開発における「スクラム」という開発手法になります。これらについてもっと詳しく知りたいという方は、スクラムに関する本を読んでみるとよいでしょう。

まとめ

1. エンジニアとしてのよいふるまい
   1. 自慢する
   2. 褒める
   3. あいさつする
   4. 日々、技術ニュースを取り入れる
2. セキュリティを順守する意識
3. チーム開発のための心がけ
   1. ITツールの活用
   2. みんなでチームのノウハウを作る
   3. 機械にやらせて楽をする
   4. 価値のある成果を毎週必ず届ける

これらが、技術の部分以外でプロのエンジニアに求められる重要なポイントです。これらが欠けているようなことがあれば、組織の中でプロとして期待された役割がなかなか果たせないのではないかと思います。

こういったプロとして必要なことは、実際にやってみてもなかなかうまくいかず、実際には先輩エンジニアなどに指南されながらチームで切磋琢磨して磨いていく部分ではあります。それでも、これらを心に留めておくと、プロのエンジニアとして組織によりいっそう貢献できるようになるでしょう。

著者プロフィール

吉村総一郎（よしむら・そういちろう）@sifue

東京工業大学大学院生命工学科修了。 製造業の製品設計を補助するシステムの開発に携わる。その後、株式会社ドワンゴ入社。ニコニコ生放送の各種ミドルウエアの開発に携わり、ニコニコ生放送の担当セクションマネージャーとしてチームを率いる。2016年よりN高等学校およびN予備校にてプログラミング講師としてプログラミングを教える。
sifue - Soichiro Yoshimura