組織ではなく、ソフトウェア設計／実装における視座の上げ下げ
前書き：視座に関する音楽性の違い
本記事は、「たまには変わった視座の話を読みたい」と考えた私が、「そんな記事が無いなら、書くか……自分で」と書き殴ったものです。
2023年ごろから、視座の話をSNSで見かける頻度が増えました。
理由は、私と同年代（30代）以上の方々がエンジニアリングマネージャーや管理職に近いポジションになったからでしょう。組織課題を解決する過程で、視座に思いを馳せるようになったのかもしれません。しかし、視座という概念自体は新しいものではありません。私が過去に所属していた会社（JTC的な会社）でも視座に関するフィードバックを見聞きしました。その会社では、昇格論文の評価軸に視座の高さが含まれているぐらいです。
視座という用語は、個々人で異なる解釈をしています。多くのケースでは、「所属する〇〇の課題に気づけるか（解決できるか）」という意味で使われています。〇〇には、チーム、課、部門、会社、業界、社会などの集団が入ります。視座が高い人は、より多くの人に関係する課題を解決できます。結果として、インパクトの大きい成果を出せます。
本題ですが、私は視座の話題に食傷気味でした。大前提として、組織に関する視座の上げ下げは重要な話だと捉えています。しかし、音楽性の違いを感じてしまいます。「昔は同じエンジニアだったのに、エンジニアリングマネージャーになったら急に組織組織って……昔の気持ちはドブに捨てたの？（※）」という気持ちです。ならば、非マネージャー職の私がそのドブをさらいましょう。ということで、ソフトウェア設計／実装における視座の上げ下げについて考えてみます。
※ 推測ですが、私もEMになったら、組織組織って言い出すと思います。
ソフトウェア設計／実装に関する視座とは
ここでの視座は、「設計がもたらす影響範囲に意識が向いているかどうか」と定義します。
大まかな参考例としては、下表のような視座の高さが考えられるでしょう。
| 視座の高さ | 観点 | 典型的な問い |
|---|---|---|
| 低い | 局所的な実装（関数・クラス） | この関数の命名は正確か？ |
| 中間 | モジュール・システム設計 | この設計は再利用可能か？将来の変更に強いか？ |
| 高い | アーキテクチャ、事業要件との接続 | この選択はなぜビジネス上の意味があるのか？どんな意思決定を促進するのか？ |
シニア以上のエンジニアであれば、アーキテクチャレベルの意思決定が可能でしょう。しかし、ジュニアレベルでは基礎知識が足りていなかったり、事業要件が理解できていなかったりするため、モジュール・システム設計の観点での意思決定が限界でしょう。例えば、新卒時の私はコードを書いた経験が少なかったので、リーダブルコード（書籍）を参考に関数を設計するので精一杯でした。視座が低かったので、ライブラリ（モジュール、パッケージ）全体のことは把握しておらず、どのようなアーキテクチャが採用されているかは考えもしませんでした。
定義内に登場する「影響範囲」は、変更容易性とも言い換えられます。下表で示すように、影響範囲が小さい事柄は変更容易性が高く、影響範囲が大きい事柄は変更容易性が低いと考えられます。変更容易性を把握した上で設計できるエンジニアが、視座の高いと考えています。
| レイヤー | 説明 | 変更の難しさ |
|---|---|---|
| 変数／関数名 | 命名の変更、意味の見直し。リファクタリングツールで容易に変更可能。 | 非常に容易 |
| ロジックの入れ替え（関数内部） | アルゴリズムや条件分岐の修正。テストがあれば安全に変更可能。 | 容易 |
| クラス・モジュール設計の見直し | 関心の分離、責務分割。モジュール間の依存が変わると他所に波及。 | やや難 |
| APIインターフェースの変更 | 外部や他モジュールとの境界。互換性の維持が必要。 | 難 |
| データ構造／スキーマの変更 | データベースや永続化層の変更。マイグレーションや互換性維持が厄介。 | 非常に難 |
| アーキテクチャの変更 | MVCからMVVM、モノリス→マイクロサービスなど。全体構成に影響。 | 規模によっては不可能 |
視座の上げ下げ
ソフトウェア設計では、設計粒度を基本設計から詳細設計までブレイクダウンする必要があります。粒度によって、視座を柔軟に上げ下げできた方が良いと考えています。
ここでの基本設計は、ソフトウェアアーキテクチャの全体像を示し、特定のユースケースをどのように実現するかを示すものと定義します。詳細設計は、特定の処理をどのように実現するかを示すものとします。また、チーム内で設計検討する中で、アーキテクチャレベルの話題から実装レベルの懸念まで入り乱れた会話をする可能性があります。視座を適宜上げ下げできた方がスムーズな会話になるでしょう（一定の視座で会話できた方がベターなのは置いておき）。
設計のブレイクダウン例として、機械学習でデータ分析を行う場合の視座変化を考えてみます。
基本設計では視座を上げて、必要なデータを一覧化（理想的な世界なので漏れはない）し、データの取得し、記録、前処理、学習、評価、運用までの流れを考えます。この流れを満たすために必要なインフラ構成（例：前処理はLambda、学習はSageMakerを使うなど）やフレームワークを選定した後からは、段々と視座が下がっていきます。データの記録処理を行う設計、前処理の設計を考え、実際の実装をする段階で最も低い視座でクラスや関数レベルの設計を行います。
視座を引き上げるには
ソフトウェアエンジニアとして一皮むけるには、視座を一度上げる必要があります。どのように引き上げるのが好ましいでしょうか。
若者に無理難題タスクを押し付けて、崖から突き落とす? それは止めましょう。
理想論としては、メンバの嗜好に合わせたロードマップと、実務経験が必要だと考えています。iOSやAndroidのアプリを作るエンジニアに「もっと視座上げてさ、インフラまで設計できるフルスタックになってさ」などとフザケた提案はできません。マネージャはメンバの望むキャリアに合わせたロードマップを把握し、必要な知識を学ぶ機会や実務経験を提供できるのがベターです。受け身だと話が進まないので、メンバ側は、やりたいことやロードマップ案を1on1でマネージャーに伝えると良いでしょう。しかし、現実的にはマネージャー側が適切な機会をメンバに与えられない場合もあるでしょう。そのような場合、人生短いので、メンバ側は転職を視野に入れた方が良いかもしれません（私だったら、1〜2年ぐらい変化がなければ辞めます）。
より現実的な意見を書くと、マネージャーから「この人には、難易度が高い仕事（視座の高さが必要な仕事）を任せられない」と思われないことが大事です。そのような人は、学習機会となる仕事が来ません。視座を上げるチャンスが一生来ません。簡単な仕事を確実にやり切ったり、日々の学習をアピールして、マネージャーから信頼感を得るべきです。自分がやりたい仕事を任されるように、社内評価を上げるのも一つの手段です。視座の話をしていたのに、泥臭い話に落ち着いてきて私は悲しいです。
また、転職のタイミングで役職（例：テックリードなど）を得るのも一つの手段だと考えています。より責任のある立場となれば、自然と視座を上げた決断をすることが求められます。
最後に
自分が読みたい視座の話を書き始めたつもりが、最終的に社内政治や転職推奨みたいな話になりました。
本記事の視座の話は、リファクタの余地があると思ってます。より良い視座の話（リファクタ）をSNSでお待ちしております。
ロシア人と国際結婚した地方エンジニア。
小学〜大学院、就職の全てが新潟。
大学の専攻は福祉工学だったのに、エンジニアとして就職。新卒入社した会社ではOS開発や半導体露光装置ソフトを開発。現在はサーバーサイドエンジニアとして修行中。HR/HM（メタル）とロシア妻が好き。サイトに関するお問い合わせやTwitterフォローは、お気軽にどうぞ。
