こんにちは、ヌーラボ Backlog課に所属するarata_nです。
日々プログラミングの仕事をしていく中で、「概念をとらえる」ということがとても重要だなーと感じていて、それを実際に取り組んでうまくいったことを紹介しようと思います。
目次
概念をとらえる
唐突に「概念」と書き始めてしまいましたが、ここで自分の理解を説明させてください。
辞書をいくつか引いてみると、そのどれも物事のあらましや本質と出てきます。これをソフトウェアに当てはめてみるとどうなるでしょうか。一般的にはなんらかの解決したい問題があり、その解法そのものや解決に至るまでの手順を組み立てたのち具体的なコードとして記述します。先ほどの辞書的な意味から考えると、「解法や解決に至るまでの手順」が概念にあたるものでしょう。新規での開発であれば全体の設計の段階でこのようなことはよく考えられていると思います。
逆に既存のコードに新しい機能を追加するために手を加えたり、リファクタリングする際、そこでは一体どのようなことが行われているのかを汲み取らなければいけません。実際に書かれているコードの動きだけでなく、そこに隠されている意図や前提を抜き出す必要があります。概念を抜き出さなければならないのです。
概念を「みんな」でとらえる
しかしながら、こういった概念は各々で異なる捉え方をされる場合が多々あります。いつも一緒に働いているチームメンバーと開発していく中でも、その知識量が異なっていたりすることにより認識がずれていく経験はみなさんあると思います。こういったことをなるべく軽減するために、ここ最近担当したプロジェクト内では以下のようなことをやっていました。
モブプログラミング的に現状のコードからやっていることを図に描く
今回のプロジェクトでは私を含め4名のチームで開発を進めようとしていました。進め方としてまずリファクタリングをして整理してから、新規の機能を追加していくのがいいねというチームの合意をとりリファクタリングに取り掛かりました。そこで先ほどいったような知識量の差があったためモブプログラミング的にチームメンバーみんなでコードを見ながら図を書き起こすということを行いました。弊社にはこういうときに便利なCacooというツールがあるので、もちろんガッツリ活用しています。使いやすいしテンプレートも豊富だしありがたいですね。
図に書き起こす時にはどのような出来事が起きるのかを意識して書いていきます。このコードが動いた時にどのようなデータができるのか、DBにデータが保持されるのかどうかなど、起こったことを意識します。合わせてクラス図でコード上の関係も書き起こしていきます。この間にもチームで同じものを見ながら話し、多方面から見直すことで一人では気が付かなかった内容を適宜洗い出して知識を共有していきます。
描いた図とコードから直接出てこない概念を抜き出す
図を描いて一旦チーム内で認識を合わせた後、リファクタリングのためのとっかかりをチームで考えていきます。特に念頭におきたいのがコード上に現れてない概念がないかです。例えば今回のプロジェクトではBacklogのユーザーが持つパスワードについてコード上の整理が必要なことがわかりました。
詳細を省きますがBacklogでは過去にユーザーのアカウントの取り扱いがガラッと変わったため、内部では2種類のパスワードを取り扱う状態になっていました。また本来はパスワードが必ず必要なのに、nullが許容される設計になっていたりいくつかの問題点も発見しました。確認した時点では問題ない状態とわかりましたが、今後の開発でつまづくポイントになるだろうから整理しましょうと、メンバーと話し合いを進めていった結果、以下の図にまとめることができました。
Backlogはプログラミング言語としてScalaを前提としているため、それを意識してまとめています。
実際にはリファクタリングを進めるにあたり既存コードをガラッと変えるわけにもいかないので、ある程度の妥協点などありましたが箇条書きでまとめるとこんな形になりました。
- 図のようにコード上異なるものだと型でわかるようにする
- 本来は全てのユーザーがパスワードを持つべきなので、Optionを使用せずパスワードがないことを表す型を用意する
- パスワードがnullになってるユーザーは現状存在しないが、考慮して導入した
「みんな」でコードを書く
ここまでくると後はモブプログラミングで実装していきます。実際にはコードを書いていくと、これまで考えていたことでは補いきれないパターンなどが出てくるので、都度Cacooのシートに戻り概念を練り直していきます。新しい概念を導入したほうがよさそうとチームで判断すればそれをコードに落とす作業に戻り、またつまづくところがあればCacooに戻り……と繰り返して先に進めていきました。
プロジェクトの後半には、認識が揃っている状態になりモブでなくとも個々のメンバーでタスクを消化していくことになりましたが、今回のプロジェクトは当初のキックオフから実装完了まではこのようなことを念頭に置いて進めたおかげで大きな手戻りもなく順調に進めることができました。ユーザーに直接影響があるプロジェクトではなかったので、目に見えた改善があるわけではなかったのですが達成感があるプロジェクトでした。
まとめ
概念をとらえるというのは、幾分抽象的でなかなか説明するのも難しいところはあります。しかし、ソフトウェアを開発する際にはどんな要素があってどういう出来事が起こるのかなどをチームで話ながらまとめていくと、ストレスなく進めることができるんじゃないでしょうか。
Backlogはこれからもプロジェクト管理とは何かを見つめながら、みなさんに価値あるものを提供していきたいと思います。
