2017.09.01

今後プログラムを書く能力は必要なくなるのか?

前編:プログラミング不要説の4つの背景

Introduction

こんにちは。trackチームの新田です。
trackという製品は、シンプルに説明すると、オンラインで「プログラミング試験」を作成して出題するツールです。
つまり、ある特定の分野(サーバやインフラ、セキュリティ)における「知識」よりも、与えられた課題に対して必ずプログラムを書いて動かして正解を導くという「実践力」を問うことに重点を充てています。(※)
しかしながら、導入を検討される企業様の中には
「いやいや、これからの時代はプログラムを書く能力よりも、活かす能力のほうが重要でしょ!」と、
お考えの企業様も多くいらっしゃる印象を受けています。
そこで今回は、 「プログラムを書く能力は、これから本当に必要なのか」 について、上記の背景やこれからの時代の考察なども含めて、ご紹介してみようと思います。
まず、こちらの前編の記事では「プログラミング不要説の4つの背景」についてご紹介致します。
※…勿論、いわゆる選択式でITリテラシーや情報技術の知識を問う問題を作成・出題することも可能です。

Contents

1 プログラミング不要説の4つの背景
1.1 1.フレームワークやライブラリ充実によってプログラミングが効率化された
1.2 2.更に人工知能等によって、ソースコード自動生成も進んでいる
1.3 3.機能として独立した外部のシステムを組み合わせる時代(ソフトウェアの同調性の時代)となった
1.4 4.アジャイル型開発の流行により、顧客課題の解決能力やコミュニケーション能力が問われるようになった
2 プログラミングはツールに代替され、プログラミング以外の能力が求められる時代に
2.0.1 関連コンテンツ

プログラミング不要説の4つの背景

そもそもなぜ、「プログラミングは不要になる」と業界で囁かれるようになったのでしょうか。 これには、これからご紹介する主に4つの背景があるのではないかと考えます。

1.フレームワークやライブラリ充実によってプログラミングが効率化された
非エンジニアの方でも「Ruby on Rails(ルビーオンレイルズ)」という言葉は多くの方が聞いたことのあるのではないかと思います。
Ruby on Railsとは、Rubyというプログラミング言語を元に開発されたWebフレームワークのことです。Webフレームワークとは、Web開発に必要な汎用的な機能をひとまとめにした機能群のことです。
このフレームワークを活用することにより、今まで何100行と書いていたコードを、簡単な機能は一行のコマンドで実装ができるようになりました。
また、フレームワークで実装されている標準化されたコードを利用することで、実装する人によるコードの違い(属人性)がなくなり、誰でもある程度同じようなコードでシステムを生成できるようになりました。
料理に例えるならば、「炒飯をつくる粉末」のようなものをイメージしてもらうと良いでしょう。
いちから食材を切って炒めるよりも、卵とご飯を炒めて粉と混ぜるだけで誰でも簡単に同じような味の美味しいチャーハンを作れるようになっているということです。
少し話はそれますが、今もなお多くの会社で利用されているPHPの人気フレームワークCake(ケーク)PHPというフレームワークでは、このコマンドをBake(ベイク)コマンドといって「勝手に焼いて料理するよ」という洒落たコマンド名になっていたります。
(エンジニアの方へ:CakePHPなんて全然もう人気じゃねーから!という論争はこの記事では論点ではないので悪しからず。m(_ _)m)

2.更に人工知能等によって、ソースコード自動生成も進んでいる
以前の記事(実務に繋がる開発力を適切に見極めるためのプログラミング問題に設けると良い3つの要素
)でも紹介しましたが、エンジニアの仕事の中で「調べる」という作業はつきものです。
普段様々なツールを扱う中で、思ったように動かない場合、解決策をみつけるためにインターネット上に公開されている沢山の解決方法を模索し、ソースコードを参照します。
それに対して、マイクロソフトがケンブリッジ大学の研究者らと協力し、「仕様通りに動くコード」を自動生成するシステム「DeepCoder※」を開発していることを発表しました。
これにより、なんだか上手く動かないシステムの穴を勝手に人工知能が埋めてくれることで、エンジニアのコードを書く、編集するという多くの作業が不要になるのではないかと期待されています。
もしこれが普及すれば、バグの発見や解決方法はAIが提示してくれるようになるので、大幅にエンジニアの作業負荷が変わることでしょう。
※…DeepCoderに関する紹介記事は以下を参照。
DeepCoder builds programs using code it finds lying around

