元記事
自分のコードが批判される不安
一般にエンジニアは、自分の仕事の進行状況(コードの品質や生産性)を他人に見られ、評価されることを恐れます。
あるソースコード管理システムをGoogleが開発した際に、次のようなissueをもらっていました。
「特定のブランチを非表示にする機能を Google Code の Subversion に付与してもらえますか?」
「最初は世界に隠されていて、準備ができたときに公開されるオープンソース プロジェクトを作成できるようにすることはできますか?」
「こんにちは、コードをすべてゼロから書き直したいのですが、履歴をすべて消去してもらえますか?」
これらには「自分のコードや仕事の質を見極められる(誤解される)不安」が見て取れると思います。
-
自分のコードは完璧な部分だけ見て欲しい
-
完成されていないコードをみて自分を判断して欲しくない
-
昔の自分が書いたクソコードを見ないで欲しい
エンジニアにおける「自分のコードを隠そうとする傾向」は次の「天才神話」によるものだと思われます。
エンジニアの天才神話
エンジニアをやっているなら次の名前は聞いたことがあると思います。
- Linus Torvalds
Linus は自分で Linux を書きました
- Guido Van Rossum
プログラミング言語Pythonの生みの親
- Bill Gates
Microsoft CEO
彼らは言わずもがな天才ではありますが、一つ誤解があるように思われます。
それは全てのエンジニアリングを一人でやってきたと言う誤解です。
例えばLinux Torvaldsがやったことは
-
Linuxの小さいカーネルを作る
-
メールでばら撒く
-
Linuxコミュニティをコントロールする
以上です。
Linuxは、初期のカーネルよりも数百倍大きく、何千人もの賢い人々によって開発されましたが、Linusの本当の功績は、これらの人々を導き、彼らの仕事を調整することでした。
Linus一人の功績ではなく、何千ものエンジニアの結晶がLinuxであるわけです。
Guido Van Rossumも、Bill Gatesもおんなじです。
確かに、Guido Van RossumはPythonの最初のバージョンを書きましたが、他の何百人もの人々が、彼の書いたコードから、機能、バグ修正などを行い貢献してきたのです。
特にバグは個人の範囲で見つけるのは相当難しいはずです。
なぜならバグ（特に潜在バグ）は自分の意識でコントロールせずに発生してしまうものであり、第三者から見て初めて欠陥が見えるのです。
バグを個人で見つけるためにはこの無意識をコントロールし、自分が認知していない世界を見つける必要がありますが、それよりは他人に指摘してもらった方が簡単でしょう。
ですが、例え個人の功績のみに依存しないことをわかっていたとしても、人間は個人を偶像化し崇拝することをやめません。
科学的な根拠は不明ですが、多くの人間は、偶像を見つけて崇拝する本能を持っています。
そしてこの天才神話は、一つの悪い傾向を生み出してしまうのです。
それは、同僚が自分の間違いを見て、コードの作成者が天才ではないことを知ることになる不安。
つまるところ、冒頭で話した通り自分が書き始めたばかりのコードを共有することを恐れです
コードを共有することの不安の結果:一人でコードを書く
「自分が書き始めたばかりのコードを共有することを恐れ」とは
プログラマーの間で非常に一般的な感情であり、自然な反応は次の通りです。
自分の部屋に引きこもってひたすらコードと睨めっこし、誰にもあなたの愚かさを見られないようにすることです。完成したら、あなたの傑作を発表するチャンスがあると考えて、コードが完璧になるまでひた隠しにしている。
これは全く悪いことだけとは限りませんが、どちらかというとデメリットの方が多いようです。
一人でコードを書くことのデメリット
一人でコードを書くと、正しいことをやっているかどうか把握する手段がない
ソフトウェア開発は非常に知的な作業であり、深い集中力と一人の時間を必要とする場合があります。
ですがその一人作業のみに成果物が依存する場合、その成果物が正しい道を進んでいるかどうかをどうやって知るのでしょうか?
これは自分自身にも一つ経験があります。
あるプロジェクト(インテリア商品の企画プロセスを改善するソフトウェア）で、当時私はプロトタイプを作成していました。
そのプロジェクトには開発メンバーが私を含め二人いましたが、
大部分の機能を閉めるフロント側を私が担当し、結果としてバックエンド側を担当した先輩はどのように動いているか把握していませんでした。ある時私はどうしてもそのプロジェクトを途中で抜けなければなりませんでしたが、
その時に私が担当するプロトタイプに大きな間違い（Reactを採用するべきところをbackboneを採用）をしていました。その後、プロジェクトは「プロトタイプをそのまま本番環境で動かす」という方向転換をしたため、
backbone.jsが書ける数少ないエンジニアを探しに行く必要が出たのです。
-
当時もし、一人で作業せずにバックエンド側の人にも確認してくれれば、
-
あるいは、Reactに精通するエンジニアが他にいれば
-
上司に「どんな技術を採用しているか」を説明する機会があれば
backbone.jsを選ばずにReactを選択した未来もあり得たかもしれません。
一人の作業は車輪の再発明を引き起こす
何かを始める前に、同期や同僚に「どんなことをしているよ」と必ず話してみましょう。
プロジェクト初期の段階で根本的な設計ミスを犯しがちです。
場合によっては、車輪を再発明するリスクがあります。
（私はtalendという仕組みを知らなかったおかげで、CSVとpowershellとSQLLoaderを使ったアナログな仕組みを採用する羽目になりました...。）
早い段階でより多くのフィードバックを求めるほど、このリスクは低くなります。
正しいことに取り組んでいること、正しく行っていること、そしてそれが以前に行われたことがないことを確認する必要があります。
（最新のコンピューターや科学技術を用いてついに車輪を発明した博士のイラストです。）
一人の作業はリスク分散できない：バスファクター
今あなたがプロジェクトに参加しているとして、プロジェクトの知識とノウハウはどの程度分散していますか?
もしチームメンバーがバスに引かれた場合、どれくらいの損害が出るのでしょうか？
覚えておいてください: チームメンバーは文字通りバスにひかれるわけではありませんが、その他の予測不可能なライフイベントは依然として発生します。
誰かが結婚したり、引っ越したり、会社を辞めたり、病気の親戚の世話をするために休暇を取ったりするかもしれません。
少なくとも私自身は過去に一度だけ、結婚を機にプロジェクトから外れることになりました。
その後の引き継ぎはわずか2週間しか取れず、幸いにも同僚が優秀だったおかげでプロジェクトは延命されましたが
もしあの時、プロジェクトを引き継ぐ者が何も知らない初心者だったらと思うと今でもゾッとします...。
少なくとも、
-
各責任領域のプライマリ所有者とセカンダリ所有者に加えて、
-
適切なドキュメントを作成することで、
プロジェクトの成功を将来にわたって保証し、プロジェクトのバスファクターを向上させることができます。
（同時に3人バスに轢かれない限りはプロジェクトはなんとか延命されるの図）
ソースコードは多くみられるのが良い
ほとんどのエンジニアは、「多くの目がすべてのバグを浅くする」という言葉を知っていますが、より適切なバージョンは、「多くの目が、プロジェクトに関連性を持ち、順調に進んでいることを確認する」かもしれません。
洞窟で働く人々が目覚めると、最初のビジョンは完成していたかもしれませんが、世界は変化し彼らのプロジェクトは意味をなさなくなりました。
IT業界のキャッチアップを全て一人で行うなんて到底不可能です。
目まぐるしく環境が変化するITプロジェクトで価値を出し続けるには、一人の目ではなく多くの人間による洞察が必要不可欠なのです。
要するに、隠すな
つまり「隠れる」ということは、言い換えると一人で作業することは、
他の人と作業するよりも本質的にリスクが高いということです。
誰かがあなたのアイデアを盗んだり、自分は賢くないと思ったりすることを恐れているかもしれませんが、
間違ったことに苦労して膨大な時間を浪費することについてもっと心配する必要があります.
チームで働く人のための、マインドセット
簡単に言えば、信頼、尊敬、謙虚さが大事になるわけですが、具体的な行動レベルに落とすと次のようになります。
- スタイルの相互尊重（自分のやり方を押し付けないこと！）
チームや大規模な組織で効果的に働きたい場合は、自分の好みの作業スタイルと他の人の作業スタイルに注意してください
- コミュニケーションコストを払うこと（会話をめんどくさがるな！）
あなたとあなたのチームがコミュニケーションや対人対立に費やす時間を認めてください。
自分自身や他の人の性格や働き方を理解するための小さな投資は、生産性の向上に大いに役立ちます。
- あいまいさ(不安定さ)の中で繁栄する（完璧ではなく80%で満足)
環境が絶えず変化している場合でも、相反するメッセージや指示に対処し、コンセンサスを構築し、問題に対して前進することができます。
- 価値観のフィードバック（コードレビューは前向きに）
成果物に対しては、謙虚にフィードバックを受け取り、適切にフィードバックし、フィードバックが個人 (およびチーム) の開発にとってどれほど価値があるかを理解しています。
- 現状維持に争う（変化を好みましょ）
野心的な目標を設定し、他人からの抵抗や惰性があってもそれを追求することができます。
- ユーザーを第一に考える（どんなに対立しても、ここは同じ）
Google の製品のユーザーに共感と敬意を払い、ユーザーの最善の利益になる行動を追求します。
- チームを大事にする
同僚への共感と敬意を持ち、求められなくても彼らを助けるために積極的に働き、チームの結束を高めます。
- 正しいことをする
自分のすることすべてに強い倫理観を持っています。チームと製品の整合性を保護するために、困難または不都合な決定を喜んで下します。
特に個人と個人で仕事をする場合、自分と他人の違いについてばかり意識してしまうという傾向が人間にあると思います。
そうではなく、「共通点は何か？」を問うこともチームをより強固にすると思います。
特にユーザーを大切にしたいという気持ちは同じであることはせめて忘れないようにしたいですね。
最後に
良いと思ったらGoodボタンかフォローお願いします。
コメントもくれば返信しますし、マージリクエストは喜んで受け付けます。
備考
title:レビュー嫌いなエンジニアに向けて
description:特に個人と個人で仕事をする場合、自分と他人の違いについてばかり意識してしまうという傾向が人間にあると思います。そうではなく、「共通点は何か？」を問うこともチームをより強固にすると思います。特にユーザーを大切にしたいという気持ちは同じであることはせめて忘れないようにしたいですね。