これからアプリケーションエンジニア(プログラマ) になるための準備

この記事は、株式会社TORICO Advent Calendar 2021 12/21 の記事です。

他社の方と話をした際、お子さんがアプリケーションエンジニアに興味があるという話を聞いたので、これからアプリケーションエンジニアになる人に向けての記事を書こうと思いました。

この記事の中にはエンジニアという言葉が何度も出てきますが、機械・工学のエンジニアのことではなく、コードを書いて機械を自動的に動かす人のことです。区別するために、なるべくアプリケーションエンジニアという表現をするようにしています。

アプリケーションエンジニア(プログラマ)とはどんな仕事か

エンジニアの業態は、大きく分けて、自社開発と受託開発があります。

自社開発とは

サービスの提供と開発を同じ会社で行っている場合がこのケースに当てはまります。社会人経験の少ない方は、おそらくサービス提供会社がアプリケーション開発も行っている印象を持たれる方は多いかもしれませんが、売上を上げるサービスをすべて自社開発している会社は、みなさんが考えているよりずっと少ないです。

サービスを自社で開発する会社は、企画を実現させるための工程が少ないため、スピード感のあるサービス開発が行えます。トライアル&エラーの手数も多く、開発技術がサービスに強く反映されます。

会社規模によっては十分なエンジニアチームが作れていない場合もあり、エンジニア人数が少ない場合、知識・技術に偏りが出たり新技術をうまく採用できていない場合があるため、求人応募する際は十分にチーム構成を調べたほうが良いでしょう。最新技術を十分に取り込んでいても、自分の求める開発チームの理想形とマッチしていない場合もあります。会社の技術ブログを見て自分にマッチしているかは事前によく調べておいてください。

会社の中の開発チームは、単純なプログラミング以外でも技術全般を広く担当する場合が多いため、ユーザー行動の解析だったり業務会計データの集計・整形だったり、社内LANの構築やグループウェアのメンテナンス、デザインや動画編集なども頼まれる場合があります。会社規模が小さいほど広い担当範囲を求められます。

そもそも自社開発の場合、会社組織がエンジニアに求めることが、「プログラムを書く」ではなく「業務課題に対して技術で貢献する」である場合が多いです。会社によると思いますが、私が今まで経験した会社はすべてそうでした。仕事をする上で、「プログラムを書く」かどうかはあまり関係無く、「新しいサービスをできるだけ多くのお客様に使ってほしい」といった業務課題があり、エンジニアはサービスの実態を作ることができるのでその分野で貢献します。ただ作るだけではなく、他メンバーとゴールやKPIを共有し、どうすれば合理的にその目標を達成できるか考えながら仕事をしていきます。

そのため、自社開発のエンジニアはビジネス的な観点も必要とされますし、ビジネス成果がエンジニアの評価とされる場合も多くあります。自分が書いたコードがお客様や会社の売上に直接影響することを実感できますし、誤って不具合を含んだコードをリリースしてしまった際は、お客様や他のメンバーから辛辣な苦情を受けることになります。

求人応募者にはエンジニアとしての即戦力を求めるため、受託開発より基準は高くなると思います。採用面接時には技術的な質問を多くされ、即戦力でなさそうだったり、業務水準に達するまでの成長時間が長くかかりそうだと判断されれば採用見送りとなります。中途採用の場合は、未経験だと採用は厳しいでしょう。未経験の場合は、業務以外の開発成果(ブログ・ポートフォリオサイト・オープンソースライブラリへの貢献等) を積極的に伝えると良いでしょう。

受託開発とは

受託開発とは、アプリケーション開発をする専門の会社(システムインテグレーター・SIer) が、開発機能を持たない会社からアプリケーション開発を依頼され、その依頼に従ってアプリケーションを作り、納品することをいいます。

開発を依頼する際に、どういったものを作ってほしいかを契約書で取り決め、受託開発会社はその契約を満たすものを作ることを最終ゴールとします。開発物がどれほどのビジネスインパクトを発揮するかは考慮する必要は無く、指示されたものを忠実に作ります。早く納品することが一番の価値となります。

