エンジニアとして次のステージに進むために
▲登壇時の写真
はじめまして、様々なバックエンドの開発をしている竹澤（@ex_takezawa）です。
PHPやGo、Scalaなどを用いてWebアプリケーションからビッグデータを扱う分析システムや、基盤システムを行っています。
今回は、これまでエンジニアとして経験したことを踏まえて、視野を広げることや事業性を理解してシステム開発を行うことの大切さなどを紹介していきます。
みなさんのエンジニアとしてのキャリアにとって少しでも参考になれば幸いです。
副業を起点としたエンジニアの学習サイクル
副業のススメ
まず、エンジニアの副業ですが、個人的には、収入が増えるというメリットがフォーカスされがちですが、本業とは異なる事業、会社の規模、ドメイン領域に触れることが出来るという点に大きなメリットを感じています。
副業で得意な開発スキルを伸ばす、ということも当然できますが、本業とは異なるドメイン領域に触れ、そこで要件分析などを経験することで、その後の自分のキャリアの大きな糧となっていきます。
ただし副業をするためにはある一定の知識や、特定の領域に関して強みを持っていることが前提です。
インプットとアウトプットの学習サイクル
▼意識している学習サイクル
- 勉強会、懇親会での学習
- プライベートで実際に開発してみる
- 勉強会、ブログで、その内容をアウトプット
- さらなる学習機会につながる
エンジニアとして仕事をしていくということは、変わりゆく技術に対応できるよう常に学習し続けることが必要です。そういった機会が業務でなかなか無い、という方はカンファレンスや勉強会などに参加することも一つのきっかけになります。
登壇者の方に積極的に質問してみたり、懇親会などで様々なエンジニアと会話をすることが、学習のためのきっかけや、自分が知らなかった技術の発見に繋がることも多いです。
その場で気になったことはその場で終わりにせず、自宅で試してみる、ということを続けることで自己学習につながっていきます。学習を重ね、プライベートな時間を少しだけ使ってWebサービスなどを開発してみると実際に自分のスキルとして習得することができます。
そして、実際に開発して経験したことを自ら勉強会やカンファレンス、ブログなどで発信していくことで、それまでよりも多くの人と会話をすることができるようになり、自己学習のイテレーションを継続的に行うことでスキルをさらに高めていくことへの近道となります。
このサイクルを回せるようになると、それまで自分がチャレンジしたことがない技術へ取り組むことも比較的容易になります。
筆者の場合は学習サイクルのきっかけとして副業
筆者の場合は、Webアプリケーションを主として開発していましたが、いわゆるWebアプリケーションとして扱うには巨大すぎるデータを扱うことが見えてきた時点で、下記のようなことを行っていました。
- 必要な技術などの調査
- 勉強会やカンファレンスへの参加
- 海外の情報などの積極的な収集
- ビッグデータに関する開発を自宅でできるように巨大なクラスタの構築
- 様々なデータを使った処理を実際に開発し、機械学習なども組み合わせた分散処理を一通り実践
気になったことなどは先駆者の方々に直接コンタクトを取るなどをしていました。そうして自分のスキルの幅を広げることで、これまで経験したことがない様な規模の開発や、問題解決への引き出しが多くなっていき、エンジニアとしての対応力の向上につなげることができます。
大事なのは、自身のできること・ゴール・コンフォートゾーンを自ら設けるのではなく、
常にそのコンフォートゾーンを超えるように学習のサイクルを回し続けることです。
そのきっかけとして副業を行うことで学習サイクルを回すことができるわけです。
技術だけでなく課題起点で考えることも大切
また、習得した技術を使うことにフォーカスするのではなく、課題に対して適材適所で技術的な選択ができるように引き出しを常に増やし続ける、ということも大事なことです。あくまで問題解決のために様々な技術を使うことが大切で、技術を使うことが目的になってはいけません。
本業以外で習得したスキルは、本業にフィードバックすることでより良いアプリケーション開発に活かすことができますが、当然新しい技術などを導入するにはチームビルディングも先導して行う必要も出てきます。
導入時に自分以外のエンジニアの方に共有したり、触ってもらったり、実際に開発で利用してもらうようにしなければ、どんなにいい技術であっても技術的負債となってしまうケースがあります。
これらもセットで考えて実行することで自然とマネージメントなども取り組めるようになりますので、技術をきっかけに自身ができる領域を広げて、その後のエンジニアとしてのキャリアに活かしていくことができます。
事業を支えるレガシーコードとの向き合い方
レガシーコードの改善はなぜ重要？
副業や自己学習などで習得したスキルを使って取り組みやすいテーマの一つにレガシーコードの改善が挙げられると思います。
新規サービスを新たな技術で開発する、ということが注目されがちではありますが、これから育っていく新規サービスの事業ドメインをうまく噛み砕きながら実装していくには、要件分析や規模に相応しい設計を行い、継続的な改善を続けなければいけません。
レガシーコードの改善は、既存サービスのコードと理想的なコードとのギャップを見つけ出し、トライアンドエラーを重ねて適切なソフトウェアアーキテクチャを導くことを実践できる場でもあり、同時に事業ドメインも理解し、分析結果をコードへ落とし込むといった手法のトレーニングにもなると言えるでしょう。
新規サービスの開発であっても、事業理解をせずに闇雲に新しい技術を導入して開発を行うと、技術そのものを使うことにフォーカスしてしまい、結果的に事業とかけ離れたオーバースペックなアプリケーションであったり、特定の開発者しか理解できない困難なアプリケーションとなり、時間が経つとやがてレガシーコードとなっていきます。
改善を行う場合、ただ単に新しい技術を使ったシステムにリプレースしたい、という動機で取り組むのは非常に危険です。
※レガシーコードとは、保守または拡張が困難な既存プロジェクトのコード(修正が難しいコード)、テストがないコード、テストが困難なコード、あるいは技術的負債を抱えているコードのことです。
レガシーコードの改善の進め方
まずは現時点でのシステムの問題点を明らかにする必要があります。単純なリファクタリングだけを行う場合は、あまり大きな改善につながらないことも多く、有効な改善を行うには下記のようなことをする必要があります。
- 1.これまでのシステムの経緯を明らかにする
- 2.現時点のシステムの状態、データベース設計などを把握
- 3.現在の仕様・機能用件と現システムのミスマッチ度がどのくらいあるか、また今後予定されている事業展開などと照らし合わせて、問題になりそうなポイントを見つける
- 4.ソフトウェアアーキテクチャの変更、データベースリファクタリングなど着手すべき箇所を明らかにする
- 5.システム改善、リファクタリングを行う
将来を見据えていないその場限りのリファクタリング・改善は、短い期間で再度改善を行うことが多いです。今までの規模、現時点の規模、将来の規模にふさわしい技術・設計は、それぞれのフェーズで適切なものが大きく変わるためです。
問題になりそうなポイントの判断の仕方
先ほどのフローの3番について補足すると、下記のようなポイントで判断しています。
- 保守頻度
- 保守人員数
- コード複雑性
- ユーザー数増加などに伴うパフォーマンスの劣化
- 単一障害点の有無
- 現在のサービス規模に相応しい実装になっているか
この時、
- 過去に作られたアプリケーションそのまま、という状態の場合
- データベースに適切なインデックスがない場合
- 規模に相応しいデータ設計になっていない場合（継ぎ足しで作るケースが多いため、データベースが正規化されていない、フラグが多い、データベースにビジネスロジックを持たせているなどがあります）
に、それに応じて実装コード、アーキテクチャの変更などが必要になります。
track1！
事業とアプリケーション開発について興味ある方は是非お気軽に / 事業のスケールアウトを支えるPHPで作る分散アーキテクチャ by 竹澤有貴 | トーク | PHP Conference Japan 2020 #phpcon #phpcon2020 #php - https://t.co/gEaQjAHDXl https://t.co/I9KNxLSowQ
— yuuki takezawa@ytake (@ex_takezawa) November 6, 2020
フェーズによる適切な技術・設計の変遷の例
例えば、スタートアップなどではWebアプリケーションフレームワークを用いて、比較的簡単なデータベース設計で開発が進むことが多いです。
その後、サービスが大きくなり、初期の頃には考えてはいかなかった機能なども追加されることも多くあります。これは事業規模が大きくなることで生じる変化なので、最初期から全てを予測したアプリケーション開発、ソフトウェアアーキテクチャ設計を行うことは不可能です。
ある日、ビッグデータや機械学習などに取り組むとしたらどうなるでしょうか。
なぜ最初からビッグデータに合わせた設計になっていないんだ！と思うこともあるかもしれませんが、サービスが小さいうちからHadoopやSparkなどを用いるということは考えづらいものですし、なにしろオーバースペックな技術となります。
サービスの最初期に将来を見越してこれらの技術を導入することはまずないでしょう。
アプリケーションのコードも事業発展を繰り返すことによって、初期よりも実装が複雑になり、データベースも同時に正規化とは程遠い設計になってしまうことも多くあります。
これらの問題はある程度事業が成長してくると事業展開の方向性や、過去との差分が明らかになっていきますので、現在の機能用件と照らし合わせたときにどういう技術がフィットし、どういうコードにするべきか、理想的な実装コード、設計のギャップはどのくらいか、というのがわかってきます。
そうしたタイミングでレガシーコードなどの改善に取り組むのは比較的やりやすい状態であるといえるでしょう。
レガシーコードの改善には、時系列/部署を全て考慮することが必要
事業を支えてきたアプリケーションのレガシーコードと正しく向き合うには、開発だけにフォーカスするのではなく、事業のこれまでの様々な出来事を把握し、開発チームだけではなく、ビジネスチームとの会話を積極的に行い、理解を深め合うことが大切です。
過去の経緯を踏まえ、ビジネスチームともシステム改善で得られるメリット、将来性などを共有し、必要に応じて機能改修や、改善期間・リソースの確保といったことを行います。
これらを放置すると、将来的に生産性が大きく低下し、様々な障害を引き起こしやすくなり、生産性が低下したことによる周辺チームとの信頼関係も崩れ、エンジニアチームのモチベーションにも下がっていきます。
その場にあるレガシーコードなどに対してネガティブな意見をいうことは簡単ですが、
それを繰り返さないように様々な改善することが重要です。そのための知識や技術は、自己学習や副業を重ねることにより得やすいものであることは間違いありません。
事業性を理解してより良いアプリケーション作りに
エンジニア目線しかないことの限界
これまで述べてきたように、エンジニア目線だけのリファクタリング、新しい技術の導入をするだけではなく、自身が携わるサービスはもちろん、所属する会社の事業を理解する事で要件分析を行い、事業として本当に実現したいことを明らかにする必要があります。
具体的に意識すること
- 週次でPLの確認
- プロダクトのKGI/KPIの設定
- KGI/KPIを意識したプロダクト開発（チケット管理なども含む）
- ビジネスチームからサービスに対しての将来像を聞き出す
- 競合他社などの動向を知る
新機能の開発などで、「難しそう、これまでやったことある技術ではできなさそうだ」などのネガティブな意見が先行してしまい、「できません」という反応をしてしまうと、そこから産まれるものは何もなくなってしまい、ビジネスサイドのメンバーからはあまり信頼されなくなってしまいます。
これは結果的に自身が所属する会社の事業にも影響を与えてしまうことになり、新しいビジネス領域へのチャレンジ、それに合わせて習得すべき技術的なスキルなどを得る機会もなくなってしまい、死んでいくサービス、チームとなっていき、良い結果になりません。
ビジネスサイドとの信頼関係の構築の重要性
またエンジニア以外の方には、現在のシステムがもつ問題点などは理解しやすくても事業に与える影響範囲を的確に判断することは非常に困難です。なかなかエンジニアチームの意見が通らない、などといった場合には関わるサービスの会議などに積極的に参加し、信頼関係を構築することが必要です。
関わるサービスのビジネスサイドのメンバーを巻き込んで、事業の未来像を引き出し、次の段階で用意すべき機能をいち早くキャッチアップし、どういった方法で取り組むか、現システムで改善すべきところはどこか、などを明らかにし、ビジネスサイドにもエンジニア側からサービスの提案を行うなどを積極的に行っていきます。
事業展開を見据えて技術的な先手を意識
これらを繰り返して関わるチームや人との信頼関係を構築することで、次の事業展開に備えて技術的な先手なども打てるようにもなり、結果的にエンジニアサイドからもアプローチしやすい環境、文化、組織作りを推進することができるようになります。
CTOやエンジニアリングマネージャーを目指す方は、半年先、一年先を事業展開と合わせて様々な技術的戦略を考えたり、それらに備えたチームマネージメントを行うことが必要となります。
将来的にそういったキャリアを歩みたい方は、自己学習や副業などを通じて様々な経験を積み、チャレンジを重ねてみてください。
