こんにちは、エンジニアの藤田です。 普段は社内向けのプロダクト「タレントエージェンシー支援システム（SFA/CRM）」の開発をしています。
ヒューマンキャピタリストはTA(タレントエージェンシー)本部という部署に所属しており、そのTA本部が使うシステムを内製で開発しています。
エンジニアとしてジョインして約半年、ここでの開発手法はアジャイルでフラットな開発チームであり、優先順位はあるもののタスクは開発者の裁量で取って進めていくスタイルで割と自由に開発しています。
書籍『アジャイルサムライ』第2章冒頭で書かれている、
典型的なアジャイルチームには、あらかじめ決まった役割分担は存在しないッ！！
というやつですね。
普段のタスク内容は、RubyやVue.jsを使ったシステム開発、バージョンアップ対応、インフラに強いメンバーはインフラ整備など行っています。
さて、ここ最近私が取ったタスクが「POと共にユーザヒアリングに同席しながら要件定義していく」というタスクでした。
正確に言えば、当初は「とある機能追加の為のUI、設計を考える」タスクであり、平行で動いている別の改修タスクと切り離し可能な作業と考えていたのですが、進めていくうちに他の改修機能との兼ね合いを考慮する必要もでてきたり、別のタスクが自分のタスクにも影響でてきたりして、こう思ったわけです。
「もっと上流から考え直す必要があるじゃん。。」
ということで色々苦労したのですが、ユーザの声を聞けたいい経験でもあったのでその時の記録を書いていこうと思います。
TA本部のとある課題と我々開発チームのミッション
おおよその業務は社内向けシステムで運用を管理できているのですが、当然ですが組織や事業は日々変化していきます。
そのため我々が気づかないうちに新たな運用が発生し、別のツール(スプレッドシートやその他管理ツール)を現場でカスタマイズし管理していくケースが往々にして発生します。
今回要件定義したものも、詳細は書けませんがこういった業務のひとつです。
別のツールだとしても管理できているならいいじゃんとなるかもしれませんが、次のようなデメリットもいくつかあるので
- 情報が分散されてデータが管理しにくい
- 属人化してしまう
今回は組織として挙がった課題を解決できるよう、システムに組み込むといったものになります。
開発者の課題
要件定義をしようとしたところ、以下の課題に直面しました。
- 何となくやりたいこと、現場の課題があることはわかったが、具体的な「システムで管理できていない運用」のところがよくわかっていない。
- 通常の運用も具体的なところまではわかっていない部分はある。
というわけで、いきなり躓くわけです。
困った時のヒミツ道具ということで手元にある『エンジニアリング組織論への招待』を開いてみると以下のことが書かれていました。
ソフトウェアにおける実現
それは誰かの曖昧な要求からスタートし、それが具体的で明確な何かに変わっていく過程が実現で、その過程のすべてがエンジニアリングという行為です。
つまり、「曖昧さ」を減らし、「具体性・明確さ」を増やす行為が「エンジニアリングとは何か」という答えでもあるのです。1-2. 不確実性とエンジニアリング
具体性・明確さを増やすために、まずはユーザの運用から整理しようと思い、業務フロー図を作成しました。
業務フロー図作成
ユーザヒアリングまで少し時間があったので、業務の理解と整理の為に業務フロー図の作成準備に入りました。
先にこれをやるメリットは以下が考えられます。
- 事前に図として整理することでヒアリングの質が向上する。
- 質問の準備ができる。
- 図を共有しながら話もできる。
どのような運用をしているかはslackのやり取りにもヒントがあったり、開発チームでも知見のあるメンバーはいるのでそれらの情報を集め整理しながら簡単な業務フロー図を作成しました。
あくまでチームで理解の共有ができればOKなので、結果以下のような図になりました。
登場人物の関係性と下半分は時系列の処理フローのような図があったり、パターンを考えた図も含まれています。
教科書通りの業務フロー図とは異なりますが、いいのでしょうか？
いいということにしましょう！
最初の段階では仮説思考的に作成したものとなり、その後にチーム内で相談、議論したりユーザから正確な運用をヒアリングしながら図を更に肉付けしていきました。
ユーザヒアリングや業務フロー図作成の過程で以下のようなことがわかってきました。
- ユーザの業務運用フローはどういったものか
- どのように管理しているのか
- 課題の具体的な特定
また、今回システム改修をする上で考慮しなければならない点も整理できるようになりました。
組織として
- 現場の運用をシステムで管理したい。
現場として
- スプレッドシート管理の拡張性は手放せない。
- システム化することで業務が回りづらい状態になっては困る。
開発チームとしては上記、両方考慮しながら開発しなければなりません。
ちなみにユーザヒアリングについては1.5ヶ月の間にトータル10回程行いましたが、POは別途回数こなしてヒアリングしていました。 様々なチームや役割があるので多角的に情報収集し、その中でベストな方向性を模索しました。
システムの新機能について要件定義
システムで管理出来ていない運用フローについて明らかになってきました。次のステップはどのように既存システムに新機能を組み込むかになります。
まずはPOが大まかな仕様を考えたり、壁打ちしたり、開発チームで仕様を検討するMTGを行いました。
仕様について検討する機会が多くなったため、仕様検討MTGを増やして議論を重ねました。
チームミーティングは1回のMTGで1時間〜2時間を週に2〜4回くらい、その時の課題によって増やしたり減らしたりしました。トータルで10~20時間は仕様検討に使いました。
この段階でシステム開発における「達成すべきもの」が徐々に明確になってきました。
ワイヤーフレーム、画面遷移図、ER図を作成
また、この工程でワイヤーフレーム、画面遷移図、ER図も作成します。
ワイヤーフレームはチーム内で理解のズレが無いよう、できる限り正確な情報でデザインしていき、それを基に更に開発チーム内で議論、ユーザとも感触を伺ったりしていき、改良を重ねていきました。
この段階での正確なワイヤフレーム作成手法はその昔、ECサイト開発をしていた時に一緒に働いたWeb制作会社のやり方を真似ました。
完成品をイメージしやすいのはもちろんですが、なかなか綺麗なワイヤーフレームを見て感心したものです。
バックエンドエンジニアの自分がやっても下手で時間的コストが掛かるので簡単な対応の時はやりませんが、他人と理解のズレが発生しそうな仕様を考える時などはこのやり方を意識してます。
話を戻しますが、ここで重要になるのが、先に挙げた以下2点です。
- この新たな機能追加が組織の課題解決になっているか、かつ
- 現場の業務改悪になっていないか。
ユーザは既に別の管理ツールで運用しており、我々が下手な追加機能を開発しても使ってもらえません。社内のユーザとはいえ、使いたいと思う機能を提供しないと使われないのは一緒です。
開発者として使われないまま負の遺産になることは何としても阻止しなければなりません。
そこで開発チームの提案とユーザの考えの違いに差がないか、慎重に仕様を詰めていきます。
ズレていたら再度、仕様見直しと共にドキュメント修正、開発チームで議論、ユーザへ提案またはヒアリングを繰り返していきます。
週一2時間でプラニングポーカーの見積もりミーティングがあるのですが、この対応の話をしていていたら長引いて見積りができない回が何回かありました。
もちろん見積りミーティングはリスケです。
またここまで、できる限り正確なワイヤーフレームを作成してきましたが、開発中に「こっちの方がいい」はどうしても出てくるのであくまでチームの共通理解が主な目的になります。
ER図等のDB設計についても「DB設計検討作業」をチケット化し、担当者が数パターンを開発チームに提案、チームで合意を得ながら進めていきました。
ユーザーストーリー作成、タスク化
この段階まで来たらかなり「曖昧さ」が減り、「具体性・明確さ」が増えてきました。
あとはユーザーストーリー作成や作業のタスク化をし、開発メンバーでプランニングポーカーの見積もりをしていきます。
また、この段階でフロント→バックエンドの仕様を描いたシーケンス図も作成しましたが、これも開発段階で変わってくることはあるので、あくまで参考程度の情報にしています。
最後に
組織の課題解決をどのようにシステムに落とし込むかを皆で頭抱えながら進めていき、話し合いの最中や開発の段階でも新たな課題が発生しては、仕様詰め、設計、見積もりを繰り返してきましたが、無事に開発も着手でき、部分的にリリースもできてきました。
今回の開発作業では、「組織の課題を解決できるだけでなく、現場のユーザの使い勝手」の２つを考えなければならないのが大変でした。
開発チームの提案がユーザ側には通らない場面も多々あり、運用ヒアリングしていく中で「なるほど」と納得する場面が多く勉強になりました。
手段として、色々ドキュメント書いたりミーティング増やしたりしましたが、「何の為に作るか」の目的は常に意識する必要があるかなと思いました。
もちろん手段もいいやり方を吸収していきたいです。
