設計書メンテで消耗しないためにIDL開発へ切り替えた話

はじめに

こんにちは。レバテック開発部の園山です。私は、レバテック開発部のビジネスサポートグループに所属し、システム開発業務を担当しています。

本記事では、開発効率を向上するためにインターフェイス定義言語 (IDL) ベースの開発に切り替えて、設計書管理を行わず、どのように開発を行っているかについてご紹介します！

レバテックにある主な3つの機能として、「営業支援・管理ツール」「ユーザーや取引先企業が使用する登録者向けサービスシステム」「オウンドメディア」があり、現在、それらを1つの統合化したプラットフォームに集約するプロジェクトにおいて業務設計・開発を進めています。

今回のリプレイスにあたり、システム開発をより良いものにするためにはどうしたら良いかメンバー間で日々意見を出し合っており、そこで生まれた案をひとつずつ取り入れています。その中のひとつとして、ドキュメントで設計書を管理する体制を廃止しました！

これまでのやり方

これまでは、設計者が設計書をドキュメントに起こし、ドキュメントに書かれたものを実際の開発担当者が読み、開発を行っていました。複数の施策が同時並行で進んでいることが多く、仕様を更新する場合は設計担当者が設計書のコピーを作り、仕様を更新して、差分がわかるように打ち消し線や文字列の色を変える工夫をしていました。 結果、原本のドキュメントのメンテナンスが後回しになってしまったり、特殊仕様の認識合わせにコミュニケーションコストがかかっていました。

インターフェイス定義言語 (IDL) ベースの開発とは

インターフェイス定義言語 [IDL: Interface Definition Language]（以下、「IDL」という) とは、特定のプログラミング言語とは別にオブジェクトのインターフェイスを指定するために使用される汎用言語のことで、本プロジェクト内では gRPC のプロトコルバッファーから IDL を使用しています。 プロトコルバッファー以外にも、OpenAPI（Swagger）、GraphQLや、Apache ThriftなどがIDLでSchemaを定義する技術になります。

プロトコルバッファーIDL は、オープンな仕様を持つプラットフォームに依存しないカスタム言語で、開発者は、入力/出力共にサービスを記述する .proto ファイルを作成し、API仕様を決めることができます。 これらの .proto ファイルはクライアントとサーバーの言語を生成できるので、TypeScript ⇄ PHP といった複数の異なるプラットフォームで通信でき、開発時にも.protoファイルを共有することで、コードの依存関係を取得することなく他のサービスを使用するためのコードを生成することが可能になっています。

IDLベースの開発は社内でも前例がありませんでしたが、1人が起案したところから始まり、サンプルコードを元に勉強会を実施して、実際に開発を進めながら習得していきました。 複雑な責務を持つマイクロサービスの場合、事前にある程度知識を深めるための資料を用意して、関係者間で認識合わせをしてから着手することもありましたが、基本はIDLベースで問題なく進めることができています。

違いを比較してみると

実際の開発シーン別にその違いを比較してみます。

開発あるある①：仕様が途中で変更になる
既存　設計者が設計書を更新 → 開発者が設計書を見て実装を修正
IDL　設計/開発者がIDLを更新 → 開発者はコード生成を再実行し、コンパイルエラーが発生していたらエラーを解消

開発あるある②：開発を分担していて連携部分が心配
既存　片方の実装が終わるまで動作確認ができず、実装完了後に不具合が見つかったりする
IDL　IDLからコードを生成するため、定義通りのスキーマになることが保証され、連携部分の心配がなくなる

開発あるある③：設計書の管理が難しい
既存　施策単位や特殊仕様に応じてドキュメントが増えがちで、設計書をメンテナンスする優先順位が低く管理が行き届きづらい
IDL　IDLから設計書を出力する（手動で差分を最新化する手間がなくなりました）

以前よりも変化を迅速にシステムへ反映させていくことができるようになりました！

やってみた感想

設計者と開発者の垣根がなくなったことが大きく、開発をしながら改善していく楽しさを実感しています。 デメリットは、慣れるまでの学習コストやある程度の設計スキルが必要なことで、I/Fだけでは見えない仕様パターンの考慮をどのようにメンバー間でコミュニケーションを取りながら進めていくかなど、チームルールを整備する必要がある点も課題に感じています。

まとめ

今回は開発効率を向上するためにインターフェイス定義言語 (IDL) ベースの開発に切り替えたことについてご紹介しました。IDL開発について何か1つでも参考になる点があれば幸いです。社内では、デメリットに挙げた点についても改善などの提案が常に行われており、解決へ向けて積極的に取り組んでいるため、また別の機会にご紹介できればと思います。

レバテック開発部では、一緒にサービスを作り上げてくれる仲間を募集中です！ ご興味のある方は、以下のリンクから是非ご応募ください。 https://recruit.jobcan.jp/leverages/

プレイド社とマイクロサービス勉強会を開催しました~コロナ禍でも楽々！クローズド+リモート勉強会のススメ~

こんにちは。レバレジーズ株式会社のテックリードの竹下です。

2021/1/13に、KARTEのサービスを運営しているプレイド社とマイクロサービスに関して、合同勉強会を開催しました。

今回は、クローズドかつ、リモートで勉強会を開催したため、リアル開催やリモート一般公開と比べてどのようなメリットがあったかをご紹介していきます。

目次

開催の経緯

これまでレバレジーズでは、社内勉強会に加え、セミナールームを勉強会に貸し出すことで、社外とも交流を持ち、エンジニアが学べて成長できる環境を作ってきました。しかし、コロナ禍によって勉強会が全てリモート開催になったり、延期になってしまったことで、勉強会の機会が減っていました。

社内での勉強会は、社内の知見共有が中心となってしまうため、世の中の技術トレンドや、他社での取り組みを知る機会は多くありません。自社でリモート勉強会を開催しようと考えましたがレバレジーズは技術的な知名度がまだ低く、集客は難しいと判断しました。(開催したのはいいけど、社員しか参加してくれなかったら悲しいじゃないですか……😥)

一般公開では集客が難しそうなので、TypeScriptでマイクロサービス化という技術スタックをすでに運用しているプレイド社に「2社で勉強会をしませんか」と声をかけたのが開催の発端です。

勉強会の内容

勉強会のタイムスケジュールは、「マイクロサービス」をテーマに15分程度で発表を2社2名づつ行い、その後に懇親会という流れで行いました。 それぞれのタイトルと資料は下の通りです。(敬称略、公開確認取れたもののみ掲載しています)

1. レバレジーズ株式会社 住村 「マイクロサービス五里霧中」
2. 株式会社プレイド 大矢「Tilt.dev を使ったリモート k8s 開発環境」
3. レバレジーズ株式会社 竹下 「開発効率爆上げを目指したインフラ技術スタック構想」Slide@Prezi
4. 株式会社プレイド 山内「アンチパターンから学ぶマイクロサービス」

私の発表に関しては詳しい内容は、また後日改めてブログに書きますので、ご期待ください

クローズドで内容が充実する

業務に密接に関係する話ができる

クローズド開催にすることで、関係者は2社のみとなるため、お互いが興味のあるテーマの勉強会を開催することが可能になります。一般公開の勉強会を行う場合、集客性や、世の中のエンジニアの人に役に立つような内容にすることを考慮する必要があるため、幅広い人に興味を持って貰えるようなテーマ設定になりがちです。

今回プレイド社とは、「TypeScript」と「マイクロサービス」という2つの共通点があり、マイクロサービスに関する勉強会を開催する運びになりました。

踏み込んだ話ができる

クローズド開催になったことで、内容に関しても踏み込んだ内容まで発表することができました。一般公開した場合、その分野に詳しくない人も来ることが想定されるため、その人達にもわかるような発表をする必要があり、どうしても本題に入るのが遅くなってしまいます。

しかし、2社間だと前提とする知識が共通してあるため本題の説明に時間を多く割くことができました。(そのため、発表スライドだけを見てもらうと端折られているように感じる部分があるかもしれません。)

さらに、発表内容自体も「開発環境をどう作っているか」や「どんな失敗をしたか」「どういう挑戦をしているか」など、一般論に終始しない実務に根ざした内容が盛りだくさんになっていて、普通の勉強会ではなかなか聞くことの出来ない内容になっています。

懇親会も濃密

勉強会では発表も重要ですが、懇親会も発表を補完する機能を持っています。クローズドだとお互い実務に携わっている人が多く参加しているので、発表者の人に話を聞くだけでなく、他のエンジニアに実務の中でのノウハウを聞いたり、あるある話に花を咲かせることも可能です。また、プロジェクトマネージメントや気になっている技術のことなど、普段なら相手のバックグラウンドを探ってからでないと聞きにくいようなことも聞きやすく、勉強会のテーマ以上のことを学ぶことも出来ました。

開催者も参加者も楽できる

周知や参加者管理が楽

私は前職で隔週でScala勉強会の会場係を7,8年務めていたりScalaMatsuriの運営を5,6年手伝っていましたがが、参加者を集めたり内容を企画するのにいろいろ苦労をしてきました。connpass, atendなどのイベント告知サイトにイベント登録をしたり、発表を募ったり、キャパ制限があれば先着順や抽選をしたり、リアル会場なら会場への入場方法を案内したり、懇親会の店をとったりと様々な雑務が必要です。

しかし、クローズド＋リモートにすることでそれらの手間がかなり軽減されました。周知はイベントサイトなど作る必要が無く、お互いの会社でSlackやメーリスで流すだけとなり、全員リモート参加なので人数制限や会場への案内も不要で、懇親会のお店の予約や準備もいりませんでした。そのため、勉強会の開催ノウハウや人員がいなくても手軽に開催が可能になります。今回は、初回ということもあり入念に準備しましたが、それでもミーティングが約1時間半くらいと、接続テスト30分程度で準備が出来ました。

勉強会を継続するには、勉強会の運営や管理をしていく人が必要になりますが、これぐらいの労力なら片手間に出来るので、ひとりでも継続して開催することができます。

