はじめに
まず参考記事にこういうフレーズがあります。
引用 タスクは食べられるサイズに小さく切ってから口に運べ！
アサインされたタスクをそのままほおばると喉に詰まって死ぬぞ！！
これは大きな問題にいきなり取り組むと何もできないから
まずはタスクを分けて考えるのがいいと思いました。
自分がこう思った理由
コードを書けない人が0からコードを書くための3ステップの通り、
いきなりコードを書こうとしても書けないので
やりたいことを言語化してからコードを書くことが大事です。
順を追って書いて行きます。
１.現在の仕様(システムの挙動の確認)
まずアプリケーションがどういう仕組みで動いているのかをローカル環境で確認します。
例えば機能を追加するならどこにどう追加すればいいのか確認します。
実際ここに機能追加してと言われてもどこに追加すればいいんだとなってしまうみたいです。
2.タスクはそのまま受け取ってはいけない(ここで差が出る)
タスクを受け取った時は、タスクを作った人の意図と背景まで考えて実装する必要があります。サービスとしてissueに書ききれなかったり、ビジネス方針が変わったりして、変更になる場合があります。この辺のビジネス側のもれの部分をフォローするのも仕事です。
ex)
自分が以前参画していた開発の例を出します。
RailsでViewの画面を実装していました。
その時に、ビジネス側からの要望で、管理者画面にユーザーのチケットの枚数の表示を実装するタスクを任されました。
その際に、ビジネス側の要求を聞いていくと、管理者だけでなく、お店側にもチケット枚数を表示させるようにした方がいいということがわかりました。
さらにミーティングでヒアリングしていくと、ユーザーの予約履歴も表示させた方がいいということになったりもしました。
もしタスクそのまま実装していたら、管理者だけチケット枚数が確認できて、ユーザーとお店がチケットの枚数を
確認できないという状態になってしまっていました。
タスクの意図がわからない場合は、必ずタスク作った人には、確認しましょう‼︎
3.機能を追加するための要件や具体的な変更内容を確認
次に機能追加の要件や具体的な変更内容の確認を確認するみたいです。
いきなりコードを書こうにも何をすればいいのかが言語化できないと実装できないからです。
それにいろいろ細かいとこまで考慮しなければいけないことが多いです。
csvファイルのダウンロードボタンを例に引用してきます。
・画面のどの位置にボタンを入れるか
・ボタンをクリックした時の挙動は？
・どんなデータを入力するか
・エンコーディングは何にするのか？
などなどです。
このように考慮すべき点がいっぱいあり、システムの挙動に一貫性を持たせるみたいです。
⚫︎エンコーディングとは
https://breezegroup.co.jp/202004/encoding/
正常系だけでなく異常系やセキュリティも考慮する。
正常系は想定通りの問題ない挙動のことですが、
異常系は起こる可能性があるけど起こってほしくない動作や挙動のことです。
・出力するデータが0だったら？
・どういう形式で出力するのか？
他にもユーザー権限や不正あくせすも考慮する必要があります。
「何をどう作ればいいのか」だけでなく、なぜそのタスクが必要なのかまで考える
ユーザーの立場になり、ユーザーが使うケースを想定していく必要があります。
新機能によりユーザーはどう思うのか、どういう時に使うかなど考える必要があります。
こう考えることにより、ユーザー目線で考えることにより機能の向上に繋がります。
4.どのようなロジックで実装されているか確認(1と重なりますが)
・この画面はどのように実装されているのか？
・この機能はどこでどうデータが返ってくるのか?
などです。
実際にコードを見るとどんなロジックで動いているのかわからなくなることが多いので
先輩などにロジックを聞くといいみたいです。現場によって仕様は全然違います。
本番環境のデータ量も確認する。
本番環境のデータベースにはどれくらいデータがあるのか、パフォーマンスはどうなのか?
などパフォーマンスを確認する必要があるみたいです。
テストコードの有無を確認
実装だけでなくテストコードも書くのかを確認する必要があるみたいです。
既存のテストコードがあればそれを参考に書けるが、
そうでない場合はゼロから書く必要があります。
5.機能を追加するにはどこをどう追加すればいいのかリストアップする(タスク分割)
小さい単位でタスクを分解していきます。（伊藤さんはタスクばらしと言います。）
タスクの所要時間は30分から1時間に収まるようにします。
ここは記事に書かれているcsvファイルを引用します。
引用 CSVダウンロード機能であれば以下のようなタスクに分解できそうです。
CSVダウンロード用のルーティングをroutes.rbに追加する
画面上にCSVダウンロードボタンを配置してCSVダウンロード用のパス（URL）にリクエストを送れるようにする
コントローラにCSVダウンロード用のアクションを追加する
CSVの生成ロジックを実装する。CSVダウンロード機能はすでに共通ロジックがあるので、今回はデータの取得とファイル名作成のロジックだけを実装し、それ以外の処理は共通ロジックに任せる
CSSを使ってボタンの見た目を整える
CSVダウンロード機能のテストを書く
こんな感じでやるみたいです。
6.タスクの見積もり方法
まずはリリース日から逆算して考えていきます。
タスクの見積もりは1.5倍かかる見積もりが必要です。
想定外のことが起きたり、影響調査の範囲が広い場合もあるので、少しプラスで見積もりした方がいいです。お手本となるコードがあるのかそれとも1から実装しなければならないのかを把握します。特に後者は時間を見積もっても時間通りになったりしないです。時間がかかりそうなら、必ず先輩やリーダーに相談していきましょう。
7.タスクを整理したら先輩や開発担当者にレビューしてもらう
「これこれこういう風に実装してこのぐらい時間かかります。」
みたいなことをレビューしてちゃんとコーディングできるように
先輩やリーダーに確認する必要があるみたいです。
レビューがないと間違った方向に実装してしまい全然やりたいことから
かけ離れてしまい、全く開発が進まなくなってしまいます。
この段階でコードまだコードは書いていない
この段階ではまだコードを書くのではなくコードを書くための準備です。
いきなりコードを書けとなっても何を実装したいのかを言語化できていないと
コードは書けないですし、僕もめちゃ苦労しました。
「やりたいことが言語化できないとコードが書けない」
なので前段階をちゃんと準備してからコーディングは
CTOの方からめちゃ大事とアドバイスされました。
なので普段から言語化の練習が大事です。
8.実装を開始する
ここからようやくコーディングができます。やりたいこと（To do リストまたは設計図）を作って、それをベースにコードを書いていきます。
実装を開始したらWIP（work in progress＝作業途中） のプルリクエストを作って
他の人がコードの差分を確認できるようにしていきます。
コーディングするまでとにかく時間がかかりますね。💦
詰まったら周りに頼る
新人だとエラーで先に進まなくなるってことは当然出てきます。
その時周りの先輩やリーダーに助けてもらうのが大事です。
エラーで止まって3日間続いて3日後にできませんでしただと何をやっているんだとなってしまします。
それよりも相手が答えやすい質問をしながら実装してリーダーなどが進捗を把握できるように
することが現場では必要みたいです。
これがエンジニアはコミュニケーション力が大事という理由です。
途中経過を報告
正常系の実装が終わったらどこまで動くのか先輩やリーダーに
フィードバックをもらうのが大事みたいです。
やり直しになると時間がもったいないのでそうならないようにする必要があるみたいです。
コミュニケーションの大切さ
実際コミュニケーションがちゃんとできないエンジニアが1番現場で迷惑で
これができれば経験浅い人でもなんとかなるくらい重要みたいです。
経験が浅い時は
「言語化」「コミュニケーション」を大切にしていくことが大事みたいです。
その前にコミュニケーションができないとスキルは伸びないみたいです。
ここでいうコミュニケーションは
「相手が欲しい情報や自分に状況を適切に伝えて、
相手の意図をわかりやすく言い換えてそれを実行していく力です。
人によって言い方はそれぞれですが。
9.実装が終わったらPRのWIPを外して完了
TODOリストが全部終われば、タスクの実装も完了し、プルリクエストのWIPを外して、コードレビューを依頼します。
プルリクエストが承認され、mainブランチにマージされたらタスクは完了です。
10.市場価値を上げるために(タスクを作ったり、お願いする側になる)
最終的には、ただ言われたことを実装するだけでなく、
自分から必要なタスクを提案し、自分がタスクを作る側になることを目指しましょう。
補足
タスクという言い方をしてますが、現場によってはチケット(タスク)、issueと言われます。
最後に
まずタスクが振られてすぐに「さーコードを書くぞ！」はNGみたいです。
実際これから何をやるのかを言語化できないとコードを書くなんかできないからです。
エンジニアだからとりあえずコードを書くだけだと全然仕事では通用しなそうですね💦。
言語化、コミュニケーション、試行錯誤する力などは
未経験の時から学習段階で訓練する必要がありそうですね。
参考記事