きり丸の技術日記

技術検証したり、資格等をここに残していきます。

副業で気にするべきこと

7月から副業をしているのですが、仕事の進め方が本業と違い、うまくいきませんでした。

この記事では本業と副業の差分を棚卸し、来月以降の副業を円滑に進められるように振り返りをしていきます。なお、私個人の感想のため、現場によっては異なる可能性はありますので御了承ください。

私の立場

  • 業務を受注する立場

まとめ

基本的には本業と同じタスクマネジメントをするべき。しかも同期タイミングが本業よりも少ない分、マネジメントをサボると手戻り工数が大きい。

ですので、副業の方がマネジメントの重要性が高い。ウォーターフォールで工程管理したほうが、安定する。

本業と副業の違いと対策

大きくは2つです。

  • 開発ブランチへのマージ権限がないので、普段の仕事の作業リズムと合わない
  • 仕様把握がリアルタイムではできない

開発ブランチへのマージ権限がないので、普段の仕事の作業リズムと合わない

マージ権限がないこと自体はいいのですが、マージされるタイミングがこちらでは読めないのが面倒です。

困ること

  • 似た作業が行われているブランチが存在してしまう。
  • コンフリクトする前提でブランチを切る必要がある。マージされた後に動作確認をする必要が何度も出てくる。

対策

  • git worktreeを使いこなすことで回避できそう
  • ブランチを機能単位ではなく、マージタイミング(レビュー)に合わせて行う

備考

Gitはできる限りシンプルな操作で行いたいので、git worktreeを使いたくないですが仕方ないですね。本業ではトランクベース開発を意識して途中の状態でもコミットしているのですが、トランクベース開発は常にソースコードや機能をメンテナンスする強い意志を持たないと成り立たないので、副業で行うのは難しそうです。

あとは、機能単位ではなく、毎週ブランチを切って運用するのも悪くないと思っています。小さい機能だと、1週間に2-3個のPull Requestを作ることになり、これがお互いにコンフリクトしているとマージコストが跳ね上がります。しかも、マージ待ちの間は開発ブランチは進んでいるわけで、それを都度取り込む手間もかかります。週1ブランチの運用はまだ行っていませんが、合意が取れたら相談のうえで週1ブランチを切る予定です。

仕様把握がリアルタイムではできない

副業の難しさはここが一番です。

困ること

  • 土日に作業するので、仕様を聞いても反応は月曜日。
  • 平日も本業の終業後に作業するので、早くても反応は翌日。

対策

  • 仕様確定していない作業は絶対にしない
    • 作業しながら仕様不明点を洗い出すのは悪手
  • 仕様が決まっていない振る舞いは作りこまない
  • 1週目に実装対象の仕様を伺い、2週目に見積、3週目に実装する
  • テスト仕様書も作る
    • 事前条件、操作、事後条件はGherkin記法等で確実に決めておくべき

備考

無駄に稼働がかかった原因は、手戻り作業でした。

しかたないのですが、細かい挙動はどうしても伝え漏れます。リアルタイムで仕様を教えていただければいいのですが、私の作業時間からしてリアルタイムで教えていただくことは難しいです。ですので、徹底的に仕様を詰めたうえで作業に入ることにします。テスト設計書等も作りこんでおくことで、認識齟齬がなくなると思います。

終わりに

賛否両論あるかもしれませんが、個人的には副業はアジャイルでやるよりもウォーターフォールを意識した方が良さそうでした。

単純に私の技術力が低くて生産性が悪いということも否めないのですが、工数が膨らんでしまった原因を納得してもらうためにも、メモや資料はキッチリカッチリ残しておくことが大事です。


この記事お役に立ちましたら、各種SNSでのシェアや、今後も情報発信しますのでフォローよろしくお願いします。

f:id:nainaistar:20210828001350p:plain