🕛

自走する方法

2021/05/19に公開

はじめに

上司にとっては自走出来る方はとても重宝します。何故なら、教育コストを掛けずとも自分で業務上すべきことを貪欲に吸収し、明確な命令を与えられずとも自分で考え、必要な時に質問をし、相手の意図を汲み取り十分な品質で達成してくれるからです。自分が上司であれば喉から手が出るほど欲しい人材ではありますが、自分の肌感と同じく知り合いのエンジニアの方から話を伺うと、その数はやはりあまり多くないらしいです。しかし自分は、自走出来る人材の数が少ないのは自走の仕方を単純に知らないからであるのだと考えています。実際、以前電力システムの保守運用をするプロジェクトのエンジニアリングのリーダーをしていた時、エンジニアとしての自走の仕方をプロジェクトに関わる開発者15人に対し教え、1ヶ月ほどでほぼ全員自走出来るようになり、それ以降リーダーとしてはほぼ何もすることがなくなりました。全員もともと素質ある方々だったということも関係があったと考えていますが、それでも「これは効果があったな」とか「これを意識すれば自走出来るだろう」という今まで自分が教えてきたこと、そして「自分自身が意識してやってきたこと」をこの記事にまとめてみました。

対象者

エンジニア歴二、三年の者

仕事をする上で最低限明確にすること

BacklogやRedmineで「管理画面の問題調査」というタイトルだけの曖昧なチケットを担当することになったとします（長く仕事をする中では何度かこのような理不尽な仕事が何度か降ってくることもあります）。この場合何が問題なのか、どういった背景でこのタスクが作成されたのか、どこまでの範囲を対象とするのか、いつまでに終わらせるのか、紐解いて問題が沢山出てきた場合どれを先に対応するべきなのかを明確にする必要があります。もしこれらを明確にしなかった場合、目的に対し一直線に作業を進めることが出来ず非効率的になり、完了までに時間かかってしまったり、背景を知らずに進めたがために会話がスムーズに進まず情報収集に時間が掛かったり問題を取り違えたり、スコープを切らずに進めたためにどのくらい品質を高めれば良いか分からずいつまでも同じ問題に対処し続けてしまったり、期限を明確にしなかったためにある日進捗を聞かれた時に「まだ対応してなかったの」と言われて急に温度感が高くなり仕事のリズムが崩れたり、優先度の低い問題を先に対応したために本当に優先度の高い問題を放置して大きな問題に繋がったり、というようなことが起こりえます。必ず有識者・目的・背景・スコープ・期限・優先度を明確にし、合意形成してください。

シナリオ

BacklogやRedmineで「管理画面の問題調査」というタイトルだけの曖昧なチケットを担当することになったというシナリオで説明します。

明確にすべきこと

有識者の識別
目的と背景の把握
スコープ・優先度・期限の決定と合意形成
合意形成をしなおす

有識者の識別

誰がこのチケットを作成したのかを特定します。チケットの中に大体は情報が書かれているためそれを確認することになると思います。稀に「これは言われて作成した」というケースもあるため、その場合は誰に言われたのかを質問します。その有識者がもし退職して会社にいない場合は次に誰かこの問題について知っている方を探します。効率の良い探し方は、Slack等の有識者が集まっていそうなチャンネルを見つけ、全体に向けて「誰か知っているか」と聞いてしまうことです。または、朝会などの会議がもしあれば、その際に聞いてしまうのも手です。もし、そこまでして誰も知らないということであれば、そのチケットは上司に確認をとった上で削除してください。

目的と背景の把握

「なぜこのチケットが作成されたのか」を有識者に聞く必要があります。効率良いやり方は有識者が分かった時点でその人との会議を設定することです。もしも、チケット内容が十分記述されていればこのような会議を開く必要はありませんが、この場合チケットにはほとんど何も書かれていない状態なので情報収集から始める必要があります。会議が始まったら、目的と背景を詳しく聞いてください。会議を開いた結果「あの管理画面全体的にバグが多い、表示がとても遅いなどの指摘が開発者やユーザーからあがっていたのですが、チケットにそれを書ききれず一旦チケットだけ軽く作成しました」など何かしら次のアクションに繋がる情報を得られる事が多いです（それにしても対象範囲が広過ぎて大体の人は困ってしまいますのでチケットを切るときはもう少し粒度を絞ってほしいものです）

