明日から新プロジェクト！

　明日から新しいプロジェクトが始まります。今回は、ある業務のシステム要件定義を進
めつつ、全社的な情報アーキテクチャーを整理しようとするものです。私と外部のエンジ
ニア2名によって、まずは7月中に最初の成果を出すことを目標としています。
　この業務を行うにあたって、私はユースケース駆動とドメイン駆動の両面からアプロー
チするという手法を考えました。
　私は主に問題領域の「もの」に着目し、ドメインモデリングを中心に分析を進めます。
外部のエンジニア2名は、主に問題領域の「こと」に着目して業務モデリングやユースケ
ースの抽出を中心に分析を進めます。そして、「もの」から発見されたビジネスエンティ
ティやトリガーなどと、「こと」から発見された情報やユースケースなどの整合性をチェ
ックすることで、新しい業務を正しく設計し、システム要件定義の網羅性を担保しようと
するものです。
　もちろん、要件定義の基本となる方法論はRDRAに準じて行います。さて、どうなるでし
ょうね？　明日からが楽しみです。

次期プロジェクトの要件定義手法

今度のプロジェクトでは、ひとつの問題領域を2チームで要件定義する予定。そして、チーム毎の作業を対照的に行うことで、成果の品質を高めるという目論見。

下図はサンプルです。


次期プロジェクトの要件定義手法 posted by (C)Satohru

要件定義手法のRDRA、ユースケース駆動開発手法のICONIXプロセスを組み合わせて、UMLをツールとして使用します。
モデリングツールはEnterprise Architect。9.0が間に合うといいけど…
ちなみに、上図はEnterprise Architect 9.0のベータ版で「手書き風」にしてみました。

性質変換によるデスクワークの工場化(1)

　私の勤める会社は主に不動産賃貸業を営んでいますが、ある人にいわせると、「江戸時代からビジネスモデルが変わっていない業態」ということだそうです。この真意はともかくとして、そんな会社で情報システムを任されている私には、この業態が故の「当たり前のムダ」というものがたくさんあります。
 　例えば「鍵」。賃貸住宅のドアのキーです。お客様との契約前には内覧をしていただきますが、その為にはたくさんの鍵を管理し、社員がお客様に同行し、中を開けて説明し、他の部屋が見たいと言えば、では後日、と言って再び同じことを繰り返します。あるいは、契約書であるとか、預金口座自動振替依頼書であるとか、さまざまな「紙」が発生し、これをお客様との間でやり取りする過程で、封入コストや郵送コスト、管理・保管コストが発生します。
　このような例が、私がいうところの「当たり前のムダ」です。言い方を変えると、他の業態と比べると相対的にムダに見えるものということになります。例えば、ネット証券会社を考えてみてください。ほとんどのオペレーションが電子的に済み、さまざまなリソースを多くの顧客でシュアしている業態は、うらやましいほど効率的です。しかし、「当たり前のムダ」がある中でも、より効率的なオペレーションは築いていけるはずです。
　私は何とか「工場化」できないか？　と考えています。「IT化」ではなく「工場化」です。つまり、事務作業やデスクワークといわれる業務を、製造作業のような「性質」に変換できないか？　ということです。
　では、「製造作業」と「デスクワーク」の違いは何でしょうか？　これを考える前に、ビジネス（あるいは、仕事、業務、作業）の構造を考えてみましょう。

　上記の図を一旦ビジネスの構造とし、ビジネスルールと呼ぶことにしましょう。

1. トリガー（業務の引き金）　：　どんな業務でも、必ず開始されるきっかけがあります。それには「アイデアがひらめいた」とか、「仕事の依頼がきた」、「上司に指示された」、「期日がきた」などさまざまでしょう。
2. ロール（業務の実施者と役割）　：　業務は人によって行われます。誰が、どんな役割で業務を行うのか？　これがロールです。IT化された業務では、システムがロールとなることもあるでしょう（ロールがシステムだったとしても、その処理内容は人が管理していますので、最終的にはすべての業務が人によって行われているということになります）。
3. インプット（業務に必要なもの）　：　業務には何らかのインプットがあります。伝票や請求書、要件などです。また、業務の実施者の知識や経験、アイデアのような無形のものもあります。
4. プロセス（業務の手順）　：　何を、どう処理していくかという業務の手順がプロセスです。「請求書の内容を確認し、支払管理システムから支払依頼書を発行し、経理に提出する」というようなものです。
5. コントロール（業務の制御）　：　取り敢えず「制御」という日本語を充てていますが、管理、監督、統制など、Controlのいくつかの和訳に置き換えてもいいでしょう。プロセスには何らかのコントロールがあります。「上司の承認を受ける」とか「支払額は予算の範囲内」とか、「条件分岐」であったりします。
6. アウトプット（業務の成果）　：　プロセスによって生み出された成果となるものがアウトプットです。インプットと同様、アイデアなどの無形のものもあるでしょう。

 　ビジネスルールは、下図のように次のビジネスルールへと引き継がれるケースがあります。また、下図「ビジネスルール A」と「ビジネスルール B」をひとつのビジネスルールに集約することも可能ですから、ビジネスルールはネスト構造になっていると捉えられます。つまり、「粒度」があるということです。

