(翻訳) GitLab 社で働くのはどのようなものだったか
本稿は Yorick Peterse 氏によって書かれた次の記事の日本語翻訳です。著者に翻訳の許可を得て公開しています。
また本稿は DeepL Pro を使って下訳したものに手を加えています。日本語翻訳の不具合または誤訳については Yorick Peterse 氏ではなく、本稿のコメント欄にお願いします。
ここから本文です。
GitLab 社で働くのはどのようなものだったか
私は2015年10月に GitLab 社に入社し、6年あまり働いて2021年12月に退社しました。
前に GitLab 社を辞めて Inko に取り組んでいることは書きましたが、2015年から2021年までの間、GitLab 社で働いていたことがどのようなものであったのかについては触れませんでした。理由は2つあります。
- 燃え尽き症候群に苦しんでいて、(当時は) 自分の人生の最後の6年間を見直す気力がありませんでした
- 私は24ヶ月間の NDA 下にあり、おそらく何の問題も起こさないだろうとはいえ、NDA に違反することなくどこまで議論できるか確信をもてませんでした
その NDA は昨年12月に失効し、私はまだ燃え尽き症候群の影響があると思われますが、GitLab 社での時間をふりかえるエネルギーは少しあります。
この記事は大きく2つの節で構成することにします。1つはまだ覚えていることに基づく GitLab 社での私が働いた概要と、もう1つは私の仕事と経験から学んだことです。
GitLab 社の入社前
GitLab 社に入社する前、私はアムステルダムを拠点とする小さなスタートアップで働いていました。ほとんどのスタートアップがそうであるように、私が退職するまでの数ヶ月間、会社は資金不足に陥り始め、費用を賄うためにオフィススペースの一部を貸し出すなど、絶望的な解決策に頼らざるを得ませんでした。同時に、技術的なレベルではやりたいこと、できることはやり尽くしたという思いもありました。
これと並行して、余暇には Rubinius の開発にも取り組んでいて、様々な場面で Rubinius の利用を検討し、すべてのコードが問題なく動くことを確認するまでに至りました。これは、Nokogiri に代わる XML/HTML 解析ライブラリ Oga の作成にもつながりました。
残念ながら、資金不足とさまざまな技術的問題が重なり、Rubinius の利用をそれ以上追求することはありませんでした。このようなことから、私は Rubinius を本番環境で使用できるほど安定させたいと思い、少なくとももう少し Rubinius の開発に時間を費やせる仕事を探し始めました。
その間、アムステルダムで開催されるさまざまな Ruby ミートアップに参加したり、Rails Girls のワークショップを手伝ったりしました。これらのワークショップのひとつで Sytse と彼の妻に出会い、後のワークショップかミートアップでまた出会いました (もうずいぶん前のことなのでよく覚えていません) 。その中で GitLab 社のことを知り、そこで働くことに興味を持ちました。
2015年の夏のある時、私は Sytse にメールを送り、GitLab 社で働きたい旨を伝え、週に1日 Rubinius で働くスポンサーになってもらえないかと頼みました。その後の会話と面接の結果、私は2015年10月に社員番号28番として GitLab 社に入社しました。私の仕事は GitLab のパフォーマンスを向上させることで、20%の時間を Rubinius に費やすことができました。
その間、私は様々なチームの一員となり、多くの自主性を持ち、数年間で10人の異なるマネージャーに報告し、会社をほぼ消滅させ、GitLab が今日まで使用している様々な重要なコンポーネントを構築し、会社が30人ほどの従業員から2000人ほどの従業員に成長するのを見届け、そして燃え尽き症候群で終わりました。オランダのことわざでは "Lekker gewerkt, pik!" です (がんばって翻訳して) 。
2015-2017
GitLab 社に入る前の会社での最終日は9月30日の水曜日で、その翌日から GitLab 社で働き始めました。つまり、私は週5日オフィスで働くことから、週5日リモートで働くことになったのです。それまでも自宅で仕事をしたことはありましたが、主に線路に積もったわずかな雪や落ち葉のために電車が動いていないときに仕事をしていました。
特に印象に残っているのは、日中に食料品の袋を家まで持ち帰ったことで、仕事から帰ってきて夕方ではなく、日中にそれをすることがいかに素晴らしいかをを実感しました。
もうひとつの思い出は、愛猫とソファで昼寝をしたことです。
そう、それはホーマー・シンプソンのスリッパです。
当時私が借りていたアパートは広くなく、小さなキッチンスペースと小さなリビングルーム、そして同様に小さな屋根裏部屋しかありませんでした。そのため、私のリビングルームは、寝室、リビングルーム、オフィスとして機能していました。あまりいい環境とは言えなかったですが、当時の私にはそれしかありませんでした。おそらく高価なアーロンチェアが関係していたのでしょう。
フルリモートの会社であるにもかかわらず、GitLab 社は社交的な会社で、何年もの間、頻繁にミートアップやイベントが開催されていました。例えば、私が入社して数週間後にアムステルダムで会社の集まりがあり、日中は様々なアクティビティ、夜には夕食会がありました。
当時はまだ、レストランの一角に会社全体をおさめることができました。
それから間もなく、GitLab 社は最初の成長期を迎え、100人ほどの従業員が新たに加わりました (と思うけれど、現時点では少し記憶があいまいです) 。2016年にオースティンで開催された次の会社の集まりでは、レストランの一角ではもはや十分ではありませんでした。
この間、ネガティブな経験もたくさんありました。GitLab はひどいパフォーマンス、頻繁な機能停止 (ほぼ毎週どこか)、不十分な管理、その他スタートアップが直面する多くの問題に苦しんでいました。その結果、"GitLabは遅い" というのがユーザーからの不満の声の第一位となりました。特に Hacker News では、元のトピック (例えば新機能の発表) が何であろうと、人々は文句を言うのが大好きでした。もちろん GitLab 社はこのことに気づいていましたし、実際 GitLab 社が私を雇った理由の一つはこの問題を解決するためでした。
特に、GitLab 社には適切なパフォーマンス・モニタリングのインフラがなかったからです。当時稼働していた唯一のサービスは New Relic のトライアルアカウントで、当時あった (と思う) 合計15～20台のサーバーのうち1台か2台しか監視できませんでした。このため、どのようなデータであっても正確な表現ではなく、パフォーマンスの測定と解決が困難でした。
これらの問題を解決するのをさらに難しくしたのは、GitLab の要件で、私たちが使うどんなツールであれ、セルフホスティングの顧客が利用できるものでなければならず、できればオープンソースでなければならなかったことです (あるいは、これは難しい要件だったのかもしれませんが、覚えていません) 。つまり、パフォーマンスを向上させるだけでなく、そもそもパフォーマンスを向上させるためのツールを構築しなければならなかったのでした。同時に、パフォーマントなコード (あるいは少なくとも恐ろしく遅くないコード) を書くことは、会社の他のメンバーにとって優先事項とはまったく考えられていませんでした。GitLab 社はまた、社内の苦情よりも Hacker News 上の苦情に耳を傾ける傾向がありました。そのため、社内では「何かを変えて欲しければ、然るべきルートで文句を言うよりも、匿名で Hacker News に文句を言った方がうまくいく」というジョークが飛び交っていました。
その後、数ヶ月間、私はパフォーマンスを改善し、そのために必要なツールを構築し、パフォーマンスに対する会社の文化や態度を変え、時間が経てば実際に改善されるように努め、GitLab がその改善に満足しないことに対処しました。少なくとも何度か、Sytse を怒鳴りつけそうになったビデオ通話があったことをはっきりと覚えています。
このような困難にもかかわらず、私は必要なツールを構築し、様々な部分でパフォーマンスを向上させることができました (重要なものもあれば、そうでないものもあった) 。このツールは "GitLab Performance Monitoring" として知られる GitLab の公式機能になりました。私が作ったもう一つのツールは "Sherlock" で、開発環境で使うためのヘビー級のプロファイラでした。
この間、GitLab は、特にパフォーマンスが会社の他の部分にとって優先事項でない場合、一人の人間を雇うだけではこの種の問題を解決できないことに気づき始めました。その結果、Sytse に直接報告する代わりに、新しい "Performance" チームの一員として専任のマネージャーに報告することになり、そのチームにはさらに人を雇うための予算がつくことになりました。その予算は正確には覚えていませんが、2人か3人だったと思います。会社の規模や、できるだけ多くの機能を生み出すことに主眼を置いていたことを考えると、これでは到底足りなかったが、スタートにはなりました。
2年目の大半は、このチームの一員として過ごしました。より多くのリソースを求めるキャンペーンを続け、新しいコードには優れたパフォーマンスを要件としましたが、結果はまちまちで、もちろん私やチーム全体としてパフォーマンスを改善し続けました。
この間、GitLab 社は最初のレイオフの波を経験し、主に GitLab 社が最初に間違った人を雇った結果、自分の意志で人が去っていきました。その結果、GitLab 社は30数人から130数人 (だったと思う) まで成長し、80数人まで縮小し、また数ヶ月後に成長し始めました。
Rubinius について。私たちは Rubinius で GitLab を動かそうとしましたが、成功しませんでした。Rubinius のメンテナがプロジェクトを別の方向に進めようとしたことと、このことが Ruby コミュニティ内で論争を引き起こしたことも相まって、私たちは最終的に Rubinius に見切りをつけることにし、私は Rubinius での作業を完全にやめました。Rubinius は長年にわたって多くのことを実現してきたのですが、最終的には、プロジェクトを成功させるために必要なこととは異なる方法で運営するメンテナーによって抑制されてしまったのです。
2017-2018
最初の不安定な1年半の後、事態は好転し始めた。パフォーマンスは大幅に改善され、GitLab 社はより真剣に取り組み始めた。採用プロセスは大幅に改善され、チェスのゲームのように GitLab 社は適切な人材を適切な場所に配置し始めた。パフォーマンス・チームの範囲も変わりました。パフォーマンス全般に焦点を当てるのではなく、データベースのパフォーマンスに焦点を当てることになり、その一環として "データベース・チーム" というクリエイティブな名称に変更されました。この変更に伴い、人を雇うための予算も増え、新しいデータベースのセットアップなどを手伝ってくれるインフラ・エンジニアも配属されました。
この時期に私が作った決定的に重要な機能は、GitLab のデータベースロードバランサー です (ここで発表しました) 。この機能により、開発者は通常通りデータベースクエリを書き続けることができ、ロードバランサはこれらのクエリをレプリカやプライマリのどちらにも向けないようにします。書き込みを行った後、ロードバランサーは、書き込んだ変更がすべてのレプリカで利用可能になるまで、プライマリデータベースが使用されるようにする。ロードバランサーの導入はパフォーマンスに大きく良い影響を与えました。もしこのロードバランサーがなかったら、GitLab は大変なことになっていたと思います。私が最も誇りに思っているのは、このシステムを透過的に導入できたことです。これまでのところ、(Ruby on Rails はともかく) プロジェクトに追加するだけで使えるデータベースロードバランサーは見たことがありません。その代わり、既存のソリューションは、パズルのほんの一部分だけを提供するフレームワークのようなもので、自分ですべてをつなぎ合わせる必要があり、多くの場合、何のサポートもありません。スタンドアローン・ライブラリーにまで発展させることができなかったのは残念でした。
1月31日、夜遅くまで続く多くの問題に対処する長くストレスフルな一日の後、私は GitLab のパフォーマンス問題を解決しました 誤って GitLab の本番データベースを削除してしまいました 。その結果、システムが長い間機能していなかったため、バックアップがないことが判明しました。また、バックアップのエラーを通知するシステムも機能していませんでした。結局、その日に行っていた作業の一環として、6時間ほど前に本番データをステージング環境にコピーしていたため、復旧はできましたが、復旧には24時間ほどかかりました。約6時間のデータ損失はどう考えてもひどいものでしたが、もしバックアップを取っていなかったらどうなっていたかはわかりません。その日、私の心臓は数拍飛び、白髪が数本増えたことは間違いない。
この間、何度も苛立ちの種になったのは、データベースのロードバランサーを導入した後も、GitLab がデータベースをシャード化したがることでした。私や他のエンジニアや上司は、これが問題に対する間違った解決策だと考えていただけでなく、それを裏付けるデータも持っていました。例えば、シャーディングは書き込みが読み込みを大きく上回る場合に有効ですが、GitLab の場合は読み込みが書き込みを 10:1 の割合で上回っていました。さらに、私たちが保存していたデータ量は、シャーディングを導入する複雑さを正当化できるほどではありませんでした。私たちが雇ったコンサルタントが、"悪気はないのですが、私たちには数桁多い負荷とストレージを持つ顧客がおり、彼らにとってもシャーディングはやり過ぎです" というようなことを言っていたのをはっきりと覚えています。にもかかわらず、GitLab は何年もシャーディングを推し進め続け、経営陣がシャーディングを放置する決断をするまでになりました。
2019-2021
2018年から2019年にかけてのある時期、私はこの4年間、パフォーマンスと信頼性に取り組むことに疲れてしまったため、データベースチームから新しく設立された「デリバリー」チームに移動しました。さらに、複数の人間がパフォーマンスと信頼性に取り組むようになったので、私にとっては新しいことに移る適切な時期だと感じました。この新しいチームの目標は、GitLab のリリースプロセスとツールの改善でした。
例えば、私たちはメインブランチにコミットしてから GitLab.com にデプロイするまでの時間を調べました。その結果、平均して数日かかるが、ひどい場合は3週間かかるというデータが出ました。ここでの主なボトルネックは、GitLab Community Edition と GitLab Enterprise Edition が別々の Git リポジトリとして存在し、定期的に手作業によるマージと競合解決が必要だったことです。そのため、 2つのプロジェクトを1つにマージする のに数ヶ月を要しました。私たちは作業をフロントエンドとバックエンドに分け、様々なチームがそれぞれの分担を分担して貢献するようにしましたが、結局私はバックエンド関連の変更のほとんどを実装し、別の同僚がフロントエンド作業のほとんどを担当しました。
チームの他のメンバーとともに、この期間にリリースプロセスを大幅に改善し、数時間で変更をデプロイできるまでになりました。これは本来あるべきスピードにはほど遠いものの、最悪の場合3週間かかっていたものが、最悪の場合1日程度で済むようになったのは大きな進歩でした。
これまでの期間と同様、この期間も混乱や変化がなかったわけではありません。
2018年は従業員に焦点を当てた GitLab サミットを開催した最後の年であり、2019年以降はより伝統的なカンファレンスのような形式で、より顧客向け、より従業員向けではないものになりました。2000人以上の集まりを開催するのはとてつもなくお金がかかるので、財政的な観点からすればこれは理解できることでした。社交的な観点からは、サミットがより企業的な設定になったことで、以前の形式ほど楽しくなくなったことは損失でした。コンテストで優勝したチームに対して Sytse がステージでダンスを披露したり 、Sytse がキリンの着ぐるみを着て Sytse 夫妻がフィットネス教室を開いたりしたのはいい思い出です。このようなおふざけイベントは、その後の数年間は起こらなくなりました。
ラップトップの管理の問題もありました。会社の Mac ラップトップを要求され、それをどう使うかは多かれ少なかれ自由でした。何年もかけて、GitLab 社の経営陣はラップトップをリモートで管理できるソフトウェアを使おうという議論を始めました。これらの議論で繰り返し問題になったのは、提案されたツールが侵略的で (例えば、ユーザーの行動を記録するために使われる可能性がある) 、悪用に対する保証がなく、主要な社員が経営陣に圧力をかけ始めるまで、社員からのフィードバック (たくさんあった) が無視されるということでした。そして計画は棚上げされ、数カ月後にまた議論がやり直されました。
最も際立っていたのは、提案された変更点ではなく、むしろ経営陣のフィードバックの扱い方であり、変更点全般が、その存在を正当化するために問題を解決しようとしているような雰囲気を醸し出していたことだった。この議論に参加したほとんどの人たち (私も含めて) は、(盗難対策など) 何らかの形でラップトップを管理する必要性を理解していましたが、提案された侵略的な解決策は行き過ぎだと感じていました。
GitLab 社は SentinelOne を使ったラップトップ管理ソリューションに落ち着きました。GitLab 社は、個人のハードウェアを含め、GitLab 社のリソースにアクセスするために使用するハードウェアにこのソフトウェアをインストールすることを従業員に義務付けていました (あるいは、少なくとも義務付けることを検討していました) が、私 (自分のデスクトップ・コンピューターを使っていました) はどういうわけかレーダーを潜り抜け、問題のソフトウェアのインストールを求められることはありませんでした。おそらく、会社支給のノートパソコンを使っていなかったために GitLab 社が私をチェックするのを忘れてしまったのでしょう。
このような文化的な変化と私生活の様々な変化が重なり、モチベーションや生産性が低下し、ストレスが増大し、労働時間が安定しなくなりました。チームのマネージャー (今までで最高のマネージャーだと思う) も別の役割に移り、今は新しく雇われたマネージャーがチームを率いています。私はこのマネージャーと折り合いが悪く、その結果、「業績改善計画」(PIP) が必要になる前に、物事を軌道に乗せるための手順である「業績向上計画」を立てることになりました。PIP は、従業員と仕事、そして雇用主との関係を改善するための最後の試みとして使われるものだ。
私は改善すべき点があることを認めましたが、問題の一端は新しいマネージャーの働き方にあると感じました。経営陣は、PEP は両者の状態を改善することを意味している、つまり私だけに焦点を当てるのではなく、マネージャーにも焦点を当てるのだと保証してくれました。それは実現せず、PEP は私が違うことをする必要があることだけに焦点を当てました。PEP はまた、どのような要件を満たさなければならないかについても少し曖昧でした。当初の計画では PEP は1カ月でしたが、最初の1カ月が終わるころ、上司は PEP をもう1カ月延長することを決めました。そして2ヵ月後、私は PEP を完了し、経営陣はその結果を満足のいくものだと判断した。
私の中の楽観主義者は、私が PEP を実施した最初の従業員であったため、経営陣が状況を把握しながら進めていったのだと信じたいです。私の中の悲観主義者は、この一連の出来事に対してはるかに否定的な意見を持っていますが、それは自分の胸にしまっておきます。
この経験の後、GitLab 社も私も違う方向に向かっていて、当時の状況に満足していなかったので、もしかしたら辞める時が来たのかもしれないと思いました。
そのチャンスは2021年の終わりに訪れました。GitLab 社が上場することになり、ストックオプションを行使できるようになるまでの期間を考慮すると、2021年12月に退職できることになりました。ストックオプションを行使すると、行使手数料と評価額との差額に対して、たとえ株式が流動的でなくても、所得税 (52％) を全額支払わなければならないからです。私の場合、税金が高すぎて払えなかったので、GitLab 社が上場するまで待つことを余儀なくされました。数ヶ月後、法律が変わり、税金を行使時に支払うか、株式が流動化した時に支払うかを選択できるようになりました。注意点は、株式が流動化するまで税金を先延ばしにした場合、ストック・オプションを行使した時点の価値ではなく、その時点の価値に基づいて税金を支払うということです。これは確かに理想的ではなく、財務上のリスクも大きいが、少なくとも選択肢はありました。
こうして株式を取得した私は、2021年12月に退職し、貯蓄を切り崩しながら Inko でフルタイムで働くことになりました。
学んだこと
歴史はさておき、私が GitLab 社で学んだことをいくつか見てみましょう。一つ心に留めておいてほしいのは、これらの知見は私の個人的な経験に基づくものであり、そのため、私が間違っている部分がある可能性は低くないということです。
スケーラビリティは企業文化とする必要がある
GitLab 社が犯した過ち、そして私が退職した後も犯し続けた過ちは、スケーラビリティを十分に気にしなかったことです。確かに、役員たちはスケーラビリティは重要だと言うでしょうし、改善もされてはきたけれど、他の目標ほど優先されることはありませんでした。この問題の核心は、GitLab 社のお金を稼ぐ方法にあります。GitLab 社は主に、GitLab.com ではなく、GitLab Enterprise Edition をセルフホストしている顧客からお金を得ています。 このため、当然ながらセルフホスティングの市場に焦点を当てることになり、GitLab.com で遭遇したパフォーマンスの問題の多くは、多くのセルフホスティングの顧客には当てはまりませんでした。
さらにイライラさせられたのは、多くの開発者が実際にはパフォーマンス向上を望んでいたにもかかわらず、そのための時間とリソースを与えられていなかったことです。
チームをよりデータ主導且つ、開発者主導にする
もう一つの要因は、GitLab のプロダクトマネージャー主導の性質です。主要な開発者の中には、プロダクトの決定に影響を与える能力を持っていた人もいたかもしれませんが (十分に叫んだり蹴ったりすれば)、何を実装すべきかを決めるのは主にプロダクトマネージャーやディレクターでした。これらの決定がとても理にかなったものであることもあれば、「Hacker News で読んだこれは良いアイデアだから作らなければならない」というだけのものであることもありました。
GitLab 社は、今日のような伝統的な多層階層ではなく、もっとシンプルな階層を早い段階から採用していれば、会社としてもっと良いパフォーマンスを発揮できたと思います。特に、プロダクトマネージャーという考え方はやめて、チームリーダーにもっと権限を与えて、ユーザーともっと交流させるべきだと思います。技術的なレベルで製品作りを支援するだけでなく、チームとユーザーとの連絡役としても機能します。
データがなければ、何が「最小限の実行可能」なのか判断できない
GitLab 社の基本原則の一つは、常に「実行可能な最小限の変更」から始めることです。これは、ユーザーに価値をもたらす可能な限り小さな作業単位を提供するという考え方です。机上では素晴らしいことに聞こえますが、実際には「最小」の定義は人によって一貫していません。その結果、あるチームではパフォーマンスや使い勝手の良さを実行可能な要件と考えるかもしれませんし、別のチームではそんなことはどうでもいいということになります。
誰も求めなかったサーバーレスプラットフォームは最終的に廃止され、Kubernetes クラスターを管理するためのサポートは誰にも気づかれることなく3週間も機能しなかったり、既存のソリューションを使う代わりに CI サービスの上に chatops ソリューションを構築しなければならなかったり (その結果、大幅なレイテンシが発生した)、データの作成と閲覧しかサポートしない要件管理機能 (更新や削除さえもサポートしなかった)、これらはここ数年のほんの一例です。
何が実現可能なのかを判断するには、ターゲットとするユーザーの要望を深く理解する必要があります。GitLab 社では四半期ごとにユーザー調査 を行っており、ユーザー・エンゲージメントに関するデータにアクセスできるチームもありますが、私が覚えている限り、また他の元同僚と話して学んだ限りでは、このデータは各チームのワークフローの中核部分ではなく、付随的に使われているようでした。
SaaS とセルフホスティングは相性が悪い
GitLab 社は、セルフホストインストールと SaaS (Software as a Service) の2種類の製品を提供しています。GitLab 社を含め、ほとんどの企業はこのようなセットアップを効果的に提供することはできないと思います。何が一番儲かるかという利害の対立が生じるだけでなく (前述の通り)、2種類のセットアップには異なる要件やアップデートの適用方法があります。
例えば、SaaS の場合、迅速にデプロイでき、一元化されたインフラ上で大量のデータとワークロードを処理する必要があります。ほとんどのセルフホストインスタンスは、SaaS の提供するものに比べて小さい傾向があるため、SaaS として遭遇する問題やそれに対応するソリューションの多くは、セルフホストインストレーションには適用されません。このため、プラットフォームの多くの部分で、SaaS 版とセルフホスト版の2つのコードパスが存在することになります。コードが物理的に同じであったとしても (つまり、セルフホスト型インストレーション用に使いやすいラッパーを提供する場合)、その違いについて考える必要があります。
対照的に、SaaS またはセルフホスティングのセットアップのどちらかに集中する場合、そのセットアップにとって最高のエクスペリエンスを提供することに全神経を集中させることができます。もちろん例外はありますが、それはまさに例外であり、例外はまれです。
人数が多ければ成果が上がるわけではない
GitLab 社は、それ以前の多くの企業と同様、何年にもわたって多くの人を雇用し、現在では2000人以上の従業員を抱えています。そのうちの何人が現在の開発者なのかは知りませんが、チーム・ページをざっと見た感じでは少なくとも数百人でしょう。
プロジェクトに人を増やしても、必ずしも生産性や成果が向上するわけではないことはよく知られています (「人月の神話」も参照) 。しかし、ベンチャーキャピタルを持つ欧米のスタートアップはほとんどすべてこのことを無視しているようで、製品にそれほど多くの開発者が必要でなくても、何百人もの開発者を雇っています。
これを裏付けるデータはありませんが、ほとんどの企業は20人以上の開発者を必要とせず、20人から50人、50人から100人の開発者を必要とする企業はほんの一握りではないでしょうか。開発者が100人を超えたら、さらに人を雇う前に、製品の範囲が手に負えなくなっていないかどうか考え始める必要があると思います。
なお、ここでは特にソフトウェア開発者について話しています。例えば、カスタムメイドのハードウェアを製造しているのであれば、製造工程を拡大するためにもっと多くの人が必要になるでしょう。営業とサポートは、一般的に人数が多い方が有利な2つの分野です。
Ruby on Rails の使用について葛藤している
GitLab は Ruby と Ruby on Rails を使って構築されており、これが今日の成功をもたらした大きな要因です。同時に、この組み合わせは、プロジェクトが大規模になり、経験レベルの異なる多くの貢献者が参加するようになると課題をもたらします。特に Rails では、うまく動作しないコードを導入するのが簡単過ぎます。
たとえば、プロジェクトメンバーの数を示すカウンタとともにプロジェクトのリストを表示したい場合、N+1 クエリの問題 を誤って導入するのはあまりにも簡単です。Rails (より具体的にはActiveRecord) はこの問題を解決する機能を提供していますが、これはオプトインの仕組みであるため、開発者がこの問題を忘れてしまうことは避けられません。私が GitLab 社にいた最初の数年間に解決したパフォーマンス問題の多くは、N+1 クエリの問題でした。
他のフレームワークは何年もかけてこの問題から学び、よりよい代替案を提供してきました。通常のアプローチは、関連するデータを任意にクエリできる代わりに、前もってデータを渡しておくというものです。この利点は、もしデータの受け渡しを忘れても、コードが行ごとにデータを照会してパフォーマンスの問題を引き起こすのではなく、何らかのエラーに遭遇することです。
また、Ruby 自体にも賛否両論があります。一方では、10年弱の間楽しく使ってきた素晴らしい言語です。一方では、メタプログラミングを多用するため、オプショナル型付けが導入されたとはいえ、大規模なプロジェクトで使うのは難しいです。私は数年前に Ruby の静的解析ツール を書いたときに、それを身をもって体験しました。
にもかかわらず、Ruby と Ruby on Rails の組み合わせの代わりに、どのような選択肢を勧められるかわかりません。Go、Rust、Node.js といった言語は Ruby よりも効率的かもしれませんが、Ruby on Rails ほど有能なフレームワークはない。Python や Django も選択肢に入るかもしれませんが、少なくともある程度は Ruby や Ruby on Rails と同じような問題にぶつかるのではないでしょうか。新しいウェブフレームワークが、ルーティングツリーをどう定義するかにこだわるのをやめて、代わりに全体としての生産性をもっと重視するようになれば、おそらく役に立つでしょう。
Inko でこの問題にどうアプローチするか、漠然としたアイデアはあるのですが、Inko でウェブ・フレームワークを書き始める前にやらなければならないことが他にもたくさんあります。
コードのデプロイにかかる時間は、組織の成功に欠かせない
これは GitLab 社に入社する前からわかっていたことで、前職では優れたデプロイとテストのパイプラインの構築にかなりの時間を費やしてきました。GitLab 社では、それに近づくまでに4年ほどかかりました。
(デプロイに何時間もかかることを考慮してコードをホットパッチする必要がない) より効率的にインシデントに対応できるといった明らかな利点のほかに、モチベーションを上げる利点もあります。変更に何週間も費やし、それがデプロイされるまでにさらに2週間かかることほど、やる気を失わせることはありません。
これがうまくいくためには、デプロイにかかる時間や、デプロイの一部としてテストスイートを実行する時間を、驚くほど積極的に削減する必要がある。アプリケーションの種類やテストするサービスの種類によっては、テストの実行にある程度の時間が必要な場合もあります。ここで重要なのは、「テストとデプロイにX分以上かかってはならない」ということではなく、(組織として) ビジネス要件が許す限り、デプロイを高速に行えるようにすることを優先することです。当たり前のことのように思えるかもしれないが、多くの組織はこの分野で、できる限り良い仕事をしていないのではないでしょうか。
場所ベースの給与は差別的だ
GitLab 社であなたが得る給料は様々な変数に影響されますが、その一つが勤務地です。勤務地の影響も取るに足らないものではありません。物理的なオフィスがある会社で、特定の地域で人を雇う必要がある場合、そうでなければ必要な地域で必要な人を雇うことができないかもしれないので、場所によって給与を調整することは理にかなっているかもしれません。しかし、物理的なオフィスを持たず、全世界に法人を持つフルリモートの会社にとって、同じ経験と責任を持つ2人の異なる人材に、純粋に住んでいる場所によって異なる給与を支払う正当な理由はありません。
例えるなら、私が GitLab 社を辞めた時の給料は税引き前で年間約12万ユーロ、月に約8500ユーロでした。オランダではこの給料は良い方で、これより良い給料でフルタイム在宅勤務ができる会社を見つけるのは難しいでしょう。しかし、もし私がベイエリアに住んでいたら、少なくともその2倍、場合によってはそれ以上の収入を得ていたでしょう。ベイエリアの方が仕事ができるからとか、そういう正当な理由ではなく、オランダではなくベイエリアに住んでいたからです。
どう言い繕ったところで、住んでいる場所によって賃金を決めるのは、どう考えても差別行為である。考えてみてください。肌の色や性別を理由に給与を低くしたら、会社は大問題になるでしょう。しかし、住んでいる場所によって賃金が低くなるのは問題ないのでしょうか？
これを解決する方法としては、企業にとっては簡単です。応募者の所在地ではなく、ポジションの要件に基づいて給与を支払えばいいのです。ベイエリアにいる人に年間10万ドル払おうが、フィリピンにいる人に払おうが、企業としてのコストは同じだからです。従業員に対する私の唯一のアドバイスは、より良い給与を交渉してみることですが、場所によって給与を支払う企業も頑固な傾向があるので、これは難しいかもしれません。いつか法律がこの慣習に追いつくことを願っています。
このやり方がうまくいっていると思われる会社に、0xide Computer Company があります。0xide は従業員に勤務地に応じて給与を支払う代わりに、同額を支払っています(詳しくは こちらの記事 を参照) 。
結論
振り返ってみると、GitLab 社で過ごした時間は信じられないほどポジティブな経験とネガティブな経験の両方が混在しています。私が所属していた様々なチームが成し遂げてきた成果や、一緒に働くことができた人たちを信じられないほど誇りに思っていますが、素晴らしい経験を台無しにしてしまったここ1年ほどのことを悲しくも思っています。GitLab 社で働いたことに後悔はありませんし、できることならもう一度やり直したいと思っています。欠点はあるにせよ、他の多くの会社よりもずっと良い会社だと思うからです。
(翻訳) ストーリーポイント再考
本稿は Ron Jeffries 氏によって書かれた次の記事の日本語翻訳です。著者に翻訳の許可を得て公開しています。
また本稿は DeepL Pro を使って下訳したものに手を加えています。日本語翻訳の不具合または誤訳については Ron Jeffries 氏ではなく、本稿のコメント欄にお願いします。
ここから本文です。
ストーリーポイント再考
私はストーリーポイントを発明したかもしれない。もしそうだったとしたら、いまは申し訳なかったと言いたい。ストーリーポイントに関する私の現在の考えを探ってみよう。少なくとも何人かは私の考えに興味をもっているでしょう。
もちろん、ストーリーは XP のアイディアであり、スクラムのアイディアではありません。どういうわけか、スクラムの実践者はこのアイディアを採用しています。公式のスクラムガイドではバックログアイテムに言及しているにもかかわらず、バックログアイテムをユーザーストーリーにすることは一般的なスクラムのプラクティスです。
少なくとも限られた範囲では正しいでしょう。ストーリーの一般的な使い方については別のところで書きました。ここでは「ストーリーポイント」について説明します。XP では、ストーリーはもともと時間で見積もられていました。そのストーリーを実行するのにかかる時間です。私たちはすぐに「理想的な日数 (Ideal Days)」と呼ぶことにしました。私たちは理想的な日数に「負荷係数」をかけて、実際の実装時間に換算しました。この負荷係数はだいたい3になる傾向がありました。つまり、理想的な日数分の仕事をこなすのに実質3日かかるということです。
私たちは、見積もりを日単位で話し、通常は「理想的な」という言葉を省略して使っていました。その結果、ステークホルダーは、1日の仕事を終わらせるのにどうして3日もかかるのか、あるいは逆の視点から目を向けて、なぜ3週間で50「日」の仕事ができなかったのか、と混乱することが多くなりました。そこで確か、私たちは「理想的な日数」を単に「ポイント」と呼ぶようにしました。つまり、1つのストーリーを3ポイントで見積もると、完了までに約9日かかるということです。ポイントというのは、あるイテレーションに要する作業量を決めるのに使うだけだったので、20ポイントくらいと言えば誰も反対はしませんでした。
私が名前を変える提案をしたかもしれません。もしそうだったとしたら、いまは申し訳なく思っています。この話題に関する私の現在の考えを、同僚の Simon に宛てたメールから紹介しましょう。
あなたは (ストーリーポイントを) 発明したことを本当に後悔していますか？それとも相対的なサイズを正しく理解していない場合に誤用されることを嘆いているだけですか？
私は次のように返答しました。
- 確かにその誤用は嘆かわしい
- 「いつ完了するか」を予測するために使うのは、せいぜい弱い考えだと思う
- 実績が見積もりと比較してどうなのかを追跡するのは、せいぜい無駄だと思う
- 見積もりやベロシティの質でチームを比較するのは有害だと思う
もう少し深く考えてみましょう。
「アジャイル」のアプローチの中には、計画を立てやすくするために、チーム間でストーリーポイントを正規化することを推奨しているものがあります。これは表面的には十分に理にかなっているように見えますが、チーム同士を比較するという罠にはまりやすく、実際に組織がそうしてしまうことがあまりにも多いです。
比較
まず第一に、たとえ「同じように見える」としても、それぞれのチームにはそれぞれのスキルがあり、それぞれの環境で仕事をしています。だから、同じように見える2つのストーリーを見て、一方のチームが2ポイントだと言い、もう一方のチームが6ポイントだと言ったとしても、それはあまり面白くないし、チームを比較するのに役立つ方法ではないことは確かなことです。
そのような状況を目の当たりにしたあなたや私は、好奇心を持ってその状況に臨むでしょう。まず比較できるほどその状況が似ているかどうかを確認し、次に高い見積もりを出したチームに、私たちが提供できる何らかの手助けが必要かどうかを探ります。それ自体はいいことです。暗に、あるいは明示的に「遅い」チームが劣っているとか、何かしくじっているとかを結論づけることは、非常に悪いことなのに、残念ながらよくあることです。
2つのチームが何かを生み出しているとき、多くのマネージャーにとって、それらを比較することは抗いがたい誘惑だと思います。これはストーリーポイントという概念を捨て去るほどの抗いがたい誘惑だと私は思います。そして、可能であればストーリーを見積もるという概念さえも捨て去るでしょう。より少ない見積もりで仕事をする方法については、また別の記事で触れる ことにしましょう。
追跡
多くのマネジャーにとって、見積りの存在は「実績」の存在を意味します。見積りと実績を比較し、見積りと実績が一致することを確認することを意味します。もし一致しない場合は、もっとうまく見積もることを学ぶべきだと意味します。
私にとって、リアルアジャイル (Real Agile) で重要なことは、次にやるべきことをいくつか選び、それを迅速に実行することです。重要な問題は、最も価値のあることを見つけ、それを素早く実行することです。それらを迅速に行うには、価値の高いものを小さく切り出し、迅速に反復 (イテレート) することに尽きます。ストーリーのコスト見積もりは、あまりその役には立ちません。
見積もりの存在によって経営陣が価値のボールから目を離し、代わりに見積もりを改善することに集中するようになると、真の価値を迅速に提供するという中心的な目的から注意がそれてしまいます。
このことから、ポイントであれ時間であれ、見積もりは避けるべきだと私は考えています。
プレッシャー
見積もりと実績の問題に関連するのは、「もっと」という経営陣の自然なプレッシャーです。チームがどんなに成果を上げていても、それだけでは十分ではありません。もっと、もっと、もっと。
価値を提供する最善の方法は、もっと、もっと、もっと、ではなく、小さな価値のあることを頻繁に行うことです。ストーリーを見積もるのではなく、「十分に小さいもの」に切り詰めれば、常に価値を提供しながら、スムーズな流れができます。
より多くのことに集中することは、価値を高める邪魔になります。チームはより速く進めようとして、コードの品質やテストに手を抜くことになります。やがて、より多くの不具合をリリースするようになり、不具合を修正するための再作業が増えるためにスピードが落ち、コード品質が急速に低下するためにさらにスピードが落ちます。事態はますます悪化し、プレッシャーは増大し、間をおかず惨事へと至ります。
見積もりは少なくとも不当なプレッシャーの適用に関与しているので、私は見積もりを避けたいのです。
さらに言いましょう。イテレーションやスプリントのプランニングは完全に止めた方がよいでしょう。次の数週間の予算を埋めるために仕事をするのではなく、次にすべきいくつかの最も重要なことのリストを持つために仕事をするのです。
完了の予測
必要不可欠な機能のリストを作り、それについてしばらく考え、次のリリースを決定するのは一般的なやり方です。次の質問は、もちろん、「いつまでにすべて完了するのか？」です。
答えは誰にもわからない、です。私たちは、わからないことを改善するために多くの仕事をできますし、入札を待っている大きな契約があるときなど、ある分野やある時期においては、それを行う価値はあります。しかし、社内外の顧客のためにソリューションを開発するビジネスをしている場合、私たちは頻繁に少量の価値を提供するのがベストであり、いつまでも未来に先送りするようなビッグバン的なリリースを待つべきではありません。
顧客に対する次のリリースの近い日を選び、そのリリースにできるだけ多くの良いものを詰め込む方がはるかに良いのです。ストーリーポイントであれ、グミベアであれ、あるいは時間であれ、見積もりは素早いリリースの邪魔をします。可能な限り、見積もりを避けるのがベストだと私は思います。
スライス
では、ストーリーの見積もりが嫌いなら、何が好きなのかという疑問が湧いてくるでしょう。私はストーリーのスライシングが好きです。これは、大きなストーリーを小さなストーリーにスライスすることであり、それぞれのストーリーは可能な限り高い価値を持ちますが、それを完成させるのに必要な時間はごくわずかです。理想的には1日以内、ほんの2、3時間です。
ここでは、スライスする際に何らかの見積もりが必要なのかどうかについて、あなたと屁理屈をこねるつもりはありません。もしあなたやあなたのチームが、頭の中で見積もりをして誰にも言わないのであれば、見積もりに関する問題は、それがストーリーポイントであれ時間であれ、発生しそうにはありません。そして「たぶん十分小さい」と「たぶん十分小さくない」の違いを知ることは、「3日」と「1日」の違いを知ることと同じではありません。
さらにコツがあります。私は 小さなストーリーを手に入れる と スライス、見積もり、トリミング でそのことを紹介しました。Neil Killick から学んだことです。「1回の受け入れテストが必要になるまでストーリーをスライスしてください。少し練習すれば、適切なサイズにできます。」
もちろん、見積もりに関する他の記事もあります。ページの一番上にあるリンクをクリックすれば、これまで知りたかったこと以上のことが書かれています。
未来の予測
しかし … 製品リリースにかかる時間を知る正当な必要性があり、そのために見積もりは必要ではないのでしょうか？そうかもしれませんが、ストーリーの見積もりは必要ないでしょう。おそらく、ストーリーレベルまで要件を落とし込むことはないでしょうし、もしあったとしても、それはあまりにも膨大でほとんどが無駄になってしまうでしょう。
もちろん、やらなければならないのであれば、やればいいです。私ならこうする、あるいはこうすべきだという私の理論は、単なるアイデアに過ぎません。最終的には、自分たちの状況で成功するために必要なことは何でもやるしかありません。しかし、私にはもっとよいと思うことがあります。
最初に、次のリリースのために重要な機能を1つ、あるいはいくつか考えます。それが解決する問題は何か、それを解決するのに役立ちそうなソフトウェアは何かについて話し合います。少しでも助けになりそうな最もシンプルな機能について話し合います。すべてを解決する必要はありません。多くの場合、ちょっとした手助けができれば、それでモノゴトが動き出すのに十分なのです。
2番目に、期限を決めましょう。それまでに良いものを作れそうだと思えるような期限を考えましょう。期限を決めて仕事に取りかかります。
3番目に、重要な機能をスライスして実装します。かなり簡単に1日以内にできるはずです。次の最も重要な部分だけに取り組みます。最初の機能を、ほんのわずかなフリルまで埋め尽くそうとしてはいけません。「このちょっとしたことを1つだけやれば、顧客であるジャックはこれを実際に使うことができる」と考えるような心境になるようにします。そして、そのちょっとしたことをやってジャックに試してもらいます。私たちは価値の継続的提供にできるだけ早く移行したいのです。
私たちがやっていることの価値を目に見えるものにし、プロダクトオーナーや他のステークホルダーが、それを世に出すのを待ちきれなくなるようにしたいのです。そうすれば … ストーリーの見積もりの有無にかかわらず、私たちは正しいことをしていることになります。
まとめ
まぁ、もし私がストーリーポイントを発明したのだとしたら、いまとなっては少し後悔しているでしょう。ストーリーポイントは頻繁に誤用され、ストーリー見積もりをまったく使わないことで多くの落とし穴を避けることができると私は考えています。もし、あなたのチームや会社に大きな価値をもたらしていないのであれば、無駄であるという理由でやめることをお勧めします。一方、どうしてもストーリーの見積もりが好きなら、そのまま続けてほしい！
リファレンス
本稿の翻訳ではなく、要約と紹介者の所感を述べた記事もあったので参考に紹介します。
過去に私が見積もりについて考えた記事です。
ストーリーポイントの誤用について書かれた記事の翻訳です。
(翻訳) ビッグテックのプロジェクトマネジメントとスクラム不在の謎
本稿は Gergely Orosz 氏によって書かれた次の記事の日本語翻訳です。著者に翻訳の許可を得て公開しています。
また本稿は DeepL Pro を使って下訳したものに手を加えています。日本語翻訳の不具合または誤訳については Gergely Orosz 氏ではなく、本稿のコメント欄にお願いします。
著者も機械翻訳を下地にしたやり方に関心をもたれたようです。
The article translated to Japanese: https://t.co/4uynyyhm4E
— Gergely Orosz (@GergelyOrosz) 2023年9月3日
The author was transparent and noted that the article is a modification of an ML-translated article.
This person managed to translate the article in maybe an hour, from me replying with "sure thing."
ここから本文です。
ビッグテックのプロジェクトマネジメントとスクラム不在の謎
プロジェクトマネジメントは、多くの人が強い意見を持っているテーマであり、私も例外ではありません。さまざまな企業がエンジニアリングプロジェクトをどのようにマネジメントしているのかという質問に答えるため、私は業界全体に協力を仰ぎました。本稿では次の内容を取り上げます。
- 業界全体のプロジェクトマネジメントのアプローチ。 100社以上が参加した調査の概要と重要なポイント
- ビッグテックにおけるプロジェクトマネジメント。 どのように行われているのか？ビッグテックの組織体制は、プロジェクトの遂行方法にどのような影響を与えているのか？
- ビッグテックにおけるスクラムの欠如。 なぜこの有名なフレームワークがビッグテックのほとんどで行われていないのか？
- あなたのチームではどのようにプロジェクトを進めるべきか？ 私の個人的な見解をお伝えしましょう
その前に、プロジェクトマネジメントのアプローチがいかに重要であるかを説明するのが難しい理由についての個人的な話をしましょう。
この記事は The Pragmatic Engineer Newsletter に掲載されたものです。このニュースレターは、とくに高成長スタートアップや大手テック企業のエンジニアリングマネージャーやシニア以上のエンジニアに関連するものです。このような記事を毎週お届けしますので 購読してください 。
Skype、スクラム、そして大切なことの再認識
私が Skype 社に入社した2012年、Skype 社はスクラムを全面的に取り組んでいました。すべてのエンジニアとプロダクト担当者は、アジャイルマニフェストの創始者の一人がファシリテートする最高クラスのスクラムトレーニングに参加させられました。Skype 社はスクラムを全面的に取り組み、数四半期をかけてすべてのチームをこの手法に移行させました。
そしてスクラムへの移行は Skype 社では成功とみなされました。Skype 社では、主要な Windows アプリの出荷がせいぜい四半期に1回だったのが、毎月出荷するようになりました。ほとんどのチームは 2～4 週間ごとになにかを納品していました。チームはスクラムマスターの役割を交代し、アジャイルコーチがチームへのフィードバックに訪れ、Skype 社を買収したばかりの Microsoft 社は、デリバリーの速度向上からインスピレーションを得ることに関心をもちました。
しかし、Skype 社がスクラムに移行する一方で、競合他社は冷酷に遂行していました。Whatsapp 社のことです。Whatsapp 社はずっと小さな組織でしたが、毎月のように市場シェアを削り、主要なコミュニケーションプラットフォームとなりました。
Skype 社とは異なり、Whatsapp 社はスクラムのようなフレームワークには手を出しませんでした。初期の従業員は、この言葉を口にしたことすらなく、重厚なプロセスを意図的に無視したことを話しています。Whatsapp 社は Skype 社を凌駕し、Skype 社よりも信頼性の高いメッセージング体験を構築し、最終的にメッセージングコミュニケーションアプリの戦いに勝利しました。
会社の成功とプロジェクトマネジメントのアプローチは必ずしも相関関係があるわけではなく、この話はそれを思い起こさせます。プロジェクトの進め方が重要ではないと言っているわけではありません。しかし、集中力、リーダーシップのアプローチ、プロセスがなくても人々がどのように働くかなど、成果にもっと大きな影響を与えるかもしれないものは他にもあります。
プロジェクトマネジメントは、複雑で変化し続けるパズルのピースです。しかし、プロジェクトマネジメントは最終目標ではなく、その目標に対してより早く到達する手段や要因に過ぎません。
業界におけるプロジェクトマネジメント手法
企業はどのようにプロジェクトを運営しているのか？私はアンケートを実施して100人以上の回答を得ました。結果は興味深いものでした。
企業がどのようにプロジェクトを管理しているかの結論は「場合による」というものでした。 これはあまり驚くべきことではありません。5人で設立されたばかりのスタートアップと、1,000 人でゆっくりと成長している非技術系の企業では、成功の見方は異なるのでしょう。非技術系の大企業のグループ内でも、斬新なアプローチを試すところもあれば、何年もうまくいっている同じやり方に固執するところもあります。
| "標準" の方法論はあるか？ | もっとも一般的なプロジェクトマネジメント方法論 (順番に) | 通常エンジニアリングプロジェクトのリーダーは誰か？ |
|---|---|---|
| ビッグテック & 公開会社のテック企業 | ||
| - チームが働き方を選択できる (通常) - 推奨された方法論はあるが、チームが選択できる (頻度は低い) |
1. プランニング → ビルド (イテレート) → リリース 2. "正式な" 方法論はない |
- テックリード - そのチームのエンジニア |
| ベンチャー資金によるスケールアップ企業 (シリーズ B 以上) | ||
| - 推奨された方法論はあるが、チームが選択できる (通常) - チームが特定の方法論に従うことが期待される (頻度は低い) |
1. プランニング → ビルド (イテレート) → リリース 2. "正式な" 方法論はない 3. カンバン 4. スクラム |
- テックリード - そのチームのエンジニア |
ベンチャー資金によるスタートアップ (シリーズ A まで) |
| - チームが特定の方法論に従うことが期待される (通常) - 推奨された方法論はあるが、チームが選択できる (頻度は低い) |
1. プランニング → ビルド (イテレート) → リリース 2. スクラム 3. カンバン |
- テックリード - 専任プロジェクトマネージャー - そのチームのエンジニア |
非ベンチャー資金調達型テック企業 |
| - チームが特定の方法論に従うことが期待される (大半) - 推奨された方法論はあるが、チームが選択できる (稀) |
1. スクラム 2. その他 (カンバン、SAFe、Scaled Agile) |
- テックリード - 専任プロジェクトマネージャー - そのチームのエンジニア |
非技術系の大企業 |
| - チームが特定の方法論に従うことが期待される (大半) - 推奨された方法論はあるが、チームが選択できる (頻度は低い) |
1. スクラム 2. SAFe 3. その他 (プランニング → ビルド → リリース、カンバン) |
さまざまである。 - 専任プロジェクトマネージャー スクラムマスター プロダクトマネージャー／オーナー テックリード |
コンサルタント企業 |
| - チームが特定の方法論に従うことが期待される (大半) - 推奨された方法論はあるが、チームが選択できる (稀) |
1. スクラム 2. "正式な" 方法論はない |
- 専任プロジェクトマネージャー |
私はこれらのカテゴリーに基づいて企業を分別しました。
- 公開会社のテック企業: テクノロジーを中核とする公開会社。これらの企業の多くは、以前はベンチャー資金を受けていた
- ベンチャー資金によるスケールアップ企業: シリーズ B 以上の資金調達を受けたスタートアップ。これらの企業は通常、少なくとも3億ドルの評価を受けており、積極的に成長しており、数年後のIPOを視野に入れていることが多い
- ベンチャー資金によるスタートアップ: プレシード、シード、シリーズ A の資金調達を行うスタートアップ。これらは一般的にビジネスモデルがあまり実証されていない成長企業である
- 非ベンチャー資金調達型テック企業: ベンチャー資金を調達しておらず、株式公開もしていない老舗テック企業。これらの企業は、ベンチャー資金を得た企業よりも積極的な成長目標を持っていないことが多い
- 非技術系の大企業: 技術を中核機能としない上場／非上場企業
- コンサルタント会社: 開発サービスを提供する会社
今回の調査で各社が使用した 方法論 は次になります。
- "正式な" 方法論がない: 公開企業やベンチャー企業に多い
- プランニング、ビルド、リリース: 公開企業やベンチャー企業に多い
- スクラム: 大企業、非技術系の企業、非ベンチャー資金調達型企業、コンサルタント会社に多い
- カンバン：すべての企業で言及されている
- SAFe (Scaled Agile Framework): 大企業、非技術系の企業、非ベンチャー系企業で言及されている
- Shape Up: 少数のベンチャー企業で言及されている
この調査では、いくつかの興味深い発見がありました。"1 (満足していない) から 5 (非常に満足している) の尺度で、現在のプロジェクトマネジメント手法にどの程度満足しているか／幸せか？"
考察に値する洞察 は次になります。この調査はサンプル数が non-representaitive (訳注: 十分な数ではない？) であるため、慎重に扱うようにしてほしい。とはいえ、これらは私が確認できる見解でもあります。
- 専任のプロジェクトマネージャーがいるチーム は、一般的に公開会社やベンチャー企業では満足度が低い。しかし、ベンチャー以外の企業やコンサルタント会社では、プロジェクトマネジメントに非常に満足している回答者が何人もおり、その理由として専任のプロジェクトマネージャーの存在を挙げている
- 自分たちの働き方を選択できるチーム は、公開会社のテック企業やベンチャー企業でより一般的でした。非技術系の大企業や、ベンチャー企業ではない中小企業では、社内の全チームに同じアプローチを義務付ける傾向が強い
- チームの自主性と高い満足度は相関関係にあるようにみえる。 満足度を4または5と評価した人の多くが、自律性、自由度、柔軟性、チームレベルでの品質第一主義をポジティブな点として挙げている
- 苦戦しているチームは、方法論とはあまり関係がないことが多い。 うまくいかなかった理由として、ビジョンの欠如、優秀なエンジニアの離職、透明性の欠如、ツールの不備などが挙げられている。このようなチームにとって方法論を変えても問題は解決しない
- JIRAはネガティブなイメージで語られることが多い。 JIRA に関する 13 の言及 は、すべてこの設定でした。JIRA をあまり使わずにものごとを成し遂げられることは、ポジティブなこととして言及されました。さらに、最近 IPO した高成長のテック企業が JIRA に移行し、エンジニアの間で調査を実施しました。その結果、ネット・プロモーター・スコア (NPS) は -83 となりました。これは驚異的に低く、エンジニアの 83% が JIRA に対してアドバイスすることを意味します。対照的な意見として、安定した成長を遂げているある公開会社のテック企業のエンジニアリングリーダーは、彼らの組織が JIRA に大きく依存し、ナレッジエンジンとして使用していることを共有しました。彼らの場合、組織が JIRA を完全に採用した後、JIRA は大規模な調整にうまく機能しています。Linear は、私の Uber の元同僚が共同設立した課題管理システムであり、私が投資しているスタートアップ のほとんどが採用を決定し、高く評価しているツールです。なお、私は Linear とは何の関係もなく、これを書くためにお金をもらったわけでもありません。
1または2の評価を残した回答者によると うまく機能しないプロジェクトマネジメントのアプローチ にはいくつかの特徴があります。
- チームがコミットした見積りにエンジニアが関与していないこと は、よくある、なかなか解決しない問題です。私の考えでは、これはエンジニアのやる気を失わせる最も簡単な方法の1つであり、何人かは退職してしまうほどです。
- 専任のプロジェクトマネージャーがいても、要件が変わること はエンジニアにとっては不都合なことです。要件の変更が多いチームもあるが、そのようなチームでは通常、エンジニアがプロジェクトをマネジメントし要件変更に対処できます。しかし、専任のプロジェクトマネージャーがチームを要件の変更から守ることができない場合、回答者はこのアプローチを悪いと評価しました。
- 失敗したプロジェクト管理手法を変更する自主性がないチームも、低い満足度を記録しました。 このような回答は、すべてのチームが同じ方法論に従うことを期待されている企業で顕著でした。これは指示的 (directive) リーダーシップの一例であり、このアプローチは、創造性がほとんど必要とされない職務ではうまくいくかもしれませんが、通常パフォーマンスの高いソフトウェアエンジニアリングチームを構築する方法としては不適切です。チームが一緒に反復 (イテレート) し、自分たちの言葉でプロセスを変えることができれば、満足度と生産性は向上します。
ビッグテックによるプロジェクトの進め方
ビックテックは、他の業界と比較して、技術プロジェクトを遂行するときの取り組み方が異なります。私は有名な公開会社のテック企業の人たちと話すことでデータを集めました。ここでは、彼らが一般的にどのようにものごとを進めているかを紹介します。
| 会社 | "標準" の方法論はあるか？ | もっとも一般的なプロジェクトマネジメント方法論 (順番に) | 通常エンジニアリングプロジェクトのリーダーは誰か？ |
|---|---|---|---|
| Amazon | いいえ。チームが選択できる | プランニング (6-pager) → ビルド (イテレート) → リリース | テックリード |
| Apple | いいえ。チームが選択できる | プランニング → ビルド (イテレート) → リリース | テックリード |
| Datadog | いいえ。チームが選択できる | プランニング (RFC) → ビルド (イテレート) → リリース | テックリードまたはエンジニア |
| いいえ。チームが選択できる | プランニング → ビルド (イテレート) → リリース | テックリードまたはエンジニア | |
| いいえ。チームが選択できる | プランニング (Design Doc) → ビルド (イテレート) → リリース | テックリードまたはエンジニア | |
| Netflix | いいえ。チームが選択できる | プランニング → ビルド (イテレート) → リリース | テックリードまたはエンジニア |
| Shopify | いいえ。チームが選択できる | GSD (Get Shift Done, 6-weeks cycles) → ビルド (イテレート) → リリース | テックリードまたはエンジニア |
| Spotify | いいえ。チームが選択できる | プランニング (ERD) → ビルド (イテレート) → リリース | テックリードまたはエンジニア |
| Uber | いいえ。チームが選択できる | プランニング → ビルド (イテレート) → リリース | テックリードまたはエンジニア |
ビッグテックは、エンジニアがプロジェクトを遂行する方法において、いくつかの特徴を共有しています。
- ほとんどのプロジェクトは エンジニアがリードしています 。テックリードか、チームのエンジニアがリーダーになります。ソフトウェアエンジニアがどのようにプロジェクトをリードしているか については、こちらをご覧ください
- チームはプロジェクトマネジメント手法を自由に選択できます。 多くのチームは RFC のようなプランニングプロセスを採用し、ビルドを繰り返し、数週間以内にすべてをリリースします。他のチームは、よりカンバン方式に近いプロセスで、優先順位の高い項目から取り組みます
- チームレベルのプロジェクトに 専任のプロジェクトマネージャーはいません。 ほとんどの企業では、複数のチームが関わる大規模プロジェクトや、組織をまたがるプロジェクトには、テクニカルプログラムマネージャー (TPM) が介入します。Uber では TPM とエンジニアの比率は 1:50 程度でした。TPMについてもっと読む
- プロジェクトマネジメントの成果物やプロセス は、同じ組織内でもチームによって異なります。ほとんどのチームはプロジェクトバックログを持ち、チームが適切と考える間隔でスタンドアップを行い、時々レトロスペクティブを行います。
- このようなところでは、 一流の開発者用ツールが与えられるのは当たり前 であり、短いイテレーションサイクルにおいて大きな役割を果たしています。多くのチームはメインブランチで作業し、CI/CD システムから素早いフィードバックを受け、作業中の機能をすぐに他のチームメンバーと共有できます。
ビッグテックで働いたことのある人にとっては、この多くはおなじみのことでしょう。しかし、これと同じアプローチを伝統的な企業で真似しようとしても、おそらく失敗するでしょう。というのも、ビッグテックの組織構造は、チームがどのように遂行できるのか、そして遂行するのかに大きな影響を与えるからです。
ニュースレター
私の 週刊ニュースレターを購読して 、ソフトウェア・エンジニアリング業界についての考察や深堀り記事を毎週読んでください。このニュースレターは Substack の No.1 技術ニュースレターであり、このような声が寄せられています 。
プロジェクトに影響を与えるビッグテックの組織構造
ビッグテックがどのようにプロジェクトを管理しているかを理解するために、一歩下がって、これらの企業の多くが活動している環境を見てみましょう。シリコンバレーがソフトウェアエンジニアについて、伝統的な企業にはない "理解" を得ていること という記事で詳しく解説しています。
ソフトウェアエンジニアとチームの自律性。 伝統的な企業で開発者に期待されるのは、与えられた仕事をこなすことです。シリコンバレーのような企業では、ビジネスが抱える問題を解決することです。これは大きな違いです。このことはエンジニアの日々の生活に影響を与えます。
好奇心旺盛な問題解決者であり、頭を使わないリソースではない。 やる気のあるエンジニアは、言われたことしかやらない「工場労働者」の何倍もの影響力を簡単に生み出します。工場労働者のような態度の組織では、このアプローチは意図的に解釈の余地をほとんど残さない、より重厚なプロジェクト管理アプローチに偏るでしょう。
内部データ、コード、ドキュメントの透明性。 エンジニアに限らず、社員はしばしばリアルタイムのビジネス指標やデータソースにアクセスし、独自のクエリーを作成したり、カスタムレポートを作成したりできます。
ビジネスやビジネス指標に触れる。 エンジニアは、ビジネスの他の部分と交流し、非エンジニアとの関係を構築することが奨励されます。対照的に、伝統的な企業では、開発者が他のビジネス部門と交流することを不可能にしていることが多いです。
三角形のコミュニケーションよりもエンジニア間のコミュニケーション。 伝統的な企業は、情報の流れを遅くし、意思決定を遅くする階層的なコミュニケーションを奨励します。
フラストレーションの少ない開発者体験への投資。 エンジニアが迅速に問題を解決することを重視する企業は、様々なプラットフォームチームを立ち上げ、開発者の離職率を低下させます。
高いレバレッジによって正当化される高い給与。 エンジニアをうまく活用している企業は、市場のトップクラスに近い、あるいはそれ以上の給与を支払うことをいとわないです。
優秀な人材の採用。 このような企業は、上記のすべての組み合わせのおかげで、高い能力と高いモチベーションを持った人材を採用しています。これらの企業は、手厚い報酬体系と強力なキャリアアップの機会で知られているため、多くの人材から選ぶことができます。
エンパワーメントされた自律的なチーム は、これらすべての企業の構成要素です。またテック業界の多くの企業にとって、差別化の鍵となる要素でもあります。
ビッグテックのすべてのチームが完全にエンパワーメントされるわけではないが、これらの組織は、先進的な考えを持つスタートアップとともに、チームが可能な限りエンパワーメントされるようにする方法を実施することに最も近いです。
明確なオーナーシップをもつチーム は、ビッグテックのもう一つの構成要素です。5～15人で構成される各チームには、明確なビジョンとミッションがあり、それを実行するためのスキルと自律性があります。そのミッションとは、ホスピタリティ製品のプロダクトチームであれば「高齢者のためのワールドクラスの予約体験を構築する」であったり、プロダクトプラットフォームチーム であれば「労力をほとんどかけずに評価体験を統合できるようにチームを強化する」であったりします。
プロダクトに特化したチームは、通常、バックエンド、フロントエンド、モバイルエンジニアのようなクロスファンクショナルなチームメンバーで構成され、プロダクトマネージャー、データサイエンティスト、デザイナーもチームに加わることが多いです。プラットフォーム重視のチーム は、クロスファンクショナルでもなく、特定のドメインに縛られない傾向があります。
エンジニアが高度な専門性をもっていても、ビッグテックでは経験豊富なソフトウェアエンジニアの多くが幅広いエンジニアリング業務をこなせることを期待されており、面接プロセスにもこのジェネラリスト的アプローチが反映されていることに注意してください。
プロダクトマネージャーのはい／いいえ
ビッグテックとその他の企業とのもうひとつの不思議な違いは、プロダクトマネージャーの役割であり、チームに専任のプロジェクトマネージャーやプロダクトオーナーがいないことです。
これらの企業におけるプロダクトマネージャーの役割は、チームにおける戦略を定義すること、つまり「なぜ」です。そして、この戦略を実行するためのステップが「どのように」です。Facebook 社のプロダクトマネージャー Will Lawrence は このように表現しています 。
プロダクトマネジャーの役割は、どのようなゲームをどのようにプレーするか を考えることだ。戦略とは、我々がプレーするゲームを選択することである。投資する価値のある分野を見つけ、このゲームで成功するための説得力のあるビジョンを描くことだ。(...) 遂行とは、私たちがどのようにゲームをプレーするかということである。ミッションに向かって前進するための日々のプロセス、決断、行動である。
プロダクトマネージャーは、チームが正しいことに取り組み続けることを保証します。これは、ビジネス、データサイエンス、デザインと協力し、ロードマップを作り、計画を立て、仕事の優先順位をつけ、必要に応じてエスカレーションすることを意味します。大企業ではこれ自体がすでにフルタイムの仕事です。
多くの場合、大企業ではプロダクトマネージャーはプロジェクトマネジメントを担当しません。チームが遂行に責任を持ち、チームのリーダー (通常はエンジニアリングマネージャー) がこれを実現する責任を負います。
権限を与えられた自律的なチームでは、プロジェクトをトップダウンで管理することはほとんどありません。各チームによって異なりますが、私はエンジニア間でプロジェクトリーダーの役割を交代させることで、チーム全員がリーダーシップを発揮できるようになり、大きな成功を収めました。購読者は、🔒 プロジェクトリーダーの期待事項 にアクセスできます。
専任のプロジェクトマネージャーがいないことから、いくつかの疑問が生じます。エンジニアはプロジェクトマネジメントで手一杯なのか？プロジェクトを管理することは、エンジニアの時間を有効に使うことなのか？これらはすべて可能であり、私の見解は次になります。
チームレベルのプロジェクト では、専任のプロジェクトマネジャーがいない方が、結果的にプロセスを簡素化し、個人的な関係を強化できます。エンジニアのプロジェクトリーダーは、自分たちの利益のために、できる限りプロセスを増やしません。また、他のチームと協働する際にも、プロジェクトマネージャーを介さずに、プロジェクトを率いる他エンジニアや製品を所有するエンジニアとの関係を構築します。このようなエンジニア同士のコミュニケーションは、複数のプロジェクトマネージャーを介するよりも効率的です。
異なるオフィスやタイムゾーンにまたがる複数のチームにまたがる複雑なプロジェクト では、そのようなプロジェクトのリーダーはエンジニアにとってフルタイムの仕事になります。ビッグテックでは、こうした複雑で、しばしば戦略的なプロジェクトを管理するために、テクニカルプログラムマネージャー (TPM) を導入し、エンジニアの負担を軽減しています。
大手テック企業には、専任のプログラムマネジャー やプロジェクトマネジャーがまだ存在します。彼らは通常、対外的なコミットメントや顧客 (アップルとのパートナーシップのためのプログラムマネージャーなど) 、あるいはコンプライアンスプログラムのような長期的な構想と結びついている。TPM が単一のエンジニアリングチームに割り当てられないのと同様に、プログラムマネージャーやプロダクトマネージャーもエンジニアリングチームを持たず、多くのチームにまたがって仕事をします。
ビッグテックにおけるプロダクトマネージャーの役割が、多くの企業におけるプロジェクトマネージャーやプロダクトオーナーと、どのように異なるかを示す要約が、Facebook 社のプロダクト・マネージャー Ben Erez のツィートから伺えます。
In >1 year as a PM @ Facebook I've created zero tickets/tasks. We don't do sprints either.
— Ben Erez (@ViableBen) 2021年7月28日
PMs here focus on vision, strategy & partnerships. Less on project management & tasks.
Engineers carry most of the project management responsibility & create their own tasks.
It's great.
Facebook の PM として1年以上働いているが、チケットやタスクを作成したことはない。スプリントもやりません。
ここの PM はビジョン、戦略、パートナーシップにフォーカスしている。プロジェクトマネジメントやタスクはあまりやらない。
エンジニアはプロジェクトマネジメントのほとんどの責任を担い、自分たちでタスクを作成する。
素晴らしいことだ。
プロダクト重視の環境とスクラムの廃止
私が Skype 社で働いていたとき、スクラムチームがスクラムを完全にやめてしまうのを目の当たりにしました。私が Skype for Web チームに参加したとき、当初は2週間のスプリントを行い、通常のスクラムプロセスに従っていました。またソフトウェアエンジニアと QA に特化したエンジニアに分かれ、Microsoft 社内では Software Development Engineer in Test (SDETs) と呼ばれていました。しかし、チームのリリースサイクルは2週間ごとでしたが、私たちはもっと頻繁にリリースしたいと考えていました。
最初にやったことは、QA をエンジニアリングの一部にしたことです。"古い世界" のやり方では、エンジニアは自分の仕事を終えてブランチにチェックインし、チケットを更新して QA にレビューの準備ができたことを伝えます。QA は1日か2日後にこのチケットを受け取り、レビューし、問題が見つかればチケットをリオープンします。これは長時間の遅延でした。
私たちは、非公式に静かな変更を行い、すべての SDETs が本番用ソフトウェアも構築し、すべてのソフトウェアエンジニアが自分のコードをテストする責任を持つようになりました。これでコードを本番環境へリリースする前にフィードバックを何日も待つ必要はなくなりました。しかし、隔週のスプリントと数々のスクラムのセレモニーが次の問題となりました。
スクラムが日々のリリースの邪魔になったのでした。 スクラムの全体的な考え方は、スプリントを中心に展開され、スプリントの最初にタスクにコミットし、スプリント中にそれらに取り組み、最後にやったことをデモするというものです。
このプロセスは不自然で、動きの速いウェブチームからは押し付けられたかのように感じられました。私たちはすぐにカンバンアプローチを取り入れました、より流動的な働き方に移行しました。私たちはスプリントを気にするのをやめ、スクラムにつきもののセレモニーもほとんどやめました。私たちは、今何に取り組んでいるのか、そして次に何をするのかを知ることだけに集中しました。
インフラと開発者ツールは、多くのスクラムのセレモニーを不要にしました。 プロダクトオーナーへのデモ、作業の承認、そしてリリースといったスクラムのセレモニーは、いくつかのことを前提としています。
- プロダクトオーナーは、作業が仕様通りに行われたことを確実に検証できる人であること
- プロダクトオーナーが仕様書を書いていること
- 承認を行わずに成果物が本番環境にリリースされることありません
しかし、私たちの環境では、これらの前提にはしばしば欠点がありました。私たちが書いたコードはすべて単体テストでテストされ、必要に応じて統合テストやエンドツーエンドテストも行われました。私たちは、フィーチャーフラグで隠してコードをリリースし、チームへの新機能の導入から始めて、段階的な導入を経て検証しました。多くの "仕様" やチケットもエンジニアによって書かれ、エンジニアはそれが期待通りに動くかどうかを検証することができました。CI/CD、フィーチャーフラグ、実験ツールのおかげで、プロダクトオーナーに頼るよりも速いフィードバックサイクルが可能になりました。
ビッグテックの多くは、一流のインフラと開発者向けツールが、エンジニアリングチームの生産性に大きな違いをもたらすことを認識しています。これが、エンジニアリングの 30～40 ％がプラットフォームチームで働くことが多い理由であり、Uber がプラットフォームチームに多額の投資をした理由です 。ファーストクラスのインフラとプラットフォームがすぐに使える状態であれば、チームはインフラをどのようにセットアップするかとか、サービスをどのようにコンプライアンスに対応させるかといったことよりも、中核となる仕事の目標に集中できます。プラットフォームチームについて、私は次のように考えています。
プラットフォームチームは組織の効率を向上させます。(...) 規模を拡大し、素早くスケールアップするためには、プラットフォームチームは必須となります。(...) しかし、プラットフォームチームは直感的に導入できるものではありません。ビジネス視点の眼鏡でプラットフォームチームを見ると、ほとんど意味がありません。確かに、小規模な組織、あまり成長していない組織、うまく機能している構造を持つ組織では、プラットフォームチームは意味をなしません。
チームのメンバー全員が、私たちがなにを作っているのかを非常に明確に理解していました。 私たちの最終目標は Skype のウェブ機能をリリースすることでした。このアプローチはいくつかのサブプロジェクトから構成されていましたが、全体像はチームにとって明確でした。プロダクトマネジャーがハイレベルな戦略を設定し、私たちエンジニアがやるべきタスクをピックアップし、それを遂行しました。私たちは、スクラムの邪魔な部分を削ぎ落とすのに十分な権限を与えられていました。しばらくすると、残されたものはまったくスクラムではありませんでした。
スクラムの先へ
Facebook、Whatsapp、Google、Netflix や同様の組織のエンジニアと話すと、彼らのほとんどはスクラムを実践したことがありません。なぜか？それにはいくつかの理由があります。
有能で自律的な人材は、信頼できる質の高いアウトプットを生み出すために、より少ない構造しか必要としません。 大手テック企業は、このような人材を惹きつけ、余裕をもたせ、雇用できます。
有能なチームを活用するには、彼らに働き方を選択する自由を与えることが必要です。 これはほとんどの種類のエンジニアリングに当てはまることであり、官僚主義を減らして自律性を高めるという スカンクワークス のモデルが、優秀な人材を擁する多くの高業績チームが最終的に従うことになります。そこにはそれなりの理由があるのです。
エンジニアリング組織のスケーリングは、チームレベルのプロセスをはるかに超えるものです。 これらの組織に生産性に関する課題がないとは言わないが、これらの課題のほとんどは、重量級のプロセスで解決できるものではありません。これらの企業が取り組んでいる課題には次のようなものがあります。
開発者の生産性。 エンジニアがインフラの問題に振り回されたり、依存関係の問題を回避したりする代わりに、チームの目標を達成するためのコードを書く時間を増やすにはどうすればいいのだろうか？プラットフォームチームはその一助となるアプローチだが、ここではさらに多くのことを解明する必要があります。これについては、今後のニュースレターで取り上げる予定です。
技術とアーキテクチャの負債を返済する。 ビッグテックはどの会社も動きが速く、新しいチャンスに素早く対応します。そうすることで、企業はしばしば近道をし、技術やアーキテクチャの負債を抱えることになります。このような負債を「ビッグバン」と呼ばれる技術負債返済プロジェクトではなく、日常的なプロセスの一部として賢明な方法で返済するにはどうしたらよいだろうか？
組織の目標にあったチーム構造。 会社や下部組織の目標は定期的に変化します。チームの結束を乱すことを最小限に抑えながら、どのようにチーム構造にその変化を反映させることができるだろうか？
イノベーションと予期せぬ仕事のための余剰時間。 イノベーションを期待されているチームにとって、それを実現するための余分な時間をどのように作るか？
エンジニアリングチームの成長にあわせてペースを維持する。 エンジニアの数が増えれば増えるほど、多くのエンジニアに影響を与える意思決定やコミュニケーションにかかるオーバーヘッドも増えます。組織の規模が2倍になった後も、同じ速さで前進し続けるにはどうすればいいのだろうか？組織の規模に関係なく、チームが軽快さを保ち、迅速に動くためのプロセスや構造の選択とは？
耐久性のある卓越性。 どうすれば組織全体の処理能力を向上させながら、エンジニアも満足し、改善点が長期にわたって持続し、複合的に作用し続けることができるのか？「耐久性のある卓越性」という言葉は Will Larson による記事「Staying on the path to high performing teams」から引用しました。
スクラムの擁護
ビッグテックの多くがそうしているからと言って、企業はスクラムやその他の方法論を否定すべきなのだろうか？それは間違いです。
スクラムに切り替えることが完全に理にかなっており、生産性の向上につながるコンテキストはたくさんあります。 Skype 社は、この変更が会社の役に立った例であり、Whatsapp 社は Skype 社がどのような方法論を使ったかに関係なく、おそらくコンシューマー向け通話分野で勝利していたでしょう。
スクラムが良い選択肢となる状況をいくつか挙げてみましょう。
1. キッチンシンクチーム あらゆるものがこのチームに投げつけられます。一般的にスクラムのような重量級のプロセスでステークホルダーを管理することが勝利につながると気付きます。ステークホルダーは、進行中のスプリントを中断することはできないし、新しい機能要求には手入れが必要であることを理解するように教育されます。相反する優先順位を持つチームは、スプリント構造によってチームがこれらの中断を無視するスペースを与えられるおかげで、中断を少なくして遂行できるようになります。
"キッチンシンクチーム" は、非技術系の企業では典型的なもので、ビジネスがエンジニアリングの仕組みを理解していません。スクラムは、利害関係者をコントロールし、ソフトウェア開発プロセスについて教育するのに役立ちます。また初期段階のスタートアップ企業でもよく見られますが、そこでは1つのエンジニアリングチームがすべてを構築します。
"キッチンシンクチーム" は、プロダクトチームがあまりにも多くの責任を負わされる場合にビッグテックにおいてもたまに現れます。どのような場合でも、スクラムのようにチームに息抜きのスペースを与えるプロセスに移行することは、非常に理にかなっています。しかし、チームが自律し、権限を与えられるようになると、チーム憲章を更新する代わりに、チームが所有しない仕事にはチームメンバーがすぐにノーと言えるようになることが多くなります。
2. 新しいチームの「形成期」と「混乱期」の段階。 心理学者の Bruce Tuckman は、グループがどのように機能するかについての段階として「形成期、混乱期、統一期、機能期」という言葉を考え出しました。このモデルは、ほとんどのエンジニアリングチームがどのように進化していくのかにも適合します。
新しいチームが結成されたとき、そのチームはどのように仕事をするかを決める必要があります。スクラムのような既成のアプローチに手を出すことは、ほとんどの場合、お互いによく知らないメンバーがカスタムプロセスを考え出すよりも、あるいは全く考え出さないよりも、より良い選択です。スクラムのような文書化されたアプローチを採用することは、"正しい仕事の進め方" について相反する、または互換性のない意見をチームメンバーがもっている場合にも有効です。
スクラムの良いところは、レトロスペクティブがプロセスの一部であることです。これにより、チームは自分たちの仕事のやり方を振り返ることができます。時間の経過とともに、作業スタイルを変更する自主性を持つチームは、通常、必要のない重量級のスクラムルールをやめ、カスタムな作業スタイルを開発するようになります。
3. リリースを数週間に1回の頻度にスピードアップする。 この頻度がスプリントの長さを超えない限り、スクラムは週単位のスプリントとともに、チームがより頻繁なリリースに移行するのを助けます。デジタルファーストではない多くの組織にとってこのような加速は大きな勝利です。
リリースのスピードアップは、Skype 社が 2012 年にスクラムに移行した大きな理由の1つです。移行前は、チームは数ヶ月に1回リリースしていました。移行後、各チームは月に 1～2 回出荷するようになりました。これ以上の頻度でリリースすることになったチームは、スクラムをやめることを決めたチームです。
4. プロジェクトの進捗報告を統一することが必須と考えられている企業。 スクラムと JIRA は密接な関係にあり、JIRA ほど組織レベルのレポーティングに適したツールはありません。私は多くの組織がスクラムを導入し、リーダーシップチームがチームをより可視化し、支援が必要なチームを特定できるようになることを期待していることを見てきました。
統一されたレポーティングとチームレベルの優先事項への掘り下げは、Skype 社のリーダーシップもスクラムへの移行で見た利点の1つでした。当時 Skype 社でアジャイルコーチをしていた Chris Matts 氏は Strawberry-Jam-O-Meter と Wrong-Order-O-Meter をどのように実装したかを話してくれました。
Strawberry-Jam-O-Meter は、進行中のバックログ項目が最も多いチームを特定するために使われました。 Jerry Weinberg の "ストロベリージャムの法則" にヒントを得ました。Wrong-Order-O-Meter は、プロダクトオーナー組織が指定した組織全体のバックログに従って、間違った順序でアイテムに取り組んでいるチームを特定するために使われました。
私の個人的な見解では、権限委譲されたチームがいる組織では、目的および主要な結果 (OKR) 、主要業績評価指標 (KPI) 、目標は、報告のためにスクラムのような厳格な方法論を展開するよりも、チームを調整するためのはるかに優れたツールです。しかし、権限を与えられていない組織、チームや個人が自律的でない組織では、スクラムは代替案よりもうまく機能するかもしれません。
どのようにチームを運営すべきか？
さまざまな段階にある企業が、それぞれ異なるアプローチでプロジェクトを運営する傾向があること、また大企業はこのプロセスをうまく機能させるために多くの組織的サポートをもっているが、大企業が一般的に単一のアプローチを義務付けていないことを見てきました。
チームをどのように運営するかは、その企業の状況によって異なるはずです。関連する要素には、組織構造、一緒に働く人々、その人々の自主性とスキル、競合、「戦時」か「平時」かが含まれます。数え上げればきりがありません。
思考の糧として、次のアイデアを残しておきましょう。
反復的な変化は「ビッグバン」的な変化よりも常に効果的である。 リリースが非常に遅いことに悩んでいたヨーロッパのテック企業が、新しいエンジニアリング担当副社長を雇いました。この人物は、就任後数ヶ月で組織全体を NoEstimates 方式に移行させることを決めました。彼らは大きなイベントを企画し、ロックバンドを雇い、新しい仕事のやり方を発表しました。その後の数週間、数ヶ月は大混乱となり、組織は以前のやり方に逆戻りしました。
誰かに釣り方を教えるのは、その人のために魚を釣るよりも大変なことなのだ。 プロジェクトマネジメントに対する私のアプローチは、チームのメンバーを指導し、プロジェクトリーダーになるよう指導することでした。その結果、チームはより多くの成果を出し、人はより早く成長し、より早く昇進し、その人たちは同業者よりも早くエンジニアリングリーダーになりました。このアプローチは、権限を与えられた環境における私の最善の決断のひとつでした。購読者は、私の blueprint ドキュメント にもアクセスできます。
ディレクション、メンタリング、コーチングにはそれぞれ用途がある。 指示すること、つまり何かをする方法を正確に指示することは、彼らが自分でできるのにマイクロマネジメントになってしまいます。しかし、そうでない場合はサポートになります。指示するのか、指導するのか、コーチするのかによってアプローチを選び、人やチームの能力に応じてスペースを与えます。時間が経てば、指示することはほとんどなくなるはずです。しかし、最初はそうする必要があるかもしれません。
意思決定に必要な人数が少なければ少ないほど、意思決定を迅速に行うことができる。 あるエンジニアが、あるエンジニアと話をするだけでよいのなら、そのエンジニアがプロジェクトマネジャーと話をし、そのプロジェクトマネジャーがまた別のプロジェクトマネジャーと話をし、そのプロジェクトマネジャーがまた別のエンジニアと話をし、そのエンジニアがまた別のプロジェクトマネジャーと話をし......といった具合に、エンジニアがプロジェクトマネジャーと話をする必要がある場合よりも、その決断は早くなるでしょう。
レポーティングを最適化することは、信頼性の低い環境を最適化すること。 幹部レベルでのレポーティングは重要です。しかし、レポーティングのために重たいプロセスを追加するようなプロジェクトマネジメント手法を導入すれば、プロセスが増え、信頼が低下し、どんなレポーティングを作成しようとも、人々がギャンブルをするようになります。
コンサルタントは、自分の価値を証明する最も簡単な方法であるため、測定しやすい結果を出すことに偏る。 測定しやすい結果がよい目標であれば、コンサルタントは良い投資となります。ただ、それが価値ある目標であり、方向性が正しいことを確認してください。
直接の競合相手から学ぶことは過小評価されている。 動きの速い競合他社がやっていることを理解し、似たようなことを試してみるのは、非常に賢いやり方です。競合他社の同業者とコーヒーを飲むことは、プロとして、また人脈作りのための投資として素晴らしいものになります。
優秀なエンジニアの中には、マイクロマネジメントされるくらいなら辞めたいと考える人もいる。 とくに雇用市場が熱く、転職が容易なときには。
私のアンケートへの回答から関連する言葉を引用します。
最近、Cレベルのエグゼクティブが、すべてのチームに対して仕事のやり方を強制し始めた (全員が同じ方法論に従う必要がある) 。その結果、多くのエンジニアが辞めていきました。
私は、他の人たちからインスピレーションを得て、実験し、反復し、人々がやる気になるような信頼性の高い環境に向かっていくことを勧めます。これは 私が行ったこと であり、チーム、会社、そして私自身という全員の利益のために、チーム内のすべての人が成長できるような体制を整えた方法です。
推奨記事
- Execution at Facebook by Will Lawrence
- Staying on the path to high performing teams by Will Larson
この記事のレビューに協力してくれた Adriaan, Alexandra, Alex, David と Steve 氏に感謝します。
本稿のオリジナルの記事は次になります。
見積もりをがんばらない
スクラムを開発方法論に採用しているチームで開発者をしています。最近たまたま見積もりについての話題がチームであがり、私の経験や考えを整理してみる機会にしようと考えました。お断りとして、本稿の考え方が正しいと主張する意図はありません。世の中にはさまざまなチームや開発スタイルがあります。私が経験していない業務においては他のやり方もうまくいくケースがあると考えています。
スクラムガイド には見積もりの実践について明確な指針を提供していません。一方でスプリントを設定し、スプリントプランニングを行う上で通常はその期間内にスプリントゴールの達成を図ることから、必然的になんらかの見積もりを行うことを前提としています。インターネットを検索すると、プランニングポーカーとストーリーポイントを用いた見積もりの記事も多くみつかります。私の立場として、ストーリーポイントという見積もり手法をやや懐疑的にみています。この手法は一定の制約の中でしか機能しないのではないかと私は考えています。その理由や背景も後述します。
また、チームのスプリントにバーンダウンチャートが導入されました。バーンダウンチャートの運用についてスクラムマスターと議論していて、私の見解とは大きく異なることに気付きました。スクラムのルールとバーンダウンチャートの目的が合致せず、不思議に思ったのでそれについても後述します。バーンダウンチャートもスクラムには含まれません。
TL/DR (要約)
- (ストーリーポイントを用いない) 見積もりは担当者によって変わる
- 見積もりの精度は見積もり対象に対する情報量や知識量に依存する
- 見積もりはその見積もりを行った時点での予測に過ぎない
さらにまとめると言いたいことはこうです。
- 見積もりは外れるので常に補正していく
スクラムと見積もり
アジャイル開発とスクラム 第2版 で木下氏が書かれた「2020スクラムガイド改訂とスクラムの3つの罠」というコラムで、デイリースクラムの目的を次のように述べています。
デイリースクラムの目的は状況に合わせた再計画であるため、形式的な報告だけではいけない。
私自身、このコラムを読むまで勘違いしていました。デイリースクラムとは昨日やったことや今日やることの報告をするものだと考えていました。本当の目的は、なにか障害があったときにスプリントの計画を柔軟に再プランニングすることです。スクラムガイドにも「デイリースクラム」の節に次のように説明されています。
開発者が計画を調整できるのは、デイリースクラムのときだけではない。スプリントの残りの作業を適応または再計画することについて、より詳細な議論をするために、開発者は⼀⽇を通じて頻繁に話し合う。
スプリントゴールが変わるような再プランニングをデイリースクラムで議論するのは構わないと思いますが、ゴールに含まれないタスクやスプリントバックログアイテムの再プランニング (次スプリントへの先送り) は開発者が能動的に行えばよいのではないかと私は考えていました。しかし、スクラムマスターからは次のようなコメントをいただき、私の考えるスクラムの運用や見積もりとスクラムマスターのそれとは大きく乖離していることに気付きました。
- 基本的にはスプリントプランニングで立てた計画は変更しない
- スプリントの中止だけ唯一 PO に権限が与えられている
- スプリントの終了日にすべてやりきらなければならないということはない
- 検査／適用／透明性を実現できることが重要である
- バーンダウンチャートはスクラムには含まれない
スプリントとバーンダウンチャート
チームでは Backlog を用いて バーンダウンチャート を表示しています。
Backlog のヘルプセンターの概要には、バーンダウンチャートの意味や目的については説明していないので、バーンダウンチャートとは？意味やメリット、作り方のポイントを解説 の記事を読み解きながらバーンダウンチャートの目的や役割を次にまとめます。
バーンダウンチャートとは、マイルストーン (スプリント) の期間における、仕事量と時間の関係を表したものである。当初の計画と現時点の進捗状況がどのぐらい乖離しているかを視覚的に表現してくれる。グラフの傾きが進捗のスピードを表し、グラフが横ばいになると進捗が停滞していることを表す。バーンダウンチャートのメリットとして、計画と実際の進捗との乖離が明確になるのと、残された期間に対する仕事量の関係を視覚的に確認できることがあげられる。マイルストーンの完了後に当初の計画と実際の進捗との管理を振り返ることにも使える。
たしかにこの説明からも、スプリントにおいて完了できないタスクをそのまま置いておき、そのスプリントの振り返りの材料とする使い方はできるように読めます。またバーンダウンチャートの注意点として、次の2点があげられている。
- バーンダウンチャートは目安のひとつとして使う
- バーンダウンチャートでは表現できないメトリクスがあるので、これだけでプロジェクト管理はできない
- タスクをできるだけ正確に見積もれるようにする
- タスクの見積もりに正確さを欠いてしまうと、理想線・計画線と実績線が大きく乖離してしまう
- 「作業完了」の定義がメンバー間で異なると、仕事量の推定が不確かなものになり、適切なチャート運用を困難にしてしまう
バーンダウンチャートの適切な運用にはタスクの正確な見積もりが必要であると、この記事では説明されています。バーンダウンチャートを利用するのであれば、なるべく正確な見積もりとなるように努めるのは正しいでしょう。ここで、スプリントにおける、あるタスクの見積もりが外れたときに、そのタスクのマイルストーン (スプリント) を変更するかどうかでスクラムマスターと私では意見が分かれました。
スクラムマスターはタスクのマイルストーン (スプリント) はスプリント期間内では変更しないため、バーンダウンチャートはバーンダウンしなくてよいと主張します。一方で、私はバーンダウンチャートをみながら、マイルストーン (スプリント) に間に合いそうにないタスクはマイルストーン (スプリント) の変更を行い、スプリントが完了するときにはタスクがゼロになる、バーンダウンするのがよいのではないかと主張しました。
意見や考え方の相違そのものを私は気にしてはいません。しかし、スクラムマスターと私で見積もりに対する考え方が大きく異なることから、バーンダウンチャートの運用に食い違いが出ました。
本稿では、私の見積もりに対する考え方を説明した上でバーンダウンチャートの運用について述べます。
見積もりと不確実性コーン
そもそも正確な見積もりはとても難しいというのが私の経験則です。多くの人は共感してくれるのではないかと思います。大前提として、見積もりは誰がやっても外れる ものであり、一定のズレを織り込んだ上でプロジェクト管理を行うべきであると私は考えます。
私の経験では、見積もりと計画との乖離を過剰に責めるとメンバーが不正や誤魔化しを行い、結果的に品質が大幅に劣化して、後になってから (たいていは運用が始まってから) 大きな問題に発展することがありました。問題はわかった時点で対応する方がずっとコストが低くなります。品質管理の視点から見積もりのズレを誤魔化す必要は全くなく、そのズレを認識した時点で然るべき補正をしていくことが重要だと私は考えています。
見積もりの話題によく引用される図に 不確実性コーン があります。エンジニアリング組織論への招待 から引用します。
プロジェクトの進行とともに見積もりのバラツキがどのように推移していくかを表したものです。プロジェクトの初期は最大4倍程度のズレが発生する可能性があり、終了前ではほとんどズレないということを表しています。調べてみると、この図は1981年に発表されたものでウォーターフォール型開発の時代の話しだそうです。現代の開発で同様にみなしてよいか、検討の余地はあるかもしれません。一方で私の経験則においてもこの図のバラツキは一定の理があるように受け取れます。
私は次の要因によってこのズレが起きるのではないかと考えます。
- プロジェクトの初期は必要な情報が不足している
- プロジェクトの初期はメンバーのスキルが未熟である
- 情報もスキルもない状態では知識や知恵を得るのが難しい
そのため、プロジェクトが進むことで次のことが発生して見積もりのズレが補正されるのではないかと考えます。
- プロジェクトの初期と比べて、相対的に情報が増える
- メンバーが成長する (スキルや知識を身につける)
ストーリーポイントとプランニングポーカー
チームでも度々ストーリーポイントの話題が出るため、ストーリーポイントとプランニングポーカーという手法での見積もりについても考察します。
私はストーリーポイントもプランニングポーカーも実践したことはないため、この記事を読んだ程度の浅慮で書きます。そのため、本節の内容は誤っている可能性があり、参考程度に読んでください。
ストーリーポイントは、ストーリーポイントを実践できる状態のチームを先に作る必要があるのではないかと私は考えます。作業時間や工数をストーリーポイントに抽象化し、それをプランニングポーカーという手法で高い精度で見積もったとしても、そのストーリーポイントを誰でも同じぐらいの速度・品質でメンバーが対応できないと意味をなしません。というのは、どんな理屈を述べても最終的にストーリーポイントは作業時間や工数と対応付けられてしまうからです。現実の期限が10ストーリーポイント後になりますということはありません。
スクラムは属人性を排除して、メンバー全員がどんな作業でも同じぐらいの速度・品質でできることを目指すフレームワークであるというのは正しいと思います。しかし、現実の世界でその状態を維持するのはとても難しいのではないかと私は考えます。メンバーの知識やスキルセットには個人差があり、退職や移動などチームのメンバーは入れ替わります。そして、現実の業務にはドメイン知識や経験が必要とされ、その習得のために一定の学習コストを要します。1人でできる作業を複数のタスクに分割してメンバー全員が担当することによって属人化をなくすというのがスクラム的なやり方だというのは重々承知していますが、それを実践するには業務に対して過大なリソースを割り当てる必要があります。大雑把に言えば、1人でできるタスクを3つのタスクに分割して3人でやるような話しになるのではないでしょうか。大企業ではそういった働き方をしているかもしれません。
現実の世界では、特定の業務に対するドメイン知識やスキルは担当者個人に紐付いていることがよくあります。例えば、ある担当者 A が3年かけて身につけた知識やスキルを、3ヶ月ほどメンバー B や C に教えたからといって、B や C が A と同じことができるようにはならないことはあるでしょう。A, B, C でプランニングポーカーを行い、ストーリーポイントを見積もったとしても、A と B, C における実際の作業速度は大きく異なります。さらに本当は速度だけではなく、品質レベルも平準化しないといけません。しかし、品質は速度よりもさらに平準化が難しいです。
スクラム的な見積もり、ストーリーポイントとプランニングポーカーを実践するには、まずチームの知識やスキルセット、実践における品質レベルを先に平準化する必要があります。強いて言えば、過半数以上のメンバーの知識やスキルセットが高くない、深いドメイン知識を必要としない業務開発などに対してこの手法はうまくいくのではないかと思えます。私の知人からもそういう事例を聞いたこともあります。
ストーリーポイントのデメリット
【翻訳】ストーリーポイントを使うのをやめよう の記事では、ストーリーポイントの弊害についてまとめられています。2012年に書かれた記事でやや古く、いまの状況とあっていないこともあるかもしれません。この記事に出てくる成熟したチームで直感による見積もりを補正する程度でうまくいっている話しや著者の知人のベテランのアジャイル実践者のほぼ全員、何年もの間ストーリーポイントとベロシティ計算を利用していないと述べています。
これはストーリーポイントに限った話しではありませんが、測定される値に報酬が与えられるものはすべてが改ざんされるという キャンベルの法則 と呼ばれるものが、まさにこの記事で述べられている弊害のいくつかに当てはまるでしょう。さらにひどいことにストーリーポイントが誤解されてしまうと、その抽象化された概念の曖昧さゆえに誤解を正すために時間と労力を要するといったことも述べられています。
余談ですが、私の周りでストーリーポイントを実践していたり、その有用性を説く開発者はほとんどいません。
見積もりは担当者が決める
前節では、チームにおけるメンバーの知識やスキルセットが平準化されていない状態で、みんなで見積もることは役に立たないと私は述べました。本節では一旦、時間や工数といった従来のやり方で見積もるときの手法について考察します。
時間や工数を見積もる場合、見積もりは外れるという前提とともに、タスクの担当者が決めて補正していく やり方がもっともうまくいくのではないかと、私の経験則から考えています。X というタスクを、A は3日、B は5日で完了すると仮定します。前提として、X というタスクを A が担当するのか、B が担当するのかで見積もりは変わることを受け入れます。A が担当しても B が担当してもよいが、B が担当するときは3日ではなく、B の知識やスキルセットを考慮して5日という見積もりとします。
実際に B が X のタスクの作業をしていて5日では終わりそうにないことが、4日目にわかったとします。このとき、あと何日かかりそうかの再見積もりも他メンバーではなく、B が自分で見積もるようにします。見積もりが外れると同時に、B は再見積もりと一緒に振り返りの機会を得ます。認知心理学ではこのことを 活動中の振り返り (reflection in action) と呼んでいて、学習におけるメタ認知的活動の1つと分類しています。見積もりが外れたときの再見積もりには、それ自体を省察の機会とする狙いがあります。見積もりが外れることは構わないが、なぜ外れたかを振り返ることが重要であると私は考えます。
タスクの担当者に再見積もりを行わせる別の理由に、進捗中のタスクには情報の非対称性が生じやすいという背景があります。組織における情報の非対称性とは、マネージャーが知っていてメンバーが知らない情報が多いという状況を指すことが多いですが、現場の業務においてはその逆が生じます。B が担当者として作業しているタスクの状況を他メンバーがその実態を把握するのはとても難しいです。とくにソフトウェア開発はそうです。B が行った作業状況を最も理解しているのは B 自身であり、B が再見積もりする方が見積もりの精度が高くなる可能性が高いと言えます。
多くのケースで見積もりが外れるのは、想定していない状況や情報不足によることが多いです。そこで B は X というタスクを完了する上で必要な情報や気付きを得て学びにつながります。仮にその学びを他メンバーに共有したとしても、B の暗黙知を過不足なく他メンバーに共有することもまた難しいです。このような実務の1つ1つの作業がメンバーの知識やスキルセットの形成につながり、それをチームで平準化するためにやはり時間を要すると言えるでしょう。
見積もりは常に補正する
前節で見積もりは担当者が行うことを私は提案しました。さらに見積もりはプロジェクトやスプリントの開始時点で行うものと考えがちであるが、私はそのように考えていません。何度も申し上げているように 見積もりとは外れるもの という前提があるからです。
作業を進めていく過程でさまざまな情報を取得したり、たまたま担当者が体調が崩してパフォーマンスを落としたり、その時々の状況にあわせて担当者の状態が変化します。知識や情報量が増えることは見積もりを減らす方向に作用し、体調を崩すことは見積もりを増やす方向に作用します。担当者の状態が変化したときに再見積もりすることは、時間が経つと、より精度の高い見積もりになるという 不確実性コーン の理論とも合致します。
見積もりを自身の状態の変化にあわせて行うという考え方は、プロジェクトやスプリントの開始時点で見積もることとも矛盾しません。熟達者の見積もりの精度が高い理由は、見積もり対象のタスクの知識や情報を開始時点から他メンバーよりも多くもっているという点があげられます。
「エンジニアリング組織論への招待」の「プロフェッショナルの仕事」という節に次の図が紹介されています。
熟達者であっても未知のタスクをこなすときの初期の見積もりは外れることが多いはずです。しかし、熟達者は不確実性の高いものから取り掛かるため、作業の早い段階で全体像をみえるようにしてしまい、後半は品質の作り込みを行うだけなので未知のタスクであっても早い段階で精度の高い見積もりに補正してきます。一方で、経験が少ない人はわかる範囲から作業を進め、後半になってから不確実性の高いものに取り掛かるため、作業の後半になっても見積もりのズレ幅が大きくなってしまう場合があります。
ここでは不確実性が高いものとは、その対象に対する知識や情報が不足していると言い換えられます。タスクにおいて不確実性が高いものは何かを把握することにも一定の経験やスキルを要するのです。前節で、時間とともに見積もりの精度が上がる背景を、必要な情報の取得とスキルや知識の習得と考えました。もし作業の後半になって行った再見積もりのズレも大きい場合、不確実性の高い作業を認識できていなかったと考えられるのではないでしょうか。
見積もりは外れるという前提とバーンダウンチャート
スクラムマスターは、スプリントプランニングで決めたタスクの見積もりに対してどのぐらい完了できたかみるためにバーンダウンチャートを用い、バーンダウンしなくてもよいと主張しました。おそらくバーンダウンチャートがバーンダウンしなかったことはスクラムイベントのふりかえりで見返すだけという運用を想定しているのでしょう。この背景はプランニングでは正確に見積もることと決めたことができなかったという事実を重視していると言えるでしょう。
一方で私は 見積もりは外れる という前提から、スプリント中に日々バーンダウンチャートをみながら実際のタスクの進捗と見積もりとの差異を確認し、見積もりのズレから気付きを得てタスクの見積もりやタスクのマイルストーンを補正しながら、スプリントの完了までにバーンダウンチャートをバーンダウンさせる運用を想定しています。冒頭でも説明したようにデイリースクラムの目的は再プランニングにあります。スプリントプランニングで決めたことを重視せず、日々の進捗にあわせて変えていこうという実践を重視しています。
スクラムの目的である検査／適用／透明性を実現するために、チームにとってどちらがうまくいくかという議論のたたき台として本稿を書きました。
余談ですが、見積もりと関連して短過ぎるスプリントの弊害もあるように感じています。私が参加しているスクラムチームはスプリントを1週間にしていますが、メンバーの業務に対する習熟度が低いと適切なタスク分割ができず、タスクが1つのスプリントで完了せず、複数のスプリントにまたがって同じタスクに取り組んでいるということも常態化しています。これが常態化すると、スプリントでタスクをやり切るというタイムボックスの効果が薄れます。さらにプランニングは前スプリントに完了しなかったタスクが優先となってしまい、新たに追加できるタスクが少なくなることから、プランニングの意義が減ってしまうようにも感じています。
まとめ
個人的には、見積もりやタスクの完了にバーンダウンチャートが役に立つとはあまり考えていません。
本当の意味で、マイルストーン (スプリント) でタスクが完了しないことを、そのタスクの担当者はある時点から気付いています。こういった見える化したいという意図は、プロジェクト管理をする立場の人から、タスクの進捗が担当者との情報の非対称性によって分からないから見える化したいというモチベーションに基づいていると私はみています。そして、バーンダウンチャートをみて、そのスプリントにて、プランニングで決めたタスクが完了しそうにないとわかったら、プロジェクト管理の立場の人がタスクのマイルストーンを変えていくのがよいのではないかと私は考えています。スクラムで言えば PO でしょうか？
一般論として、タスクの担当者は、タスクが完了しないことを認めたくない傾向があります。タスクが完了しないことは見積もりや実務能力の未熟さを露呈するものなので、自身が無能だと思われたくないという心理が働きます。これは容易に品質を犠牲にしてもタスクを完了させたいというインセンティブに変わります。とくにまだ十分に時間がある中で間に合わないという判断を下すのは担当者にとってはある種の屈辱感もあります。
したがって、私はマネージャーの立場と責任においてタスクの先送りをするのがよいと考えています。タスクが遅延したのは、担当者が無能だからではなく、マネージャーが無理なスケジュールにタスクを割り当てたという体裁にしてしまうのです。しかし、スクラムにはマネージャーに相当する役割がいないので、担当者以外にタスクが間に合わないという判断を誰が下すのでしょうか。スクラム的にはチームで話し合って決めるというのが教科書に書いてあると思います。しかし、私はそれでもチームって誰ですか？と聞いてしまいたくなります。
リファレンス
アジャイル開発とスクラム 第2版 顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント
最近、開発方法論や組織論に関心をもっています。2020年改訂スクラムガイド を読んだり、実際に業務でもスクラムを実践している開発チームで働いています。しかし、まだスクラム開発者として働き始めて2ヶ月なので新人です。これまで私はスクラムを実践している開発チームで働いたことがなく、いま初めてスクラムチームで開発者として実践しています。とはいえ、チケット駆動開発 + イテレーション開発 は10年以上実践してきており、厳密な定義では正しくないかもしれませんが、広義ではアジャイル開発という枠組みで開発を実践してきたと私の中では捉えています。そして、私の周りでうまくまわっていないスクラム開発をみかける度にチケット駆動 + イテレーション開発でうまくいくのになぜスクラムのような効率の悪い開発をしているのか？とすら内心では思っていました。
本書を読み終えて、結論から言うと、これまでの私の考えは誤っていたことが分かりました。スクラム開発が悪いわけではなく、スクラムをうまく実践できていない開発チームの諸問題を、スクラムがよくないかのように私が誤解していたと補正できたことが、本書を読み終えて私が得た最も大きな収穫と言えます。
(2020年改訂版の) スクラムガイドでは意図的に抽象的な表現を用い、役割と会議体のルールを定めた軽量な開発方法論のフレームワークを提供しています。そもそもスクラムとは、それ単体でうまく機能するような方法論ではないと考えるのが正しいようです。組織の文化、顧客、開発対象・規模など、様々な状況において柔軟にカスタマイズできるようなフレームワークです。そのため、一口にスクラム開発というカテゴリに括ることはできても、それは組織や開発チームによって千差万別であると言えるでしょう。
したがって、開発方法論がスクラムであるかどうかはあまり重要ではなく、スクラムをベースにしてもしなくてもいいが、開発がうまくいくように創意工夫や改善をし続けることが重要であり、スクラムはそのための下地としてのフレームワークを提供するにすぎないということが本書を読み進めていくうちに理解できました。
このことは第3章で木下文彦氏が書かれた「2020スクラムガイド改訂とスクラムの3つの罠」というコラムからも伺えます。私がスクラム開発を誤解していたように、スクラムを適切に実践できていない開発チームの特徴を3つの罠として述べられています。これまで私はこの3つの罠に陥っているようなスクラムチームを傍からみていて違和感を抱いていたと言えるでしょう。
3つの罠から1番目の例を取り上げると、デイリースクラムが形式的に情報を報告するだけになっているチームがあるとコラムの中では指摘されています。本来のデイリースクラムの目的は状況に合わせた再計画であり、形式的な報告はその副次的なものです。こういった目的を理解せずにただガイドに書いてあるからと状況報告するだけのチームも増えたのだろうと推測します。
余談: デイリースクラムのトレードオフ
私はデイリースクラムが現代の開発方法論において開発の生産性とトレードオフになっていると考えています。
まずデメリットから述べます。スクラムガイドではデイリースクラムを15分のイベントと定義しています。毎日15分会議してなぜ生産性が落ちるのか？と思う人もいるかもしれません。私が課題意識をもっているのは時間の長さではなく、チーム全員を毎日同じ時間に集めるという同期的イベントの発生そのものに懸念を抱いています。同期的イベントのデメリットとして次のようなことが考えられます。
- 集中して作業をしていても強制的に中断させられる
- 同期的イベントの前後30分ぐらいは集中力を要する作業がやりにくくなる
- 様々な理由でチーム全員集まらないことがままある
まずデイリースクラムを何時に開催するか？という大きな課題があります。朝10時にしているところも多いのではないかと推測します。私は朝型なので平均して8時ぐらいから始業しています。そうすると、集中して作業をしていても必ず10時に作業の手を止めなくてはいけません。そして夜型の人にとっては10時に参加することが難しいメンバーもいます。そういう人は遅刻したり午前半休することが常態化してしまうこともありました。13時にすればよいのでないか？となると、急ぎの報告をしたいときに13時では遅いため、デイリースクラムの前に打ち合わせをしてしまい、デイリースクラムを必要としなくなってしまう状況も起こりがちになります。こういう指摘をすると、朝会と夕会をやろうと言い出すマネージャーが現れたりして、さらに会議を増やすのかと私のような開発者はうんざりするわけです。とくに実務をやらないマネージャーほど、会議を増やすことに抵抗がなく安易にそういった提案をする傾向があるように思います。
またデイリースクラムという1日1回しかないイベントでしか進捗を報告しないメンバーの問題もあげられます。チケット駆動開発に慣れた開発者からみると、これでは報告が遅過ぎるように感じるのです。問題や懸念が発生した時点でチケットにその状況を記載し、それをマネージャーやメンターがみていれば、その時すぐにアドバイスや対策を検討できます。しかし、デイリースクラムでしか進捗報告をしないメンバーがいると、1日1回しかアドバイスや対策を議論できなくなってしまう懸念があります。それはメンバーの問題でしょうと思う方もいるかもしれません。しかし、私は知人からもこういった話しをたまに聞くため、特殊なケースではないと考えています。とくにメンバーのスキルが未熟なために誤った考え方や作業方針で進めてしまっている場合、1日1回の進捗報告では訂正がやりにくい状況というのがあります。スキル不足が原因の場合、メンバーは誤っているという気付きがないために報告できないのです。チケット駆動開発であれば、発生時に状況を伺う内容がコメントとして記載されるため、マネージャーやメンターがより迅速に状況を把握して訂正していくことができるのです。
ここからはデイリースクラムのメリットを述べます。スクラムを支持している方も安心してください。当然デメリットがある一方でメリットもあります。繰り返しますが、本来のデイリースクラムの目的は状況にあわせた再計画にあります。
想定外の状況が発生したため、スプリントのタスクを見直したり、ゴールを変更したりすることを比較的早いタイミングでメンバー全員で確認・合意できるところにあります。また先ほど、私がチケット駆動開発ならば書き込まれたコメントから状況を把握できると言いましたが、これをすべてのメンバーができるとは限りません。自分がやっていることを文章として書き表せるというスキルは、私が思っていたよりも習熟を必要とするスキルであり、開発者であっても全員ができるというわけではないことが経験則から分かってきました。書くスキルに加え、自ら情報発信するのが苦手なメンバーもいます。そういったメンバーは書くよりも話すことで情報共有できるデイリースクラムという場が唯一の救いであり (一方で義務でもあり)、聞かない限り状況を伝えるのが苦手なメンバーでも協働しやすいプラクティスと言えます。
さらに本書を読み進めることで著者の野中氏がナレッジマネジメントの古典となっている考え方として SECI モデルを説明しています。そして、SECI モデルの 共同化 (Sociallizatoin) がプロジェクトの起点であり、個人の暗黙知を他人や組織の暗黙知に伝えていくことの意義や重要性を説いています。起点が暗黙知であるならば、それはチケット駆動開発のようなコメントや文章として書くことはできないのです。
スクラムのイベントが多いのは個人の暗黙知を他人や組織の暗黙知に伝えていくための装置でもあるように私は受け取りました。そして、デイリースクラムもその暗黙知を伝えるための役割の一端を担っているはずです。だからこそ、儀式的に進捗を報告するだけのイベントには意味がなく、個人の暗黙知を伝える共同化という活動を促す必要があるのだと私は理解しました。
つまり、デイリースクラムは直接的には状況にあわせた再計画という目的をもちながら、中長期的には共同化という知識創造につながるプロセスも組み込まれているのです。単純に開発の生産性だけを理由にデイリースクラムは非効率だと断じるのは適切ではないと、本書を読み終えて私は考えています。
前置きが長くなりました。ここからは本書を読んで私が関心をもったところを抜き出して紹介します。
スクラムの起源と知識創造と組織
ソフトウェア開発方法論としてのスクラムはジェフ・サザーランド氏らによって定義され、スクラムガイドによってまとめられています。一方でそのオリジナルと言えるコンセプトは、野中氏と竹内氏が1986年にハーバード・ビジネス・レビューに掲載した The New New Product Development Game という論文になります。この論文はスクラムの直接の参考文献であり、スクラムの理論的基礎にもなっているそうです。
本書の「第10章 竹内・野中のスクラム論文再考」には野中氏と竹内氏のオリジナルの論文とソフトウェア開発方法論としてのスクラムの対比や考察が行われています。1986年という、日本の製造業が強かった時代に書かれた論文なので、いまとは全く時代背景が異なります。その時代背景も考慮しながら現代のスクラムとの共通点を見い出すことは、普遍的価値や概念を推し量る上でとても意義のあることだと私は思いました。さらに歴史を振り返ることでその是非を検証することもできるかもしれません。いま考えたことややっていることが正しいかどうか、本当の意味では、時間が経ってから歴史を振り返ることでしか検証できません。そして、オリジナルの論文とスクラムの間には多くの共通点があり、その意図している目的や概念を理解することでスクラムが意図する目的の理解もより進みます。
野中氏は2010年までこの論文のコンセプトがソフトウェア開発方法論として使われていることを知らなかったそうです。野中氏は組織や組織的知識創造理論の研究者であり、氏の理論が実際のソフトウェア開発の中でどのように発展してきたか、どのように要項が取り入れられているかなど、氏の研究にも意図せぬ相乗効果を生み出しているように私は読めました。そのため、スクラムの今後の発展形や拡張を推し量る上で野中氏の理論を学ぶことにも大きな意味があるように私は考えています。
また Scrum Inc. CEO であるジェフ・サザーランド氏のインタビューも本書の中で紹介されています。ジェフ氏はオリジナルの論文を1993年の終わりに作られた開発チームに取り入れたそうです。チームリーダーをスクラムマスターと呼び、機能横断チームを採用しましたが、最初はそれだけでは大きな変化をもたらさなかったように答えています。そして、第2スプリントでデイリースクラムを取り入れたらすごくうまくいき、第3スプリントでは生産性が最初の2回のスプリントと比べて400%にアップし、1ヶ月の仕事を1週間でやり終えたことが語られています。そして、そもそもジェフ氏がスクラムを体系化しようと考えた動機にも触れており、それは後半の実践知リーダーシップとはどういうものかにも係ってきます。
本書の前半では、ソフトウェア開発プロジェクトの背景や難しさ、スクラムの方法論やアジャイル開発における様々なプラクティス、大規模スクラムの話題などが書かれています。そして、中盤に事例紹介があり、後半は知識創造の背景や方法論について述べられています。とくに 実践知 という概念について説明されているところに私は関心をもちました。
実践知とは、アリストテレスが フロネシス と呼んだ概念であり、暗黙知と形式知との両方で構成されるものであると説明されています。そして、そこに身体性を伴っていないと実践知とは呼ばないというやり取りも野中氏のインタビューで話されています。「第12章 スクラムと実践知リーダー」を読んだだけでは曖昧だった実践知という概念が、その後のコラムやインタビューでのやり取りから、私はより理解できました。実践知は、考えることと行動することがセットになっており、自分の頭の中で考えているだけでは得られないものであることが明言されています。昔は 知行合一 と呼ばれていたものですが、90年代以降の日本は分析過多、計画過多、コンプライアンス過多になってしまい、そのことを忘れてしまっているという件には納得感がありました。
野中氏は日本的経営の強みとしてミドル層、中間管理職の存在をあげています。過去の日本においてはトップと現場に間の独特のポジションが政治力や知識の共有に影響力をもっていたと言います。そして、日本からイノベーションを起こしていくためにミドル層の役割が重要だとも話されています。しかし、この点だけは私は同意できませんでした。1980年代の日本においては中間管理職が大きな役割を担っていたかもしれませんが、私の経験からは中間管理職を不要とする組織を目指すべきではないかと考えています。中間管理職の大きな役割の1つにトップの考えや方針を現場に伝えることがあります。これは口頭で議論できる人数という物理的制約を伴うコミュニケーションパスの問題から組織階層が生まれたのではないかと思います。そして階層型の組織には情報の非対称性というとても厄介な問題があります。情報の非対称性は組織の理不尽を増大させてしまいます。だからこそ中間管理職が重要だという主張も理解はできますが、ICT 技術が発達した現代では別の解決策があるのではないかということを追求したいと私は考えます。その答えがティール組織やホラクラシーであるかどうかはまだわかりません。
合宿をしなさいという解決方法
「おわりに」という最後の結びに野中氏のこんなエピソードが紹介されています。2011年にジェフ氏とガブリエル氏がスクラムのトレーニングを日本で開催し、その際に平鍋氏と野中氏が飛び入りで参加したそうです。そして、参加者からの質問に対して野中氏が次のように回答したやり取りが紹介されています。
「プロジェクトには、営業部門、マーケティング部門、サポート部門など、いくつかの部門のステークホルダーがいるのです。そして、どの機能を優先すべきかについて意見が分かれているのです。意見を1つにまとめるには、どのようにしたらよいのでしょうか」
「合宿をしなさい」
「形式的な会議で決めることはできない。いろんな背景をもった人の集合において、形式知で語れること、理解し合えることはごく一部だ。合宿をし、一緒に飯を食い、泊まって徹底的に話しをする。そうすると、形式知は脱ぎ捨てられ、自分の主観で話すようになる。そこで、なぜこのプロジェクトに自分が参加しているのか、という根源的な問いにまでたどり着けるだろう。そこから初めて、1つの共通理解が生み出される。この過程をみんなで踏みなさい。」
この回答がどのような組織や状況においても正しいとは私には思えません。しかし、この回答は決して私が自分の言葉では語れない類のものであり、野中氏の唱える実践知リーダーシップがどういうものかを物語る一例として、私は衝撃を受けました。平鍋氏はこのことを伝えたいというのが本書を執筆した動機と書いており、その衝撃も理解できます。
一般論としてはなにかしら定量的な論理や多数決などで決めがちな難しい問題を、形式知では決められないと早々に認め、全く非論理的な解決方法を簡潔に提示しています。データサイエンティストが読んだらぶっ飛んでしまうのではないでしょうか。このような決め方に反発する人もいると思います。私もどちらかと言えばそちら側の方です。
おそらくこの手法の成否はリーダーとメンバーの関係性に依るのではないかと私は思います。最終的には論理ではなく、このリーダーに任せようという主観的な判断がメンバーに広がっていって結論を見いだせるように私は受け取りました。したがって、合宿そのものはその装置の1つであって、最終的には人間関係が決め手であり、チームまたはプロジェクトがよりよい関係を築くには実践知といった概念が不可欠になってくるのでしょう。
実践知の話題は心理的安全性や認知心理学の知見ともいくつか合致するところがあるように思います。合宿という手段を用いなくても、スクラムの中でそれに近い状態を再現できるようにしていくことが今後のスクラムを発展させていくということにもつながるのではないかと私は思いました。
More Joel on Software
過去にアリエル・ネットワーク (以下アリエル) という会社で働いていました。これはもう10年前の話で、アリエルはオンプレミスで運用するパッケージベンダーの会社だったので、昨今の SaaS のようなプロダクト開発とは状況が大きく異なります。そういった時代背景の違いを考慮して本稿を読むように注意してください。
当時の課題管理や開発方法論が、その前もその後も、10社以上、十数の開発チームで働いた私の経験の中ではもっとも開発の生産性も開発体験 (Developer Experience) も優れたものでした。
- アリエル・ネットワークでアルバイトをしてきました - forest book
- アリエル・ネットワークに入社しました - forest book
- アリエル・ネットワークを退職しました - forest book
たまたま、というよりは、私がお願いして、当時の上司と雑談してみました。当時のアリエルの課題管理システムには、自社パッケージの開発に関する内容 (プロダクトの機能開発や不具合など) だけでなく、顧客からの問い合わせや開発者のTODOやシステム管理のメモなど、会社の多くの情報が入っていました。プロダクト開発に関するすべての情報はたった1つのプラットフォームに集約されていたので情報の一元管理という視点からみると非常に強力なプラクティスでした。
多くの情報が課題管理システムに入っているので、営業もコンサルタント (アリエルでは顧客と開発者の仲介役) も、マネージャーも開発者も、そのチケット上でコミュニケーションをしていました。最近だと、チャットツールで他チームや他部署の人たちとコミュニケーションを取ることが多いと思いますが、アリエルでは課題管理システム上のチケットで行われていました。当時も Skype のグループチャットはあったものの、課題管理システムがコミュニケーションのメインで Skype はアナウンスなど補足的な用途でした。
そんな話題を上司としていたとき、あのやり方は Joel on Software に由来するのだと教えてもらいました。具体的には次の記事です (この記事は本書には含まれてなかった) 。
そんなきっかけで、私が Joel on Software に興味をもち、本書を読んでみた次第です。本書は2000年代に書かれた内容を出版したものなので、いまとなっては古典のような内容も多いです。とくに特定の技術について言及している内容は、当時の状況ではそうみられていたんだなとか、歴史的な読みものとして理解することも多いでしょう。本稿ではなるべくいまでも通用しそうな内容に絞って紹介することにします。私はいまマネジメントに関心があるのでその内容が多くなります。
第2章 優れた開発者を見つけるには
基本的に転職市場には優れた開発者がいないという前提を述べた後、次の方法を提案しています。
こちらから出向く
- ホットな新技術のカンファレンスに出かけて廊下をぶらぶらして会う人に声をかける
- 優秀そうな人をみかけたらスカウトする
自分のコミュニティを作る
- 似た考えをもつ優秀な開発者のコミュニティを会社の周りに作り上げる
- できればうまくいくが、コミュニティを作るのがとても難しい
これらはいまでも採用活動の一環として行われているようにみえます。最後のコミュニティを作るというのは、多くの会社がテックブログを書いていて、読者となる開発者の興味・関心を集めようとしているのがもう少し簡単な施策かなと思います。
またリファラル採用について、著者はそれほどこの採用方式を信用していないと述べています。
- 優秀な社員が優秀な開発者の友だちをもっているのは事実だが、優秀じゃない友だちもたくさんもっている
- 不採用になると友人関係にヒビが入るから本当の友だちを紹介しようとしない
- 最初の採用プロセスをパスする程度で新規採用のソースとしては最も弱いもの
- あくまで通常の採用プロセスをすべて通過するかどうかを判断基準にしている
リファラル採用よりも自社の採用プロセスを重視していることが伺えます。リファラルによって採用のバーが変わらないという点が大事なのかなと私は理解しました。
第3章 開発者観察ガイド
同僚はどんな人たちか？
著者がマイクロソフト社からもってきた採用ルールに、自分たちが付け加えたルールが次になります。
嫌なやつでないこと
アリエルの CTO もたしか飲み会のときに「アリエルの開発には嫌な人がいない」が仰っていた気がします。私も辞めるときにそのことを意図的に書いているので間違いないです。
開発者の視点からみたとき、一緒に働いている同僚に嫌な人がいなくて、同僚の技術スキルが高いというのが魅力的です。
昨今ではコンプライアンス対策からハラスメントを禁止する風潮もあり、若い人にとっては嫌な人がいないのが当たり前の職場しか経験していないかもしれません。それはよいことだと思います。いまは、技術スキルが高くて優秀な嫌な人になるのが難しい属性になっているように私は思います。それは技術の発展に伴う多様化・複雑化が要因の1つではないかと考えます。
2000年代はまだ1人の開発者がその事業部やチームがやっている技術の大半を把握しているといったことが、いまよりは可能でした。嫌な人だけど、技術スキルが高いから誰も文句言えないといった人が職場にちらほらいた気がします。
いまは技術の要素が多岐に渡り、それぞれが専門化・分業化したことでその事業部やチームがやっている業務すべてに熟達するのが難しくなっています。特定分野の技術スキルが高くても、他チームと協調したりお願いしたりすることが昔より増えました。結果として、嫌な人は活躍できなくなってしまい、そういう態度を取るデメリットの方が大きく、採用時点でも嫌な人特性を排除することを重視するようになり、いまでは淘汰されてしまったのではないかと私は思います。
いまは逆に、心理的安全性の文脈で、同僚に適切な厳しい指摘をするのが難しくなってしまった雰囲気はありますが。
心理的安全性は本来、思ったことを言える環境という意味な気がするが、一方で何も言えないというのは、なんかおかしいなと思ったり...知らんけど
— ヒデ・グク (@OgawaHideyuki) 2021年10月9日
誤解を招く表現だったので補足します。本来の心理的安全性の文脈では、同僚同士で適切な厳しい指摘をし合える関係のことを指します。しかし、それはお互いの信頼関係が前提になっています。そうじゃない状況において相手を尊重し、信頼関係を築いていくことから始めるでしょう。問題なのはそれがずっと続いてしまい、そのまま、ぬるま湯のチームが出来上がってしまうことです。メンバーが誰も厳しいことを言わないチームは永遠に問題ばかりをエスカレーションして、ビジネスの問題解決力に劣ったチームになってしまいます。
独立性と自律性
この考え方は、会社や組織、チームによっても解釈が変わってきそうな気がします。著者は優秀な開発者を次のように扱うべきだと述べています。
基本的に、頭の良い人を雇おうとするなら、彼らがその能力を仕事に適用できるようにしてやる必要がある。マネージャはアドバイスできるし、自由にそうしてかまわないが、その「アドバイス」が命令と受け取られないよう、細心の注意を払う必要がある。
(中略)
開発者は自らの能力によって雇われ、専門家として遇され、その専門領域に関しては決断させてもらえることを望んでいるものだ。
先日、上司と雑談したときも、課題管理システムの他者が担当者のチケットにコメントすると若い人は「命令」と受け取ってしまうのであまりしないようにしているといった話しを聞きました。チームで相談したり議論したりすることは良いことだと思いますが、なにかを決断するとき、その担当開発者が決められるようになっているか。みなさんの組織ではどうでしょうか。
政治がないこと
プログラミングの世界は非常に公正で、非常に厳格に秩序立てられている。そもそもプログラミングの世界に入ってくる人がそうする理由は、多くの場合、公正で、秩序があり、厳格に能力主義で、議論は単純に 正しいほうが勝つ ような場所にいたいと思うからなのだ。
プログラマが「政治」について文句を言うとき、それが正確に意味していることは、技術面よりも個人的な考えが重視されているということだ。
これも営業やビジネス部門がめちゃくちゃな機能や納期を要求してくるといったことは減ってきて、開発者が目の前の課題に集中しやすいようになってきたのではないかと、私の周りではそう思えます。しかし、業界や業種に依るのかもしれません。
プログラマが気にしないもの
彼らはお金を気にかけない。あなたが別なことでひどいことをしない限りは。
誤解のないよう、著者はプログラマの給与を低くしてかまわないということを主張していません。前述した通り、プログラマは公正さを気にかけるので、業務や能力に応じた適正な給与でないと怒りを覚えると補足しています。そのため、本節の内容は適正な給与を支払った上での前提であることに注意してください。
給与よりも業務内容や職場環境の居心地の良さを優先するので、給与の多寡は優先順位が低いことを理解しておく必要性を説いています。もう1つ、興味深かったのは、プログラマがこれまで不満を述べていなかった給与に言及するようになったら、その本音は給与ではなく、やっている仕事に不満をもっているという兆候であると述べています。要はやりたくない仕事をする代わりに見合う対価がほしいといった理屈だそうです。
さらっと書いてあったのですが、ソフトウェア会社の経営者は考慮しておくとよさそうに思えました。
第7章 一体化マネジメント法
著者の知っているマネジメント方法として3つあげています。
- 指揮統制マネジメント法 (軍隊のようなやり方)
- 入門経済学マネジメント法 (経済合理性を重視したやり方)
- 一体化マネジメント法
前の2つもそれぞれ章を割いて説明していますが、本稿では省略します。著者は自分の会社で一体化マネジメント法と呼ぶマネジメントのスタイルを取っているようです。いま聞くと、よく知られたプラクティスが背景に思い浮かぶ人も多いと思います。著者の名誉のために言及しておくと、この記事が書かれたのは2006年8月10日です。
入門経済学マネジメント法でやっちゃいけないマネジメントとして、内発的動機づけを外発的動機づけに置き換えてはいけないと強調されています。例えば、プログラマが自分からやりたいと考え、自律的に行動して改善した行動に報酬を支払うといったインセンティブを与えることです。これは 過剰正当化効果 と呼ばれるそうです。
余談ですが、最近、メタ認知に関する認知心理学の入門書を読みました。この本の中でも動機づけは次のような順番になるのがよいと書かれています。
- やる気のない段階 → 外発的動機づけ段階 → 内発的動機づけ段階
内発的動機づけによる行動に報酬を与えると、内発的動機づけを外発的動機づけに置き換えてしまい、外発的動機づけは内発的動機づけよりもずっと弱い動機になるので意欲を失わせてしまうことにつながるというわけです。その入門書では副作用のない安全な報酬として、ことばで褒めることを紹介しています。ことばで褒めても動機づけは置き換わらないことが知られています。但し、能力を褒めると失敗できないとプレッシャーになってしまう人もいるので、成果そのものを褒めるようにした方がよいそうです。
著者の言う、一体化マネジメント法は、この内発的動機づけを最大限発揮できるよう、社員の自律的に行動した結果が組織の目標につながるようにマネジメントの工夫をしているということでしょう。そのための施策として著者は次の2つをあげています。
- 昼食を同僚と共にする
- みんなに情報を渡す
後者は「情報の透明性」について言っていて、ホラクラシーやティール組織を成功させる要素の1つにもなっています。私の周りでは、比較的、小規模な組織では原則すべての情報を社員に開示することがプラクティスとして浸透している気がします。意図的にしろ、そうでないにしろ、情報の非対称性は組織の理不尽を増幅してしまうと組織論の本で読んだこともあります。これについてはあまり説明の必要はないでしょう。
前者の同僚と昼食を共にするというのどうでしょうか。私も過去に働いてきた会社では、だいたい同僚と一緒に昼食をとっていました。いま思い返すと、昼食を共にしていた上長や同僚と業務で対立したことがないことに気付きました。私は理屈の通らない業務やマネジメントにはクレームする方だったので、何度か上長と業務で険悪になってしまったこともあります。しかし、一緒に昼食をとっていた上長と険悪になったことは1度もありません。もしかしたら私の性格や考え方を上長が汲んでくれて、私が不満に感じないようなマネジメントをしてくれていたのかもしれません。
これもたまたまかもしれませんが、一緒に昼食を共にしていた同僚とは会社を辞めてからも繋がっていてやり取りしたりすることが多いです。昼食を共にしているうちに仲良くなるのか、仲が良いから昼食を共にするのか、どちらが真であっても、昼食を共にすることが悪い結果をもたらすことはないように私は経験から思います。意識したことはなかったのですが、本章を読んでいて、そういえばと気付いた次第です。
当然、著者もこのマネジメント法は難しく、うまくやるにはある種の深い対人スキルも要求されると述べています。そして、多くの職場では、場当たり的な、日により人により変わる「何でもあり」の方法でマネジメントされているという言葉で締め括っています。大企業では同じ会社でもマネージャーによってマネジメントが大きく異なるのが容易に想像できます。
第10章 コンピュータサイエンスの学生へのアドバイス
いくつかあるアドバイスの中で私が関心をもったもののみを紹介します。
卒業するまでに文章の書き方を学ぶこと
最も大きな権力や影響力をもつプログラマは、明確に、説得力をもって、やすやすと書き、話せる人間だ。
まぁまぁのプログラマと優れたプログラマの間にある違いは、アイデアについてコミュニケートできるかどうかという点にある。他の人を説得することで、彼らは力を得るのだ。
日記やウェブログをつけはじめるといい。書けば書くほど、書くのは楽になる。そして書くのが楽になれば、もっとたくさん書けるようになるという、プラスのサイクルができる。
私はいま「書くこと」そのものを再考しています。再考というほど、過去にちゃんと考えたことがあったのか問われると曖昧です。しかし、意識的に書く機会を設け、書く時間を割いて何かを考えるようにしています。あるとき、生産性の低い開発チームをみていて、ふと思ったことがあります。
よいプロダクトはよい開発文化から生まれる。よい開発文化は書くことから醸成されていくのではないか？
私は、いくつかの会社やチームで課題管理システムの利用を推奨し、日々のやっていることをチケットに書くことを促してきました。そして、自然に課題管理システムを使いこなす開発者が半分ぐらいしかいないという現実をみてきました。ここでは書かない人たちの理由は追求しませんが、情報の一元化や情報共有の文脈から書くことのメリットは大きいです。情報の非対称性が組織にとって弊害があることを多くの人が実感しているはずです。それでも書かない人たちはいるのです。
経験則では、書かない人たちと技術の多寡は相関がありません。そして、いま思い返すと、書かない人たちはチームで孤立しがちになります。これは周りが避けているわけではなく、その人は何をしているのか、何を考えているのかわからないので必然的に協働する機会が減り、結果として接する距離が縮まらないせいではないかと思います。
口頭と文章によるコミュニケーションでは次の特性があります。
- 口頭: 同期的で複雑ではない内容に対して数人程度でしか成り立たない
- 文章: 非同期でも可能で、複雑な内容も不特定多数へ伝えられる
つまり、口頭によるコミュニケーションコストはとても高いということです。そのため、チームのメンバー間で毎日やっていることや業務で考えていることを口頭で双方向に共有することは現実的にできません。例えば、それを課題管理システムのチケットにコメントとして書き込むのであれば、それぞれのメンバーの余裕のあるときに読めるのです。無論、読むかどうかはメンバー次第ですが。
その日々の積み重ねが中長期で開発の生産性をあげたり、チームの協調性を高めていくのに役立ちます。そのためにはメンバーが自律的に書ける必要があります。
もう1つ書くことのメリットをあげてみます。
後藤貴子の米国ハイテク事情 は Alan Kay 氏へのインタビューの内容です。その中で次のことを発言しています。
過去1世紀の電子技術のほとんどは退行的だ。というのは電子技術の多くは書くことよりオーラルコミュニケーションを奨励するからだ。昔、人々に読み書きを強いた多くのものは今は存在しない。楽しみのために読まなければ、恐らく必要になったときには読む鍛錬が足りていないだろう。書くこともどんどん不要になっている。将来はもっと、コンピュータが、“学ばないこと”の言い訳になるかもしれない。米国の多くの学校は、子供がGoogleで何かを見つけコピーすると、それで学んでいると思っている。しかし私は、子供がそれについての作文を書かない限り学んだことにならないと主張している。作文は思考を組織化する。単に博物館の展示物を集めるだけではない。しかしほとんどの学校はその違いを分からない。
氏は「作文を書かない限り学んだことにならない」と主張しています。書くことは記憶の定着とも関連するので学びの質を高めるように読めます。もし学んだことを自分の言葉で書けないのだとしたら、その内容について理解が欠けていることを自身で容易に判断できます。
これは私自身への戒めとして、このブログのアーカイブ数をみると、2009年から年間の記事数が減っていっていることがわかります。この理由の1つに、勤めていた企業のテックブログや他のプラットフォームで記事を書いたりしていたこともあげられますが、近年、私は書くことを軽視している傾向がありました。学びが減っているのと怠惰になっていることの両方あると考えています。
卒業するまでにミクロ経済学を学ぶこと
ミクロ経済学はビジネスで重要な理論すべての基礎となっている。需要と供給とか、競争優位とか、NPV とか割り引きとか限界効能について知らなければ、ビジネスの仕組みが全然理解できないからだ。
マクロ経済学は、当たっているよりもはずれていることの方が多い。スキップしてよい。
私自身、いま会社の経営も考えたりするので経済の基本的なことをもっと昔に学んでおくべきだったと振り返っています。著者によるとミクロ経済学より先の経済学はどんどん悪くなっていくのでやらなくてよいとのことです。本節を読んで入門本を読んでみようと思いました。後述する第34章でソフトウェアの価格づけを考察するときにミクロ経済学の用語も出てきます。
仕事がみんなインドに行ってしまうと心配するのをやめること
第1にビジネスの現在の流行に基づいて職を選択するというのはばかげている。第2に、仮にすべてのプログラミングの職がインドや中国に行ったとしても、プログラミングというのは、ビジネスプロセスエンジニアリングになる。第3に、これは信じてもらいたいのだが、非常に優れたプログラマというのはアメリカでもインドでもすごく不足している。
オフショア開発 - Wikipedia によると、1970-1980年代ぐらいにオフショア開発という移転が始まったそうです。2000年代はオフショア開発する企業が増えてきて、先進国でプログラマーの仕事がなくなるのではないか？という話題もあったように私も思います。しかし、いまはすべての業界の会社がソフトウェアを活用するようになった結果、プログラマの需要はまだまだ衰える様子はみられません。日本においても当面、プログラミングのお仕事は売り手市場になるのではないでしょうか。
第15章 ユーザビリティがすべてではない
そこには (少なくともユーザビリティのプロには) 恐ろしい一片の真実があった: 人々が本当に欲する何か本当にすごいことをやるアプリケーションであれば、無惨なほど使いにくかったとしてもヒットしてしまうのだ。そして世界で最も簡単に使えるアプリケーションであっても、みんなが望むことを何もしないのであれば失敗することになる。
多くの場合、ユーザビリティは実際オプショナルだということだ。
著者の会社は課題管理システムを開発しているので業務アプリケーションに近いパッケージベンダーになります。時代が大きく異なるので当時は見た目や操作性よりも機能の方が重要視されたように私も思います。バックエンドの機能がビジネスの差別化に直結していました。
ちなみにユーザービリティとユーザー体験 (UX) とは別の概念であると次の記事で説明されています。ユーザビリティはソフトウェア側の視点からの、特定のユーザーや用途において使いやすいことを指しているそうです。
ユーザビリティは「モノが持つ品質的特性」（実用的品質）であり、UXは「人が体験する感性的品質」であると言えます。
本章で著者が言及しているのは、ソフトウェアデザインの次の段階で、ユーザーインターフェースを正しく作ったら、ソーシャルインターフェースのデザインの方が重要であると言及しています。当時はソーシャルインターフェースのデザインについて系統だった学問はなく、新しい分野なので試行錯誤しているように読めました。
FogBugz では多くのデザイン上の決定が、1人で使っても有用であるようになされている。そしてチームの他のメンバにもだんだんと広まっていくのを促すようにデザインされた機能がたくさん組み込まれている。
FogBugz (課題管理システム) の顧客で、バグトラッキングシステムを全然使っていなかった顧客に FogBugz を導入して常用するようになった事例が紹介されていて、利用者がチームで仕事をするやり方が変わったことによると説明されています。ここでいうソーシャルインターフェースというのは、SNS のソーシャルではなく、チームのメンバー同士が協調する上で必要な機能やデザインを指しているように思います。
当時から10年以上経ってチームで協調して使うソフトウェアは進化したのでしょうか。私からみて課題管理システムに限って言えば、大きな変革があったようにはあまりみえないですね。
第20章 エビデンスベーススケジューリング (EBS)
途中まではアジャイル開発で言うところのベロシティを計測して、その値から見積もりの精度を上げる話しであろうと読み進めていました。課題を小さいタスクに分割し、個々のタスクの見積もりと実際の作業時間から速度を算出します。見積もりが正確であれば、速度は 1.0 に近付きます。例えば、見積もりより2倍の時間を要すれば、速度は 0.5 となります。見積もりと実際の作業時間がずれるのはよくあることなので速度の値がバラけることになります。ここでおもしろかったのが、速度をランダム値として、実際にかかる作業時間をモンテカルロシミュレーションで複数生成して、多少のズレがあってもどのぐらいの範囲の日程で終わりそうかの分布を確率的に求めていくというシミュレーション手法です。
スクラムなどでは次のスプリントで何ができるか、その達成に全力を尽くすというスタイルなのでスプリントを5回やれば何ができているかということは分かりません。著者の提案する EBS はちょっと先の未来を開発者が勘と経験で見積もるより信頼できる予測をモンテカルロシミュレーションで算出するといったものです。私は課題管理システムでこういった機能をみたことがありませんでした。プロジェクト管理の文脈ではいくつか記事が検索にヒットするのでこういった機能があるのですね。見積もりの精度が悪いチームではやってみるとおもしろいかもしれません。
その他、個人的に納得感が高いものが自分のスケジュールに次のためのバッファを用意しておくと述べているところです。
- 新しい機能のアイディア
- 競合への対応
- インテグレーション (他メンバーの作ったものと協調して動くようにする作業)
- デバッグのための時間
- ユーザビリティテスト (および、その結果を製品に反映させる)
- ベータテスト
もしかしたらパッケージベンダーだからこそ可能なバッファなのかもしれませんが、アリエルでも近いスケジュール管理をしていました。イテレーションにおける Feature freeze までの1.5ヶ月に対して必須機能を開発者に割り振り、それらを実装すれば、個々の開発者が (バックログから) 好みの新機能を自由に実装してよいというやり方でした。私の場合、2-3個の必須機能、2-3個の好みの機能、合計で5個前後ぐらいの新機能を実装していました。私の記憶では、3年間で開発チームが必須機能を期間内に実装できなかったのは1つだけだった気がします。つまり3年間でプロダクトとしての機能開発の遅れはほとんどなかったと言えます。
精度の悪い見積もりがためにスケジュールの引き直しを何度もやっているプロジェクトをみかけたことがあります。スケジュール調整のための管理コストもかかってしまうので適切なバッファの持ち方もマネージャーやプログラマに一定の経験を要求するのかもしれません。
第27章 バイオニックオフィス
開発チームのマネージャーはいいオフィス空間がどういうものであるかを知っているが、マネージャーの権限でオフィスを引っ越ししたり改装したりできるものではないのでどうすることもできないものだと考えていると述べられています。著者は経営者なので自分の会社のオフィス空間をいいものにしたいというこだわりが伺える内容でおもしろいです。建築士にブリーフ (ソフトウェア開発で言う要件) として提示した内容が次になります。
- 1人1人にちゃんとドアの付いた個室があることが絶対条件
- コンセントがたくさん必要、プログラマが新しいおもちゃを机の上でつなげられる
- データケーブル (電話、LAN、ケーブルテレビ、警報、その他) を床を這い回らずにつなげられる
- ペアプログラミングが可能であること (L字型の大きい机を用意する)
- 遠くのものを眺めて目を休められるよう窓を設け、ディスプレイを壁に向かって置いてはいけない
- オフィスはそこで時を過ごすのが快適なたまり場のような場所であるべき
現代ではデータケーブルの接続インターフェースはなくてもよさそうですね。一定規模以上の従業員が働く会社では個室は幹部のみでしょうし、最近は社員間の協調を優先してオープンなオフィス環境を重視しているイメージが私にはあります。たまり場について、日本人は休憩用途でたまたまそこにいる人たちとコミュニケーションを取ったりすることはあまりないように思います。それよりも、ちょっとした打ち合わせや小さい勉強会に、普段の会議室とは違う、ややくつろいだ雰囲気で行えるスペースがあるとよいように私は思います。
私はいまシェアオフィスを借りています。ドアのある個室で8割ほど満足しているのですが、2年近く使っていて、唯一不満だと思い始めたのがまさに窓がないことでした。窓がないと1日の時間の経過、天候の変化、季節の移り変わりに疎くなります。直接、業務には関係ありませんが、外から受ける刺激が少なく自然な気分転換にならないように感じるようになりました。次に引っ越しするときは窓のある部屋を借りようと考えています。
フィリップ・グリーンスパンは、はっきりこう言っている。「会社の成功は、ある部分までプログラマが実質オフィスに暮らすようになるかどうかにかかっている。オフィスが平均的なプログラマの家よりも素敵な場所である必要がある。そうする方法は2つある。すごくみすぼらしいアパートに住んでいるプログラマを雇うというのが1つで、もう1つは素敵なオフィスを作るかということだ」
学生時代に研究室に入り浸って過ごした人たちには馴染みがあるかもしれません。過去、私もオフィスに泊まり込みで働いたこともあったので環境がよいに越したことはないというのは理解できます。私は自宅で仕事をしない人だったので、自宅とオフィスの目的を明確にわけていました。一方で IT 業界ではリモートワークが普及しつつあり、私の周りではオフィスよりも自宅環境が快適で満足しているという友だちも少なからずいます。自宅とオフィスのどちらがよいか、個人差があるかもしれません。
第32章 心に残るカスタマーサービスへの7ステップ
ソフトウェア開発の本でカスタマーサービスについて言及している内容を私はあまり読んだことがないように思います。それだけで希少価値があるように感じますし、実際に内容も示唆を与えるものでした。
問題はすべて2通りの方法で解決する
ホコリを払うように勧める
- ユーザーに回答するときに言い方を工夫して相手を怒らせないようにするという話し
- キーボードが効かないというユーザーに「ちゃんとつながっていますか？」と聞くと、ユーザーは確認もせずにバカにしているように感じる
- 「接点のゴミがついていると接続が弱くなる。接点のゴミを吹き払ってからつなぎ直してもらえますか？」というと、自然にやってもらえる
顧客をファンにする
- 顧客が問題を抱えている時、それを解決してあげたなら、彼らは始めから問題なんかなかった場合よりもいっそう満足を覚える
- 私も過去にトラブル対応をして逆に顧客の信頼を得たことがあるのでこの考え方は支持します、ピンチはチャンス
- 顧客が問題を抱えている時、それを解決してあげたなら、彼らは始めから問題なんかなかった場合よりもいっそう満足を覚える
責めを負う
- 鍵のトラブルで「私のミスです。」と行った鍵前屋に対して著者は怒りの感情がなくなってしまった話し
- ミスを認めない姿勢や態度そのものにさらに腹が立つという話しに読める
言いにくい言葉を覚えておく
- 顧客からクレームがあったときの返す大事な言葉は覚えておいて、それを言う練習をしておく
- 例えば「私のミスです」、「申し訳ありませんでした。お代は結構です。」
- 心から言っていることが伝わる必要がある。だから練習をするのだ
操り人形の練習する
- 怒れる顧客の相手を感情的に切り抜ける唯一の方法は、彼らが怒っている相手は自分ではないのだということを認識することだ
- 怒られているのは自分という自然人ではなく、会社という法人だと置き換える
- 操り人形のように個人の感傷をなくして謝罪すればいいという話しに読める
- 私の経験では、過去に謝り方の下手な人は自分は悪くないと顔に出ていて顧客を逆に怒らせてしまう人がいた
- 当事者意識をなくさずに操り人形になるスキルは言うほど簡単ではないかもしれない
強欲ではどこにもたどりつけない
- 求人広告サービスで質問なしの90日間返金保証をしてうまくいった話しに読める
- クレジットカードで支払ったときに払い戻しに応じないとき、銀行に電話して払い戻させることができる。これをチャージバックと呼び、事業者側はチャージバック手数料を支払うことになる、たびたび起きると手数料が引き上げられることになる
- 顧客が払い戻しを要求したら結果は同じになるのでもめずにすぐ払い戻しに応じるという話しに読める
本章の内容はいまでも通用するように私は受け取りました。カスタマーサービスの問い合わせ内容を重視して、スキルの高い人を配置し、さらにその人たちのキャリアパスも用意しておくということをできているパッケージベンダーは少ないのではないでしょうか。テクニカルサポートは習熟するとキャリアアップのために辞めてしまうイメージが私にはあります。
第34章 ラクダとおもちゃのアヒル
パッケージソフトウェアの価格付けについてミクロ経済学の考え方を応用しながら論理的に考察していきます。著者がソフトウェア開発者も学んだ方がよいと助言するミクロ経済学の勉強にもなりますし、ユーモアのあるの文章で楽しめました。どういった属性の顧客にいくらで販売するのが利益を最大化できるかを次の手法を使って求めていきます。
- 需要曲線
- 消費者余剰
- セグメント化
- 正味現在価値 (NPV)
最終的にどういう価格付けになるのか。これから読む方のために秘密にしておきます。こういった考察を読むことで、ビジネスにおける数字の見方や考え方を学ぶ必要性も理解でき、経済学への興味へとつながるように思いました。本章を読み終えた後に気になって次の記事も読みました。
所感
一通り読んで、私が関心をもった箇所を書き出してみました。その過程でアリエルのよかったところが本書でも言及されている内容だったりして思い返すことも多々ありました。2000年代に書かれた本でも、学ぶべきところや時間が経ってもあまり変化がない内容もあります。私にとっては温故知新ということばがぴったり当てはまる内容でした。
エラスティックリーダーシップ――自己組織化チームの育て方
最近出版された本ではありませんが、じっくり読む機会があったので簡単に所感をまとめてみます。購入したのは約1年前でした。それから積ん読していて、読み始めてからも時間のあるときに少しずつ読み進めて1ヶ月ぐらいかかりました。
買っておくといつか読む可能性がある。
読まないよりは少しでも読んだほうがよい。
一通り読めてよかった。
。。。
そんな所感は誰も期待してないでしょうから、少し振り返りながら私にとって関心のある内容をまとめてみます。私はリーダーや管理職に就いたことがないので本当の意味では、本書のリーダーの難しさや悩み、葛藤などは理解できていないと思います。
一方でメンバーの立場でリーダーを補佐してきたことや、いくつかの企業やチームでそれぞれのリーダーに接してきたこと、自分にとって働きやすかったリーダーなど、やはり、本書を読んで共感できるところは多々あります。
そして、自分がリーダーとして振る舞うことが求められるとき、やはり、本書は人それぞれのリーダー観を獲得するヒントにもなるでしょう。
チームの自己組織化
本書でのキーワードの1つに「自己組織化」があります。聞いたことがあるような単語ですが、そもそも自己組織化とはどういう意味だろう？と思ったときに私は答えられませんでした。
パターン形成の仕組みを理解するために、物理学、化学、生物学、情報科学などに広く用いられる概念。無秩序状態の系において、外部からの制御なしに秩序状態が自律的に形成されることをいう。ここで「外部からの制御なしに」とは、外部から細かく手を加えてパターンを作成するような作用がないということを意味する。
いくつか説明の記事を読んで、コトバンクの説明が私にはわかりやすかったです。科学の分野にまたがって用いられる概念であるという。系をシステム、秩序をパターンやルールのように読み替えるとエンジニアリングの概念とも合致しそうな雰囲気はします。
それではチームの自己組織化とはどういう意味でしょうか。ちょうどその記事がありました。
この記事によると、アジャイルソフトウェア開発宣言 (Agile Manufesto) の一節に次の文言が出てきます。
最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。
記事内では、単なる個人の集まりとしての共同作業グループと、その宣言で意図された自己組織化チームとの違いを、様々な特徴、モデル、要素などから説明しています。私がざっと読んだだけでは理解できそうにありません。私の中ではまだ言語化できていないので、ここではチームの自己組織化とは尊いものだとしておきましょう。そのぐらいの安易で、なんら初学者の理解を助けない表現で留めておきます。そして、チームの自己組織化は、簡単には成らず、成ったとしても永遠に続くものではなく、メンバーが相互に作用して目的を果たしていく形態のようです。
リーダーシップのスタイルとチームのフェーズ
チームには異なるリーダーシップを必要とするフェーズ／状態がある。本書では次の3つの関係を図解で表しています。
- 指揮官が必要なとき: サバイバルフェーズ
- コーチが必要なとき: 学習フェーズ
- ファシリテーターが必要なとき: 自己組織化フェーズ
図では「モード」と記載されているが「フェーズ」とも呼ぶと説明されている箇所があるのでモードとフェーズは同じ意味で捉えてよさそうです。
サバイバルフェーズ
本書では、チームに学習する時間が十分にない状態を「サバイバル」と定義している。リーダーはメンバーが学ぶ時間をとれるよう、サバイバルモードから抜け出すための戦略を練る必要がある。そういった状態では指揮統制型のリーダーシップが有効である。
学習フェーズ
十分なゆとり時間があり、その時間を使って学習や検証を行っているなら「学習」フェーズにいると言える。このフェーズにおけるリーダーは、メンバーに対して自分たちの問題を自力で解決できるように教え、挑戦させ、自己組織化チームへと育てることが目標となる。そのため、コーチ型のリーダーが必要になる。
自己組織化フェーズ
リーダー／メンバーともに何の心配もなく、携帯電話やパソコンの電源を切り、数日間仕事を放置できる状態であれば、自己組織化フェーズと言える。このフェーズにおけるリーダーは、ファシリテーターとなってその状態を維持すること、そして現状を処理するチームの能力に注意を払うことが目標となる。
フェーズ間の移動
チームの状態によってはリーダーシップが異なること、チームに発生するイベント、例えば、新人がチームに入ってくる、目標の期限を変更するといったイベントが発生したときにフェーズが移動することもありえると説明されている。
スタイルやフェーズに関する所感
リーダーシップのスタイルとフェーズにも「自己組織化」というキーワードが出てきます。他のフェーズと比べ、リーダーは自由時間をもち、メンバーは自分たちで意思決定を行い、チーム自身で問題解決できるという、尊い状態であることが伺えます。
本書では、それぞれのフェーズについて章を設けてより詳細に説明されています。その中で私が印象に残った5章の学習することを学ぶについて取り上げてみます。
学習することを学ぶ
学習モードとは、チームがゆとり時間を持ち、それを新しいスキルの集中的訓練にあてている状態と定義できる。
本書を読んで私がもっとも関心をもったことの1つに学習には「谷」があると説明されていたことでした。
進捗には2つのタイプがある。
- 学習の進みが遅く安定している高原。
- 学習が大きく飛躍している峰。
さらに引用します。
私が思うに、学習の真の力というのは、次の単純な事実を悟ることだ。谷は最終的には終わって、あなたは新しい知識と共に飛躍する ことになる。このことを知ってい れば、不可能だと思うことだって、やり始めることができる。
そして、自分が谷に直面している可能性があるのは次のような状況にあると言う。
- 面目や尊厳、お金や友人を失う可能性があるために、一歩を踏み出すのに勇気がいる。
- 違和感を感じている。
- 自分を変えるかもしれないこと、あるいは、自分の世界や仕事、関わる人々への理解の仕方を変えそうなことがある（が、これを事前に知るのは難しい）。
- 新しいスキルを獲得しなくてはならない。
真の学習は谷によってもたらされる。谷底は不快で、時折イライラさせられる。メンバーが楽しくなさそうなら、彼らをうまく安全地帯の外に出せている良い兆候かもしれない。メンバーから抵抗を感じたなら、それはあなたがうまくチームを操縦できている証拠だ。
余談ですが、先日、寺田さんの podcast に出演した際にも本書の学習の谷について少し話しました。
私はずっとバックエンドの開発に携わってきて、最近フロントエンドの開発に携わりました。その過程で自分の培ってきた経験や知識と明らかに考え方の異なる設計やアプローチに対して、大きな違和感を受けつつ、それを言語化できない自分自身のもどかしさに葛藤や逡巡を覚えました。
決して自身の経験や知識を正しいと主張して新たな開発スタイルを否定する気持ちはありませんでした。しかし、設計とはトレードオフを強いることもあるため、この設計ではこういうケースに対応できないとか、拡張するときにこういったデメリットがあるといった、大小あれども自分の価値観との違いをうまく言語化できずにもがいていました。
手伝い始めた当初はアンラーニングも大事だろうと考え、盲目的に同僚の意見や設計を受け入れながら開発を進めました。同僚はあまり設計やアーキテクチャを言語化せず、意図も説明しなかったので、違和感があっても指摘するのが面倒になって放置するといったときもありました。
そのときの楽しくない気持ち、自身の行動に自信がもてない気持ち、そういった感情の振れ幅とモチベーション管理をうまくできなくて自己嫌悪に陥ったときもありました。思い起こせば、これまでも新しいことに挑戦するときは同じような、うまくいかなくて挫折感を味わうというのは何度も経験していました。しかし、それを「学習の谷」という概念では捉えていませんでした。本書で谷という概念を知ることで少し救われたように私は感じました。
真の学習というのは、以前より生産性が落ちたり、違和感を感じて不快なものであると考えることにより、いくらか新しい挑戦への不安を軽減する術になるように私は思います。
第7章「メンバーを成長させる」にもリーダーがメンバーを指導するとき、メンバーにとって真の成長機会であるかを見分ける項目として、学習の谷にあることを確認するときの項目と同様に次をあげている。
- 恐怖があること
- 初期の不快感や不満があること
影響パターン
メンバーの主要な振る舞いを変えるように影響を与えたい場合の6つの影響力について次の説明があります。当初、この影響力のマトリクスの説明を読んだときはあまり内容を理解できていませんでした。
本書の後半は、様々なリーダーが1章ずつエッセイを綴っています。そのエッセイに対して著者が分析してコメントを書いています。そのコメントを読んでいると、このエッセイは影響パターンのこれとそれを示唆しているといった説明が度々でてきます。
より具体的な事例を影響パターンに分類することで私の理解が深まった気がします。
現場リーダーのための 6 つの原則 平鍋 健児
過去に平鍋さんの記事をいくつも読んで私は大きな影響を受けています。その中で「名前づけ」の節がおもしろかったので紹介します。
気づきによって得た知識に名前をつけましょう。
問題を解決する方法には、「ブレークダウンによる方法」（Divide and Conquer）と、もう一つ、「名前づけによる方法」（Name and Conquer）があります。
プログラミングで最も難しいことの1つに、やはり名前づけがよく言われます。私は初期の開発時にしょっちゅう名前を変えます。
名前を知ったことで人間の認知に影響が出たエピソードとして「ヨシュアツリーの原則」も紹介されています。
まとめ
読者の経験や立場によって本書の興味や関心をもつ箇所は変わるでしょう。また時間が経って、自分の状態の変化によっても本書から受け取る内容は変わるかもしれません。
さて、冒頭でチームの自己組織化とはなんぞや？という問いに、私は尊いという言葉で表現していました。本書を読むと、自己組織化とはこういった内容かなと、自分なりの解釈や理解が、読む前よりは進むように思います。そして、その解釈や理解に絶対というものもないように私は考えています。
私にとっての、チームの自己組織化というのは、チームが自律的に課題を解決していくための責任と権限をもち、それが開発文化として十分に根付いており、リーダーもメンバーもその役割を担う上での価値観が共有されている状態であると考えます。
