エンジニアリングを頑張ろうと思えば思うほど、結局ビジネスの理解が必要になると思っている話
なんかこう綺麗にまとまっているわけではないのですが、最近エンジニアリングをしていて思うことをポエム的に書こうと思います。
1. 現状の思い
日々エンジニアリングをしている中で、下記のような思いがあります
1.1 あまり知識がない個別の技術がある
やっぱり自分があまり良く知らない個別の技術領域がめっちゃあります。
そうめっちゃ。
比較的領域として狭いとみなせそうなCIの話にしても、Bitriseを使うかCircle CIで頑張るか、Xcode Cloudを入れてみるか、Jenkinsおじさんで頑張るか、などいろいろな選択肢があります。
これがジェンキンスおじさんだ！(Jenkins Artworkより引用)
領域が広いとみなせる開発の話になると、Swift / Kotlinでネイティブに頑張っていくいわゆる普通のやり方から、Flutterを使うとか、 Xamarinでいくとか、ReactNativeでがんばるとかいろいろな選択肢があります。
もっとレイヤーが上の話をすると設計などの話もあって、どのアーキテクチャで開発するのかとか、アプリに必要な知識をどこに配置するべきかとかのドメインモデルの話とか、具体的な技術に依存しない抽象的な話があります。
そして私は1人の人間なので、これらの技術全てに精通しているわけではありません。
CIでいうと、Bitriseは一人で環境設定からトラブルシュートまで一通りこなすことができますが、それ以外については全くわからず、ジェンキンスに至っては怒らせたことしかありません(反省)
開発についてもフルネイティブ開発はある程度勝手がわかりますがクロスプラットフォーム開発については調べながらじゃないとできないです。
設計については最近本格的に始めたばかりで、今作っているプロダクトのアーキテクチャで何をどこに置くのがいいか、またクリーンアーキテクチャ的にはどういう事を言いたいのか、みたいな部分はわかりますが、もっと上のレイヤ、サービスとしてどうあるべきかみたいな点についてはやっぱりまだわからないところが多いです。
1.2 勉強する
私はエンジニアです。
知らないところは勉強します。
最近はいわゆる「アーキテクト」という立場に興味があって、個別の具象技術ではない抽象的な部分を多く勉強するようにしています。
レイヤーが上の話だと、プラットフォームに閉じた形でのドメインモデリングだったり、具象に近いところだとアーキテクチャの勉強をしたりしています。
1.3 勉強したけどそれを採用するべきかを技術面だけから判断することができない
正直僕はまだ1.2までで手一杯で、1.3の内容は僕がまだ到達していない箇所ですが、きっと勉強して個別技術を完全に理解したとしても、下記のような問題が発生すると思っています。
個別の技術のProCon(メリデメ)を判定できるようになったとしても、きっと各プロダクトのコンテキストを踏まえた技術選定をしないと、実態に即していないエンジニアリングをしてしまう。
例えば、クロスプラットフォームを採用すれば1ソースで2つのプラットフォームを開発できるでしょう。
でもAプラットフォームで起こるバグを直したらBプラットフォームでバグを生んでしまった・・・という問題が発生するかもしれません。
またそもそも工数が不足しているのは資金調達の都合で今はアプリエンジニアが1人しか雇えないからで、2ヶ月後にVCから資金調達をして、iOS・Androidにそれぞれエンジニアを1名はつけられるようになるかもしれません。
例えばユーザー数だったり、サーバーへの同時接続数だったり、そもそもプロダクトとして求められている安定度とか、将来的な展望、ビジネスとしてやってくのかとか資金はどうするのかとか、各プロダクトには各プロダクト固有の コンテキストが存在すると思っています。
このコンテキストを考慮しないで純粋なエンジニアリング的目線で近視眼的に技術選定を行うと、サービスとして適切なエンジニアリングがなされずオーバーエンジニアリング(必要がないのにやりすぎ)だったり、アンダーエンジニアリング(規模が足りていない)になってしまうと思っています。
2. いいエンジニアになるために必要だと思っていること
上記のような課題感を感じていて、それらを解決して「いいエンジニア」(ずるい表現ですよね)になるためには下記のようなスキルが必要だと考えています。
2.1 エンジニアリング力が必要
当然ですがエンジニアリング力が必要です。
ここでのエンジニアリング力はある特定の分野でのある程度突出した力で、良いと思っています。
突出と言ってもそこまですごい必要はあまりないと考えていて、アプリケーションに必要な機能を一人で実装する、もしくは設計に落とし込んで施策を遂行する力があれば十分かなと思っています。
(それさえできれば、問題を把握することができるはずで、問題を把握できるなら解決策も一緒に把握できるので、あとはやるだけだと考えているからです)
2.2 ビジネスコンテキストの理解
いいエンジニアリング、つまりエンジニアリングの状態をオーバーエンジニアリングだったりアンダーエンジニアリングにさせないためにはビジネスコンテキストの理解が必ず必要です。
ビジネスコンテキストとは、そのサービスはどういうサービスで、可用性はどれぐらいないとだめなのか、現状のユーザー数はどれぐらいで、今後どれぐらいグロースさせる予定で、サービスとしての課題感がどこにあるのか、それを解決するための打ち手はなにか、費用的にはどこまでかけられるんだっけ・・・みたいな部分を指します。
ここを適切に理解できないと自分がどういうサービスを作っているのかがわからないため、サービスの実態と乖離した、でもユーザーが使うことだけはできる不思議なエンジニアリングをしてしまうと思っています。
3. 思っていること
以上を踏まえて下記のように思っています。
3.1 多分「正解」のエンジニアリングはない
これをやっておけばもうどんな状況にも対応できる魔法のエンジニアリングはおそらくないと考えています。
それは各プロダクトごとにサービスコンテキストが違うため、サービスを適切に実現するためのエンジニアリングが異なってしまうためであると考えています。
だからこそ、正解に近づけるように様々な選択肢を考慮しながら技術を選定していかないといけないのです。
3.2 理想と現実の間でもがき続けるしかない
実態サービスと乖離するかどうかよりも、実際に動いて可能な限り早くユーザーに価値を届けるコードのほうがいいよねという主張もあると思いますし、それは正義だと思っています。
我々はビジネスの世界で生きている以上、実際にお金を生み出して、ユーザーに価値を届ける行為が何よりも価値があると思っているからです。
なので今のエンジニアリングのやり方が理想じゃないときは、様々なサービスコンテキストのもとで自分たちに現実的に取れる一番ベストな選択肢を選択し続けて、こうあってほしいという理想と、そうではない現実の間でもがき続けるしかないんだなぁという感覚もあります。
4. まとめ
色々思っていることを書き並べてしまいましたが、結局エンジニアリングは楽しいと思っています。
ユーザーに価値を届けることに楽しさを感じますし、それを実際に組み上げていきサービスとして公開することにとてもやりがいを感じます。
私は各プラットフォームに閉じた具象の個別技術ではなくサービス自体を開発していけるような人をソフトウェアアーキテクトと呼べるとおもっていて、そういう人になりたいと思っています。
頑張るぞ〜💪
Discussion