生産性のない時間 is プライスレス

ひとりアジャイル開発に挑戦したい - いちばんやさしいアジャイル開発の教本を読んで

公開日時:

（今回、かなり衝動的に書いているので、いつも以上に読みにくいかもしれませんが悪しからず…。）

いちばんやさしいアジャイル開発の教本を読みました。

控えめに言って、とても良い本でした。（当たり前ですが、個人の感想、というやつです。）

基本的に私は、全体を俯瞰しつつ流し見のようなそうでもないような塩梅で本を読んでいるのですが、この本はいつの間にか精読をしてました。言語化が苦手な私ですが、少なくともそれらの自分の行動からこの本が面白かったんだということはわかります。

さて、その中でも私が特に目を引かれたのは、Chapter7 Lesson60 の『アジャイル開発は本当にできるのか？』の部分です。

実際問題、アジャイル開発を導入するメリットがあるからと言って、それを例えば自分の会社で布教できるかというのは全くの別問題です。 組織構造のしがらみや風習 etc で、なかなか大変だろうなというのは社会初心者な私でも何となくわかります。

そこで、この話では具体的にアジャイル開発をどうやってはじめ広げていけばいいのかというのが書かれています。 さすが『いちばんやさしい』というだけはあります。具体例を示してくれてるのです。

というわけで、それらを参考にしつつ、どのくらいからだったらアジャイル開発の一部を導入できそうかな、というのをまとめてみようと思います。自分向けなので、他の環境だとまた違う順序があるのかもしれませんが、まぁそれはそれ。そういうのをアップデートしつつ考えるのもアジャイル開発でしょう。（一体何視点なんだ）

導入できそうなこと

というわけで、まずは初動で導入できそうなことを一覧にしてみます。

タスクの見える化

基本的には書いてある通りです。

いつまで・誰が・なにを、というのを簡潔に記載したものをタスクとするといいそうです。

タスクを出来る限り視覚化することで、今自分が何をやっているか、自分自身で把握することは意味があります。 さらに、それらをチームで共有できると単純に進捗の可視化がしやすくなるということだと思います。

ちなみに、プロダクトバックログとスプリントバックログの違いが、よくわからなかったのですがこういうことだと私は解釈しました。

そして、タスクの見える化というだけあり、当たり前ですがタスクを見えるようにするのが目的なので、これらのタスクは出来る限り詳細に書くようにします。

例えば『〇〇をできるようにする』というタスクに、子タスクとして『仕様をまとめる』『設計をまとめる』『〇〇機能を作る』といった感じでしょうか。

1 日単位ではなく、数時間単位のタスクを作成し順に処理していくことで、どの作業がどこまで終わったのかが視覚化できるようになる…ということのはずです。

そして、終わったタスクには、そのタスクに関連する資料の URL なんかをしっかり残しておくといいんじゃないかなぁと思いました。 開発作業の時なんかは、テスト方法とか、受け入れ条件とかですかね…。（思案中）

朝会

朝会、と書いていますが、要は仕事を始める前にを軽く整理しておきましょうということだと思います。 大体 15 分ぐらいらしいです。

情報を共有しスプリントを軌道修正することが目的なので、朝会をすること自体が目的にならないように気を付けます。

といった感じです。ただ、これは一人でやるだけだと結局形骸化しそうなので、自分でやったあとに、適宜自分の所属してるメンバーの誰かにアジャイル開発という名目ではなく、あくまで相談という形で話すことで無理せずチームの情報共有度を自分だけの分でも上げられるのではないかと思います。

ふりかえり

手段が目的化しないよう、しっかりとふりかえりをしないといけません。 スプリントに連動させて、大体 1 週間～ 2 週間の間隔で繰り返します。

成果物のレビュー（開発で言うならプルリクとか）なんかと組み合わせて行います。 過去のイベント、体験、感情なんかを入れるのがポイントのようです。

keep（続けること）・Problem（問題点）・Try（次に試すこと）を Backlog なり Wiki に書きだすと良いと思います。

例

上記のような感じで気軽に振り返れるといいんじゃないかなぁ。

共有

今までの話は一人でする前提で組んでますが、最終的にはやはり組織レベルで取り入れられたほうがいいでしょう。

そういうときのために、日々の自身のひとりアジャイル開発の活動を、きちんと社内 Wiki などで視覚化して残しておくことは大事なことだと思います。もしかしたら、それらの記録を見て「これぐらいでいいなら私もやってみよう！」という人がいるかもしれません。そういう人を逃さず仲間にするのも大事だと思います。理想が高いですけどね…。初めから諦めるよりはいいでしょう。

また、段階的に組織に導入していくことを前提に、どういう段階を踏むかの図なんかも社内情報共有に投げておくといいとのことです。

感想

今までの綴りがすでに感想みたいなものですが、自身でまとめてみて改めてこの『いちばんやさしいアジャイル開発の教本』はとても良い本だなと感じることができました。私みたいなど素人でもまとめたり挑戦してみたりといったことができるのは、それだけこの本が初心者向けに丁寧に書かれていて、なおかつ知見にあふれているということだと思います。

組織というのはなかなか大変なのだなとひしひしと感じる今日この頃ですが、少しずつでも職場で伸び伸びと、そして効率よく仕事に取り組めるよう頑張っていきたいと思います。上司さんのことも嫌いではないので、あとはメンタル的な垣根を飛び越えて真にチームとして活動できるになりたいです。

まぁそれをするには組織が云々以前に、私の豆腐メンタルをどうにかするべきなんですけどね！！！（

最後になりますが、いちばんやさしいアジャイル開発の教本、お勧めなので是非読んでみてください！