3.機能として独立した外部のシステムを組み合わせる時代(ソフトウェアの同調性の時代)となった
IT業界で働かれている方であれば、API(エーピーアイ)やAPI公開、という言葉も良く聞き慣れた言葉なのではないかと思います。
APIとは、 アプリケーションプログラミングインターフェイスの略です。アプリケーションをプログラミングするための「入り口」のようなものです。
Webサービス間で機能やデータを利用するのためのAPIの事をWeb APIといいます。
APIの概念は少し難しいかもしれないので、またまた先ほどと同じく料理で例えましょう。「Web APIを活用する」とは、炒飯を作る上での一部の作業工程・調理器具・食材を外部に委託して活用することです。
もし本格的な美味しいチャーハンを作るには、先ほどの炒飯の粉だけでは不十分です。なぜなら、炒飯は強力な火力とスピードが命だからです。この強火を実現できるコンロと強火の中でスピーディに炒飯を炒める中華鍋を自宅で用意するのは、少しコストが高いですよね。
そこで「本格炒飯炒めAPI」を活用します。その入口をくぐると、そこには渡した具材を超強火で炒めてくれるシェフ、中華鍋、コンロが用意されており、具材を渡すだけで美味しい炒飯に仕上げて自宅に返してくれるわけです。
すみません、だいぶ話が炒飯に寄り過ぎました。
身の回りの体験では、ログイン機能が一番わかり易い例かもしれません。 皆様が普段利用しているサービスの中で、「FacebookやTwitterアカウントで登録する」という登録画面を見たことがあると思います。ボタンをクリックすると、「連携しますか?」というような認証画面が表示されて、許可をすると、そのサービス単体でメールアドレス、アイコン画像、ユーザ名等をイチイチ登録しなくても、勝手にユーザアカウントを作ることができると思います。
これは、各種SNSが公開しているWeb APIを活用することによって、サービス独自でアカウント登録作業を行わなくても、SNS登録情報をそのまま利用することができているのです。
このWeb APIの充実により、様々な外部サービスと簡単に連携ができるになり、新しいサービスは作るものではなく「組み合わせるもの」になりつつあります。
この組み合わせてソフトウェアを開発することをMashup(マッシュアップ)と呼び、ウェブ上に公開されている情報を加工、編集することで新たなサービスとすることです。
ハッカソンなど、時間の限られた中で製品を開発する際に、「XX情報は◯◯APIをマッシュアップして取得し〜」 という説明は、いわゆるこの事です。
一からプログラムを書くよりも、より本格的な機能として外部サービスと連携することが当たり前になっています。

4.アジャイル型開発の流行により、顧客課題の解決能力やコミュニケーション能力が問われるようになった
最後に、ここまでご紹介をしてきた技術の進化だけではなく「開発プロセスの変化」もプログラミング不要説に影響を与えているのではないかと思います。
従来のソフトウェア開発は「ウォーターフォール型」という開発手法でしたが、これが近年多くの現場で「アジャイル型」が導入されるようになりました。
どちらのソフトウェア開発プロセスも言葉は聞いたことがあるかと思いますので、細かい補足は省きますが、これらの二つの開発プロセスの概念の違いとしては

というような要素があげられます。 アジャイル型の開発プロセスは

「不確実なもの(マーケット・ビジネス環境)にどのように対応をするか」
「失敗のリスクをどのように低減するか」
という課題に取り組む上で改善されてきた開発手法と言われています。
そのため、初期段階で要求を仕様として細かく定義することや、緻密に開発をしていくことから、より顧客と寄り添い、柔軟性をもって開発していくプロセスが主流になりつつあります。
そのためには「コミュニケーション能力」がエンジニアにも求められてきており、このような開発プロセスの中では、単にプログラムを書くこと、だけがエンジニアにとって必要なスキルではなくなってきているということがいえるでしょう。

