I/O BLOG;

input を整理して ouput する訓練ブログ

「継続的な改善」のための「引き継ぎ」の話

導入

すこし前に琉球大学情報工学科 新入生歓迎LT祭り 2014というイベントがありました。
そこで、ノウハウが引き継ぎされていないことを、フィードバックしました。
実はよくあることで、仕事上でも「うまく引き継ぎされてない」状況に多々遭遇したことがあります。
とても苦労する状況です。
引き継がれた方は、前任者と同じかそれ以上の労力を使って、現時点の状況を自分の中で「再創造」する必要があります。
また会社として「継続的な改善」が出来なくなるのが辛いところです。
下手な引き継ぎによる情報のロストが、PDCAのサイクルを振り出しに戻してしまうからです。
そうなるとなかなか業務改善が進まず、悪循環に陥ってしまいます。
そこで、どうしたらスムーズに引き継ぎできるか考えてみました。

ちなみに引き継ぎ自体に多大なリスクとコストがかかるので、なるべく発生しないのが望ましいですが、 組織やコミュニティが代謝していくなかでは、どうしても必要になってきます。

結論

結論から言うと、スムーズな引き継ぎを行うには

  • 日頃から大量のコミュニケーションをする
  • 中間成果物を絶えずアウトプットする

ということだと思います。
形式的に一度ですべての情報を落とし込むことは難しいです。
泥臭いですが、日頃から引き継ぎの情報になりうるモノをアウトプットするのが良いです。
そのためのコミュニケーションと成果物が重要になります。
アジャイルな思想を借りると、完璧でなくてもいいので、ひとまずアウトプットすることが重要になります。
そして、完璧ではないので「正確さ」は「繰り返しの量」で補います
そんな話をしてみたいと思います。

「継続的な改善」 と 「引き継ぎ」

突然の異動

ある日突然の異動が命じられて引き継ぎ期間は一週間です。とか辛いですね。
一週間あれば多い方でしょうか。
慌てて引き継ぎ用の資料を用意して、内容を引き継ぎ先の方と確認と打ち合わせ。
キチンと引き継ぎしないと、異動後も業務こなしながらの問い合わせが重なってしまいます。

引き継ぎのリスク

先述しましたが、良くないことの一つは、PDCAが振り出しに戻ることです。
前任者が築いてきたノウハウは一週間程度では引き継ぎ不可能です。
引き継ぎ先の方が、前任者と同じ経験をもう一度して、ノウハウを「再創造」しなければなりません。
また、引き継ぎ先の方が必ずしも、同じノウハウに辿り着けるわけではなく、より良くなる場合もありますし、より悪い状況になってしまう場合もあります。 業務の内容にもよりますが、知的労働に近ければ近いほどそういった引き継ぎは難しくなります。
ソフトウェア開発等では一ヶ月でも足りないぐらいかと私は経験から感じています。
引き継ぎ元と引き継ぎ先の方の技術力にも影響しますが。

引き継ぎのポイント

上記の場合など、引き継ぎには

  • ドキュメント
  • コンテキスト

が重要です。
ドキュメントはいわゆる引き継ぎ資料です。
簡潔で明確で、最新な内容でないと行けません。抜けがあるととても苦労します。
もう一つ大切なのがコンテキストです。現在の状況にいたる経緯が大事です。
同じ現時点の状況でも、それまでの経緯つまり、コンテキストを理解しているとまったく違う見え方になります。
また、コンテキストが共有されていることで、ドキュメントの行間が読み取れるようになります。
コンテキストが共有されることで、複数人が同じ体験をし、ノウハウを同時に創造します。
それはつまり「本質」を理解しているということになります。
完璧なドキュメントは書くことはできません。すべて形式的にコミュニケーションすることは難しいです。
それなので、ドキュメントなどの形式的な知識、「形式知」の漏れを埋めるために、暗黙的な知識である「暗黙知」を利用することが良いと考えています。 そして形式知暗黙知を常時アウトプットするのが望ましいです
その際には内容は完璧でなくてもいいです。
途中でもいいです。途中なんだと言うだけで ok です。

ドキュメントをキチンと書くには

結城先生の言葉をかりと 読者のことを考える です。

