マネージメント
非機能要件

社内開発における非機能要件の捉え方

Livesense - 関 Advent Calendar 2017、16件目のエントリです。
でも今日はすでに12月18日なのですよね……思い切り遅れて書いています。本当にすみません……
さて、さっそくですが、今回のAdvenCalendarはそれぞれのテーマに沿った内容を書くということで、このカレンダーのテーマは「関」です。
事前に色々とプログラミング的なことを考えていたのですが、結局、今年一番「関心」のあったことということにしました。
最近特に考えていることでもありますが、内容としては、社内開発における非機能要件の捉え方と、上流工程担当者として意識していくべき点などをつらつらと書いていこうと思います。

日々あがってくる改善案

私は普段ネイティブアプリ開発に従事しています。
日々機能改善や新規機能開発などを行っているわけですが、その中でいわゆる「機能要件」の他に
「アプリの起動ってもっと早くならないですか?」
「こことここ、画面遷移する時カクつくのなんとかならないですか」
といった「性能」についての話しが出ることも多いです。
あるいはバックオフィスからの要望を受けることもあり、社内の「運用」についての議論がされることもあります。
ただ、こうした、いわゆる「非機能要件」として定義される部分については、「機能要件」に比べて要件定義が曖昧になりがちなことがあります。
非機能要件という範疇には他にも色々な項目(セキュリティ、可用性など)がありますが、日々あがってくる内容としては「使い勝手」の部分が多いように感じます。
もっとも、セキュリティや可用性、障害時の対応などは、エンジニア側が率先して気にすることが多く、非エンジニアからそうした要望が少ないのは当然と言えるのかもしれませんが。
開発に詳しくないディレクターやプロジェクトマネージャーからあがってくる内容としては、ユーザに提供する機能、画面などに比べると要望の内容が抽象的であることが多く、どちらかというと開発にあたるエンジニア側がそれを具体化する必要があります。
チーム内ではこのあたりについて、今までおざなりというか曖昧なまま運用されてきてしまった感があり、改善しなければならない部分だなと最近特に強く思っています。
あ、もちろんあくまで弊社の場合です!きっと多くの現場ではもっと厳密に要件立てされていることが多いとは思います。

いい感じにしておいてね

前述したような「使い勝手」については、改善点として意見があがってくることが多い一方で、「要件」として例えば「アプリの起動は5秒以内に行う」「通信処理は最大でも10秒以内に収める」と具体的に定義されることが少なかったりします。
あるいは初期開発時には定義されていることでも、その後の機能追加、機能改善の中でおろそかになりがちなところがあったり。
様々な機能を追加していくうちに、いつの間にか起動処理に時間がかかるようになってしまったり、機能を優先するあまりユーザスレッドをブロックする時間が長くなってしまったり……。
そうしたことが続いていくと、再びそこの改善が議論されるという、なんとも不毛なことになるわけです。
なぜこうしたことになるのかというと、その原因は様々なのですが、1つにはやはり、要件定義を行う人間が「非機能要件」を要件として正しく捉えていない、あるいは、捉えているつもりでも明確に定義することを怠ってしまうことがあると感じています。
非機能要件は受託開発時に難しい部分として取り上げられることもありますが、自社開発においても具体化することが難しい部分ではあるかなと思います。
非エンジニアからすると、エンジニアが「なんとなくいい感じ」にしてくれる部分、「要望」としてあげておけばいい事柄であって、「要件定義」するほどのことでもない部分、という考えもあるのかもしれません。
これは何もネイティブアプリに限った話ではなく、例えばwebサイトにおいて高速化を行う場合、「どこまで速くすればいいのか」という数値を事前に明確に定義しない場合などもあるかとは思います。

非機能要件を具体化する

「いい感じ」とはいったいどのような状態を指しているのか、開発者がコーディングするうえで必要になる要件をヒアリングし、開発者はできあがった要件を満たすように実装を行う。
当たり前といえば当たり前なのですが、ここが曖昧になるといつまでたっても非機能要件が明らかにならず、思うように改善が進まない結果になります。
開発側としては起動処理を高速化したつもりで、実際、以前に比べると速くなっていたとしても、ディレクター側から見るとそれはまったく不足しているかもしれません。
そこでまた「もう少し」などという話しが出てきてはエンジニア・非エンジニアの間に無駄な軋轢が生じる原因にもなります。
具体化するにあたっては、普段開発に従事していない人でもイメージしやすにように、現在の性能を数値化する、他のアプリでの参考数値を見せるなどの工夫も必要かと思います。
漠然と「非機能要件どうしますか?」「数値書いてください」などと伝えても、それはそれで突拍子も無い数値が出てくることもあるでしょうし、そもそも「いい感じに」してくれると思っていた箇所をなぜ「要件」として定義しなければいけないのかすら分からないかもしれません。

ディレクターも非機能要件を意識する

弊社のネイティブアプリチームにおいては、そこ(要件をヒアリングし言語化する)を担うのは私の役割でもあります。
ただし、今まではそれほど具体化することがないまま開発を進めてた経緯があり、なぜかと言えば開発部分も自分が行なっていたということがあります。
現在はチーム内で開発を行うメンバーが増え、必ずしも私自身が開発を行わない機会も出てきたため、今後は上流工程の担当者としてディレクターと開発者との間で要件を明確にし、双方が同じものを改善目標に置く状態を作っていこうと思います。
しかし、開発において「機能要件」と「非機能要件」があり、それぞれがどのような範囲になっているのか、どのような役割を担っているのか、ということについては、ディレクターやプロジェクトマネージャーが非エンジニアであっても意識しておくことは大事だと思います。
何かの機能を追加する、あるいは従来の機能を改善する際、その機能はどこかの非機能要件を支えている、または、既存箇所に影響を与えるかもしれません。
開発者が既存箇所に影響が出ていないか担保することは当然ですが、上がってきた機能を確認する側もまた、そうした影響を意識すべきです。
もちろん、非機能要件の範囲は広く、そのすべてを非エンジニアが意識する必要な無いですが、それこそ、非機能要件のうち、どの部分までは考慮しなければならないか、くらいは事前に把握しておくことは重要だと思います。

今後の取り組み

現在までは曖昧な部分があった、こうした非機能要件の取り扱いですが、今後私のチームでは、非エンジニアであるディレクターと開発を担うエンジニアとの間で、具体的な要件定義を挟んで会話ができる体制を作っていきたいと思っています。
もっとも、IPAが定める非機能要件グレードのようなものを作るのはオーバースペックではあるので、チーム内でもう少しミニマムな要件定義の雛形を作り、機能要件のみならず、非機能要件についても、必要な箇所はディレクターが明確に要件を作成する方法を模索していこうと思っています。
ちなみに、ツールとしては、今開発者間でナレッジ共有のために使っているKibelaがなかなか好評なので、このKibelaのテンプレート機能をうまく活用する方向を考えています。
ユーザが見る、触る画面や機能に比べると、それを支える部分は一見すると地味で優先度が下がってしまいがちなものもありますが、プロダクトの品質向上のためには必須です。
橋渡しの役割としての立ち回り方、チーム内でのナレッジ共有の取り組みについては、来年引き続きこうした場で広く共有していけたらいいなと思っています。

最後に

いや、もう本当にすみません。
次回以降もっとしっかり書きます。