スコープ・優先度・期限の決定と合意形成

対応するスコープを明確にしなければ後々「あれ、ここまだバグっているのになんで対応しなかったの？」と言われかねません。相手のあなたに対する期待値は非常に曖昧で「期限は出来次第早く、いい感じにこのバグを対処してくれるだろう」程度に考えている事がほとんどだと思います。問題が起きる前に相手の期待値を絞っておきます。管理画面の問題というくらいですから、全体的にバグが多いのでしょう。しかし、全てを「相手が考えている時間内」に対応することは難しいです。従って、「何から対応するべきなのか」「重要な部分は何か」を意識してスコープを切ると良いです。AからZページ分全てにバグが含まれているうち、XからZまでのページが一番利用率が高くバグも多いということであれば、最優先でその三つのページのバグと重い処理の問題を解決する必要があるということが言えます。実際に伝えるとき「X,Y,Zのページの利用率が高いので一旦二週間で対応します。想定以上に長引く場合はすぐに一報入れます」と伝えて必ず合意形成をしておきます。もしもそれで合意形成ができれば作業対象の範囲がX, Y, Zページのみと一気に絞られ、少なくとも確実に二週間の余裕ができ、明確な目的の下解決にあたる事ができます。

合意形成をしなおす

これが意外と重要だったりします。（スコープを切ったとしても）大きなタスクを長く対応している時は特に大事です。なぜなら、気付かぬうちに途中でそのタスクに対する温度感が変わることがあるからです。これを気付かず放置してしまうと、「そんなに温度感高く無いよ」と伝えられていたタスクは、直前になり「あのバグ修正をしてくれないとリリースする意味がない」と指摘され、スケジュールギリギリで対応することになります。これを防ぐために、「最近なんだか温度感変わってきた気がするな」と感じたタイミングですぐ会議を開き、目的、スコープ、優先度を再度確認しておきます。そうすると意外と変更があったりするものです。この会議で「この箇所のバグはリリース前に確実に修正されるべきバグです」ということになれば、「それでは、対応範囲が少し広がることになるのでスケジュールを少し伸ばさせていただきますが、よろしいですね」と認識を合わせることができ、再度ゆとりのあるスケジュールで作業にあたることができます。

チームで仕事をしているという意識

会社での仕事は、必ずチームで仕事を進めることになります。例え、それが個人作業のように見えても、その成果物を使うのはユーザーだけでなく、チームのメンバーもです。その人から手を離れ、将来的に変更が掛かる場合、当然タスクをこなすのは別のメンバーということになります。その時コードが可読性が悪く、全体的に密結合で、ログもなく、テストコードもないなど保守性が全く確保されていないコードであったならばどうでしょうか（※レビュー体制が整備されていない劣悪な現場を前提としておりますが）。そして、往々にしてその作業者だけではなく、色々なメンバーがその機能のソースコードを何度も見なければならないとしたら、どれだけの人件費が消えてなくなるでしょうか。これはコードの話だけではありません。あなたのSlackでのメッセージの送り方、ホウレンソウの仕方、プロダクトの品質に対する姿勢全てがチーム全体に影響します。会社での仕事はチームで行うため、自分の仕事のことだけを考えていれば良いという訳にはいきません。チームで仕事を進める上で特に重要なことを以下で説明していきます。

誰がボールを持っているのかを明確にする

仕事をしている中で意外と頻繁に発生するのが、今誰がボールを持っているのかが分からないという状況です。例えば、障害発生アラートがSlack上に流れてきたとして、複数人が障害についてチャットベースで議論を重ねていたとします。そこで対応方法の結論を出したものの、そのまま会話が終了してしまった場合、「結局今は誰が対応しているのか」となります。「会話の流れ的にあの人が対応してくれているだろう」とそれぞれが考えていた場合、いつまで立っても解決されず、気付いた頃には大問題になっているかもしれません。そういう問題を防ぐために、解決策を提示するだけでなく必ず「このボール、誰が持ちますか」と聞くとそれらの問題を未然に防ぐことができます。

ホウレンソウ

