プロのエンジニアに必要なものとはなんだ？『Clean Coder』に学ぶ信頼獲得のメソッド【今こそ読み解きたい名著】

本書のサブタイトルにもある「プロフェッショナルプログラマ」を目指すには、どのような道をたどっていくべきでしょうか。

私は“プロフェッショナルと認められている” とは、周囲からの信頼が得られている状態だと思います。エンジニアとして信頼を得るためには、設計・実装などの技術力が必須です。しかしいくら高い技術を持っていても、それだけでは信頼は得られません。むしろ、コミュニケーションやセルフマネジメントなど、技術以外の面が信頼に大きく影響すると考えています。

本書でも技術面のみならず、コミュニケーション方法や時間の使い方といった信頼獲得につながる要素を解説しています。心がけだけでなく具体的なテクニックも紹介されているため、読んですぐに活用できるのです。

エンジニアは完璧を目指す責任がある

本書では、バグをゼロにすることは現実的ではないが、完璧を目指す責任があると説いています。

同じ間違いを何度も繰り返してはいけない。プロの道を究めていけば、間違いの割合は限りなくゼロに近づいていく。決してゼロになることはないが、ゼロに近づける責任があるのだ。

『Clean Coder プロフェッショナルプログラマへの道』p.37より

間違いの割合をゼロに近づけ、「プロの道を究めていく」には、失敗から学んでいくしかありません。なぜ、ここまで求道的になる必要があるのか。本書では、エンジニアはある大きな責任が前提として存在することを説いています。

とても恐ろしい責任だ。それは、エンジニアとして、マネージャが知らないシステムやプロジェクトの深い知識を持つということだ。知識を持てば、行動する責任が伴う。

『Clean Coder プロフェッショナルプログラマへの道』p.19より

ものづくりにおいて、開発・デプロイ・運用を担うのはエンジニアです。良いものを作り、プロジェクトを成功させるためには専門性を発揮するだけでなく、エンジニア自身がコミュニケーションを通してチームやプロジェクトに影響を与えていくことが必要です。

『Clean Coder』で押さえたいポイント

本書にはテスト駆動開発などの技術的な内容も含まれていますが、本稿では技術以外の面に注目し、以下の項目をピックアップしました。

• エンジニアはどのようにYES/NOを言えばいいのか
• 会議との付き合い方

特に若手のエンジニアは状況把握ができないばかりに、つい流されて無理にYESと言ってしまうことがあります。また、会議の多い現場に慣れてしまい、自分の時間管理が上達しないまま過ごしてしまう危険性があります。だからこそ、本書を参考にプロに近づく成長速度を高めていく必要があると、私は考えるのです。

エンジニアはどのようにYES/NOを言えばいいのか

目次の中でひと際目を引くのは第2章「ノー」と言うと第3章「イエスと言う」ではないでしょうか。

誰しも、日常の業務で当たり前のようにYES/NOというコミュニケーションをしていると思います。エンジニアが口にする「YESかNOか」は、周囲にどんな意味を与えるのでしょうか？ プロフェッショナルとしてどのようにYES/NOを使えばいいのか？といったことを考えてみます。

最善の成果を生むためにNOと言う

本書ではエンジニアのYES/NOコミュニケーションの例として、マネージャのマイクとエンジニアのポーラの会話が紹介されています。

以下の例は、みなさんの現場でも日々交わされているような会話ではないでしょうか。

マイク「ポーラ、明日までにログインページが必要なんだけど」
ポーラ「えっ！　明日ですか？　えーと、はい。やってみます」
マイク「よかった。ありがとう！」

『Clean Coder プロフェッショナルプログラマへの道』p.50より

この会話は対立もなく一見スムーズに見えますが、本書では「プロの行動ではない」と述べられています。なぜなら、このときポーラはログインページの準備が、明日までに間に合わないと分かっているのに伝えていなかったからです。一方マイクは「やってみます」を「明日までにすべて用意できると約束します」という意味で受け取っています。

この例のように、エンジニアが「無理かもしれないが、やってみる」と答えるとき、他のメンバーはコミットしたと受け取ってしまいがちです。相手の期待に応えたい、対立を避けたいという意図で「やってみる」と言ってしまうと、かえって事実が見えなくなり、混乱を招きます。一方、プロは「返答の要件定義」が明確です。

本書にある次の会話例を見てみましょう。