リモートなので参加者が楽

リモートになったことで参加者も楽になっています。リアル開催の場合、会場へ移動する必要があるためどうしても参加障壁が上がります。今回は、19時開始でしたが、もしプレイド社（銀座本社）で開催した場合、レバレジーズは渋谷に本社を構えているため、遅くとも18時30分には退社し会場に向かう必要があります。懇親会含めると22時30分くらいまでやっていたため、家につくのは23時を過ぎてしまいます。レバレジーズ社とプレイド社ならまだ近いですが、大阪や福岡にある会社の場合は、そもそも参加すらできません。

しかし、リモートだと移動時間が全くなくなるので拘束時間は実際の勉強会と懇親会の時間だけになり、もし急遽業務の割り込みが合ったとしてもすぐに業務に戻ることも可能です。そのため、気軽に参加してもらうことが可能になり双方の参加者を増やすことが出来ます。

初めての発表の人も気が楽

私もはじめはそうでしたが、見ず知らずの人の前で発表をすることは初めての人にとってはハードルが高いものです。しかし、2社間クローズドにすることで半分は自社の人で見知った人も多くいるため、発表になれていない人にとっても発表がしやすいです。また、当日は資料を完全公開にする必要が無いため後で手直しも可能なため、発表慣れしていない人にとっては嬉しいかしれません。

まとめ

今回は、レバレジーズが現在取り組んでいるマイクロサービス化について、すでに運用して1年ほど経つプレイド社の知見を大いに学ぶことが出来ました。プレイド社のハマったポイントや、レバレジーズで現在抱えている問題をどのように解決しようとしているかなど、知りたいと思っていることを学ぶことが出来ました。 私もいろいろな勉強会に参加していますが、通常は入門的な内容が多かったり、今知りたいことと少しずれてたりするので、ここまで密度の高い勉強会はなかなか経験がありませんでした。

これは、クローズドかつリモートという形式を取ったことの効能だと感じました。 また、勉強会の開催の手間も少なく、ハードルも低いため頻繁かつ定期的に開催することも出来ると思います。今後もひとつ一の取組みとしてクローズドかつ、リモート形式での勉強会を継続して開催し、エンジニアの技術力UPの一助にしていきたいと思います。

レバレジーズと勉強会しませんか？

現在レバレジーズでは、マイクロサービス化、TypeScriptの導入、gRPCの採用、DDDやクリーンアーキテクチャの採用、Vue.js/Reactの導入、IaCによるインフラ管理など様々な技術スタックの刷新を行っています。もし、同じような技術を持っていたり、導入を考えている方いたら竹下や的場にご連絡ください！是非、一緒に勉強会を開催しましょう。

お問い合わせはこちらにお願いします。

レバレジーズの４事業を支える基幹システムのPMとは？

はじめに

こんにちは。プロジェクトマネジャーの丸山です。

最近、プロジェクトマネジメントに関する記事をたくさん見かけますが、 「社内システムのプロジェクトマネジメント」のテーマはそこまで出回ってないように思います。

そこで今回はレバレジーズの社内システムのプロジェクトマネジメントがどのように行われているのかを紹介します。

年商150億円を支える基幹システム！

プロジェクトマネジメントについて紹介する前に、対象のシステムについて紹介させて下さい。 営業活動を行う時に利用するシステムを社内の事業部に提供しています。この類を営業支援システム(SFA)と呼び、有名なものではセールスフォース・Hubspotなどがあります。

このシステムは、顧客管理・案件管理・進捗管理・書類管理・金銭管理といった基本的なSFAに付いている機能に加え、 連絡機能(電話・メール・LINEなど)やマーケティング情報の管理機能なども付いているので、営業だけでなく事業の全領域を支援しています。（よって基幹システムと題させて頂きました）

このシステムは、1つで4事業を支えています。看護師さんの紹介事業・派遣事業・介護士さんの紹介事業・派遣事業の4つです。 看護業界と介護業界の中身は異なる部分が多いですし、紹介事業と派遣事業のビジネスモデルも全く違いますが、人材業界という大きな枠組みでシステムを設計したことで、4事業の全領域を管理するシステムを作ることが出来ました。

このシステムが支援する4事業の年商は約150億円です。社員による月間アクセス数は250万PVとなります。

基幹システムの全体像

プロジェクトマネジメントをどのように行っているか？？

それでは本題に入ります。 まず、全体の流れを簡単に示すと下記のようになります。

プランニング → 要件定義 → 基本・詳細設計 → 実装・テスト → 導入 → リリース → 効果測定 → プランニング

このサイクルをおよそ1ヶ月スパンで回しています。関係者が全員社内にいるため、コミュニケーション調整コストがほとんどかからない社内システムだからこそ、この短いスパンを実現出来ています。

それでは、各プロセスについて具体的に説明します。

プランニング

今後どのようなシステム改修をしていくか、4事業の責任者と話し合い、優先順位を付けます。

4事業の売上を最大化するために、事業部の全活動の中でどこを改善するべきか（事業課題）を話し合います。事業課題の中でシステム改修によって解決可能なものがあれば、「このような改修によってこの事業課題がこのくらいのインパクトで改善される」などの提案をします。採用された提案には優先順位を付け、優先度の高い改修のスケジュール調整を行います。

採用された提案の多くがプロジェクトマネジャー発案であり、エンジニアが考えてプロジェクトマネジャーに提供した提案も採用されています。 ほとんどの改修で、自分達がやる価値があると思ったことに取り組んでいるので、開発チーム全体のモチベーションが高く保てています。

要件定義

プランニングで決まったシステム改修案の要件を定義します。

関係者を集め、どのような改修をしようとしているか説明を行い、実現可能性・課題解決の方法・役割分担などについて話し合います。

営業関連の改修なら営業部のリーダー、マーケティング関連の改修ならマーケティング部の担当者と、集める関係者は改修案によって異なります。同じ会社の仲間なので、協力的に動いて下さる社員が多く、様々な領域のプロフェッショナルと意見交換が出来るので視野が広がります。

基本・詳細設計

要件をベースに基本・詳細設計をします。

基本・詳細設計は画面設計・入出力設計・機能設計・DB設計の4つで構成されています。画面設計は、関係者に要望をヒアリングしたりプロトタイプを見せたり意見交換をしながら行います。

要望をヒアリングした際に、4事業の文化の違いやチーム体制の違いにより意見が割れることも多いです。この場合には全ての要望を汲み取るべきか取捨選択するかを意思決定し、対立意見の関係者を説得することで意見を収束させます。

4事業を支えるシステムだからこそ、難しい部分もありますが、この苦労があるからこそ4事業を支えるシステムが成立します。

また、DB設計では4事業間の整合性を担保するために抽象化・正規化が適切に行われているかを細かくチェックします。最初は上手く設計が出来ませんでしたが、経験を経て上手く設計出来るようになりました。DB設計が上手くなっただけでなく、概念的に考える力がかなり成長したと感じます。

実装・テスト

実装・テストの実行はエンジニアが担当します。 プロジェクトマネジャーの担当はスケジューリングとサポートです。

開発チームでは2週間ごとに区切りをつける、スプリント形式で開発しています。スケジューリングとは、プランニングで定めた改修のスケジュールを守れるようにタスクをスプリントに割り振っていくことです。サポートとは、エンジニアに要件や基本・詳細設計を説明をしたり、開発で発生した問題を解決したり、実装・テストを進めるための支援活動のことを指します。

複数のプロジェクトが並行して走ることが多く、スケジューリングやリソース調整は大変になりますが、「スケジュール通りに開発を進める」という、プロジェクトマネジメントで一番基本となる能力の成長に繋がりました。

導入

全てのシステム利用者に改修内容を説明します。

要件定義や基本・詳細設計において全てのシステム利用者を巻き込むことは時間制約上不可能なので、改修に関する情報があまり伝わってないシステム利用者もいます。

その方々に向けて、「どのような事業課題に対してどのような改修をしたのか」を説明します。システムの最大の目的は「4事業の売上の最大化」であるため、それに基づいてシステム利用者が表面上不便に思う改修を行うこともあります。 そのような場合にも改修の理由を事前に説明して理解してもらうことで、システム利用者との信頼関係を保つことが出来ます。

システムへの関心が薄い相手もいる中で、まんべんなく理解を得ることは難しく、このプロセスも初めは苦戦しました。ただ、試行錯誤を重ねる内に分かりやすい説明と共感性の高いメッセージの発信が身について、システム改修について大部分の人に理解してもらえるようになりました。

リリース

エンジニアがリリース作業を行っている間にプロジェクトマネジャーがSlackでリリースを告知します。改修の内容が良ければ、告知後すぐにSlackのスタンプや称賛のコメントがたくさん返ってきます。反応が薄いときはもっと頑張らないとなと思いますし、反応があったときには純粋に嬉しい気持ちになります。

効果測定

システムのアクセスログや売上データを分析して、事業課題の改善インパクトを測定します。インパクトがプランニングで提案した時の基準に達していれば、システム改修によって事業課題を解決出来たと評価されます。

事業課題を解決出来た場合の達成感は、リリース時以上のものです。 リリース時の反応は重要であるものの指標の1つでしかなく、チームの最終的な使命は「事業課題の解決」と、それによる「4事業の売上の最大化」だからです。

事業課題を解決出来た際は、チームSlackで成果を共有し、達成の喜びを分かち合います。数多くの困難を共に潜り抜けたチームメンバーと共に達成の喜びを分かち合えたときは、全ての苦労が報われたように感じます。

効果測定が完了すると、その結果を踏まえて更なる事業課題が無いかプランニングで検討します。効果測定からプランニングに繋がることで、プロセスが循環しています。

まとめ

レバレジーズの基幹システムのPMとは、一言で表すと「4事業の売上最大化を目的としたシステム改修の仕掛け人」です。この仕事には主に2つの魅力があります。

システムの規模が大きいこと