場合によっては、アプリケーションサービス提供会社(発注者)が得た売上成果の一部を開発会社の売上とする「レベニューシェア」という形態を取る場合があります。ゲームなど、開発技術が売上に直結するようなものだったり、継続的な機能追加が必要なものはレベニューシェアとなる場合が多いです。レベニューシェアの場合、開発会社の責任領域がサービス売上にも及ぶため、完全な受託開発より開発の意見・提案が影響力を持つようになります。

現代のアプリケーションソフトウェアは複雑なため、開発依頼時点で開発物の仕様が十分に決まっている場合は多くありません。大抵は、正常に動作するいくつかのパターンの仕様のみが決められており、特殊なケースは考慮されてない場合も多いため、都度依頼者に確認するなどの対応をする必要がります。その際に新たな機能が必要なことが判明し、開発工期の再見積もりが必要になってしまうのはよくある話です。

これは依頼者の考慮不足といえばそうなのですが、現代のアプリケーションを仕様書で完璧に組み上げることは不可能です。完璧を目指せば、それはプログラムコードと同じものになるので、人に依頼するよりコードを書いたほうが早いってなります。

開発依頼時点で開発物の仕様が十分に決まっていない理由としては、「最終目標に破綻の無いように、詳細な動作仕様を決める」というところまで、依頼内容に含むと考えていることも多いです。どこまでを誰が考えるか、あいまいなまま開発を進めてしまうと、問題が発生した時に責任問題となりますので、契約時の段階でアプリケーションサービス提供の内容をお互いにしっかり合意しておく必要があります。…が、現代のプログラムは契約書で責任分掌がはっきりできるほど単純なものではないので、けっこう揉めることは多いです。大きなコミュニケーション能力が必要とされます。

会社によるかもしれませんが、求人応募者に対してそれほど技術的な点を深く求める会社は多くないように思います。開発未経験でも学歴を見て採用が決まる場合は多いと感じます。

受託開発会社は、社員がほぼエンジニアで構成されるため、知識が共有しやすく、能力による給与評価や昇格も制度が固まっていて、フラットに行われやすいように思います。

自社開発・受託開発 どちらが良いか

個人的には、断然自社開発をおすすめします。業務課題を社内のチームで共有し、みんなで解決策を考え、開発したサービスが顧客体験に直接影響し、会社の売上につながっていく様子を間近で見れることは、エンジニアにとって大きなモチベーションとなります。これこそが、開発をしていて楽しいと思う瞬間です。

ただし、会社によっては開発チームの技術が停滞していたり、経営層が開発チームに十分なコストを投資しない場合があり、そのような会社で開発者を続けていくのはかけがえのない人生を棒に振ることになりますので、十分考慮して判断するようにしてください。

アプリケーション(プログラム)開発とは何か

新しい価値の提供

今まで全く存在しなかった価値を、エンジニアは作り出すことができます。ゲームによるエンターテイメント体験、SNSによる承認欲求の充足、動画投稿サイトでの顧客間での放送、動画ミーティング、顧客間での商取引サービス…昨今台頭した強い新体験を持つサービスは、アプリケーションエンジニアリングの賜物です。これらのサービスは、スマートフォンやPCなどあればどこでも利用できるため、使用者は金銭的にも時間的にも、心理的にも安価に体験を得ることができます。スマートフォン含め、最近の情報機器もサービスも、どこかの会社のエンジニアとボランティアのエンジニアの協力により成り立っています。

雇用コストの削減

例えばECサイトで商品を販売することで利益を上げている会社の場合、接客・商品の販売・代金の回収 すべをプログラムで処理します。おそらく、商品の在庫管理、発注、会計処理などもプログラムが行っています。このプログラムは、会社の業務フローそのものです。エンジニアは、この「会社の業務フローそのもの」をメンテナンスする仕事です。

現代の業務フローは、大量のデータをルールに沿って自動的に処理するために、プログラムによる自動化が必須です。自動処理を構築しない場合、その分余計な人件費がかかることになります。

