手順不足と知識不足は分けて考えた方がいいと思う話

はじめに

プロジェクトでメンバーが詰まったとき、「手順書を追加する」「手順書を詳しくする」という対応が行われることがあります。

もちろん手順不足が原因の場合もあります。

しかし、実際には知識不足が原因で詰まっているにもかかわらず、手順書で解決しようとしているケースも少なくありません。

私は、手順不足と知識不足は切り分けて考えるべきだと感じています。

本記事では知識を「プログラミング言語やフレームワークなど、作業を実行するために必要な一般的な技術知識」として扱います。業務知識やプロジェクト固有の知識については別の論点となるため、本記事では対象外とします。

手順不足とは

手順不足とは、「何を行うべきか、どの順番で行うべきかが定義されていない状態」です。

例えば、新しいメンバーがプロジェクトに参画した際、「どのツールをインストールするのか」「ソースコードをどこから取得するのか」「設定ファイルをどこから入手するのか」が定義されていない場合です。

この場合、開発に必要な知識を持っていても、環境構築の進め方が分からず作業が止まってしまいます。

知識不足とは

一方で知識不足とは、「必要な作業内容は分かっているが、実行に必要な技術的理解が不足している状態」です。

例えば、次のようなケースです。

• 必要な修正箇所は分かるが実装方法が分からない
• エラーメッセージの内容を読み取れない
• 言語やフレームワークの使い方が分からない

このような場合、手順は存在していても、それを実行するための知識が不足しているため作業が進みません。

なぜ混同されるのか

手順不足と知識不足は、どちらも「メンバーが詰まる」という形で現れます。

作業が止まったり、質問が発生したり、想定より時間がかかったりといった状況です。

私自身、現場で他のメンバーからの質問に対応することもあれば、逆に自分から質問することもあります。

その中で感じるのは、「手順が分からない」のではなく、「手順に書かれている内容を実現するための知識が不足している」ケースが意外と多いことです。

しかし、外から見るとどちらも作業が止まっている状態に見えるため、原因が十分に切り分けられないまま「手順を追加しよう」という話になりやすいように感じています。

混同すると何が起こるのか

手順不足と知識不足を混同すると、知識不足の問題に対して手順書で解決しようとすることがあります。

知識不足に対して手順書を追加し続けると、特定のケースに対応した説明が増えていきます。

その結果、手順書が肥大化し、本来は簡潔に済む作業まで大量の説明の中から探さなければならなくなることがあります。

問題の原因を誤認すると、適切な対策を講じられず、同じような詰まりが繰り返されることになります。

よくあるパターン

「手順書通りに実装してもエラーが出る」という相談を受け、調べてみるとフレームワークやライブラリの使い方そのものへの理解が原因だった、というケースです。

これは特定の誰かに限った話ではなく、新しい技術や経験の浅い分野であれば、私自身も含めて誰にでも起こり得ることだと思います。

ただ、こうしたケースに対して「手順書にフレームワークやライブラリの使い方を追記する」という対応を重ねていくと、特定の事象向けの補足や確認項目が少しずつ増えていき、手順書を読む負担が大きくなっていきます。

一方で、根本原因である技術的な理解の部分は、あまり改善されないまま残ってしまうことが多いように感じます。

解決方法は異なる

手順不足と知識不足では、必要な対策も異なります。

手順不足であれば、

• 作業フローの整備
• ルールの明文化
• チェックリストの作成

などが有効です。

一方で知識不足であれば、

• OJTやペア作業によるフォロー
• 技術情報の共有
• 学習機会の提供

などが必要になります。

手順書は「何をするか」を示すもので、知識は「どう実現するか」を支えるものです。

両者は似ているようで役割が異なります。

まとめ

メンバーが詰まったとき、まず考えるべきなのは、手順不足なのか知識不足なのか、という点です。

手順不足であれば手順を整備する。

知識不足であれば学習や教育で補う。

この切り分けを行わずに対処を続けると、手順書だけが肥大化し、本質的な解決につながらない状態になりがちです。

問題を正しく解決するためにも、原因の見極めを意識することが重要です。