朝日新聞社に技術職入社した理系修士卒が、半年間でできるようになったこと【第2回】
ICTRADに所属する１年目の倉井と申します。このエントリは「朝日新聞に技術職入社した理系修士卒が、半年間でできるようになったこと」の第２回です。
今回は、私が入社した後、５月から８月にかけて取り組んだ技術者研修の中から、特に勉強になった・役に立った要素について、前回に引き続いて紹介していきます。
（※学生向けに執筆しております。）
まずはインフラを学ぼう！
皆さんは１からWebサービスを開発しようと思った時に、何から始めますか？
もちろん、コンテンツそのものをしっかりと作り込むことも大切ですが、各ユーザのアクセスに応じて正しいレスポンスを返すというサービスの根本を提供するには、いわゆる「インフラ」をしっかりと整える必要があります。
「でも、サーバとか立てたことないし、そもそも何が必要なのかわからない」
「サービスは作ってみたいけど、セキュリティ対応とか大変そう」
という方、実は多いのではないでしょうか。
安心してください、あのAmazonが便利なサービス群を提供してくれています。
それが、Amazon Web Service（AWS）です。
AWSはクラウドプラットフォームの一つです。
クラウドプラットフォームとは、アプリケーションの実行やデータの保存などが行えるシステム基盤をWeb上で展開しているサービスのことです。簡単に言えば、アプリケーションを開発・リリースしたい時にこのサービスを利用すれば、物理的なサーバを用意することなく、Webベースで簡単にシステムを構築できてしまうということです。
AWS以外には、GoogleのGoogle Cloud PlatformやMicrosoftのMicrosoft Azureなどがあります。
それぞれの会社によって特徴や機能が異なっていますが、Webサービスをより簡単に作成可能にするための、多くの便利なサービス群を提供している点は共通しています。
以下に、研修で実際に扱ったサービスについて、名前だけ列挙します。
興味の湧いた方は、ぜひそれぞれのサービスについて調べてみてください。
EC2、RDS、Route53、ELB、VPC、S3、IAM、CloudFront、CloudFormation、CloudWatch、Certificate Manager、Lambda、Comprehend、Cloud9、ECR、ECS、等々
研修ではこれらのサービスの使い方や概念を理解するために、研修チームの監修の元、AWSの提供する資料をベースにしたチュートリアルをこなしていきました。
また、このあと説明する「記事管理システム作成実習」はAWSで作成した仮想サーバをベースに行いました。
実習形式で、自分達でググりながらサービスの構築を行ったので、AWSに関する知識も自然と身につけることができました。
研修段階でAWSに触れたことのある同期はいませんでしたが、現在は実際の業務で利用している人も多いです。私も業務と個人開発とでAWSを利用していますが、自身で物理的なサーバを用意することなく簡単にWebサービスの開発が行えるので、非常に重宝しています。ちなみに、個人開発では、EC2とRDS、Route53等を活用し、Webサイトを作成しました。
現在はインフラがサーバレスなスマホアプリも鋭意作成中です！
個人利用の範囲では無料枠が用意されていることが多いので、ぜひ調べてみてください。無料枠を利用して、色々なサービスを作ってみましょう！
知っておきたい！プログラムのバージョン管理
チーム開発には必須の存在とも言える、バージョン管理ソフトウェア「Git」の研修も非常にためになりました。
Gitについては、GithubやGitlab等々で名前は聞いたことがあるという方が多いのではないでしょうか。
私も修士時代、先行研究を漁っている時に、幾度もGithubのお世話になっていましたが、Gitそのものの勉強はしていませんでした（した方が良いと個人的に思います）。
学生の読者の方にはわかってもらえるかも知れませんが、大学の研究は個人単位で開発をすることが多く、また過程よりも結果が重視される傾向にあります。このため、研究の中身の計算を行っているプログラムについては、きちんと管理をしている人は少ないのではないでしょうか。
私個人も、行き当たりばったりで研究のコードを書いていたので、
「前のバージョンに戻したいけど、バックアップとってなかった〜」
ということが結構ありました。
そんなときに、もってこいなのが「Git」です。
上述のGithubやGitlabのようにGitを冠するサービスは複数ありますが、共通しているGit全般の仕組みについて紹介したいと思います。
Gitは分散型バージョン管理システムと呼ばれるものの一つです。
この「分散」の意味するところは、プロジェクト（PJ）に参画するメンバーがそれぞれの手元（ローカル）にPJ全体のプログラムフォルダ（リポジトリ）をもつところにあります。
そうして、参画している開発者の数だけローカルのリポジトリが分散され、各メンバーが必要に応じて大元のリポジトリ（リモート）の状態の参照や更新を行うことで、PJ開発を進めていくことができます。
わかりやすく言い換えると、それぞれの開発者ごとにプログラムフォルダを手元に保存し、その状態を大元の別フォルダと適切なタイミングで連携させながら開発を進めることで、参加者間でプログラムの変更が大きくバッティングすることなく開発が行えるということです。
Gitをつかうことで、リモートリポジトリにアクセスできない場合でもローカルでの開発が行えます。また、運用中のリポジトリからの機能の追加実装や、突然のエラー対応がしやすくなります。
個人で開発を行っている場合にもGitを使うことによる恩恵は大きいと思います。例えば、プログラムの変更履歴を残すことができるので、昔のバージョンに簡単に戻すことができます。
またGithubを利用すれば、オンライン上にリモートリポジトリを作成することができるので、別のPCへのプログラムの移植が容易になります。
研究時代にこれを活用にしていなかったために、ソースコードの移植に手間取った記憶があります。
個人利用でもおすすめをいたしましたが、Gitの強みは複数人で開発している時に味わえると思いますので、興味があれば勉強してみてもいいかもしれません。
記事管理システムの作成
研修の目玉とも言える「記事管理システム作成」について、いよいよお話ししたいと思います。
この実習はズバリ、朝日新聞デジタルをまるまる作ってみることが目標です。
一般のユーザにとってはたくさんの記事の読めるWebサイト、管理者ユーザにはそこに公開する記事の追加や修正、公開設定が行えるWebサービスのシステム全体を、自分たちでつくってみようという実習になります。
サーバの立ち上げからサービスのリリースまでを体験できることから「システム構築実習」と呼ばれていたので、以下ではそのように呼びたいと思います。また、ここまで用語解説のような説明ばかりになってしまいましたが、説明した要素技術のほとんどを活用した実習が、このシステム構築実習です。
システム構築実習で作成する記事管理システムの要件は、次の通りです。
①. 一般または管理者ユーザとしてのログイン機能
②. 管理者機能として記事の執筆、編集、削除、タグ付け、一覧表示、公開設定、トップ記事の選択が可能
③. 記事には画像を添付可能でAWSのS3に保存
④. 一般ユーザ用のニュースサイト画面を用意し、トップ画面、記事詳細、ジャンル別記事ページを用意
⑤. データベース（DB）のバックアップを30分ごとに自動生成
⑥. システムの健全状態を10分ごとにチェックし、メールで結果を送信
⑦. セキュリティチェックソフトによる警告を極力低減する
⑧. 記事をrestfulAPIとして受け渡せる
⑨. EC2サーバの環境としてはLAMP（Linux、Apache、MySQL、PHPの頭文字）を採用、DBにはRDSを用い、フロントはFuelPHPで開発する
⑩. ソースコードはGitLabで管理
この仕様に沿ったシステムを、２人または３人のグループに別れ、のべ２ヶ月程度をかけ作成します。
実習の最後には、研修チームと技術系の新人全員で作成したシステムのレビューを行い、意見や評価を受けます。
各要素技術については一度研修チームより研修を受けますが、実際の開発に入るとわからないことだらけなので、ググって実装が基本になります。
また個々人の判断で、面白そうな技術を活用した追加機能を実装するのもOKです。
スケジュール管理も自分たちで
開発はウォーターフォールモデルと呼ばれる開発形態で行われます。
この手法では、開発を要件定義、詳細設計、実装、テストなどの工程にわけて実装を行います。
開発の手順を一歩ずつ着実に進めていく手法で、現在の工程の目標や現状の達成度が明確な分、大規模な開発をする際に有効です。
またチーム開発ということもあり、最初にWBSと呼ばれるタスクの一覧表をメンバー全員で作成します。WBSはWork Breakdown Structureの略で、タスクを細分化した一覧表のことです。
タスクは親タスクが子タスクを内包するように構造的に作成します。
例えば、ログイン機能を作るという親タスクを設定したら、その実現に必要な要素（例えばDBとの連携機能の実装やログインフォームの作成など）を子タスクとして書き出していきます。
そして、それぞれの子タスクに要するであろう時間と担当メンバーを割り当てていきます。
こうすることで、システム全体の実装に要する期間を見積り、納期に合わせた開発が行えるように作業計画を立てることができます。
開発が実際に始まったら、作業終わりにその日の作業進捗をWBSに記録していきます。
こうすることで、予定と実際の状況の齟齬や問題点をチームで共有し、人的リソースの再配置や実装機能の見直しを行う際の判断材料とすることができます。
WBSを最初に作成する際に気をつけなくていけないのが、システムの要件定義やシステムテスト作業の工数もきちんと計算にいれてスケジューリングをしなくてはならないということです。
システムテストでは、システム全体が連携し問題なく機能するようにチェックを行う必要があります。
これを実現するには、最初に考えている以上にチェック項目が膨大で、またテストに使うデータ等も用しなくてはならないので、予想以上の時間がかかります。
私たちのチームは、システムテストに当初見積もっていた以上の時間を要したために、計画が若干崩れていしまいました。
さまざまな困難はあったものの、最終的には概ね要件を満たす記事管理システムを作成することができました。
チーム開発のいろはからLAMPやAWS、APIの設計、セキュリティ対策に至るまで、Webエンジニアにとっての基本を全て抑えられる、コスパの良い実習でした。
５ヶ月でたくさんのことが学べる
最初に８月中旬まで研修があると聞いた時、「長くない？」というのが正直な意見でした。
今年の春から他の企業に勤めだした大学の同期と話しても、朝日新聞社ほど長く技術研修を行っている企業はあまり聞いたことがありません。
しかし今になって振り返ってみると、Web技術者の素養を身につける上での基礎の基礎を学べる、無駄のない実習であったように思います。
１から学べる実習のメリットは、特にエラーハンドリングをする際に享受できると思っています。
たとえば、
• 基礎情報技術者的な内容としてPCの構成をきちんと知っておくことで、ハード由来のエラーが発生した際に、それがどこに起因するものなのかより詳細に原因を考察できる。
• サーバを１から立ち上げてサービスをスクラッチ開発する経験をすることで、Webサービスを実際に運用している際に、どの構成技術によるエラーが起きてもその対応がある程度しやすい。
集団研修を早くに終えてOJTに移るというのも、新人に素早く実際の業務に慣れてもらうという意味では効果的かも知れません。
しかし、新卒だからこそ、技術者としての基礎をしっかりと学び、その基礎を持ってどんな業務にも柔軟に取り組めるようにするというスタイルも悪くないと、研修を終えた今では思っています。
加えて、同期の間だけで協力して何かを作る経験は、社会人生活の中でなかなか味わえるものではありません。
当たり前のことかも知れませんが、会社に入ればどこかの部署に配属され、チームとして色々な先輩方と連携していくことが多いでしょう。
もちろん先輩と協力して仕事に取り組むのも、勉強になることが多く、私は楽しいです。
一方で対等な関係である同期と、ああでもない、こうでもないと言い合いながらプロジェクトを進められるのも、青春っぽくて別の面白さがあります。
会社の中でいざという時に頼れるのは同期であることが多いです。
研修の中で同じ困難に立ち向かい関係を深めることができれば、それぞれの部署に配属された後でもちょっとした時に助け合える、協力な味方になるでしょう。
さて、今回はこのあたりで。
今後のエントリでは、配属後の実際の業務について、お伝えできる範囲でお話しできればと考えております。
このエントリのタイトルである「できるようになったこと」について、より詳しく触れていく内容になる予定ですので、ここまで辛抱強く読んでいただいた皆さん、ぜひ今後もお付き合いください！
（ICTRAD・倉井敬史）