はじめに
ここ1年ほどアジャイルでの開発に開発チームメンバとして参加して、マインドやアクションとして大事だなと感じたことをお伝えします。開発チームメンバとして技術力はもちろん大事ですが、この1年を振り返るとむしろ最初はマインドを変えてアクションも変えていけるかが第１の壁だったと感じてます。
年次が若い方で初めてアジャイルをしている方や、開発は何年もやってきたけどアジャイルは初めてという方の参考になれば幸いです。
自己紹介
5年ほどウォーターフォールに近い形で開発をしてきました。お客様から要望を聞いて仕様を調整して設計し、製造フェーズではレビューをしつつ自分で開発をして、後進育成をすることもありました。
正直アジャイルをするまでは、使ったことのない技術に困ることはあっても、開発に必要なマインドは分かっていてアクションも取れるはずだと思っていました…でも、実際やってみたら、甘くなかったですw
参加していたプロジェクトについて
開発手法としてはスクラムで、以下のようなメンバ構成です。
スプリント期間は2〜3週間で、デイリースクラムは毎日やってました。
- スクラムマスタ、プロダクトオーナーは1人ずつ
- 開発チームメンバは複数人（うちアジャイル経験者2人）
アジャイルをやっていくためのマインド・アクション
ここからは私がやってみて大切だと感じたマインドやアクションを紹介していきます。
アジャイルじゃなくても開発を進める上で大事なことも含まれていますが、改めて重要だと感じたことです。
有識者には直接会いにいく
別にアジャイルに限った話ではないんでしょうが、有識者怖いって印象を持たない（良好な関係を築いておく）のがまずは重要だと感じてます笑
私は、アジャイルでめちゃ仕事をさばく有識者の方々ってスピードが速すぎるからか何か近寄りがたく、何か怖かったです。
怖いから質問しずらい、報告しずらい、とかなるとアジャイルのスピード感にはのれずに溺れます…
仕事を始める前に同じPJの有識者には直接会って安心できる関係性を作っておくことをおすすめします。
画面から各処理の大まかな流れを把握
新しい画面を作るとき、どこに何を書いていけばいいのかを把握しないとプログラムを書くときに手が止まってしまいます。既存のシステムがあるのであれば、有識者に大まかな流れを教えてもらうのがいいと思います。
私がよく気にしているのは以下です。
- URLと画面との紐付けを定義しているところ
- 画面として表示されるところ
- 画面からバックエンド呼び出し部分〜バックエンドの受け取り口〜データベース接続部分
- 共通関数、共通変数を定義するところ
デバッグ方法の把握
デバッグ方法を知らないと何か起きた時に自分で対処する術がありません。
エラーが表示される場所とエラーが起きた時にどう原因を確認するか（デバッグ方法）は有識者に確認しておきましょう。
プログラムを書き始める前に具体的な作業を書き出す
思いつくままに作業をしていると抜け漏れがあったり効率的ではなかったりする可能性が高いです。
具体的な作業を書き出してどの順序で進めるか決めてから取り掛かることをおすすめします。
私がいつもやっている作業の書き出しはこんな感じです。
詳細設計をやっている感じなので、この時点でほぼ作業の8割方終わってる感じです。
ちなみに何の作業をしたらいいか分からない場合は即誰かに聞いた方がいいです。
- まずは、フロントエンド、バックエンド、インフラでどんな作業が必要か書き出す
- 不明点、調査が必要なところには印を付ける
- いつまで調査するか決める
- そのまま使えそうなサンプルが他の画面や他PJにないか、ライブラリないか確認
- 自分で調べても分からなければ誰かにヘルプ
- 各作業の大体のスケジュールを立てる
分からないことは溜めずに聞く
これは開発経験者の方だと当たり前に感じる方も多いかもしれません。ただ、違うのはスピード感です。アジャイルならばウォーターフォールの時よりも体感10倍速で質問していいです。そして、デイリースクラムがあるからその時聞けばいいやと先延ばしせずに即質問することをおすすめします。
最初の頃にわからないことは、聞かないとわからないことの方が圧倒的に多くて自分で調べてると詰むし、周りもまさかそこで止まっていると思わなくて誰にも気づかれないまま時間が過ぎて…蓋を開けてみたら全然進んでないじゃんなんてことにもなりかねません。
計画を立てる、日々進捗に合わせて計画を立て直す
アジャイルではバックログ（タスク）は割り振られますが、計画は基本的に担当者に一任されます。最初は計画通りいかないし計画立てようにも分からんわ！って感じと思いますが、まずは計画を立てて何を出来たかを知ることが大事なのであって、計画通り進めることが目的ではありません。
計画を立てていれば遅れそうな時に客観的に気付くことができます。また、間に合わないと気づいた時に日々何をどれくらい進められたかという足跡が、どうリカバリできるかを考える材料になってくれます。
計画を周囲に伝える、進捗報告する
アジャイルではバックログ（タスク）は割り振られますが、計画は基本的に担当者に一任されるので、最初のうちは自分では順調に進んでいると思っても、周りから見たらやばいってこともあります。そういう状況にしないためにも、立てた計画は伝えて、出来るだけ進捗報告することをおすすめします。
出来ないことは出来ないと伝える
今まで任された仕事は責任感を持って何が何でも（身を削っても）やり遂げることが大事だと思っていたんですが、アジャイルではちょっと違います。
任された仕事が終わらなかった場合はチームの責任でありチームで反省する、誰かが頑張りすぎるとストーリーポイントが増えて次のスプリントでも同じように頑張らなければいけないのでチームの首を絞めることになると捉えます。
もちろん、適当に仕事していいわけではないのですが、「任された仕事が終わらなかった場合はチームの責任でありチームで反省する」ので、誰かの終わらない仕事があればチームでカバーするという考え方です。
なので、終わらないかもって話は積極的に伝えましょう。
そして、「誰かが頑張りすぎるとストーリーポイントが増えて次のスプリントでも同じように頑張らなければいけないのでチームの首を絞めることになる」ので、頑張りすぎないでください笑
最初のうちは予定通り終わらせることが目的ではなく、チームとしてどの程度タスクを消化できるかを知ることが目的なので、チームのためにも未来の自分のためにも無理してやらないでください笑
フィードバックは早めにもらう
お客様に早めのフィードバックをもらうのも大切ですが、社内のチームメンバにも早めにフィードバックをもらうことをおすすめします。
色々と言われて大変かもしれませんし、面倒に感じてしまうかもしれませんが、最初のうちは期限ギリギリになって見せてると周りと認識が違っていることが多く、修正に追われた結果、締め切りに間に合わなくなる可能性が高いです。
また、やり始めて詰まることって、チームメンバに聞けばすんなり解決する可能性（何かのライブラリで簡単に解決、他の機能のコピペでOKなど）もあるので、そういう気づきを得やすくするためにもフィードバックは受けておいた方がいいです。
別プロジェクトの人にも相談する
モヤモヤしてきたら、新鮮な立ち位置の方（別プロジェクトのアジャイル経験者や知識を持っている方）に話を聞いてもらうのもおすすめです。アドバイスを変な先入観なくストレートに受け取れることがあります。
私の場合は、別プロジェクトの先輩にタスクを終わらせようと結構頑張ってるって話をしたら、無理に頑張らないで出来ないことを出来ないと伝えた方がいいよって言われて、次の日には今あるタスク終わりませんってデイリーで報告してました笑