「進捗ダメです！」と思ったときに僕が考えてることを書いてみる

どうもnasa_desuです。新卒29日目でソフトウェアエンジニアを名乗って良いのか悩んでるお年頃です。

一応お仕事としてエンジニアをやっており、何かしらのプロジェクト、タスクに取り組んでいます。

ふとした時に「あれ、なんか思ったより進んでないぞ？」「パフォーマンスがあまり出せてないな？」と思ったことはありませんか？
僕は常日頃そう思っているので、どうして思うように進んでないかを考えるように意識しています。

この時、どのようにして「どうして進んでいないか」を考えているのかを書いてみようと思いました。

この記事を書くモチベーションとしては次の２つがあります。

• 言語化することで思考整理を図る
• 今の振り返り方が良さそうかを振り返る (振り返り方を振り返る)
• 意見を頂戴したい！ 僕はこう振り返ってますよ〜など教えてほしいな。

何を書くか考える

• 進捗ダメですの定義
  • 想定と現在の進捗にずれがある状態
• この認識が正しいか考える
  • yesなら何故を考える、noなら「進捗、実は悪くない！！」となるよね
  • 想定スケジュールがまず正しいのか？
    • タスク洗い出しが正しいかった？ちょっと具体例を添えて
      • 周辺知識を得るのは含んでいた？
        • 具体例を添えて。GraphQLを触るのに何も知らなかった。調べる時間を考慮していなかった。
      • 洗い出し時点では分かってなかったことが分かった
  • 期間内にやっていたことが列挙されている。その上で正しい。
• 解決していきましょ
  • このセクションになるとフレームワークは無くて状況に応じて考えるしか無い。
    • ベースとなる考え方を述べると良さそう
  • メンター、リーダーに聞いてみる。（自分より経験のある人に自分の進め方を伝えて「どうしたらもっと良い進め方が出来ますか？」と聞く。
  • 無駄はなかったか
    • 調査系だと、調べすぎていないか？
    • 二重で同じ作業を行っていない？
    • ビルドを待つ時間 -> これってじつは削れない？
      • 疑り深いのは良いこと
    • 手戻りを減らす動き
  • ブロックするものを徹底的に排除していくのが主。
    • 排除するというよりは早め早めにしておく。手が空いている時間をなくす。
• 意見頂戴したいぴょん 新卒ペーペーの考えたことなので

本当に進捗ダメなの？

まずは「進捗ダメです」という状態を僕がどう捉えているかを書いておきます。
この状態はタスク完了までの「想定した」スケジュールに対する進行度と、「実際」の進行度がずれている状態です。(です！と言い切っちゃたけど僕はそう捉えている。)

一週間で終わるっしょ！と思ってたが気づいたら終わってないという状態ですね。
割と自明だと思うけど一応言語化しておきました。

正しくパフォーマンスを上げていくためには、まずは本当に「進捗がダメ」なのかを判断する必要があると思います。本当に進捗がダメなら具体的な改善ポイントを探してネクストアクションに落とし込んでいけると思うし、進捗がダメじゃないならそもそも悩むことがなくなりますから。

想定スケジュールは正しいのか？

「進捗ダメです」と思っているということは意識的、無意識的どちらにせよ取り組んでいるタスクが終わる時間を見積もっていることになると思います。これが正しいのかを考える必要があると思います。

まずタスクに取り組むにあたってやることの洗い出しを行った場合や、完了までの時間を見積もっていた場合を考えていきたいと思います。
抽象的な話を書くのは苦手なので具体例を交えて書いていきたいと思います。パッと思いつく例は次の２つです。

• 自分の知識量を勘定に入れているか
• 洗い出し時点では分かってなかったことが分かった

