お前らの議論の仕方は間違ってる -フェーズを意識した議論の進め方-
https://qiita.com/crossroad0201/items/69fda265cdeda134f7af
ある期間で、ある人数で、ある金額で仕事をするときに、いろいろな制約条件にがんじがらめの場合には、上記方法で仕事をすることに意味があることは合意。
共有とか、決定とか、自分でしたことがない人がいて、仕事の流れに追従だけしていると、技術力とか、指導力とかは身につかないかもしれない。
オープンソースで共有, 発散, 収束, 決定がいらない仕事を進めてみて、技術力とか指導力とかを考えるのもよいかもしれない。
「オープンソースプロジェクトで上手いことやってくための10の方法」を拝読し
https://qiita.com/kaizen_nagoya/items/81265788e7cf8f7b230b
この記事と、この記事の元記事に共通の事象、認識を出発点として論を進める。
「」書きの事項が、１０の方法のうちの９つ。
共有
オープンソースは初めから共有している。
仮説(10)「共有」と言って良い時
オープンソースでない事業の場合、共有と言いながら、紐付きで、制約が多く、共有でないことがしばしば。
オープンソースで、共有ってどういうことか経験しておくとよい。
「こまけぇことはいいんだよ！まずはやろう！」
「GitHubの仕様をよく理解する」
「英語を使う」
発散
オープンソースの利用対象集合は、全世界である。
分布は発散している。
敢えて、発散する必要はない。
「やりたいようにやる」
「人には好み、主義・主張がある」
「敵はどこにもいない」
収束
オープンソースでは発散しているものを収束させる必要はない。
自分のやりたいようにやればよいだけだから。
「利用者を守る」
「ローカルルールに従う」
「相手に敬意を払う・おもてなしの心」
決定
オープンソースでは発散しているものを収束させてから決定する必要はない。
自分のやりたいようにやればよいだけだから、発散したまま決定すればよい。
まとめ
オープンソースでは、共有・発散・決定が同時。
次に自己決定で分岐（発散）するかもしれない。
最後に統合決定（収束）するかおしれない。
収束してから決定するのではない。
流れとしては、
共有・発散・決定ー＞自己決定・分岐（発散）ー＞統合決定（収束）
オープンソースで、どこからか資金が出るときには、別の方法を取ることもある。
オープンソースで、何人かで組んで作業するときには、別の方法を取ることもある。
大事なのは、構造設計社(architect)が、よりよい構造への変化の可能性を見積もり、いつ構造変革を行うか。
よくない変化を捨てる決断がでるかどうかなど。
進め方（process)ではなく、構造についての決断（決定）が大事かも。
それ以外の、もろもろの制約条件、複数の選択肢、過去の遺産の継承など、など。
一度、オープンソースで、構造設計から、配布、分岐、統合などを経験しておくと、制約条件の多い業務で、どこまで発散し、いつ収束するといいかの勘所がつかめるかもしれない。
オープンソースの世界に嵌ってしまって、抜けられなくなるかもしれない。
＜この記事は個人の過去の経験に基づく個人の感想です。現在所属する組織、業務とは関係がありません。＞