雇用の賃金が上がり、労働の自由度が増すことで労働者が働きやすくなるほど、経営者は人を雇いにくくなります。また、情報処理はより複雑化しながらも、PCは高性能化し利便性が高くなったことで、知識が乏しい人が誤った情報の使い方をした場合、指先ひとつで会社を終わらせるような情報漏洩被害に発展する場合も考えられます。日々、それを誘発するような攻撃を仕掛け続けている人もたくさんいます。現代において、人を雇用するというのは大きなコストとリスクを負うことになります。

会社にとって、同じ経常利益を上げるとしたら、人は少ないほうが絶対に有利です。人が行う処理をプログラムにすることで、雇用という大きなコストとリスクを回避できます。
プログラム開発者は、人が行っている業務フローを自動化し、人がいなくても(採用しなくても)機械を使うことで自動的に大量の情報処理ができる組織を構築することができます。
究極的には、人的労働力をほぼかけずに商品を販売し続けるサービスを、全業種の中で唯一エンジニアは作ることができます。

コンビニは、店舗のマネージャーが業務フローマニュアルを使ってアルバイトの店員をマネジメントすることで商品を販売します。ECサイトの開発者は、人を使わず機械をマネジメントすることで、商品を販売します。そのマネジメントするための業務フローを記述したものが、プログラムというわけです。

今後の雇用情勢

エンジニアは、雇用する人数を減らすことのできる唯一の職種といえます。現在、色々な会社で業務フローは高度にプログラムにより自動化されていってます。エンジニアは業務フローを自動化でき、雇用を削減できる職種として、会社経営者から強く求められており、人類の理想とするAIが誕生するまでこの情勢は変わらないと考えます。プログラム開発を仕事にして、前線を走り続けることで、仕事に困ることは無いでしょう。

開発者の担当領域による分類

ゲーム開発者

現代では、Unity や Unreal Engine 等ゲームエンジンを使ってゲームを開発する人です。
私は専門外なので割愛します。

組み込み/IoT エンジニア

家電や自動車制御プロセッサ、自動販売機、デジタル看板、ルーターやLANハブなどのプログラムを開発する人です。
基本は C++ や Java だと思いますが、最近は開発環境の進歩により、 C#, JavaScript, Python などでも開発できます。
私は専門外なので割愛します。

Webアプリケーションエンジニア

ネットワークを介して処理をするアプリケーションを作るエンジニアです。
基本的にはブラウザ上で動くアプリケーションを作ります。

現代は様々なものがネットワークにつながるようになっており、家電もネットにつながったりしますし、スマホにインストールするモバイルアプリも大抵はネットワークを介してサーバと通信することで機能を提供します。そのサーバサイドを作るエンジニアでもあります。

アプリケーションエンジニアになるには

まず、全くの未経験であれば、教則サイト ( Progate, PyQ 等) の有料会員になって、最後まで進めましょう。最初はモチベーションが上がらずに、苦痛を感じるかもしれませんが、最後まですすめてください。教則サイトは誰にでもわかるように一つ一つ丁寧に教えてくれます。もし、教則サイトで知識的に躓くようであれば、エンジニアに向いてないように思います。幼稚すぎてだるい、と感じるようであればちょうど良いです。

10年前であれば、有名な本を買ってそこから学ぶのが効果的だったと思いますが、今は親切丁寧に解説してくれる教則サイトがいくつもサービスされていますので、便利に使いましょう。

教則サイトを一通り終わらせることができれば、おそらくプログラムとは何なのかが体感できたはずです。次は、自分の生活の中で困ったことを開発で解決させてください。

例えば、PCを使っている時に、自動的にフォルダ内の全ファイルをリネームしたいとか。ネット上に散らばっている画像を自動的に収集したいとか。クリップボードにコピーした文字列を自動的に整形してどこかに共有したいとか。自分の所属するサークルやクラブのための情報共有ツールを作りたいとか、スコアを統計したいとか。まわりを見渡すと、アプリケーションエンジニアリングで解決できそうなことが山ほどあるはずです。

ひとつづつ、手をつけていきましょう。おそらく、なんとなくロジックはわかるけどどういうプラットフォーム上でプログラムを動かしたらいいかわからない、という状態になるのでは無いでしょうか。

テキスト処理や計算処理をするだけなら、HTML + JavaScript だけで解決できる場合もあります。