今このタスクを誰がやっているのかが分からない、二人でそれぞれ同じ機能開発していた、誰に報告するべきか分からない。現場ではこのようなことがしばしば起こります。これは単純にホウレンソウが十分ではないためこのような問題が発生しています。ホウレンソウは非常に基本的なことではありますが、メンバー間で連携していく上で最も重要なことです。しかし、どの年代の方でもホウレンソウを意識していなければ意外とうまく出来ていない方が多いように感じておりますが、それには理由があり、このホウレンソウは塩梅が非常に難しいのです。報告し過ぎれば相手の負荷になり、逆に報告を全くしないとお互いの状況を把握することができず、うまく連携が取れません。では、どうしたら良いか。「相手の立場を理解し、どんな情報を必要としているのか」を理解すると、適切なホウレンソウを行うことが出来ます。例えば、ディレクターが「来週までには必ず本番反映してほしいのでこちらの対応をお願いします」というように依頼してきた場合は温度感が高いので「正しくタスクが進められているか定期的に進捗を知りたいのだろう」と判断することができ、こちらから定期的に進捗報告すればディレクター側から「今どこまで終わっていますか」と聞かれることもなくなるため、管理コストが減ります（タスク管理をする人は何人もの開発者の状況を把握しなければならないことが多いですから出来るだけ負荷は減らしてあげてください）。また、本番サーバーで何かを直接設定することになった場合、アクセスする時に一言「今から本番サーバーの設定を変更します。影響範囲は比較的広いため、もしも設定反映を行なった後に障害等が発生した場合はこちらまで一報よろしく御願いします」と連絡を入れておけば、実際に障害に繋がったとしても関係者達は慌てることもなく、冷静に対処することが出来ます。新機能開発をする時も、設計を自分だけで完結させずに、自分以上に技術力のある人に相談しレビューを頼むなどをすると後々の設計不備によるトラブルを避けることが出来るかもしれません。ホウレンソウのタイミングやどれだけの情報を載せるかなどを意識することは初めのうちは難しいかもしれませんが、チーム間の連携、サービスの品質に大きな影響を与えるため、これに慣れておくことはとても重要です。

お膳立て

相手に質問する時、相手にタスクを依頼する時、要望を伝える時、テストを依頼する時、相手が関わる全てに対しお膳立てをすることであなた自身の信頼が積み重なり、評価が高くなり、生産性も上がります。例えば相手に質問する時は、情報を小出しにして何度も返信させることで相手の集中力と時間を奪うのではなく返信が出来るだけ少なく済むように一つのメッセージに必要最低限の情報を全て入れ、「〜の件で」とはじめに入れるなどして読みやすい形にしてからまとめて送ると、相手はそれに対し返信を比較的すぐに返すようになります。また、タスクを依頼する時に「このタスクお願いします」と雑に投げるのではなく、一度会議を開いて「こういう背景でこういう温度感なのでこの期間まで対応してほしいと考えています」と出来るだけ相手に取り掛かりやすい状況にしてあげます。そうすれば不必要な不満を持たれることはなく、「こちらが仕事に取り掛かりやすいように分かりやすく説明してくれてありがとう」とむしろ言われるようになります。印象も良くなるため、次も仕事を依頼しやすくなり、質問にもすぐに反応してくれるようになります。チームで密にやりとりをする場合この「信頼度」が生産性において重要な変数を担っており、信頼度が低いと返信が返ってこない、または「それはあなたで対応してください」と依頼を拒否されることもあります。時間がない時は特に厳しいですね。人は意外と感情的な生き物で、どんなに相手が理性的であるとしても常にこのことを忘れてはなりません。このように、自分の時間を少し削ってお膳立てをすると相手はそれ以上に答えてくれるようになり、逆にそれをせず雑に投げ付ければそれ相応のしっぺ返しを受けることになりますので、お膳立てはチームで仕事をする上ではとても大事なことです（チーム全体でお膳立ての文化が広まれば全員が仕事をしやすい環境を作ることが出来ると考えていますので、目指すべき理想です）

10分調べて分からなければ聞く