扱っているシステムは基本的なSFAの枠組みを大きく超え、連絡機能(電話・メール・LINEなど)やマーケティング情報の管理機能などもついているので、事業の全てを支える基幹システムと言えます。そのうえ、ひとつのシステムで4事業、年商約150億円を支えています。

裁量権が大きいこと

システム開発において、上流として位置付けられる要件定義だけでなく、事業の責任者と事業課題を話し合うプランニングから参加しているため、システム開発に関する全ての意思決定について関わることが出来ます。

事業を成長させたい思いで自ら考え動かした改修案が、リリースされシステム利用者に喜ばれる、嬉しい経験も味わうことが出来ました。

4事業が関わるシステムなので、難しい意思決定が多いですが、コミュニケーション力や論理的思考力などのスキルの成長に繋がりました。

We are Hiring

レバレジーズではプロジェクトマネジャー・エンジニアを募集しています。 興味を持って頂けた方はこちらからご連絡頂けると幸いです。

https://recruit.jobcan.jp/leverages/

社内電話アプリをChrome拡張機能からElectronにリプレースした話

はじめに

こんにちは！エンジニアの呉です！ 今回は社内で開発している電話アプリについて、Chrome拡張機能からElectronへリプレースした話をご紹介します。

リプレースしたきっかけ

■問題点

社内で開発している電話アプリでは、いくつかの問題が顕在化していました。

• コードの見通し
  • 電話という特異的な機能に加えて、Chrome拡張機能独自のお作法によりコードの見通しが悪くなっていた
• 手動リリース
  • ウェブストアのダッシュボードから審査の申請をする必要がある
• リリースコントロールがしにくい
  • Chrome拡張機能の自動更新が最大5hのタイムラグが生じる(chroniumの対象コード)
  • ウェブストアの審査が介入するため、リリースが手間

■解決手段

今回これらの問題を解決する手段として、Electron + Vue.jsでリプレースをすることを決めました。

• コードの見通し
  • 社内で知見の多いVue.jsを採用し、学習コストを低減
  • 言語はTypeScriptを採用し、型宣言による開発効率、保守性の向上
  • 表示のコンポーネント化、機能のモジュール化を行うことにより、それぞれの責務を明確にし、コード全体の見通しを向上
• 手動リリース
  • GitHub Actionsを利用し、リリースを自動化
• リリースコントロールがしにくい
  • electron-builderのelectron-updaterパッケージを使い、自動更新タイミングを自分でコントロールできるように解決
  • AWS S3へのアップロードを行うだけのため、審査介入によるリリースコストダウン

出来上がったもの

今回出来上がったものを簡単なご紹介します。

■Electronアプリケーション

主なディレクトリ構成は以下の通りです。

src
 ├── assets
 ├── background
 ├── components
 ├── constants
 ├── models
 ├── plugins
 ├── router
 ├── services
 ├── store
 └── views

ディレクトリ名	役割
assets	グローバルで利用するCSSやフォント、ロゴなどのリソース
background	Electronアプリケーションのライフサイクル制御とプロトコル設定、バージョンチェックなど
components	表示部品単位でのコンポーネント定義
constants	通話で利用する結果コードの定義や外部イベントの定数を定義
models	APIや通話で利用する連絡先などのモデル定義と型定義
plugins	API通信で利用するaxiosやGoogle OAuth、Slackなど外部ライブラリのラッパーを定義
router	ページのルーティング定義
services	業務ロジックをサービス層として抽出し定義
store	モジュール単位での状態管理とアクション定義
views	ページ単位単位でのコンポーネント定義

■リリースフロー

リリースフロー

これまで他のプロジェクトでは、CircleCIを使ったリリースの自動化をしていましたが、今回はGitHub Actionsを使ったリリース方法を採用しました。

理由としては、

1. 社内でElectronを使ったプロジェクトが多く発足する可能性を考慮し、プロジェクト独自のリリースフローで良いと判断
2. GitHub Actionsのワークフローを定義のみで設定作業のコストを削減
3. CircleCIのmacOSビルド環境(executor)を追加で契約する必要があったため、ランニングコストを削減

よかった点

今回電話アプリの開発を実際に担当している身として、前述の問題点に対してどうすべきなのか、どうしたらやりやすくなるのかをエンジニアサイドから考えた上での行動に起こしました。

■運用保守コスト

結果として、リプレースによる利用者の満足度を向上させるようなダイレクトなインパクトはありませんでしたが、エンジニアサイドの心理的安心感や運用保守コストダウンにより、間接的に利用者に機能提供するまでの開発効率を向上することができました。

■スキル

ElectronやGitHub Actionsなど社内でもあまり導入実績のない技術に対して挑戦することで、個人の成長を実感することができました！

■意思決定

今回のリプレースの提案に対しても「イイじゃん！イイじゃん！」と共感してもらった上で、その場で「じゃあいつまでにできそう？」とスピード感に若干驚きました（笑）

ボトムアップの提案に対してもスピーディに対応し、承認までの間隔が短く、提案することに対して億劫にならない環境だなーと私個人としてとても印象に残りました。

大変だった点

…ここまで良いことばかり書いてきましたが、もちろん良いことだけではありませんでした。

■Twilio

元々前任者がベースを開発していたこともあり、全容を完璧に把握できていたわけではなかったので、動作が変わらないように全体を見渡す時間がとてつもなくかかってしまいました。

■Appleの公証

macOSを利用している方もいるため、Appleの公証（アプリ署名）を行う必要がありました。

Apple Developer Programからの証明書発行、発行した証明書を用いてビルド・リリースの自動化で苦戦をしました。

最終的にはelectron-notarizeを使うことで解決しました。

まとめ

いかがでしたでしょうか？

社内のカイゼン事例として、社内電話アプリのChrome拡張機能からElectronにリプレースした話をご紹介いたしました。

今回エンジニアによるボトムアップからの提案に対してスピーディに実現ができたことが素直にとても嬉しかったです。

みなさんも「やりたい！」と思ったことをまずは声に出してみるところから始めてみてはいかがでしょうか。

We are Hiring

レバレジーズでは、一緒に今をより良くしていく仲間を募集しています。

弊社に少しでも興味を持っていただいた方は是非ご連絡いただけると幸いです。

https://recruit.jobcan.jp/leverages/

ネイティブアプリをFlutterにフルリプレイスした話

はじめに

こんにちは！エンジニアの藤野です！ 今回はキャリアチケットが運営するキャリアチケットカフェのiOS/Android向けアプリをFlutterにフルリプレイスした話をご紹介します。

なぜFlutterに移行したのか

元々アプリ開発はiOSはSwift, AndroidはKotlinを使用し、開発を進めていましたが、開発を進めていく上で生産性が上がらない問題が発生していました。

最終的には1人でモバイル開発をしていたため、iOS/Androidのどちらとも実装する時間がなく、iOSのみに実装するといったOSによって機能が違うアプリになっていました。また、1人で仕様検討から実装・リリースまでを行っていたため、開発効率も下がっていました。レビュワー等もいなかったため、プルリクエストを投げた後もセルフマージで対応していました。

以上のような問題を解消するために、Flutterにフルリプレイスすることを決めました。Flutterにした理由は下記2つです。

• 未経験でも取っ付き易い
• OS関係なくひとつの言語で統一できる

他のチームメンバーにもFlutterを触ってもらうことで、開発できる人を増やせること、さらに生産性を向上させるメリットがあったため、Flutterへのフルリプレイスへ踏み切りました。

構成

