PR
クラウド時代に通用する「見える化」の実践法
情報システムの歴史はメインフレームに始まり、クライアント/サーバーによるオープン化、サーバーの仮想化、システム基盤のクラウド化へと進んでいる。システム形態の変化に伴い、かつては業務の一部を代替するものだったコンピュータの役割も、業務の遂行に必要不可欠なものになった。同時にシステムの大規模化と複雑化が進んでいる。こうした中、プロジェクトを成功させるために、システム開発の各フェーズにおける「見える化」はもちろん、個々の開発者が担当すべき仕事を明確にすることの重要性が日増しに高まっている。
以下では、まずシステム開発のフェーズを細かく分解し、どうしたら徹底した見える化が可能になるか、その実践方法を見ていく。続いて、プロジェクト管理という、どちらかというとマクロな視点での見える化についてもポイントを整理する。
企画・要件定義の見える化
非機能要件の合意を形成
アジャイル型やウォーターフォール型などの手法に関係なく、システム開発は大まかに(1)企画、(2)要件定義、(3)設計、④コーディング、(4)テスト、(5)リリース、(6)運用というフェーズからなる。そして、それぞれのフェーズにおいて見える化が可能だ。
システム要件を見える化する最大の目的は、開発するシステムの要求条件をユーザー企業と合意し、満足度を高めることにある。このとき大切なのは、「非機能要件」を明確にすることだ。大手システムインテグレータを中心とする検討会は、「非機能要求グレード」という用語を用いて、非機能要件を整理する重要性を次のように説明している。
非機能要求グレード検討会では非機能要求の見える化と確認の手段を実現するため「非機能要求グレード」を検討しました。非機能要求グレードでは要件定義工程までに確認が必要な非機能要求項目を体系的に整理し、項目ごとにレベル付けした選択肢を提示することで、これまで受発注者の間で曖昧な表現で意識あわせをしてきた内容を明確に共有することができます。（同検討会のWebサイトより）
同検討会はこれまでに、要件定義に盛り込むべき「システム基盤の非機能要求に関する項目一覧」を公開、次の6つの大項目を中項目から小項目へと細目化している。
- 可用性：システムの耐性
- 性能・拡張性：システムの応答速度や増設のしやすさ
- 運用・保守性：システムの維持のしやすさ
- 移行性：システムの更改のしやすさ
- セキュリティ：データの安全の度合い
- システム環境・エコロジー：環境への配慮
この一覧は、発注者であるユーザー企業と受注者である開発者との間で、システム応答速度や維持のしやすさ、環境への配慮といった非機能要件を検討する際のチェックリストとして有効利用できるだろう。
システム利用方法の想定シナリオも作成する
非機能要件の見える化以外に、筆者が重視しているのが、「ユースケースシナリオ」の作成である。これはシステムがどういった局面で使われるかをユーザー企業と一緒に検討し、想定される一般的なユーザー像を基にシステムの利用方法をシナリオ化したもの。要件定義の早い段階で、目的のシステムがどのように使われるのかユースケースシナリオにまとめておくことで、設計フェーズにおけるUML（Unified Modeling Language／統一モデル言語）のユースケース（後述）が策定しやすくなる。
一般的に「ペルソナ/シナリオ法」と呼ばれる手法を活用し、ペルソナ（架空の人物）を登場人物とする物語（シナリオ）を作る。そして想定されるシステムの利用パターン、すなわちインタラクションやシステムの振る舞い、機能を明確にして、デザインの要件を確定していく。
成果物はシステム利用のシーンを文章で表現した物語となる。個々のシーンは、利用者が何を目的にどのような状況で何を考え、または感じながらシステムを操作するかを示しており、ユーザーの行動を想定しながらデザインするための基礎情報になる。実際、筆者は主な利用シーンを全体のサービスイメージとして絵を描いて添えるようにしており、ユーザー企業との要件の意識合わせに力を発揮している。
設計の見える化
モデリングによって意思疎通
設計フェーズで見える化を進める目的は大きく2つある。1つは、開発者間で意思を疎通しやすくすること。もう1つはユーザーとの意思疎通を促進し、合意を形成しやすくすること。
情報を正確に伝達する手法の1つに、設計書を単純な図形で示すモデリングがある。先に少しだけ触れたUMLは、ソフトウェア工学におけるオブジェクト指向開発のために標準化された仕様記述言語であり、モデルの記述様式を形式化･標準化した代表例だ。ユースケース図（図1）、シーケンス図、状態遷移図、クラス図、コンポーネント図、配置図の作成に用いることができる。
UMLを使うことで、誰もが同じルールでモデルを書くことができるといったメリットがある。さらに、矢印や四角など簡単な記号の意味を一度学習すれば、誰でもモデルを理解できるという利点もある。しかし、図が単純なためにUML以外の設計図も作成して補完した方がよいケースは少なくない。例えば、システムアーキテクチャの概観などはUMLだけでなく、ブロック図によって内容を補うことが意思疎通を図る上で大切だ。
コーディングの見える化
版管理の徹底で品質を確保
ソースコードとそのバージョンは適切に管理されているか─。コーディングのフェーズで肝心な見える化を実現するには、ソフトウェアの構成管理ツールが有効だ。以前は「CVS（Con-current Versions System）」と呼ぶツールが利用されることが多かったが、最近は「Subversion」が使われるようになってきている。
図2は、オープンソースのソフトウェア開発環境であるEclipseにSubversionのプラグインを組み込んだものである。筆者の開発プロジェクトでは、チームのメンバーがネット上にあるSubversionのソースコードリポジトリに修正したコードをコミット（アップロード）すると、変更部分を開発メンバー全員にメールで通知する仕組みにしている。
見える化の仕組みとしては極めて簡素かもしれないが、ソースコードの品質を確保するという観点で、開発の現場では必要不可欠な仕組みだ。ソースコードのどの部分を誰がどう修正したかを確認できるため、ソフトウェアのチーム開発とバージョン管理の効率化の双方に役立っている。
テスト/リリースの見える化
クラウドの機器配置も制御
テストフェーズの見える化には、「プロファイラ」と呼ぶツールが利用できる。プログラムが意図通りに動作しているかだけでなく、プログラムのどの部分がボトルネックとなって処理に時間がかかっているかといったパフォーマンスも把握可能だ。見える化した内容はプログラムの改善に役立てられる。
プロファイラはプログラムの余計な部分を削ってパフォーマンスを高めるのに用いられるケースが多いが、ウェブサイトの表示性能を改善するのにも用いられる。ブラウザ「Firefox」に組み込まれたプロファイラ「Firebug」をご存じの方も多いだろう（図3）。
システムをリリースするフェーズでは、配置の見える化が重要だ。特にクラウドを本格利用するに当たり、いかに効率よく仮想環境にサーバーを配置して見える化できるか、開発から運用フェーズにかけてキーポイントの1つになってくる。
システム配置の見える化に有効なツールの例が、米ベンチャー企業3Tera（本誌注：CA Technologiesが買収）の「AppLogic」である。App Logicはブラウザ上でネットワーク構成を描くと、それをクラウドのサーバー環境に反映する（図4）。ネットワーク設計からサーバーの配置までを一貫して見える化して制御できるわけだ。従来のようにネットワーク構成図はMicrosoft Office Visioなどで描き、別途サーバーをプロビジョニング（システムの初期設定）するといった煩雑さがなくなる。
運用の見える化
クラウドの稼働も監視
システムをリリースした後、障害の正確な察知や迅速な対応をするうえで運用フェーズの見える化が欠かせないことは言うまでもない。具体的には、サーバーが正常に動作しているか、ネットワークは切断されていないか、CPUの負荷は正常範囲内か、ディスクの使用量はオーバーしていないか、といった項目を逐一確認しながら可用性（Availability）をモニタリングする。
図5はオープンソースの監視システム「Nagios」の画面例である。複数のサーバーやネットワーク機器をブラウザから一元的にモニタリングし、障害があるとアラートを出す。これと似たモニタリングの仕組みをクラウド環境向けに提供する企業も存在する。米ベンチャー企業のRightScaleが、その1社だ。
RightScaleのサービスを使うと、米Amazonが提供するクラウドコンピューティングサービス「Amazon EC2」上に構築したシステムを監視できる（図6）。仮想サーバーのリソース状況（CPU、ネットワーク、ディスク、サービスの監視など）を確認して、問題を発見するとアラートメールを出す。CPUの負荷に応じてサーバーを自動的に追加することもできる。見える化によって従来は人手で行っていた作業の自動化が可能になり、運用の負担やコストの削減につなげられる。
進捗状況の見える化
市販ツールの長所と課題
ここまでは企画/要件定義から運用までシステム開発の各フェーズごとに見える化のポイントを見てきた。ここからは、もう少し上位の目線でプロジェクトの見える化について解説する。
プロジェクトの見える化とは、システム開発現場の見える化であり、第1に取り組むべきは進捗状況の可視化だ。そのための有名なツールの1つにプロジェクト管理ツール「Microsoft Office Project（以下MS Project）」がある。MS ProjectはMicrosoftが自社内で実際に使っているプロジェクト管理ツールを販売しているもので、機能的には申し分ない。特に以下の点において、筆者はMS Projectが進捗状況の見える化に有用だと考えている。
-
ガントチャート作成機能
ガントチャートが簡単に書ける。すなわち容易に進捗管理ができる（図7）。
図7 「Microsoft Office Project」の画面例。プロジェクトの進捗をガントチャートで把握できる -
外部ツールとの連携
Outlookと併用するとスケジュールやタスク（仕事）管理を連動させられる。 -
きめ細かなプロジェクト情報管理
統計情報を提供してくれる。プロジェクトの人的リソースの単価計算などもすべて組み込めるため、厳密なコスト管理ができる。
ただし、筆者の経験ではMS Projectには次のような課題もある。
-
ライセンス料
大規模なチーム開発では各メンバーにライセンスを用意しなければならなず、コストがかかる。また、MS Projectがカバーする機能は多く、小規模なチームでのシステム開発ではオーバースペックになる。 -
ポータビリティ
各部門間（あるいは子会社などの間）でMS Projectのファイルをやり取りして情報共有する際に、相手がMS Projectを持っていないとファイルを開けない。このためPDF形式に変換して保存するなど、本来は必要のない手間がかかる。 -
情報の一覧性
大規模なプロジェクトのガントチャートはもはや一画面では収まりきれなくなり、タスクを増やしていくと見通しが悪くなっていく。図などの拡大縮小の機能は備わっているが、メンバーが一堂に集まりプロジェクトの進捗をプロジェクタに映し出したいときや、紙に印刷して見たいときなどの一覧性の悪さは避けられない。
OSSを駆使して進捗と問題点を管理
コストを押さえながら、プロジェクトの進捗状況を一覧できる仕組みを用意できないか。そう考えるのは、筆者だけではないだろう。筆者が実践している1つの例が、ブログの応用である。
筆者の開発プロジェクトではブログに要件やタスクを入力し、その進捗状況に対してコメントを残すことで、プロジェクトの進捗状況と問題を管理している。このシステムは、ユーザー管理の仕組みやブログシステムの機能を備えるオープンソースのCMS（コンテンツ管理システム）「Drupal」に、「Case Tracker」と呼ぶモジュールを組み合わせて構築した。
このシステムでは、あらかじめ用意したフォームにしたがってタスクのタイトルや優先度、期限、実施者、ステータスを登録すると、登録した項目をステータス（未着手、実施中、完了など）に応じて色分けしてリスト表示する。本稿の執筆時点で、ガントチャートのモジュールがないのは残念だが、プロジェクト名やステータス、優先度などの条件でリストをフィルタリングでき、進捗や問題を一元的に把握するのには重宝する。
ガラス張りのデメリットはマネジメントで解消する
ひと口に見える化といっても、さまざまな切り口があり、それぞれに効果的なツールや仕組みが存在することは、これまでに述べてきた通りだ。最後に、それらのツールや仕組みを活用して徹底した見える化を実践するメリットとデメリットを整理しておきたい。
メリットについては改めて詳説するまでもないだろう。今この瞬間に発生している問題を早期に発見できる。そのうえでタスクの優先度を臨機応変に決め、プロジェクトのメンバー間で主要なタスクが何かを共有することが可能になる。
進捗状況など見える化した情報をユーザー企業側にレポートとして報告・開示すれば、システムやプロジェクトの透明性の確保にもつながる。プロジェクトがどのような過程で進められているかを共有することで、顧客満足度を高める効果も期待できる。
一方、進捗状況がガラス張りになることが、結果的にデメリットとなるケースもある。例えば、進捗の遅れが目立ち始めたときだ。進捗の遅れは、プロジェクトメンバーのモチベーションを下げる原因になりかねない。
こうしたデメリットが存在することをきちんと認識し、プロジェクトのマネジャーは適切にサルベージプランを示す準備をしておかなければならない。サルベージプランでは、基本的にタスクを分割して粒度をさらに細かくする。個々が担当するタスクを簡単に進められるレベルまで細分化すると、進捗状況の遅れが解消しやすくなり、結果としてプロジェクトメンバーのモチベーションもキープできる。
このときメンバーの能力を見極めてタスクの粒度を適切に定め、メンバーとの間で合意を得ながら割り当てることが肝要だ。タスクの難易度やボリュームが同じでも、遂行できる能力は各メンバーによって異なるからである。タスクをフェアに割り当て、メンバーに責任を持って取り組んでもらう意味合いも強い。
◇◇◇
見える化は今に始まったことではない。筆者の場合、入社当時は一太郎で進捗管理をしていた。その後、ExcelからMicrosoftのMS Project、Webへと見える化に用いるツールは変わった。Webを活用するようになってツールの操作やレポート作成、情報へアクセスしやすくなり、タスクの完了率を逐一確認・共有できるようにもなった。だが、検討項目やマイルストーンの設定、ToDoや問題管理のリスト化など、見える化すべき項目は実は普遍的である。
ツールや仕組みは変わっても、脈々と続いてきた見える化のゴールは変わらない。「プロジェクトのメンバー間、および開発側とユーザー企業側との間で合意形成（コンセンサス）を図ること」、そして「プロジェクトを遂行する中で発生する問題を迅速に発見し対処すること」である。それが個々の開発者の生産性を向上させるのはもちろん、リソースとコスト、納期、品質のきめ細かい管理を可能にして、最終的にユーザー満足度を高めることになる。
本誌は、読者登録いただくことにより、毎月無料でみなさまのお手元まで直接お届けいたします（書店などでは販売していません）。
企業の情報システムを担当する方々や事業部門のIT担当の方々、およびIT関連プロフェッショナルの方々を対象に、実践的に役立つ情報を掲載、幅広く業務にご活用いただけます。
- データセンター見積もりは「DC完全ガイド」
最新iDCやテクノロジ・製品情報が満載。iDC事業者・サービスカタログで見積もり資料請求にも対応 - レンタルサーバー比較検索「RS完全ガイド」
共用・専用・VPS、国内1600以上のレンタルサーバー／ホスティングから最適なサービスを比較検索 - クラウド比較検索「クラウドサービス完全ガイド」
企業に役立つクラウド関連記事、製品・サービス情報
