昨日の話を書きましょう。一昨日の不具合について、さらっと事象の説明を行ったところ、マネージャーに「最近品質色々言われてるから、再発防止策を考えてほしい」と言われました。なにそれ、と反論する前にPLが「まずは修正でしょ。そのあとでいいよね？」と言ったため、話がそこで終わりになり、モヤモヤだけが募りました。僕が思うに、この発言の悪い点は3つあります。

• 指示があいまい
• 前提条件があやふや
• 責任転嫁的発言

再発防止策を考えてほしい、という指示だけだと、具体的になにをどうすればいいのかわかりません。考えればいいだけならすでに考えてはいるので作業が終了していると言えます。そうではなく、再発防止策を考えたものを報告すればいいのか、レビューすればいいのか、実施すればいいのか、そもそも何かフォーマットを作ればいいのか、選択肢が多すぎです。また、最近品質が色々言われているから、という前提条件は、何の根拠もありませんし、一つもファクトが含まれていません。こういうことをマネージャーの立場で言ってしまう人は、こんな発言は単なるいいがかり以外の何物でもないことを自覚すべきだと思います。誰がどこで何を言ってるのでしょう。それを明確にするだけでも違います。さらに言ってしまうと、「最近言われているから」「他部門がうるさいから」「上に言われてしまうから」という発言は、非常に責任転嫁的であり、部下の信頼を失いかねません。それを言われてしまうと「この人は自分の意見がない傀儡なのか・・・？」と思います。避けられるなら避けたほうがいいです。よく「I」トークということが言われますが、できるだけ主語は私で話すほうがいいです。もし品質について誰かに何か言われたのだとしたら、それを受けて「自分は品質を上げるには再発防止策をまとめた資料を提示するのが一番だと思うので」、という風に一度自分の中で整理して、それをアウトプットするほうが、僕は求心力も説得力も感じます。

本当に、こういう思いつきみたいな作業指示が、どれほど無駄な仕事を生み出しているのか、自覚はないのでしょうか。

そんな感じで、色々考えたらモチベーションがぐっと下がったので、こういうときはプログラミングで邪念を払うのが一番！と、Pythonでプログラムをいくつか書いてみました。しかし、requestsでcsvファイルのダウンロードをする処理を実現したかったのですが、ファイル書き出しがどうしてもうまくいかず、文字化け地獄にはまってしまいました。僕はこんな単純なこともできないのか…と少し落ち込んでしまったのですが、一息ついたらふと思いついて、ファイルの書き出し方を、テキストの書き出しの方法ではなく、csvの書き出しの方法にしたことで解決しました。csvファイルから取得したデータなので、書き出しもcsv形式に合わせれば良いという、わかってみれば簡単なことだったのですが、はまってるときはわからないものです。requestsで検索すると、テキストベースのwebサイトへのアクセスばかりHitするのもあって、考えがそっちに寄ってしまいました。

少し時間を置くと冷静になってひらめくのがプログラミングの楽しいところですね。おかげで再発防止策も多少考える気になりました。正確には再発防止策をどのように考えるかを考えるところから始めるのですが…。