　ビジネスルールを一定の定義に基づき理解した上で、製造作業とデスクワークとの違いを考えてみましょう。

　製造作業は、明確な役割分担のもと、品質レベルが明確な成果物を、定まられた手順に従って行い、かつ、生産量や技術レベルを物理的・定量的に捉えることができ、作業全般を通じて可視化されています。
　これに対しデスクワークの一部は、不明確な役割分担のもと、品質レベルが不明確な成果物を、試行錯誤の連続によって行い、かつ、成果物や業務遂行レベルを定性的に捉えることが多く、作業全般を通じて見えにくくなっています。
　上表のように、{ T,R,I,P,C,O }で比較してみましょう。

1. ロール　：　デスクワークでは責任と権限のバランスがとれていないケースがあります（責任だけは押しつけられるが、それを遂行するだけの権限がないなど）。
2. インプットとプロセス　：　例えば新規事業を企画する、というような業務を行う時、インプットやプロセスは試行錯誤の連続によって行われます。「市場調査をやってみたけれど有用な情報を得られなかったから、競合他社の分析をしてみよう」というようなケースです。そうした試行錯誤の連続は、スピードや効率の低下要因となります。
3. アウトプット　：　最も大きな違いがアウトプットです。製造作業のアウトプットには明確な品質レベルが測定可能な形で定義され、よって検証することができます。しかし、デスクワークのアウトプットの大部分はこの逆です。例えるなら、製造作業はX,Yの座標で弓を射る目標を定義しているのでズレを定量評価できますが、デスクワークは的のどこかに当たればいいというような曖昧な定義なので、定性的な評価しかできません。

　このようなデスクワークの各要素を製造作業の持つ性質に近づけることができれば、デスクワークの「工場化」を推進することが可能です。

　性質変換によるデスクワークの工場化、理屈はこれでいいのかもしれませんが、では実践ではどのようなアプローチをすればいいのでしょうか？　これから具体的に検証していきたいと思います。

第2回 クラウドコンピューティングEXPO

　昨日、幕張メッセで開催された第2回 クラウドコンピューティングEXPOに行って来ました。出展製品の中から、私が興味を持ったものを紹介します。

■ BPMワークフローシステム『Questetra BPM Suite SaaS Edition』
　株式会社クエステトラ

　私はホワイトカラーのデスクワークを「工場化」することによってより高付加価値な業務にパワーシフトできないか？　という理想を持っていますが、その為には業務の可視化が重要な一歩となります。
　Questetra BPM Suiteは、恐らくエンドユーザーレベルでも定義可能な「プロセスモデラー」とアクティビティに対する「入力画面」を作成し、「業務実績グラフ」などで進捗や結果を可視化し、PDCA基盤を構築できます。しかも、5ユーザー、100MBまで無償で使用することができますので、早速試してみたいと思います。


■ 『VR-Studio』等
　株式会社フォーラムエイト

　大規模な3次元空間CGを製作する為のソフトウェア製品です。


■『ホワイトワークスタイル』
　ソフトバンクテレコム株式会社

　ホワイトカラーの生産性向上、ワークライフバランス、メンタルヘルス、事業継続性の観点から、このようなワークスタイルは今後普及が進むかもしれません。
　今後、継続的に研究すべきテーマだと感じています。

工場見学を終えてのちょっとした感想

　先日、ある精密機器メーカーの工場見学に行って来ましたので、ちょっとした感想をメモします。

　製造の仕事は、成果が明確であり、その出来不出来が定量的に測定でき、個々人の作業が定型化されていて、かつ、その作業の進捗を誰もが目視で確認することができます。

