ごめんねボールペンはおやすみしてて

上司に仕事が多くてどれから手をつけていいのかわからない、と相談した。こう言うとまるで僕が優先度をつけることの出来ない出来損ないみたいだけど、その通り。数ある仕事の中で、どれが一番最優先でやらなければいけないものなのか、判断がつきかねたところもあるし、独断で終わらせた仕事が後になって「それより先にこっちだろ！」的なことを言われるのが嫌だったので、先に了解を得ておきたかったわけだ。石橋は叩きまくる主義なんで。
大きな括りとしては５つの項目として列挙出来たわけだけど、それぞれにかかる時間と、他開発メンバーへの影響度と、現在のプロジェクトの進行状況として一番先に取り掛かるべきものを相談して決定し、さらにその他の項目についても順序を明らかにした。
それらを早速、僕が使っているRemember the milkにインプットして忘れないようにした。
1番目と2番目のタスクの合計時間は約5日間となっている。相談したのが木曜日の終わり頃なので、来週の金曜時点で出来ていれば計画通りという計算になるわけだが、僕の見積もりが甘かったのか、1日で終わってしまった。あまり早く報告するのはどうかと思ったので、報告は来週にするとして、余った時間で「課題」扱いとなっていた技術について検証していた。
そこそこの規模のプロジェクトなのに、開発メンバーがたった4人。しかも2年目の僕がリーダーとなって先輩方に指示してやってるわけだから心細いことこの上ないが、逆に考えれば僕の好きなように出来るため、トライアンドエラーで色々とやっている。
中でも僕が力を入れてるのは（公言はしてないが）、GTDとチケット駆動開発だ。GTDは学生時代にその存在を知って、いつか取り入れたいと思っていたものだが、学生時代ではそのタスクの少なさから、ほとんど意味を成さなかった。だが、仕事が多くなってきた今なら、GTDは役に立つと実感出来る。いろんな人にいろんな仕事を言われて、「わかりました」と承るが、それが1ヶ月以内にやらないといけないことだったり数日中にやらないといけないことだったりすると、日々の雑務に追われてすぐに忘れてしまう。特に長期スパンの仕事は。そこでGTDがあると、タスクを確認する習慣さえ身に着ければ、たいていのことは見過ごさなくなるので、とてもいい。
一方チケット駆動開発のほうは、複数人で開発を並行しているとき、不具合や課題が発生したときにチケットを発行して「誰か解決してくれ！」と言うのを公募するようなもので、これはバグの優先度によってすぐに直すべきかどうか判断しやすくなるし、その他多くのメリットがあるので始めてみた。ただ、チケットの数が少ないと管理作業のほうが多くて意味がないと言うのが実感としてある。やはり、テスト専門の人を用意して、集中的にチケット発行する時間を作るべきかな。技術的な課題事項については開発者がチケット発行出来る。
また、そのチケットはDBに「記録」として残る。つまり検索対象にもできるわけだが、それで何が嬉しいって、PGのリリースが済んで運用が始まったとき、不具合が出ればその記録を参照することができるわけだ。そうすると、類似不具合の解決方法がわかるし、不具合ならチケットを通じてプログラマーに通知することもできる。運用と開発を密に結びつける手段として、また長い目で見た時の記録として、チケット駆動開発に慣れておくのは損ではないと思っている。
とまあ、上記のような考えで開発メンバを率いているわけだが、僕の開発ボリュームが一番多いのに、そういう管理業務・間接業務も多いから、自分で自分の首を絞めてるような気がしないでもない。普通なら「まあこういうのもあるけど、やりたいようにやってね」と言うんだが、そうは言えない理由がある。部内開発手法の統一とその試行について僕が選ばれたわけだ。かくして、良かれと思って考えたことが仕事となったわけだ。給料あげろー

で、昨日は部署の若手で飲み会だった。先輩が結婚されたのでそのお祝いと言うことで。嫁さんもゲストとして登場。先輩は酒が弱いのでつぶれてたけど、お二人ともお幸せに。