こんにちは。
前回のQiita記事投稿から3年以上が経っていることに驚いた、エンジニア経験が10年の若松です。
はじめに
この記事はうるる Advent Calendar 2019 11日目の記事です。
今の働き方
週3日フリーランスとして働きながら、他の4日は自分が所属する会社でIT事業の立ち上げを行っています。（仕事が好きなので基本的に週7日働いています）
この働き方になってから約1年が経ちます。
フリーランスの現場としては、現在お仕事をさせてもらっているうるる社が2社目です。
今年の4月からインフラエンジニアとして参画させてもらい、今はサーバーサイド開発もフロント開発もやらせてもらっています。
この記事で書きたいこと
今うるる社で参画しているプロジェクトでは、1週間スクラムを採用しています。
私は週3日勤務なので、1スプリントの5日間のうち2日間は不在になります。
密なコミュニケーションが必要なスクラム開発において（しかも1スプリントは5日間！）、週3日勤務なんて成立するのかと思われるかもしれません。
私も最初は少し不安でした。
しかし、半年以上が経った今、チームメンバーに恵まれていることもあり、週3日勤務でもしっかりプロジェクトに貢献できているし、モチベーション高く仕事に取り組むことができています。
週3日勤務でもプロジェクトに貢献できるように、色々なことを考え、工夫してきました。
その一部を記事に整理したいと思います。
在宅勤務やリモートワーク、時短勤務など、様々な働き方の選択肢が出てきました。
違う働き方をしてみたいけれど、今まで通りにプロジェクトに貢献できるか不安に思う人に、ぜひ読んでもらい、少しでも勇気付けられたら嬉しいです。
週3日勤務の懸念点
私が抱いた懸念を挙げます。
1. わからないことが増えて、主体的に行動ができないことによりモチベーションが下がる
これが1番大きな懸念でした。
チームが週5日で稼働しているにも関わらず、私の稼働が週3日だと、当然わからないことがたくさん出るようになります。
わからないことが多くなってしまうと、主体的に行動するのが難しくなっていきます。
わからないと自分の意見が持てないし、「何をすべきか」の判断もできなくなるからです。
結果、チームメンバーの考えに従って行動せざるを得なくなり、主体的に行動ができなくなります。
私は主体的に行動ができず、言われたことをやるしかない状態になってしまうと、モチベーションが著しく下がるので、この状態は避けなければならないと思っていました。
モチベーションが下がると仕事が楽しくないですし、良いパフォーマンスも発揮できません。
誰も幸せにならないです。
2. 意思決定に参加できないことで、プロジェクトが他人事になる
私の不在時にチームの意思決定がされることも多くあります。
「ここの設計はこうしよう」「打ち合わせのやり方をこう変えてみよう」「こんな失敗があった。次からはこれをやってみよう」というように。
意思決定に参加していない、ましてやその意思決定に賛成できない、ということが多発すると、どんどんプロジェクトが他人事になっていきます。
何か上手くいかなかった時にも「ほらね、あの決定が間違っていたんだよ」という思いを持ってしまうかもしれません。
プロジェクトを自分ごとで考えられなければ、良いパフォーマンスを発揮することはできません。
3. 不在時に他のメンバーの仕事が止まる
わかりやすく仕事の進みに影響が出ます。
以下の2種類があると思います。
- 私しか知らないために、その周辺のタスクは私がいないと進められない
- 取り組み中のタスクが、他の人の仕事をブロックしてしまっている
懸念を解決するための取り組み
懸念を解決するために、様々な取り組みをしてきました。
1. 情報のキャッチアップにしっかり時間を割く
わからないことが多くなると主体的に行動ができなくなるので、情報のキャッチアップにはしっかり時間を割こうと決めています。
「ただでさえ稼働が少ないので、自分が持っているタスク以外のことはあまり気にせず、自分が持っているタスクをとにかく進めるのに時間を使おう」と考える人もいるかもしれませんが、私は不在時の情報をキャッチアップするのに時間をしっかり使っています。
そうすることで、チームの状況/やるべきことが良くわかり、自分の頭で考えて行動ができるようになるので、必要な時間だと私は考えています。
周りの状況を把握したうえで、考えて行動ができることで、結果的にも良いパフォーマンスが出せるようになると思います。
※ 議論がSlackに残っていたり、情報がチケットに整理されているので、後からでも情報のキャッチアップが可能な状態になっています。チームのみなさん、ありがとうございます！
2. 遅れてでもチームの意思決定に対して自分の意見を発信する
自分の不在時にチームの意思決定がなされることは避けられませんし、避けるべきだとも思いません。
ただし、意思決定に対して気になる点があるのにそれを黙っているのは、プロジェクトを自分ごとだと考えていないチームに対する裏切り行為だと思っています。
なので、数日遅れであっても、チームが議論し決定したことについて自分の意見を発信するようにしています。（「何を今更」と迷惑になっていることもあかもしれません…）
結果として、不在時にされた意思決定についても納得ができており、プロジェクトを自分ごとに捉えて仕事に取り組むことができています。
3. 積極的にアイデアを発信して実現のために動く
勤務日数が少ないと、どうしてもプロジェクトが他人事になりやすいと思ったので、プロジェクトに対して主体的に取り組めるよう、積極的にアイデアを発信して実現のために動くことを意識しています。
簡単に言ってしまうと「自分のアイデアを採用してもらったんだから成功しないとヤバい」という気持ちになれるように行動しています。
スクラム開発の立ち上げ時期には、ユーザーストーリーマッピングの作成を提案して、作成ワークショップのファシリテーションをしました。
今でもプロダクトの全体像の把握にはユーザーストーリーマッピングを使っています。
自分の提案が受け入れられると、やはり受け入れてもらったプロジェクトは成功させたいという思いを強く持つようになります。
4. 自分のやっていることをオープンにする
「私しかできない」「私にしかわからない」ことで、私の不在時に仕事がストップしないための施策です。
唯一のインフラエンジニアとして参画していたのにも関わらず、週3日勤務だったこともあり、「インフラを属人化させない」ために様々な施策を行いました。
専門的な内容も含みますが列挙します。
1. インフラ構築を完全にコード化する
「私の頭にしかない」ということを無くすためです。
インフラ構築で必要なことは全てコードで記述されており、「誰が読んでもわかる」「誰が実行しても環境を構築することができる」という状態を作りました。
2. モブプログラミングを実施する
技術共有のために、何度かモブプログラミングを実施しました。
ドキュメントで共有する、講義形式で共有する、という手段もありますが、一緒に手を動かしながら情報共有を行うのは非常に効果的だったと思います。
3. 対面レビューを実施する
コードレビューは基本的に対面レビューで時間をかけて行いました。
品質の担保と情報共有の2つを効率良く実施できたと思います。
最近はじめて、私の不在時にインフラの更新をチームメンバーがやってくれました。
「インフラを属人化させない」がしっかり実現できていることがわかり嬉しかったです。
5. 仕掛かりのタスクが日を跨がないようにする
仕掛かりのまま不在になることで、そのタスクが他の人のタスクをブロックするのを防ぐためです。
仕掛かりのタスクは状況も本人に聞かないとわからなくなってしまいます。
不在では回答もできないので、仕掛かりのタスクはできるだけ作らないようにしています。
タスクは完了させる時に必ず、チーム内でレビューを実施します。
その日のうちに完了に持っていくことでレビューまで実施されるので、結果的に情報共有にもなります。
まとめ
やってみた結果、週3日の勤務であっても、主体的にモチベーション高くプロダクト開発に取り組めるということがわかりました。
また、不在によってチームに迷惑をかけるということもあまり起こっていないように思います。
働き方が多様化している今、開発チームが色々な働き方を受け入れられるようになると、開発チームの可能性は大幅に広がるのではないでしょうか。
週3日勤務の私を受けて入れて頂き、素晴らしい環境（後からキャッチアップができるように情報が残っている、結論が出てから数日後の意見でも聞いてくれる、など）で、このような体験をさせて頂いている開発チームに感謝しています。