マイク「ポーラ、明日までにログインページが必要なんだけど」
ポーラ「ちょっと無理ですね。2週間はかかります」
（中略）
マイク（イライラして険しい表情で震えながら）「それはだめだよ。明日の顧客デモで、ログインページが動いているのを見せなきゃいけないんだから」
ポーラ「明日までにログインページのどの部分が動けばいいんですか？」
マイク「ログインページなんだぞ！　ログインに決まってるだろ」
ポーラ「ログインページのモックアップであれば、すでにあるのでお渡しできます。ただ、ユーザ名とパスワードのチェックはしていません。Eメール送信やパスワード再発行の機能もありません。トップに企業ニュースのバナーもありませんし、ヘルプボタンもホバーテキストも動きません。（中略）」
マイク「ログインはできるんだね？」
ポーラ「はい、ログインはできます」
マイク「素晴らしいよ、ポーラ。君は命の恩人だ！」

『Clean Coder プロフェッショナルプログラマへの道』p.50,51より

こちらの例ではマイクが感情的になり、2人が対立しているように見えます。しかし、2人はこの関係者にとって、この時点での最善の成果を目指すためのコミュニケーションがとれています。安易にYESと言うのでなく、ときにNOを使い、目的を見定めることがプロフェッショナルな対応なのです。

YESと言える方法を探す

無理な期限で仕事を依頼されたとき、品質を落として締切日に間に合わせようとしたことはないでしょうか。デッドラインを死守するためにテストを書かず、リファクタリングもせずに納品する、といった具合です。

本書では、これはプロとしての行動ではない、と述べています。

テストを書かなければ、もっと早くできることはない。リファクタリングをしなければ、もっと早くできることはない。リグレッションテストを実行しなければ、もっと早くできることはない。長年の経験から得た私の教訓からすると、規律を破ると遅くなる。

（中略）プロとして基準を守る責任がある。コードはテストしなければいけない。コードはクリーンにしなければいけない。システムの他の部分を破壊しないようにしなければいけない。

『Clean Coder プロフェッショナルプログラマへの道』p.72より

実際、手を抜いたから開発が早く完了した、ということは私の経験でもありません。手を抜くと問題が発生しやすくなるばかりか、終えた後の達成感もなく、仕事へのやりがいも下がってしまいます。

本書では、難題に対してただNOと言うのではなく、目標に近づく方法を見つけてYESと言うことがプロとしての振る舞い方だと述べます。最終目標へのコミットを約束できない場合でも、「ある部分まではYES」と言えるような、創造的な方法を懸命に探すことが重要なのです。

　できるかどうかわからないのであれば、その目標に近づく行動を約束しよう。できるかどうかをみつけることが約束になるのだ！
　例えば、リリース前に25個のバグを修正すると約束するのではなく（それが可能であったとしても）、その目標に近づくための3つの行動を約束する。

• 25個のバグを調査・再現する。
• バグを発見したQAの隣に座って、再現方法を確認する。
• 今週は時間が余ったら、できるだけバグを修正する。

『Clean Coder プロフェッショナルプログラマへの道』p.69より

良い方法を見つけて一歩ずつ進むことで、結果としてゴールにも近づくことができるでしょう。

会議との付き合い方

会議に時間が取られてしまい作業が進まない、と悩んでいる人は多いのではないでしょうか。 こうした悩みの前提に、「野放図な会議への参加」があると本書は指摘しています。

会議に誘う人が君の時間を管理してくれるわけではない。自分の時間を管理できるのは自分だけだ。会議への誘いを受けても、今の仕事にすぐに必要なのかを確認するまでは、受け入れてはいけない。

『Clean Coder プロフェッショナルプログラマへの道』p.132より

会議の主催者は、参加者の抱えているタスクや忙しさを把握しているわけではありません。そのため、必要なのは自分で時間を管理する意識を持つことです。すべての会議が悪いわけではありませんが、不要な会議は欠席して自分の時間を確保していくのが得策でしょう。

ときに「わからないことがあったら聞きたい」「一応その場にいてほしい」といった軽い理由で会議に呼ばれてしまうことがあります。本当に自分が出席する必要があるのか、自分がいないと成り立たない会議なのか、などを都度考えて判断するべきなのです。

なお、私の場合、不要な会議を回避するための方法として、日頃のコミュニケーションを重視しています。困っていることや進めたいことが周囲のメンバーとお互いに共有されていれば、日頃からアイデアは充実し、そもそも会議をする必要がなくなるのです。

