“プロトタイプアプローチ”型開発とは 杉浦技術士事務所 杉 浦 和 史 概要 システムの開発には、ウオータフォール型の開発方式とプロトタイプアプローチと呼ばれる方式とがあります。 前者は、仕様を決める上流工程に始まり、プログラムを作り、仕様通り出来上がっているかをテストする下流 工程まで、上から下へ進めていく方式です。後者は実際に動くプロトタイプを作ってテストし、スパイラル状に 仕上げていく方式です。ウオータフォール方式は、設計する際の条件が変わらないことを前提としているのに 対し、プロトタイプアプローチ方式は、全体構想を立てた後、小さな単位で試行錯誤を繰り返し、変更があれ ばそれを吸収しながら完成度を高めていく方法です。 １．はじめに 一般的に、システムの開発は現状分析から始まり、ＢＰＲ（無理無駄を省いた業務プロセスにする作業）を したのち、仕様を作り、プログラム作ってテストして完成するまでの過程をたどります。 C 図１ 一般的なシステム開発工程○ 仕様が“ほぼ”決まったら、デザインレビューした後、実際に動くもの（プロトタイプ）を作り、操作し、画面 レイアウト、操作性、画面遷移が作業実態に合っているかを関係者でレビューします。当院では、仕様 を決めた者はもちろん、現場で作業をしているスタッフも参加します。 よく吟味して作ったはずの仕様でも、実務に即して使ってみると、機能の過不足が発見されることが 多々あります。また、無理な操作を要求をしていると指摘されることもあります。年に数回しか起らない ことに、手間暇をかけていることが見つかりＢＰＲの結果、システムの対象から外したこともありました。 必要に応じ関連する他部門のスタッフもレビューに参加しますが、そこで部門間での情報授受の齟齬、 機能の過不足が発見されることもあります。これらを反映し、実用性を高め、使い勝手を向上させて いきます。 Coyright2015 杉浦技術士事務所 All rights reserved １ ２．プロトタイプを作るタイミング R という考え方で、以下の手順で設計 筆者は以前より、SCD（Screen Centered Design／画面中心設計）○ しています。 ①業務内容、作業手順を分析 ②ＢＰＲ実施 ③対応する画面を作る ④実際に操作しているように、１操作ずつ画面を遷移させながら、以下のチェックを行う －レイアウト、文字サイズ、線の太さ、色などの見た目の印象はどうか －スム－ズな操作を阻害していないか －機能、情報の抜け漏れはないか －機能、情報の連携を考えているか ⑤仕様に反映する ⑥ ④、⑤を繰り返し、完成度を高める ⑦プロトタイプを作っても良いくらいのレベルまで仕上がっているかを確認する ⑧プロトタイプを作る ⑨仕様通りに動くかを確認する ⑩実際に動くことによって発見される問題をプロトタイプへ反映する ⑪ ⑨、⑩を繰り返し、完成度を高める ⑫完成 以上ですが、⑦は無駄になる部分ができるだけ出ないようにするために必須です。ただし、完璧を目指 さず、７，８割の完成度で臨むのがポイントです（図２）。完璧な仕様に仕上げるのが理想ですが、①少 なからず想定外のことが起きる、②得られる成果に比べ、所要時間が多すぎる、③動いているもので チェックした方が早いし確実。と割り切って考えます。経験に照らし、ある程度の完成度に達したと判断 した時にプロトタイプを作ります。 実際に動く画面を見ながらテストすると、描画ツールで作った画面を紙芝居的に見て、機能、操作性を チェックした時には発見できなかった問題に気がつくことが多々あります。特に性能（レスポンス）は 実際に動くものを見なければ分りません。機能的に満足し、操作感がまずまずでも、操作に対応した 反応が遅かったら使い物になりません。見つかった問題点を反映（ブラッシュアップ）し、更にテストを続 けます。これを繰り返しを行い、完成度を高め（スパイラルアップ）、使えるシステム、効果を実感できる システムが完成します。 C 図２ プロトタイプを作るタイミング○ Coyright2015 杉浦技術士事務所 All rights reserved ２ ３．プロトタイプを作るうえでの注意 プロトタイプアプローチでは、開発期間内に、いかに頻回にプロトタイプ作成→テスト→反映を繰り返すことが できるかがポイントです。それには、“できるだけ早くプロトタイプを作る”ことが求められます。時間を要して いてはプロトタイプアプローチの意味がありません。プログラミング能力、センスに優れた技術者が必要です。 一方、プログラミングは属人性の高い作業であることは知られています。できるだけ属人性を少なくし、生産 性を高めるための開発支援ツール、標準コーディング（プログラムを書くこと）集の整備など、諸施策はありま すが、属人性をなくすことはできません。図３は、筆者が某コンピュータベンダでＯＳの設計を担当していた際 に受けた研修で印象に残っているもので、プログラムの作成が如何に属人的であるかを示すグラフです。 トータルで８倍、個別に見ると２７倍もの開きがあることに驚くことでしょう。研修は３５年以上も前のことです が、数年前、ある大学院で開かれたセミナでこれを紹介したところ、出席していた某大学の先生が、同じ様な 調査をしたところ、個人差が約３０倍あるとの結果を得たとコメントがありました。個人差は何十年経っても変 わっていないと思った次第です。 C 図３ プログラム作成の属人性○ プロトタイプアプローチで臨む際には、この属人性を考慮しなければなりません。極端に言えば、１００名の 平凡な技術者ではなく、１０名のセンスの良い優秀な技術者に任せたい仕事です。石橋を叩き続け、なか なか渡たろうとせず、仕様が完全に仕上がるのを待って次の工程に移ろうとするウオータフォール型開発の 信奉者が開発チームのリーダだったりすると、工程遅延を引き起こす原因になりかねません。 歴史と伝統を誇る大手ベンダ（システム開発会社）に多い“パラダイムシフトできず、時代に乗り遅れた技術 者”が指揮を執ると大幅な工程遅延を引き起こす可能性が高くなります。時代に乗り遅れたという意識がない ので更に問題を大きくします。発注側は、この点に注意し、場合によっては開発要員の交代を申し入れること も必要になります。発注者は丸投げではなく監視しなければなりません。楽そうに見える丸投げは、発注者 に有形無形の損害をもたらす可能性さえあることを肝に銘じましょう。 ４．参考 プロトタイプアプローチの対局にある、ウオータフォール型開発につき、簡単に説明します。ウオータフォールと は英語で waterfall と書き、滝のことです。滝は上から下に向かって流れ落ちますが、これになぞらえ、上流工程 から下流工程まで一般的に不可逆な開発過程をたどる設計手法をウオータフォール型開発と呼んでいます。 上流工程をがっちり固めて後工程に移るこの手法は、コンピュータ黎明期から何十年にも亘って使われ、半ば 常識になっています。このタイプの開発方法の問題は、手戻りが発生した際の対応に工数（時間、手間、費用） がかかり、志気も衰えるということです。工数の多少は、どれだけ上の工程に遡るかにもよりますが、現状分析 まで遡ることになった場合には、極端に言えば作り直しとなり、被害が大きくなります。（図１参照） Coyright2015 杉浦技術士事務所 All rights reserved ３
© Copyright 2024 ExpyDoc
