【アジャイル】設計書に時間をかけたくない人のための話
アジャイル開発において”個人と対話”は重要な要素ですが、必要に応じて設計書も作成すべきです。しかし、アジャイルではスピード感ある開発を意識するところもあり、設計書の作成をしないことがしばしばあります。
「設計書が大事なのは分かるけど、そんな時間ないよ」
「時間があるなら設計書つくるけど、動くものをつくるのが優先でしょ」
確かに正しい意見ではあるのですが、各機能が相互に影響する複雑な実装だったり、長期的に改変を繰り返していくようなシステム(1年以上運用するなど)であれば、設計書を書くことで助けられる場面が結構あると思います。
そこで、アジャイル開発において「あまり設計書に時間をかけたくない人」のために、私が現場でやっていたことをご紹介できればと思います。
はじめに
こんにちは。アジャイルScrum開発をメインとして日々精進しているkikuchi.sです。
この記事は アイソルート Advent Calendar 2020 16日目の記事です。
本記事を読むことで、
- アジャイル開発において設計書を書くことのメリット・デメリットを整理する
- アジャイル開発のスピード感と設計書を両立する方法を知る
ことをゴールに書いていきます。
とはいえ、本記事で言いたいのは「設計書は正義だ」ということではないです。あくまで、アジャイルチームの運営がどうすればより良くなるかを考える上で「そういう方法もあるんだ～」くらいの参考に捉えてもらえればと思います。
設計書をつくるメリット
先に書いたように、アジャイル開発において設計書は絶対のものではないです。ドキュメントよりかは個人との対話を重要視し、効率とスピード感ある開発が期待される場合が多いです。少なくとも、私が経験したチームでは、設計書を作らないor時間をほとんどかけないことになりがちでした。
一方で、設計書を書くことには以下のようなメリットがあると思います。
- 認識齟齬の防止対策
- 実装のたたき台になり手戻り防止
- 運用・保守の負担軽減
１と２については、設計書があることで認識齟齬を防ぎ、かつ開発者間のコミュニケーションの円滑化が図れるということです。
３については、システム開発した人が運用・保守をしない場合もあり、運用・保守する人への引き継ぎとして役立つということです。
設計書をつくるデメリット
「設計書をつくるメリット」であげた利点は理解していても、以下のようなデメリットから設計書を嫌う声もありました。
- 設計書に時間をかけてたらPBLでやりたいことできない
- 改変されていく前提のシステムの設計書はメンテナンスしきれない
確かにその通りだと思います。
１については、設計書に時間をかけてて実装が終わらないのは本末転倒だと思います。
２については、アジャイルは短いスパンで改修とリリースを繰り返すことが前提としてあるので、せっかく作った設計書がすぐ古い内容になってしまいます。
とある開発現場での出来事
私）実装できましたー。レビューお願いします。
Aさん）承知です。 、、、ってこれ、要件と違くないですか？
私）え？どこですか？
Aさん）〇〇は××したときにこうなってないといけないって言いましたよね？
私）それについては念のために確認しましたけど、こっちの方針でOKだってAさん言ったじゃないですか。。。
Aさん）いや、そうは言ってないですよ。
私、Aさん）うーん。。。
アジャイル開発のスピード感と設計書を両立したい
上記の「とある開発現場での出来事」は、設計書には起こさず、対話での認識合わせをしていて起きたものです。言った言わない論で終わりが見えませんでした。そして結果的には実装し直すということで、手戻りになってしまいました。
では、どうすれば良かったのでしょうか？
考えたいポイントは、
- 動くものをつくることを優先したい
- 認識齟齬を対策したい
の２つを両立する方法です。
チケットにメモを残す
私がアジャイル開発で使っているRedmineやJiraのようなタスク管理ツールを利用しているのであれば、タスク単位でやることを箇条書き程度でいいのでやることを書いておきます。
「とある開発現場での出来事」の現場では、PBLに完了条件を書いてあるのみで、タスクには何もやることについて書かれていませんでした。それも、会話で認識合わせできているから問題ないというチームの文化があったからです。チームが成熟してくると開発者のノウハウが洗練され、コミュニケーションも簡素化していくかと思います。しかし、常にチーム全員が同じ認識を持つことは難しく、その場限りの認識合わせは危険です。
「設計書を書く」というとガチガチのものをイメージするかもしれませんが、ここで言いたいのは「メモ程度でいいから何か残しておいて欲しい」です。メモ程度なら、タスク見積もりをする時にでも開発者間で会話しながら書くことができますし、そこまで時間を必要としないはずです。チケット単位でやることを書いておくと、後からチケットを確認しても何をすべきタスクなのかが把握しやすくなり、忘却防止にもなります。ちょっとしたメモが、認識齟齬を防ぐ一手になるはずです。
テキストファイルで設計書をかく
これも有効だと思います。
APIのIF仕様書やDBテーブル設計書など、フォーマットをつくって当て込んでつくっておくのも大事です。しかし、時間がない/優先度が低いなどの理由でスキップしたくなることもあると思います。そういう時は、「テキストファイルに書く」くらいのラフさがあっても良いのではないでしょうか？
「設計書を書く」のハードルを下げることで少しは書く気になりませんか？
たとえテキストファイルに書いた設計書でも、開発者間で作業内容をすり合わせる時のたたき台としても役立ちます。文字に起こすことでイメージをより具体化する効果もあるはずです。
タスクを細かく切る
チケットにメモを残すのも、テキストファイルの設計書も、あまり効果がなかった/やるのを忘れがちになってしまう場合は、「タスクの作業内容を細かく切る」という方法はどうでしょうか？
これなら設計書なるものは残らないものの、タスク名からやることが把握しやすくなります。一つのタスク名に対し作業を複数内容もたせると複雑になり後から見たときに理解しにくくなります。
例えば、タスク名「画面実装」とだけ書かれたタスクがあるとします。
タスク名から”画面”の実装ということまでは分かります。しかし、具体的に何を実装するのかは書いておらず、PBLに記載されている要件のみという状況が生まれます。このままでは実装者の解釈１つでどうにでも実装できてしまいます。
そこで、「画面実装」を「ログイン画面作成/ログインフォーム作成/ログインサービス作成」のようにクラス毎のタスクに分けてみると、何をするタスクなのか一目で分かるようになり、要件漏れも起きにくくなります。
まとめ
本記事では、アジャイル開発における設計書のメリット・デメリットを確認しつつ、
- チケットにメモを残す
- テキストファイルで設計書をかく
- タスクを細かく切る
という、アジャイル開発のスピード感と設計書を両立する方法をご紹介しました。
アジャイルの現場において、使えそうなものやヒントになるものがあれば是非試してみてください。参考になれば幸いです。
明日は ide.t さんの 【Swift】TableView内に配置したUISwitchのindexPath.rowを取得するです。
是非そちらもご一読ください。