分からなければすぐに聞くか、自分で調べるか。賛否両論あるかもしれませんが、個人的に最も効率が良いと考えているのは「10分自分で調べて分からなければ知っている人に聞く」というやり方です。分からないことをなんでもすぐに相手に聞いてしまうと相手はとても嫌がります。なにより、少し調べれば分かるようなことを聞いてしまうのは相手の時間と集中力を奪うため、自分以外の生産性を下げることになります。かといって分からないことを自分だけで調べようとすると、掛かる時は何日も掛かることもあり、これはこれで問題があります。それでは、どうしたら良いか。まず自分で10分間調べ、最低限検索すればすぐに解が得られるようなことは自分で見つけ相手の負荷を減らし、10分以上時間が掛かりそうなものであれば相手に質問するようにすれば、相手に負荷をあまり与えずに時間を短縮することができます。知っている人に仕組みやポイントを軽く教えてもらってから自分で調べれば8時間掛かっていたことが1時間で終わるかもしれません。この一度だけでも7時間分の人件費が削減できます。これが10回、100回、そしてチームメンバ各自で行われれば、人件費削減の効力も大きくなります。ただ「自分で調べてください」とメンバーに伝えるのではなく、「自分で調べて10分経っても分からなければ自分に聞いてください」というように伝えてあげれば、後のチーム全体の生産性向上に繋がると考えています（※プロジェクトの規模が大きくなると10分では頻度が多過ぎるかもしれないので、関係者と相談して合意を取っておくことも良いかもしれません）

即時レスポンス

作業中にメッセージが来ると、キリが悪い場合はついつい「後で回答しよう」と後回しになってしまうことがあります。個人だけで仕事をしているのであればこれでも良いのかもしれませんが、チームで開発をしている場合はこれが全体最適とはならないことが多いです。特に今はリモートワークを採用している企業も多く、チャットベースのコミュニケーションのレスポンス速度がチーム全体の生産性に無視できない影響を与えます。「後で返信しよう」と考えている間に、相手にとってはあなたからの返信がなければ先の作業に進めないかもしれません。また、あなた自身相手にメッセージを送った時に返信がすぐに返ってこず、四時間も放置されていたら「返信返ってこないし、もう今日の仕事は終わりだ」とTwitterに流すかもしれません（実際にこれをやっている方を何度か見たことがあります）。チーム全体で返信が遅いと仕事に影響があることは想像に難くないかと思います。もしも仕事を今以上に生産的にしたいのであれば、相手の返信には直ぐ答えるようにしてみると良いです。直ぐに返信を返すことを徹底すると、意外な効果があります。相手も同じように返信を直ぐに返してくれるようになったり、すぐ返事を返すことが評価に繋がったり、それがチーム全体の信頼に繋がったりします。そしてもちろん、あなたが早く答えた分だけ相手の作業がブロックされることなくスムーズに仕事を処理できるようになるため、チーム全体の生産性が上がります。「コンテキストスイッチが掛かる」など勿論反論はあるとは思いますが、数時間メッセージの放置をせずともポモドーロタイマーを使用してタイマー終了後にメッセージを返すなどのやり方は探せばあるはずです。もしもそれでも影響が分からなければ、「返信を返さなかった場合の影響」についてヒアリングし、どの程度チームの生産性に影響したかを確認するというのも良いかもしれません。

残業をしない

締め切りが近いとつい残業をしたくなるかもしれませんが、後々の影響を考えると残業を習慣にするべきではありません。単位時間あたりの自分の価値が下がるというのもそうですが、残業が習慣化されていると「残業が前提の仕事の仕方」になり、効率が落ちていきます。今から話す内容は個人差があるかも知れませんが、自分と昔の同僚で実際にあったことをお話しすると、毎日残業をしているとそれが習慣になってしまい、中々定時に帰宅することが出来なくなります。はじめのうちは「このやる気がいつまでも続く」と考えているのですが、自分の時間が取れずやりたい領域の勉強をすることも出来ないため徐々に技術に対するモチベーションが無くなっていきます。影響はモチベーションだけではなく、工数見積もりにもそれは影響し、不思議と残業を前提にして考えるようになってしまい、最悪の場合「休日稼働すれば終わるだろう」と考えて工数見積もりを細かく考えなくなります。そうしてそれは自分のみならず全体の炎上に繋がり、プロダクト品質は確実に低下していきます。では、逆に残業しなくなった後は何が起きたか。残業、徹夜、休日出勤が当たり前だった時は無限に感じられた時間が急に有限に感じられ、はじめのうちは限られた時間の中で仕事を終わらせなければなくなるために焦ります。しかし、そうして時間を意識すると「では、どうしたら期間内に仕事を終わらすことが出来るのか」と考えはじめるようになり、自然と仕事の仕方が効率化されていき、仕事の進め方も変化します。「物理的に無理だ」と感じたら「今回重要な部分はここまでなので、スコープはこれくらい」というようにスコープを絞ってフェーズを分けることを意識するようになり、「毎回同じ作業をしているな。ここを自動化すれば時間短縮が出来そうだ」と考えるようになりました。これはあくまでも自分と昔の同僚の例ではありましたが、このように、残業をしないことで逆に仕事の効率や品質が大幅に改善されたため、自分は「残業をしない習慣」をお勧めしておきます（※リリース時と障害発生時の残業、休日出勤はまた別の話です。それは契約に従い、適切に対応してください）