「自分の知識量を勘定に入れているか」について具体例をあげると「GraphQLについて知らなかったので想定より時間がかかった。キャッチアップの時間を考えてなかった」といったケースのことです。(想定しておくべき！という話ではないので注意)
特定の技術知識、ドメイン知識はタスクを進めていると必ず必要になると思いますが、知識不足によって「進捗ダメです」と感じる必要はないと思っています。知識がない状態でタスクに取り組む場合は「知識収集」自体を一つのタスク(もしくはサブタスク)として考える必要があると思っています。これは最初からそうしておくべきという話ではなく、進捗がダメだと感じたときの「想定スケジュール」に知識を入れる必要があるというの含めるべきという意図です。「GraphQLについて知ってたらもっと速く終わったのになー」と考えてしまうことはあると思いますが、ナンセンスだなと思うようにしています。

次に「洗い出し時点では分かってなかったことが分かった」についてですが、ほぼほぼ↑で言っていたことと同じで、タスクの見積もり時点では分かっていなかったことが明らかになり想定よりもタスクの難易度が高くなってしまうことはあると思います。この時も「進捗ダメです！」と感じたときの想定しているスケジュールに含まれてないことがあるのでちゃんと含む必要があると思っています。

これらを含めて「想定スケジュール」を考えると実は進捗悪くない！というケースはあると思います。

タスク以外のところを勘定に入れているか？

「進捗ダメです！」と思ったときにちゃんと期間内にやったことを列挙できているかを考える必要があると思います。
タスクAの進捗がダメだな〜と考えているときに、他のタスクが割り込みで発生していないか？ミーティングはどれほどあったのか？をきちんと考慮しておくのは大切です。

僕はこれが漏れがちで、「実は割り込みで優先度の高いタスクが発生していてそっちの取り組んでいた、よってタスクAはあまり進んでいない」と考えるのが苦手です。

実際はタスクに時間をかけられていないのに、ちゃんと取り組んだ体で進捗を考えてしまうのは良くないので気をつけたいです。これも「進捗実はダメじゃない」になりえるパターンだと思います。

「進捗ダメです」をどう改善していくか

では、ちゃんと「進捗ダメです」と分かったときにどう改善してい行きましょうか？
改善については完全に状況によってしまうので書きづらいですね、、、僕がどう改善しているのかを書いていきます。

基本的には次のうちのどれかを考えています。

• 無駄なことをしていないか
• ブロックする要素を取り除けているか
• メンター、リーダーに聞く！

無駄なことをしていないか

これにはいくつかあると思っていて、わかりやすいところを挙げると

• 設計が悪いとレビューを受けてコードを書き直す手戻りが発生した
  • 早い段階で設計を共有していれば手戻りを減らせた
• 直近必要ないところまで調べていた
  • GraphQLのスキーマの書き方だけ知っていればタスクに取り組めるが、GraphQLを完全に理解しようとして調べ回った
  • (長期的に見れば無駄では無いかもしれないが、ここではタスクに必要なものだけを考える。)
• etc 他にも挙げるときりがない

これらは振り返る時間さえ設ければ気づけるところだと思いますし、改善もしやすいと思います。

気づきづらいが実は無駄だった(というか短縮できた)ものとしては次が挙げられると思っています。

• アプリケーションのデバッグサイクル
• etc 他にもあるけど、ぱっと思いつかなかった。

アプリケーションのデバッグは決まった方法はなく状況や個人の環境によって異なるものです。そのためか、実はここを早くすることができる、もっとうまいやり方があるということに気づきづらいのかなと考えています。
基本的に個人個人が我流でやっていくものだと思うので。これを見直すことも大切だと考えています。

もう少し一般化して話すと、現在当たり前にやっていることに改善ポイントがないのかを考えることはすごく重要なことだと思います。

ブロックする要素を取り除けているか

TBW

メンター、リーダーに聞く

TBW

まとめ

まとめは別に、書くこと無いな。

つらつらと新卒のペーペーが思ったことを書いてみました。
今回書いたのは自分自身のパフォーマンスを上げるための取り組みの一つです。これを時間をとって継続的にやっているというよりは、業務中のふとした時に考えています。

「自分はこうしてるよ〜」「もっとこうしたほうが良いんじゃない？」などご意見ありましたら下さい！意見乞食なので。