チームと分権と領分と裁量
注記: 文中の「裁量を手放す」は「相手をリスペクトし、自分は説得する立場にまわり、最終決定を相手の判断を委ねる」ことであり、 知らん任せたと言って投げ出すことではないので悪しからず。
登場人物
提案者
問題を考えついた人
こういう機能があればこの問題解決できそう！まで考えて、Issueを立てる
解決者
問題を解決する機能を実現する人
Issueを見たり話を聞いたりして、よっしゃ実装したろ！となる
結論
この二人が、いかにして、分権を図り、互いをリスペクトしあい、適切なオーナーシップを持ち、適切な領分を維持するか、という話。
複数の人間がいて、それぞれが十分なスキルと自信と権限を持ち合わせていた時。裁量を渡さず仕事を振ったり、権限の垂直関係を整えずにタスクを回しても、うまくいかない。
ここでいう「うまくいかない」は、「プロダクトの成長」や「機能が期日通りリリースされること」とは全く関係ない独立した事象
提案者は、問題の精度に強い裁量を発揮すべきである。
実際の機能がどのような実装であるべきかについては、裁量を手放すべき
たとえ、どれだけ確度高く機能を思いついて「やった機能に落とせた辿り着いた俺最強！」と思っても
自分が思いついた機能をそのまま実装するには、自分で実装するか、解決者を説得して納得させる
解決者は、機能の妥当性に強い裁量を発揮すべきである。
実際にどのような問題を解決するかについては裁量を手放すべき
たとえ、どれだけ提案者の問題がおかしく思えて「そんなんより俺の問題の方がいい切り口だ！」と思っても
自分の解決したい問題へ方向転換したり、自分の問題意識を相乗りさせたいときは、提案者を説得して納得させる
下記のような越権行為が行われると、いわゆる「指揮が低い」状態に陥り、野放図で無責任に目の前のタスクをこなすだけのチームになってしまう。決めたルールが守られないチームは、法律を破ってもお咎めの無い法治国家と同じである。
提案者が「いいから俺の指示した通りの機能を作れ」と言う
解決者が「お前の問題設定は甘いから俺が変えといた」と言う
プロダクトの進行フェーズにおけるルール
あるプロダクトが、ある問題を実装によって解決する時、実行に至るまでの進行フェーズは三つに分類できる。
1. 提案
2. 計画
3. 議論
https://gyazo.com/f41c1daed805d76e929b16a55e03e40f
「提案」は、提案者によって行われる
依頼する側が考えるのは問題、問題を説明するために機能を例示する。
解決したい問題は何か
どういう機能があればよさそうか
その機能は最低限なにを達成すればいいのか
その機能はどういう風にユーザーに使われるか
提案者が機能について話す時は、問題を説明するための例示にとどめる。独力で詰めずコミュニケーションを図る。
問題の精度について裁量を持ち、機能の裁量は明け渡す
提案者がエンジニアリングに明るくない場合は特に
「計画」は、解決者によって行われる
解決する側が考えるのは機能、正しい問題から正しい機能が実装されるよう、提案者を助ける。
解決したい問題と機能の演繹関係は正しいか
機能の複雑さや実装コスト、プロダクトの性質との相性は適正か
ブラッシュアップするとほぼ同等の機能で複数の問題を解決できないか
善悪それぞれのユーザーが利用した時に致命的な問題が起きないか
解決者は、提案者を信頼する必要がある。問題の再設定は独断でせず、コミュニケーションを図る。
機能の妥当性に裁量を持ち、問題の裁量は明け渡す
解決者がビジネスやデザインに明るくない場合は特に
「議論」は、双方の打ち返しによって行われる
解決する側が考えて、依頼する側に打ち返すことがある。
解決したい問題と機能の演繹関係が正しくない、実はこういった機能が必要である
問題に対して機能が豊富/貧弱/複雑/簡素すぎる、こういった機能にした方がハンドリングが楽である
工数は少々増えるが、こうした方が自分の考えるこういった問題を解決できるが、どうか
この機能を実装するとこういったセキュリティ的な問題が起きるので、機能の提案からやり直して欲しい
依頼する側が、解決する側に打ち返すこともある。
たしかに演繹関係が正しくないように見えるが、実はこういった因子があり、それを踏まえるとどうか
実はこういった要望/計画があり、この複雑性は払わねばならないコストである
こういった実装をしたら問題を同時に解決しつつ工数が増えずに済むのではないか
セキュリティに関して調査したらこういった実装方法があったが、どうにかならないか
まとめ
上記3つのフェーズが完了すれば、懸念事項がある程度クリアになっていて、お互いがお互いの意図企図をなんとなく理解し合えているはずである。おおよその懸念事項はクリーンになり、強いオーナーシップを持ってプロダクション向けの実装が開始できる。
マイルストーンや工数見積もりなど、みんなが知ってるモノサシで機能や問題が測れるようになる
このステップに到達するまでは、それらモノサシはただの援用ツール
ピジン語的な機能以上の価値は無いことが多い
何か問題が起きても、お互いへの責任転嫁や、そもそもなぜ実装するのかといった議論まで立ち戻ることなく、前進できる
立ち戻りが発生した場合は、議論が不足していたとも言える
提案者が何かを説明しなかったのかもしれないし、解決者が細部を詰めきれていなかったのかもしれない