TOUCH THE SECURITY Powered by Security Service G
2019年11月1日株式会社エーピーコミュニケーションズとパーソルクロステクノロジー株式会社の合同イベントとして“手順書Night”を開催しました。
会の発起人は、エーピーコミュニケーションズの横地晃（よこちあきら）氏と、弊社パーソルクロステクノロジーの岩井大祐です。横地氏は、同社のテクニカルエバンジェリストとして近年Ansibleをテーマ軸とする執筆・講演活動などを精力的に行っていますが、横地氏のとあるツイートにガッツリ反応した岩井が、社を超えたコラボを提案し、今回の開催に至りました。
イベント会場は弊社ではなく、エーピーコミュニケーションズの社内スペースをお借りしました。ステージを社外に設定することで、外部登壇の場として社内の皆に提供したかったのは、今までと変わらないスタンスです。
いざ社内で参加者を集ってみたところ、IT・機電の双方の社員から手が上がり、「違う分野の手順書を知るきっかけ」というコンセプトも加わりました。
記事後半では、今回開催した「手順書Night」のお話を主催者である私自身としても改めて開催の趣旨に触れつつ、今年の振り返りの一部とさせて頂こうかと思います。
弊社岩井（左）とエーピーコミュニケーションズ横地氏（右）。
横地氏の活動については「てくなべ」をご確認頂きたい。
会の発起人はエーピーコミュニケーションズの横地晃（よこちあきら）氏と弊社パーソルクロステクノロジーの岩井大祐。横地氏は同社のテクニカルエバンジェリストとして近年Ansibleをテーマ軸とする執筆・講演活動などを精力的に行っていますが、そんな氏のあるツイートにガッツリ反応した岩井が、社を超えたコラボを提案。今回の開催に至ったものです。
そもそも手順書とは？
手順書は、業務およびタスクを行う手順をドキュメント化し、どのエンジニアであっても同じ質で作業できるように、業務や作業の内容が明文化されたものです。作業計画書や作業手順書と呼ばれることもあります。
エンジニアチーム全員が業務を統一して進められる、特定の人しか作業手順が分からない状況を防げる、新人に教える手間を大幅に削減できるなどのメリットがあります。一方で、手順書は常に更新しなければ運用できなくなったり、例外の出来事が起きたときに（ノウハウ不足によって）対応できない人が増えてしまう可能性が出てしまったりするデメリットがあります。また繰り返し行うような業務であれば手順書は有効的に機能しますが、そうではない場合に効果が発揮されないといったデメリットもあります。
しかし、手順書の大きな目的は、手順書を読めば業務の目的を達成できるというのが大事なポイントになります。そのため、手順書は目的達成のできる内容でドキュメント化して、内容が古くなったときには適宜修正や追記をおこなうことで優れた手順書が作られます。
手順書を巡る“あるある”や気づき
まず第1部、両社より5名のエンジニアがライトニングトーク形式で、手順書について様々な指摘を提示しました。
-
パーソルクロステクノロジー
- 先人の残した方法と手順を“神託”として個々人が無条件に受け入れてしまうと、スキルの低下にも繋がり得る。 / 渡辺 直史
- 書き手（開発部門）と読み手（運用部門）には手順の文書化に対する温度差があることも踏まえつつ、更新の方法には皆の合意が形成されていることが大切。 / 宮後 怜美
- 組込みソフトウェアに関わる者の観点としては、用語定義や搭載機能の記述に加え、故障に繋がる事例などにも触れておくことが必要。 / 阿部 耕二
渡辺（左）、宮後（中）、阿部（右）
-
エーピーコミュニケーションズ
- 手順を細かい粒度で（コマンドを打つに至るまでの流れなど）定義することは、一時的な負荷になる反面、結局は運用のコストダウンに繋がるのではないか。また、それを文書化することは後の自動化への布石にもなりうる。 / 中村 圭佑 氏
- 別紙（読み替える必要が流動的に発生する要素をまとめたもの、いわゆるパラメータシート）参照や過剰な画像などを極力減らすことで、読み手が注視すべきポイントを絞ってあげる観点も大切。全てのケースに当てはまるわけではないが、シンプルであることは重要。 / 伊藤 雅人 氏
伊藤氏（左）、中村氏（右）
両社エンジニア、それぞれの意見をまとめてみました。技術職に従事している方においては、これらの話には、何かしらの思いを持つこともあるでしょう。
“別紙参照”と変更管理の難しさ
ライトニングトークを踏まえ、会場全体を巻き込んだディスカッションで特にクローズアップされた要素の一つに「別紙化」が挙げられます。
クローズアップされた内容としては、「“別紙参照”は、どちらかというと作り手の都合を優先したものではないか」というもの。
動的要素を手順書に内包して読者コンシャスであろうとすることが、かえって変更管理上の問題を引き起こしてしまう、という課題がでてきてしまっているのではないかということでしょう。様々な意見や考え方が有り得るイシューですが、このとき比較的目立った意見としては、作り手・読み手どちらかに寄るのではなく「使い分け」が必要ではないか、というものです。
たとえば頻度が限定される計画作業ならば、動的な要素の記述を編集し続ける負荷も少ないことから、一冊にまとめることが可能です。そして、読者層が流動的な（非技術者の場合もある）作業についても、やはり一冊にまとめるべきではないか、といった意見です。
しかし、読者が固定されている、単独で作業しない等の条件が揃えば、別紙という方法を取らざるを得ないのではないか、それが大方の見方なのかもしれないという話といえるでしょう。
改善要望が上がる環境は整っているか
イベントが進み、横地氏からの1つの問いかけのイシューとして、「改善要望の上がる背景やその風通し」に関するものが挙がります。
改善を実施するトリガーについて、参加者からは、未然予防的な申告によるものではなく多くの場合オペミスの後に生じてしまっている、との意見が目立ちました。
特にミスに関わったとされる当事者は、改善のためのキーマンである一方、性格として委縮しがちという特性を持っていました。手順書を作成する側は、そういった場合でも、要望をうまく拾い上げる何らかの工夫が要求されます。
各人がそれぞれおこなっている工夫として、「当事者にヒアリングを行う際、その方自身への対策を行っている訳ではない旨を理解してもらい、率直な感想を引き出そうとしている。」といった試みもあれば「ヒアリングを行ってもうまく意見が拾えない時もある。その場合、こちらが良かれと想像する改編を加えるが、根拠には乏しく改善に繋がったか疑問が残る。」といった声もあり、現場の苦悩が垣間見える問いかけになりました。
外部を巻き込んで自らイベントを企画してみた結果
2018年頃、自身がJAZUG（Microsoft Azureのユーザーコミュニティ）の勉強会に参加・登壇させて頂く中で、漠然と感じたことが「自身のみならず、後輩たちも巻き込んで、アウトプットの有り方を更に模索できないものか。」というものでした。
当時、社内では有志による勉強会など活発な活動はあったものの、それが外部と繋がっていくことについては「いや、そんなことやっていいの？」といった抵抗をなんとなく感じていました。
JAZUGへの登壇は「ならば、とにかく前例を作ってしまえ」という発想から一念発起したものです。その甲斐もあってか、2019年9月のJAZUG 9周年イベントでは、弊社若手メンバーもライトニングトークに登壇デビューし、結果を残すことも出来ました。
登壇デビューを果たした弊社 山村のLTIntuneとWSUSを使ってWindows Updateをやってみる。より。
元々話すことは苦手としていたはずなのに、覚悟を決めてやってくれたのだから純粋にすごい！ from shotayamamura1
しかし、そもそも弊社は様々な技術領域に対して、キャリア年数もまばらなエンジニア達がそれぞれの想いで集う組織。全員をJAZUGイベントに誘導するというのも色々な意味でハードルが高いのが実情です。もう少しライトに、外部との接続を体験する場があっても良いのでは、と感じていた頃に、首尾よく出会ったツイートがこちら。
このよこち（yokochi）さんは、イベントの発起人でもあるエーピーコミュニケーションズのエバンジェリスト横地晃氏です。「コレだ！」と思いつき早速リプライしました。何度かのミーティングを経た後、「まずは“第0回”と称して、2社で共同開催してみるというのはどうか」という方向に話が進みます。
なぜ手順書がテーマに？
今回、なぜ手順書がイベントのテーマになったかというと、手順書という存在は、技術の領域、職種、キャリア年数を超えて誰もが目にして手にするもので、皆が参加しやすいためです。また、同じIT部門の社員だけでなく、弊社の機電部門の社員も巻き込むチャンスにもなるからです。
手順書は、一見地味な存在ではあっても、多くのエンジニアが毎日触れるものです。読む側や作る側など、立場はそれぞれ違えど、作成者も読者も何かしらのこだわりをお持ちではないでしょうか。
手順書Nightを苦労したこと、やってよかったこと
手順書Nightを開催して苦労したのは、やはり参加者を募ることでした。なかなか困難な状態でしたが、社内のイベントなどを通じてできたコネクションをきっかけに、登壇者になってほしいとアタックをかけます（我々、平時は現場がバラバラなのでここがいつも大変な部分です）。
おかげさまで、弊社では3名の賛同者（登壇者）を募ることができ、当日は内容的にもかなり盛り上がる結果となりました。
やってよかったこととしては、次回以降、場合によってはもっと多くの会社に参加を呼びかけることもできるかもしれないし、これを社内向けの議論・勉強会に落とし込むことも可能かもしれないと実感として思えることができたことです。とにかく色々な方向に広がりを持たせられる可能性を感じています。
また、当日はゲストに松林 弘治 氏（Vine Linuxの開発やInstagramの日本語化などに貢献している、著書も多数出版されている方）をお呼び出来て、運用業務目線とは違った切り口の意見を頂けたのも嬉しい誤算でした。「事前に言っておいてもらえれば、もっとちゃんとお話のネタを作りますよ」という心強いお言葉添えも、次回の弾みになりました。
まとめ ――“来年の私”がわかるように作る
誰もが関わる手順書について、役割を超えてディスカッションを行う試みとなった「手順書Night」ですが、イベント最中は、書ききれないほど多くの指摘や意見が挙がりました。手順書は多くの人の論点であり、これを巡るエピソードや語りも多々あるものだと感じています。
参加者の中に「来年、ふとその作業をやる羽目になった私がわかるような手順書を作っている」というものがありましたが、これは非常に高度なコミュニケーション能力を意味することであり、才能の一つといっても過言では無いのかもしれません。
最後となりますが、会場のご提供をはじめ、重要な指摘の数々を賜ることとなったエーピーコミュニケーションズの皆様、誠にありがとうございました。