自分の限界を知る

自分の限界を知ること、これはとても大切なことです。「この仕事はどう足掻いても物理的に無理」という感覚をもしも知覚することが出来れば、「無理」と気付いたタイミングで早めに上司に相談することができます。（残業や休日出勤をはじめから選択するのではなく）ビジネス側と調整し優先度を決めてスコープを絞るか、経験ある技術者にサポートに入ってもらうなどが可能になり、落ち着いて開発を進めることが出来るようになります。落ち着いて開発を進められるということは、それは品質にも影響し、最終的にはそのシステムを利用するユーザーに影響します。

手を抜かない

プログラムを開発している時、「特定の条件下ではバグに繋がるけど、そうそう起きないだろうし対応しなくても良いだろう」という甘い考えが時々頭をよぎる時が誰しもあるかとは思います。その障害発生確率が全体の0.5%の確率という小さな値だとすれば無視して良いだろう、とこのように考えてしまうかもしれません。しかし、もしもそれを開発者全員が同じことを考え、それもどの機能にも同じように考えて開発を進めていたと考えるとどうでしょうか。例えば、一年間で一人あたり20機能担当するとしていたとします。開発者は30人いて、一機能毎に最低5箇所は非常に小さな手抜きがあるとします（現実ではそれは想像以上に多いと思っています）。これだけで20人 x 20機能 x 5箇所の手抜き = 2000箇所手抜きが一年間で生成されるということになります。ここからさらに障害発生確率を計算すると2000 x 0.005 = 10、つまり「一年に10回は障害が発生する」ということになります。「なんだ、年に10回程度の障害なら無視できるじゃないか」と思われるかもしれないですが、これを対応していかない現場はそこからさらに年々積み重なっていくことになります。もしも、「微々たる問題だから」とその一つ一つのバグを対応しなかった場合、どうなるでしょうか。10年もシステム運用していれば100件ずつ障害が発生することになり、それに対する問い合わせ対応などが増えていきます。おそらくこの頃には開発者の三分の一は問い合わせ対応やバグ調査に時間を取られることになると思います。そろそろ無視出来なくなり、全員が問題を認識し始めますが、一つ一つを直したところで効果はあまりなく、一つのバグ修正に掛ける時間と効果を考えると「バグ修正は調査に時間が掛かる割には効果が低く優先度が低い」というように対応する人がさらに減り、「誰も触ることが出来ないシステムが何故かギリギリのところで動き続けている」という目も当てられない状態になります。運用負荷は高く、生産性は下がり、そこから退職者も出てくるでしょう。技術力のあるエンジニアを採用し定着させことも難しくなるでしょう。経験上、どの企業でも同じような流れを辿っているため、一エンジニアの心構えとしては「どんなに些細なことでも手を抜かない」と考えておくべきだと考えています。

改善のサイクル

Next Action

Next Actionを必ず出す、これは非常に強力です。会議をする時、何かを分析する時、またはPDCAを回す時。例として、仕事効率に関しての分析の結果としてNext Actionを出してみます。

# 仕事の効率改善
- 問題点
    - レポートラインが不明瞭
    - スコープが切られていない
    - 情報収拾が個人では難しい
    - 残業が習慣になっている
        - 気付いたら定時を大幅に過ぎていることが多い

