介護や医療、ヘルスケア、シニアライフなどの4つの領域で高齢社会の情報インフラを構築している株式会社エス・エム・エスで、技術責任者をしている @sunaot です。2015年2月に入社して以来、技術責任者として開発組織の構築や開発基盤の整備をリードしてきました。
今まで私がソフトウェアエンジニア(以下、エンジニア)の採用面談を延べ800件ほど担当してきた経験を振り返ると、ソフトウェアアーキテクト(以下、アーキテクト)をキャリアのゴールに据えているエンジニアも多いようです。ただ、アーキテクトを目指している一方で、実際にアーキテクトになるためには、どういった会社組織でどのような経験をしたらいいのか分からないというケースも見受けられました。
今回は、アーキテクトを目指したいエンジニアの方向けに、アーキテクトになるために必要な4つの経験や、それが経験できる会社組織について紹介します。
アーキテクトという職種の仕事や価値については、『「継続性アーキテクト」という生き方』の記事で詳しく述べていますので、ぜひ目を通してみてください。
1.自分で設計したソフトウェアをメンテナンスする経験
1つ目は、自分でソフトウェアを設計し、それを長期間メンテナンスするという経験です。ソフトウェア開発に一気通貫で関わることで、開発に必要なあらゆる判断力がつけられると考えています。
ソフトウェアの設計の仕方自体は、エンジニアリングの教科書的な書籍を読んで概要をつかみ、実際に設計することで、具体的なスキルや経験が身につけられると思います。しかしそれで本当に満足のいく設計ができるようになるのかというとそうではありません。
この点について、ソフトウェア開発者の和田卓人さんが「質とスピード」のスライドで引用している言葉にとても共感しているので、引用して紹介します。
「ソフトウェア開発に最初から最後まで関わるという経験は、とても貴重だった。なぜなら、プロジェクト開始時のダメなデザインのしっぺ返しを、後で自分でモロに受けるからだ。ほとんど考えずコードを『アンダーエンジニアリング』していた。後々これを過度に修正してしまい、全てを『オーバーエンジニアリング』し作り込みすぎてしまったぼくがデザインしたシステムは概ねシンプルさと洗練さを丁度よく兼ね備えていたと思うし、他のエンジニアのデザインの問題点も、比較的すぐに気づくことができた。判断力をつける一番の方法は、自分で設計したシステムを長い間メンテすることだと思う」
自分で作ったシステムをメンテナンスする経験によって、メンテナンスしやすいようにとこだわって設計したソフトウェアが、実際には思うように役に立たなかったり、こだわった部分が意味を為さなかったりと、失敗に気づくことが多くあります。
開発をしていく中で得た知識や経験を、いつどの場面で使うのか。それがとても重要なことであり、その使い方や使う場面を理解できるのが、自分で設計したシステムのメンテナンスから得られる財産だと思います。
2.フロントエンド、ミドルウェア、インフラ、バックエンドのすべてを経験する
2つ目は、フロントエンドからミドルウェア、インフラを含めてバックエンドまでを、すべて自分で経験することです。
大規模な開発組織では分業体制を敷く会社が多く、フロントエンド、バックエンド、インフラと、それぞれの分野で専門性を磨く人材も存在します。そのため、各領域を専門とするアーキテクトも存在しています。
しかし、本来であればアーキテクトは、ソフトウェアシステム開発の全体像を知っている方がいい。なぜなら、フロントエンドの構成がバックエンドの構成に関わっていたり、バックエンドをミドルウェアやインフラを含めた大きな枠組みで設計するなど、ソフトウェアシステムは全体がつながっているからです。
例えば、自社でリリースしたソーシャルゲームが大当たりして、既存のシステムを数百万ユーザーが安定して利用できるシステムに拡張するとします。大量のアクセスをさばけるようにする必要がありますが、そのための方法はひとつではありません。インフラ部分やミドルウェアで解決する手段もありますし、バックエンドで対応することもできます。
大規模な開発や複雑な開発では、ひとつの領域だけでは問題をクリアできないこともあります。インフラ部分で対応しつつ、プログラムの構造を書き換えるなど、複合的な解決手段を取ることも珍しくありません。
ソフトウェアシステム全体の構造から考えて最適な設計を行うためにも、アーキテクトにはシステムを構成する各要素を経験することが必要なのです。
3.Webオペレーションの経験
3つ目は、サービスを実際に運用する(以下、Webオペレーション)経験です。自分で開発したサービスや、すでに運用されているサービスのオペレーションを担当し、運用中に出てきた課題を自分で解決していきます。
Webオペレーションはいわば構築したシステムに対する答え合わせです。設計のときに気にしていたことはテストで答え合わせをすることもできますが、観点が漏れていたことは運用の中でしか見つかりません。
運用中に見つかったさまざまな「設計の穴」を、次のシステム開発に生かすことで、より良いシステムを設計できるようになるでしょう。
4.エンジニアとしてビジネスに向き合う経験
4つ目は、エンジニアとしてビジネスに向き合う経験です。アーキテクトの仕事は、最終的にビジネスの意思決定と関係します。
サービス開発の中での判断の一部は、時にビジネスとしてもタフな決断になることがあります。そういったときには、判断のための材料を提示して議論する必要性が出てきます。特に、技術側とビジネス側で意見の分かれるような開発のときは、ビジネスのフェーズやビジネスモデルもふまえて考えるべきです。
ビジネスのフェーズやビジネスモデルによって、技術的な最適解は変わりうるということを頭に入れて、選択肢の検討をしなければなりません。どうしたら技術とビジネスが両立できるのかを考えていくのもアーキテクトの役割です。
もしビジネスのことまで考えられないと、「この開発をしたいのですがよろしいでしょうか?」とお伺いを立てるアーキテクトになってしまいます。ビジネスのことも理解していれば、「この開発はビジネス的にも意味があるはずなので、この案で実行していこう」とパートナーとして一緒に決めていくことができます。
アーキテクトに必要な4つの経験を積むための環境とは?
ここまでアーキテクトに必要な経験を4つに分けて紹介してきました。
1.自分で設計したソフトウェアをメンテナンスする経験
2.フロントエンド、バックエンド、インフラのすべてを経験する
3.サービスを運用する経験
4.エンジニアとしてビジネスに向き合う経験
これらの経験を得やすい環境の例としては、小規模なスタートアップがあります。一般的な初期のスタートアップでは、小規模なサービスを数人のエンジニアで担当します。一つひとつの仕事の難易度は高くないケースが多く、2年〜3年も在籍していれば、サービス開発や運用に関するほとんどの経験が積めるでしょう。
ただ、スタートアップでは人数が少ないため、自分の仕事に対して客観性を持つことが難しくなります。優れたアーキテクトになるためには客観的に自身のエンジニアリングの仕事の水準を知る必要があります。この点を補うためには、テクノロジーを重視しているメガベンチャーを経験するといいでしょう。そうした会社には優れたエンジニアがたくさん在籍しています。実際の仕事を通して、一流のエンジニアがどのような思考をし、どのような質とスピードでアウトプットをしているかを知ることができます。
両方の組織を通して経験を積むと優れたアーキテクトのキャリアに近づけると考えています。
ここまで、アーキテクトを目指すエンジニア向けに、私が考えるキャリアのヒントを紹介してきました。ここからは宣伝になってしまいますが、今回紹介したアーキテクトに必要な経験という視点で見た場合のエス・エム・エスという会社を紹介して終わりたいと思います。
エス・エム・エスではサービスの種の状態から育てるようなフェーズの事業から売上が100億を超えるような規模の事業まで様々な事業をやっています。エンジニアの仕事の範囲はサービスの企画に関わるところから自身でコードを書いて開発をし、インフラの構築をし、ウェブオペレーションを通してサービスの日々の面倒を見ていくところまで自分の仕事として担当します。アーキテクトになるための経験を全部体験できる環境です。関心のある方はぜひスライド資料『アーキテクトの生き方』を見てみてください!
アーキテクト人材のキャリアの考え方から、エス・エム・エスでのアーキテクトとしての機会や環境について紹介しています。
少しでも気になったら、軽く話してみるだけでも結構ですので、下記リンクからご連絡ください。お待ちしています。