一方マネージャならば、メンバーが会議に時間をとられすぎていないか注意する必要があります。本書でも、マネージャの役割の一つを以下のように定義しています。

マネージャの最も重要な仕事は、君を会議に参加させないことである。優れたマネージャであれば、君の時間のことを気にかけているはずだから、会議に参加しないことを擁護してくれるはずだ。

『Clean Coder プロフェッショナルプログラマへの道』p.133より

特に、断ることが苦手なメンバーには気を配る必要があります。「誘われたので断りづらい」というだけで会議に出席しているようであれば、時間の使い方を見直すサポートをしましょう。

会議が忌避される理由の一つに、「やたらと時間がかかる」という点が挙げられるでしょう。結論が出ずに会議が長引く、といった経験は誰もがお持ちでしょうが、その原因のひとつとして、事実の不足が挙げられます。

「5分で決着のつかない議論は、議論では決着がつかない」。時間がかかるというのは、双方とも明確な裏付けとなる根拠がないからだ。事実に基いているのではなく、宗教になっているのだ。

『Clean Coder プロフェッショナルプログラマへの道』p.135より

議論がヒートアップしたとしても、意見が事実に基づいていなければ結論には至りません。自身の主張のポイントを整理し、裏付けとなる事実を集めましょう。事実を元に決めれば、仮に自分と異なる主張が採用された場合も、一定の納得ができると思います。

また、「会議時間の管理」問題以前に、そもそも、会議を開く必要があるかどうかを考えねばなりません。

何かを進めること = 会議の開催 になってしまっている現場も多いはずです。残念ながら、会議以外にプロジェクトの進め方を知らない人もいます。

もちろん、会議を持ちかけるメンバーに悪気があるわけではないので、こちらからコミュニケーションし、会議を「健全に回避」していくことが必要だと思います。たとえば、チャットで議題を事前に聞き出して調査して返答すれば、会議自体が不要になるかもしれません。

締め切りのプレッシャーを低減するには

エンジニアであれば誰しもが、開発の締め切りに追われて、プレッシャーを感じた経験があると思います。プレッシャーそのものをなくすことはできませんが、なるべく減らしていきたいところです。そのために、本書ではまずは無理なコミットメントをしないことが大切だと述べられています。

達成できそうもない締め切りにコミットメントしないことが大切だ。ビジネスはリスクを排除したいので、常にコミットメントを求めてくる。我々は、リスクを定量化してビジネスに提示し、適切に管理できるようにしてあげなければいけない。それを妨げるような非現実的なコミットメントは、ビジネスと開発者の両方に危害を加えることになる。

『Clean Coder プロフェッショナルプログラマへの道』p.155より

非現実的なコミットメントは、事業やプロダクトに重大なリスクを発生させます。リリースの遅れによってプロモーションプランの変更を余儀なくされたり、不完全なプロダクトを提供するとユーザが離れたりしてしまうからです。 では、いわゆる「無理めなスケジュール」を提示された場合、それを突っぱねるのが、正しい対応でしょうか。否。目的を達成するために最大限の努力をすることこそ、プロフェッショナルの姿勢なのです。

我々に相談せずに、ビジネスが顧客と約束することもある。そのような場合には、そのコミットメントを果たせるようにビジネスを助けなければいけない。ただし、コミットメントを受け入れるわけではない。
この違いが重要だ。プロであれば、ビジネスに手を貸して目標を達成できるように務めるが、それは必ずしもビジネスのコミットメントを受け入れたということではない。顧客との約束を果たす方法が見つからなかったら、約束をした本人が責任を果たさなければいけない。

『Clean Coder プロフェッショナルプログラマへの道』p.155より

「責任」と「協力」の意味はそれぞれ異なります。責任はコミットをした人が引き受けるべき務めですが、責任の所在に関わらず協力することは、組織やひいては自分にとってプラスになります。

例え自分が約束したことでなくても、メンバーと協力して目標を達成できるように努めましょう。しかし雰囲気に流されて無理なコミットメントを受け入れてしまったり、逆に全く協力しなかったりするのはプロの振る舞いとしてふさわしくありません。

このように責任と協力を切り分けつつ全力でプロジェクトに取り組めば、必要以上にプレッシャーを感じずに、成果を出して貢献することが可能です。

ペアを組んで乗り切る

緊急事態になると冷静さを失ってしまうことがあります。私も自分の担当箇所でバグが見つかり、頭から血の気が引くような思いをしたことがあります。こうした緊急時には、周囲の人に助けを求めるのが解決への近道です。本書でも複数で事に当たる重要性が強調されています。