プログラミングはツールに代替され、プログラミング以外の能力が求められる時代に

ご紹介させていただいたように「これまでのプログラミングを書く能力」をもっていなくてもそれらはツールに代替されるようになってきましたし、「プログラミング以外の能力」が必要になってきました。
これらの背景から、プログラミング力における必要性が徐々に軽視されつつあるのは事実であると言えるでしょう。
しかしながら、では本当に「プログラミング力は不要」になるのでしょうか。
後編の記事では「プログラミング能力は本当に必要なのか」について、具体的に考察をご紹介していきたいと思います。

◾Speaker情報
LINE株式会社 Data Labs/ Clovaセンター Clova開発室 マネージャー
橋本 泰一 様
(写真右)

株式会社ギブリー 取締役
新田 章太
(写真左)

◾️イベントレポート概要

オンラインでプログラミングスキルチェックを行うサービス「track(トラック)」などを展開するギブリーは、2018年3月24日、東京・千代田区で開催された国内最大級のエンジニア向けの技術祭典「MANABIYA TERATAIL DEVELOPER DAYS」にて、エンジニア採用課題解決についての講演を行いました。壇上にLINE株式会社の橋本泰一氏を迎え、エンジニア新卒採用における同社の取り組みを紹介しました。本記事では、その模様をレポートします。

エンジニアが主導する採用変革

従来のエンジニア採用では、書類選考、面接を経て技術面接を実施しており、選考が終盤に差し掛かる中で技術のミスマッチが発覚することもありました。そのミスマッチを解消するため、人事ではなくエンジニアが主導で行う「ダイレクトリクルーティング」と呼ばれる選考手法が、特にITベンチャー系企業を中心に増加していると弊社の新田が解説しました。

「ダイレクトリクルーティング」の大きな特徴は、現場のエンジニアが面接の場で直接学生と話をしたり、選考の最初の段階で技術選考を実施するなど、技術面のマッチングを成功させるためにエンジニアが積極的に選考に関わる点です。スキルマッチングを見極めた後に自社の魅力付けの役割を人事が担うケースもあります。

エンジニア採用を成功させるためには従来の「パーソナリティマッチ」よりも「スキルマッチ」をまず考えることの重要性について解説し、スキル判定に伴うエンジニアリソースの工数増加に対してはオンラインツールなどを駆使した効率化が有効であることも取り上げました。 また、少ない母集団を拡大する方法として場所や時間を問わずに参加できるオンラインハッカソンの開催や、採用対象を新卒のみならず大学を卒業した就業未経験者にまで広げて募集する取り組みについても触れました。

選考参加学生の10%~20%が再受験する、LINE社社独自の技術選考「Re:Challenge」制度とは?

講演の中で、エンジニア採用において数々の新たな取り組みを導入しているLINE株式会社の採用施策を紹介しました。LINEでは選考フローにおいてまず技術選考を行い、エンジニア面接、技術役員の面接を経て内定となる「スキルマッチファースト」の採用を実践しています。技術テストはオンラインにより国内3拠点ですべて同じ内容、同じレベルで実施しているといいます。

LINEが2018卒の新卒採用から取り入れている画期的な試みとして「Re:Challenge」制度があります。技術テストで一度不合格になっても再度の挑戦を認める制度であり、再挑戦を経て内定に至る学生もいるといいます。「Re:Challenge」制度を設立した理由についてLINEの橋本氏は次のように語っています。

「高校受験や大学受験は一発勝負ですが、模試のような疑似体験の機会があります。就活にはそのようなトレーニングが整っておらず、一回の試験で上手く力を発揮できなかった優秀な人材を取り逃がしていることが多いんじゃないかと考えていました。またLINEの選考を受けて不合格になった人の中には『自分の勉強が足りなくて、本当はLINEに入りたかったけど諦めます』という人もいましたが、そういう人たちが半年間勉強したら僕たちが求める人材になって、一年後活躍してくれる可能性もあるわけですよね。そういう人たちを一回のテストだけで判断するのはもったいないと思い、この『Re:Challenge』という仕組みを作りました」(橋本氏)

