環境構築の手引きが古くなる理由と、隣で1回やる進め方

新しく入った方が、環境を用意するだけで1週間を使ってしまう。この現場を何度か見てきました。原因は書き手の腕前ではありません。手引きという形そのものに、無理があります。

同じ内容でも、書いて渡すか、隣で一緒にやるかで、かかる時間が桁で変わります。この記事では、なぜ手引きが古くなるのか、代わりに何をしているかを書きます。

前提

想定しているのは、社内の方に開発の環境を用意していただく場面です。エンジニアではない事務や営業サポートのご担当が対象です。

道具の名前や具体的な手順は書きません。どの道具でも同じことが起きるからです。

なぜ手引きは古くなるのか

手引きは、たいてい一番詳しい人が書きます。

その人にとって当たり前の手順は省かれます。「もちろん先にこれを入れてありますよね」という前提が、書かれないまま残ります。書いた本人は無意識なので、省いた自覚もありません。

しかも、書いた時点の画面と道具が前提です。

半年経つと、道具のほうが更新されます。画面の名前が変わり、ボタンの位置が変わる。書いた本人は最新のやり方を知っているので困りません。困るのは、手引きだけを頼りに進む人です。

手引きが更新されないのにも理由があります。

書いた人はもう使わないので、古くなったことに気づきません。使う人は、そもそも正しい手順を知らないので、書いてあることが古いのか自分が間違えているのか判断できません。

この構造がある限り、手引きは放っておくと必ず古くなります。

実際に時間を食っているところ

詰まるのは、手順の理解ではありません。

日本語の表示が出ない。回線が遅くて待たされる。有料のアカウントが部署に1つしかなく、使ってよいか確認が要る。この種類が、実際にはいちばん時間を食います。

これらは、手引きに書きようがありません。

会社ごとに事情が違い、そのときにならないと分からないからです。書いた人が経験していない詰まりは、当然ながら書かれていません。

もうひとつ多いのが、選択肢が出たときです。

「AとBのどちらを選びますか」と聞かれて、どちらが自社に合うか判断できない。ここで手が止まります。詳しい人なら数秒で決められることが、初めての人には決められません。

隣で1回やる

やり方を変えました。手引きを配る代わりに、隣で一緒に1回やります。

ある会社では、非エンジニアの方2名のパソコンに開発環境を用意する回を設けました。画面を共有しながら、詰まったところをその場で解いていきます。

2時間ほどで、2名とも自分のパソコンで動く状態になりました。

一緒にやる利点は、判断をその場で渡せることです。

選択肢が出たら、なぜこちらを選ぶのかを説明しながら決めます。1回説明を受けていると、次に似た場面が来たとき自分で決められます。

会社ごとの事情も、その場で分かります。

このときは、有料のアカウントが部署ごとに1つしかありませんでした。他のチームのものを流用すると影響が出るので、システム用に新しく発行することにしています。

こうした社内調整は、手引きを配る形だと、詰まってから相談が来ます。一緒にやっていれば、詰まる前に手を打てます。

手引きには「なぜ入れるか」を書く

手引きを捨てたのではありません。書く内容を変えました。

何を入れるかだけでなく、なぜ入れるのかを書きます。理由が分かっていれば、画面が変わっていても目的から辿れるからです。手順だけだと、画面が1つ違うだけで止まります。

理由を書いた手引きは、古くなり方が穏やかです。

画面が変わっても、目的は変わりません。「この道具を入れるのは、複数人で同じものを触るときに上書きし合わないため」と書いてあれば、画面が違っても探せます。

いまは、伴走の最初にこの手引きをお渡ししています。

回を重ねる前の準備として、何を入れるか、なぜ入れるかを読んでいただく。そのうえで、実際の作業は一緒にやります。読んで分かる部分と、一緒でないと進まない部分を分けた形です。

まとめ

手引きが古くなるのは、書き方が悪いからではありません。書いた人が使わなくなり、使う人が正しさを判断できない、という構造があるからです。

実際に時間を食っているのは、その会社固有の詰まりと、判断が要る場面です。どちらも手引きには書けません。

新しい人が入ったら、最初の1日で何に時間を使ったかを聞いてみてください。作業そのものではなく準備で潰れているなら、手引きを直すより一緒にやるほうが早く終わります。