視座を上げる・視野を広げるということ
はじめに
ぺんぎん（@jitepengin）です。
エンジニアとして一定の経験を積んでくると、こんな壁にぶつかることがあると思います。
- 技術的には自信があるのに、なぜか提案が通らない。
- 上位の方針についていけず、ただ言われたことをこなしている感覚がある。
- 先輩や上長がなぜその判断をしたのか、当時はよくわからなかった。
わたし自身もいち担当者から始まり、ラインマネジメントやPM、アーキテクトと役割が変わっていくなかで、同じことを感じた場面が何度もありました。
その都度、「もっと早くこの視点を持っていれば」と思うことも少なくありません。
その根本にあると感じているのが「視座」と「視野」です。
この2つはよく似た言葉として混同されますが、異なる概念です。
今回はエンジニアとして視座と視野を意識することの意味と、その変え方について考えてみたいと思います。
視座と視野の話は、上位の役職の方だけに必要なことではないと思っています。
若手のうちから意識するほど、キャリアへの効き方が大きくなると感じています。
視座とは
視座とは「どの立場・高さから物事を見るか」ということです。
同じプロジェクトでも、関わる立場によって見えているものがまるで違います。
| 立場 | 見えているもの |
|---|---|
| 若手エンジニア | タスク・コード・バグ |
| シニアエンジニア | 設計・品質・チームへの影響 |
| テックリード / アーキテクト | システム全体・技術負債・中長期の方向性 |
| PM / マネージャー | プロジェクト全体・ステークホルダー・コスト・リスク |
| 経営層 | 事業戦略・競合・市場 |
視座が低いと目の前のことしか見えない状態になります。
視座が高いとより広い文脈の中で、今やるべきことが見えてくるようになります。
視野とは
視野とは「どれだけ広い範囲・領域を見渡せているか」ということです。
視座が「縦の高さ」とすると、視野は「横の広さ」です。
- 自分の担当技術だけを知っている → 視野が狭い
- 隣接技術・他チームの動き・ビジネス文脈も理解している → 視野が広い
例えばバックエンドエンジニアとして開発していても、フロントエンドの制約、インフラの構成、データの使われ方、ユーザーの体験まで理解しているかどうかで、設計の質は大きく変わってきます。
視座と視野は両輪のようなものだと思っています。
高い視座があっても視野が狭ければ判断は偏り、広い視野があっても視座が低ければ全体への影響を考えられないと思っています。
この2つが揃って初めて、より良い意思決定ができるようになると感じています。
このようなイメージです。
- 視座だけ高い人 → 理想論になりがち（現場との乖離が起きる）
- 視野だけ広い人 → ただの物知りで終わる（意思決定に責任を持てない）
- 両方ある人 → 制約の中で意思決定できる
自戒に基づくありがちなパターン
ここからわたし自身の過去の反省も込めて、ありがちなパターンをまとめてみます。
「仕様通り動く」ことをゴールにする
わたしが若手の頃、テストが全部グリーンになった瞬間が完了でした。
また、レビューを通過してマージできたら終わりでした。
あるとき「それって、誰が何のために使うやつだっけ？」という簡単な問いに答えられませんでした。
仕様書に書いてある機能を作っていたけれど、それが誰の課題を解決するのか、考えたことがなかったのです。
本質的に「動く」と「価値がある」は、別の話です。
視座が低い状態というのは、悪意があるわけではなく、ただ、見えていないだけだと思っています。
ただし、それが積み重なると、言われたことしかできないエンジニアになってしまいかねません。
自分の中で「自分の担当外」とスコープを狭める
わたしは以前、「それはフロントの問題なので」、「インフラの話なのでわからないです」、「そこはPMが決めることです」というように担当領域を決めがちでした。
間違ってはいないのですが、言い訳として使っていることが多くありました。
視野が狭い状態は仕事を放棄しているわけではなく、自分の外側に意識が向いていないだけだと思っています。
ただし、その「向いていない」が続くと、気づいたときには自分の専門領域だけで完結する人になってしまうと思っています。
「担当外」と「関係ない」は、別の話であり、自分事として捉えられるかが重要だと思っています。
上の人の判断がよくわからない
特に経験の少ないころによくあったのですが、上位者の判断が分からないことが多くありました。
「なぜこの技術選定なのか」「なぜこのスケジュールなのか」「なぜ理想的な設計があるのに妥協するのか」。
今マネジメント側に立って思うのは、あのころ自分がわからないと感じていたのは、見えていない情報があったからだということです。
例えば、コスト制約、組織の事情、ステークホルダーとの調整、将来の撤退シナリオなど、様々な考慮事項があります。
それらが見えていない状態でなぜこんな判断を？と思っていたわけです。
上の判断に納得できないとき、もしかすると自分の視座が足りていない可能性があります。
もちろん、上が間違っていることもありますが、まずは自分には見えていないものがあるかもしれないと考えてみることが出発点になるのかなと思います。
妥協することもよくあります。それについて書いた記事も参考にどうぞ！
技術さえ磨けば何とかなる
もちろん技術力は間違いなく重要です。
SIerで社内政治や諸々を経験するうちに技術力だけでキャリアが開けるのは、ある段階までの話、もしくは本当に突出したエンジニアの話だと感じています。
わたしの周りにも、高い技術力を持っているのに、プロジェクトでうまくパフォームできていなかったり、評価が伴っていない方がいます。
逆に、技術的には突出していないですが、信頼されて重要な意思決定に呼ばれるエンジニアもいます。
その差はどこにあるか、一言でいえば、「技術を文脈に乗せられるかどうか」だと思っています。
文脈にも様々なものがあり、ビジネスの文脈、チームの文脈、プロジェクトの文脈など状況により変動する要素になります。
その文脈を読む力が視座と視野になります。
視座を上げるとどうなるか
視座が上がると、「なぜこれをやるのか」が見えてくるようになります。
具体的には、以下のような変化が起きます。
タスクの優先度が自分で判断できるようになる
「言われたことをやる」から「何をやるべきかを考える」へ変わります。
上位の目的を意識することで、価値の高い仕事に集中できるようになります。
ステークホルダーとのコミュニケーションが変わる
マネージャーやビジネス側と話す際、技術の話だけでなくビジネスへの影響・リスク・コストを絡めた提案ができるようになります。結果として信頼を得やすくなります。
長期的な意思決定ができるようになる
目先の実装速度だけでなく、将来の保守性・拡張性・技術負債を見据えた判断ができるようになります。
今は動けばいいという判断がいかに後工程に影響するかも、視座が上がると見えてきます。
仕事の意味が見えてくる
「このAPIの実装がユーザー体験・売上・事業目標にどうつながっているか」がわかることで、モチベーションにも良い影響が出ます。
わたし自身、上流工程に関わるようになってからコードを書く理由が腹落ちするようになりました。
視野を広げるとどうなるか
視野が広がると、「何が必要かの選択肢が増える」ようになります。
より良い技術選定ができるようになる
自分の慣れた技術に固執せず、要件やトレードオフに応じた選択ができるようになります。
「自分が知っている技術で解決する」から「この課題に最適な技術は何か」へ思考が変わります。
チームの課題を早期に察知できる
自分のタスクだけを見ていると気づかない「依存関係の問題」、「コミュニケーションのボトルネック」、「設計の不整合」が見えるようになります。
横断的な課題解決ができるようになる
「これはフロントエンドの問題だから関係ない」ではなく、全体を俯瞰して課題を整理し、関係者を巻き込みながら解決策を導けるようになります。
キャリアの幅が広がる
アーキテクト・コンサル・PM・テックリードといった、より広い文脈を扱うロールへのステップが踏みやすくなります。
「ソフトウェアアーキテクチャの基礎」でも、アーキテクトには技術の「深さ」より「幅」が重要とされています。まさに視野の広さが問われる話だと思います。
こちらも参考にどうぞ！
視座を上げるには
視座を上げるためには、今の自分よりも一段上の視点で考えることが重要です。
上位の目標・KPIを意識する
まずは自分のタスクが「チーム（クライアント）の目標・プロジェクトの目標・事業目標」のどれにつながっているかを意識する習慣からでいいかなと思います。
スプリントの目標、OKR、四半期の事業計画などを積極的に読みに行くだけでも視座の変化を実感できます。
意思決定の場に参加する・観察する
設計レビュー、アーキテクチャ検討、要件定義の場などに積極的に参加しましょう。
なぜその決定がされたのかを知ることが、視座を上げる最短経路のひとつだと思っています。
ロールモデルを観察する
この人のようになりたいと思う先輩・上司がどういう視点で発言・判断しているかを観察するだけでも十分な学びになります。
アウトカムで考える習慣をつける
「このPRをマージする」ではなく「このPRをマージすることでユーザーに何をもたらすか」を意識する。
アウトプットではなくアウトカムで考えることが、視座を引き上げます。
技術書以外のインプットを増やす
エンジニアリングマネジメント・プロダクトマネジメント・ファイナンスの基礎など、技術書以外のインプットが視座の引き上げに効きます。
わたしもマネジメント系の書籍を読んだり、様々な方と交流する中で上位の方針がなぜそうなのかが少しずつ理解できるようになりました。
視野を広げるには
視野を広げるためには、「自分の専門領域の外に意識的に踏み出す」ことが重要です。
隣接技術を学ぶ
バックエンドエンジニアならフロントエンド・インフラ・データ基盤を触ってみる。
専門家レベルである必要はなく、どういう仕組みで動いているか・何が課題になりがちかを理解するだけで十分です。
わたしはO'Reilly Online Learningでの多読がここに効いていると感じています。
他チーム・他職種と積極的に関わる
社内外クライアントやデザイナー・PMO・営業・データアナリストなど、普段あまり接触のない職種の人と話す機会を作るのがいいと思います。
「自分たちの仕事がどう見えているか」を知るだけで視野が変わります。
わたしもPM、技術リードやコンサルなど様々なポジションや立ち回りを行う中で、ビジネス側の見え方がずいぶん変わりました。
社外のコミュニティに参加する
勉強会・カンファレンス・OSS活動など外部の知見に触れることで、「自社では当然だと思っていたこと」が必ずしも当然でないことに気づきます。
ドメイン知識を深める
自社・担当プロダクト、担当クライアントのビジネスドメインを理解することも、視野を広げることにつながります。
「誰が・何のために・どう使うか」を知ることで、技術の文脈が一気に変わります。
普段と違うロールを経験する
PMのサポートをしてみる、コードレビューを積極的に行う、プレゼンの機会を増やすなど、普段とは違う役割を担うことが視野を広げる近道です。
視座と視野のバランスを意識する
視座と視野はどちらも過剰になると、判断の軸が失われてしまいます。
視座が高すぎると現実が見えなくなり、視野が広すぎると判断ができなくなることもあります。
視座が高すぎると、例えば以下のような弊害が考えられます。
- 理想が先行しすぎて現実の制約を軽視する
- 俯瞰しすぎて具体の重さが感じられなくなる
- 「正しい方向」ばかりを語り、いま目の前の課題を拾えなくなる
そして視野が広すぎると、以下のような弊害が起きてしまいます。
- 可能性が見えすぎて、選択や判断が遅れる
- 多様な価値観を理解しすぎて、優先順位がぼやける
- すべてを配慮しようとして、どっちつかずな判断になる
つまり視座は「適切な高さ」、視野は「必要な広さ」が必要となります。
重要なのは、「今どのレイヤーで意思決定すべきか」を選ぶことです。
まとめ
今回は視座と視野の違いと、それぞれを高める方法について整理しました。
| 項目 | 視座 | 視野 |
|---|---|---|
| 概念 | どの高さから見るか | どれだけ広く見るか |
| 方向 | 縦（上位の目的へ） | 横（周辺領域へ） |
| 上がると見えるもの | なぜやるか・何が重要か | 何が必要か・何が欠けているか |
| 高める方法 | 上位目標の意識・意思決定への参加 | 隣接技術・他職種との交流 |
技術力を高めることはエンジニアとして非常に重要です。
しかし視座と視野を意識することで、技術をどう活かすかがより明確に見えてきます。
現在の役割に関わらず、一段上の視点・一歩外の視点を持つよう意識することが、エンジニアとしての成長を加速させると思っています。
まずは自分の担当プロジェクトのゴールを確認するところから、あるいは隣のチームに「最近どんな課題がありますか？」と聞いてみるところから始めてみてはいかがでしょうか。
今回の記事が、視座と視野を意識するきっかけになれば幸いです。
Discussion
視座・視野。素晴らしい感覚だと思います。
周りを見渡して視野を広げると見えるものが増え、
立って視座を上げるとより遠くまで見えるようになります。
それでも全体を一度に捉えるのは難しくて、
少し下がって“引いて”みると、細部は薄れても全体が自然に見渡せる瞬間があります。
この全体が見える感覚の意義は大きく、個人的にも強く実感しています。
さらに、視点を自由に動かせるようになると、
自分の視点だけでなく、対話している相手の立場にも立てるようになる。
視座を上げられるようになった先には、まだ別の視点操作がある──
そんな感覚があります（うまく言葉にしづらいのですが）。