コラボレーションは最悪だ！無駄な共同作業にうんざりする開発者の本音
引用元：https://news.ycombinator.com/item?id=45892394
コラボ現場を見たら「人数多すぎ。Xがお前が決めろ！」って言え。（これ友達作りに最高）。マネージャーは「お任せ」って言ってから後出しで口出すのやめろよな。そうやってると従業員いなくなるぞ。
もっと最悪な結果もあるんだぜ。開発者は賢いけど、全員が対立的になれるわけじゃない。上司が急に忙しくなったら、それは部下の判断を何度も潰したせいだろ。チームは全部の決定に君の“助け”を求めるようになり、悪い結果は全部サプライズ。彼らは君を自分の傲慢さと支配欲で窒息させようとしてるんだよ。
ソフトウェア開発者はみんな自分が賢いと思ってて、そう話して誇りにしてる。でも実際は、めちゃくちゃバカな開発者も多いんだよな。
Appleを辞めた理由の一つさ。マネージャーの上司がいつもこんなこと言ってて、僕がPR出すと、結局ゼロから全部やり直させられるんだ。何やっても結局書き直す羽目になるって分かってたから、プロジェクトやるのが嫌になったよ。
僕らは概ね賢さで雇われるから、そうなるような選抜が多いんだ。知恵で雇われる方がいいよな。賢さと愚かさを混同すんな。両方あり得るんだから。でも開発者は、部下を子供扱いして、自己成就する予言に驚くような奴じゃない。それはTaylorのせいだ。
前の職場で、「～についてはどうだ？」って言葉が、僕にとって段々トリガーワードになったんだ。無限のピクセルやレイアウト調整、それに大幅なフルスタック再作業が必要な新機能のせいでね。
僕がまだAppleにいる理由の一つだよ。僕のマネージャーは僕の決定を尊重してくれるんだ（正直、たまに歯を食いしばってだけどね）。「人は仕事を辞めるんじゃなくて、マネージャーを辞める」って言うしな。
自分が賢いって自慢したり、開発者全体が他の職業より賢いって言うのは賢くないぞ。それはお前が賢くない証拠だ。平均IQは110-113で、平均の1標準偏差を少し超える程度。開発者は特に賢いわけじゃないけど、やたらと自分が賢いと思いたがる奴が多いんだよ。間違ってることを自慢するのは賢いか？いや、違うね。
ソフトウェアプロジェクトで最悪の4つの言葉はね、「なんでただ～できないの？」だよ。
「これは簡単だ」とか「すぐ終わる」って言葉も、まじでよく聞くようになったよな。
開発者はコードや技術の才能で雇われるけど、その才能が社内政治やマネジメントのうまさに繋がるとは限らないんだよな。
Taylorのせいじゃないって！彼は作業の標準化や改善、専門家による指導を推進したんだ。労働者を蔑むなんてひどい考えは持ってなかったし、労働者への権力ゲームや発言の無視には強く反対してたんだぞ。
マネージャーを追い出すためにグループでいじめるって戦術があるんだよ。公共部門ではかなり効果的で横行してるから、マジでうんざりするぜ。
「君に任せるよ」って言われても、要求がないわけじゃないんだ。俺のチームでは各自に任せてるけど、みんな批判的思考で正しいことを選ぶ必要がある。マネージャーが「これ足りない」って言えるなら、それは実装が間違ってるってことだよな。
ところで、コンピューターサイエンスの卒業生の平均IQは130だってさ。これで何が言いたいか、好きに考えてくれよな。
あーあ。俺は、デザイン（ドキュメント＋承認、ライブ議論など）を先にやるか、いきなりPRを出すか選べるのが好きだね。デザイン合意済みなら、レビューで根本的な再考はレアケースであるべき。PR直行は実験だから、別の設計案が出たら捨てる覚悟が必要だ。これは記事の提案と違うけど、高信頼性インフラを扱う俺は速度より品質を重視するから、それでいい。
作業の標準化は、人をマネジメント層に研究され改善されるオートマトンに変えちまったんだ。Demingが日本で意見を聞いてもらうまで米国の景気後退を招いたし、結局うまくいかなかった。DemingやGoldrattは従業員を議論に引き戻したんだ。Taylorは新封建主義で、マジでクソだな。
出荷前に協力せず、出荷後も振り返りレビューしないなら、どうやって意見を出すんだよ？
昔の職場では、パートナーの一人がエンジニアチームが「やりすぎ」って文句ばっかり言ってたんだ（実際は全部ギリギリだったのに）。そいつの口癖は「〜するだけでいいんだよ」で、しばらくはイライラしたけど、そのうちエンジニアの間で「バカな〜するだけ」アイデアを競い合うジョークになったよ。
わかるわー。Appleにはチームがいっぱいあるけど、マジで上司がすべて。AppleのPhotosチームは最悪だったけど、他のチームはどこも良かったよ。（だからPhotosチームは辞めて、いい上司のいるチームに移ったんだ。Appleにはそのまま残れたし、異動しただけだけどね）
リリースしたもので改善していくんだよ。一回やったら終わり、ってものじゃないからね。
上の方でみんなが不満を言ってることって、Taylorのせいじゃないんだよ。彼はむしろそれに積極的に反対してたしね。最初の一行で文句言ってることはそうだけど。それにTaylorは労働者の声を聞くことを支持してたし。Taylorismのすべてを彼に押し付けるのは違うよ、彼が発明したのはそのほんの一部だけだから。Demingも作業の標準化を提唱してたし、工場を運営するならそれなしじゃ無理だろ。
「It’s your call」ってのは、テーブルにある選択肢はどれも有効で要件に合ってるから、従業員に判断を任せるって意味だよ。その後でその判断にケチつけるのはマジで最悪だし、信頼関係が崩れる。だって従業員はその後、自分の判断に自信がなくなるし、決定を下すのを避けようとするようになるからね（どうせひっくり返されるって思って）。
今、まさに今の職場でそういう状況だわ。いつも同じエンジニアがいて、なぜかそいつだけはデザインレビューしなくていいのに、他の人のデザインには口出ししてくるんだよ。先週、そいつが手抜きしたせいでサービスが数時間、いや数日間停止しかねない危ない橋を3回も渡った後、俺はこのコンポーネントをどう改善するか決める会議を主宰したんだ。そのエンジニアも招待したんだけど、割り当てられた会議時間全部使って、集めた選択肢全部にFUDをばらまきやがった。そしたら経営陣は何も行動しないって決めたんだよ。
これ、よくつぶやいちゃうんだよね。でも、つぶやいた95%の時間は、その後すぐに簡単な作業はしちゃうんだけどさ。
上司を辞めたいときは、いつも会社内で異動するんだ。新しい仕事を探すよりずっと簡単だしね。それに、その新しい部署の役割についても、もっと情報があるから。経験のない分野に飛び込むのにもいい方法だよ。
これいいね。自然な現実だと思うよ。信頼度が低い場合（新しいチームに加わるときなど、多くの理由でね）、デザインドキュメントから始めるのはリスクを減らすかもしれないね。
IQの統計データが少なすぎて評価できないって意見、わかるよ。そんな情報なしに提示するのは、正直言って低IQだよね。元の投稿にはほとんど同意するんだけどさ。
「締め切りなし、調整最小限、マネージャーなし」と「異常に高いオーナーシップ」は、一見良さそうだけど、やり方を間違えると危ないよね。高いオーナーシップでやりたい放題って、それが会社の目標とズレたらどうするの？全体的な目標構造がないと、会社は成功できないよ。
本当の問題はコラボレーションじゃなくて「意思決定」だと思うな。誰かにレビューしてもらったりフィードバックをもらったりするのは、悪いことじゃない。学びの機会だしね。問題は、最終決定者が誰かわからないとか、全員の合意が必要なこと。決定者が明確で、さっと決められるなら、もっと早く進めるよ（ほとんどの決定は後で修正できるしね）。
もっとコメントを表示（1）
この投稿の核心は前のコメントに同意だね。コラボしないと学びの機会が減って、個人の成長が止まるよ。意思決定者は明確に任命して、責任と権限を持たせるべき。でも、みんなのフィードバックには耳を傾けるべきだ。彼らが聞いてもらえていると信じられれば、実際の意思決定プロセスには口出ししないだろうしね。可逆的な決定は早くすべきっていうのも同意。あと、「コラボはスピードを落とす」って意見だけど、それは良いことなんだ。ちゃんと考えるきっかけになるし、説明できないならやるべきじゃない。品質はゆっくりやれば上がるよ。
「ゆっくりやれば品質が上がる」っていうのは、ある程度はわかる。でも、そのアプローチだと、チームが居心地の良い現状維持に陥っちゃうこともあるんだ。時にはリスクを取ることも必要だよ。
人は主体性を持って、前に進む力を感じる必要があるってのはわかるよ。でも、主体性があるからといって、説明責任がないわけじゃないし、やってることを説明できないわけじゃない。結局、速く動くのとゆっくり考えるのは難しいバランスなんだ。だからまだ完璧な、長続きする解決策は見つかってないんだよね。
「ゆっくりやれば品質が上がる」は違うな。品質に関する一番の洞察は、出荷後じゃないと得られないんだ。遅らせるってことは、その洞察も遅れるってこと。ロケット産業とかじゃない限り、ゆっくりやるのは品質にとってマイナスだよ。
最終決定者が誰か不明とか、全員合意が必要なことに加えて、その決定がどれくらい固まってるのかわからないのも問題だね。PMとして、エンジニアリングに関わる多くの決定に「GAFスコア」（Give A Fuck score）を付け始めたんだ。例えば、「この往復時間は200ms以下にしないとダメ、GAF-10だ」みたいに、どれだけ重要かを伝えるんだ。もし「アプローチAで行こうと思うけど、GAF-2だから、もしダメそうならまた相談して」とかね。こうすればチームは進めつつ、無駄に頑張りすぎないで済むんだ。
GAFスコアって、すごく良いアイデアだね！
レビューやフィードバックが悪いことだった経験、いっぱいあるよ。PRを私物化して決定を乗っ取る同僚がいたり、「このエッジケースは起こらないから過剰設計だ、やめろ」って言われて、1週間も経たずにそのエッジケースにぶち当たったりね。あるチームに作ってあげたものが、別のエンジニアのせいでアーキテクチャを大幅に変更させられて、結局チームには嫌がられたりもした。この投稿は本当に共感したよ。良い人を雇って、意思決定を任せるべき。そうすれば、たいてい良いものができる。デザインバイコミッティで素晴らしい製品ができたのを見たことがないんだ。フィードバックを重ねるうちに、まともな貢献が悪くなっていくのを何度も経験したよ。
フィードバックを重ねるほどコードが悪くなるって、まさに委員会設計の罠だよね。みんながちょっとしたことで口出しするから、結局誰もPRに責任持たなくなるんだ。品質と開発速度には最適なフィードバック量があって、それを超えるとむしろ劣化するって観察、マジ同意！
コラボレーションには意思決定と、それぞれが何をもたらすか明確にすることが大事なんだ。SMEと組むならドメイン知識を、戦略を練るなら現場の状況を、って感じで期待値を共有しなきゃダメ。目的や見返りがハッキリしないと、どんなに善意があってもプロジェクトはうまくいかないよ。
いいマネージャーやリーダーって、自分で決めるんじゃなくて、メンバーが自律的に意思決定できる範囲を広げるもんなんだ。例えば、プロダクトの目的を示したり、優先順位のフレームワークを与えたり、あるいは「このソフト買って使っていいから、他のことに集中して」みたいに決断の選択肢を減らしたりするんだね。
フィードバックを受けたら対応しなきゃって思うのが、俺たちの性（さが）だよね。でも、シニアはフィードバックをいつやるか（後で、バックログに、今すぐ）をちゃんと考えて、ジュニアはどんなフィードバックが欲しいか明確にすべきなんだ。そうすればもっと上手くいくはず。
PRのコメントには、「issue／question／nitpick」みたいに接頭辞をつけるようにしてるよ。全部修正しなくてもいいけど、コメントを読むのはやっぱり役に立つからね。
フィードバックと最終決定は違うって意見には同意するよ。でもさ、非技術系の人が最終決定者で、たくさんのシニアが会議に出ると「Design By Committee」になっちゃうんだよね。最終決定者がみんなの意見に流されたり、自分の意見が強くなかったりしても、結局そうなっちゃうのがマジ困る。
フィードバックって学びの機会としてはいいんだけど、最終決定とは違うんだよね。いくつか会社を経験したけど、フィードバックがわざと反対意見を出すゲームみたいになって、主導権を奪われることがあったよ。一度却下された自分の元の案が、後で別の誰かから提案されるってのもマジで腹立つんだよね。
意思決定には「独裁者」「仲裁者」「調停者」の3タイプがあるけど、フィードバックを聞いてから決める「仲裁者」が一番うまくいくし、人気も高いんだって。この仲裁の文化ってのは自然にできるものじゃなくて、意識的に作っていかないとダメなんだよね。
「コラボレーション」ってのは、共有の目標のために一緒に働くことだろ？この記事で言ってるのはコラボレーションじゃなくて「フィードバック」だよ。目標もタスクも、そもそも俺たちのものなんだから。定義をちゃんと使い分けようぜ。
Charlesのスパークリングウォーター嫌いには同意しないけど、この問題が表に出たのは嬉しいね！コードレビューで細かいスタイル修正に3倍の時間かけた経験もあるし。スタイルに関する指摘は自分で直して教えてくれた方がお互い助かるってのが本音だよ。大半のフィードバックにも当てはまると思う。Be weird and do stuff. https://www.youtube.com/shorts/DjvVN4Vp_r0
フォーマッタを使えよ。コンパイルとかビルドとかコミットのフローに組み込んで、スタイルが合わないならパイプラインを失敗させるくらいすればいいんだ。レイアウトの要件があるなら、それをみんなに伝えて強制しろ。コードレビューで細かいこと直すなんて遅すぎるだろ。
俺の職場じゃ、コードのフォーマットはフォーマッタが最終決定権者なんだ。もし気に入らないなら、その変更を正当化するのはめちゃくちゃ大変だぞ。何千人ものエンジニアが試しては、色んな理由で敗北してきたから、よく考えた方がいい。
フォーマッタがコードの最終決定者なのは全然アリだね。読みやすさには一貫性が超大事だし、コードって書くより読まれるもんじゃん。読みにくいレガシーコードは誰も読みたくないし、新しく作り直したくなる。みんなが変えたいって言う変更の大半は標準的じゃないから、新しいチームメンバーがコードを読みにくくするだけなんだよ。BlackとかPrettierとかSpotlessとか入れといて、さっさと次に進めって。
俺もフォーマッタは好きだよ。信頼できるし、予測通りに動くからね。細かいスタイルに関する意見の対立がなくなるのもいい。
スタイルに関する細かい指摘って話だけど、オートフォーマットを使ってない会社なんて珍しいし、同じ問題に何度もぶつかるなんてありえないだろ。多分、関数名や変数名、三項演算子、戻り値の型とか、そういう類の話だろ？
周りのコードに自分のスタイルを合わせようとしない奴は、問題があると思うな。細かいって思われがちなことでも、可読性にめちゃくちゃ大きな影響を与えるし、他の人の前提を壊すこともあるんだから。
それ以上に、それは開発者が周りのコードを理解するのに時間をかけてないってことだ。だから、負債やCRUFT、リスクを増やしてる可能性が高いんだよ。
これってコラボレーションとは関係ないでしょ。PRで細かいこと言いまくるのは間違ってる。リンターを使うとか、そういう細かい指摘をしない文化を強制すべきだ。こんなの、”コラボレーションの文化”なんかじゃないよ。
リリースされた機能は全部負債だよ、資産じゃない。信じないなら、顧客を同じくらい満足させる製品が二つあって、片方が動く部品が半分だとする。どっちが維持に利益がある？ ゴミが少ない方だ。他は全部負債でしかないんだから。
だから俺が一人で速攻で機能を出して次に行くと、もっと早く大きな問題の種を蒔いてるってこと。一番大事なのは、俺が何を作ったか、なんで作ったかを、お前ら誰も知らないってことだよ。スタンドアップとか、俺が一人で書いたクソなドキュメントでかじった程度だろ。もし俺が森でハイキングしてる時にクラスターが炎上したらどうする？ その機能、ちゃんと一緒に作ってたら良かったって思うだろ？ そしたら、他に聞ける人が二人いたはずなのにさ。
あなたは機能と可動部品を混同してるよ。機能は資産だ。可動部品（つまりコード）が負債なんだ。それらは同じじゃない。
コードを減らしたり、リファクタリングしたりして、同時にプロダクトを改善できることだってあるんだから。
「もし俺が森でハイキング中にクラスターが炎上したらどうする？ そしたら他に聞ける人が二人いたはずだ」って言うのはもっともな意見だけど、それは規模によるかな。小さいことなら簡単に理解できるし（でも、それがシステム炎上の原因じゃないかも）。あと、少なくとも一人はコードレビューをしてるはずだから、何が起こってるか少しは知ってるはずだろ。
混同してるのはあんただよ、だから俺たちの多くはUXが苦手なんだ。ソフトウェアでタスクを達成する能力こそが資産なんだよ。全てのアプリが同じ操作数でタスクを終わらせるわけじゃないし、それぞれの操作自体が機能なんだ。
ウォーターフォールでもスクラムでもカンバンでも、”機能”って言葉はユーザーが意味のあることを達成する能力と直接関係ない。それは、開発者が何かやったっていう尺度であって、その”意味”ってのはただの仮定で、現実じゃないんだ。
「すべての機能は負債であり、資産ではない。」っていう例えに対して、「誤った類推だ」って反論してるね。機能の数が半分の製品とそうでない製品の利益性を比べるなら、顧客がその機能にお金払うかどうかで全然変わるじゃんってさ。
顧客は俺らがどれだけ賢いかとかどうでもいいんだよ。ただタスクを片付けて次の４つの仕事に進みたいだけなんだ。彼らは俺たちのことなんて気にしない。上司に言われたことをやるか、悪者を倒して宝を手に入れたいだけで、俺たちは邪魔になることだってよくあるんだからさ。
俺がいつ「顧客はタスクを片付けたいだけ」ってことに異論を唱えたんだ？このコメントは「機能」と「可動部品」を混同してることについて言ってるんであって、それらは別物だろ。それに、人々は機能が多いソフトウェアにお金払うことが多いんだからさ。
もっとコメントを表示（2）
これって人間の性だと思うんだ。恋人関係でも、パートナーが些細なことで文句言うことってあるじゃん。経験と練習を積めば、そういうのを乗り越えられるようになるんだ。だから、経験豊富なレビュー担当者も同じってことだね。
「些細なこと」って言ってたけど、もしパートナーが１日に５回も文句言うなら、それって本当に些細なことかな？「乗り越える」んじゃなくて、なんで彼らが気にするのか理解した方がいいよ。結婚１０年でパートナーに捨てられても理由が全く分からないって言う男たちみたいにね。
些細なこと＝構文エラー
コミュニケーション＝両者が効果的な方法でコミュニケーションすることを学ぶこと
「タブストップは些細に見えるかもしれないけど、コードを読みやすくレビューしやすくするんだよ。」
「分かった、懸念を理解したからエディターを設定するよ。」
「便座は些細に見えるかもしれないけど、真夜中に落ちたらお互い困るでしょ。」ってね:)
何が「細かいこと」で、何が「コードをきれいに保って、他の人が仕事できるようにするために不可欠なこと」なのかって、誰が判断するんだ？
全く同感だね。俺はスタイルとかフォーマットとか本当にどうでもいい。もし気にするなら、自動化すべきだってのが俺の意見だよ。
筆者は「すぐ行動する」ってのを推してるけど、コラボレーションを捨て去るのはやりすぎだろ。それじゃあ孤立しちゃうし、独りよがりの決定ばっかりになって、避けられるはずのトラブルが起きるだけだよ。長期的にベストな結果を出すには、実用主義的なアプローチで良い落としどころを見つけるべきだろ。そうじゃないと全社集会とかブログ記事で面白い話にならないってことかな。
「すぐ行動する」って点では、前の会社で「Xをやるつもりだけど、何か強い反対意見ある？」って聞くのがめちゃくちゃ効果的だったよ。強い反対意見ってとこがポイントで、ほとんどの無駄な議論を避けられたんだ。もちろん反対意見があればちゃんと議論するけど、大抵は賛成でサッと進むんだ。
これについては意見が分かれるな。どっちかの極端が常に正しい解決策ってわけじゃないからね。官僚的な会社にはこの記事のアドバイスが必要だろうけど、技術的負債に苦しむ会社は避けるべきだ。でも今のIT業界では、片方が圧倒的に評価されがちだから、この記事の意図はわかるよ。もう一つの極端な問題は「統合」だね。計画なしに２つの別々のシステムを作って、結局チームがお互いをちゃんと連携させようとしない。そういう時に、共通のアーキテクチャが必要になるんだ。
このやり方の強みは、yes/no形式で、デフォルトでGOにするって仕組みを作ったことだね。こうすれば物事が進むんだよ。
フィードバック文化に脳を乗っ取られてるよ。「強い異論」とか言ってるけど、それって結局コラボのフリした許可待ちじゃん。企業のお芝居だよ。余計な手間を増やして、みんなの集中力を削いでるだけ。出荷して、使ってもらってからフィードバックもらって、改善すればいいじゃんか。
まず、あんたがコラボはダメだって言ったところで、それが真実になるわけじゃない。次に、そのプロセスを誤解してるみたいだね。手順は「すぐに出荷する。この方向で決めた理由はXYZ。異論があるなら短い時間で、ただしその異論は些細なことじゃダメ。」許可待ちはないし、道は決まってるんだよ。事後に異論を出すのがいいと思ってるなら、勝手にやれば？
GitHubのエンジニアの話、興味深かったな。コード書く前に「どうやるか」の空のPRでチームの承認が必要なチームがあったって。これってスマートなコラボだよ。単に「やる」だけじゃなく「正しいこと」をやるには、集合知が大事。良い文章力とコミュニケーションスキルがあれば、コラボは速くて効果的。視野狭窄も防げるしね。Perseverance bias、sunk cost fallacy、cognitive entrenchmentは記事に欲しかった。AIが広まる今、これらのスキルはもっと重要になるよ。
「物事を成し遂げる」が大事って言うけど、年取るほど違うと思うわ。でかい組織だと「会議と目立つこと」が一番大事なんだよ。ただ仕事を終わらせるだけじゃ誰も評価してくれない。良い計画で問題を未然に防いでも、誰もその功績を知らない。だから、最適なのは定期的に会議して上層部を巻き込み、「予期せぬ問題」を起こさせて、それを解決してヒーローになること。俺の組織では、問題を未然に防いだ人には特別報酬が必要なくらい、これは共通認識なんだ。
残念ながら、反論できないわ。会社だと「やったこと」の評価は見る人次第って、あんたの言う通りだよ。この記事書いてるposthogもそうじゃないってフリしてるけど、どの組織も避けられないよね。GitHubもホラクラシーっていうフラットなマネジメントを取り入れてから問題だらけだったんだ。誰も責任者がいない状態は、いくら空のPRを増やしても解決できなかった。この記事がposthogのリーダーシップを通過したってことは、彼らがリーダーシップの危機に陥ってる可能性もあるかもね。
昔から言うじゃん…コードを出荷しても誰もそれに気づかなかったら…本当に価値を提供したって言えるのかな？
「年を取るほど、大事なのは会議と可視性」って話があったけど、エンジニアを4つのタイプに分けられるよ。
・自分を売り込みたい「セールスエンジニア」は目立ちたい。
・スタートアップエンジニアは、最低限の売り込みで、とにかく出荷したい。
・職人気質のエンジニア（研究者）は、「正しく」仕事を終わらせたい。
・ブルーカラーエンジニアは、とにかくチケットを消化したい。
成功の基準は人それぞれで、環境によって必要なスキルも変わるんだ。
俺のチームでも、重要なことに関してはそういうやり方してたよ。非同期じゃなくてチームミーティングでね。マジでめちゃくちゃ価値があった。システムが複雑だから、みんなが全部を知ってるわけじゃないし、もっと簡単な方法を誰かが教えてくれて、チームメイトの時間をすごい節約できたことが何回もあったんだ。
俺、このやり方のために10年間も戦ってきたんだ。組織は2つに分けられるね。その価値を理解して、うまくやるチーム。もう一つは理解できず、常にリファクタリングやバグに追われ、コードの目的すら誰も分かってないせいで、数えきれないほどの問題を抱えてるチーム。この差はデカいよ。
PostHogも、賢いコラボレーションが必要な時はRFCs (https://posthog.com/handbook/company/communication#requests-…) で同じことしてるよ。俺がOPの投稿を読んだ限りだと、これは孤立の話じゃなくて、信頼の話だと思うな。
大まかなアーキテクチャや戦略の計画は理解できるけど、実際のコードは計画できないんだ。何を作るかは、座って作り始めることで、プロセスはすごく反復的。多くのものをスタブ化して逆算していくんだ。コードの正確な変更計画は、実際に作ってみないとわからない。
考えてみてよ、十分な時間があれば君にもできるはず。たぶん君には、そんな時間を与えてくれるマネジメントがいなかったんだ。物事を書き出すのは大変な作業だけど、練習すればうまくなる。時間があれば、培ったスキルが計画に収束する。物事を書き出すことで得られるワクワクする禅のような状態で、アーキテクチャやチームについて深く考えられるんだ。それは全く違うものを作り出す感覚で、すごく満足感がある。そうすれば、君はシニアエンジニアになれるよ。
＞ チームは、作業が始まる前にそのPRにサインオフする必要がある。これをコラボレーション以外でどう説明できる？
それって、一つの課題に対するアドホックな計画みたいだね。例えば2週間ごとに、オープンな課題の一部について同じことをするってこともできる。そう、それでSCRUMが生まれたんだよ。
＞ それって、一つの課題に対するアドホックな計画みたいだね。例えば2週間ごとに、オープンな課題の一部について同じことをするってこともできる。
つまり、チーム全体に、一部の人しか興味ないことに時間を費やさせるってこと？しかも非同期じゃなくて、ブロックするやり方で？一体どんなメリットがあるっていうんだい？
なら、君のチームは大きすぎるんだよ。もし計画会議に7人以上いるなら、チームがデカすぎる。それに、計画は決して非同期じゃない。インプットがあるかもしれない全員をブロックする方が、よっぽど正直だ。作業量（ポイント）を計画すれば、実装前に問題を発見できるんだ。完璧じゃないけど、計画をするなら、ちゃんとやれよ。
＞ そして、それは決して非同期じゃない。インプットがあるかもしれない全員をブロックする方が、よっぽど正直だ。
どうして？全員に見てもらう必要があっても、非同期の方が時間と集中力を尊重できるでしょ。稀なケースのために一般的なケースを悪化させる必要はないよ。
＞ 完璧じゃないけど、計画をするなら、ちゃんとやれよ。
『ちゃんと』って何？難しくて時間のかかる方法で計画するのは、立派に思えるかもしれないけど、実際には得策じゃないよ。
俺の経験だと、4時間の会議にしたくなければ、Scrumプランニングは実装の詳細にまで深く踏み込まないものだよ。
この方法は機械工学でも効果的だよ。少人数の前で事前に作業やデザインを計画すると、時間と無駄な労力を節約できる。これは基本的なプロジェクト計画で、多くの現代エンジニアリングチームで未発達なスキルだと思う。『空のチケット』の例だと、低レベルの計画だね。全ての作業に必要じゃないけど、特にジュニアレベルの人がタスクをこなす場合に有効だよ。このアプローチを全面的に支持する。主要なプロジェクトはチームでやるもので、調整とコラボレーションは必須だからね。
『良いデザインのドキュメントがなければ、大小問わずあらゆる間違いは、おそらくその間違いを最初に犯した唯一の人間によって分析される。なぜなら彼だけがプログラム領域を理解しているからだ。』— Winston Royce, 『Managing the development of large software systems』
でも、過剰なコラボレーションも似た状況を招くのを見てきたよ。みんな、延々と続く話し合いを各自が解釈して、自分なりの計画のモデルを持っちゃうんだ。真実とされるデザインドキュメントがあっても、誰も見てないかもね。口論や混乱のせいで、維持が不可能になるからだろう。
