How do you get programmers to join your project? 翻訳
筆者・・・Jeremy Garcia
LinuxQuestion.orgというLinuxのユーザーコミュニティの設立者。
プログラマーをプロジェクトに引き込む方法
私がとある言語で書かれたプロジェクトを引き継いだとしよう。開始当初のプログラマーは去っていて、誰も保守しようとはしていなかった。
今はGit hubにアップロードされ、GPLv3のライセンスを持つ。
この状況から助けてくれる一人もしくはそれ以上のプログラマーをどうやって見つけられるのだろうか？
過去僕は２、３人のプログラマーを見つけた。しかし、どれだけ手を尽くしても誰も仕事が上手く行く前に去ってしまった。
答え
この質問は非常に多かった。だからThe Queueに質問を寄せてくれたみんなに感謝したい。プログラマーはとても需要が高いし、彼ら自身多くのサイドプロジェクトを持ってることが多い、だから君のプロジェクトに参加させるのは一種の挑戦といってもいい。
僕から君に捧げる最初の提案は、参加してもらうに当たって現実的な期待を持つことだ。プロジェクトに高い関心を持っているか、仕事上参加が必須となるプログラマーを見つける以外では、すんなり保守担当になる人物を見つけるのは不可能に近い。保守担当としての献心性と責任感は重視すべきである。
とは言っても、君のプロジェクトを見て興味を持った人が常に活躍するエースになってもらうための確かな秘訣はいくつかある。
プロジェクト紹介とメッセージ
プロジェクトの分かりやすい概要は非常に重要だ
-
何をするのか
-
誰のために
-
違いは何か
-
いつどこで使われるのか
一見シンプルだが、プロジェクトに長く関わっている者にとってはつい忘れがちなものだ。しかも外からだと見えにくい。
多くのプロジェクト、特に小規模のものはこれらの情報を見逃しがちで、非常に見つけづらく、そしてあったとしても分かりづらい。結果として多くのプロジェクト、特に小規模のものはこれらを見落としてしまう。GitHubを使っているのなら、README.mdがこの概要の置き場だ。
(GitHub外のREADMEも同じ用途で使える)。概要は簡潔で、かつ君がプロジェクトにとって重要だと思う情報が明確かつ理路整然と表現できるほどの長さであるべきだ。
貢献してもらうためのガイドライン
君のプロジェクトに実際に参加するにあたっての情報を含んだCONTRIBUTINGファイルを作るべきだ(もしGitHubを使っているならCONTRIBUTING.mdでもいい)。その中には環境構築、ビルドの具体的な手順、コーディング規約やフォーマット(もしあれば)、テストの情報、パッチの実行手順、プルリクとレビュー手順、その他一緒に作業するために必要と考えられるもの全てを含める。GitHubはそういう情報の置き場として最適だ。保守者の観点からすると、そういった資料はいかに上手く一緒に働けるか簡潔に伝えられるべきである。そして作業者としては、その資料を軽くチェックすることで彼らの成果は保守者のガイドラインに沿ったものであると確認できる。
明瞭ではっきりと定義された”取り掛かり”
新しくメンバーになりえる人材が最初にぶつかる壁の一つは、いつプロジェクトに参画すべきか、である。単に今上がっている課題を担当してもらうのは簡単かもしれないが、取り掛かりとして小さい単位ではっきりと定義されたタスク表は新しいメンバーとの衝突を減らしてくれる。
行動するきっかけを持たせること。小さなUIの問題、翻訳、ちょっとした修正は新しいメンバーにこのプロジェクトが自分に合うかどうか見極めるために、君たちのコードベースに慣れてもらうきっかけを与える。君達のコードに慣れてもらった後、次のステップとして小さなパッチをリリースするのは悪くない。
コード品質とドキュメント
プログラマーはいくらか興味を持てるプロジェクトに参加する傾向がある。
それとは別に、彼らに快く協力してもらう必須条件は素晴らしいコードベースだ。高品質のドキュメントがある設計が良いコードは他のメンバーが素早く作業する助けになり、作業者が途中で”君のコードに慣れる”ことができずに離れてしまうのを防げる。
最初の作業をサポートする
プロジェクトが小さくなるほど、クラッキングでパッチの実行が失敗するのは容易い。
新しいメンバーにとって、返事が無いこと、たとえコードは素晴らしくとも忙しいスケジュールで返せない場合でもその場合彼らは今後も手伝ってくれる可能性は低いだろう。加えて、彼らのコード全てが基準の品質に達していないとして、コードを却下する君の断り方は彼らがプロジェクトに入るかどうかを決定づける。モチベーションが高く、メンバーになりうる人を見つけ、指導できる作業者が既にプロジェクトにいるというのは非常に重要だ。もし陰険で冷たい態度をとれば、貢献者は品質の高いコードを提供しないだろう。それどころか違うプロジェクトに行ってしまうだろう。
オンラインだけで探さない
GitHubのような素晴らしいツールが使えると、将来の貢献者はどこでも見つけられるというのを忘れがちだ。カンファレンス、地域のミートアップ、他の勉強会といった選択肢は良いリソースになりえるこれらを忘れるべきでないし、見落としてはならない。
実際のところ新しい、もしくは小さいプロジェクトのためのメンバーを見つけるというのは簡単ではない。しかし、これまで挙げた秘訣は非常に重要である。参加してもらうための明確なガイドライン、手始めの簡単なタスク、そして友好的かつ建設的なフィードバックループはメンバーを成長させ、将来継続的な貢献者になるための助けになるだろう。
Full Cycle Developers at Netflix - Operate What You Build : Net Flix tech blog 翻訳
こちらの記事の翻訳。ところどころ誤訳があると思うので指摘、提案大歓迎。
翻訳元に使われている画像は載せていません。()付きで表していますので元記事をご覧ください
Full Cycle Developers at Netflix — Operate What You Build
ネットフリックスのフルサイクル開発者- 効果的なビルドの運用
2012年ーネットフリックスのサービス運用は非常に厄介なものであった。デプロイはまるで濡れた砂の上を歩くようで、カナリアテストは機能の検証というより、耐久性の証明のためだった。(一週間のカナリアで問題がなければ、プッシュだ！みたいにね)。問題の調査は擦り付け合いが続き、終わったと思っても原因の究明は困難だった。全ての問題が我々は変革を必要としているということを示していた。
2018年現在、ネットフリックスは会員数125万を誇り一日に140万時間超利用されている。私たちはエンジニアチームの為開発、運用環境に随分と投資してきた。それと同時にサービスをより良く構築そして運用するために多くのアプローチも試してきた。そこで我々が実践し今やネットフリックス内に根付きつつあるアプローチを長所と短所を交えて紹介したいと思う。この情報共有から我々の経緯を学び、もっと良い取り組みを生み出してくれることを願う。
これまでの遍歴
最新技術チームはネットフリックスのストリーミングを可能にするAWSサービスの最初のレイヤーを担っている。
以前はデプロイ、運用、ソフトウェアのライフサイクルを支援する運用チームとSREの専門家が在籍していた。
新しい機能をリリースするということは評価基準、アラート、容量の問題を考慮しつつ運用チームと連携し、彼らの運用、デプロイのためのコードに対処するということだ。より効率的な実行コード、パートナー支援のために、運用チームは新機能とバグ修正のための研修が必要だった。
別個に運用チームを持つ最も良い点は事が上手く進んでいる時に開発チームからの厄介事が減ることだった。
しかし事がうまく運ばなくなると、コストは増大した。開発と運用/SREチーム間の情報共有は減り、一方でバグ修正と質問の回答のやり取りは増えていった。
運用チームがリリースの変更を詳細まで把握していないため、デプロイの際のトラブルは常に原因究明、解決共に時間を必要とした。開発とリリース時のコードのギャップは今より大きく、リリースは日単位というより週単位であった。パフォーマンスと遅延の増加に対する意識の低さを指摘した運用チームの意見は人づてでしか開発に届いていなかった。
この状況を改善するために、最新技術チームは混成した運営方法を試した。それは開発チーム自身が必要な時にコードをプッシュし、
たとえ営業時間外であっても問題の対処と要望に応えることに彼ら自身が責任を持つというものである。この試みは開発におけるフィードバックと改善のサイクルを向上させた。部分的に責任を持つことは一つの問題を生んだ。開発チームが主体となり、彼ら自身が仕事のプロセスを管理する様になったにも関わらず、運用チーム内のリリースのベテランが主導権を握っていたのである。開発は運用チームの為に日々の仕事をこなしており、
そうならないために自動化を推進するといったことは困難だった。
より良い道を探すため、僕たちは原点に戻って根源を定義した。何を達成したいのか？なぜ自分たちは上手くいっていないのか？
ソフトウェアライフサイクル
ソフトウェアライフサイクルの目的は"時間対効果"を最適化することだ。アイデアを実際に動く生産物に効率的に変換し消費者に届ける。
ご存知の通り、ソフトウェアの開発、運用というものは全てのプロセスの責任を負う。
(開発ライフサイクルの構成要素)
そこで僕たちは各プロセスの責任を分割した。その一方で、各プロセスはそれぞれ異なる人、役割が担当することとなる。
(開発ライフサイクルの各専門家)
ライフサイクル全体で見れば非効率性を生み出すかもしれないが、この専門分野に特化した役割は各部門の生産性を向上させた。
彼らは特定の領域内の専門性を伸ばし、その分野で本当に必要とされている事を最適化した。
彼らはパズルの特定のピースだけを簡単に見つけることができるようになったのだ。
しかし、ソフトウェアは価値あるものを消費者に届けるためにライフサイクルを必要とする。全体を各分野に切り分けて専門家を持つことは
全体の進捗を遅らせる自己中心さを生み出すことになる。かといって専門家たちを一つのチームに纏めると今度は異なる分野間でのコミュニケーションからボトルネックが発生し、フィードバックループを妨げる。
自分がビルドしたものに責任を持つ
自分たちのアプローチを見直すため、僕たちは開発の基本的な流れから閃きを得ようとした。
自己中心さを打破し、全体のライフサイクルで責任を共有するように努めればこのフィードバックループを改善できるはずだ。
(開発の原則に則った開発ライフサイクル)
”自分がビルドしたものに責任を持つ”。このルールはチームに開発から、運用、保守まで責任を持たせることによって開発の原則として働くようになる。責任を他のチームではなく各チーム自身に持たせることで直接フィードバックループを回し、全てのタスクを自分達の立場だけで考えられる。運用関係の悩みで苦しんでいるチームはコード、設計の変更からくる悩みを解消できることに勇気づけられるはずだ。彼らは両方のフェーズの責任と義務を負うからだ。チームは開発、パフォーマンス、容量計画、アラートの対処、他部署との連携など全て自分たち自身で担当する。
開発ツールによるスケーリング
開発ライフサイクル全体に当事者意識を持つと、ソフトウェア開発者に対する期待感が飛躍的に増える。開発のニーズを満たし自動化するツールはこれを補ってくれる。例えば、もし開発がサービスのロールバックの管理を任された場合、ロールバックに役に立つだけでなく問題を監視し検知する高機能なツールが求められる。
ネットフリックスは全開発チームが抱える問題を解決する汎用的なツールとインフラを開発する目的とともに中央管理チーム群(クラウド、性能信頼性エンジニアリング、開発ツール等)を立ち上げた。これらのチームは彼らの専門的な知識を利用可能な開発ツールに変換する強力な支援チームだ。例を挙げよう。
(専門家が作る再利用可能なツール群)
これらのツールを自由に使えることによって、開発は開発の分野の問題を解決することだけに集中できる。
新たなツールが必要になれば、中央管理チームはそのニーズが複数の開発チームにとって役に立つか査定する。もしそうであれば、協力するための形としてツールが出来上がる。時々共通化するために投資するにはあまりに局所的なケースの場合もある。その場合は開発チームにとって本当に解決する価値があるかどうか彼ら自身が判断する。
そういった問題を開発側か中央管理側かで調整することはこのアプローチの厄介な問題のうちの一つだ。我々の経験から言って、開発の要望を満たす画期的な方法を見つけるメリットは複数のグループが複数の解決策を見つけてしまうリスクに見合う価値がある。
コミュニケーションと協力は成功のカギだ。需要と、いかにその需要を複数のチームに役立つよう共通的に整えられるか、まずそこから始めることで僕たちはネットフリックス開発チームのための投資対効果を高めてきた。
フルサイクル開発者
これらのアイディアを組み合わせることで、僕たちは一つのモデルにたどり着いた。そこでは高機能な開発ツールを携えた開発チームが設計、開発、テスト、デプロイ、運用、保守全てのライフサイクルの責任を持つ。
(責任を持ったフルサイクル開発者)
フルサイクル開発者はライフサイクル全てのプロセスに対して博識かつ、有能であることが求められる。これはネットフリックスに入社したばかりの多くの人にとって、今まであまり経験したことのない分野を強化しなければならないという意味を持つ。だから僕たちはこれらの知識と技術を身につけてもらうため短期集中コース等のトレーニングを実施している。知識は必要だが、それだけでは不十分だ。簡単に使えるデプロイ管理ツール(Spinnaker等)や監視ツール(Atlas等)は効果的な主体的フルサイクル開発では必須となる。
フルサイクル開発者は開発ライフサイクル全てにエンジニアの教練を当てはめる。開発者の観点から問題を評価しこんな感じに質問する。「どうやってこのシステムに必要なものを自動化できるかな？」「どんなヘルプツールが僕が対処しなくてもパートナーの質問に答えてくれるかな？」人よりもシステムに焦点を当て、手動よりも自動化を促進することでチームは一段階レベルアップできる。
フルサイクル開発に移行するためには考え方の変化が必要になる。開発者の中には設計、開発、テストが価値を生み出すために最も大事な工程だと考えている者もいる。この考えは運用を面倒なものだと認識し、彼らの”本当の仕事”に戻るために運用、保守支援に短絡的な解決策を出させてしまう原因になりうる。しかしフルサイクル開発者の”本当の仕事”はライフサイクル内の全ての問題解決に彼らのソフトウェア開発の専門性を活用することである。全てのフルサイクル開発者はSWEとして,SDETとして、SREとして考え行動すべきである。ある時はビジネス的な問題を解決するソフトウェアを開発し、ある時はそのソフトのテストケースを書く、またある時はそのシステムの運用を自動化する。
この手法ではチームは価値を届けることを約束し、そのためのコストを意識しなければならない。チームにはビルドとデプロイ、本番環境での問題の対処、パ―トナーの要望に応えられるだけの十分な環境が必要になる。時間は研修に充てられるべきだ。ツールは投資され、活用されるべきだ。パートナーシップはコンポーネントと解決策の再利用のため中央管理チームに管理されるべきだ。ライフサイクル全てのプロセスは計画、振り返りをされなければならない。アラート検知の自動化やパートナーに対するヘルプツール等の投資はビジネスプロジェクトに並ぶ最優先事項である。
適切な人員、優先順位付け、そしてパートナーがいればチームは自分たちがビルドしたものの運用についても上手くやっていけるだろう。逆に彼らなしでは高稼働が続いた末、燃え尽きてしまうだろう。
ネットフリックス外でこのモデルを受け入れてもらうためには各種に調整が求められる。君たちの開発チームが抱えるありがちな問題は似たようなものだー継続的に価値を届ける必要性から監視、観測性諸々だ。しかし多くの会社はネットフリックスのように中央管理チームを運用するための人員を持たない、もしくはネットフリックスが持つ複雑性を必要としていない。ネットフリックスのツールはほとんどがオープンソースで、しかもちょっと使ってみようと思わせるくらい魅力的だ。一方他のオープンソースやSaaSもあなたの会社のニーズを満たせるだろう。考え方を変えて、潜在的な価値を分析しコストに重きを置こう。自分がビルドしたものを評価して、複雑さをできるだけ少なくしていこう。
トレード・オフ
テクノロジー業界にはソフトウェア開発と運用の問題を解決する選択肢がいくつもある(世の中には幅広い形態の開発運用チームがあることを知るべきだ)。ここで説明したフルサイクルモデルはネットフリックスの一般的なスタイルだが、欠点もある。選ぶ前にモデルのトレード・オフを把握できればより成功する機会を得られる。
フルサイクルモデルでは、より広範囲の分野において主体性と、開発ツールを生かした効率性が求められる。広い分野に対応するためには多種多様なテクノロジーに対して好奇心と才能、両方持つことが必要になってくる。開発者の中には特定の分野で世界に通用するような専門家になることを目標にしており、また我々の業界もそういった人材を欲している。彼らにとって幅広い分野で責任と能力を求められることは時に居心地が悪く、やりがいを感じられないかもしれない。実際ネットフリックス内でもその類の人々は存在するが、私たちは彼らにこのモデルを受け入れてもらえるよう支援している。他の人たちがその役割を受け入れ、そして楽しんでいるように。
私たちのクラウドベースの開発運用経験の中で、フルサイクルに対応できる幅広さに価値を見出している開発者の効率が向上していく場面を目の当たりにしてきた。しかしこの幅広さは開発者の各分野における認知負荷を増大させる。さらにチームが一つの分野に集中していた時よりも、毎週タスクの優先順位の調整を行わなければならない。我々は開発者の中でデプロイ、運用、サポートを交代で担当するローテーションを組むことによってこれを軽減している。上手く行けば、集中的かつ流動的な仕事を行うゆとりが彼らの中で生まれる。上手く行かなければ、チームの誰かが心労を抱える、本番環境の問題のような重い問題に取り組まなければならなくなる。
ツールと自動化は専門範囲を拡大する上で助けになる。が、開発者の生産性と運用領域の問題をすべて解決できるツールなど存在しない。ネットフリックスには中央管理チームが公式にサポートしているツールと手法で固められた”舗装道路”がある。私たちは”舗装道路”の使用を強制しているわけではないが、これらの技術を使用している人々が使わない者たちより素晴らしい経験を得てもらうことで使用を推奨している。このアプローチの欠点は”全てのチームが全てのツールの全ての機能を最も重要なニーズを満たすために使う”という理想が達成不可能に近いという点だ。中央管理チームの運用の投資対効果を把握するには努力、連携、そして継続してこの手法を受け入れてもらうことが求められる。
結論
2012年から現在に至るまでの道は実験、検証、受け入れで溢れかえっていた。初期に私たちにより良いモデルを探す気にさせてくれたエッジ・エンジニアリングは現在も積極的にフル・サイクル開発に取り入れられている。開発者は日常的に素早く対応し、日単位で時間がかかっていたカナリアは数時間で終わるようになり、責任の押し付け合いよりも早く問題を調査し修正を加えるようになった。他のグループも似たような素晴らしい取り組みをしているかもしれない。しかし私たちは数あるアプローチを一つ一つ試して学びながらここまで来たことを自負している。私たちをさらに進化させてくれるような未来の需要が楽しみだ。
このモデルが実際にどうやって運用されているか興味がある？未来のためアプローチを進化させる探求作業に加わりたい？
なら僕たちと一緒に働いてみないか！
By Fhilip Fisher-Ogden, Greg Burrell and Dianne Marsh
