ObjectSquare [2005 年 1 月号]

[レポート]


「見える化」でソフトウェア開発!


〜オブジェクト指向実践者の集い(第 3 弾) 参加レポート〜

(株)オージス総研
ビジネスプロセスモデリング部
米田 匡史

1.はじめに

昨年の 12 月 9 日、オブジェクト倶楽部主催によるイベント「オブジェクト指向実践者の集い」が行われました。「オブジェクト指向実践者の集い」はオブジェクト指向を現場で実践している、あるいは実践しようとしているエンジニアに役立つよう「現実的なオブジェクト指向とは何か」、「オブジェクト指向を見直してみよう」をテーマとしています。今回で、このイベントは 3 回目となりました。
クリスマス企画という事で会場にはツリーが置いてあったり、スタッフのみなさんがサンタクロースの帽子をかぶっていたりで、和やかな雰囲気でした。 クリスマスツリー

今回のテーマは「見える化」です。ソフトウェアの世界は見えないものが非常に多いです。そして「見えない」ことにより、ソフトウェア開発では様々な問題が出てきます。例えば、アプリケーションは CPU とメモリを使って動いており人間がその動きを見ることは出来ません。そのため、止まってしまったときにどこを直せばよいのかわからなくなります。また、進捗も見えにくいものです。進捗が見えないために、計画がどのくらい遅れているのかが分からなくなるなどの問題が出てきます。
そこで、どのようにしたら「見えないもの、見えにくいもの」を見えるようにすることができるのか、また、見えることによってどのような効果があるのかを考えていくというのが今回のイベントのコンセプトです。

この記事では、「オブジェクト指向実践者の集い」にて行われたセッションについて報告したいと思います。

2. リーンソフトウェア開発と「見える化」
(株)永和システムマネジメント:平鍋健児さん

リーンソフトウェア開発はトヨタ生産方式を使ってアジャイル方法論の有効性を説いたものです。この中でトヨタ生産方式(リーン思考)の「 7 つの原則」をソフトウェア開発に置き換えたものが述べられています。平鍋さんはこの「 7 つの原則」には裏テーマとして「見える化」が含まれているのではないかと話されていました。
そして、アジャイル開発における「見える化」の実例が紹介されていました。それらのいくつかをここで報告したいと思います。

進捗の「見える化」:バーンダウンチャート

バーンダウンチャートはアジャイル開発方法論であるスクラムで最初に紹介されたツールです。
縦軸に実現できていない機能数や残りのタスクの数、横軸に時間(イテレーション,日程など)を取ります。開発の初期に計画を立て、折れ線グラフを書きます。そして実績を折れ線グラフで書きます。例えば、縦軸に「残りのタスク数」、横軸に「イレテーション回数」を取ると 図1 のようになります。

 

バーンダウンチャート
図 1 バーンダウンチャート

計画の折れ線より実績が上に来ていると進捗が遅れている事になります。このように、バーンダウンチャートを使うと進捗の遅れが一目でわかります。
重要な点は、完成したかどうかの判定をテストで管理することです。開発した機能を受け入れテストに通し、成功したら完成とします。これは、テストは必ず 0 か 1 に倒れるので、確実に進捗を管理することができるためです。開発現場でよく、あるタスクに対して「進捗は現在 80 %です」という報告を受けたのに 1 週間が経過し・・・2 週間が経過し・・・っと、いっこうに進捗が進まないという現象が起きます。これは、開発途中の中間成果物で計測しているためです。そこで、テストに通ったかどうかで決めることでこういった現象を防ぐことが出来ます。

作業の見える化:ソフトウェアかんばん

ソフトウェアかんばんは、タスクをカードに書き、壁に張り出したものです。壁には、図2 のように ToDo と Doing, Done の 3 つのカテゴリを作成します。ToDo(未着手) にはイテレーションの始めに抽出したタスクを置きます。そして、朝会で開発者は自分がその日に行うタスクを選び Doing(作業中)におきます。そしてテストが終わったタスクは Done(テスト完成)に移動します(図2)。

ソフトウェアかんばん
図 2 ソフトウェアかんばん

これにより、作業者は今日何をしなければならないのか、今自分は何をしているのかが明確になります。また、リーダーがその日にいなくても今日何をすればよいか迷わなくてすみます。さらに副次的な効果として、行う作業を自分で選ぶことによりプロジェクトに参加しているという意識が高まり、メンバーのモチベーションを高めることができます。

異常の見える化:ソフトウェアあんどん

自動車業界での「あんどん」は、生産工程中に欠陥が流れた時や問題が起こった時につくパトランプの事です。あんどんがついたら即座に問題の解決に当たり、欠陥品が流れるのを防ぐという仕組みです。  
ソフトウェアあんどんは受け入れテスト時の異常を知らせるツールです。全受け入れテストを自動化し、毎日決まった時間にバッチで流します。もしテストが失敗したら即座にあんどんを付け、原因を追求します。  
会場にソフトウェアあんどんとして以下のライトが展示されてました(図 3 )。

 

ソフトウェアあんどん
図 3 ソフトウェアあんどん

  「欠陥のムダによるコスト = 欠陥の大きさ × 欠陥の滞在時間」と平鍋さんは語っておられました。この計算式に従うと、欠陥によって生じるコストはすぐに取り除くことで大幅に低減できると言えます。逆に、欠陥があるのにそのまま放置しておくと、どんどんコストが高くなっていくことになります。つまり、欠陥が見つかったら、今の作業を止めてでも欠陥の修正に専念するのがコストを減らすことに繋がります。そして、コストを削減するために、欠陥が生じた時に開発作業から修正作業にすぐさま切り替えることが重要で、その切り替えスイッチとなるのがこのソフトウェアあんどんです。