今回使用した状態管理手法やディレクトリ構成を紹介します。 状態管理の手法はChangeNotifier+Providerパターンを採用しています。ProviderはPragmatic State Management in Flutter (Google I/O'19)で公式に推奨されています。 設計当初にはまだ登場していませんでしたが、最近はStateNotifier+Freezed+Providerを使った状態管理やRiverpodの登場などがあります。

ディレクトリ構成

ディレクトリ構成は以下の通りです。どのような役割になっているかも、ひとつずつ簡単に説明しています。

lib
 ├── config
 │    └─ route.dart
 ├── models
 │    └─ tmp
 │      ├─ tmp.dart
 │      ├─ tmp.freezed.dart
 │      └─ tmp.g.dart
 ├── resources
 │    ├─ api
 │    │   └─ tmp_api_provider.dart
 │    └─ repositories
 │      └─ tmp_repository.dart
 ├── screens
 │    ├─ common
 │    └─ tmp
 │      ├─ widgets
 │      └─ tmp_screen.dart
 ├── services
 ├── utils
 ├── assets
 ├── viewmodels
 │    ├─ common
 │    └─ tmp
 │      └─ tmp_view_model.dart
 └── main.dart

• config
  • 設定ファイルを配置(ルーティングを設定するファイルなど)
• models
  • 作成するモデルのディレクトリを作ってその中にdartファイルを配置する
  • freezedパッケージを使用
• resources
  • api
    • APIとのやり取りをするファイルを配置
    • ファイル名 : xxxx_api_provider.dart
  • repositories
    • apiからデータを取得して各モデルの形にマッピングしたり、データ送ったりする
    • ファイル名 : xxxx_repository.dart
• screens
  • 各画面ごとにディレクトリを作成してその中にファイルとwidgetsディレクトリを作成する
  • 基本的には1画面1screenを作成し、widgets配下に画面内で使用するWidgetを配置
• services
  • 主に外部サービスとの連携周りの処理を書いたものを配置
• utils
  • 定数などのファイルを配置
• assets
  • 画像などの素材系を配置
• viewmodels
  • screenの状態管理をここで全て行う
  • provideパッケージを使用(Provider & ChangeNotifier)

構成は以上のようになっています。伝わりづらい部分はサンプルとして、 APIからデータを取得して表示するだけの簡単なアプリを作成しながら詳しく説明します。

1. パッケージの導入

providerパッケージやfreezedパッケージを利用するため、pubspec.yamlを以下のようにします。

dependencies:
  flutter:
    sdk: flutter
- cupertino_icons: ^0.1.3
+ provider:
+ freezed_annotation:
+ http:

dev_dependencies:
  flutter_test:
    sdk: flutter
+ json_serializable:
+ build_runner:
+ freezed:

2. モデルの作成

モデルはFreezedパッケージを使用しているため、以下のように書いた後に以下のコマンドを実行します。 flutter pub run build_runner build これによって event.freezed.dart ファイルと event.g.dart が生成されます。 詳しいFreezedパッケージの使い方はドキュメントを参照してください。

import 'package:freezed_annotation/freezed_annotation.dart';
import 'package:json_annotation/json_annotation.dart';

part 'event.freezed.dart';
part 'event.g.dart';

@freezed abstract class Event implements _$Event {
  factory Event({
    int id,
    String title,
    @nullable @JsonKey(name: 'created_at') String createdAt,
  }) = _Event;

  factory Event.fromJson(Map<String, dynamic> json) => _$EventFromJson(json);
}

3. APIからの取得処理実装

APIから実際にデータを取得する部分をプロバイダーとして作成します。

import 'package:http/http.dart' as http;

class EventApiProvider {
  Future getAll() async {
    return await http.get('http://localhost:8080/events');
  }
}

Repositoryでは上記で作成したプロバイダーから取得したデータをモデルの形にマッピング

import 'dart:convert';
import 'package:sample/models/event.dart';
import 'package:sample/resources/api/event_api_provider.dart';

class EventRepository {
  Future<List<Event>> getAll() async {
    final _response = await EventApiProvider().getAll();
    return json.decode(_response.body)
        .map<Event>((json) => Event.fromJson(json))
        .toList();
  }
}

4. ViewModelの作成

ここで先ほど作成したEventRepositoryを利用してデータを取得し、画面側へ結果を伝えます。

import 'package:flutter/material.dart';
import 'package:sample/models/event.dart';
import 'package:sample/resources/repositories/event_repository.dart';

class EventViewModel extends ChangeNotifier {
  final EventRepository _repository = EventRepository();
  List<Event> events = [];

  Future getAll() async {
    events =  await _repository.getAll();
    notifyListeners();
  }
}

5. Screenの作成

ボタンを押すとAPIからデータを取得し、取得結果を表示するような画面を作成します。 ボタン押下時にViewModel側の getAll() を呼び出してデータを取得、notifyListeners() が呼び出されたタイミングでListViewが再描画されます。

import 'package:flutter/material.dart';
import 'package:provider/provider.dart';
import 'package:sample/viewmodels/event_view_models.dart';

class EventScreen extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    EventViewModel _viewModel = Provider.of<EventViewModel>(context);

    return Scaffold(
      appBar: AppBar(
        title: Text('Event List'),
      ),
      body: Center(
        child: Column(
          children: <Widget>[
            FlatButton(
              onPressed:() async => _viewModel.getAll(),
              color: Colors.lightBlue,
              child: const Text('取得'),
            ),
            Expanded(
              child: ListView.builder(
                itemCount: _viewModel.events.length,
                itemBuilder: (BuildContext context, int index) {
                  return ListTile(
                    title: Text(
                        "${_viewModel.events[index].id} : ${_viewModel.events[index].title}"
                    ),
                  );
                },
              ),
            ),
          ],
        ),
      ),
    );
  }
}

6. main.dartの修正

各画面の遷移先は以下のようにルーティングファイルに記載します。

import 'package:flutter/material.dart';
import 'package:sample/screens/event_screen.dart';

final Map<String, WidgetBuilder> routes = {
  '/': (BuildContext context) => EventScreen()
};

そして MaterialAppのroutesに先ほど作成したルーティングを設定することによってEventScreenが呼び出されるようになります。

import 'package:flutter/material.dart';
import 'package:provider/provider.dart';
import 'package:sample/config/route.dart';
import 'package:sample/viewmodels/event_view_models.dart';

void main() {
  runApp(MyApp());
}

class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return MultiProvider(
      child: MaterialApp(
        routes: routes,
      ),
      providers: [
        ChangeNotifierProvider(create: (context) => EventViewModel()),
      ],
    );
  }
}

完成！

取得ボタンを押すと、APIからデータを取得し表示します。

実際にリプレイスしてみて

メリット

1. 開発工数の削減 Flutterで開発すると、SwiftとKotlinの別々で書いていたときよりも 体感4割ほど工数が削減できました。ただ、全て共通で同じ実装をできるかと言われるとそうでなく、OSに依存する機能などは個別に実装する必要があるため、その部分に関しては工数がかかってしまいます。 また、Flutterの大きな特徴の一つであるホットリロード機能がとても便利で、開発中のデバッグにかかる時間がかなり削減されました。

2. 未経験でも開発が容易 今回のリプレイス作業は、自分以外のチームメンバーのほとんどがFlutter未経験者でしたが、全員スムーズに開発をすることができました。公式ドキュメントが充実していて、UI部分に関してもSwiftやKotlinよりも簡単に実装ができるため、Flutter未経験でも簡単にモバイルアプリを開発することができます。

3. UIの実装が簡単 こちらもFlutterの大きな特徴ですが、UI部分は全てWidgetで構成されており、マテリアルデザインなどといった、様々なデザインが備わっています。そのため、ある程度のデザインであれば公式のライブラリを使用することで、簡単に実装をすることが可能です。

4. コードレビューが楽 SwfitやAndroidではそれぞれStoryBoardとレイアウトファイル(xmlファイル)で実装していたため、コードレビューの際に変更箇所の差分が分かりにくく、苦戦していました。Flutterに移行したことで、変更箇所が分かりやすく、コードレビューが楽になりました。

デメリット

1. OSに依存する機能などは個別に実装が必要 OS依存の機能を使わない場合に関しては、特に問題ありません。通知機能やAppleサインインなどのOS依存の機能を実装する場合は、その部分に関する知識が必要になってきます。 また、リリース時もiOSとAndroidで証明書が異なるため、別々に管理することが必要となります。

2. パフォーマンスを考慮した設計 さまざまなWidgetを組み合わせて簡単にUI部分を実装することは可能ですが、何も気にせずに実装を進めていくと、ネイティブよりもパフォーマンスが低下し、アプリ実行時に全体的にもっさりした感じになります。そのため、複雑なUIなどの場合にはパフォーマンスを考慮して設計をしなければいけません。

開発を行ったチームメンバーの感想

モバイルアプリ開発未経験にも関わらず、リプレイス作業に携わってもらったチームメンバーから、以下のような感想を貰いました。

• 環境構築がそこまで複雑ではないのですぐに開発をすることができた
• UI部分はWidgetがHTMLみたいで直感的で書きやすい
• UIパーツを組み上げる感覚で、思ったほど苦労せずに実装できた
• Flutterの進歩が早い
• 開発がスムーズ進められた(デバッグツールが使いやすい、ホットリロード機能最強！など)

メリットでもあるUI部分に関しては、直感的で未経験者でも開発がしやすいとのことです。

Flutter移行中に起きた問題とその対応

Flutterに移行する際にさまざまな問題等に直面したので、その内容と解決方法、注意点などをいくつかご紹介します。

UI設計をあらかじめした方が良い

今回は画面単位で担当者を割り振ったため、コンポーネント化出来るWidgetがコンポーネント化されていなかったりと煩雑になってしまいました。他にもContainer Widgetを使う実装があったので、パフォーマンスなども考慮して適切なWidgetを使うことをおすすめします。

iOSのバージョンアップデートには事前に対応しておくべき

今回iOS側にはUniversal Links機能を実装していたのですが、アプリのリリース前にiOSのバージョンがiOS 14に上がったことでAssociated Domains周りの仕様が若干変更されました。そのため、サーバサイド側の設定変更を余儀なくされました。 iOSの次バージョンがリリースされる3ヶ月ほど前の6,7月頃にはBeta版がリリースされるので、事前にBeta版を使ってあらかじめ対応するべきでした。

審査に落ちてしまった

iOS側の話が続きますが、いざリリース申請に出したところ、App Store Reviewガイドラインの5.1.1(xi)に引っ掛かっている理由のため、リジェクトにされました。 ガイドラインに引っ掛かった原因は、アプリ内に下記のようなRSSから記事を取得して表示する機能を実装していたものの、その中に「新型コロナウイルス」に関する記事が表示されていたため、リジェクトされていました。

そのため、サーバサイド側でRSSから記事を取得する際、タイトルに「新型コロナウイルス」に関する単語が入っている場合は表示しないよう、一時的に対応しました。その後、もう一度審査に出したところ、何の問題もなく審査を通過しました。 外部からの取得したデータを表示する場合などは、念のため気をつけましょう。

リリース周りが大変

iOSとAndroidではデメリットのひとつ目にも記載していますが、リリースまでの手順が異なるため、OSごとに対応が必要となってきます。ビルドからデプロイまで全て手動で行うのは大変でしたが、現在ではFlutterなどモバイルに特化したCI/CDツールであるCodemagicの導入を検討しています。

終わりに

今回、SwiftとKotlinで実装されたアプリをFlutterに移行した話をご紹介しました。チームメンバーのほとんどがFlutter未経験にもかかわらず、スムーズに移行を進めることができました。

この移行プロジェクトは自分からチームリーダーに提案をしたものですが、快く承諾していただきました。メンバーが提案しやすい環境があること、感謝しています。

未経験者でも、簡単にモバイルアプリ開発をすることができます。Flutterを触ったことのない方は是非、Flutterを触ってモバイルアプリ開発をしてみてください。

てっくらんち ~ クリーンアーキテクチャ入門 ~

はじめに

レバレジーズ株式会社エンジニアの高橋です！ 本日から、社内で毎週金曜日に行なっている勉強会、通称「てっくらんち」を皆さんにお伝えします！！

「てっくらんち」ってどんな勉強会？

お昼にやっているゆる〜い勉強会です。