# Next Action
- レポートラインを明確にするため、水曜日に関係していそうな者を含めて会議を開き、関係者を特定する。
- その会議にもし関係者が揃っているのであれば、適切にスコープを切り、合意を得る。
- 定時にSlackのリマインドを設定する

こうして「仕事の効率改善」という課題に対しNext Actionを書き出すことが出来たため、後はこの通りに実行するだけです。これだけで業務の改善が確実に行われていきます。この他にも、Next Actionという考え方は様々なことに適用することが出来ます。「朝早く起きる習慣を身に付けたい」「最近のストレスの原因をなんとかしたい」「タスクを安定して処理できるようになりたい」などなんでも設定することが可能で、今まで「改善することが出来ない」と考えていたあらゆることをNext Actionとして出すことで、改善への次の一歩を進めることが出来ます。本記事の中で自分自身が一番好きな考え方でもあるので、本当に効果があるのかを是非お試しください。

概念実証(PoC)

新しいことをやる時、新しいツールを導入する時、一気にやろうとすると反発を受けたり、実際にいきなり導入してしまうと作業効率がむしろ低下することもあります。しかし、PoCとして短い期間で小さく「実験」をすることで「本当にこのツールを入れることによって効率が良くなるのか」を小さな影響で確認することが出来ます。期間も短く影響も小さければ「二週間くらいならやっても良いかも」と合意が得られやすくなります。新しい方法を実行したり、何かを導入する際に非常に重宝する考え方です。

Noteに書き出す

（Next Actionの内容と一部被りますが、強調しておきたい部分が異なります）
仕事で何か作業を進めていると、ふと「ああ、なんだかやりたくないなこのタスク」と思うことがあるかもしれませんが、こういう時は「何がそう思わせているのか」を考えると原因が明確になります。そのための方法として「Noteに書き出す」という行為は個人的にはとても効率が良く、最終的にそれを解決するためのNext Actionへと繋げることが出来るようになります。やり方としては、そのタスクに関する「懸念事項・不確実な部分・不安・問題」を列挙していくと明確になっていきます。

# 問題点や不安だと思うこと
- なんかこのタスクやりたくない
    - 不確実な部分が多過ぎる
    - 関係者がふわっとしている
        - レポートラインや不明瞭な状態がとても不安
    - 時間が経って関係ない部分でバグが発生すると自分の責任ということになりそう
    - スコープが広過ぎる
    - コスパが悪いし優先度が低いように感じる

こうして問題点を明確にした後は、「では、これらの問題を解決するにはどうしたら良いのか」を意識してNext Actionを出していきます。

# Next Action
- スケジュールを考慮し木曜日までに、以下の目的を達成するべく「関係していそうな人」をざっくりと選び、会議を開く。
    - 関係者の特定
    - 本タスクについての背景の確認と目的を明確にし、必要性について話し合う
    - スケジュールを考慮し、スコープを絞り、優先度について話し合い、合意を形成する

これで懸念点、問題点はなくなり、自信を持って次の一手を打つことが出来ます。しかし、ここまで出して「会議をしている時間がない」と跳ね除けられた場合、そこからまた更にNext Actionを出すことが出来ますが、そこから先は個人の問題ではなく「組織の構造や文化の問題」となってくるため、それでもしもあなた自身が失敗したとしてもあまり気に病む必要はないと考えています。それは組織の構造、文化を管理する者の責任であるからです。

最後に

自走の方法について説明しました。恐らくここまで読んで「そもそも会社の問題なのに、何故ここまでしなければならないのか」と思う方もいらっしゃると思うのでこの記事の前提を補足しておくと、本記事では個人がもし劣悪な環境で仕事をせざるを得ない状況下におかれたとしても適切に対処、自走する方法を説明させていただいております。これだけ劣悪な環境で自走が出来ればあなたはどこの会社でもやっていくことが出来ます。むしろ、これだけのことが出来れば「どの会社からも求められるような人材」になることが出来ます。なぜなら、管理コストが全くかからず全てを自分で考え、行動し、改善するのですから。記事であげたほとんどは組織の構造上の問題であり、間違いなく会社側の責任ではありますが、それに対して不満を言っているだけでは幸せになれません。会社の構造を変えるか、自分が対処するか、転職するのかのいずれかを、あなた自身が選択する必要があります。自走出来るようになった今のあなたは次にどのような選択をするのでしょうか。