Perl日記

PerlとかRubyとかPHPとかPythonとか

チケットタイトルアンチパターン

普段はBTS、JIRAとかRedmineとかのチケットでタスクを作っている。
その中で、いくつかチケットタイトルについて、アンチパターンを把握したので、メモ。

現状を書いただけで「だから何?」パターン

例)

  • 「ABC機能がX仕様に対応していない」
  • 「DEFアプリのY機能の矢印が動かない」
  • 「GをしたらZ機能ができない」


このパターンが一番多い
これらはすべて、「だから何?」と聞きたくなってしまう。
なんとなく、ニュアンスから類推することもできるのかもしれないが、それでも「じゃあ正解は何で何をすればいいのか」くらいは書いてほしい。
「対応していないのを対応させる」とか。

ログ貼り付けパターン

例)

  • 「Error: hoge feature: fuga abc def ghi jkl mno ...」
  • 「HogeException: AはBによってエラーになりました」


エラーログの内容をそのままとか、アラートで飛んできた件名とかを、そのままコピペで作ったパターン。
作ったときはいいものの、たとえば一週間後に見たときにすぐに内容が把握できるのかといえば、そんなことはない。
あと、当事者以外には触りたくない感じになる腫れ物チケットと化すことが多い。

エラーログは、チケットタイトルにちょっとはあってもいいけど、
全部をチケットタイトルにすると、結局何が失敗したのかわからない。
エラーログの内容はチケットの説明に書いて、チケットタイトルには何の失敗の対応をするのかを書こう。

漠然でふわふわ

例)

  • 「J画面の例のアレ」
  • 「今日のデータを取る」


もうちょっと頑張って書こうぜ。

【番外】ネタチケット

例)

  • 「もうすぐ到達するキリ番を取る」
  • 「↑のキリ番を取るのを防ぐ」


集計の邪魔になるので。

ミーティング中に漫画を読む

正確には、「全体ミーティングでたまに発生する雑談中にサンデーを読む」である。
いまの職場では、社内のエンジニア全員でのミーティングが週に一回行われている。
そのミーティングの時間内で、古くからの鉄板ネタとして、いじられキャラをいじる、という雑談に見せかけた何かが数分発生することがまれによくある。
まあ五分も十分もミーティングが中断するわけではないので、最初は「まあいいか」と思ってやり過ごしていたけど、さすがに最近は時間の無駄かなと思って手元のiPod touchを操作するようになってしまった。
そしてなんと水曜日は、十年以上惰性で読んでいる週刊少年サンデーの発売日なのである。
朝にiBooksで買ってDLしておけば、職場でインターネットにつながらなくても読むことができるのだ。
ミーティング中に漫画読む、っていうのは、さすがに後ろ暗い気持ちがないではないので、ちゃんとミーティングが再開されればすぐにiPodをスリープさせるくらいはしている、とここで言い訳もしておこう。
ちなみに最近始まった中で面白いのは「保安官エヴァンスの嘘」である。
ネタ切れに負けず頑張って欲しい。

プロとは

「あなたが思うエンジニアとしてのプロとは何か」を提出しないといけないらしい。
先にこちらに下書き的にまとめてみる。
まあ特段新しく考えたわけでもなくて、普段、業務の中で感じていた漠然とした内容を言語化してみただけだ。


エンジニアとしてのプロとは何か

  • 好き嫌いで拒否しない
  • お金になる(ような)ことをする
  • 自分がいなくても仕事が回るようにする
  • 【番外】ワインでいる努力

好き嫌いで拒否しない

仕様がなんかアレとか、
既存コードが辛いとか、
調べるのが面倒とか、
スケジュール調整をなんで自分がとか、
謎の問い合わせ対応が来たとか、
まあ色々あると思うけど、「それはやらない!」と拒否するのではなくて、(モチベーションの差はあれど)とにかくやるのが大事かなと思う。

あと言うまでもないけど、もちろん好き嫌い自体はあっていいに決まってる。
それを日々の仕事にダイレクトに反映させていると、途端にチームメンバとしての存在感は薄くなっていくだろう。

お金になる(ような)ことをする

最初は「ユーザに価値を届ける」、と心地のいい言葉を書こうかなと考えていた。
が、よく考えなくても、いまの会社(スタートアップ? ベンチャー?、というのか)は、まだそんな余裕はなくて、とにかく収益を上げたいのだ。
それはイコールで「価値を届ける」ことになるのかもしれないが。
一見すると、直接はお金を生み出さないような、たとえば1行ログを出力するだけの処理を追加するにしても、
「この情報をログに出力しておくことで、問い合わせ対応がスムーズになり、業務効率の改善になるのだ」とか、
「あとで集計して想定との差を測定するのだ」とか、
「ユーザの行動を追跡して、よりよいおすすめを出せるようにするのだ」とか、いろいろあると思う。
それらはすべて、「1行ログを出す」という点を出発して、活用というプロセスを経て、収益という形で帰ってくる。
リファクタリングだったら処理効率があがってサーバ台数が減らせるかもしれないし、単体テストは不具合という損失を未然に防いでいるかもしれない。
あれ?、そう考えると、だいたい理屈がつけられるな…。
まあなんにしても、Webサービス開発・運用をするという名目で雇われているので、何も考えずに何かをするのはよくないとは思う。


自分がいなくても仕事が回るようにする

常に自分がそこにいなくなったときのことは想定しておきたい。
そのためには、自分だけが持っている情報がないかどうかを日頃から意識しておく必要がある。
自分としては、そうやって、「他の人も自分と同じことができる」「同じでなくてもこれを見ればわかる」「わからなくてもそこにあることは知っている」と共有をはかっている。
が、これはなぜか現場との乖離があって結構辛い。
「この部分はこのひとしか知らない」と情報を専有しているひとに高い価値が置かれている。
なんだ、じゃあ自分もあれとかあれとか教えずに黙っていればよかった、そうしたら会社は自分を辞めさせられずに給料が高くなるのにーーー、という気持ちになる。
悲しい。


【番外】ワインでいる努力

「泥水にワインを足しても泥水のままだが、ワインに泥水を足すと泥水になる」という有名な言葉がある。
チームで仕事をするのも同じで、全員が「チームで仕事をしている」という意識を持たないと、よい仕事ができないように思う。
一滴の泥水が全体を壊す。
そんなことのないように、ワインでいる努力は常に怠らないようにしたい。