毎週金曜日に開催しており、社内エンジニアの発表をお昼ごはんを食べながら聞くスタイルの勉強会です。 発表者は毎回一人で、発表時間は15分〜30分程度、質疑応答も含めると30~45分ほどの内容になっています。

ジャンルは様々で、エンジニアの生存戦略的な内容から、Dockerの踏み込んだ話まで、技術に関する内容であれば何でもOKな形をとっています。 発表者も様々で、あらゆる部署のエンジニアや、フリーランスでJoinされている方、支店や外勤のエンジニアなど、社内の多くのエンジニアが参加しています。

本日のてっくらんち

• 発表日：2020/06/19
• 発表者：住村 翼
• 題目：クリーンアーキテクチャ入門

てっくらんち ~ クリーンアーキテクチャ入門 ~

感想

今回は、住村さんから弊社でシステム化をしているお米予約システム＆お米を炊く例にして、クリーンアーキテクチャの概要から、実際に実装をするときどうするかをお話していただきました。
特にDIに関して、メリット、デメリットを踏まえて教えていただいたので、実装するときに今後の実装に活かしていこうと思います。

We Are Hiring

レバレジーズでは「てっくらんち」のような社内での勉強会や「レバテックラボ」という外部の講師を招いたパブリックな勉強会も開催しております。
また、横浜に開発拠点ができるなど、新たな働き方も創出しています。
弊社に少しでも興味を持っていただいた方はご連絡いただけると幸いです。

https://recruit.jobcan.jp/leverages/list?category_id=5142recruit.jobcan.jp

コスト最適化のワークショップに参加してきました

こんにちは、msatoです。

AWS re:Invent2019のワークショップ「ENT206 Optimize AWS costs and utilization with AWS management tools」のレポートになります。

概要

この実践セッションでは、AWSのツールとサービスを使用して、ビジネス全体のコスト最適化を推進する方法を学びます。 AWS IAMポリシー、AWS予算、AWSコストエクスプローラーなど、コスト管理のコアツールを検討します。これらのツールを習得した後、Amazon Athenaを使用した高度な課金分析と、Amazon QuickSightを使用した視覚化について詳しく説明します。

原文

In this hands-on session, you learn how to use AWS tools and services to drive cost optimization throughout your business. We look at the core tools of cost management, such as AWS IAM policies, AWS Budgets, and AWS Cost Explorer. After mastering these tools, we go deeper into advanced billing analysis with Amazon Athena and visualizations using Amazon QuickSight.

スピーカー

Nathan Besh Cost Lead, Well-Architected , Amazon Web Services Arthur Basbaum AWS Cloud Economics , Amazon Web Services

レポート

Governance

AWS BudgetsとIAM Policiesでコストの統制を行います。

• AWS Budgets
• 使用量と支出を通知することができる(予算を超えたらアラートを飛ばす)
• 予算の使用状況をレポートにして、配信することが可能
• IAMポリシー
• ユーザが起動できるインスタンスのタイプを指定することができる(t3.larage以下を起動できるようにするなどができる)

Visualization and Analysis

Cost ExplorerやGlue、Athena、QuickSightを使ってコストを可視化します。

• Cost Explorer
• 無料で使えるコスト分析ツール
• コストと使用状況を分析し傾向やコスト要因を把握することができる
• Glue
  • マネージド型 ETL (抽出、変換、ロード) サービス
• Athena
• Amazon S3 内のデータをSQLを使用して分析できるサービス
• GlueとAthenaを活用したコスト可視化
• コストのレポートをS3に保存する(請求ダッシュボードから可能)
• Glueを使ってデータを分析しやすい形に整えます
• Athenaで分析する

クエリの例)

Top10 アカウントIDごとのコスト

select "line_item_usage_account_id", round(sum("line_item_unblended_cost"),2) as cost from "workshopcur"."workshop_c_u_r"
where month(bill_billing_period_start_date) = 12 and year(bill_billing_period_start_date) = 2018
group by "line_item_usage_account_id"
order by cost desc
limit 10;

Top10 EC2 Costs

select "line_item_product_code", "line_item_line_item_description", round(sum("line_item_unblended_cost"),2) as cost from "workshopcur"."workshop_c_u_r"
where "line_item_product_code" like '%AmazonEC2%' and month(bill_billing_period_start_date) = 12 and year(bill_billing_period_start_date) = 2018
group by "line_item_product_code", "line_item_line_item_description"
order by cost desc
limit 10;

Right Sizing

インスタンスのサイズを適切にして、コストをカットします。

• インスタンスのサイズを一つ落とすと、料金は半分になる
• Cloudwatch
• インスタンスで使用しているリソースの状況を確認する
• Cost Explorer EC2 Optimaization
• cloudwatchで取得しているメトリクスからインスタンスサイズをレコメンドする
• cloudwatch agentからのメトリクスもレコメンドに使える

Pricing Models

Savings Planを使って、コストの割引を受けます

• Savings Plans
• 1年間または3年間、一定の利用料をコミットするだけで、その利用料に対して割引がてきようされる
• Cost Explorer > Savings Plansから見積もりを確認することができる
• RI report
• Cost Explorer > Savings PlansからRIのレコメンドを確認できる

Well-Architected Tool

AWSのベストプラクティスにそったアーキテクチャにすることで、コストを最適化します。

• Well-Architected Tool
• サービス > Well-Architected Toolから使用できる
• 運用上の優秀性、セキュリティ、信頼性、パフォーマンス効率、コスト最適化の5つの柱からなる質問に答えることで、現状とベストプラクティスを比較できる

まとめ

弊社でもリザーブドインスタンスを購入するなど、コストカットの取り組みは行ってきました。 このセッションを聞いてまだまだできることはありそうだと感じました。

コストについて知って、お得にAWSを使いましょう。

AWSツールを使用したGitflowに参加してきました

こんにちは、msatoです。

AWS re:Invent2019のワークショップ「DOP202-R2 - [REPEAT 2] Implementing GitFLow with AWS tools」レポートになります。

概要

短命の機能ブランチを利用することは、多くのチームにとって最適な開発方法です。このワークショップでは、AWSツールを使用してマージとリリースのタスクを自動化する方法を学びます。 AWS CodePipeline、AWS CodeCommit、AWS CodeBuild、AWS CodeDeployを使用してGitFlowを実装する方法の高レベルフレームワークについて説明します。また、事前に構築された例を見て、個々のユースケースにフレームワークをどのように採用できるかを調べる機会もあります。

原文 Utilizing short-lived feature branches is the development method of choice for many teams. In this workshop, you learn how to use AWS tools to automate merge-and-release tasks. We cover high-level frameworks for how to implement GitFlow using AWS CodePipeline, AWS CodeCommit, AWS CodeBuild, and AWS CodeDeploy. You also get an opportunity to walk through a prebuilt example and examine how the framework can be adopted for individual use cases.

スピーカー

Ashish Gore　Sr. Technical Account Manager , Amazon Web Services Amit Jha　Sr. Solutions Architect , Amazon Web Services

GitFlowとは

git-flowは、正確にいうと Vincent Driessen 氏が提唱する「A successful Git branching model」というブランチモデルをサポートするツール（コマンド）の名称です。

一般的には、モデルとツールのどちらの名称としても使われています。git-flowでは、役割が決められた5種類（場合によっては6種類）のブランチを切り替えながら開発を進めていきます。

ブランチの作成やマージに決まりを設けることで、複数人での開発時にもブランチをわかりやすい状態に保つことができ、不用意なマージによる問題を避けることが可能です。

