「SOFT SKILLS ソフトウェア開発者の人生マニュアル」という本を読んでみた。 内容はエンジニアとして生きてくためにどうすればよいか?を筆者の体験をもとに書かれたものだった。 日本語訳も素晴らしく翻訳本によくある意味不明な例えも少なく、非常に読みやすい本であった。
この本の中に「私は半分の力も出さずに仕事をしていた」と書かれていた。内容としては実際にコードを書く時間は労働時間中50%ほどであとは会議やその他の雑務作業である、といったものだった。
気になったので私の作業時間も割り出してみた。
Redmineから直近1年間の作業時間を出す
私の会社ではRedmineで作業時間を記録しており、クエリで時間を過去の作業内容・時間を計算することができた。 また、現在入社2年目で、研修を終えてチームにアサインされたのがちょうど1年前ほど前だったので時期的にちょうど良い。
作業時間は以下のクエリで算出。チケットのタイトルやコメントも出したのは1年前どんな作業をしていたかも気になったから。
SELECT projects.name, issues.subject, time_entries.hours, time_entries.comments, time_entries.spent_on, enumerations.NAME, (CASE WHEN DATE_FORMAT(spent_on, '%W') = 'Monday' THEN '月曜日' WHEN DATE_FORMAT(spent_on, '%W') = 'Tuesday' THEN '火曜日' WHEN DATE_FORMAT(spent_on, '%W') = 'Wednesday' THEN '水曜日' WHEN DATE_FORMAT(spent_on, '%W') = 'Thursday' THEN '木曜日' WHEN DATE_FORMAT(spent_on, '%W') = 'Friday' THEN '金曜日' WHEN DATE_FORMAT(spent_on, '%W') = 'Saturday' THEN '土曜日' WHEN DATE_FORMAT(spent_on, '%W') = 'Sunday' THEN '日曜日' END) AS WEEK FROM time_entries INNER JOIN projects ON time_entries.project_id = projects.id INNER JOIN enumerations ON time_entries.activity_id = enumerations.id INNER JOIN issues ON time_entries.issue_id = issues.id WHERE time_entries.user_id = XXX AND time_entries.spent_on >= (NOW() - INTERVAL 1 YEAR) ORDER BY enumerations.name;
クエリ結果
name subject hours comments spent_on NAME WEEK 経理・財務全自動 バッチ実行自動テスト作成 1.5 テストコードの見本作成 2018-01-16 開発作業 火曜日 新卒研修 2018 Docker構築 1 composerでライブラリをインストールする際に、必要なソフトをインストールするようWeb/Dockerfileを追記 2018-02-12 開発作業 月曜日 @メイン機能 編集項目選択画面の修正 0.5 ラジオボタンで項目を切り替えれるようにした。項目の内容をセット商品用の情報にすることにした。 2018-07-10 開発作業 火曜日 ....
懐かしい、、、たった1年でも結構色々なことをやったなあとノスタルジックな気分に浸った。 こうやって自分のやったことを見直すと「色々やってこれたんだからこれからもやっていける」と自信に繋がるなと思った。もはや収穫ありだ。
スプレッドシートで内訳を算出
クエリで全部一気に算出してもよかったが、ちょっとクエリ考えるの面倒臭かったのでここからはスプレッドシートの関数に頼ることにする。
スプレッドシートの関数を調べてみるとSUMIF、SUMIFSで全部算出できそうだ。 クエリの結果を以下のように貼り付けてその横に出したいグラフのデータを計算していく。
各作業の割合
会社では主に以下のように作業を振り分けている。
- ソースレビュー作業
- その他作業
- 開発作業
- 検証作業
- 調査作業
開発作業はコーディングの時間、その他作業は会議やチャット上での話し合い、その他雑務等のプロダクトに関わらない作業を指している。 調査作業、検証作業、ソースレビュー作業はプロダクトに関わる作業なので開発作業に入れて計算する。 「SOFT SKILLS」で言えばこの「その他作業」が約50%存在するということだったが私の環境ではどうだろうか。
各作業の割合結果
その他作業の割合は35%、開発比率は65%だった。これは、、結構良い数字なのでは。 他の会社がどんな比率になるかは知らないが、「SOFT SKILLS」の筆者の環境と照らし合わせると割と開発に集中できている環境だと思う。
最近までほとんどチームでの作業はしておらず、ソースレビューは上司に任せるといった仕事をしていたためソースレビュー作業が少ないのだろうと思う。今はチーム作業がほとんどなので半年後とかにやったらまた違う結果になりそうだ。
何曜日が集中できるのか
さて、今回の算出をしようと思ったきっかけは「SOFT SKILLS」を読んだからなのだが、最近「曜日によってアウトプット量が違うな...」と強く感じ始めたからである。会議が集中する日などは当然あるわけだが、どの曜日が集中できる日なのかを改めて知ることでその日やる仕事の内容も変えていけるなと思ったから知っておきたかった。
SUMIFSを使って曜日ごとに各作業の時間を算出し、割合を出す。
結果のグラフ
このままだと少しわかりずらいのでその他作業と開発時間の2つに絞って割合をだす。
曜日 | その他作業 | 開発作業 |
---|---|---|
月曜日 | 31% | 69% |
火曜日 | 42% | 58% |
水曜日 | 39% | 61% |
木曜日 | 34% | 66% |
金曜日 | 39% | 61% |
火曜日がダントツで開発に集中できないDayだ。確かに火曜日に会議を集中させたり雑務をしている感はある。 逆に月曜日と木曜日が開発割合が多い結果となっている。金曜日は締め会や勉強会が入ることが多く、その他作業の割合が多くなりそうな予感だったが、水曜日と同じ結果だというのも面白い。水曜は週の中日だから何か他事したくなってしまっているのだろうか。
算出したデータをもとに曜日ごとの自分のコンディションをグラフにするとこうだ。
金曜日がコンディション低めに見えるが、締め会等の絶対にその他作業の時間が加算されることを考慮すると割と開発Dayだと思われる。対して水曜日は定期的な会議等がないにもかかわらず金曜日と同じぐらいの開発割合なので単純にやる気の問題な気がする。改善できそうだ。
結論
月曜日と木曜日に集中するべき仕事を持ってくる。火曜日にもっと雑務を突っ込めば水曜も開発Dayになる。
なんとなく肌感で知っているのと実際に数字を出してみるのとではだいぶ違う。このデータを出す前は水曜と木曜が開発Dayだと思っていたが、実際は月曜と木曜だった。 コンディションによってやる仕事を変えれば不要なストレスを抱えず仕事ができるかもしれない。やってよかった。 また1年後に出してみようかな。