計算するだけなら、 Google Colaboratory で十分かもしれません。

スプレッドシートやメールを自動処理するなら、Google Apps Script が良いでしょう。

Mac でファイルに対して自動処理を処理したいなら、ターミナルで動くテキストベースのアプリケーションスクリプトを書きましょう。最初は Python か Node.js がおすすめです。

Apple や Google の App Store に並んでいるような綺麗でかっこいいアプリを作る必要はありません。まずは、自分の身の回りのことを、自分でコードを書いて自動化していってください。技術がついていかず、途中で開発が詰まることはよくあると思いますが、考えてもわからないものは一旦放置して、別の問題を解決するコードを書いてください。

できたコードは Github に プライベートリポジトリにして保存しておきましょう。もし、公開してもセキュリティ的に絶対大丈夫だと自信があるものだけ、パブリックリポジトリにして上げてください。

多くのコードを自分で書かなければいけないわけではありません。誰かが作ってくれている、素晴らしく便利なものをうまく組み合わせて、自分の課題を楽に解決してください。会社内のエンジニアの仕事というのは、いつもこの延長です。有料のサービスも、無理のない範囲でどんどん使いましょう。機械的な動きや計測が求められるラズベリーパイやスイッチボットなども買って使ってみましょう。

慣れてきたら、Webサイトを作成しサービスしてください。最初は自分のポートフォリオやブログ だったり、自分の趣味研究の成果の公開、またはサークル・クラブのサイトを作るのが、モチベーションを高く保てて良いと思います。ログイン機能を提供するなど個人情報を扱う場合は十分注意し、絶対に自作はせず、認証サービス ( Firebase, Cognito, Auth0等 )を使うか Webアプリケーションフレームワーク(Django, Rails, Laravel等) を必ず使うようにしてください。

あとは、自分の思想とあっている会社を見つけて採用応募し、「自分が今までどういったことを自動化してきたのか」を丁寧に説明してください。その自動化の成果や方針が会社の思想とマッチしていれば、会社組織の一員として安定したエンジニアリング人生をやっていけます。

フリーランスでやっていくのは、他のエンジニアと良好な人間関係を構築するのにひとつ壁があるため、あまりおすすめしません。ビジネスに共感を持った会社の、正社員として採用されることが、エンジニアとしての人生を豊かにすると、私は考えています。

アプリケーションエンジニアとして生きること

アプリケーションエンジニアは、人間の職業のひとつの極限だと感じています。アスリート、漫画家、数学者、棋士、芸術家などと同様に、「十分な域に達するには一生分の時間では到底足りない」職業です。課題や習得することは無数にあり、一生…60年ほどを使っても、全ノウハウの1%も習得できないでしょう。そのため、自分に合ったスタイルを取捨選択し、日々自分の技術を磨き続ける人生になります。毎日が新しい挑戦の連続で、毎日限界まで頭脳を使い、自分の能力の低さを痛感し、何度も停滞し、何度も失敗します。しかし課題解決をした時のリターンが予想しやすく、かつ経済的な価値が大きいものである場合が多いため、他の業種より安定した生活が継続してできるでしょう。

エンジニアが新しい価値を作り、何かを自動化するということは、おそらくその時点で既存のビジネス(業務) の価値を下げ、いくらかの人への報酬を奪うことになり、エンジニアリングをする人としない人で格差ができます。その社会は20世紀後半から既に始まっています。

もし、あなたがアプリケーションエンジニアになろうと思っているのであれば、先輩として応援します。アプリ開発はめちゃめちゃ面白い上に、人から必要とされます。自分では、今まで開発者をやってきてよかったと思いますし、あなたも10年後、間違いなくそう思います。

特にここ40年は、電子計算が飛躍的に向上し、インターネットが一般化した、人間史の中で一番面白い時期であることは間違いありません。そしてこれからも、量子計算の一般化やシンギュラリティ、人工生命の誕生など従来の人間の価値観が覆るイベントが目白押しです。その転換期に立ち会えることができてよかったと思っています。

Currently unrated

コメント

コメントを投稿
コメントするには TORICO-ID にログインしてください。
ログイン コメント利用規約