こんにちは,@onk です。

これは ドリコム Advent Calendar 2016 の 7 日目の記事です。

6 日目は @ogwmtnr さんによる 地図に追従する View を置こう! Android 編 です。

はじめに

十名~数十名ぐらいのプロジェクトで開発することの多いドリコムだが,
プロジェクトの中に「プロジェクトリード職」という役割を置いている。
プロジェクトの実現性と健全性を担保するのが仕事だ。

ディレクター,プロダクトデザイン,プランナー,アート,エンジニアリーダーという風に
職種別のリード職を設けていて,エンジニアリーダーの場合はアーキテクチャや安定稼働,
(技術的な) ユーザビリティ等への専門性を持って責任を負うのと,エンジニアチームの
チーム作りもミッションに加えている。

最近は開発ライン数が増えてきたこともあり,新卒 2,3 年目のリード職が増えてきた。
リード職になった人に「一メンバーだった頃と何が違う?」と聞くと,
よく「視野が広くなった」と返ってくる。
視野が広くなるとは具体的にどういうことなのか,掘り下げてみようと思う。

主に 2 年目エンジニア向けのエントリです。

仕事とは何か

視野の前に,まず仕事とは何なのかについて定義しておく。

僕なりの定義だが,

理想の状態になることを阻害している問題を見つけて,
問題を解決する手段を考え,解決すること

だと思っている。

リーダーになる前は

  • 理想の状態はプロダクトマネージャが決めてくれる
  • 問題はリーダーが見つけて,手段を考えてくれる(=課題)
  • 課題をこなすのが自分の仕事

が許されるんだが,本来の意味で仕事をするためには問題を見つける力が求められる。

問題を見つける力

例えばとある機能の実装を任されて,想定の 3 倍ぐらいの工数がかかってしまったときに,
何を改善していけば良いだろうか。

自分のコードしか視野に入っていないぐらいのルーキーは

T: 見積りを 3 倍にする

ちょっと深掘りして

P: ライブラリの使い方を習得するのに時間がかかった
T: ライブラリに習熟しておく

P: 他のところに影響してしまっているのがテスト時に発覚し,修正に時間がかかった
T: 周辺コードも読んで業務知識をつけておく

といった Problem, Try を上げてくるが,根底には違う問題が眠っている場合が多々ある。

例えば

  • 仕様の伝え方が曖昧だったため,手戻りが発生していた
  • レグレッションに気付けない程度に現状のテストカバレッジが低い
  • 見積りが甘い

とかだ。

これをツリーにすると

  • 個々の実装能力の問題
    • ライブラリの理解が甘い
    • コーディング速度が遅い
  • エンジニアチーム全体の問題
    • 実装前(設計)の段階でレビューを行っていない
    • テストカバレッジが低い
  • コミュニケーションの問題
    • ドキュメント粒度が荒い
    • 企画職とエンジニア職の席が遠い
    • キックオフ MTG の議事録がない
  • 見積りの問題
    • 一人で見積もったので精度が悪い
    • クリティカルパスになっており,遅延したら即リリースも遅延する

のような感じになる。

これをイシューツリーと呼ぶ。

イシューツリーをどうやって見つけるか

まず第一に,自分が思いつく問題の他にもまだ問題が眠っているはず,と疑うこと。
次に,視座を変えて事実を眺めてみることだ。

視座とは何か

し‐ざ【視座】
物事を見る姿勢や立場。「人道主義的な―で発言する」

goo 国語辞典 デジタル大辞泉

視座とは,事実を眺めるときにどのような立場・役割で眺めるかだ。
事実というものは不変であるが,眺める人によって違う点に注目される。

時間軸に対するスタンス

だいたい職位によって意識しなければいけない時間軸が違う。
社長が今日の作業の効率化だけを考えていたら会社の方向が決まらない。

バイトはその日のことを考える
営業(現場最前線)はその日~1週間先のことを考える
営業(主任・リーダー)は1週間~1ヶ月先のことを考える
営業(係長・課長)は1~3ヶ月先のことを考える
営業(部長)は3ヶ月~1年先のことを考える
取締役は1年~3年先のことを考える
社長は社員のすべての行為に責任をとる

http://jernel.seesaa.net/article/151521090.html

仕事の定義は

理想の状態になることを阻害している問題を見つけて,
問題を解決する手段を考え,解決すること

と言ったが,「3 ヶ月先に理想の状態に近づくためにはどうすれば良いか」を考えるようにすると
未来寄りの視座になり,別の問題が見つかる。

この着目する問題のことを「視点」と呼んでいる。

役割に対するスタンス

「他の人からこの事実を眺めてみるとどう見えるだろう」と考えてみること。

他の人というのは,

  • 同じプロジェクトにいる同僚(他業種)
  • 別のプロジェクトにいる同僚
  • 上司
  • 部門長
  • ユーザ

