チームでレベルアップする！共通言語を最大化する業務標準化のマイ極意！
この記事はファンタラクティブ2024年アドベントカレンダー 12月16日の記事です
はじめに
こんにちは、ファンタラクティブでエンジニアリングマネージャーをしているyagikoです。
アドベントカレンダーでは12月3日に記事を投稿して、2度目の投稿になります。
前回は個人を対象に、いかに自身の働きを他者に認知させ、関心を持ってもらうかを記事にしました。今回は、チーム・組織に軸足を移し、本題にある業務標準化・ナレッジ共有について自分なりに整理してみました。なお、本記事は会社や役職とは関係なく現時点でのわたし個人の考えになります。
「標準化」とは
標準化とは、「そのままでは多様化・無秩序化してしまう対象を整理し、秩序化すること」をいいます。その対象を業務に落とし込んだものを業務標準化と呼び、本記事ではこの業務標準化を以降「標準化」と表記することにします。
具体的な活動としては、業務に関するマニュアルや手順書の作成があります。入社時のオリエンテーションでは、出退勤や経費精算などの手続きをドキュメントを通して社内担当者から共有されますが、そうした資料や共有も標準化の一環といえます。
メンバー共通で使われるものもあれば、デザイナーやエンジニア、プロジェクトマネージャーといった職種別や、プロジェクトや案件ごとにマニュアルや手順書が用意されることもあります。作られる種類や数は、会社や組織によって異なります。
標準化の目的
標準化が組織内のメンバーに向けて進められる目的として、「業務の均一化」と「属人性の低減」があります。
業務の均一化
標準化によって、個々人がやっていたことが明文化され、適宜行っていたことの是非について評価しやすくなります。
エンジニアだと、DBからデータを取得する際にいくつかのアプローチが考えられます。それが手順化されていないと、Aさんは〇〇のやり方、Bさんは△△のやり方と個々人で判断して進めます。すると、詳細が詰め切れていない場合、それぞれの集計結果が異なってしまうことがあります。
そういったことがないようにあらかじめ手順書にまとめておくことで、初めて扱う人も迷わず進めることができ、一定範囲の期待結果に収束させることができます。
属人性の低減
属人性とは、「業務に従事する担当者しか知識やノウハウを有していないこと」を指します。仮に、あるプロジェクトでAさんが中心的な立場にいるとします。ただし、Aさんが病気でプロジェクトを離れることになった場合、Aさんがやっていたことが分からなかったり、Aさんの立ち位置を担える人がいなかったりすることが挙げられます。
ただ、ここで「低減」と書いたのは標準化で一定以上その割合を下げることはできても、完全に排除・脱却するのは難しいと考えています。その人の知識をマニュアルなどで補うことはできても、個人のパーソナリティや経験を代替し、踏襲するのは困難だからです。
わたし個人の考えですが、入社時点やその後の経験を通じて、どうしても個々人の知識や能力には偏りが生じるものだと思います。それは標準化によってある程度埋めることができても限界があり、偏り自体はなくならないだろうと考えます。
標準化の効果
標準化のメリット
標準化を行うことでどのようなメリットが生まれるのか、大きく分けてメンバーと管理者(マネージャー)側にもたらされる点をいくつか挙げてみました。
メンバー側のメリット
経験値の浅い人が戸惑うことを減らせる
心理的安全性が上がる
生産性の向上
引き継ぎ作業の簡略化
周りができることで新しくチャレンジができる
マネージャー側のメリット
特定個人に依存しすぎないアサイン体制
案件における人の入れ替えが考えやすくなる
標準化をもとに一定の水準が生まれる
まず、メンバーの観点で見ていきます。
入社したばかりの人が何かの業務をするときにマニュアルがあるとスムーズに着手することができますし、資料があることで心理的に安心も得られます。それから、一から調べる手間が省けて生産性が上がり、あらかじめ資料を用意することで配置換えになっても後任への引き継ぎがスムーズに行えます。
5つ目のチャレンジができるというのは、マニュアルがあることで周りも少しずつ理解できる体制ができてきます。そうすると、当人は属人化された領域から離れ、さらに異なる領域やプロジェクトに専念する機会を得られるのではないかと考えます。
次に、マネージャー視点で考えてみます。
マニュアルや手順書によるナレッジ共有が行われることで、Aさんは〇〇に強いからという理由で固定化しがちなプロジェクトのアサインについて一定度の選択肢を増やせると想定されます。そして、それにより進行中の案件状況を鑑みて、人を入れ替える判断も取りやすくなりそうです。
最後に、こういったマニュアルや手順書が作られることで、メンバーが〇〇や△△を扱えるようになってきていることを知り、それを使って営業の話題に組み込んだり、評価基準、採用情報への反映にも活用できそうです。
このように、標準化がうまく回ることで組織内の「共通言語・共通認識の最大化」を図ることができるところが利点になるでしょう。そして、標準化は一定のラインまで認識を引き上げて終わりではないと考えます。その後使うツールが変わったり働くメンバーの経験値や認識も引き上がってくるので、そこで再びマニュアル作成及び作成した資料の共有を経て、認識の基準をさらに引き上げます。そうすることにより、組織全体の強度も上がってくるのではと推察します。
とはいえ、これらには一部の理想も含まれていて、ただマニュアルを作るだけでなく、資料の品質や組織への浸透も実現に大きく関わってくると感じています。
標準化のデメリット
一方で、標準化活動にもデメリットがあります。考えられる点としては、大きく以下の3つが挙げられます。
標準化の型にはめられて制約を受ける感覚になる
ドキュメントのメンテナンスコストがかかる
ドキュメントが放置されがちになる
標準化というのは、ある業務における型化を行うものであり、その型に窮屈さを感じたり、自由に進めたいと感じる人も少なからずいるかもしれません。そして、資料作成によく見られる問題としては、作り上げるのに時間を割かれることや、それを作っても存在が忘れられ、型が陳腐化してしまうことが挙げられます。
こういったデメリットが起きる背景として、関係者の標準化に対する理解不足や標準化の形骸化といった課題が潜在的にあるものとわたしは推察します。
標準化とどう付き合うか
では、どのようにしたら標準化を導入できるようになるでしょうか。先ほど挙げた課題のアンサーにはならないかもしれませんが、個人的な見解を多めに含めて、何ができるのかを考えてみました。
目的と効果を説明する
まずは標準化を進めることの意義を関係者に周知し、理解を促す必要があります。そうでないと、先のドキュメントの放置を誘発する可能性があるためです。
そして、こうした説明を1度で済ませるのではなく、定期的あるいはイベントのタイミングで行うのが望ましいと思います。
扱いやすい題材から
はじめにドキュメントを作る際に、資料全体をどう管理するか、どういうカテゴリーにするかを考えることがあります。それが最初に決まっていると進みやすくなりそうですが、あれこれと考えているうちに作り始めるスピード感が落ち込むことも想定されます。
全体の構成を考えてもあとあとになって構成が変わってくることはあり得るため、まずは課題に感じたところからマニュアルを作っていくのが良いと感じています。
フットワークを軽くし、資料の構造を含めた改訂を定期的に行うことで、ライトに進められるでしょう。
小さくまとめる
ドキュメントを書いていると、あれもこれもと書き込んで結果かなりのボリュームになることがあります。そうした資料を作ってもらえるのは大変ありがたいのですが、ボリュームが多いと読む側の負荷に転じます。
できれば、資料は2～3枚以内に収めるように作ると、参照する側にとっても把握しやすくなるでしょう。公開する情報の取捨選択は、作成する人が意識する必要があると考えます。
ですが、どうしても扱う内容が広く深いなどでドキュメントが長大になる場合は、冒頭にサマリ・目次を用意したり、中項目・小項目に区切ってドキュメントをいくつかの章に分けてボリュームを抑えつつ、検索性もある程度維持することを検討するのが良いです。
ドキュメントを書くことに慣れていなくても、最近ではChat GPTなどの生成AIツールがあります。そこからのアウトプットをそのまま使うことは推奨されませんが、題材と字数制限をプロンプトに組み込んだらそれらしいものができてくるはずです。そうしたドキュメントの流れを参考に、自分の業務に置き換えつつ書き直してみるのも有効な手段だと感じます。
口頭説明も視野に入れる
ナレッジ共有でありがちなのが、マニュアルを作った後に誰にも共有しない、もしくは全体周知だけで終わらせてしまう点です。誰にも共有しないのは論外ですが、Slackなどで一斉に共有しても一部の人は全く読まなかったり、読んでも流し読みになるケースが想定されます。
それであれば、「〇〇に関する手順書を作りました。この日に説明する場を設けたいと思います」のように口頭説明を15～20分程度設けるのも有効ではないかと考えます。
確かにテキストベースの共有は、非同期で読むことができて依頼して終わりのため気が楽です。ただ、ドキュメントを通じて一定の理解度を揃えるのであれば、個々人に読む時間を5～10分取らせるよりも、20分程度の口頭説明の方が経緯も交えつつ説明できるので浸透しやすくなりそうとわたしは考えます。
また、こうした機会により伝え方を工夫したり、その場の質問から再考し、フィードバックする、といった副次効果も期待されます。
棚卸しをする
標準化の大敵は時間です。時間がドキュメントを風化させ、その資料の存在自体も忘れられてしまいかねません。それに対して考えたのが、これを小売店舗の在庫と同じように見立てて、一定の期間ごとに棚卸しをするのはどうかということです。
年末の締めくくりだったり、あるいは期初の落ち着いてくるであろう時期にドキュメントの棚卸しを予定として登録し、複数人で一斉点検するというものです。
その手間が面倒という声はごもっともです。ドキュメントが増えるとその分確認する量も増大します。それをある程度制御するために、棚卸しの時にそのドキュメントを更新あるいは削除を検討すると良いでしょう。部屋の整理整頓と同じようにモノが増えたらその分捨てる、ドキュメントを増やした分は削除する判断も必要になると考えます。
活用する場を増やす
これは個人的なアイデアになります。どうしてもドキュメントを作っても目に触れない状況が生じることがあります。であれば、積極的に活用する場を増やすために、イベントに組み込んでみるのはどうでしょうか。
例として、エンジニアの場合は入社時のオリエンテーションでGitHubの設定方法やコーディングガイドラインの資料を共有し軽く読み合わせをします。これだけでもドキュメントが人の目に触れることになりますし、もしかしたらそこで新しく入った人から、ドキュメントに書かれていない質問や手順が古いためにアップデートが必要だという意見が出てくるかもしれません。
それはそれで、資料を改善する良いタイミングになりますし、入社した人にとってもコントリビューションチャンスになります。そこからその人を巻き込んで改訂のためのヒアリングや既存メンバーへの共有といったコミュニケーションへの導線にもなり得そうです。
さいごに
ただ単にマニュアルを作る手段に走る前に、まずは標準化の目的や意義を見つめ直し、その上で楽にドキュメントを適度に作る、あまり細かく書き込むよりも読み手に丁寧な余白をとることが肝要だと思います。
とはいえ、こうした標準化活動は地味ですし業務外にかける労力もそれなりに要ります。できたドキュメントを読んで利用する人にとっては、ドラクエでいうところの経験値が2〜3上がる程度なのかもしれません。
それでも、そうした活動が積み重なり、やがてチームや組織にとっての財産、意識共有のツールになっていくことを願っています。
(インドの元大統領、アブドゥル・カラームの名言)
次回は、誰が呼んだかファンタラクティブ唯一にして炎のカスタマーサクセス 兼 DIY本部長であるモロさんの記事になります！どうぞお楽しみに！！