Gleyzer両氏によって共同開発されました。2019で、同言語の発表を行いました。InfoQはPurdy氏に言語と、氏らが解決を目指した問題について聞きました。設計/アーキテクチャアジャイルマニュフェスト:ソフトウェアアーキテクトの視点ソフトウェアアーキテクトの役割と責任はアジャイルソフトウェア開発のためのマニフェストの価値と矛盾していると見えますが、優れたアーキテクトはアジャイル開発チームをサポートするテクニックを見つけています。Streamingは、ストリーミングデータのためのSQLライクなインターフェースを提供します。Streamsによって、Redisがストリーミングデータを複数のプロデューサとコンシューマの間で消費、保持、配信することができるようになります。ソフトウェア開発のマニフェストたゆまず息もつかずに市場に突進することで、会社を静かに消滅の崖っぷちへと追い込みます。それは設計してコードを書く方法を再考する時です。簡単さへの投資は、速さへの投資です。簡単さは知的財産の主鉱脈でもあります。競争上の優位性は、一度失ったら、もう一度手に入れることはほとんど不可能です。Buytaerts氏が過去10年間にわたって、企業がDevOps採用のハイプサイクルをくぐり抜け、変革に対する誤解を解消する過程を支援してきた経験について語ります。裕介システム開発の要件定義工程において、すべての要件を抽出することは非常に困難です。ここでは、この要件抽出を補助する手段のひとつとして、画面プロトタイプを用いて要件抽出を行う技法とその有効性を紹介します。システム開発において、発注側(お客様)の要件を調査し、IT化すべき要件を決定する重要な工程です。この要件が十分に引き出せるか否かでシステム開発の成功が決まってきます。現状ではこの工程において要件の抽出漏れが発生し、実装、試験工程においてお客様からの追加要件が発生してしまうことが多いのです。この現状を解決すべく、要件を取り扱うツールや技法など様々なソリューションが存在します。ここでは、UIの観点を生かして要件抽出を行う技法を紹介していきます。関連スポンサーコンテンツまず、要件定義工程における要件抽出の難しさを、架空の事例を例にとって説明します。PowerPointで画面定義書として作成し、開発側とお客様が意識合わせを行っていました。この画面定義書では、画面については画面のイメージと画面項目を表形式で、画面の動きについては、画面遷移図でまとめていました。(図1)図1要件定義は無事終了し、開発は予定通りに進んでいるようみえました。試験工程において動く画面が出来てきたところでお客様から「想定していた動作と違う」と画面の動作に関するコメントが頻発してしまいました。中には、要件定義工程への手戻りが発生してしまうコメントも散見され、この開発プロジェクトでは対応に追われるようになってしまいました。問題の原因はこの開発プロジェクトでは要件定義工程において、図1に示したように開発側とお客様の意識合わせは、紙面のみやり取りされていました。画面の動作に関する定義は、画面遷移図でなされていたものの、お客様は、画面の動作については明確に理解をできていなかったのです。このため、試験工程で動く画面に触ってみて初めて、開発中のシステムと自分のイメージの違いに気づき、コメントを出すようになりました。一般的に開発プロジェクトにおいて、画面の定義が紙面などの動きをともなわないものでなされることは多いです。この時、上記の開発プロジェクトのように開発側とお客様側でシステムの動きに関するイメージが共有できていないことが頻発しています。これは、近年、画面の表現力が飛躍的に向上し、以前に比べて複雑なシステムの動き(インタラクション)を表現できるようになったものの、システム開発では動きに着目した開発がなされていないためだと思われます。このため、お客様にはシステムの動きが明確に伝わりません。このような問題を防ぐには、開発側とお客様で、システムの動きも含めた意識合わせを行うことが重要となってきます。画面プロトタイプを作成して利用のイメージを伝える利用イメージを明確にする画面プロトタイプについてお客様に利用イメージを伝える最も良い方法は、実際のシステムを使っていただくことです。要件定義工程においては、使ってもらえる実際のシステムは当然できていません。そこで、実際のシステムのように動作する画面プロトタイプを用いることがお客様に利用イメージを伝える一つの有効な手段となります。画面プロトタイプとは、実際のシステムに近い画面や画面の動きをお客様に伝え、開発側とお客様の意識のずれを見出し、解消を図るために用いられ、その実施方法にはペーパープロトタイピング、実装技術を用いたプロトタイピング、ツールを利用するプロトタイピングなど様々な方法があります。ペーパープロトタイピングはその名前の通り、紙を使ってプロトタイプを作成する方法です。紙に画面を描き、画面上の動的に動く部分(たとえば、プルダウンメニューなど)は付箋などとして準備しておきます。お客様に利用イメージを伝えるときは、開発側が、動的に動く部分を状況に応じて手で張替えたり、画面に書き足したりして行きます。非常に安価で手軽な方法です。実装技術を用いたプロトタイピングでは、画面を実際の実装技術(Htmlなど)で作成します。実際のシステムと違い、画面に表示される値などは典型的な値を静的にはめ込み、画面遷移についても条件分岐などのない単純なものとして作成することが多いです。実際のシステムに近い画面を作り込むことができる半面、作成や修正にコストがかかりやすくなる方法です。ツールを利用するプロトタイピングでは、ツールにてシステムを模した画面を作成します。画面の作り方は、ツールの仕様によって異なりますが、基本的には画面に対して、画面部品を貼り込んでいく形となります。ツールよっては画面の動きをよりリアルに表現できるものもあります。生産性や表現力が変わってくるため、より適した専用ツールを選定することが重要となってきます。開発プロジェクトで画面プロトタイプを作成する際には、画面プロトタイプ作成方法を選択しなくてはなりませんが、その際の重要な観点となるのが、「利用イメージの伝達力」と「開発の生産性」でしょう。一点目の「利用イメージの伝達力」は、まさに画面プロトタイプを利用するその真価が問われることになります。利用のイメージが伝わる画面プロトタイプの利用はお客様の要件抽出につながります。二点目の「開発の生産性」は開発プロジェクト全般に言えることであり、当然画面プロトタイプ作成においても考慮されるべきものとなります。この2つの観点を考慮した画面プロトタイプ作成方法の選定については、後ほど触れます。画面プロトタイプ作成に当たって、まず問題となるのが、そもそも画面プロトタイプ作成が開発プロジェクトで受入れられにくいことです。時間やコストの面で余裕のない開発において、時間やコストをかけた以上に価値のある要件を抽出できるでしょうか。仮にもし画面プロトタイプが容易に作成できたとしてもそのような画面で要件が抽出できるのか、といった疑問があるためでしょう。この点については、後ほど適用例を挙げてその有効性を示します。ここでは、無事プロジェクトに画面プロトタイプが受け入れられた後に注意すべき点を挙げておきます。画面プロトタイプを作る際の注意すべき点の一つに、作りこむ粒度の調整があります。あいまいに作ってしまうと、システムの利用イメージがお客様に伝わらず、本物らしく作りこみすぎると、コストがかかってしまうことがあります。システムの利用イメージが無事にお客様に伝わり、お客様から多くの要件を抽出できるようになる時も、実は注意が必要です。多くの場合、要件は画面の情報項目、レイアウト、機能、はたまたデザインなど多岐に渡って出されてしまい議論が発散してしまう可能性があるためです。画面プロトタイプを最大限に活用する技法についてこのため、画面プロトタイプの作成においても、作りこむ粒度の検討やお客様とのレビューの方法を整理した定型的な技法に則って実施するのが良いです。図2最初に、開発側の作成するプロトタイプの粒度の意識合わせを行い、作り込みすぎないように気をつけます。作成しているプロトタイプをなるべく早い段階でお客様に見せ、確認を取ることが重要です。レビューの場においては、議論のスコープを定め、意見が発散しないようにします。「基本フローの画面」「エラーの画面」「その他の画面」などといったステップ分けの考え方が有効です。それぞれのステップでアイディアを収集し、整理を行います。レビューにおいてステップ外のアイディアが出てきた場合は、そのアイディアを先のステップに先送りしつつ、議論をステップ内に戻るように促し、発散を避けるように調整します。プロトタイプの作成を行い、お客様とのプロトタイプを用いたレビューも行ったうえ、可能であれば取り組みたいことの一つに、ユーザビリティ(使いやすさ)の確認があります。おけるユーザビリティの診断では、診断対象がドキュメント中心となり、どうしても実戦にかける診断となってしまいます。要件定義工程において動くプロトタイプを作成しておくと、ユーザビリティの診断もより実践的になり、多くの改善点を抽出することができます。開発の初期工程であるために、実装技術による縛りなどがないために抽出した改善点への対応も容易となっています。このように、プロセスに則ってプロトタイプを作成し、お客様とのレビューでプロトタイプを活用していくことで、お客様の要件をより多く抽出することができます。ユーザビリティの確認にプロトタイプを活用することで、システムの使いやすさも向上させることができ、その結果としてよりお客様に満足していただける質の高いシステム構築につながる要件定義を実施することができるようになります。ツールを利用して画面プロトタイプを作成するツールによる画面プロトタイプここで、上述した画面プロトタイプ作成方法を「利用イメージの伝達力」と「開発の生産性」の2つの観点で整理しておきます。図3画面プロトタイプ作成方法として、ペーパープロトタイピングは、容易に作成でき開発の生産性は良いものの、利用のイメージがお客様に伝わらない可能性があります。次に、実装技術を用いる方法は、利用イメージの伝達力がある半面、開発の生産性を落としてしまう可能性があります。最後にツールを利用したプロトタイプについては、ツールの仕様によってメリットが変わります。いった汎用なツールから、プロトタイプ作成に特化したツールがあります。このうち、特にプロトタイプ作成に特化したツールが「利用イメージの伝達力」「開発の生産性」という点で有効です。Studio」「iRise」といったツールが挙げられます。AgileNetが日本語版を販売)。評価目的について開発において、画面プロトタイプを用いることの有効性は実際のところはどうなのでしょうか。画面プロトタイプを作成して利用のイメージを伝える」で取り上げた要件抽出技法を実際のプロジェクトに適用し、評価を行いました。この結果、画面プロトタイプを用いたレビューを行うことで、紙面のみのレビューよりも要件抽出数が増加することを確認できました。行った開発プロジェクトは、30画面程度の社内で利用するウェブアプリケーションです。この開発プロジェクトに筆者も参画し、画面を検討し評価を行いました。RP」を利用しました。具体的な評価方法は以下のとおりです。開発中のある特定の画面に対して、まず紙のみで数回レビューを実施し、開発者側、お客様側からの要件を抽出します。次に、おおよそ要件の抽出が収束したところで、同じ画面について画面プロトタイプを用いて開発者側が動く画面をお客様に提示し、レビューを実施します。このとき、開発者側は頻繁に用いられる機能を中心とした利用シナリオを作成し、そのシナリオに沿ってレビューを行います。そのレビューにおいて紙のみでのレビューに加えて追加の要件がどのくらい抽出されるかを確認します。画面プロトタイプを用いたレビューが有効であるならば、紙のみでレビューを数回繰り返して要件が出切った思われる画面に対して、さらに画面プロトタイプを用いてレビューをすることで、新たに要件が抽出されるはずです。以下に、紙のみで2回のレビューを実施し、その後画面プロトタイプを用いたレビューを実施した際の、要件抽出の数の推移を示します。レビューの1回目(紙面利用)では非常に多くの要件が抽出されましたが、2回目(紙面利用)ではすでに要件の抽出が収束してきています。そのまま3回目を外挿するとほとんど要件の抽出は見込めません。実際にはレビューの3回目(画面プロトタイプ利用)で再び多くの要件が抽出されました。このことから、画面プロトタイプを用いることで要件抽出数が増加することを確認できました。用いたため、修正作業などが非常に効率化でき、トータルとしての作業時間はこれまでの開発とほぼ変わらないものとなりました。動くプロトタイプを用いることで抽出された要件とは動くプロトタイプをお客様とのレビューで用いることで新たに抽出された要件は、主に画面の動きに関する部分(動的に変化するプルダウンメニューの中身)や画面遷移に関わる部分でした。画面の実際の動きや、遷移のイメージは静的な紙面ではなかなか伝えにくい内容であり、画面プロトタイプを用いることでこれらのことがより具体的に伝わったため、要件の抽出に至ったと思われます。このことからも定性的にも動く画面プロトタイプを使うことの有効性が確認できました。まとめ画面プロトタイプを用いた要件抽出方法の有効性について要件定義工程において、画面プロトタイプを用い要件を抽出する方法は有効です。画面プロトタイプを活用して、お客様から要件をしっかり抽出する技法を実践できるとより効率よく要件を抽出することができます。画面プロトタイプを作成する際には、専用のツールを用いることも効果的です。お客様に利用イメージを明確に伝えることができつつ、開発の生産性も確保できるためです。ユーザビリティに関する研究開発を実施しつつ、NTTデータが手掛けるシステムのユーザビリティ診断や設計支援などに従事しています。毎週火曜日に前週のまとめコンテンツがお送りいたします。25万人ものシニアデベロッパーのコミュニティーにぜひご参加ください。サンプルを見るあなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。登録するとさまざまなことができます。アカウント登録をしてInfoQをお楽しみください。あなたの意見をお聞かせください。毎週火曜日に前週のまとめコンテンツがお送りいたします。25万人ものシニアデベロッパーのコミュニティーにぜひご参加ください。サンプルを見る様々なイノベーターとアーリーアダプターがお送りするテクノロジーの概要を見る。自分がまだ知らないことに気づいていないと知るあなたが興味のあるトピックスをいつでも最新な情報に。あなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。よい世界へ私たちが暮らす世界を大切に思い、よりよいものにしたいと考えています。人のためのソフトウェア開発を加速し私たちのミッションを実現することで、この思いを成し遂げようとしています。私たちは利益の1%をさまざまな慈善団体に寄付しています。会社として、また従業員として、そうしたことの価値を強く信じているからです。with.プライバシーBTあなたのプロファイルは最新ですか?プロフィールを確認してアップデートしてください。アドレス*Eメールを変更すると確認のメールが配信されます。会社名:現在の会社名をご入力ください。Other組織規模:現在の組織規模をご入力ください。2,501+国:現在の国を設定してください。Zimbabwe都道府県:現在の都道府県に設定してください。次の都道府県にアップデートする:ニュースレターを購読しますか?インダストリーメールを購読しますか?本Eメールに登録すると、以前より関心のあったトピックの関連情報をお送りする場合がございます。詳細はこちらのプライバシーポリシーをご覧ください。newsletter?新しいメールアドレスに確認用のメールを送信します。このポップアップ画面は自動的に閉じられます。