カイゼンの見える化:ふりかえりシート(Keep - Problem - Try)

ふりかえりシートは、イテレーションの終わりに振り返りをし、そのイテレーションで行って良かった点を定着させ、問題点には解決策を立ててカイゼンを行うためのツールです(図 4)。

ふりかえりシート
図 4 ふりかえりシート

Keep の欄には実践してよかった点、Problem には問題点、Try には改善策や次のイテレーションで挑戦することを書きます。Keep に書かれたものは定着し、Problem に書かれたものは Try を生み出し、Try に書かれたものは今後 Keep か Problem に移動するという構造になっています。このシートを用いて全員で意見を出し合い、暗黙知の共同化と形式知化を行います。悪いプロジェクトの一例として「こんな事を言ってもいいのかな」とメンバーが感じてしまうものがあります。このツールを用いることで、コミュニケーションを活性化させ、そういった現象を防ぐことができます。

所感

現場での経験談で非常に説得力があり、また分かりやすい説明と聴衆を巻き込むプレゼンテーションで非常に魅力のあるセッションでした。
このセッションで挙げられたツールはアナログなものばかりで非常に驚きました。ですが、どのツールも開発者のモチベーションを向上させる効果を持ち、なおかつすぐにでも使えそうなものばかりでした。
「見える化」による効果として最も重要な点は行動が起きることだと感じました。進捗が遅れているのが分かっていても「どのくらい」遅れているのかが分からなければ対応策が出てきません。また、進捗が遅れているのがわかっていても「何を」すればよいか分からなければただ時間が過ぎるだけです。行動ができないのは判断材料がないためです。しかし、現状が分かればどう行動すべきかの判断材料が増えるため何らかの行動が起こせるようになると感じました。


3. 要求開発 〜ユーザーから見たシステム開発の問題点〜
清水建設(株):安井昌男さん

「要件定義」とは、顧客からヒアリングなどを行いシステムの仕様を決定する作業です。「要求開発」とはモヤモヤとした業務プロセスを明確にすることにより、システム化をどのように行うかを明確にしていく作業です。一般的に広く行われているのは要件定義ですが、要件定義はユーザー企業の要求がすでに存在することが前提と考える場合が多いように思います。しかし、実際には要求は担当者の理解の範囲内で生まれるものが多いため、そういった要求をヒアリングしてシステムを作っても、必ずしもユーザーの望むシステムを作ることはできません。一方、要求はもとからあるものではなく、業務を元に開発されるものであると考えて要件を定義していこうという考え方が「要求開発」です。

このセッションでは、清水建設(株)で行われている要求開発のプロセスについて紹介されていました。

背景

最近のシステムに対する要求は、記録の管理などの「省力化」から新しい「売り方」を支援するものに変化してきています。たとえば、20 年前だと記録を管理するシステム(人事・会計など)が多かったのですが、最近はプロセス制御系のシステム(営業・設計・施工・保全など)に変化してきました。このプロセス制御系のシステムは、インプットが顧客でアウトプットも顧客に直接影響があるものが多いです。このプロセスをすべて自動化していくことで付加価値を高めていくというのが、最近のシステム要求の傾向です。
プロセス制御系のシステムでは、人間が関わってくるところに特徴があります。ですから、システム化する前にビジネスフローを明確に理解する必要があります。

Lane Flow Diagram

ビジネスフローは目に見えず、理解しにくいものです。そのため、ビジネスフローを理解するために、「見える化」を行う必要があります。このセッションでは「 Lane Flow Diagram 」という図が紹介されました。
Lane Flow Diagram は一言で言うと、ユースケース図をアクティビティ図風に並べて、ビジネスフローを表現したものです(図 5)。

Lane Flow Diagram
図 5 Lane Flow Diagram

規約としては以下のようになっています。

プロセスとしては、まず経営方針や企画書などの業務マニュアルから問題点や解決策を理解します。次に Lane Flow Diagram の素案を作成し、それをもとに業務遂行者個別にヒアリング・ミーティングを行います。これを何回か繰り返した後、ステークホルダーを集めて集中検討会を開き、トランザクションの実現可能性を検証します。Lane Flow Diagram を作成することで、ビジネスフローを理解しやすく、また関係者間で共通の認識を持つことができるようになります。
また、Lane Flow Diagram は、概念クラス図作成の資料にもなります。システムのレーンに描かれた Entity アイコンとバケツ型のアイコンは、概念クラス図での Entity クラスの候補となります。また、アクターのレーンに描かれた Boundary のアイコンは画面の候補となります。

所感

ビジネスモデリングの方法論がまだ確立していない中、独自にダイアグラムを作成し、実践しているところが素晴らしいと思いました。
ビジネスモデリングが重要視されてきている背景として、記録を管理するシステムから人間が関わっている業務プロセスの部分をシステム化するという流れに変わってきているためだということがよく理解できました。
ビジネスモデリングが注目されているのは、「要求の見える化」にあると感じました。システムの成功は要件定義の質が大きく関わってきます。ですが、要求というのは本来目に見えないものです。システム開発で最も重要である要求が見えないのに、お客様に満足していただけるシステムを構築するのは難しいと思います。そこで、要求開発を行い、ビジネスモデリングによって要求を明確に見えるようにすることで、システム開発を成功に導くことができると期待されているのだと思いました。


記事の内容を5点満点で評価してください。
1点 2点 3点 4点 5点
記事に関するコメントがあれば併せてご記入ください。

© 2005 OGIS-RI Co., Ltd.
HOME HOME TOP オブジェクトの広場 TOP