私のITエンジニアとしてのキャリアでは、先行で新しい技術の検証を行なって、組織やチームに推進する担当になることが数多くありました。
最近では、IT技術に関するスキルやナレッジをエンジニアではない方にも教えてメンバー全員の知識の底上げを依頼されたりすることもあります。
同時に、さまざまな業務現場を見ましたが、どこも悩ませているのが、技術系であればシステムの仕様書や設計書、非技術系だと業務マニュアルのような、メンバー間のスキルやナレッジの共有管理だったりしました。
この記事では、私の経験上このようなスキルやナレッジの共有浸透のために実践していることをご紹介できればと思います。
目次
マニュアル作成管理徹底より作業ログのドキュメントを残す文化を作る
ナレッジ共有というと、とにかく業務マニュアルを作り管理を徹底させることを強調する組織もありますが、私個人はあんまりマニュアル作成と管理にこだわりすぎるのは好きではないです。
それよりも、各種任された業務の作業メモや作業記録を残す文化を作ることを進めています。
マニュアルがなくても、過去の作業ログの閲覧が業務マニュアル代わりになる
経験則上、マニュアルがなくても過去の作業ログを読んでいけば、業務上抑えておくべきポイントは大体理解できることが多いです。
言うまでもなく、作業ログを理解するために最低限の手順などを覚える必要があります。そのため、業務マニュアルの管理はそういった最低限に抑えて、その代わり作業ログは業務メンバーならだれでも閲覧できるような状況にする文化を作るように推進しています。
マニュアルよりも作業ログの方が執筆コストが低く、メンバー間の執筆モチベーションが高い
この種の業務設計や管理をやったことなら誰でも悩むことですが、マニュアル管理はとても大変です。
そもそも、新しく入られた方向けにあるものであってその業務に慣れている人にとっては不要なものになります。
加えて日々の業務は日進月歩で改善が進められるため、せっかく労力かけてマニュアルを作ったとしても、定期的にメンテナンスをしなければいけません。
一方で、作業ログのドキュメントは依頼されて、責任もって遂行しなければならない業務の手記であるため、そもそも記載するモチベーションがマニュアルと全く違います。
そのため、マニュアル管理の徹底を推進するよりも、作業ログの記載と保存をメンバーに推進していくほうが文化として浸透しやすいという特徴があります。
ITソリューションを活用して検索性よくする
保管した各種作業ログドキュメントはなるべくITソリューションを使って検索性の良い環境を作って利便性を高めたいです。
新しい組織でナレッジ管理をすすめるのであれば、できれば最初からAtlassian社のConfluenceのような検索性の良いWikiツールを使って管理したいです。
もっとも、従来からある組織で、少なからず個々人がWordやExcel、メモ帳のテキストファイルなどで作業ログを作っていたような組織であれば、いきなりWIKIツールに移行する必要はないと思います。
最近のストレージサービスは、WordやExcelの中身まで検索してくれるので特にフォルダや中身の管理ルールを作らなくても簡単に検索して欲しい情報を見つけることができます。
そのため、最低限、今まであるドキュメントをGoogleDriveやBoxといったストレージサービスに移管して管理させるだけで解決できます。
類似の先行事例としてのマッキンゼーのPD
こうした過去の作業ログドキュメントの管理にフォーカスすることに関する類似の先行事例としてマッキンゼーのPDという取り組みがあります。
※PDについては以下の記事や書籍など、さまざまな場で紹介されていますが、正式名称は「Practice Development」や「Practice Document」など紹介する場所によって異なっており、諸説あるようです。
「なぜマッキンゼーの人は年俸１億円でも辞めるのか？」の著者である田中裕輔さんによると、マッキンゼーの取り扱うコンサルティング業務の性質上、社員間でも厳しい守秘義務が課されるため、業務共有することが非常に難しいという課題があったそうです。
そのためマッキンゼーは各クライアント案件が終了するごとに、企業ナレッジとして全社員に共有できるように、各案件で経験した学びをPDに記録して全社員が閲覧できるようにデータベース管理する取り組みを行なっていると述べております。
このようにして、マッキンゼーの社員はPDの活用を通じて、類似案件の業務ナレッジ共有を行なっていると紹介しています。
学びと作業ログで違いがありますが、作業ログの記録管理もこのマッキンゼーのPDと目的や効果は同一を私は思っております。
文章より関係図
前述のように、マニュアルは最小限にしたいです。そして最小限にしたマニュアルの中でも大事にしたいものは文書ベースのマニュアルよりも、業務における重要事項の関係図です。
関係図というと重々しい表現ですが、システム開発においてはシステム構成図、事務業務であれば業務フロー図、といった各種ビジネスフレームワークにあたります。
これを押さえることによって、主にこんな利点があります。
認識を共通化しやすい
やはり、文章より図の方が認識を共通化しやすいです。誤解が生じにくくなります。
検索して過去業務ドキュメントを調べるうえでの指針になる
前述のように、私はマニュアル管理徹底より、過去の業務ログの保管徹底を重視しています。これには、いくら文章で細かい業務エッセンスを盛り込んでも理解や認識に差異がでてしまいやすいことやメンテナンスに過大な負荷がかかるためです。むしろ細かいエッセンスやポイントは先人の業務作業の手記を読んだ方が臨場感があってより深い業務理解を得られると考えているからです。
それゆえに、基本的に、まずはドキュメントを検索して探すということを主眼に置いています。その時に、マニュアルとして業務全体の関係図だけは持っておけば、検索をする上での手がかりや指針となり検索効率が上がります。
業務マネジメントをするならば、関係図は最低でもこまめにアップデートして管理したいと思っています。
業務内容共有を目的とした勉強会を定期開催してみる
もう一つ意識していることとして、業務内容共有を目的とした勉強会の定期開催です。
私は特にナレッジ共有のために以下２つのことを意識して行なっています。
知識共有というよりは、苦労話・愚痴などを語ってもらう
ある程度真面目な方が揃っている業務環境であれば、本当に必要な知識などは、勉強会など開かなくても各個人自主的に調査したり勉強して学習しています。
そのため、むしろ苦労話や愚痴を語ってもらうようにお願いしています。
意外とその人が経験した苦労や愚痴の中に、どのように解決したのかその人自身のテクニックなどが隠れていたりすることがあり、そうした経験を語り合う場にした方が集合して集まる勉強会では有効と思っています。
発表ハードルをなるべく低くする
上述のように苦労話、愚痴を語ってもらうために、発表ハードルはなるべく低くなるように準備しています。いわゆるライトニングトークという５分くらいの短い発表にしたり、そもそも発表資料作成不要にしたりしています。
また心理的安全性の低い場にしたほうがいいと思うので、傍聴する人も、途中入退室OKにしつつ、一方で発表者の批判などはしないというルールを作ったりしています。
専門スキルはカリキュラムに基づいて個人ベースで
最後に、初心者からのプログラミングスキル習得、簿記スキル取得といった専門スキルについては、集合の勉強会でやるよりは、何らかの専門カリキュラムを用意して個々人でできる環境にしたいと思っています。
集合勉強会などでは個々人の習熟度によってばらつきがでてしまう
初歩的なオリエンテーションであれば、集合勉強会のハンズオンでなんとかできます。しかしながら、第二ステップとなると、集合勉強会で学んだ人の中でも習熟度にばらつきがでてしまいます。
そのため、集合勉強会では効率が悪く、個々人ベースで学んでいくための道筋をたてて支援していく形になります。
個々人ベースで支えていくとなると、個別レッスンはさすがに骨が折れるので、たいていは自力で勉強できるオンライン講座や書籍を与えて、独自で自習させつつわからないものがあれば、質問相談という形にしています。
やはり専門スキルは自分であれこれ考えて実践して自分のものにしてもらわないといけないです。そのため自主的に学んでもらいつつ、困った点、難しい点について質問して助けていくという方式のほうが良いと思っています。
終わりに
最後まで読んでいただきありがとうございました。ひょっとしたら、どこの組織でもすでに実践していることかもしれませんが、何か気づきがあれば幸いです。
Photo by Benjamin Child on Unsplash
