シリコンバレーのソフトウェアエンジニアは何が違うのか(4)
- 1回目の投稿では「なぜ品質の良いコードを書く必要があるのか」
- 2回目の投稿では「ビジネス面から見て、なぜ高速に開発をする必要があるのか」
- 3回目の投稿では「個人のパフォーマンスを最大化し合う仕組み」
ということについて投稿をしました。
今回は「ソフトウェアエンジニアに必要な能力」について触れていきたいと思います。
1.コードだけを書いているわけではない
ソフトウェアエンジニアに求められる能力というのはコーディングだけではありません。
下図に示す通り、ソフトウェアエンジニアに求められる能力は非常に多岐に渡ります。
- 技術調査、PRD, DesignDocの作成などの準備
- コードを書く、テストを書くなどの実作業
- バグのトリアージュ、タスクの作成などの運用作業
- ミーティングやインタビュー等のその他の作業
Greek Alphabet Software Academyで定義している「ソフトウェアエンジニアに求められる能力」より
全てに対して精通している必要はなく、「XX」になっている部分を100点中70点くらい、その他は30点くらい取れれば良いです。ただし全体としては「早く・質の良い製品やサービスを開発すること」なので、個々のタスクを効率よく進める能力が求められます。立場や職種にも依りますが、Googleのソフトウェアエンジニアが1日に受け取るメールは100通くらいと言われています。
「早く・質の良い製品やサービスを開発する」ためには、知識も必要です。単にコーディングだけでなく、アルゴリズムやデータ構造、そもそもコンピュータがどのようになっているのか、チーム開発やコミュニケーションなど、幅広い知識が求められます。
またポジションによっては、クラウドを使ったシステム設計の能力や、特定のフレームワーク、UI/UXについてまで求められることもあります。最近ではMachine LearningやAIというのもよく目にします。
Greek Alphabet Software Academyで定義している「ソフトウェアエンジニアに求められる知識」より
具体的にLinkedInにポストされているAdobe社の「Software Develpment Engineer」のjob descriptionを見てみましょう。
こんな事が書いてあります。
このポジションの役割
- 大規模なデータ処理のための高性能かつ耐障害性のあるシステムを構築する。
- プロダクトマネジメントと連携し、新機能を設計する。
- 大規模に機械学習(ML)モデルを学習、テスト、デプロイするためのインフラを構築し、最適化する。
- データサイエンティストと密接に連携し、研究やプロトタイピング段階のモデルを本番環境へ移行させる。
- アーキテクチャ、設計、コードのレビューに参加する。
- 問題領域を調査し、他の開発者と協力して解決策を見つける。
- 設計文書やコードコメント、プレゼンテーション、コード実行を通じてソリューションを文書化し、実証する。
必要なスキル・経験
- コンピュータサイエンスまたは同等の分野での学士号または修士号
- 3年以上の実務経験
- コンピュータサイエンスの基礎(特にアルゴリズムとデータ構造)を強く理解していること
- Java、Scala、またはPythonでの開発経験
- 過去にMLモデルの構築とデプロイの経験があると望ましい
- Javaのメモリモデルに関する理解
- モックフレームワークを使用したユニットテストケースの作成経験
- 新しい技術を学ぶ意欲
- 高いコミュニケーションスキル
なかなかハードル高めですね。でもこれができる人物には $113,400 - $206,300 ($1=150円で、1700万円 - 3000万円)の年収を提示してくれます。これは魅力的。
高い年収のオファーには、それだけ高い能力が求められるわけです。
2.今日の1分を惜しまない
1日が24時間、というこの絶対的なルールだけは、万国共通です。要はこの24時間、実際に仕事に使えるのは8 - 10時間程度をどう使うのか、というところが問題になってきます。
1つは高い能力で仕事を行うこと。これはここまでの投稿で一貫して話してきたことです。
もう1つは「仕事をしないこと」です。
正確に言えば「自動化できるところは徹底的に自動化を行い、自分の時間を確保する」ということです。
Googleでは「明日の10分のために今日の1分を惜しまない」と言われます。
つまり明日、手作業でやったら10分かかる作業を自動化するために、今日の1分を使おう、というわけです。
今日の1分が明日の10分になるのだったら、今日の48分は明日の8時間(480分=60分×8時間)になります。
そしてソフトウェアの素晴らしいところは一度動作設定をしたら、再利用できる点です。「明日の8時間」を何度も確保することができます。さらに素晴らしいことは、この仕組みを他の人も使えるようにすると、他の人は今日の0分で明日の8時間を確保できるようになるのです。
この空いた8時間で、あなたはさらに開発をすることができます。そうすると同じ能力でも普通に働くよりも2倍、3倍もの作業をすることができるようになるわけです。
3.嫌われ役はやらない
自動化の重要性は理解していただいたと思います。この開発と運用の自動化のことを「DevOps」と呼ぶわけですが、その根幹を担うのは「継続的インテグレーション(CI)と継続的デリバリー(CD)」です。
1回目の投稿で「なぜ品質の良いコードを書く必要があるのか」ということを書きました。ではその「品質」を誰が担保するのでしょうか。
「品質」にも色々とある訳ですが、コーディングスタイルの癖(スペースを開ける、開けない、行末にセミコロンなどなど)は、皆さんそれぞれに非常に「こだわり」を持っています。3人ソフトウェアエンジニアがいたら、3人とも好みのコーディングスタイルが違います。これを人間がチェックして、いちいち重箱の隅を突くようなコードレビューを行っていたら、ストレスが掛かりますね。
人間がやると時間の無駄ですし、指摘する方もされる方もストレスが掛かりますので、Linterというソフトウェアに自動でチェックをしてもらうようにします。コーディングスタイルを定義(一般的には既に公開されているコーディングスタイルのルールを採用)して、それに基づいてLinterに自動チェックをしてもらいます。
不思議なことに、人間に重箱の隅を突かれるとストレスを感じるものですが、機械的にエラーが出されるとストレスを感じにくいものです。最近はAIによる変数や関数名などのチェック、従来のLinterだけではなかなか検出しづらかった潜在的なバグの可能性なども、自動的にチェックができるようになってきました。
そうすると人間は最終確認として「きれいになったコードのチェック」(主にロジックのチェック)を行えば良く、レビューをする負荷が下がります。つまりレビューをするために必要な時間を少なくすることができるわけです。
このように「嫌なこと」(人間がやったらストレスが掛かるような作業)を自動化することで、人間をストレスから解放し「楽しい開発」の部分に集中させることができるのです。
4.人間はミスを犯す動物である
DevOpsを知る上で、もう一つ重要なのが「人間はミスを犯す」という考えです。
皆さんも1回くらいは経験がありませんか?
- 手動でデプロイしたら、一部ファイルが含まれてなくて、本番環境の動作が止まった
- 手動で本番環境にアップロードしたら、ライブラリの整合が合わなくて、コードの一部が機能しない
- 緊急で対応する必要があり、テストをすっ飛ばしてパッチコードをリリースしたら、そのパッチがバグっていた
あ、すみません。全部あります。DevOpsという考えがまだ一般的ではなかった20年前、よくありました。
20年前は、まだ小さなソフトウェアハウスで規模の小さいシステムでしたので、「ごめんなさい」ですぐに修正できましたが、クラウドで様々な仕組みを組み合わせてスケーラブルなシステムを構築する現在、世界中で何億人も居るようなサービスでこんなことをしたら、ものすごい金額の損害が発生します。
これを防ぐためにCI/CDにより、何重にもチェックを行い、デプロイを自動化するのです。
5.開発と運用をつなげるのがDevOps
あるシステムを作ったとき、それを開発したメンバーが直接運用することは稀です。規模が小さいスタートアップ企業や、個人的なプロジェクトではありますが、大規模なシステムになると開発と運用は必ず別部門が行います。
本来はこの2つのチームが協力し合いながら共通のゴールに向かうのが大事です。
究極の共通のゴールは「お金を稼ぐ」ことです。お金を稼ぐために、システムやサービスの価値をユーザーに届けることが重要になってきます。
そして開発チームとしては新しい機能を作ること+安定したシステムを作ること。
運用チームとしては、安定してシステムを運用することです。
DevOpsという考えが出てくる以前は、開発チームと運用チームは分かれていましたので、「開発して引き渡したら終了」「不具合があったら運用チームが対応する」といった”縦割り”が生じがちでした。
これが何が悪いのかというと、例えばシステムに致命的なバグがあったとします。開発チームと運用チームは、週1でミーティングをして同期していました。そうすると1週間バグを放置することになります。
一方、DevOpsでは開発チームと運用チームを一体として考えます。
ソフトウェアエンジニアは、運用のためのインフラや運用の実態を学びやすくなり、運用担当者もソフトウェアの開発プロセスやコードの見方を学ぶ機会を得やすくなります。これによりお互いの専門性を尊重しながら学び合う姿勢が育つことで、コミュニケーションが密になり、開発がより活発化するようになります。
具体的には、以下のような知識を共有します。
- どのようにCI/CDを改善するのか
- モニタリングには何を使うのか
- セキュリティ対策をどのおうに自動化するか
このように開発・テスト・デリバリー(リリース)までを自動化し、可視化できるようにすることで、開発チームと運用チームのコミュニケーションの垣根を取り外すのが、本来のDevOpsのあるべき姿なのです。
これにより自社だけで開発から運用までをワンストップでできる自律型チームが編成されるようになり、それぞれのメンバーがオーナーシップを持ってモチベーションを高く仕事をすることができるようになります。それは結果として、開発リリースを短縮することや製品やサービスの品質を向上させることに繋がり、究極の目標である「お金を稼ぐ」というところに繋がります。
まとめ
今回は主に「DevOpsの重要性について」書きました。書き始めると1冊の本になってしまいそうですので、このあたりで止めておきますが、まとめるとDevOpsの目的は以下のとおりです。
■DevOpsの目的
- (1)時間を省略するため
- (2)嫌なことから人間を解放するため
- (3)人間がミスを犯すのを防ぐため
- (4)開発チームと運用チームの垣根を取り払い、全体を通して最適化を図る
結果として品質の良い製品やサービスをユーザーに届けることになり、企業としては「お金を稼ぐ」ということに繋がります。
Greek Alphabet Software Academyでは何を教えているのか
シリコンバレーで働くソフトウェアエンジニアは、このようなことを「当然」のこととしてやっています。しかしGreek Alphabet Software Academyに入ってくる現役のソフトウェアエンジニア達と話をしても、意外とこの辺りが分かっていないのです。
次回は「チームビルディングの違い」と「プログラムマネージャーの違い」について触れていきたいと思います。
Greek Alphabet Software Academyでは、主に元Googleエンジニア達を講師陣に、シリコンバレー流のプロダクト開発というのを中心に教えています。アイディアの出し方、ドキュメントの書き方、高速で開発する方法、運用する方法、など、その内容は多岐に渡ります。
この記事を読んで興味を持っていただいた方は、ぜひご連絡ください
Discussion