皆様、こんにちは。
エコモットの板橋です。
前回投稿した「バグ分析」は、主にシステム開発の下流でいかに状況を把握して、リスクコントロールしていくかというお話でした。
今回は、同じプロジェクトで同時に導入した要件定義～設計工程までに導入した「1文節1仕様」というルールについてお話ししたいと思います。
※実際は、上流から下流に至るまでのトレーサビリティもやっていますので、現実的には「1文節1仕様1ID」なんですけど、”1ID”の部分はまた今度…
なお、この記事は以前に書いた「察する文化」がシステム開発と相性が悪いという現実の深掘り・導入編に該当するものです。
まだ読んでいない方は、先にお読みいただくことで、導入のきっかけや考えについて理解が深まると思います。
導入のきっかけ
システム開発を行っていると、皆さんも、認識の齟齬や勘違い等が理由で戻り作業をした（もしくはお願いした）経験が少なからずあるのではないでしょうか。
私もありますよ。メンバーには大変申し訳ない思いで、謝りながらお願いしています。
では、なぜこのような事が起きるのでしょうか。
それについて考察した記事が、冒頭で紹介している”「察する文化」が～”の内容というわけです。
では、考察して終わりなのか、、、というと、そんな訳ありません！
もちろん、しっかりと対策を打たせて頂きます！
対策を色々考える過程で、文章を分解しながら、勝手な解釈の余地を削り、本質を損なわない様に簡潔な内容にしたら「1文節1仕様」になってしまった、、、という話なんです。手元で文章をこねくり回していたら、偶然出来上がった「1文節1仕様」が最も直感的でノイズの少ない内容だったという事なんです。
じゃぁ、プロジェクトに適用しよう（爆）という事で導入した結果どうだったかというのが、今回の内容になります。
文節とは何か
文節とは一般的に、”意味の通じる範囲で文を分割した最小の単位（単語のまとまり）”を指します。（要件の最小単位を示すための区切り）
身近な例だと、箇条書きをイメージしてもらえれば良いかと思います。
プレゼン資料など、他人に何かを伝える場面で、長文で説明するよりも、端的に要点のまとまった箇条書きの方が、スムーズに頭に入ってきますよね。
それを、開発工程上流のドキュメント作成に応用しましょうという事なんです。
気づきを与えてくれる
要件定義は、お客様からの資料やミーティングで、システムで行いたいことをヒアリングしていきます。
ただ、資料や会話ベースでは、すべての状況や条件が網羅されていない事が多く、ドキュメントを纏めている過程でエンジニアがそれに気づいて確認しない限り、設計漏れとして後続の工程へ流出してしまうリスクが出てきます。
それを1文節1仕様で書き始めると、下記のように色んな事が見えてきます。
- 「～の場合」・・・条件がある事を示唆している、条件に合致しない場合も考慮が必要
- 「～時に」 ・・・タイミングが決まっていることを示唆、それ以外のタイミングはどうするのか考慮が必要
- 「除算する」・・・ゼロ割や端数処理の確認が必要
- 「連続で～」・・・連続しない場合や連続回数の確認が必要
- 「～経過で」・・・経過していない場合や長時間経過時の確認が必要
要点をまとめて端的にシンプルだからこそ、こういった部分の気づきが際立って目立つようになってきます。
実は仕様に変換するための事前準備をしている
システム開発をする際には、必ずシステムで実現したいこと（機能要求）が存在します。
それは、お客様やサービスの運営主体が「こういった事を実現したい」という内容です。
私たちは、上流工程のどこか（大部分は要件定義→外部/内部設計）で必ず、このような要求事項を「システムの仕様」として変換する必要が出てきます。
この作業は、「日本語による曖昧な表現」をシステムの振る舞いとして「厳密なコンピュータの論理的な定義」に落とし込む作業です。
曖昧な表現である文章を、0,1しかない厳密なコンピュータの世界の振る舞いとして直接落とし込むわけですから、当然のように漏れや、本来の解釈とは異なる解釈で仕様が作成されるリスクが高まります。（イメージ緑矢印）
更に、このリスクに拍車をかけているのが、「どの程度漏れるか」「どの程度異なる解釈をするのか」という点が人に依存しているという点です。
設計作業は、1人で全ての設計をするのではなく、複数のメンバーで手分けをして行います。
当然、メンバーそれぞれで文章の捉え方や考え方が異なりますから、個人差が出てしまう（品質のばらつき）事になります。
1文節1仕様で記載するとどうでしょうか。（イメージ青矢印）
最小単位にまで分解された文章は、単純・明解で曖昧さが無く、個人による品質のばらつきも起きません。
下記に、ログイン認証でのアカウントロックの要求仕様を例に比較してみましょう。
（文章の場合）
パスワードを3回連続で間違えた場合、入力されたIDをもとにアカウントをロックし、管理者に通知メールを送信する。
また、24時間経過後または管理者が解除した場合はログイン可能となる。
（1文節1仕様）
- 連続でパスワード認証を失敗した回数をカウントすること
- 連続3回失敗した場合、該当アカウントをロックすること
- ロック対象のアカウントは、IDに入力された情報で特定すること
- アカウントロックが発生した場合、システム管理者にメール通知を行うこと
- アカウントロック実施後24時間経過で、自動的にアカウントロック解除を行うこと
- 管理者は24時間経過前でも、任意のタイミングでアカウントロックの解除ができること
如何でしょうか。
比較してもらうと、理解のしやすさは一目瞭然で、人によって理解に差が出る心配も極めて低い事がお判りいただけるのではないでしょうか。
また、文章の場合と1文節1仕様で書いた場合、明らかに1文節1仕様で記載した方が設計に落とし込みやすいと思いませんか？
このように、仕様に落とし込みやすい形で纏めることで、漏れや、異なる解釈で設計してしまうリスクを下げ、同時に、個人による品質のばらつきも抑えるという両方の効果があります。
少しトレーニングが必要
1文節1仕様がどの様なものか、詳しく説明しましたが、やってみたらできそうだと思いませんか？笑
私たちのチームでも業務で実際に行った際は、それほど大きな混乱もなく、比較的スムーズに1文節1仕様の実践ができています。
一番最初に、私が作成した要件定義書をメンバーに見せ、「1文節1仕様（要件定義の場合は1文節1要求）の書き方はこうだ」というものを示し、文章を徹底的に最小限の文節単位に分解する方法や考え方をレクチャーしました。
レビューで、1文節に複数の仕様があるケースなど散見されましたので、都度、指摘しつつ、分解する為のトレーニングを行いました。
また、日常の文章作成の癖のようなもので、「～など」「不適切」「処理」など、曖昧な語句を使ってしまうケースもありましたので、こういった読者に解釈を委ねる語句を纏めた「禁止語句リスト」を作成しました。
レビューする際に、禁止語句を使用していないかもレビュー観点として加え、「無意識の曖昧さ」を排除する取り組みを進めました。
しかし、初めての手法という事で、やはりテスト工程で幾つかの考慮漏れ（お客様から聞いたメインのifに該当する条件は実装されているが、言及されていないelse、elseifの考慮漏れ）があり、「気づきを与えてくれる」で記載した、考慮すべきポイントを徹底する必要があるという有益な改善点を得ることができました。
やってみてどうだったか
思った以上に、要件定義～単体テストまで非常にスムーズに進行したイメージです。
これには幾つかの要因があると考えています。
- 担当者による設計品質のばらつきが最低限に抑えられた
記載内容に対して、誤解の入り込む余地が無いためだと考えられる - 設計レビューの精度が上がった
フローチャートと組み合わせて記載した場合、処理の流れが非常に分かり易く、レビュアーが理解しやすい形式だったためと考えられる - 重大な設計ミスのバグは検出されなかった（軽微な設計ミスはバグ全体の7%弱）
品質の高い設計を行う事が出来た事による、重大な仕様の解釈ミスが激減したことによるものと考えている
このように、設計工程での記述量の増加による工数の増加を、戻り作業の削減によってカバーすることが出来ています。
悩んだこと
実際に業務でやってみて、少し困ったこともありました。
文章で書くよりも、行数が増えるのです。箇条書きの様なものなので、仕様の多い機能ではどの様に書くか等、迷いますよね。
しかし、「文書としての体裁」と「1文節1仕様の本質」を天秤にかけるまでもないですよね？笑
お客様への納品物ではあるので、必要最小限の可読性と体裁を整えつつ、1文節1仕様の本質が損なわれない様に纏めてもらいました。
また、内部設計において、1文節1仕様の記述だけでは、処理の流れが把握しにくい事から、紙面の左半分をフローチャート、右半分を仕様記述という形で併記する事により、他の人が読んでも
十分に理解できるものとなりました。
※第三者が読んでも誤解なく、正しく理解できる事というのは、私のチームでドキュメントを作る際の必須条件になっています。
トレーサビリティについて触れておく
私たちの今回のプロジェクトは、「バグ分析」「1文節1仕様」「トレーサビリティ」という「三種の神器」とも言えるし、劇薬でもある取り組みを導入しました。
冒頭でも軽く触れましたが、要件定義～単体テスト項目、議事録やバグ票に至るまでトレーサビリティを確保しています。
1文節1仕様であることによって、それに対応するテストがしっかりと網羅されているかどうかまで、追跡できるようになっているのです。
品質の高いソフトウェアを開発するための取り組みとして、今後もできる限り採用したいと私は思っています。
ちなみに、今回のプロジェクトは、スケジュールは6か月、単体テストケースは全体で3,200件、そういうプロジェクトの規模です。（想像にお任せで、、、苦笑）
トレーサビリティの導入に関する内容は、別な記事として改めて書きたいと思っています。
まとめ
以上、ここまで色々と記載しましたが、やはり、複雑なものをいかにシンプルにして伝えるかというのがとても大切な事だと改めて認識した取り組みでした。
シンプルである事によって、余計な解釈や曖昧さが入り込む余地を無くす事ができ、結果、戻り作業をゼロにはできませんでしたが、大幅に減らすことができ、思った以上の成果が出て、メンバーにはとても感謝しているところです。
システムの品質を上げる、ひいては、各工程での成果物の品質を上げる為に必要なのは、プロジェクトを動かす仕組み・ルールが基盤としてあって、その上に各個人の努力や取り組みがあるんだなと、改めて強く実感しました。
本当は、こんな成果が出てるんですよと具体的な数字をあげて、説得力満載で書きたかったのですが、その点は諸般の事情によりご容赦ください、、、泣
最後に、別な記事でも述べましたが、プロジェクトが抱えている制約（コスト、人員、期間）は様々です。
何事も、そういった事前条件を考慮して、何をどこまでやるのか、無理のない範囲で適用するのが重要です。
欲張りすぎてしまうと、最悪、プロジェクトの崩壊を招きますので、その点はご注意ください。
私たちと一緒にモノづくりをしていく仲間を募集しています。 弊社に少しでも興味のある方は、ぜひ下記の採用ページをご覧ください。