「エンジニアが就職活動の準備として模試のようにチャレンジできるような場所を目指しているのでしょうか?」という新田からの質問に対し、橋本氏は次のように答えました。

「何度もチャレンジできるので、就活の最初にまずLINEを受けてくれればいいかなと思っています。LINEのテストを通じて、ITやインターネットのサービスを行なっている会社がどういうスキルを求めているのか、何をチェックしているのかを知ってもらい、就活に望んでもらえればいいなと思います」(橋本氏)

「Re:Challenge」制度を活用して同社を再受験する学生は全体の10%〜20%(最近のテストでは再受験率40%)ほど。受験によって自分の不得意な箇所を認識し、次回の挑戦に向けた学習に生かしているといいます。候補者のスクリーニングを行うのみならず学生にエンジニアとしての成長を促し、結果として母集団の量と質を確保することにも繋がる施策であるという印象を受けました。

実務に求められる技術や、思考プロセスを見抜くための問題の作り方とは?

「Re:Challenge」制度などのLINEの取り組みは画期的なものですが、テスト結果の管理や問題作成の工数など負担も大きくなることが懸念されます。LINEはこの課題を「track(トラック)」(旧:codecheck {コードチェック}) により解決しています。trackはプログラミングテストの作成・配信・受験・採点・評価をワンストップで実現するオンラインツールで、自動採点機能も備えています。
自社オリジナルの問題作成も可能であり、LINEも独自の問題を多数出題しています。
オリジナル問題はどのような方針で作成しているのか、橋本氏は次のように語っています。

「もっとも気に入っているのは暗号の問題なんですけど、問題に提示されている情報だけでは答えが導き出せない。なのである程度予測をしたり決め打ったりしなければならないという問題になっています。答えのない問題に対してどう攻めていくのかというところを見たいなと思って作った問題です。実際のビジネスで開発をやる時には答えはないし、どういう解き方をしてもいい。こうやった方がいいんじゃないかという取り組みを色々考えてトライしていくことが重要なので、チャレンジしていくマインドがあるかということを見ています」(橋本氏)

LINEのオンラインテストではインターネットで情報を検索することも認められており、インターネット上で見つけたソースコードをコピー&ペーストして回答しても問題ないといいます。その理由について橋本氏は次のように述べています。

「今の時代、頭の中の知識だけを元に開発するわけではなく、インターネット上の知識もフル活用して開発していくのが現場で求められていることだと思うので、テストの環境についてもそれに近い状態にしています」(橋本氏)

実務に求められる技術や思考プロセスを選考に落とし込むことでスキルのマッチングを実現する手法は、今後のエンジニア採用における重要な鍵となるのではないでしょうか。

これからのエンジニア採用に求められることは

最後は、これからのエンジニア新卒採用における企業側の心がけについての話で締めくくられました。橋本氏はなるべく若いうちからエンジニアが実務に取り組むことの重要性を主張。インターンなど若いエンジニアの就業機会をより広げることが重要であると語りました。

新田はギブリーが主催する学生向けハッカソンなどでの経験から、勉強している内容と実務との結び付きがイメージできていない学生がいることを挙げ、それを実現するための場が少ないことを指摘。企業側が学生エンジニアのアウトプットの場を積極的に設けることで、優秀な能力を持った人材の発掘に繋がるのではないかと述べました。

この記事をシェアする

  • Writer
  • AgileHR magazine編集部
  • エンジニアと人事が共に手を取り合ってHRを考える文化を作りたい。その為のきっかけやヒントとなる発信し続けて新しい価値を創出すべく、日々コンテンツづくりに邁進している。

関連記事

AgileHRが開催する
エンジニアHRに特化した
トークイベント

Agile HR

# タグから探す

-