ソフトウェア・インテグリティ

 

オープンソースコミュニティから学ぶ;リモートで働かなければならなくなった人たちへ

生産的なリモートチームワークは可能なのです。オープンソースコミュニティでは長い間リモートチームワークを実践しています。ということで、この記事ではリモートで作業する人たちのためのヒントをいくつか紹介します。

私たちは、何百万人もの従業員をオフィスから追い出して、自宅からより安全に作業できるようにする「課題」を痛いほど理解しています。

しかし、降って湧いたリモートワークへの移行は、計画を立てる余裕のないまま唐突に対処しなければならなくなった「作業」であり、解決の糸口のない混乱を伴っています。さらに、新しい仕事のスタイルに対して不慣れであること、ストレスが伴うことが大きな問題です。特に、学校に通っていない年齢の子供がいる人にとっては頭が痛いことだらけです。例えば、「今、私は2つの仕事があります。教師であり、牧師でもあるのです。平日も週末もなく、そして子供の世話もしなければならなくなったのです。」

また、リモートワークに移行することで、オフィスで共同作業を行っていたソフトウェア開発者が突然孤立することになります。 確かに、VPNで必要なリソースへのアクセスはありますが、同じ部屋にいるわけではありません。

とはいえ、開発が壊滅的な状況に陥ってしまうという意味ではありません。課題を克服するための参照可能な事例があります。オープンソースが広く利用されるようになって以来、オープンソースソフトウェア開発者達はずっとリモートで作業しているのですから。

オープンソースと従来の開発チームを比べてみる

ほとんどの場合、オープンソースソフトウェアの開発者は他の開発者と会ったことがありません。彼らはお互いをよく知りません。彼らはお互いを見たり話したりすることも殆どないかもしれません。また、彼らの多くは、異なる国々のさまざまな地域にいるだけでなく、多くの場合、彼らは同じ言語を母国語としていませんし、場合によっては多くの開発者が使う「英語」を話さないこともあります。

それでも、驚くべき効率で連携し、優れた品質のプログラムコードを生み出します。たとえば、Linuxオペレーティングシステムはオープンソースプロジェクトとして始まり、今日までオープンソースのままです。オープンソースソフトウェアは、現在稼働しているほぼすべてのアプリケーション、ネットワーク、システムの一部です。多くの場合、コードベースのコードの半分以上(時には90%以上)を占めています。

そうです、生産的なリモートでのチームワークは可能なのです。

しかしながら、オープンソース開発が企業の世界とまったく同じであると言っているのではありません。オープンソースは「コミュニティ」であり、企業ではありません。参加するのは基本的にボランティアであり、有給の従業員ではありません。コミュニティには階層ありますが、監督者は「上司」ではなく「コミュニティリーダー」というのが適切でしょう。

しかし、リモートで作業するための新しいアイデアを必要としている従来の開発チームとそのマネージャーは、オープンソースの世界のリモートワークから多くのことを学ぶことができます。それについての本さえあります—最も人気のあるものの1つは、Ubuntuの元コミュニティマネージャーであるJono BaconによるThe Art of Communityです。

オープンソースのリーダーからリモートで作業するためのヒントを学ぶ

シノプシスのサイバーセキュリティリサーチセンター(CyRC)のプリンシパル・ストラテジストであるTim Mackeyは、オープンソースコミュニティのリモートワークについて良く知っています。彼は会社で働いている間、オープンソースプロジェクトのコミュニティリーダーでしたし、今もメンバーとして貢献しています。彼はリモートで働き、キャリアの大半でリモートチームの管理をしてきたのです。

また、彼は経験から、「リモート」によってチームが「分断」される必要はないことを知っています。しかし、そのためにはチームメンバーの意識、努力、協力が必要です。彼はオープンソースコミュニティが物理的なコミュニケーションの不足を補う方法のいくつかを説明してくれました。

とにかく「コミュニケーション」あるのみ

「ともかく「コミュニケーション」あるのみ」というのは、家を購入する上で最も重要な要素として唱えられる「とにかく「場所」が最も重要」だという呪文のようにも聞こえます。

しかし、それはコミュニケーションが他のすべての基礎だからです。 もちろん、リモートで作業することは、物理的なオフィス環境とまったく同じではありません。 Mackeyが言うように、「誰かがあなたが取り組んでいることに関連する何かに取り組んでいる時、「このコードの意図していることが本当にわからない」と呟く時、頭が浮かび上がるのは「問題がある」ということです」

しかし、チームが大きすぎない限り(理想的には10人未満であるのが理想的ですが)

「実際には、質問すべき相手にSkypeでチャットすることができます。電話はすぐそばにあり、オフィスに居なければ解決しないといったことは無いはずです」と彼は言った。「コミュニケーションの問題を解決する方法はたくさんあります。必要な手段を見つけるだけでいいのです。」

回復力

回復力はコミュニケーションから生まれます。Mackeyが言うには、回復力はプロジェクトに関する「すべての問題を完全かつ透過的に伝える」ことから生まれるということです。