ポイントとしてざっと以下の様なことがあげられるかなと考えました。

  • 誰に対してのドキュメントなのか
  • 何をもっとも伝えるべきか
  • 数学的な唯一性があるか

とにかく読者のことを考えて洗練された文書がかけるかどうかが重要になってきます。
書いて書いて、レビューをもらって鍛錬するのがいいでしょう。

コンテキストの共有を行うには日頃のアウトプット

残念ながら上述のケースのように、引き継ぎが決まってから引き継ぎを始めると時間が足りない場合が多々あります。
どのタイミングでも、誰にでも、引き継ぎができるようになるのが私の理想とする所です。
それなので、日頃から完璧でなくてもいいので、中間成果物やドキュメントをアウトプットする必要があります。
加えてドキュメントの不足を補うコンテキストを共有する必要があります。
コンテキストの共有を行うには、「時間」が必要です。
そもそも人間がお互いの考えていることを理解し合うのは難しいです。
なので、時間を掛ける必要があります。

日頃から何をどう考えて業務を行っているかを常に共有する必要があります。
例えばソフトウェア開発などでは、技術の進歩がはやく、開発のパラダイムが流動的です。
何を考え、どこに向かっているか、方針だけでも常日頃から共有しておく必要があります。

どうやってその部分を共有するかというと、とにかくコミュニケーションすることです。
圧倒的な量が必要です。 方法はこうです。

ありとあらゆるサービスと機会を利用してコミュニケーションします。
内容はできる限り、引き継ぎが起こった場合に、引き継ぎしたい内容に近いところがいいです
現状業務を整理した内容でもいいです
周辺知識や技術でもいいです
そして必ずしも、両方向でコミュニケーションする必要はありません。
他人から参照可能であれば、効果はあります。
これは記録を残す意味でも有効です。
常に最新の情報となることも利点です
常時、記録を続けるとそれは コンテキスト になります。

※もちろんオンとオフを分けて、休むときは休みましょう

日頃アウトプットのメンタリティ

ここで、大事なメンタリティ として、指摘を恐れない ということがあります。
人はだれでも失敗したくありません。他人からできないやつだとおもわれたくありません。
なので、中途半端なアウトプットはしたくありません。
しかし、そこはグッと堪えます。かんばりましょう。
以下の理由があります。

  • 完璧を目指すとアウトプットが遅れます。
  • どうせ完璧にできません。
  • 途中経過が参照ができません。
  • レビューが遅れます。

アウトプットする際にこれは途中だといってしまえばいいです。
いつどこで、引き継ぎしなければならなくなるか、わかりません。
大事に温める利点はどこにもないのです。
その時のベストを出していきましょう
傷つくのは自分のプライドぐらいです。

まとめ

引き継ぎがうまくいかないと、「継続的な改善」ができないことを説明しました。
引き継ぎを行うには、いつ引き継ぎしてもいいように日頃のアウトプットと、そのメンタリティが重要です。
そうすることで、組織やコミュニティが人の入れ替わりによってPDCAが振り出しに戻るリスクを減らすことができます

番外編

ソフトウェア開発の視点から得た「継続的な改善」

「継続的な改善」とは

ソフトウェア開発プロセスとしてフォーカスされている考え方です。

これらの開発モデルの狙いは

  • 早めに失敗して後々の大きな失敗を防ぐ。
  • 継続的に失敗と改善を繰り返して、ソフトウェアのカオス化を防ぐ。
  • 漸進的に見積もりができる
  • どこで切り上げても成果物がある

というものがあります

特徴として

開発段階毎にすべてが完璧になってから、次の段階に進むわけではなく優先度の高いものから 漸進的に開発を行い、そのサイクルで「継続的な改善」を行います。

サイクル自体が短いので、どのタイミングでも成果物がある程度揃っています。

複雑で巨大なプログラムを秩序を保ちながら開発していくために、有効な手段と言われています
また単に PDCA を素早く回すための開発プロセスと言ってもいいかもしれません。
根本は PDCA にあるので、ソフトウェア開発だけでなく普通の業務にも適応できると考えています

このプロセスを元に業務を進めていけば、引き継ぎによる情報のロストを最小限に抑え、「継続的な改善」を行うことができるのではないでしょうか。