タスクをこなすとは何か

２月〜８月までの約半年間、かなりフルタイムに近いペースでインターン生として働かせていただいていました。

本当に色んなことを経験させていただいたんですが、その中でもタスクをこなすということに対する理解が以前よりも少しは深くなったような気がしています。
ここでは半年の学びのまとめとして、ソフトウェアエンジニアとしてタスクをこなすとはどういうことなのか、何をするべきなのかということを現状の自分の理解でまとめたいと思います。

タスクをこなすとは何か

まずそもそも「タスクをこなすこと」は「ユーザーに価値を届けることに責任を持つこと」だと思います。

ソフトウェアエンジニアとして働いている方々からしたらとても当たり前のことだと思うのですが、この事実にちゃんと意識を向けられていませんでした。

と言うのも、今までのインターンでは「丁寧に切り分けられた細かなタスク」が主だったので、「仕様通りに実装してマージすること = タスクをこなすこと」と認識してしまっていましたし、それで特に支障もありませんでした。ただ、この半年間でその認識は間違っていたんだと理解しました。

この感覚は小さい頃に母の料理を手伝っていた時の感覚に近いような気がします。僕は小さい頃、どうしても料理をしてみたくて母の料理の手伝いをすることがありました。その時は人参を切ったり鍋をかき回したりして、すっかり料理をした気分になっていましたが、今考えてみればそれは「料理をしている」とは言えなかったなぁと思います。

母がいつも行なっている料理は「レシピを考えて、具材を買って、調理器具を用意して、調理して、盛り付けて、食べてもらって、後片付けをする」までを含んだ料理です。僕はその数ある工程の中でも「調理」の部分だけを、しかもお膳立てされた状態でこなしただけで料理全体をした気になっていましたし、それで問題ありませんでした。しかし、本当に一人で料理をするのであればその感覚は捨てなければいけません。

ただ作るだけではなく後片付けまでに責任を持つ必要がありますし、買い物に行く時間が無いなら家族に頼んでおく必要もあります。

ここで言うところの「調理」は、ソフトウェア開発における「実装」だと思います。今までのインターンでのタスクではPdMやEM、メンターの方々にお膳立てしていただいた規模の小さいタスクの実装だけを行っていたため、そこまで深く考えずともタスクを問題なく進めることができていました。

しかしタスクの規模や複雑性が上がり、関係者も増えていくとそう簡単な話ではなくなります。

そのようなタスクだと、実装だけをしてユーザーに価値を届けられるかというとそんなことはなく、たとえば実装前に仕様がユーザーの課題を解決するための最適解なのかを考えたり、実装後にユーザーに届けるまでにエッジケースなどで問題が起きないか観点を洗い出してQAを行ったりと実装以外に必要な要素がどんどんと増えていきます。

全てを一人だけでやる必要はありませんが、それら全てをハンドリングしてユーザーに価値を提供できる段階まで持っていくことには責任を持つ必要があると感じました。

この半年間でプロフェッショナルとしてのエンジニアの働き方の一端を感じられたのがとても良かったです。

具体的に何をすればいいのか

では「ユーザーに価値を届けることに責任を持つ」ためには何をすれば良いのでしょうか？自分の中で大事だと思った要素がいくつかあったのでそれを書き出してみます。

ユーザーに価値を届けるまでにどうなっていればいいかを洗い出す

まずタスクを始める前に設計をすると思うのですが、この段階が本当に大事だとこの半年間で深く実感しました。

このタイミングで最初にやらなければいけない事は完了条件をリストアップする事だと思います。
実装が完了してデプロイされた後にユーザーがどのようなユースケースで使用されるかを考えてそのパターンを洗い出します。

例えばブログの記事投稿機能を実装するというタスクなのであればこんな感じかなぁと思います。

- 記事が投稿した時にDBにデータが保存される
- 投稿に成功すると記事一覧画面に遷移する
- 遷移した後に成功した旨をトーストで表示する
- タイトルが入力されていない場合にバリデーションが出る
- バックエンドでエラーが出て投稿できなかった場合にエラートーストが出る
- 記事が変更されている時に画面遷移しようとするとダイアログが出る

本当はもっと構造化した方がいいとは思うのですが一旦例としてはこんな感じです。

このようにリストアップして正常系、異常系ともにユーザーが取りうるパターンが洗い出せると目指すべきゴールが明確になりますし、実装完了後のQAでも確認が容易になるのでまずやるべきことかなと思います。

ここで意識した方が良さそうなのは「このタスクにおける変数が何か」ということです。
例えばタイトルの有無や本文の文字数、ユーザーの動線などユースケース中の代わり得る値にどんなものがあるかを把握できているとエッジケースへの考慮漏れが少なくなります。全ての変数の全組み合わせを考慮し切るのは不可能に近いと思いますが、どんな変数があるかを把握するだけでも十分に効果があるんじゃないかと思います。

頭を使わずに実装できるところまで設計を詰める