オープンソースプロジェクトの場合と同様に、「特別なことを知る必要のある特別な人は誰もいない」と彼は言います。「いつでも誰でもすべてを知ることができます。このレベルの平等主義によってメンバーの積極的な関与が行われるようになるのです。」

また、全員が積極的に関与することは、回復力の必須要素である「単一障害点(SPOF)がない」ことも意味します。 誰かが病気になったり、休暇に出かけたり、別の仕事に就いたりしても、1人の人がすべての制度的知識を持っているわけではないので、チームの構成に変更が生じても、プロジェクトに影響を与えることはありません。

「このことで、1人が何か秘密の知識を持っていることを心配する必要はなく、その1人が何らかの個人的な問題に対処しなければならないとき、たとえば高額な宝くじに当選したとしても、混乱することはありません」とMackeyは言いました。

「それはあなたに柔軟性を与えます。誰もが自分の人生にいくつかの側面を持っているでしょう。スキーをしたい人、サーフィンしたい人、寒さが嫌いな人、逆に寒いのが好きな人もいます。」

感情的で知的なフィードバック

感情的で知的なフィードバックは、良いコミュニケーションからも流れますが、電子メールやテキストには通常「トーン」がないため、リモートで作業しているチームの間でははるかに扱いにくい場合があります。顔の表情、スピーチの音量、および対面式のコミュニケーションに存在するジェスチャーなどの身体的な手がかりは、文章に厳しいまたは非難のように見えるかもしれないコメントに多くの役立つニュアンスをもたらす可能性があります。

文化や言語の壁は、書面よりも対面で克服する方が簡単なことは言うまでもありません。別の国の別の言語を話す受信者がメモを受け取り、それをGoogle翻訳のようなものを通すことで、結果は予測できないことになりかねません。

「複数の言語を知っていて、それを試したことがあるなら、Google翻訳などの技術がとても良いこともあれば、ひどいこともあることを知っているでしょう」とMackeyは語った。彼はリモートワークの状況では、オープンソースの世界と同様、非常に正確な言語を使用してコメントを書くべきだと強調しています。

「誰かにあなたの文章の調子について不平を言われたことがあるなら、成功したオープンソースチームがどのようにしてコミュニケーションの問題を克服してきたのか、かなり早い段階で理解することができるかもしれません」と彼は言った。「国によっては、口調が母国語の重要な要素であり、あなたが望むよりも頻繁にあなたの意味を聞き逃してしまうかもしれないからです。」

一方で、フィードバックの感情的な要素が伝わることは、「士気を大いに高める」可能性があると語っています。

批判してはいけないものなどない

すべてのチームとプロジェクトには、物事がどのように行われるかを管理するプロセスが必要です。しかし、プロセスは物事を成し遂げるのを助けることであることに注意してください。Baconの本で述べられているように、プロセスは「目的を達成する手段である場合にのみ有用」なのです。

またはMackeyは次のように付け加えます。

「結局のところ、誰もがそれが何であるかを理解していること、それがなぜそうなのか、そしてある程度まで彼らが手を挙げて意見することができることを知っていることです。でしょ?」

また、オフィスからリモートワークへの移行において、特定の作業を完了できないことが明らかな場合、プロセスは修正が必要です。

Mackeyによると、よくある例は、ITや法務部門が「私たちのソースコードを保護するために、社外からはアクセスできないこの特別なネットワーク上でのみコードをコミットできる」というセキュリティポリシーを課したシナリオです。

以前は完全に理にかなっているかもしれませんが、誰もオフィスにいないときは機能しません。「プロセスは生きた実体である必要があります。「しかし、これは私たちがいつもやってきた方法です」などと思考停止してはいけません。」と彼は言いました。

その理由の1つは、チームの誰かが、個人の判断で、目の前の仕事を終わらせるためだけに回避策を考え出す可能性があります。そのような回避策はセキュリティポリシーの範囲外であるため、いわゆる「シャドウIT」ということになります。

「つまり、割り当てられた作業を行う際に、在宅で働くすべての人の現実や課題を想定して設計されていないため、皆がすべてのプロセスを回避してしまうという状況が生まれてもいいはずなどないのです。」と。

繰り返します。コミュニケーションはリモートで作業するための鍵です

繰り返しますが、コミュニケーションはリモートワーク実現の鍵です。リモート開発チームが作業を行うことを不可能にすることなく、ソースコードのセキュリティを維持する方法を理解することがはるかに優れているのは明らかです。

これらすべて、決め手になるのは「とにかく「コミュニケーション」あるのみ」ということなのです。

もちろん、慣れるには少し時間がかかります。最初はうまくいかないこともあるでしょう。しかし、オープンソースコミュニティにできていることが、企業などの組織にできない理由などないはずです。

この記事の原文は Taylor Armerding によって Wednesday, April 15th, 2020 に投稿されました。

 

この著者によるその他の情報