InnerSource Commons コードの共同所有が企業活動のまん中に来る日

InnerSource Commons Meetup #2
インナーソース入門！ コードの共有所有から探るインナーソースの役割https://innersourcecommons.connpass.com/event/259065/

Transcript

1. InnerSource Commons コードの共同所有が 企業活動のまん中に来る日
2. 川口 恭伸 かわぐち やすのぶ Twitter: @kawaguti アギレルゴコンサルティング株式会社 シニアアジャイルコーチ 株式会社ホロラボ シニアアジャイルコーチ 一般社団法人スクラムギャザリング東京実行委員会 代表理事 一般社団法人 DevOpsDays Tokyo 代表理事
3. 研修やってます アギレルゴアジャイル研修 検索
5. ソフトウェアの品質ってなんでしょう？ 30年前なら、動いていれば よかったかもしれないけど、 今は、きれいに整理されていて、 メンテナンスしやすいことが必要。 どうやったら変更しにくくなる？ …を考える(たぶん数値では測れない)
7. この本が扱うのは人間だ。 それもソフトウェアを書く人間である。 ここ10年ほどの間、我々は、 共同作業によってソフトウェアを 生み出す方法について研究してきた。 優れたソフトウェアを効率的に 次々と生み出す能力に関心が あるのだ。
8. https://www.youtube.com/watch?v=CwodQs7D8BY
9. https://blog.bosch-si.com/ digital-transformation/ agility-at-bosch-mission-impossible/
10. https://blog.bosch-si.com/ digital-transformation/ agility-at-bosch-mission-impossible/ アジャイル開発は、テスラ社との協業にも役立ってい ます。テスラの電気自動車には、シャシーと安全シス テムを提供しています。これらのハードウェアおよび ソフトウェアコンポーネントの多くは、それぞれの車 両の要件に正確に適合させ、望ましいハンドリング特 性に調整することができます。このアプリケーション はテスラ社と短期間で成功裏に完成し、このプロジェ クトがアジャイルエンジニアリング手法の使用に適し ていることが証明されました。この成功したコラボ レーションが評価され、テスラは2014年に私たちに 「Excellent Development Partner」賞を授与しま した。これは、ボッシュが新規市場参入者を含む多様 な顧客要件に対応できることを改めて示すものです。 テスラ社との共同開発では、開発期間は通常の半分で 済みました。
11. ITバブル崩壊 2009年 リーマンショック 2001年 先アジャイル期 アジャイル期 DevOps期 まことに勝手なる歴史観
12. 1970-80年代 コンピュータの普及 1990年代 パーソナルコンピュータの普及 ソフトウェア工学の黎明 2000年代 Webブラウザ、仮想化、クラウド、スマホ 2010年代 スマホ/クラウド中心、ビッグデータと機械学習 軽量ソフトウェア開発 方法論の進展 フリーソフトウェア OSS 2001 アジャイル マニフェスト アジャイルの普及 リーンスタートアップ 2009年 リーマンショック 2010年東日本大震災 DevOps MIT, Xerox PARC, DEC, シリコンバレー Unix, Mac, Windows IE4-, VMware/Xen, Chrome, iPhone, Android ドットコムバブル崩壊 クラウドの普及 ユニコーン企業 GAFA+M ざっくり年表 日米経済摩擦 1985年プラザ合意 2001年同時多発テロ 自動車、半導体産業 1991年バブル崩壊
13. 1970-80年代 コンピュータの普及 1990年代 パーソナルコンピュータの普及 ソフトウェア工学の黎明 2000年代 Webブラウザ、仮想化、クラウド、スマホ 2010年代 スマホ/クラウド中心、ビッグデータと機械学習 軽量ソフトウェア開発 方法論の進展 フリーソフトウェア OSS 2001 アジャイル マニフェスト アジャイルの普及 リーンスタートアップ 2009年 リーマンショック 2010年東日本大震災 DevOps MIT, Xerox PARC, DEC, シリコンバレー Unix, Mac, Windows IE4-, VMware/Xen, Chrome, iPhone, Android ドットコムバブル崩壊 クラウドの普及 ユニコーン企業 GAFA+M ざっくり年表 日米経済摩擦 1985年プラザ合意 2001年同時多発テロ 自動車、半導体産業 1991年バブル崩壊
14. XPとは、自分たちのできることをオープンに して、それを実行に移すことだ。そして、そ のことをほかの人にも認めたり、期待したり することだ。「自分は頭がいいんだから、ひ とりで上を目指せばいい」などという未熟な 思い込みを克服することだ。もっと広い世界 で成熟した場所を見つけることだ。自己超越 のプロセスのことだ。そのプロセスの中で、 開発者として最善を尽くすことだ。ビジネス のためになる優れたコードを書くことだ。
15. コードの共同所有では、モ ジュールの割り当てそのものを 行わない。コードはチームの所 有物であり、誰もがどのコード にも変更を加えることができる。 コードの所有という考えがが無 いと考えてよい。ただ、コード の共同所有を提唱する者たちは、 個人ではなく「チームに」所有 されていることを強調している https://bliki-ja.github.io/CodeOwnership/
16. 決定と実行
17. 37Signals: 全員が働く 小さなチームでは、働いてくれる人が必要なので あって、人に仕事を振る人間が必要なのではない。 皆何かを生み出さねばならない。結果を出さない といけないのである。 つまり、他人にこれをしてと言うばかりの仕切り 屋を雇ってはいけないということだ。 「自分マネジャー」を雇う 自分をマネジメントできる人は、自身の目標にも とづいて実行する人だ。彼らは、あれやこれやと 指示を必要とせず、毎日の細かなチェックも必要 としない。
18. ぼくは、「Ruby」という オープンソースのプログラムをつくった まつもとゆきひろさんという人に 「オープンソースの秘密」について うかがったことがあるんですけど、 彼がとても興味深いことを言ってたんです。 どういうことかというと、 彼にはまず、つくりたいものがあるんですね。 誰かのために、というのではなく、 「自分はこういうものがつくりたい」と思って ひとりでダーッとつくっていく。 そうすると、自然に適切な大きさの 問題が生まれていくというんですね。 https://www.1101.com/ umeda_iwata/2008-11-18.html
19. 人間ひとりのできることには限界があるから、 まあ、一部分だけしかできない、と。 そうすると、あいつが言ってたのに できてないところがここにあるぞ、とか、 つくったというけど欠陥があるぞ、とか、 毎日毎日動きを続けていると、 適切な大きさの問題が つぎからつぎに生まれるんだそうです。 で、それさえ生まれれば、 インターネット上にはそれを解決する人が現れる。 新聞にクロスワードパズルが載っていたら それを解く人がいるように、 それをみんなが解いていくんだと。 https://www.1101.com/ umeda_iwata/2008-11-18.html
20. 糸井 おもしろい。その感じ、よくわかる。 梅田 おもしろいでしょう？ つまり、そこには、まつもとさんといっしょに 「なにかをやってやろう」という気持ちさえない。 それをつくったらユーザーのためになるぞ、 という動機もない。 自分のステイタスのためでもないし、 まつもとさんと仲よくなりたいわけでもない。 https://www.1101.com/ umeda_iwata/2008-11-18.html
21. 旧来型 リーダー の消失
22. コミュニティ形成を始めるときには、 まずなによりも実現できそうな見込 みを示せなきゃならない。別にその ソフトは特によく書けてなくてもい い。雑で、バグだらけで、不完全で、 ドキュメント皆無でもいい。でも絶 対不可欠なのが、開発者候補たちに、 それが目に見える将来にはなにか本 当に使える代物に発展させられると 説得できることだ。 伽藍と バザール Eric S. Raymond 山形浩生訳
23. リーヌスは、ハッカー/ユーザたちを たえず刺激して、ごほうびを与え続 けたってことだ。刺激は、全体の動 きの中で一員となることで エゴを満 足させられるという見込みで、ごほ うびは、自分たちの仕事がたえず （まさに毎日のよう に）進歩してい る様子だ。 伽藍と バザール Eric S. Raymond 山形浩生訳
24. オリジナルのスライド https://www.infoq.com/presentations/The-Roots-of-Scrum/ Google の戦略: マネジメントを取り除く • Rosing氏がGoogleに入社した2001年当時は、「エンジニ アリング部門にマネジメントがいました。そして、その構造 は、「そんなことをしてはいけない」と人々に言う傾向があ りました。そこで、Googleはマネージャー職を廃止します。 現在、ほとんどのエンジニアは3人1組のチームで仕事をして おり、プロジェクトリーダーはチームメンバーの間で交代し ています。何かおかしいことがあれば、それがすでにリリー スされたプロダクトであっても、チームは誰にも聞かずにそ れを修正します。アジャイル原則#5, #9, #12 • 「しばらくの間、私には160人の直属の部下がいました」と Rosing氏は言います。マネージャーはいませんでした。そ れがうまくいったのは、チームが自分たちのやるべきことを 知っていたからです。それが人々の頭の中の文化的なスイッ チが入りました。あなたがボスだ。出番を待つな。管理され るのを待ってはいけない。" アジャイル原則#1, #3 • そして、もし失敗しても大丈夫。次のアイデアに向かおう。 「賢くてやる気のある人たちが正しいことをする能力を信じ ています」とRosing氏は言います。「それを邪魔するもの が、悪なのです。」 アジャイル原則#5, #12
25. 大企業では優秀な人がバカになる?! • 「会社が大きくなればなるほど、 中にいる賢い人たちがバカに なる確率が高くなるという 仮説を立てています。」 • 大企業では、 沈黙こそが卓越性の真の敵。 賢い人は気づいているけど、 言わなくなる。 https://youtu.be/R1WG_u0o9JM
26. ビル・キャンベル: 人がすべて • どんな会社の成功を支えるのも、人だ。マネー ジャーの一番大事な仕事は、部下が仕事で実力 を発揮し、成長し、発展できるように手を貸す ことだ。われわれには成功を望み、大きなこと を成し遂げる力を持ち、やる気に満ちて仕事に 来る、飛び切り優秀な人材がいる。優秀な人材 は、持てるエネルギーを開放し、増幅できる環 境でこそ成功する。マネジャーは「支援」「経 緯」「信頼」を通じて、その環境を生み出すべ きだ。
27. 「こんにちは、私は xx です」というやり取りが一周した後、 車座に座って、お互いをしばらく凝視した後、誰かが言った。 「我々は、アジェンダ(今日話す議題)をどうやって作れば いいんだろう？」 すると、誰かがアジェンダ項目をインデックスカードに 書くことを提案した。XPの人たちは研修用にインデックスカードを 持ち歩いていたのですぐに取り出して書き始め、 書き終わったものを中央の床に放り込んだ。 急に、過半数の人々が床にインデックスカードを入れ始めた。 残りの人も、同じようにやり始めて、アイデアが尽きたときには、 床のインデックスカードは山になっていた。 https://kawaguti.hateblo.jp/ entry/20110213/1297531229
28. 誰かが尋ねた。 「このカードをどうやってまとめて、アジェンダにするんだろう？」誰 かが言った(私はこのときすでに、誰がなにを言ったかを記録する パワーはなかった)。 「アジェンダの順番に意見がある人は、このカードを並べ替えよう。 そうでない人は、ここを離れてもいい。」 私はトピックの順番は気にしていなかったので、休憩をとった。 私が戻ったとき、インデックスカードは壁にテープで貼られていた。 後で、誰かが「私は他のアジェンダ項目を考えているんだけど、 どうしたらいい？」と言い出した。 誰かが「アジェンダの空いているところ、好きなとこに貼りなよ」 と答えた。 https://kawaguti.hateblo.jp/ entry/20110213/1297531229
29. 私はこの作業にずっと付き合ったのだが、 それは、このグループの２つの特徴が私の心を打ったからだ。 リスペクト(Respect) その部屋にいた全ての人が、他の人に対して、絶大な信頼を置 いていたこと。だれもミーティングをハイジャックすることを試み たりしなかった。全員が他の人の意見を極めてじっくりとよく聞 いていた。常に、話している人に最大の信頼をおいていた。 自己組織化(Self-organization) そこは、最も優れた人々の自己組織化の場だった。それまで経 験した他の場では、常に一人の人（または、もっと悪い場合は 複数の人）がミーティングを "動かそう" とするものだった。偉 い人が部屋にいて、お互いをよく知らない場合、まず最初に権 力闘争が始まりやすい。そこでは、そんなことは一切起こらな かった。 https://kawaguti.hateblo.jp/ entry/20110213/1297531229
31. ソフトウェアが世界を食べている: 映画から農業、国防に至るまで、ますます多 くの主要ビジネスや産業がソフトウェア上で 運営され、オンラインサービスとして提供さ れるようになってきています。その多くはシ リコンバレー型の起業家的テクノロジー企業 であり、既存の産業構造に侵入し、覆してい る。今後10年の間に、さらに多くの産業が ソフトウェアによって破壊されることになる だろう。その際、世界をリードするシリコン バレーの新企業が破壊を行うケースがほとん どです。 https://a16z.com/2011/08/20/ why-software-is-eating-the-world/
32. クラウド時代への旅: アジャイルの第二の時代が来ている。 開発原則: - 常に稼働している - 完全に自動化している - サービス間を明確な契約で分離 - フィーチャーフラグ - 漸進的な(カナリア)デプロイ
33. https://www.slideshare.net/WinOpsConf/ sam-guckenheimer-moving-to-one-engineering-system 開発システム統合の目的 エンジニアやプロダクトチームにとって 生産性を向上する以上に大事な ことはありません。 ですから、週のどの日においても 機能を犠牲にしてでも 生産性を上げたい。 自社の最高のエンジニアたちに この開発システムで働いてほしいと 私は考えています。 その結果、長い目で見れば、 私たちが望む新しいコンセプトは すべて実現できるでしょう。
34. エンジニアリングの目指すべき星 • 全社のソースコードはだれにでも利用可能 • 開発者はだれでも会社のどこでも改善できる • 会社の知的財産は長年に渡って再利用可能な コンポーネントである • だれもが他の人の作った再利用可能なコン ポーネントを探すことができる • 開発者は人気のあるコンポーネントを作るこ とで称賛される • 開発者が変更を加えたら、すぐさま全社の社 員から見ることができる • ビルドとテストの時間は、変更を加えたらす ぐ確保される • 開発者は他のチームに移れるし、そのチーム での働き方を知っている https://www.slideshare.net/WinOpsConf/sam- guckenheimer-moving-to-one-engineering-system
35. https://logmi.jp/tech/articles/320413 米Microsoftで働く日本人エンジニアが語る、 “楽しく開発”するために必要なこと - Part1
36. 我々ソフトウェアエンジニアが、設計、実装、 あとはクラウドだったらデプロイから運用ま で全部、最初から考えてコードを書きます。 運用も責任の一部なので、テレメトリを見て 例外が起きていたら、当然自分が直す。どう いうテレメトリを埋め込めばいいか決めるの も自分の責任です。 https://logmi.jp/tech/articles/320413 米Microsoftで働く日本人エンジニアが語る、 “楽しく開発”するために必要なこと - Part1
37. クラウドって、いろんなサービスの大きな集合体なの で、自分のところを（ダウンさせずに）動かし続ける しかないんです。ほかのサービスが一時的にダウンし ても、当たり前に動かします。ネットワークが切れた り、毎日どこかが壊れるんです。そういう中でも毎日 動かしつづけるためには、テレメトリの運用、あとは、 そういうのをあらかじめ全部考えた上での運用方法の 確立というのは、絶対に必要です。 https://logmi.jp/tech/articles/320413 米Microsoftで働く日本人エンジニアが語る、 “楽しく開発”するために必要なこと - Part1
38. ソースコードって、要はいろんな人たちの知識の蓄積 なんです。これに対して読んだり、自分がアクセスで きて、なおかつそれに対してコントリビューション、 チェックインすることができる。これはものすごく素 晴らしいことだと思うんです。アウトソースするなん てもったいない。これこそが我々の知識の集約。それ を読めるということがもう、僕にとってはたまらない です。そういう権限を会社が与えてくれていることは、 すごく大きな信頼感につながっています。 https://logmi.jp/tech/articles/320413 米Microsoftで働く日本人エンジニアが語る、 “楽しく開発”するために必要なこと - Part1
39. https://logmi.jp/tech/articles/327160 テスラのアジャイル 1日60個以上の新しい部品がリリースされる 通常、部品のチェンジにだいたい2年から7年か けていると思います。テスラでは、ヘッドライ ト、テールライト、あと充電口などを2日で変 更します。2日で変更というのは、設計から製 造、そしてテスト、リリースまで2日で行って しまうということです。 テスラの「Model 3」や「Model Y」などの充 電口は3時間でアップデートが行われます。そ して、ソフトウェアや組み込みも含めて1日60 個以上の新しい部品がリリースされます。この 惑星の中で最速だと言えます。
40. https://www.businessinsider.jp/post-174645 例えば、製造技術のリーダー、 ミゲール・カレラは次のように 我々に語った。 ｢彼はいつも会社にいる。 誰もが、彼が机の下で寝ている 姿を見たことがある。 突然、皆が部屋から出ていくか ら、見てみると、誰かが机の下 に丸まっている。イーロンだ｣
41. 「もし私が一つの教訓を選ぶとしたら」 “他の何よりも多くの組織が失敗していると 思うことは、グループサイズです。リチャー ド・ハックマンの言葉を借りれば、チームが 5,6,7,8人よりも大きくなり、10人近くにな ると、物事が本当に悪くなるという証拠がた くさんあります。基本的には、10人、あるい は11人になると、調整のための雑務に費やす 時間が増え、実際に仕事をする時間が減って いきます。もう1つは、人間関係の問題が発生 することです。ディナーに行って10人、11人 と会話をするのは不可能に近いですよね。” https://youtu.be/R1WG_u0o9JM
42. コード チーム
43. 動くソフトウェア、 作れるチーム、 の周りに すべての力を 集める。
44. エクストリームプログラミングの原動力のひとつ は、ビジネスとテクノロジーの間の溝を癒すこと でした。私は、一般的に言われている2つのグ ループが激しく対立し、協力する方法を見つけて も必要なものが得られないという状況を目の当た りにしてきました。つまり、自分には納期を決定 する力があると思っている人が、その力の幻想を 手放そうとしなかったのです。そこにエクスト リーム・プログラミングが登場し、一連の人間関 係とそれを支える儀式、そしてそれらの儀式や人 間関係を支える技術的な慣習を提示しました。そ して、その代償として、締め切りを指示すること ができなくなりました。 (Kent Beck 2021年７月のAgile 2021でのトークより) https://ja.wikipedia.org/wiki/ ケント・ベック
45. それを良しとする人もいました。そして、そのよ うなチームはとてもうまくいきました。しかし、 一般的には、力関係は変わっていません。つまり、 インセンティブが変わっていないのです。だから、 行動は変わらない。だから結果も変わっていない。 私は、これはペアプログラムをするかしないかと いう問題ではなく、意思決定をスキル・情報・結 果に向けて動かす意思があるかどうかという問題 だと思っています。 (Kent Beck 2021年７月のAgile 2021でのトークより) https://ja.wikipedia.org/wiki/ ケント・ベック
46. Beyond Budgeting - enabling business agility 脱予算経営 - ビジネスアジリティを実現する 1.目的 - 大胆で崇高な目的のために人々を巻き込み、 奮起させる。短期的な財務目標ではなく。 2.価値 - 共有された価値観と適切な判断によって経営 する。細かいルールや規則ではなく。 3.透明性 - 自律的な規制、イノベーション、学習、コ ントロールのために情報をオープンにする。それを制 限しない。 4.組織 - 強い帰属意識を育み、責任あるチームを組織 する。階級的管理・官僚主義を排除する。 5.自律性 - 人々を信頼し、自由に行動させる。もしそ れを乱用する人がいても(それ以外の)全員を罰するこ とはしない。 6.顧客 - 全員の仕事を顧客ニーズと結びつける。利益 相反を回避する。
47. Beyond Budgeting - enabling business agility 脱予算経営 - ビジネスアジリティを実現する 7.リズム - ビジネスリズムやイベントに合わせて、ダイ ナミックにマネジメントプロセスを組織化する。年次の 決算に合わせるだけでなく。 8.目標 - 方向性と、野心的・相対的な目標を設定する。 固定の、カスケード(上位から分解した) 目標を避ける。 9.計画と予想 - 計画や予測を、無駄のない公平なプロセ スにする。硬直的で社内政治的なエクササイズではなく。 10.リソース配賦 - コスト意識を醸成し、必要なリソー スを提供する。年次の詳細な予算配分を行わない。 11.パフォーマンス評価 - 学習と能力開発のために、パ フォーマンスを総合的に評価し、ピア(1対1の)フィード バックを行う。計測のみでなく、報酬決定のためだけで なく。 12.報酬 - 競争ではなく、ともに成功することに報いる。 固定のパフォーマンス契約に対してではなく。
48. 1970-80年代 コンピュータの普及 1990年代 パーソナルコンピュータの普及 ソフトウェア工学の黎明 2000年代 Webブラウザ、仮想化、クラウド、スマホ 2010年代 スマホ/クラウド中心、ビッグデータと機械学習 軽量ソフトウェア開発 方法論の進展 フリーソフトウェア OSS 2001 アジャイル マニフェスト アジャイルの普及 リーンスタートアップ 2009年 リーマンショック 2010年東日本大震災 DevOps MIT, Xerox PARC, DEC, シリコンバレー Unix, Mac, Windows IE4-, VMware/Xen, Chrome, iPhone, Android ドットコムバブル崩壊 クラウドの普及 ユニコーン企業 GAFA+M ざっくり年表 日米経済摩擦 1985年プラザ合意 2001年同時多発テロ 自動車、半導体産業 1991年バブル崩壊
49. ITバブル崩壊 2009年 リーマンショック 2001年 先アジャイル期 アジャイル期 DevOps期 まことに勝手なる歴史観
50. ITバブル崩壊 2009年 リーマンショック 2001年 イル期 アジャイル期 DevOps期 まことに勝手なる歴史観 2020年 新型コロナ
51. ITバブル崩壊 2009年 リーマンショック 2001年 イル期 アジャイル期 DevOps期 まことに勝手なる歴史観 2020年 新型コロナ 脱権力の時代
52. 積み重ねだけだ それらの積み重ねだけが ヒトをヒト以上たらしめる メイドインアビス(10)
54. InnerSource Commons コードの共同所有が 企業活動のまん中に来る日