[参考 Git-flow ～Gitのブランチモデルを知る～] (https://tracpath.com/bootcamp/learning_git_git_flow.html)

資料

AWS TOOLS GITFLOW WORKSHOP

レポート

Codeシリーズを始めとしたAWSサービスを使って、Gitflowを実現するワークショップです。

使用するAWSサービスの概要

今回のワークショップで、使用するAWSサービスの概要です。

CodeCommit: Gitリポジトリをホストするサービス CodePipeline: 継続的デリバリーサービス CodeBuild: ビルドサービス(ソースコードのコンパイル、テスト) CodeDeploy: デプロイを自動化するサービス Lambda: サーバレスでコードを実行できるサービス Cloudformation: AWSリソースのプロビジョニングサービス Elasticbeanstalk: ユーザがインフラを管理しなくても、アプリケーションをホスティングできるサービス

ブランチが作成された際の流れ

ブランチが作成された際に、自動で環境が立ち上がりコードがデプロイされます。 流れは以下です。削除時も同様です。

1. ユーザがCodeCommitリポジトリにブランチを作成する
2. Codecommitトリガーで、ブランチが作成されたのを検知してLambdaを呼び出す
3. LambdaではCloudformationを実行する
4. Cloudformationでは、CodePipelineとElasticBeanstalkが作成される。

まとめ

ブランチを作るだけで、環境が立ち上がりデプロイされるのはとても楽ですね。

個人的には、CodeCommitのトリガーが便利だと思いました。 AWSのサービスなので、Lambdaとの連携が簡単です。 (githubでもwebhook使えばできます)

Gitのブランチモデルに合わせて、最適なデプロイの流れを作っていきたいです。

AWS reinventを快適に過ごすためのTips

こんにちは、msatoです。

12月1日よりはじまったAWS re:Invent 2019に、当社からは私を含むエンジニア2人が参加しました。

re:Inventでの学習効果を最大限に高めるために、快適に過ごすためのTipsを紹介します。

移動編

reinventは複数の会場があり、会場によってはバスで数十分かかります。 地図上はさほど離れていない用に見えますが、端から端までで約4kmあります。 (MGM GrandからEncoreまで、徒歩で約50分)

会場内もとにかく広いです。 移動で消耗しないためのTipsを紹介します。

歩きやすい靴は必須

re:Inventでは、とにかく歩くことになります。

日によっては、歩数が20000歩を超えたこともありました。 (日本人の１日あたり平均歩数は、約8000歩)

靴ずれや移動で疲れないために、歩きやすい靴必須です。

帰国日が一番多かったですが、reInvent期間中は平均15,000歩くらいになっています。

セッションはできるだけ同じ会場にまとめる

できるだけ移動を少なくできるように、予定を組むことをおすすめします。 会場間の移動で、30分以上かかることもあるので時間を無駄にしてしまいます。

有意義に過ごすために、日によって会場をまとめる・overfloowルームを活用するなどしたほうがいいです。

こまめな給水を心がけよう

周りが砂漠のため乾燥しています。 疲労をためないために、こまめな水分補給をおすすめします。

給水スペースは会場の至るところにあるので、活用しましょう。

宿泊編

ホテルは「ザ・ベネチアン/パラッツオ」おすすめ

「ザ・ベネチアン/パラッツオ」がおすすめです。

理由は、メイン会場だからです。

メイン会場では、Keynoteや前夜祭(MidnightMadness)が行われます。 単純に行く回数が多いと思われるので、宿泊先にしてしまえば移動時間を短縮できます。 (私自身も、期間中毎日1回は「ザ・ベネチアン/パラッツオ」行きました)

水の確保が大切

ホテルの部屋にも水のペットボトルがありますが、高いです。 また自販機もないため、水の確保が面倒です。

近くのドラックストアでまとめて買うのがおすすめです。 「WealthMart」「CVS」などで買うことができます。

1ガロン(約4リットル)の容器で買うとコスパがいいです。 初日に1人 1~2本買っておけば手間が少ないです。

同じことを考える人は多いみたいで、初日は売り切れてました。 できるだけ早めの時間に買いに行くことをおすすめします。

写真撮り忘れましたが、こんな感じです。

ポータブル加湿器を持っていこう

ラスベガスはとにかく乾燥してます。 私は１日目、就寝時に口の中が乾きすぎて起きました。

日中のパフォーマンスを低下させたいために、睡眠の質は確保したいところです。

タオルを濡らして加湿するのもいいのですが、最近は持ち運びに便利な小型の加湿器があります。

値段もリーズナブル(1000~2000円)なので、日本で買っておくことをおすすめします。

セッション編

予約できなかったセッションでも、当日並べば受けれる事が多い

セッションは事前に予約することができます。 しかし、人気のセッションを予約するのはなかなか難しいです。

「どうしても受けたいけど、予約を取れなかった」場合は、当日並んでみましょう。 当日席が用意されているため、並んでみると受けれることが多いです。

開始の30分~1時間前に行けば高確率で受けれます。 人気のセッションは、1時間半前くらいに並ぶのをおすすめします。

ハードウェア系のワークショップ受けてみよう

ハードウェア系(Deepracer、Deepcomposer、Alexa、IoT系)のワークショップおすすめです。

おすすめの理由は、2点あります。

• 普段触る機会がない人が多いと思うので、刺激になる
• ワークショップでハードウェアを貰えることがある

今回は、DeepcomposerやDeepracerがもらえたそうです。 (聞いた話では、昨年はAlexaとかももらえたとか。)

知識も増えて、帰国後も学習できるハードウェアが手に入り一石二鳥ですね。

AWS Deepcomposer

セッションカタログはこまめに確認しよう

reInventの期間中もセッションやワークショップは追加されます。

追加されたセッションは一瞬で埋まってしまうこともあります。 こまめに確認して、受けたいセッションを逃さないようにしましょう。

「new launch」とかでセッションカタログを検索すると見つけやすいです。

最後に

実際にreInventに行ってみて、知っていたら便利そうなことをまとめました。 快適に過ごして、reInventの学習効果を最大限にしましょう。

AWS Lambdaとストレージゲートウェイを使用したグローバルストレージの設計に参加してきました

こんにちは、msatoです。

AWS re:Invent2019のワークショップ「ARC313 Architecting Global Storage with AWS Lambda and storage Gateway」のレポートになります。

概要

企業は、AWSテクノロジーのベストプラクティスを使用して、オンプレミスとクラウドの両方で世界中の生産施設に資産を同期する方法を探しています。このセッションでは、AWS Lambda、Amazon API Gateway、Amazon Simple Storage Service（Amazon S3）、AWS Storage Gateway、AWS Directory Service、およびAWS Fargateを使用して、世界中の従業員のコラボレーションを可能にするサーバーレスグローバルストレージプラットフォームを構築する方法を学びます。

Companies are searching for ways to synchronize their assets to their production facilities around the world, both on-premises and in the cloud, using best practices with AWS technologies. In this session learn how you can use AWS Lambda, Amazon API Gateway, Amazon Simple Storage Service (Amazon S3), AWS Storage Gateway, AWS Directory Service, and AWS Fargate to build a serverless global storage platform to enable employee collaboration around the world.

スピーカー

Paul Roberts Rob Hilton Principal Solutions Architect , Amazon Web Services

レポート

構成図

動画ファイルを格納できるグローバルストレージの構築です。

具体的にはアテナに動画編集者がいて、トロントから確認したいというケースでした。 (アテナは読み書きが可能で、トロントでは読み込み)

AWSのマネージドサービスを使用して、サーバレスで作ります。

使用するサービス

• S3
• 動画ファイルを置きます
• masterとstudio(読み込み専用)というバケットを作ります(masterがアテナで、studioがトロント)
• StorageGateway
  • クライアントからSMBでS3をマウントさせるためです
• AWS Fargete 　- フロント部分に使います
• AWS API Gateway
  • リクエストを受けて、lambdaを起動します
• AWS Lambda
  • masterにアップロードされた際に、studioのバケットにコピーします

まとめ

オンプレで作ったらかなり手間がかかりますが、AWSのサービスを使うことで簡単に作れました。 また、サーバレスのためコストや運用の手間もほとんどありません。

StorageGateway使ったことがなかったので、ワークショップで実際手を動かしながら作れたのはいい経験になりました。

グローバルストレージを構築する機会はなかなか無いと思いますが、このアーキテクチャは色々応用が効く気がします。

JAWS-UG 初心者支部#21 reInventReCap＆LT大会で登壇してきました

こんにちは、msatoです。

reInventで学んだことのアウトプットのために、JAWS-UG 初心者支部でLTしてきました。

JAWS-UG 初心者支部とは

以下引用です。

AWSをこれから活用したい人や一緒に勉強する仲間が欲しい人を主なターゲットとしています。 AWSへの理解を深めていただくお手伝いをすることはもちろんのこと、みなさまがより楽しく学び、よりステップアップしていくためには不可欠となる、初心者支部の卒業→JAWSの他支部へと巣立つためのお手伝いをします。

イベント概要

12/6-12/6にラスベガスで開催されたre:InventのreCap(振り返り)と、LT大会が行われました。

JAWS-UG 初心者支部#21 reInventReCap＆LT大会

登壇してきました「IAM Access Analyzer使ってみた」

reInvent期間中に発表されたサービス「IAM Access Analyzer」について話してきました。 資料は公開していますので、ご興味のある方は是非ご覧になってください。

伝えたかったことは以下です。

• ポリシーの設定ミスによる意図しないアクセスを防ぐとことができるサービス
• 無料で簡単に有効化できる
• 「AWSアカウント作成時のやることリスト」に入れたほうがいいと思うほど、有用なサービス

最後に

「アウトプットしないことは知的な便秘」LTで度々出てきて印象的でした。 いい言葉ですね。アウトプットしなきゃという気持ちになります。

JAWS-UGではアウトプットの機会を提供してくれています。

特に初心者支部はLT初心者でも、発表しやすい雰囲気があります。 今回のようなLT大会もたまにやっているので、初めてのLTにおすすめです。

HRE（Human Resource Engineering）を提唱して開発リソースを整理する試み

Leverages Advent Calendar 2019 - Qiita 最終日を担当します。ITインフラの研究職からSREを経て、現職ではいつの間にかVPoEのようなことをやっています久松です。キャリアを拗らせて唸っているうちにこういうキャリアになった、と説明しています。

今回はHRE（Human Resource Engineering）と題しましてエンジニア組織のカタチとマネージメントについてお話させていただきます。昨今のエンジニア組織マネージメントの難しさに悩む方々は多いかと思います。組織図や開発関係者一覧、タスク量計算をしていて「何だこれは」と思っている方々も多いのではないでしょうか。私自身、VPoE的な業務に取り組むにつれ、ふとインフラエンジニアだったあの頃と似通った着想に至りました。組織図をCDPっぽく描くというのが今回の主テーマです。何故EMやVPoEといったソフトなスキルを持ったポジションが求められるのか、エンジニア組織運営の難しさを理解する一助になれば幸いです。

従来型の会社組織

データセンター（会社）の中で全てが収まっています。室温から空調まできちんと整えられています。オンプレミス環境のオペレーションに関わったことのある方は思い当たると思いますが、物理サーバのホスト名に拘ったりして可愛がりますね。落ちると悲しいし、涙します。

増設（採用）は好ましいことですが、ラック（会社の物理空間）に限界もあります。計画はしっかりとデータセンター管理会社（バックオフィス）と連携しておく必要があります。

サーバやプロセスの監視も必要です。異常発生時はその現場に駆けつけましょう。ハードウェア（フィジカル）・ソフトウェア（メンタル）・ネットワーク（人間関係）など様々な課題が有りえますので、それらを吸い上げる仕組みや関係性づくり（1on1等）が必要です。

従来型組織

遠隔開発拠点

都内でのエンジニア採用が難しいと感じた場合、遠隔地で採用をかけるケースも多く見られます。海外でオフショアだったり、国内でニアショア、もしくは地方支店の一角を開発拠点にするケースもあります。その場合、意識すべきは意思疎通です。遠隔地に居る分、伝送遅延はありますので何往復も意思疎通するとその分ロスが発生します。何の機能を本社に残し、何を機能を外に出すのかが重要になります。社内組織として設ける場合は「外注感」「下請け感」が出ないようにしなければならず、機能ごと任せてしまうというのは一つの解法だと考えています。

遠隔開発拠点

SES

正社員でまかなえない業務が発生した場合、SESが登場します。フリーランスだったり所属会社の正社員だったりします。契約単位は時間のケースが多いですね。さながらパブリッククラウド的な形。同じドメイン（社内）で稼働をお願いするためにDirect Connect利用のケースもあるでしょう。ALB（タスク分配）やCloudWatch（勤怠管理）も必要です。

SES

請負、コンサル

機能を部分的に他社に依頼するケースもあります。アプリケーション開発を受託開発に出すケースもあれば、チューニングといったスポット依頼のケース、AI開発や分析のような専門性の高いケースもあります。

AWSで言うところのManaged Service利用のようなセットアップと運用を丸々委託するパターンもあれば、Facebook APIやTwitter APIなどをインターネット経由利用するように基盤に乗っかるパターンもあります。

重要なこととして障害・仕様変更・サービス終了などにより依頼先が（一時的にでも恒久的にでも）応答しなくなった場合、極力本番環境に影響しない形での実装と運用が必要です。私も前職ではFacebookベースのサービスのインフラを担当していましたが、先方都合の部分はいかんともし難いものでした。「他人の褌で相撲を取っている」という感覚を忘れてしまうと大事になりがちです。

請負、コンサルとの契約

社内副業

俄に流行の兆しですね。新卒採用イベントにて他社さんの会社説明などを聞いていると「実は取り組んでいます」という会社さんがちらほら居られます。これはつまり外注という選択を取る前に社内の余剰リソースでタスクを消化させようという動きです。余剰リソースを有効活用という意味合いでは仮想化のようなものですね。

加えて弊社調査でも言及させて頂きましたが、若手エンジニアには限られた時間でできるだけ複数の経験を積みたい（複業）というタイムパフォーマンス志向が見られます。

余剰リソースの有効利用や、複業に応える解答としては肯定できる社内複業制度ですが、労務や制度的な難易度が高いです。実務的な観点で問題となるのは「タスクの切り分けとマネージメント」が挙げられます。

社内副業制度

クラウドソーシング

タスクを細切れにして外部に依頼します。特にインフラを構築せずともリクエストを投げるとリザルトが返ってくる様はさながらLambdaです。ただしプロセスの信頼性は低く、タイムアウトする可能性もありますのでプロセス管理が重要となります。

クラウドソーシング

（エンジニア）組織のミライノカタチ

経営層の視点で「働き方改革は誰のためにあるのか？」と問われると「メンバー層」を対象にしたものではないかと答えています。特に能動的な行動を好むメンバー層への働き方改革の影響は大きく、所謂自社メディアと呼ばれる企業、それも他社との比較がしやすいITベンチャー密集区ではその直撃を免れていないように思います。

あるスタートアップ事業さんでは正社員は数名のみが在籍し、タスク分解を徹底し、残りは全てフリーランスで事業展開をされています。出勤日は固定ではなく、カレンダーに稼働時間を登録して貰った上で消化していくというスタイルを取られていたりもします。稼働可能な時間（スキマ時間）に稼働するスタイルはスポットインスタンスと言えます。

経営目線で考えると会社とは何か（少なくとも社員数は重要ではなくなる）、正社員には何を期待し何を残すのかを考えなければならない時代に来ています。オンプレミスとパブリッククラウドのハイブリッド構成だとデータベースをオンプレミスに残すケースが多いですが、会社組織であれば事業イメージをカタチにする企画職や、開発管理をするPM業務が該当するかと思われます。こうした人達をどこから連れてくるのか、育てるかというのも課題となってきます。事業コンセプトだけが会社に残るケースもあるのではないでしょうか。

一方、メンバー視点で考えると働き方改革を前に「ええじゃないか」と踊るのではなく、前回記事の指名される理由が必要になってきます。自分の自己責任が叫ばれる時代の中、どの立ち位置で、時間・成果のいずれの報酬体系で、どう渡り歩いていくのかを意識しなければなりません。また、弊社レバテック事業においてもこうした流動性の高い不確実な時代の流れを捉えつつ、日本一の相談相手として歩まなければならないと考えています。

タスク細分化による組織のミライノカタチ

最後に

働き方の多様化が進み、自社のみでの開発組織の完結が難しくなってきた現在、人的マネージメントは困難を極めています。だからこそEMやVPoEといったソフト面の職種が登場したのだと考えています。

こうしたデザインパターンに載せて考察していくとHRとSREで共通点が見つかったり、マネージメント上の課題が発見できたりするというのが今回提唱したHREです。インフラエンジニアの基本であるトポロジ図やCDPに倣って、自社の組織図を書いてみるのも一興ではないでしょうか。

今回は書くと棘のあることはあえて伏せているのでいつの日かあるかも知れない書籍化に取っておきます（DRとかオートスケーリングとかマルチクラウドとかクラウド移行とかリプレイスとか）。

qiita.com

FirestoreとLINE Messaging APIでチャットシステムを内製してる話 〜運用での学びを添えて〜

はじめに

はじめまして！
Leverages（レバレジーズ）Advent Calendar 2019 18日目担当の吉澤です。

普段は、看護師向けの転職サイトや社内システムの開発・運用などをしています。
今回は、LINEでの顧客対応に用いられるチャットシステムの構築についてと実際運用してみてどうなの？みたいなところを書いていこうと思います。

何作ってるの？

↓ざっくりこんな感じのやつを作っています。

開発に至った背景については以下の記事に書かれています。

markezine.jp

LINEのMessaging APIとFirestoreを用いて、社内のSFA/CRMシステムから顧客とLINEのやり取りができるような機能です。

以下、内製のSFA/CRMシステムを社内システムと略します。

構成

全体的な構成としては以下の様になっています。

サーバーサイド

まず、ユーザーがメッセージを送るとLINEサーバーからWebhookを受け取ります。受信時のメッセージの取りこぼしがあると、そもそものコミュニケーションツールとしての役割を満たせなくなってしまうため、ここは特に気を使わなければならない部分でした。
そのため、Webhookを受け取ったらペイロードをそのまますぐにキューに追加し、仮に後続の処理に問題があったとしても、ログから復旧できるような構成にしています。

サーバーサイドは慣れ親しんでいたという理由もありlaravelを利用しています。
キュードライバはAmazon SQSを使おうかとも思いましたが、当時SQSがFIFOに対応していなかったこともあり1回のみのメッセージを保証したかったのでRedisを利用しています。
後は順にキューから取り出し、Firestoreへの保存など受信時の処理を行っています。

クライアントサイド

次にメッセージを表示するクライアント画面ですが、ここはVue.jsとfirebaseのsdkを用いて、該当ユーザーのメッセージのcollectionをリッスンし、変更があればステートに追加していくといった割と一般的な処理になっています。
自力でWebSocket使って...みたいなことをしなくていいのでfirebaseほんと楽で便利ですね！

ただ当時、「Firebaseの読み取り超過で○百万円飛んでった 😇」みたいな記事が上がっていたのと、実際にリリース後どのくらいの読み取りが発生するかが予想しづらい状況であったため、ドキュメントの読み取り数には警戒していました。

そのため対策としてメッセージを20件ずつローディングするようにしたり、オフラインキャッシュを利用するなどして読み取り数を削減していました。今思うとFirestoreの無料枠も大きいのでそこまで警戒する必要もなかったかもと思っています。

通知機能

メッセージ受信時の通知に関しては、FirebaseCloudMessagingとServiceWorkerを使ってプッシュ通知をしています。
普段、通知許可を求められると不快に感じてしまうタイプではあるんですが、こういう利用用途が限られていてユーザーに使ってもらうことが前提の場合はサクッと実装できて便利だなと思いました。
社内システムにおいては、サポートブラウザが限定できる点や実装効率の面でもPWA周りの技術のメリットを享受しやすいのではないかと思いました。

ーーー

全体的には、このような構成で何とか一年近く運用できています。

加えてメッセージのやり取り以外の面でも、LINEログインを用いたオウンドサイトからの登録や定期的なメッセージ配信など集客面での機能追加なども行っています。

最近、LINE側でも頻繁に機能追加されているので、いろいろできそうで面白いですね😉

運用してみて

このプロジェクトにおいては、技術面以外でも多くの学びがありました。

まず、これまで顧客とのLINEでの連絡は通常のLINEを利用していました。
これを内製のシステムに乗り換えるとなると提供されていない機能があったり、実装工数などの兼ね合いでどうしても今まで出来ていたことが出来なくなる機能が存在します。
狩野モデル *1 でいうところの当たり前品質が「本家のLINEで出来ていたこと」に該当していたように思います。
当然、利用者からすれば不便に感じる部分があったかと思います。

また、移行において仮にLINEで出来ていたことを実現できていたとしても、それだけではただ代替性が高いだけで、移行コストの方が高く感じてしまうのではないかと思います。(自分に置き換えてもそうなので、ｗ)

そのような状況の中で、社内システムの開発・運用において以下のような点が重要だと感じました。

背景・目的への理解

何か新しいものを導入する際にはその背景や目的を明確にすることはもちろん、それが現場の人たちの中でも共有され、腑に落ちているかが重要だと思います。

よく職種間のやり取りにおいて、専門的な用語でなく相手が理解しやすい言葉でのコミュニケーションを心がけようと言われますが、たとえ言っている内容を理解できたとしても、それがどのくらい重要であるかという温度感は担当する役割によって違っていたりします。
全員が納得するのは中々難しいかもしれないですが、そういった認識のギャップを埋めていく動きも必要であると感じました。

ただ納得してもらうために、不用意に決定を曲げてしまうと本来の目的から逸れていってしまうこともあるので、その塩梅は中々難しいように感じます。

実際にはチームメンバーが現場への説明、疑問や不安の払拭、改善要望に対する対応目処の伝達など、とても献身的に働きかけてくれたこともあり、理解が得られていったように思います。

エンドユーザーの視点を持つ

ここでいうエンドユーザーはサービスにおける最終的な顧客のことを指します。

社内システムの開発において、システム自体の利便性を高めるということはとても重要ですが、それが最終的にどうユーザーに還元されるのかという視点を持つことも必要だと思います。

例えば

• システムのレスポンス速度を改善することによって、現場の業務効率が上がり、ユーザーへの対応速度が上がる

• データを入力しやすくすることによって、今まで個人の中に埋もれていたような情報が蓄積されるようになり、ユーザーがより詳細な情報を得られるようになる

などのようなことです。

普段、開発をしていると目の前のタスクの消化だけに目が行ってしまったり、自分は何のサービスを作っているのかが分からなくなってしまう時があるので、立ち返るという意味でも重要であるように感じます。

また、担当の職域が違うとその担当内での視点に寄ってしまいがちですが、同じ視点で議論することによって共通認識が取れやすくなるように思います。

同じサービスを提供する者同士として、目的は共通であるという前提の理解と、お互いがユーザーの視点に立ち、何ができるかを一緒に考えていくという姿勢が重要だと感じました！

We Are Hiring !

レバレジーズでは一緒に働く仲間を募集しています！
創業14年目を迎え、より一層テクノロジーでの課題解決が求められるフェーズになってきたように思います。
技術での事業貢献、ユーザーファーストでのサービス作りなどなど、ご興味ある方、是非ご連絡お待ちしております！！

https://recruit.jobcan.jp/leverages/show/b01/7682recruit.jobcan.jp

*1:顧客満足度に影響を与える製品やサービスの品質要素を分類し、それぞれの特徴を記述したモデル | wikipedia:狩野モデル

「横浜」に「開発拠点」作ってみた

はじめに

レバレジーズメディカルケア株式会社CTOの内田です！

横浜に開発拠点を作ってみたらイイ感じだったので書いてみました、興味ある方どうぞ！

本題

福岡など地方にサテライトオフィスなど聞く事も増えました。 IT会社（だけではないですが割愛）は東京に集中していて、これは諸説ある所だと思っています。

なので本社は渋谷スクランブルスクエアですが今回、横浜にも開発拠点を作ってみました。

社長と拠点作成の話をしたあと「身体バキバキに鍛えたいッス！」と雑談してたら、 ここの本格的な筋トレ器具も何機か横浜に送ってくれる事に、オフィスはここの3F、キレイだし横浜駅も徒歩圏で、鍛えれるし、素敵です。

↓いきなりですがかわいい横浜拠点のメンバーたちｗ

それでは、実際に 横浜を選んだ自身とメンバーたちによる比較を感じたままに紹介します。

比較 (体感比)

通勤

渋谷本社への電車はギュウギュウなのに対し、横浜支店は逆方向だから空いています。横浜近郊に住んでいる人以外にもメリットがあるようで、朝の集中力はチームとしても大事にしているので嬉しいです。

家

賃貸相場情報をHOME'sで見てみました。(2019/12時点)

渋谷駅

不動産・住宅情報サイトLIFULL HOME'S - 渋谷駅の家賃相場

• 1K 12.13万円
• 1LDK 28.08万円
• 2LDK 51.59万円

横浜駅

不動産・住宅情報サイトLIFULL HOME'S - 横浜駅の家賃相場

• 1K 8.61万円
• 1LDK 14.11万円
• 2LDK 21.69万円

駅付近の相場だと思いますが参考にはなりそうです、思ったよりもすごい差でした。（横浜駅から一本離れれば更に安いですがそこは一旦割愛）

入外出 (出勤やランチ)

渋谷

どこを歩いても人が沢山でお店も混みがち、エレベーターもなかなか来ない。色々と待ったり混雑が多めです。

横浜

意外にも平日は混まなくて、エレベーターもすぐ来る。色々と待たなかったり混雑が少なめです。

まとめ

総合した効果として皆がいうのを要約すると以下、

• 集中力が上がった
  • 通勤コストの削減と、スモール化による周りの目の減少と考えています。
• 会社への好感度が上がった
  • 働き方の多様化に応えて貰えたことや、この総合点の高い環境に感謝しているのかも。

これがQoLの重要性なのだと感じる日々です。

オマケ

スカイスパのコワーキングスペースでの1on1

スカイスパに仕事上がりに徒歩数分で行けるのも最強ポイントですｗ

ちなみに、プロサウナー達の厳正な審査による"今行くべき全国のサウナ11選"で6位の施設がスカイスパです。

ぜひお試しあれ！

エンジニア生存戦略論と、生存に向けての場の提供

メディアシステム部 部長の久松です。

今回のテーマに関わってくるので自己紹介させて頂きますと 2000年からIT革命真っ只中のIT業界にインフラの研究開発から入り、20年が経とうとしています。

• 20代　大学教員を目指す
  • インターネット動画配信、P2Pをテーマに研究員として活動
  • 博士進学翌年にリーマンショック、その後 事業仕分け・震災
• 30歳　学術からビジネスへの転身
  • 博士取得と共にポスドクのポジションが無期延期になり、就活も難航し、就職課に「進路未定」で提出
  • 高学歴ワーキングプアとしてアルバイトプログラマに（額面で月給15万円）
  • ベンチャー企業に就職後、やがてインフラ責任者をやりながら気がつけばリクルーターに
• 現職への転職
  • エンジニアの取りまとめの役割ですが、ほぼVPoE
  • エンジニア紹介事業のレバテックでは技術顧問としてエージェントの専門性向上を担当
  • エンジニアキャリアに悩んだり採用したりするうちに新卒・中途採用、オンボーディング、新卒・博士キャリアをテーマにしたセミナーをするようになる

今回は私が現在、レバレジーズ社員やエージェント教育の過程でお話しているエンジニアの生存戦略とその機会提供についてご紹介させて頂きます。

エンジニアを勤め上げるにあたっての脅威

人生100年時代と言われている中、年金の支給タイミングの後ろ倒しを加味すると80歳程度までは 何かしらのキャリアチェンジ・ジョブチェンジを繰り返しながら行きていく必要があります。 特にITエンジニアとしては

• 技術トレンドの移り変わり
• AIによる自動化
  • Sketch2CodeだったりAmazon CodeGuru Reviewerだったり足音は聞こえますね
• 「巨人の肩の上」に乗ったできる若手
  • 構築がスムーズな開発環境、溢れる教材、溢れるソースコード、QA環境・・・
• 海外からの高度人材
• フリーランスやクラウドソーシングの一般化による有期のスポット人材の増加

を考えなければなりません。

生き残りやすいエンジニアの特徴

私自身が事業仕分けられたということで需要の底を経験したということもありますが、20年の間に

• ITバブル
• クラウドバブル
• SNSバブル
• ソーシャルゲームバブル
• AIバブル

と各種のバブルと共に数多くのエンジニアの栄枯盛衰を見ることができ、生き残りやすいエンジニアの特徴が見えてきました（図）。 これを意識し、メディアシステム部のエンジニアには様々な機会に挑戦してもらっています。

エンジニア生存戦略

ベースとなる基礎知識

計算機の基礎、インターネットの基礎が挙げられます。特にインターネットの低レイヤについての知識はJavaScriptのフレームワークのようなハイレイヤーの技術に比べると革新速度はゆっくりですし、パケット交換方式は当面続きそうなので臆することなく身につけておくことをおすすめします。

専門性 2つを時流に合わせて変化

ヒトとは基本的に怠惰なものなので「可能であれば身につけた一つの技術で生涯食べていきたい」と思いがちです。 ただIT業界とは無情なもので5年程度でパラダイムシフトが発生し、身につけた技術は骨董品になります。 加えていかにも流行りそうな顔をして近づくバズワードというのもあります。

どちらか一方の専門分野が廃れても良いように2つの専門性、加えて時流に合わせて変化させることが必要です。

コミュニケーション力

他業種とのコミュニケーション力です。よくあるできるエンジニアの凋落パターンとして、

「いつも何をやっているのかよく分からないし、何を話しているか分からないし気難しそうなので話しかけにくいけど流行りの技術を身に着けているらしいので今は仲良くしておくと得だ」

と、周囲に思われているうちは需要があるものの、流行の終焉と共に周りから人が居なくなるというものです。

いざというときに周りに助けを求めるためにもコミュニケーションは取りましょう。転職してもフリーランスになっても繋がりは役に立ちます。

リーダーシップ、マネージメント、プレゼンテーション、教育、採用より2つ以上

いくつか補足をしておきます。

プレゼンテーション

プレゼンテーションはブログの投稿でも構いません。その人が何をしているかを自分以外に積極的に知ってもらう術を持っているかということです。

短期的には予算の出どころに対する説得や説明に繋がります。中期的には「指名をもらう」ことに繋がりますし、怠ると控え目に表現して「忘れられてしまう」ということになるケースも多くあります。 　

教育

教育は自分の持っている技術や知識を後進に伝えられるかどうかです。特に知識の更新の早いIT業界では、知り得た事柄をまとめて周りに拡散していくという能力が強く求められるようになっています。

採用

採用はチームビルディングに繋がります。人材不足という中でどれだけ自分の属している組織に勧誘し、人を引き込むことができるかというスキルは年々高まっています。

まとめ

1990年前後の金融バブルを解説する専門家の間でも目にしますが「バブルの中に居る人はバブルだと思わない」と仰っしゃります。先に述べたIT界隈のバブルの中の人も、永遠の需要と反映を信じている人が多く居ましたが、今のエンジニア売り手市場もバブルですし弾けてから改めて認知されるでしょう。

良いのか悪いのか分かりませんが80歳まで労働しなければならないと仮定した場合、ジョブチェンジやキャリアチェンジを想定して生きなければなりません。 　 一つのヒントとして「これは自分の仕事じゃないな」という仕事が目の前に現れたとき、それを受け入れるか拒否するかというのが分かれ目になるのではないかなと考えています。

Engineering Manager vol.2 Advent Calendar 2019 qiita.com