　一方、いわゆるホワイトカラーが行う事務作業は、成果が不明確なことが多く、その出来不出来が定性的に判断されることが多く、個々人の作業が非定型で、かつ、その作業の進捗が見た目では分かりにくいという性質を持っています。

　つまり、ホワイトカラーの生産性を上げるために、作業を可視化が極めて重要であることを再認識しました。また、成果を明確にするためにも、目的、目標を作業前に定義することが重要です。

サイボウズを使って業務の見える化(2)

　サイボウズを使って業務の見える化（試行）の続編です。今回は実際のデータを使って簡単な分析を行ってみます。

　サイボウズのスケジュールには、前回の例（下図）のように入力しますが、今回は業務、会議となっている予定項目を、業務（定型）、業務（非定型）、会議、外出の4項目で入力しました。
　
　例）4/1 10:00-11:00　業務（定型） 業務報告書の作成



　このように入力した実績データを2月24日～3月11日までエクスポートし、Excelを使って分析してみます。

　Excelに読み込んだデータをピボットテーブルにし、条件付き書式を使って数値を読み取りやすくしました。

　これを見ると、部下の定型業務がタスクの数（データの個数 / 予定詳細）、所要時間共に一番多いことが分かります。これは、細かな定型業務をいくつも行っていることを表しています（1タスクあたり平均約2時間で38タスク）。

　一方、非定型業務の割合はSatohruの方が多く、部下との役割やスキルの違い等が表れています。

　そこで、タスク数をレーダーチャートにしてみました。

　Satohruの定型業務を部下にシフトできれば、非定型な業務にパワーシフトできます。また、部下がスキルを高めて非定型業務の幅が拡がれば、2人で負荷分散をしやすくなります。

　次に、会議の中身を見てみます。

　タスク（先頭2文字のみ表示）別に所要時間を表示していますが、パッと分かることは、Satohruは会議の機会が多いということです。ムダな会議をしている認識はありませんが、タスクを切り替えるにはコストがかかりますから、いかに会議を少なくするか？　というのが課題として浮かび上がってきます。

　以上、簡単ですが前回の続編でした。

　いずれまた、続きをレポートできればと思います。

サイボウズを使って業務の見える化（試行）

　業務の可視化、特に一人ひとりが行った仕事の実績を捉えるというのは、理屈は簡単ですが、実践や運用が難しいです。
　日報や週報などの業務報告書は、いざ組織的に定義しようとすると項目が多くなり、項目を埋めるだけでもひと苦労です。また、最初はみな真面目に取り組んだとしても、書く方も見る側も、次第に形骸化し消えていく、こんなところではないでしょうか？
　ITで何とかならないか？　と要件を定義し始めると、セキュリティを始めとする非機能要件に煩わされる。そして、情報システム部門の仕事が確実に増えることになりますし、コストもかかります。

　何とか手軽に、あるものを利用して、コストをかけずに、持続可能な業務実績の見える化ができないかなぁ…　と昨日から考えていました。

　我が社には、サウボウズというグループウェアが導入されています。そして、これにはスケジュール管理機能と、そのデータをCSVファイルとしてエクスポートする機能があります。これを利用できないか？　ということで今日は朝から機能の確認をしていました。

　今日から試行運用をシステム部門限定で始めたところですが、大体こんな感じになります。

　このように主要な業務とその時間帯を実績として入力します。これをエクスポートすると、下記のようなCSVファイルが取得できます。

"イベントID","開始日付","開始時刻","終了日付","終了時刻","予定","予定詳細","メモ","参加者","設備"
"710883","2010/3/29","8:30:00","2010/3/29","10:00:00","業務","Xシステム要件開発","","Satohru",""
"710891","2010/3/29","10:00:00","2010/3/29","12:00:00","会議","次期ITインフラについて","","Satohru",""
"710895","2010/3/29","13:00:00","2010/3/29","14:00:00","業務","稟議書の作成","","Satohru",""
"710899","2010/3/29","14:00:00","2010/3/29","16:00:00","業務","社屋LAN工事仕様書作成","","Satohru",""
"710903","2010/3/29","16:00:00","2010/3/29","17:00:00","業務","Xシステム要件開発","","Satohru",""

　これをExcelでちょっと加工し（水色の項目を追加）、

　ピボットテーブルで可視化します。

　いかがでしょう？　これなら安くて簡単です。

　実データを使ってピボットテーブルを操作すれば、おもしろい分析ができるかもしれません。

続きはこちら