等々,情報格差がある人で想像すると良いと思う。

  • 開発者だと古いライブラリを使っているのが問題だと思っている
  • 企画者だと機能改修を優先して欲しいと思っている
  • 部門長はこのプロダクトは「金のなる木 (Cash cow)」なのでコスト低く収益を上げて欲しいと思っている

のように,視座が変わるとまったく視点が異なる。

その人の視座に立って SWOT 分析をしてみると,どのような情報格差があるのか,
それによってどう判断基準が変わるのかを理解しやすいかもしれない。

チーム内の視座,視点を揃えるためにインセプションデッキを作るんだけど,それはまた別の機会に。

視野・視座・視点

し‐てん【視点】
1 視線の注がれるところ。
2 物事を見たり考えたりする立場。観点。「―を変えて考える」「相手の―に立つ」
3 透視図法で,画像と直角に交わる仮定の一点。対象を眺める位置。

し‐や【視野】
1 外界の一点を凝視するとき,その点を中心として見える範囲。視力の及ぶ範囲。「―が開ける」「―を遮る」
2 顕微鏡・望遠鏡・写真機などの,レンズで見ることのできる範囲。
3 物事を考えたり判断したりする範囲。「―の狭い人」「国際的な―に立つ」

視点とは,事実を眺めるときに注目する点のこと。
視野とは,持っている視座全てから眺められる事実の範囲のこと。

視座が少ないと視野は狭くなる。
複数の視座を持っていて,視野が広いことを「視座が高い」と言ったりもする。

図示すると以下のようになる。

視野・視座・視点

視点を鍛える

視座を変えてみたところで,何に注目すべきかが分からないと問題を正しく認識できない。
視座が合っているにも関わらず注目点を間違えている状態を「視点が鈍い」と言う。

では視点を鍛えるためにはどうしたら良いのだろうか。

あたりの本はすごく参考になった。

  • 費用対効果を考える
  • 仮説を立てる
  • 別の問題があるはずだと疑う

が定番だが,「大きな仕事をする」というのを特に挙げておきたい。

大きな仕事をする

ステークホルダーが多い仕事,ステークホルダーが多岐にわたる仕事をすると
お互いの利害が対立する状況が生まれる。
この対立の中での決断は,幅広く様々な要因に思いを巡らせる必要があるので
自然と思考のスケールの桁が変わっていく。

また,大きな仕事はしばしば混乱の場でもある。混乱の中では物事を整理しなければ前に進めない。
整理整頓を繰り返すことで,視点が磨かれていく。

視座を上げるときのアンチパターン

視座を高く持って視点を探そうとすると,例えば朝会に遅刻をした時に
「そもそもリモートで参加できない状態がおかしくないですか」
みたいな発言をしがちになる。

視座・視点の切り替えは得てして論点ズラしに使われる。
他人の視座に立つというのは,他責にすることではない。

まずは敢えて視座を下げて視野を狭くし,任された範囲でやりきるのも大事。
ふりかえりの場だとよく陥りがちなので注意。

とにかく自分の問題として捉えるという意識をなくさないこと。

問題解決時にも使える考え方

主に問題発見時の話をしてきたが,視座の切り替えは問題解決時にも使える考え方だ。

指示された仕事全てについて,

  • そもそもなぜこれをやるのか
  • どうあるべきなのか
  • もっと良いやり方は無いのか

を考えるようにすると,ゴールに対するアプローチの良し悪しの経験が
どんどん自分に積まれていく。

依頼者の視座に立つ

僕らの仕事は要件に対して成果を出すことだ。
見える範囲で,さらに暗黙の要件であろうことに気を配ることもある。
このとき,作業者の視座と依頼者の視座は違うので,気配りがまったく響かないことがある。
一方で依頼者の側も「何故これぐらいのことに配慮してくれないんだ」と不満を持つことも多い。

伝わらない気配りと気づかない不満

伝わらない気配りと気づかない不満

過剰品質にならないように,期待を裏切らない成果を出すために,依頼者の視座に立って
仕事をするようにしたい。

依頼者の視座を獲得するには,依頼者に「何を評価するのか」を問い続けるのが一番良い。
上司・同僚が依頼者の場合は直接聞けば良いが,ユーザが評価者だったりすると直接聞くことが
できないので,高速で PDCA サイクルを回し続けることになるだろう。

エンジニアの評価をエンジニアがするということ

これも視座の違いを埋めることに他ならない。

被評価者であるエンジニアが何を考えて作業し,どの辺りが成長したのかは
エンジニアとしての視座からでないと気づけないことが多いからだ。

評価者側がエンジニアだと,お互いに自分の言葉で説明したら 100% 伝わるので
視座を変えなくて良くなり,楽ができる。

怠慢という話ではなく,「評価者はエンジニアであるべき」という言説がこれだけ広がるぐらいには
複数の視座の獲得は難しいのだ。

まとめ

伝えたいことは「視野を広くしてリーダーになろう」なんだけど,
視野を広くするとはどういうことか,そのために視座と視点という考え方があるよ
というのを紹介しました。

明日は村松さんの 5万円以下で映画を撮る方法 です!