目指すべき場所が分かった後はその完了条件を満たすためにどのような実装をしたらいいかを考えて実際に設計をします。
ユーザーストーリー単位で切ってもいいと思いますし、別の切り方でもいいと思うのですが、コミットと一緒で「最小限の意味あるまとまり」に切れると実装の進捗が確認しやすくなるほかレビューも容易になるので目指した方がいいとは思います。
僕はそこまでできませんでしたし、タスクの大きさによっては小さく切らない方がコスパが良かったりもすると思うのでいいバランスを考える必要はあるとは思いますが。

設計する時に意識した方が良さそうなのは「この設計であれば頭を使わずに実装できそうか」を考えることだと思います。

僕はインターンの途中まで実装中に悩んで手が進まないということが非常に多かったのですが、メンターに相談したところこれを意識すると良いということを教えていただきました。

設計通りに手を動かすだけで頭を使わない状態にまで持っていけばスムーズに実装を進められますし、何より予想外や考慮外のパターンが出てくることが減るので手戻りも少なくなります。途中からこれを意識できたので少しはスピードが上がったかなと思います。

適切に人を頼る

設計が終わったら実装に入ると思うのですが、タスクが大きくなればなるほど自分一人では実装し切るのが難しくなると思います。

特に僕の様なインターン生であればドメインの知識も乏しいですし、技術力も伸び代しかない状態なので様々な人の手を借りながらタスクを進めていかなければならないと思います。

設計が終わった段階で自分だけでできないことは十分に見えていると思うので、実際にできる人を頼る必要が出てきます。

人を頼るというのはとても当たり前のような気がしますが、意外とできていなかったです。特に適切なタイミングで頼るということが難しかった記憶があります。

就業型インターンとして働いたことのある人なら分かる人は多いと思うのですが、人に頼るというのは想像以上に難しいことだと思います。
自分よりも圧倒的に難易度も分量も多いタスクをこなしている社員の方の時間を奪ってしまうのは申し訳なく感じてしまいますし、何よりこんな簡単な事で頼ってしまっていいのかと考えたりして時間を溶かす事が僕も多かったです。

そのせいで実装が後手に回って引いたスケジュールからビハインドしたり、締切ギリギリになって無理な状態で頼ることになった事も何度もありました。

ただここで考えなければいけないのは、「タスクをこなすこと」は「ユーザーに価値を届けることに責任を持つこと」だという事です。

その中にはスケジュール通りに実装を終わらせることも含まれています。しかし社員の方の時間を取らないことは要件として入っていません。

つまり人を頼る事がタスクを進める上で最適解なのであれば申し訳なさなどは感じずに積極的に頼っていく事がむしろベストだという事です。

質問したり頼ったところでそれに対して怒ってくる人は稀だと思いますし、特にインターン生であれば分からないことばかりなのが前提なので引け目を感じずに頼るべきだと感じました。

設計段階で誰かの手を借りる必要がある事が発覚したらそれを先に伝えておいたり、いつまでにそれを完了しなければいけないかを意識していつ頼むのかを考えたりしておくことがスケジュール通りにタスクを進めることにつながるため、頼るべきタイミングを見逃さないことが大事だと学びました。

ただ頭では分かっていても引け目を感じてしまうが多かったので「自分でできる限りのことはしているからしょうがない」という気持ちを持つことにしています。

例えば質問する時であれば「自分が今こんなことをやっていて、今はこんな状態で、目指すべきゴールはここで、その間にこんなギャップがあります。これを埋めるためにはどうすればいいでしょうか？」の様に、可能な限り相手の認知負荷を下げられる様に質問の仕方を考えるなどです。

頼る時も「必要な情報を揃えて後はそれ通りに手を動かすだけ」の状態に近づける努力をする様にしました。

それをすることで多少は相手の負担が減った様な気がするので今までよりは人を頼りやすくなった様な気がしなくもないです。

自分の状況を知ってもらう

実装に入る前にはチェックを貰ったり人の目が入る機会は多いと思いますが、一度実装に入ると中々今の自分の状況を他の人に把握してもらうことが難しくなります。

しかし、「このまま行くとスケジュールからビハインドしそう」だとか「現状の実装だと漏れてる観点があるかも」などの途中で気付いてもらうことがとても大事だったりもします。

実装が終わってから「あれこの観点抜けてない？」「これだと動かなくない？」などの指摘が入ると悲惨なことになりますからね...

定期的なsyncの場がプロジェクトのメンバーや所属しているチームにあればいいのですが、全てのタスクでそのようなsyncの場が用意されている訳ではないですし、チーム全体の夕会などではそこまでタスクについて深く話す場は設けられていないことが多いと思うので不十分だと思います。

正直これに対するクリティカルな解決策はあまり見つけられていないのですが、チームのslackチャンネルがあるのであればそこで定期的に勝手にsyncするとかが良いのかなと思っています。ただ、他チームと共同で進めている場合などではそれでも不十分だと思うのでそれは自分からアクション取ってメンションしてでも見てもらいに行くべきだと思います。

どれだけ考えても自分一人の観点や思考には限界があるので(特にインターン生であれば尚更)、こまめに人の目を入れて常にブラッシュアップできるチャンスを作ることが大事だと学びました。