前のページでは「知識の置き場所を一つにする」話をしました。では、置き場所を決めた知識を、実際の作業でどう使えばよいのでしょうか。毎回同じ説明を読み返すのは大変です。このページでは、手順そのものを名前で呼び出す考え方を見ていきます。
置き場所が一箇所に決まっていても、それを見に行くたびに長文をすべて読み返すのでは、実用に耐えません。必要なのは、「これをやりたい」と思ったときに、すぐに正しい手順へたどり着ける入口です。その入口の作り方が、このページのテーマです。
手順に名前をつけて、中身を隠す
プログラミングには、関数という仕組みがあります。何度も使う一連の処理を、ひとまとまりの手順として書いておき、名前をつけて呼び出せるようにするものです。
たとえば「合計を計算する」という処理を、毎回一から書く代わりに、一度「合計する」という名前の手順として定義します。以後は必要な場所で「合計する」と呼ぶだけで、中身の計算式を意識せずに結果を得られます。
ここで重要なのは、2つの効果です。1つ目は、同じ処理を何度も書かずに済むこと。これは前のページのDRYそのものです。2つ目は、呼び出す側が中身の詳細を知らなくてよいことです。「合計する」の中身がどう計算されているかを知らなくても、名前を呼べば正しい結果が返ってくる。これを、中身を隠すという意味でカプセル化と呼ぶこともあります。
呼び出す側からすれば、中身がどれほど複雑でも関係ありません。複雑な計算式が3行だろうと30行だろうと、「合計する」と呼べば同じように結果が返ってきます。複雑さは名前の内側に閉じ込められ、外側からは単純な操作として扱えるようになります。これは仕事における「丸投げ」とは違います。丸投げは責任の所在まで曖昧にしますが、関数化は中身の実行方法だけを任せ、何を渡せば何が返るかという約束はきちんと決まっています。
さらに関数には、もう一つ大事な性質があります。一度作った関数の中身を直せば、その関数を呼んでいるすべての場所に、修正が自動的に反映されることです。呼び出し側を一つずつ書き換える必要はありません。
これは前のページのDRYと矛盾しません。むしろDRYを実際に動かすための仕組みが関数だと考えると分かりやすくなります。DRYが「知識は一箇所に置け」という原則だとすれば、関数化は「その一箇所を、名前で呼び出せる形にする」という実装の方法です。原則だけでは実行できません。呼び出せる形になって初めて、日々の作業で使えるようになります。
仕事の言葉に翻訳する
仕事における関数とは、手順書やチェックリストのことです。「この作業をしたいときは、この手順書を見ればよい」という状態を作ることが、関数化にあたります。
手順書に名前がついていれば、依頼するときも「あの手順でお願いします」の一言で済みます。毎回、口頭で一から手順を説明する必要がなくなります。これは前のページで見た、新人に毎回口頭で説明していた先輩の問題への、直接の答えでもあります。
さらに、手順書には「誰がやっても同じ結果になる」という価値もあります。ベテランが対応しても、新人が対応しても、手順書通りに進めれば、成果物の質にばらつきが出にくくなります。これは個人の能力差を否定する話ではありません。判断が難しい例外的な部分にこそ人の経験を使い、毎回同じであるべき定型部分は手順書に任せる、という役割分担の話です。
手順書を作るときに大事なのは、「何をすればよいか」だけでなく「何を渡せば、何が返ってくるか」をはっきりさせることです。プログラムの関数にも、受け取る値(引数)と返す値(戻り値)があります。手順書で言えば、「必要な情報(引数)」と「完成する成果物(戻り値)」にあたります。これが曖昧な手順書は、結局呼び出すたびに追加の質問が発生してしまいます。「経費精算の手順書」と言われても、必要な持ち物(領収書の原本かコピーか)や、出てくる結果(即日承認か、翌週承認か)が書かれていなければ、毎回誰かに確認しなければ動けません。これでは、名前をつけた意味が半分になってしまいます。
手順書の名前づけも軽視できません。「あの資料」ではなく「経費精算手順」のように、具体的で覚えやすい名前がついていれば、依頼するときの会話がそのまま呼び出しの言葉になります。名前が曖昧だと、探す手間が発生し、結局は口頭で一から説明し直す方が早いと思われてしまいます。
具体的な場面で見る
経費精算の手順書。「領収書と経費申請書を、いつまでに、誰に、どの形式で出せばよいか」を1枚にまとめた手順書を用意します。渡す情報(領収書・日付・金額・目的)と、返ってくる結果(承認済みの精算・差し戻し理由)を明確にしておきます。新人が入るたびに、先輩はこの手順書を渡すだけで済みます。口頭説明にあった「毎回微妙に違う話」がなくなり、全員が同じ手順を実行できるようになります。
問い合わせ対応の手順書。返品期限や送料についての問い合わせに対する回答を、定型の手順として書き出しておきます。担当者は自分の記憶に頼らず、手順書を見て回答します。これにより、前のページで見た「同じ質問に違う答えが返ってくる」問題が防げます。新しい担当者が入っても、ベテランと同じ精度で答えられるようになります。
引き継ぎの手順書。ある業務を担当者が交代するとき、「何を確認し、どこに何を入力し、誰に連絡するか」を手順として書いておきます。担当者が変わっても、手順書を呼び出せば同じ結果にたどり着けます。この考え方は、11章で扱う属人化の問題にも直結します。
会議準備の手順書。週次会議の準備を、毎回担当者が「何を用意すればよかったか」を思い出しながら進めているとします。「議題を集める、資料をまとめる、前回の宿題を確認する」という手順を一枚にまとめておけば、担当が交代しても同じ質の準備ができます。準備の質が担当者の記憶力に左右されなくなります。
4つの場面に共通するのは、頭の中の手順を「呼び出せる形」に変換したことです。一度きちんと書いておけば、以後は書いた本人がいなくても手順が機能します。逆に言えば、手順が頭の中にしかない間は、その人が忙しいか休んでいるかによって、チーム全体の作業速度が左右されてしまいます。手順書は、個人の都合とチームの進行を切り離すための仕組みでもあります。
落とし穴 — 隠れた前提を持つ手順書
関数化には、見落とされがちな落とし穴があります。手順書が、書いた人だけが知っている「隠れた前提」に依存してしまうことです。
プログラムの世界では、関数が呼び出し側から見えない場所の情報(たとえば、他の処理が先に済んでいることが前提、など)に依存していると、思わぬ場面で不具合が起きます。これは副作用や隠れた依存と呼ばれる問題です。
仕事の手順書でも同じことが起こります。「経費精算の手順書」が、実は「総務のDさんが月初に在籍している」ことを暗黙の前提にしていたとします。Dさんが休んだ月だけ、手順書通りに進めても処理が止まってしまいます。手順書には書かれていない前提が、手順書の外側に隠れていたのです。
厄介なのは、この前提が普段は問題にならないという点です。Dさんが毎月きちんと出社していれば、手順書は何の問題もなく機能し続けます。不具合が表面化するのは、前提が崩れる、めったにない瞬間だけです。だからこそ、手順書を作った時点では気づかれにくく、実際に困るまで見過ごされてしまいます。
こうした隠れた前提を減らすには、手順書を書くときに「これは誰が担当でも成立するか」を自問することが有効です。特定の個人の存在や、特定のタイミングでしか成立しない手順は、名前をつけて呼び出せるようにしたつもりでも、実際にはいつでも呼び出せる状態になっていません。
見つけ方の一つは、実際に別の人に手順書だけを渡してやらせてみることです。書いた本人がやれば、頭の中の前提を無意識に補ってしまい、不備に気づけません。別の人が手順書だけを頼りに動いてみて、どこで手が止まるかを確認すると、隠れた前提がどこにあるかが具体的に見えてきます。これは、手順書を作った直後の点検として有効な方法です。
もう一つの落とし穴は、手順書を作ったきり更新しないことです。呼び出し側が増えるほど、手順書の古さに気づかれにくくなります。複数の人が同じ古い手順書に従い続け、気づいたときには全員が同じ間違いを繰り返していた、ということも起こります。これは1ページ目で見た「重複は発見が遅れる」性質と、よく似ています。一箇所にまとめたからこそ、古くなったときの影響範囲も一箇所に集中します。被害が広く薄く散らばらない代わりに、古さそのものに気づく機会も減ってしまうという、両面があります。手順書には、最終更新日と見直し担当者を明記しておくと、この放置を防ぎやすくなります。
さらに、手順書を細かく分けすぎるという逆方向の落とし穴もあります。一つの作業を、あまりに細かい手順書に分割しすぎると、呼び出す側は「どの手順書を、どの順番で呼べばよいか」を覚えなければならなくなります。これでは、口頭で説明していた頃と手間があまり変わりません。手順書の粒度は、一つの依頼として自然にまとまる単位を目安にするとよいでしょう。「経費精算」はまとめてよくても、「領収書を撮る」「日付を確認する」まで分けると、かえって呼び出し側の負担が増えます。
次のページでは、こうした手順書や部品を、個人やチームを超えて共有する仕組みについて見ていきます。一つのチームの中だけで閉じていた手順書を、組織全体で使える共通部品に育てる話です。
手順書に名前をつけることは、組織にとっての「共通言語」を一つ増やすことでもあります。「経費精算手順でお願いします」という一言が通じるチームは、毎回説明し直すチームより、依頼のやり取りが確実に短く済みます。
持ち帰り
- 関数化とは、手順に名前をつけて、中身を意識せず呼び出せるようにすること
- 手順書は「何を渡せば、何が返るか」を明確にして初めて機能する
- 特定の人やタイミングに依存する隠れた前提は、手順書を機能不全にする
やってみる
自分がよく頼まれる作業を1つ選び、「名前を言われたら誰でも実行できる手順書」になっているかを確認してください。渡す情報と返ってくる結果が、どちらも書かれているかも合わせて見てみましょう。