ペアになるんだ！　危なくなったら、ペアでプログラミングをしてくれる仲間を探そう。きっと不具合が少なくなり、仕事が早く終わるだろう。ペアのパートナーがいると、規律を保つことができるし、焦らずに済む。パートナーは、君が見逃しているところを見つけてくれる。役に立つアイデアを持っている。集中力がなくなったときに緊張感を持たせてくれる。
　誰かにプレッシャーがかかっていたら、こちらからペアを申し出よう。抜け出せない穴から出るのを手伝ってあげよう。

『Clean Coder プロフェッショナルプログラマへの道』p.157より

一人で慌てて対応をしてしまうと、二次的に被害を生む危険性が高いです。周囲の人と会話し、いつもと同じように正しい手順を踏んで対応しましょう。

また、緊急時にはディレクターや営業など、いろんな人が最新情報を求めてエンジニアの所に集まってきます。そうなると担当エンジニアが情報提供や質問の回答に追われて肝心の対応が進まず、人に囲まれることで強いプレッシャーを受けてしまいます。

この問題を起こさないために、対応担当者と連絡担当者を分けることが重要です。対応担当者は集中して技術的な対応を行うべきです。また、連絡担当者は情報を整理し、対応担当者をプレッシャーから守るのが務めです。実際の対応とコミュニケーションを分担することで、問題に対して素早く冷静に対処できるはずです。

プロフェッショナルに近づく、キャリアを積む

ここまで『CleanCoder』で押さえたいポイントを挙げていきました。ここからは本書の内容をふまえ、私がエンジニアとしてプロフェッショナルに近づくために日頃気をつけることを考えてみます。また、プロフェッショナルとして信頼を積んだとき、エンジニアが進めるキャリアの例としてプロダクトマネージャーを挙げます。

信頼をコツコツ積むこと

本書にもあるように、プロフェッショナルとして認められるには、信頼の獲得が欠かせません。そして信頼を得るには、まずは約束を破らないことが重要です。見積もりの精度を高め、自ら設定した期限を守ることを大切にしましょう。信頼貯金という言葉も使われますが、信頼とは地道に積み上げられていくものです。

私は新しいチームに参加するときに、「約束を守る」ことは特に強く意識しています。まだ信頼を積み上げていない状態で約束を破ってしまうと、すぐにマイナスのイメージを与えてしまうからです。

約束を守る以外にも「他の人のアイデアに賛同し、さらに自分のアイデアを加えてより良くする」など少しずつ信頼を得られるように行動していると、周囲の人がアイデアや困ったことを相談に来てくれるようになります。必要な情報が自然と集まるので、自分の仕事も進めやすくなり、好循環が生まれます。

エンジニア出身のプロダクトマネージャー

エンジニアとしてプロフェッショナルに近づくと、どのような道がみなさんの前に開けるでしょうか。

素早く意思決定して価値あるプロダクトを生み出すため、昨今、プロダクトマネージャーの重要性が高まっています。特に海外の企業ではプロダクトマネージャーにエンジニアリングの知識が必要とされている場合も多く、エンジニアの一つのキャリアになってきています。

GoogleやIncrementsで同職を務めた及川卓也さんも、そのポジションの重要性を力説しています。

プロダクトマネージャーに必要なのは高い判断能力です。実現難易度や必要な期間を判断し、何をどの順序で取り組めば最も効率が良いかプランを立てることが求められます。このような能力を磨くには、まずは自分の作業について上手に判断ができなければなりません。少しずつ判断できる範囲を広げていけば、プロダクトマネージャーへの道が見えてくると思います。

おわりに

周囲から信頼されたプロフェッショナルとなるためのポイントとして、コミュニケーションやプレッシャーとの付き合い方を挙げました。信頼はすぐには得られません。技術力を磨くとともに、プロフェッショナルらしい振る舞いについても意識していきましょう。

著者プロフィール

池田 惇（いけだ・じゅん）@jun_ikd

スマートフォンアプリエンジニア。iOS・Androidのアプリ開発を行いながらPMや開発チームリーダーを経験。エンジニアとして技術を学び続け、プロダクトマネジメントや人材育成でも活躍したい。アジャイル開発とオープンソースソフトウェアの活用を好む。

【今こそ読み解きたい名著】バックナンバー

編集：薄井千春（ZINE）