エンジニアの作る壁
次の条件下でシステム開発に携わるとき、いったいどれだけ壁ができるだろうか。
- プロジェクトチームのメンバ
- 担当エンジニア（アプリエンジニアでもインフラエンジニアでも構わない）
- B2C、B2B、社内システムのどれでも良い
- システム開発手法はウォーターフォール、アジャイル開発のどちらでも良い
- チームは自社と外注業者
アクティビティを機能的にアサイメントされるか、意志で選ぶかに問わず、チームのメンバである時点で自分の作業にフォーカスしてしまう。この現象に開発手法は影響を及ぼさない。ウォーターフォールであれば予定完了日でトレースされ、アジャイル開発ならデイリースタンドアップミーティングで実績を共有するため、どちらも完了予定は意識せざるを得なくなる。能力や開発スピードなどに左右されるが、期待されている日までにアクティビティを終わらせようとすると、リソースを全振りするため、プロジェクト全体を俯瞰する動機付け自体エンジニア自身に生まれない。
エンジニアの専門を指定されると機能分担のバイアスが強くなる。機能分担は分掌に対しての責任を意識しやすい。結果的に担当の責務を果たそうとするのでプロジェクトチームの階層構造が3つ以上かチームメンバが10人を超えるようになると、機能分担がより強くなる。その結果、タコツボ化が始まり、灰色のボールは間に落ち、影と同化して見つけにくくなる。
ビジネスモデルというか、システムの使われ方というよりは、エンドユーザに到達するまでどれだけの役割（エンドユーザに到達するまでに介在するヘルプデスク、IT部門、営業、PM、リーダなど）により、エンドユーザへの意識は希薄化する。機能分担も相まって、階層が増えれば増えるほど、仕事への関心はエンドユーザからアクティビティにエンジニアの関心は依存する。エンドユーザの顔が見えないのにペルソナを設定しても全く意味はなさない。
システム開発手法は、どちらを採用していても、エンドユーザへ接しないのであれば大した差はない。顔の見えていないB2Cよりは、社内システムのエンドユーザの方が格段に近い。システムの使われ方で距離も会うまでに介する人の少ない方がユーザビリティへの関心は高くなる。ただし、エンドユーザに会うことがなければ期待できない。
チームの人的リソースが、自社と外注業者の組み合わせの場合、自社のエンジニアの方から外注業者の監督者か契約形態によっては直接作業を相談されるから、仕事は線を引かれる。指示をする側は、指示をする範囲全てを把握することになるが、指示を受ける側は契約の範囲にフォーカスする。（完成責任を負うかは契約によるが）完成させたいと責任感を強く感じると作業にフォーカスしてしまう。
