真面目で優しいシステムエンジニアは損をする15~データ移行って難しい~
どうも！ヒグッティ(ヒグッティ＠システムエンジニア)です！
私の実体験を元に真面目で優しいシステムエンジニアが損をすることについて書いていこうと思います。 これはフィクションです。とあるシステムエンジニア、ヒグッティの物語です。
前回は データ移行の始まりについての話について書きました。
今回は引き続きデータ移行の話です。では、お楽しみください！
今回の記事で言いたいこと
- お客さん先でPCがなくて作業できないことがたまにある。
- 「今まで1分かかっていた作業を１秒にした」 これがシステムエンジニアの本質だと思っている。
- 作業の自動化、効率化できる人は優秀なシステムエンジニア。
- 日本語でドキュメントを作成するのは難しい。人によって受け取り方が違う書き方が発生するため。
- 手順書の作成はきつい。スクリーンショットを張り付けて作業の説明を加える。これをお客さんからOKをもらうまで修正し続ける。
- 移行作業のほとんどがドキュメント作成。技術がわからない人向けに資料を作成するときは地獄。ドキュメントは80%くらいの出来で出して、早めに実作業をすべし。ツールの作成とかね。
- ドキュメント作成はテンプレートを用意。できればお客さんが知っているテンプレートがおすすめ。ないと資料の見方からの説明となり時間がいくらあっても足りない。
新しいメンバ
4月から移行について色々と相談している中、他にもやることはありました。
向井さんと交代でクロさんがメンバに加入しました。クロさんには分析機能の開発をやってもらう予定です。ゆくゆくは新計算機能もやってもらおうと思っていますが…
まずはクロさんに色々と教えようと思ったのですが、PCが来ない！PMさんに確認しましたが、最近、PCの発注を担当していた事務さんが辞めちゃったらしく、PCの手配の方法がわからないらしい。(そんなことあるのかよ…(笑))
とりあえず、向井さんが使っていたPCを臨時で使うことに。
クロさんに、分析機能での開発内容や設計書などを共有しました。クロさんは20年戦士なのでかなり信頼しています！！
クロさんはさすが20年戦士でした。私の書いた設計書で不備を発見し修正してくれました。私的にできるシステムエンジニアの特徴として作業の自動化、効率化できる人は優秀です。VBAなどでテストデータの作成を自動化したり、細かい作業でも自動化することを意識しています。私個人の考えですが、システムエンジニアの本質としては「今まで1分かかっていた作業を１秒にした」というところに美徳を感じると思っています。クロさんはまさに優秀なシステムエンジニアでした。仕事も早いし、仕様の理解も早い、クロさんに任せておけば安心だ。そんなクロさんですが、一点だけ気になる点がありました。それは話が長いこと。必ず定時頃に１時間ほど話します。状況報告としてはありがたいんですけど、同じ話のループが多い、、実際は15分くらいで終わることが１時間、長い時で２時間話しました。クロさんは社内では私の上司になるので話が長いことをあまり強く言えずにいました、、、これもよくなかった。言えばよかった、、
実際の作業では、クロさんに任せた作業は問題なく進んでいきました。
新計算機能のメンバについても優男さんが調整してくれました。
優男：ヒグ、新計算機能のメンバの件だけど、ボンバさん使っていいよ。
ヒグ：ありがとうございます。いつまで使っていいですか？
優男：5月から6月までの2カ月使っていいよ。なんか別プロジェクトで作業が遅延していて、ボンバさんの作業がないらしいから。
ヒグ：ありがとうございます！！
この時期に人が空いていたことは運がよかったです。普通こんなことはありません。これで、データ移行、分析機能の開発、新計算機能の開発で人をあてはめることができました。
移行が難しい
４月も終わり５月に入ろうとしているときのこと。
移行で作成するドキュメントは大体決まってきましたが、肝心の中身が決まりませんでした。中身というよりは体裁の問題だったり日本語の問題でした。日本語は難しいです。技術ができてもそれを何も知らない人に文字で伝えることは至難の業です。日本語の書き方や受け取り方によって書き手と受け手の意味が異なってくるためです。仲間さん、PMさんは特にこの日本語の問題を強く指摘してきます。ぶっちゃけ技術者からすると全く面白くない話です。
技術のわからない人は指摘することができないんですよね。説明されても何を言っているかわからないから。だから技術がわからない人でも理解できるような資料を要求してきます。そして資料に対しては「言っている意味が分からない」と一言で終わらせます。または日本語的な指摘をするのみです。お客さんは中身が正しいかなんて見ていなかったですね。ここは私として、すごくもどかしいところです。わかりやすい資料を作りたい半面、納期が迫っている。わかりやすい資料を作ると時間が間に合わない、資料を間に合わせようとするとお客さんに意味がわからないと言われる。私は「わかりやすい資料を作ると時間が間に合わない」を選択していました。終電ギリギリまで作業しても間に合わないんですよね。私の効率が悪かったこともありますが。５月に入った頃から、ほぼ毎日終電で帰宅でした。定時内は作成したドキュメントのレビュー会議、または管理業務と報告。定時外はメンバの進捗確認と問題の共有、ドキュメントの作成と修正でした。
移行の際、手順書を作成する必要があるのですが、これが大変でした。Excelにスクリーンショットを張り付けて、入力する項目やボタンは赤枠で囲み目印をつけ、吹き出しをつけて作業内容の説明をしていました。これを延々と繰り返します。そしてお客さんに見せて「意味がわからない」と言われて再度ドキュメントを修正する日々です。チームメンバも日々の長時間労働と指摘により作業が進まないことにイライラしていました。プロジェクト全体としていい雰囲気とは言えませんでした。
そんな中でも作業を進めていくしかありませんでした。予定では8月上旬で移行含めすべてのタスクが完了し８月はリリースに向けた準備(特にやることがないはず)をする予定でした。なのでバッファがないわけではなかったんですよね。しかし、ドキュメントのレビューや修正で次第にこのバッファも無くなり始めていました。
この時の反省としては、ドキュメントが70%~80%くらいでお客さんに見せて、早めに実際の移行作業をやればよかったと思いました。いくら手順書を完璧に書いてうまく説明したとしても実際に試すとうまくいかないことがかなりありました。プログラミングでもまずは手を動かせ！！といいますがまさにその通りでした。
あとは、お客さんやうちの会社含めて共通のテンプレートみたいなものがなかったこともドキュメントの作成に時間がかかったことの原因でした。全ての資料を0から作らなければなりませんでした。お客さんにテンプレートがあるか確認しましたが、「わからない」、「あったら渡します」としか言われませんでした。0から資料を作ると、まずは資料の体裁や見方から説明をしないといけないので時間がかかります。さらにお客さんの好みによっては資料を修正しなければなりません。共通のテンプレートがあればこのようなことに時間を取られなくて済んだのに、、、
６月中旬から移行のテストも始まります。模擬移行テストです。移行当日と同じ作業を実施します。なのでそのテストまでに移行方法を確立させなければなりませんでした。この模擬移行テストは３回実施しすべてOKにならないとリリースできません。
実際、ドキュメント作成は終わっても肝心の中身が全くできていませんでした。なぜならツールなどを作成し試す時間がなかったからです。ドキュメントに時間を費やし、打ち合わせの度に作成する資料が増え、またその資料の作成と修正、、、という悪循環でした。移行の資料を作成していると作業の抜け漏れもわかってきます。なので本当は移行ツールなども修正しなければならなかったのですが、そんな時間もなく、、、正直、最悪でしたが、お客さんは知ってか知らずか「ドキュメントが完成=ツールもできている」という方程式がお客さんの中で、完成されているようでした。
朝から終電まで作業をしていたため、自分の時間はほとんどありませんでした。家に帰って飯を食べてねるだけ。週一日の休みは妻とでかけたり、趣味のランニングやサッカーをしていました。自分の時間って大事ですね。あと睡眠も大事です。体がもちません。この頃は1時～2時に寝て８時に起きる生活でした。正直、毎日体が重く疲れ切っていました。やる気もほとんどありませんでした。でも一日で唯一の楽しみは夜、東海オンエアの動画を見ることでした。
癒しって大事ですね。私の場合、東海オンエアでした。