« 2013年7月 | トップページ | 2013年9月 »

2013年8月

2013/08/25

チケット駆動開発がWF型開発と相性が悪い理由

SIの現場で使えるチケット駆動開発|セミナー|Growth xPartners Corporate Site」セミナーをUStreamで聞いて、思ったことをメモ書き。

【元ネタ】
2013/08/24(土)「SIの現場で使えるチケット駆動開発」セミナー #gxptech - Togetter

【1】Excelによるプロジェクト管理は、計画作成時はまだしも、その後の実績管理の運用では、利点よりもたくさんの弊害の方が出てくると思う。

Twitter / akipii: #gxptech Excelの最大の弱点はコミュニケーションが閉じてしまうことかな。更新する人しか最新情報を知らない。メールにExcelを添付されても、その履歴を追跡するは面倒。Excel駆動とメール駆動の開発は表裏一体だと思う。

しかし、最近はRedmineを導入したものの、思ったような効果が出ていない事例をよく聞く。
話を聞くと、Redmineによるチケット駆動開発をそのままWF型開発を当てはめようとして、うまくいっていないという事例が多い。

Twitter / akipii: #gxptech @yusuke_arclamp はい、最近はRedmineを導入してもその効果を余り感じない事例をよく聞きます。開発業務の管理が混乱してる現場には即効果がありますが、管理業務が既にある所では、別の問題があり、ツールだけではない運用ルールが必要と思います。

Twitter / Sean_SF: 「BTSをプロジェクト管理に使えるのか?」という話題は盛り上がる。ウォーターフォール型が多い日本のプロジェクトにおいて、BTS、チケット駆動開発をどう取り入れていくのか。取り入れたいんだけどうまくいっていないと悩んでいるリーダーが多いんだろうなぁ #gxptech

【2】Redmineのガントチャートでタスク管理しようとする場合、MSProjectと異なる点は、チケットの粒度が異なる点と予実管理ができない点があげられる。

顧客やプロマネの観点と開発者の観点でチケットの粒度が異なる理由は、以下に既に書いた。

チケット駆動開発は進捗報告作りをどのように解決しようとするか?: プログラマの思索

予実管理がRedmineではやりにくい理由は、Redmineチケットに、予定の開始・終了日と実績の開始・終了日が区別されておらず、実績管理しかできないように機能実装されているからだ。
つまり、Redmineでは、本来チケット管理で予実管理を厳密に運営することは想定されていない設計思想で作られている。
だから、WF型開発でチケット駆動開発をやろうとすると、予定に合わせるようにタスクを調整するマネジメント手法が正直使いづらい。

Twitter / digitalsoul0124: "BTSについているガントチャートは何なんだ ガントチャートはタスクの前後関係が見える。それに対して、チケットで管理するのは総量" #gxptech

Twitter / akipii: #gxptech Redmineにガントチャートを欲しがるPMは予実管理がやりたいが、チケットは実績管理しかできない設計思想になっている。予定管理をチケットでやろうとするとカスタマイズが必要になる。その食い違いがチケット駆動でWF型開発をやろうとして失敗しがちなのだと思います。

WF型開発は、当初の計画で決められた予定をベースラインとして、実績として発生したタスクを合わせようとして、変化を抑えこむやり方。
計画で作成された予定作業がコロコロ変わると、ベースラインとして意味がなくなってしまう。
予実管理によって、予定よりも遅れたタスクに注目して是正対策を取る。

チケット駆動開発では、ロードマップのビューを主に使って、決められた期限までにどれだけのタスクを実現するか、という観点で、スコープ管理する発想。
タイムボックスという箱に、状況に合わせてチケットを詰め込むやり方。
だから、チケットという作業スコープに着目して、チケット管理していく。

Twitter / akipii:#gxptech ガントチャートを使って予実管理する手法では、予定した計画にいかに実績を合わせて、変化を抑えこむのを目的とする。チケット駆動はアジャイル開発と同じ設計思想で、スコープ管理の観点で計画偏差という変化を制御しようとする。やり方は全く違うと思います。

チケット駆動開発では、チケットに予定日を入れたとしても、ロードマップに当てはまるように随時調整するため、予定日は意味をなさない。
つまり、チケット駆動開発はアジャイル開発と同様に、計画と実績の偏差(ばらつき)に着目して、タイムボックスに入るようにタスクを調整する。

つまり、プロジェクト管理におけるWF型開発のやり方とチケット駆動開発のやり方は全く発想が違う。
他にもWF型開発に囚われすぎたアンチパターンについては以前まとめた。

WF型開発にとらわれすぎたTiDDのアンチパターン #tidd: プログラマの思索

【公開】RedmineのFAQとアンチパターン集 #Rxtstudy: プログラマの思索

このようなアンチパターンが発生する原因は、BTSから生まれたチケット駆動開発が当初の利用範囲から外れた箇所に適用されたためだろうと思っている。

【2】では、WF型開発にチケット駆動開発を適用するには、どんな手法が必要か?

チケットで予実管理をやりたいならば、チケットに予定・実績の開始・終了日を設けるようなカスタマイズが必要だろう。
また、進捗管理が一目でわかるような、ロードマップとは違う別のビューが必要だろう。
多分、ガントチャートをもっとカスタマイズする必要があるだろう。

あるいは、CCPMのような発想を取り入れるといいかもしれない。
つまり、計画作成時に予定されたチケットを作るが、チケットに実績情報を入力する時に、残工数がひと目で分かるようにして、プロジェクト全体の残工数で進捗管理する手法を取ること。

Twitter / sakaba37: CCPM的ですね。RT @pato_taityo: … @yusuke_arclamp さん…計画に対する遅れがすぐわかるようにあえてギリギリのスケジュールを設定する。遅れが出たらその遅れの種類を見極める。そしてその種類に応じて残しておいたバッファで対応する。 #gxptech

個人的には、純粋なWF型開発をそのままチケット駆動開発に適用した場合、カスタマイズすれば運用できるだろうが、チケット駆動開発の利点が消えてしまうため、恩恵がなくなるのではないかと思っている。

WF型開発へのチケット駆動開発の適用方法については、@sakaba37さんが「アダプタブルウォーターフォール」という概念で説明されているので、そちらを御覧ください。

【3】では、Redmineによるチケット管理は万能なのか?

@yusuke_arclamp さんや@digitalsoul0124さんも話されていたが、担当者が決まらないチケットは、チケットとして起票してもあまり意味を成さない。
例えば、WBS作成時は、詳細なタスクが分からない項目もまずは空き箱として配置できるが、チケットに起票したとしても、そのチケットからどのように作業していけばよいか分からないから、放置されやすい。

Twitter / akipii: #gxptech WBSでは曖昧な課題やタスクを空箱として配置できるが、チケットは曖昧なタスクを登録しても運用しにくい。@yusuke_arclamp さん談。

Twitter / akipii: #gxptech チケットはソフトウェアの改修に関する情報が集まって更新されて流れるもの。(和智さん談) チケットは「型はあって形はない」方が良いのでは。チケット駆動は期限までに担当者がチケットを完了させる仕組みではなく、活性化させるもの。(鈴木さん談)

また、「チケット管理は予実管理しにくい」という特徴から、チケット管理のモデルを考えると、チケットはマスタではなくトランザクションである。
つまり、チケットは、予定というマスタ情報を蓄積するのではなく、実績としてトランザクションを日々記録していく方が向いている。
だから、チケットを元帳のように扱うことには向いていない。
むしろ、GTDのように、次々に発生するタスクをどんどん消化していくやり方の方がチケット管理に向いている。

最近、Redmineによるチケット管理をヘルプデスク管理や顧客管理、資産管理に使う発想が試されている。
日々のトランザクションを管理する点はチケット管理は最強だが、顧客マスタやPC資産マスタというマスタ情報(元帳)はチケットではなく、別のマスタを用意する方が扱いやすい。

つまり、チケット管理がうまく当てはまる業務であるか否かという判断条件は、チケット管理のモデルの特徴に大きく依存していると考えている。
この辺りは今後まとめてみたい。

【追記】
@yusuke_arclampさんや@sakaba37さんも、チケット駆動による進捗管理についてBlogを書かれている。

ITS/BTSは進捗管理に使えるのか - SIの現場で使えるチケット駆動開発 - arclamp

[#TiDD] チケット駆動開発をプロジェクト管理の視点だけで考えてはいけない #gxptech: ソフトウェアさかば

| | コメント (0)

2013/08/24

PC資産管理で必要な機能~Redmineとフィットギャップ分析する

PCやソフトウェア、サーバーなどのハードウェア資産管理について、調べた内容をメモ書き。

【参考】
ソフトウェア資産管理

BSA P-SAMポータル|石川県庁の事例

時代は「PC資産管理」から「IT統合資産管理」へ - @IT情報マネジメント

勉強会リポート:クラウド時代のIT資産管理(2):なぜ、PC資産管理は失敗するのか? (1/2) - ITmedia エンタープライズ

勉強会リポート:クラウド時代のIT資産管理(2):なぜ、PC資産管理は失敗するのか? (2/2) - ITmedia エンタープライズ

特集:自社の命運を左右するIT資産管理(2):IT資産管理ツール、失敗しない選択基準 (1/2) - ITmedia エンタープライズ

特集:自社の命運を左右するIT資産管理(2):IT資産管理ツール、失敗しない選択基準 (2/2) - ITmedia エンタープライズ

SARMSユーザ会 ≫ マニュアル

IT資産管理システムi-doIT: プログラマの思索

【1】PC資産管理の背景と問題点

PCが業務で必要不可欠となった今、内部統制やISMSという観点で、PCやサーバーの資産管理が重要になってきている。
例えば、個人情報や顧客情報の流出、ウイルスによるPC汚染、著作権を無視したソフトウェアライセンスの不正利用、セキュリティパッチが当てられていないサーバーへのDoS攻撃など、下手をすれば会社は社会的信用をなくしてしまう。

情報セキュリティマネジメントシステム(ISMS)とは

そのために、PCやハードウェア、ソフトウェアの資産管理がどの会社でも必須になってきている。
だが、その資産管理はとてつもなく大変なのが実態だろう。

会社で保持しているPC・SW・サーバーをそもそもどれくらい保持しているのか、という内容をまとめるだけでも大変。
現代ではPCやサーバーは消耗品であり、3年も経てば陳腐化してしまい、買い替えが必要。
ハードが変われば、OSもソフトも変わってしまう。
OSやミドルウェアがバージョンアップすれば、それに付随するソフトウェアも一括更新が必要。
情報を収集した時点は最新の情報だが、1ヶ月も経てば、その情報は古くなる。

ハードウェアの資産情報の収集も大変だが、ソフトウェアライセンスの情報収集はもっと大変だ。
特に、WindowsOSやWindowsサーバーはセキュリティパッチがどの状態まで当たっていて、何が不足しているのか、を把握する必要がある。
そうでなければ、IEやWindowsサーバーのセキュリティホールを狙われてしまい、業務の障害や顧客情報の流出などの危険が出てくる。

ソフトウェアライセンスの不正利用がないかをチェックすることも重要だ。
MSOffice製品はもちろん、他のソフトウェアでもライセンス数が足りないのに、水増しして使っていないか。
ソフトウェアライセンスの管理で重要なのは、倉庫に保管されて未使用なPCにあるソフトウェアライセンスの棚卸しだろう。
使われていないソフトウェアライセンスは回収して、別の人に割り当てるなどして、できるだけ有効利用するようにしたいものだ。
だから、PCなどのハードウェア情報だけでなく、ソフトウェアライセンスの情報も定期的に収集する機能が欲しくなる。

また、派遣要員が社内の大半を占める場合、資産ではなくリースの概念も必要になってくる。
全てのPCが資産とは限らない。
特に、会計の観点では、PCやサーバーは資産として計上し、年度ごとに減価償却していくために、年度末には台数をきちんと棚卸し(インベントリ)して確定しておかねばならない。
つまり、PC資産管理では、最終的には会計システムへの連動機能も考慮する必要はある。

【2】資産管理の基本的な機能

資産管理の基本的な機能は3つあると思う。

(1)構成管理データベース(CMDB)の構築による台帳機能

ITサービス管理のガイドラインであるITILでは、構成管理データベース(CMDB)で、PCなどの資産情報を一括管理する。
CMDBに資産情報というマスタが一元管理されていれば、常に最新の情報が取得できるし、いくらでも欲しい情報を集計して出力もできる。

CMDBには、あるべきPCやハードウェアの状態の情報であるToBeと、インベントリ機能で現在の資産情報を収集した状態の情報であるAsIsが明確に区別されて保持する必要がある。
ToBeの情報が、あるべきIT資産台帳に相当する。
資産台帳には、ハードウェア、ソフトウェア、ライセンスの情報が全て入っている。

また、資産台帳とは別に、ソフトウェア辞書もあるとありがたいだろう。
例えば、ソフトウェア辞書を使えば、一つのPCやサーバーに必要なソフトウェア情報をテンプレートとしてまとめておけば、他のPCにも流用できる。

ISMSのセキュリティポリシーを元に、現在の資産の状態が是正すべき状況であるか判断するためには、ToBeの情報とAsIsの情報は明確に区別すべき。

(2)資産情報を自動収集するインベントリ機能

全社規模でPCやサーバーの資産情報を定期的に、社員にアナウンスして情報収集して管理するのは、派遣社員を含む社員数が増えるほど煩雑になる。
自己申告制のため、報告された情報の正確性も内部統制上、問題になるかもしれない。

だから、PCやサーバーの資産情報をツールで自動収集するツールが必須になってくる。
この機能はインベントリ機能と言われるらしい。
つまり、インベントリ=資産の棚卸しだ。

インベントリ機能で、PCやサーバーのスペック情報だけでなく、OS・ソフトウェアのバージョンやパッチの状態、ライセンス情報まで取得できるとありがたい。
そのレベルまで実現できれば、セキュリティポリシーやライセンスポリシーによる判定がかなり楽になる。

実現方法としては、サーバー上でCMDBに資産情報(AsIs)を記録する機能があり、クライアントには別途インストールしたアプリで資産情報を収集してサーバーへ送付する機能の2つが必須。

(3)ワークフロー管理と資産管理の連携

PCやサーバーを新規購入する場合、普通は、上司に申請して承認されて、購入され、OSやソフトをインストールして構築して、データセンターや社内に移動されて、初めて使えるようになる。
すると、資産のライフサイクルに合わせたワークフロー管理機能が資産情報を連携できると運用しやすくなる。
承認フローがワークフロー管理として実装されていれば、証跡として記録することで、内部統制の運用もやりやすくなる。

【3】運用のコツ

PC資産管理は、情報システム部門や管理部門が担当しているだろうが、その業務は結構面倒だ。
そして、管理業務ゆえに細かい所まで頑張るほど、売上に直接関わらないし、単に管理コストが増すだけだ。
だから、できるだけツールを使って、少人数で運用できる方が望ましいだろう。

実際の運用は、ツールと一体化した業務フローを手順としてまとめる必要があるだろう。
PC・サーバーの購入は購買調達部門、PC構築は情報システム部門、実際の使用は各部門のように、ハードウェアの状態によって、担当者が変わる。
従って、資産のワークフロー管理は必須機能だろう。

特に、インベントリ機能は、各担当者のPCやサーバーにアクセスするために、頻度が多いと、彼らの業務に支障が出る。
それ故に、インベントリ機能の頻度や調査範囲をバランスさせる必要があるだろう。

そして、資産管理から会計システムへの連動も考慮が必要。
例えば、購入したハードウェアやソフトウェアは資産として計上され、年度ごとに減価償却されるから、台数やライセンス数を常に厳密に把握しておかないと、会計監査でNGを食らう時がある。
普通は、ハードウェアは有形資産、ソフトウェアは無形資産で計上される場合が多いだろう。
そして、PCが除却されれば、PCの資産はゼロとなり、廃棄費用が計上される。

会計上面倒なのは、リースないしレンタルされているPCやサーバー。
リース故に負債として計上される場合もあるから。

つまり、会計部門と年1回は資産管理の情報を連携する必要があるだろう。

【4】Redmineを適用できる範囲と限界

Redmineのチケット管理をPC・サーバーの資産管理に使う事例は、既にあるようだ。
適用方法や運用方法について、下記で既にまとめた。

RedmineはPC・サーバ資産管理に適用できるか?: プログラマの思索

Redmineのチケットとハードウェア資産を1対1に対応づけることで、チケットに最新の資産情報が表示されるし、その後の変更履歴も記録される。
チケットのカスタムフィールドにIPアドレスや設置場所を追加しておけば、クエリで欲しい情報を簡単に出力できる。

また、PCの状態(購入前、構築中、使用中、廃棄、倉庫に保管中)をチケットのステータスに対応づけることで、定期チェック時にどの資産を的に絞ればよいか、分かりやすくなる。
そして、Redmineの優れたワークフロー機能によって、申請や承認フローも運用可能だ。

しかし、Redmine単独では実現できない機能もある。
上記の資産管理の機能をフィットギャップ分析してみよう。

(1)構成管理データベース(CMDB)の構築による台帳機能

チケットには、登録された資産の最新の情報を記録するだけ。
つまり、AsIsの情報は記録できるが、ToBeの情報を保持する機能は別の実現方法が必要。

また、カスタムフィールドで資産情報を追加していくと、かなりの数のカスタムフィールドが必要になってくる。
例えば、インストールされるソフトウェアとそのライセンスやバージョンの数は数百以上に上るだろう。
すると、チケットの属性が多くなるほど、チケット更新の手間がかかる。
つまり、ソフトウェア辞書のような機能が、チケットのデフォルト機能に存在しないのが弱点の一つ。

(2)資産情報を自動収集するインベントリ機能

Redmineにはもちろん存在しない。
現状は、各担当者にメールで通知して、自己申告で資産情報をチケット更新する運用になる。
すると、自己申告された情報をチェックする運用フローも別途必要となるから、何らかの業務マニュアルやチェックリストが必要になってくる。

(3)ワークフロー管理と資産管理の連携

Redmineのワークフロー機能で実現可能。
但し、もちろん、会計システムと連動する機能はない。
会計システムと連動したい場合、月次・年次のバッチ処理で資産状態を一括集計する機能を実装する必要があるだろう。

以上を比較すると、Redmineでは手運用でカバーする業務が多い。
だから、現状の業務の問題点に対し、Redmineで解決できる業務はどれか、そして、解決できない問題点は手運用でどのようのカバーするか、をあらかじめ事前に分析しておく必要があるだろう。

つまり、我々SIの受託開発の要件定義で、顧客の問題点を洗い出し、開発するシステムが何をどこまで解決するのか、というITソリューション事業の作業内容と何ら変わりない。

【5】オープンソースの資産管理ツールの機能

オープンソースの資産管理ツールはいくつかある。
日本製では、SARMSユーザ会 ≫ マニュアルがあるらしい。

ドイツ語製品だが、i-doITはデモ画面でその機能を確認することができる。
画面をキャプチャしておく。

ちなみに、i-doITは、(1)構成管理データベース(CMDB)の構築による台帳機能、(3)ワークフロー管理と資産管理の連携は実装されているが、(2)資産情報を自動収集するインベントリ機能はないようだ。

IT資産管理システムi-doIT: プログラマの思索

I_doit_cmdb_server_location

I_doit_cmdb_server_infra


I_doit_cmdb_layer_3_net

I_doit_cmdb_persons_contact

I_doit_cmdb_workflow

I_doit_logbook

I_doit_cmdb_licenses_i_doit_report_

| | コメント (0)

2013/08/21

リーンスタートアップはマーケット開発だ

実践リーンスタートアップ」を読んでみて、ビジネススキルとプログラミングスキルの立場が逆転したのだ、という感想を持った。
ラフなメモ書き。

Twitter / akipii: 「 実践リーンスタートアップ」を読むとアジャイル開発の影響を受けた起業の手法だとよく分かる。「生産手段の所有」ではなく「生産手段の借用」のおかげで、問題は「構築できるか」ではなく「構築すべきか」に変わった! http://www.amazon.co.jp/dp/4873115914

Twitter / akipii: リーンスタートアップの根底にある時代背景。ビジネスの分かる人がコードを習う事とコードを既に書ける人がビジネスを学ぶ事のどちらが現代では簡単か?それは後者。現代は、最先端のコンピュータ科学を近い過去に大学で学んだエンジニアの方がIT起業に向いている。FacebookCEOのように。

Twitter / akipii: 料理は別の国でアレンジされると世界に広まりやすいという経験則。中国発祥の麺類は日本でラーメン、イタリアでパスタとなり広まった。リーンスタートアップも、日本発祥のトヨタのリーン生産方式が米国でソフトウェア開発とビジネス起業でアレンジされて広まった。BTS発祥のチケット駆動も同様。.

【1】「実践リーンスタートアップ」を読んでみて分かったのは、リーンスタートアップはマーケット開発だ。
つまり、リーンスタートアップは単なるITベンチャーの起業方法だけではなく、新しいマーケットにいる潜在顧客を発掘し、ビジネスモデルを作る手法と言える。

例えば、iPod/iPhone/iPadを生み出したApple、検索エンジンからGMailやGoogleAppEngineを生み出したGoogle、レコメンドエンジンやAWSを生み出したAmazonがまさに当てはまる。
実際、iPod/iPhone/iPadという革新的な製品は、投入した後、アーリーアダプターが注目して、その後一般の人達まで一気に普及した。
その間、ハードウェアもソフトウェアもチューニングして改善しながら、より良い製品になった。

実践リーンスタートアップ」の基本モデルは、Learn→Build→Measureの運用ループだ。
このサイクルを早く回すことで、製品をチューニングして、機能や品質をどんどん改善していく。

この時、MVP(機能最小限の製品)をまず作り、いち早くマーケットに投入して、アーリーアダプターを見つけるのが大事。
アジャイル開発のように、製品を使ってくれて、障害報告だけでなく機能改善の要望をあげてくれる熱心なユーザを作るのが大切。
そうすれば、熱心なユーザのフィードバックを活かすことで、製品の方向性や完成度をいち早く見極めることができる。

そして、当初の計画を変更して、MVPの状態の製品を違う方向へ作り直す時、ピボットする。
最初の計画を守りすぎて、マーケットの動向や時代の趨勢に乗り遅れないように、計画は柔軟に変えていく。
ピボットという言葉が意味することは、バスケットボールのピボットのように、最初の計画を踏まえて方向転換することだ。

製品計画を作るには、リーンキャンパスを使う。
リーンキャンパスはビジネスモデルキャンパスに似たフレームワークであり、課題解決にフォーカスしているのが特徴。
リーンキャンパスで重要な項目はUVP(独自の価値提案)だ。
どんな価値を提供するのか、によって、どんな顧客にリーチするのか、どの課題に対してソリューションを提供するのか、が分かってくる。
プログラマはどうしてもソリューションに注目しがちだが、課題や価値、顧客も意識すべき。

実践リーンスタートアップ」には他にも、かんばんを使ったタスク管理、顧客インタビュー、製品インタビューなどの手法も書かれていて、とても実践的。

【2】「実践リーンスタートアップ」を読むと、「アジャイルプロジェクトマネジメント」をブラッシュアップしたような内容のように思えた。
アジャイルプロジェクトマネジメント」は革新的な製品を作るためにアジャイル開発のアイデアを適用した内容が書かれているが、その内容を新しい概念で表現し直したのが「実践リーンスタートアップ」のように思える。

リーンという言葉が流行しているのにその意味を僕はよく理解していなかったが、無駄の排除だけではなく、新しいマーケットを開拓する「顧客開発」や革新的な製品を生み出すための「製品開発」の視点がある。

【3】「実践リーンスタートアップ」のまえがきと解説がとても印象的。

なぜ現代は起業しやすくなったのか。
それは、「生産手段の所有」による制約がどんどんなくなって、「生産手段は借用」すればよい環境になってきたから。
実際、Webサービスを作りたいならば、プログラミングスキルさえあれば、クラウドの環境を使えば、そんなに難しいことではない。
クレジットカードさえあれば、ITベンチャーに必要なものは借りることができる。

すると重要な問題は、「構築できるか?」ではなく「構築すべきか?」に変わる。
つまり、Webサービスをどんな言語でどんなアーキテクチャで作るべきか、という実現可能性調査よりも、作ったWebサービスをどんなマーケットへ提供してビジネスを展開したら良いのか?という問題に変わったということ。
そのために、実験が必要になる。
だから、Learn→Build→Measureの運用サイクルが生まれた。

【4】「実践リーンスタートアップ」はビジネスに興味のないプログラマにこそ読んで欲しい本、と解説に書かれている。
現代のアメリカでは、コードが書けるビジネス起業家が大人気らしい。
リーンスタートアップの基本手法は、「機能を小出しにリリースして、顧客の反応を見ながらどんどん改善していく」ことだから、この手法を最大限に活かすには、自らコードが書ける人でないとその速さについていけない。
でも、やはりビジネスの理解がないとビジネスの起業は難しい。

だから、ITスキルとビジネススキルの両方が必要。
でも、ビジネスが分かる人がコードを学ぶのと、コードが書ける人がビジネスを学ぶのはどちらがより簡単か。
現代では、後者だ。
既にコードが書ける人がビジネスを理解すれば、一人でも起業できる。

しかし、2000年代前半までは、そうではなかった。
ソフトウェア製品やWebサービスを開発するには、たくさんの人と高価なサーバーが必要だった。
サーバーも自分たちで運用しなければならなかった。
だから、GoogleがシュミットCEOを呼んだように、ある程度まで成長したら、口が立つ経営者を呼ぶのが必要と思われていた。

でも今は違う。
FacebookCEOのザッカーバーグや、その他のWebサービスの起業家のように、20代でITベンチャーを起業しても懸念する人はいない。
むしろ、最先端のコンピュータ科学を過去直近に学んだ生粋のエンジニアの方に好感が持たれる時代なのだ。

「ビジネスが主体でプログラミングスキルはサブとして付加」だった頃から、現代は「プログラミングスキルが主体で、ビジネスはそれに付加」という逆転の発想。
リーンスタートアップが流行している背景にはそんな時代背景がある。

「リーンスタートアップ」が流行している理由はもう一つあるという。
それは「料理と同じように、別の国でアレンジされると世界に広まりやすい」という経験則に当てはまっているから。
例えば、麺類は中国発祥で、日本にわたってラーメンやうどん、イタリアに渡ってパスタを生み出して世界に広まった。
ピザはイタリア発アメリカ経由で世界へ。

リーンスタートアップも同様に、日本のトヨタのリーン生産方式のアイデアが、アメリカでソフトウェア製品開発に適用されて、無駄を排したITベンチャーの起業手法として生まれ変わった。
日本とアメリカという相当気質の違う国を経て生まれた「リーン」という概念は、相当カドが取れたグローバルな味付けになった。
だから、世界中で注目されている、と。

| | コメント (0)

2013/08/18

【告知】「Redmineの運用パターン集~私に聞くな、チケットシステムに聞け」を講演します

9/12(木)午後に、@sakaba37さんとチケット駆動開発に関する講演を行います。

【参考】
第3回SRA関西セミナー チケット駆動開発による「ソフトウェア開発の現場力向上」 のご案内

【告知】チケット駆動開発の知っておくべき大切な事 - 講演の構造 - #TiDD: ソフトウェアさかば

【開催概要】
日 時: 2013年9月12日(木)14:00~17:30(13:30~ 受付)
会 場: 株式会社SRA 関西事業部
参加対象: 製品開発、情報システム、運用関連の関係者の方、チケット駆動開発にご関心のある方
参加費用: 無料 (事前登録をお願いします)
定員: 30名 (定員になり次第、募集を締め切らせて頂きます)

講演タイトル:
「Redmineの運用パターン集~私に聞くな、チケットシステムに聞け」(@akipii)

講演概要:
昨今、Redmineをソフトウェア開発のタスク管理だけでなく、社内の他業務へ適用する運用事例が増えています。
それら運用事例を調べてみると、チケット駆動開発の特徴を生かしているだけでなく、 Redmineの優れた機能を流用して、業務改善に役立てておられます。
本講演では、Redmineによるチケット駆動開発の運用パターンと、Redmineの適用範囲や適用の限界についてお話します。

【講演の背景】
今年6月に開催されたRxtStudy(関西)と品川Redmine(関東)において、幾つかの事例を聞いてみると、Redmineをソフトウェア開発以外に適用する事例が多いことに気づきました。
どうやら、Redmineの豊富な機能を使って、社内の業務における課題解決に流用しているようです。

Redmineを業務に適用した事例としては、ソフトウェア開発自身も含めると、下記があげられます。

・障害管理(BTS)
・課題管理(ITS)
・アジャイル開発(TiDD:チケット駆動開発)
・システム運用保守
・ヘルプデスク管理
・ハードウェア資産管理(PC・サーバなど)
・工数管理(→EVMなど)

第8回勉強会の感想~RedmineはCRMや情報系システムにも適用できる #RxTStudy: プログラマの思索

第5回品川Redmine勉強会の感想 #47redmine: プログラマの思索

RedmineはCRMソフトとして使えるか?: プログラマの思索

メールからRedmineのチケットを自動登録する時の注意点: プログラマの思索

RedmineはPC・サーバ資産管理に適用できるか?: プログラマの思索

【公開】未発表資料「チケット駆動開発におけるEVMの考え方」 #RxtStudy: プログラマの思索

自分でもいくつか試していますが、ソフトウェア開発以外の業務でRedmineを導入する場合、幾つかのポイントがあります。
一番重要な点は、チケット管理がどの業務、あるいはどの課題解決にうまく当てはまるのか、という点です。
つまり、チケット化すべき対象の業務や課題は何か?ということです。

その考え方を突き進めると、チケット管理のモデルが見えてきて、そのモデルが現場の業務の問題点をどれだけ解決できるのか、という方向へ進化できます。
もちろん、Redmineでは解決できない課題も出てきますし、Redmineを導入したことで新たに判明した課題も出てきます。
それこそが、問題の背後にある本来の本質なのだと思います。

例えば、アジャイル開発にRedmineを導入すると、変化の多いタスク管理をサポートできます。
そして、プロジェクトファシリテーションや他ツールとの連携などの色んな副次的効果も出てきます。
しかしながら、Redmineによるチケット駆動開発でアジャイル開発を実装できると、現状の問題の本質は、本来のマネジメントは何か、とか、小規模リリースの実装方法、更には、並行開発を支える構成管理パターンの重要性に発展していきます。

そんなことを考えてみると、Redmineは情報系システムのERPと同義のツールと思えてきます。
実際、従来の業務にRedmineというツールを導入することで、業務フローが大きく変わり、担当者の役割も変わり、最終的には組織体制まで変革の影響を及ぼします。
つまり、Redmineは単なる無料のツールではなく、業務改善のための道具の一つとして扱うべき対象なのです。

今回の講演では、ソフトウェア開発以外について、私が経験したこと、考えたことについて話してみたいと思います。

| | コメント (0)

2013/08/17

SugarCRMの資料

オープンソースのCRMソフトSugarCRMの資料を見つけたのでリンクしておく。

【参考】

SugarCRMはシンプルなCRMソフトと言える。
SugarCRMの機能は、Redmineの機能にマッピングできるか?

取引先=Redmineユーザグループ、担当者=Redmineユーザとすれば、顧客情報の管理に使える。
取引先(顧客)が潜在顧客(ターゲット)なのか、見込み客(リード)なのか、既に受注済みの既存顧客なのか、という区別は、Redmineユーザグループの属性の一つとして管理できる。

また、取引先との活動履歴として、SugarCRMには、ミーティング(打合せ、予約)、ケース(クレーム対応)、タスク(依頼された仕事)、コール(電話対応)があるが、これらはRedmineのトラッカーとしてマッピングできるだろう。
つまり、ワークフローの一部として捉えることができる。

但し、SugarCRMの重要な機能であるマーケティング機能や営業支援機能は、Redmineのデフォルト機能にそのままマッピングするのは無理。
RedmineCRMプラグインを導入して、取引先ごとの案件管理や商談ステータスの管理を使う必要があるだろう。

RedmineはCRMソフトとして使えるか?Part2~RedmineをCRMソフトとして使うためのプラグイン: プログラマの思索

RedmineはCRMソフトとして使えるか?: プログラマの思索

メールからRedmineのチケットを自動登録する時の注意点: プログラマの思索

| | コメント (0)

Jenkinsの使い道

7月にJenkins勉強会があり、@kazuhito_mさんの資料が公開されていたのでリンクしておく。

Jenkinsの使い方は参考になる。
感想はまた後で。

【注】
僧侶「仁斤」さんとは、Jenkinsのことだそうです(笑)

| | コメント (0)

2013/08/13

ソフトウェア工学の講義資料

名城大学でのソフトウェア工学の講義資料が公開されていた。
用語や概念を知るには分かりやすいのでリンクしておく。

【参考】
2012年度 「ソフトウェア工学」 ホームページ

(講義内容)
1 大規模ソフトウェア開発の課題
2 ソフトウェアの開発工程
3 プロジェクト管理
4 要求分析
5 構造化分析
6 オブジェクト指向分析
7 中間試験
8 アーキテクチャ設計
9 ユーザインターフェース設計
10 モジュール設計
11 プログラミング
12 テストと検証
13 保守と再利用
14 中間試験2

上記のソフトウェア工学の講義内容は、もちろんアジャイル開発やスパイラルモデルなどの説明もあるが、従来のWF型開発における知識の総体系のように思える。
要求仕様の品質特性、ソフトウェア品質の6つの特性、テスト設計の種類、ソフトウェア再利用、ソフトウェア保守などの概念を網羅的に説明してくれているので分かりやすい。

上記の資料は、今までのソフトウェア開発で蓄積されたノウハウの一つ。
しかしながら、それら知識体系を知っているからといって、高品質で効率性の高い開発ができるとは限らない。

アジャイルの背景には、開発生産性の向上がある - ウィリアムのいたずらの開発日記にも書いているように、実際の開発現場ではむしろ、フレームワークありきのアーキテクチャを元に、要求仕様や工数見積を合わせて、高速に開発していくという現実もある。

フレームワークのAPIを駆使した泥臭いプログラミング、サーバーやDB移行などの泥臭い環境構築、色んな観点でのテストによるバグ出しと修正、肥大化しがちな要求スコープを現実的に折り合いをつける調整などの作業が実際の開発現場では多い。
ソフトウェア工学の綺麗な概念だけでは、実際のソフトウェア開発ではうまくいかない。

とは言え、上記のソフトウェア工学の概念を知ることによって、自分たちの経験を整理して、現状の問題とそこから生じる今後の課題を見つけることはできる。
過去のソフトウェアの偉人の肩に乗って、少しずつ遠くを見ることはできるようになる。
そうでなければ、ソフトウェア開発は、いつまで経っても、蓄積されないノウハウの塊であって、ソフトウェア工学の概念を何度も車輪の再発明で実装する羽目になるだろう。

アジャイル開発やチケット駆動開発も、ソフトウェア工学の知見を注入して、体系化できればいいなと思っている。

| | コメント (0)

2013/08/10

パイロット開発にAgile開発のアイデアを適用した事例~実験的アプローチ #JaSST_Kansai

先週開催されたJaSST'13 Kansaiで、細谷さんが発表された実験的アプローチの話がとても興味深かった。
理解できたことをメモ書き。
間違っていたら後で直す。

【参考】
JaSSTソフトウェアテストシンポジウム-JaSST'13 Kansai

JaSSTソフトウェアテストシンポジウム-JaSSTレポート

JaSST関西2013私的まとめ - Togetter

[#Agile] 組織的改善から現場改善へ #JaSST_Kansai: ソフトウェアさかば

フィードバックループ構築の最初の一歩:メトリクスの重要性 | "Lean Startup Japan"

【1】新しい技術を適用する場合の問題点

ソフトウェア開発案件では、特に新規開発では、必ず新しい技術を使って開発するのが普通。
例えば、Java+Scalaを使おう、とか、RailsとNode.jsを使おうとか、バッチにCobolではなくAsakusaフレームワークのHadoopを使う、など。
理由は、その時代の最新のフレームワークやライブラリ、ハードウェアを使うことで、システムが運用できる期間を長く維持するためだ。

細谷さんの事例では、原因結果グラフやドキュメント生成ツールなど、特定の課題や特定の工程に対して、新しい技術を適用しようとしている。

しかし、新しい技術を使う場合、リスクは結構ある。
一番のリスクは、開発案件や自分たちのチームのコンテキスト(状況)にその技術がうまく当てはまるか、ということだろう。
本では、こうすればうまくいく、と書かれていても、プロジェクトやチームのメンバーのスキル、開発環境は様々であるがゆえに、制約条件も多い。
その制約条件と技術がマッチしない場合は、失敗プロジェクトになる。

また、新しい技術は実際に使ってみたら、想定した効果が出なかった、あるいは、別の悪影響が現れた、というリスクもある。
例えば、最新のフレームワークを採用したのに、開発者が慣れるのに手間取り、開発やテストが長引き、品質も良くなかった。
あるいは、せっかく出来上がったシステムでは、大量のトランザクション処理で性能要件を満たさず、別の解決策を選択せざるを得なかった、など。

だから、経験のあるプロマネは、要件定義をしている期間中に、アーキテクチャの実現可能性調査というパイロット開発を裏で並行作業している時が多い。
早めに実現可能性調査(フィージビリティスタディ)のフィードバックを受けて、うまくいかないならば、別の手段を調査するように、手を打つわけだ。

でも、細谷さんの説明のように、新技術を適用するための検証時間が長かったり、適用した投資コストが大きすぎるために撤退しづらいという問題点がある。
開発がズルズル進んで、結合テスト工程で技術上のリスクが判明したら、その時点で新技術を捨て去ることは普通は困難だ。

細谷さんの事例「実験的アプローチ」は、そんなパイロット開発をメタプロセス化した事例のように思えた。

【2】実験的アプローチのプロセス

実験的アプローチによれば、下記のような流れになる。
ポイントはいくつかある。

【2-1】手段(細谷さんのコンテキストでは、適用したい新しい技術)の情報収集は、SNSや書籍、コミュニティなどで行う点が面白い。
 うまくいった事例だけでなく、発信者その人も知っているならば、どんなコンテキストで成功したのか、をよく理解できる。
 最近は、FacebookやTwitterですぐにコミュニケーションが取れるし、コミュニティのイベントがとても多いので、感度の高い情報を収集しやすくなったと思う。

【2-2】課題の発見→課題と手段をマッピング→手段の試行

この辺りのプロセスがとても重要。
まずは、繰り返し現れる課題を特定する。
アジャイル開発ならば各イテレーションだろうし、WF型開発ならば過去の複数のプロジェクトが抽出の対象になるだろう。
なぜなら、再現性の高い課題は、新しい技術(手段)で解決できることで大きな効果を得やすくなるからだ。

次に、課題と手段をマッピングする。
普通は、課題と手段の関係は多対多なので、複雑だ。
だから、課題のスコープをできるだけ小さくして、より具体的な課題にすることで、手段を絞り込む。
普通は、1つの課題に対して、複数の手段を取る時が多いだろう。
それゆえに、複数の手段を並行して実施する場合もある。

ここで、手段の試行のゴール(終了条件)は、手段の実践を開始できる状況であること、という説明がある。
この意味は、採用した手段を使えば課題を解決できる可能性が高くなると決断した状況であると理解している。

この辺りのプロセスが重要と思うのは、現場のトラブル(問題・AsIs)から課題(ToBe)を特定して、有効な手段を選定しているからだ。
細谷さんの説明では、原因結果グラフを使うためにCEGTestを使ったりした事例でその辺りの事情を詳しく話してくれて、なるほどと理解できた。

【2-3】結果の評価

手段を実践後、できるだけ早く結果を得て評価する。
評価の基準は、採用した手段が自分たちのコンテキストにうまくハマっているかどうか。
プロジェクトやメンバーの制約条件の元で、その技術で課題を解決できたのか。

失敗したらなば、すぐに撤退すればいい。
そのために早めにフィードバックを受けたわけだから。

成功すればそれでよいだろうが、なぜうまく成功したのか、という必然性をリーダーもメンバーも認識しているとは限らない。
だから、成功した必然性をコンテキストと比較して、そのノウハウを形式知ないし実践知として言語化することが重要。

この辺りはとてもなるほどと思う。
個人的には、実験的アプローチで得られた実践知は、パターン言語でまとめることが有効だろうと思っている。
成功したノウハウは、コンテキスト依存が大きいために、どのプロジェクトでも、どのチームでも適用できるとは限らない。
だから、どんな状況でどんな問題に対して有効であるのか、というパターンで形式化してネーミングすれば、流通しやすくなるだろうと思う。

【2-4】実験的アプローチはパイロット開発の成功率を高めるための一手法

実験的アプローチの原則は、細谷さんに後で聞いたら、リーンスタートアップの手法にヒントを得たと聞いた。
確かに、最低限の機能の製品(MVP)を早く作って、少しずつ改善していくリーンスタートアップの手法と、アーキテクチャ検証などのパイロット開発はとてもよく似ている。

コンテキストと新技術が合致するかどうか、手探りしながら、早く結果を得て、新技術が適用できる範囲を特定していく。
コンテキスト探索手法と言ってもいいのかもしれない。

上記のアプローチは、RedmineやJenkinsなどの新しいツールを導入する場合にも使える。
ツールが全てを解決してくれるとは限らない。
どのコンテキストでうまくいくのか、逆に想定しない副次的な悪影響があるのか、を特定して、ブラッシュアップしていくのが大事。

もちろん、ERPのようなパッケージ製品を導入する場合にも、そのアイデアを流用することはできるだろう。
色々考えてみる。

| | コメント (0)

Antを見直すpart2

Antに関する記事をメモ。

【参考】
Antリファクタリングカタログ: プログラマの思索

Antを見直す: プログラマの思索

【1】AntとGroovyを組み合わせる

下記の記事では、MySQLへ画像ファイルをBlobデータとしてInsertするとき、Antをバッチスクリプトとして作り、Insert処理はGroovyで実装する。

Groovy + AntでBlobデータ投入ツールをさっと作る | SDアドバイザーズ開発室から

この手法が面白い点は、Antと言うタスク指向のビルドスクリプト内部で、条件分岐やループ処理をGroovyで自由自在に実装できること。
つまり、Antビルドスクリプトをバッチ処理のように使える。

他にも下記の事例があるみたい。

Antスクリプト内でGroovyを利用する - No Programming, No Life

ant中からgroovyを呼び出す~あれこれ~ - プログラマ的京都生活

最終的にはDSLのような考え方に通じるだろうと思っている。

groovyの可能性: プログラマの思索

DSLの使い道は継続的デリバリ~AntやMavenからGradleへ: プログラマの思索

【2】AntではCVSタスクは普通に使えるのに、SVNはデフォルトでは使えない。
 AntでSVNコマンドを使うには、svnantタスクを使えばいい。

svnantのtask一覧

SVNのチェックアウト、エクスポート、コミットなどもAntのタスクで使える。

| | コメント (0)

2013/08/08

コプリエン著のアジャイルソフトウェア開発の「組織パターン」の感想part2

和智さん翻訳・コプリエン著のアジャイルソフトウェア開発の「組織パターン」を読んでいると、気づくことが多い。
ラフなメモ書き。

【参考】
生成的開発プロセス・パターンランゲージ

コプリエン著のアジャイルソフトウェア開発の「組織パターン」の感想: プログラマの思索

【1】コプリエンは、モデルとして安定しないプロセスよりも、モデルとして安定しているロールに着目して、組織パターンを書いた。
何故、ロールに着目したのか?

7.3節「ロールとコミュニケーション」で、組織におけるロールの重要性について述べている。

【1-1】組織の中で何が行われているか、をロールが定義する

組織の中のプロセスは誰かが担当していて、それはロールによって抽象化されて定義される。
担当する作業を組織内の誰にでも実施できるように、アサインできるようにするならば、ロールの定義が作業内容になる。

【1-2】人はロールによってアイデンティティを得て行動できる

開発者、テスター、プロジェクトマネージャなどのロールを与えられて、初めて、その組織内でそのロールを使って振る舞える。

人にふさわしいロールを与えることで、生き生きと見違えるように、能力を伸ばす人もいる。
僕の経験では、若手にはロールを意識的に付与させると、仕事していくうちにそのロールに必要な能力を身につける。

特に、管理職や経営層のように、組織内で権力が大きくなるほど、ロールの影響力は大きくなる。
ロールを付与されることで、ノブレス・オブリージュのように、その社会的地位にふさわしい能力を自然に身に付けるパターンが多いと思う。

それらロールは、プロジェクトや組織を離れても、その人について回る時がある。
その人の能力や性格に見合ったロールはある。
プロセスよりもロールの方が安定している。

【1-3】組織の情報はロールの間を流れる

コミュニケーションは、ロールの間を流れる。
情報の流れは組織の成功・失敗の起因の一つ。

コプリエンによると、調査した組織では、あるロールが存在すること、あるいは、存在しないことに気づいたと言う。
ロールが足りない組織は、そのロールを組織が必要としていないことを意味しているわけだ。

例えば、組織の中で、顧客をロールに組み込んでいない場合、その組織は顧客の問題に対してどれくらい認識しているか、疑問に思える。
これは、顧客の代理人パターンを指すのだろう。

あるいは、アーキテクトというロールがない組織がある。その組織は、ソフトウェアアーキテクチャを軽視している組織なのだろう。
これは、アーキテクトが製品を統制する、アーキテクトもまた実装する、アーキテクチャチームのパターンに相当するだろう。

【1-4】ロールを取り巻くコミュニケーションパスも重要

開発者ロールを中心に組織のコミュニケーションが回っていることが大事。
もし、マネージャのロールを中心に結びついていたら、その組織はマネージャが管理者として干渉しすぎていることを示唆している。

品質管理者のロールが他のロールと結びついていなかったら、きちんとしたシステムテストが行われていないだろう。
その場合、開発組織がシステムテストに価値を見出していない可能性がある。
そうだとすれば、かなりの問題だ。

【2】組織パターンのほとんどは、ロールの性質を説明している。

防火壁(FireWall)、門番(Gateway)、顧客の代理(Proxy)、パトロン、アーキテクト、品質管理者というロールがない組織があったとしたら、そのロールに付随するパターンの効果が実現されていないことになる。
つまり、そのロールが果たすべき作業を、開発組織は軽視しているか、その作業の工程そのものの品質が悪いことを意味しているのだろう。

個人的には、防火壁(FireWall)、門番(Gateway)、顧客の代理(Proxy)というパターン名は、ネットワーク機器を連想させる。
それらのパターンの意味は、まさにネットワーク機器の特徴と同じ。

ファイアウォールは、外部からの不要なアクセスを防ぐ。
防火壁(FireWall)は、ニワトリとブタというScrumの格言の通り、スクラムチーム外の利害関係者からの割り込みや干渉を防ぐ。

ゲートウェイは、通信媒体やプロトコルが異なるデータ(情報)を相互に変換して通信する。
門番(Gateway)は、スクラムチーム外の利害関係者と、適切なプロトコル(外部インターフェイス)を通して、対話できるパイプラインを作る。
門番(Gateway)は、プロジェクトの情報やシステムに関係する用語を、利害関係者とチームの間で翻訳する。

プロキシサーバーは、ネットワークに出入りするアクセスを一元管理し、内部から特定の種類の接続のみを許可したり、外部からの不正なアクセスを遮断する。
顧客の代理(Proxy)は、チームが顧客と頻繁に会えない場合、プロジェクト内に顧客の代理人というロールを作り、課題を明確化したり、解決策のアイデアを出し合う。

このように、防火壁(FireWall)、門番(Gateway)、顧客の代理(Proxy)というロールは、コミュニケーションを遮断したり、促進するために用いられる。
それらロールがあるからこそ、開発者は自分たちの仕事に集中できる。
そうでなければ、外部からの利害関係者やマネージャが常に開発者へ干渉して、開発の生産性や製品の品質に悪い影響をもたらしているだろう。

他にも気づいた点があれば書いてみる。

【追記】
コプリエンさんのつぶやきを見つけた。

Twitter / jcoplien: Nice summary / overview of what org patterns are all about in the new Japanese translation. http://forza.cocolog-nifty.com/blog/2013/08/part2-e61b.html …

| | コメント (0)

2013/08/06

Redmine for ITILが解決するもの

ホロンテクノロジーという会社がRedmine for ITILというソリューションツールをPDFで公開していた。
とても参考になる資料だったので、システム運用保守におけるRedmineの解決方法について、考えたことをメモ書き。

ホロンテクノロジーが提供するOSSソリューションのご紹介 (PDF)

Redmine for ITILの特長|株式会社ホロンテクノロジー

Redmine for IMSの特長|株式会社ホロンテクノロジー

Hinemos+Redmine for ITILで運用保守を改善する: プログラマの思索

Redmine for ITIL: プログラマの思索

TiDDにITILの概念を持ち込む: プログラマの思索

チケット駆動開発の課題~ITILやDevOpsの適用方法: プログラマの思索

【1】システム運用保守の問題点

システムの新規開発案件ではなく、システムの運用保守では特有の問題点がある。

(1)完全化保守や適応保守が難しい

本番運用している業務システムは安定稼働が命だ。
しかし、実際の運用現場では、色んな障害が毎日のように起きる。
HDDが壊れたり、ネットワーク回線の通信速度が突然ダウンしたりするハードウェア障害。
SIで新規案件を無事にリリースしていくたびに、保守する対象のシステムは飛躍的に増えていく。

しかも、サーバーは3年おきにリプレースする時が多い。
メモリの増設、HDDの交換、ネットワーク回線の高速化など、動いているのにシステムをいじって、システムをダウンさせてしまう場合が多い。

予防保守とは「リリース後のソフトウェア製品の潜在的な障害が運用障害になる前に発見し、是正を行うための修正」のことだが、実際の現場では、障害も起きていないのに、上記のような事情で是正対策を実施せざるを得ない。
そんな保守作業は、完全化保守や適応保守と呼ばれる。

適応保守とは「ソフトウェア製品を使用できるように保ち続けるため、ソフトウェア製品の引渡し後に製品を修正する」保守作業。
完全化保守は「性能や保守性を向上させるためにソフトウエアを改良する」保守作業。
つまり、完全化保守や適応保守は、稼働中のシステムを生き延びさせるために必要な保守作業を示す。

しかしながら、完全化保守や適応保守の作業で、障害を自ら起こしてしまいがち。
それら保守作業のノウハウが蓄積されず、日々追われているのが実情ではないだろうか?

(2)運用コストがどんどん大きくなる

運用中はHW障害だけでなく、アプリの障害、社外の外部接続サーバーからの異常データ送信など、ソフトウェアの障害もある。
そんな障害が発生するのを抑止するために、障害フォロー手順をやリリース手順をコマンドで自動化したり、マニュアル化する時が多い。
しかしながら、リリースしたサーバーの冗長化、社外のサーバーからの外部接続、業務データは、稼働するほどどんどん増えていく時も多い。
すると、実際のマニュアルやコマンドを情報共有するのが難しくなってくる。
運用作業のオペレーションミスが結構多くなってきている。

運用ノウハウが属人化してしまい、情報共有や作業の引き継ぎがやりにくくなってきているのだ。

(3)障害検知後の連携が悪い

システムの安定稼働を保証するために、監視ツールでpingやヘルスチェックなどで検知する仕組みを作るのが普通。
だが、障害検知のメール送信機能ぐらいで、その後の調査やソース修正への情報連携がスムーズでない。
Excelの障害報告票をメールでたらい回しにする場合が多いから、どれが最新の情報なのか、すぐに分からなくなる。

【2】Redmine+ITILによる解決策

システム運用保守のマネジメントフレームワークであるITILの考え方をRedmineと組み合わせる場合、以下のような方針でシステム運用保守に導入するとよい。

(1)障害や問合せ、改良作業など全てはチケットで一元管理する

障害、問合せ、サーバーのリプレース、ソフトウェアの機能改善など全てをチケットに登録して記録していく。
チケットに作業記録が残るので、後から参照できる。

チケットのステータスで問合せや障害の状態を管理すれば、チケットのワークフローで一括管理できる。
途中で、担当者を入れ替えたり、ステータスの更新を権限でチェックすることも可能。

また、チケット集計機能を使えば、障害一覧や問合せ一覧、期限間近のタスク一覧など、多種多様なレポートを出力できる。
リーダーは毎月の報告書作りや、毎日の進捗チェックに活用できる。

(2)監視ツールの障害検知は、メールによるRedmineのチケット自動登録機能を適用する

Zabbixなどの監視ツールが検知した障害をメーリングリストへ送信する時に、Redmineにもメール送信すれば、チケットを自動起票できる。
チケットの起票漏れがなくなるし、一度チケットに登録されれば、誰かが気づいてくれる。

チケットの発行を起点とした後は、インシデント管理→問題管理→変更管理への流れをチケットのステータス管理でマッピングすればいい。

Redmineのチケット登録をITILへ応用する: プログラマの思索

メールでRedmineチケットを登録する機能の可能性: プログラマの思索

メールでRedmineチケットを登録する機能のアーキテクチャ: プログラマの思索

(3)共有したい情報はWikiを積極的に使う

運用保守では、毎日のアクセスログチェック、毎月末のログ集計からの報告などの定形作業がとても多い。
それらの運用手順はWikiにまとめておくと、ブラウザで閲覧しながら作業できる。
もし手順に変更があれば、Wikiですぐに編集すればいい。

また、ネットワークやシステムの設定情報、定型的なリリース手順もWikiで公開しておくと良い。
Wikiの利点は全文検索できることなので、分からなければ、まずは検索すればいい。
作業の引き継ぎもWikiがあれば、やりやすくなる。

【3】Redmine導入による効果

Redmineを導入すると、副次的効果も出てくる。

(1)チケットやWikiで見える化

作業の見える化は、コミュニケーションの促進をもたらす。
過去の障害や問合せをチケット番号で話すことで、お互いの認識が共有しやすくなる。

チケット駆動開発のプラクティスである「No Ticket, No Work」や「Ticket First」を運用していれば、チケットの起票と共に作業が始まり、チケットをキャッチボールしながら作業するようになる。
複数人が一つのチケットに関わることで、2つの目による品質チェックが有効に効く。

ホロンテクノロジーが提供するOSSソリューションのご紹介 (PDF)の17ページ以降に、Redmineの運用方法を詳しく解説している。

(2)トレーサビリティによる効果

Redmineには関連チケット、親子チケットなど、チケットを関連付ける機能がある。
この機能を使えば、並行で作業しているチケット、過去と同じ事象のチケット、同一人物による問合せチケットなどを相互リンクすることで、作業の理解を促進できる。

また、ソースのリビジョンとチケットの連携により、ソース修正の発生理由をチケットから辿ることもできる。
運用保守は少ないメンバーで数多くのタスクを回すから、人の出入りも激しい。
いなくなった人の運用ノウハウは口頭の説明だけでは引き継がれない。

トレーサビリティは、特にその後の運用保守やリバースエンジニアリングで大きな威力を発揮する。

(3)変化に適応

チケットは変化に強い。
日々の状況に応じて、ステータスや期日、内容、マイルストーンを更新して記録していく。
チケットを最新化する運用さえ徹底できれば、チケット集計機能によって、リーダーはリアルタイムに作業状況を把握できる。

【4】Redmine+ITILを適用して判明した課題

(1)ITILをそのまま運用すると、ワークフローが複雑になる。

インシデント管理→問題管理→変更管理→リリース管理という流れは、一つのインシデントを4つのチームでやり取りするので、ステータスがとても多くなる分、複雑になりやすい。

ITILをガチガチに運用して複雑になるよりも、現場の体制に合わせて、ステータスを減らして、気軽に回せるワークフローを構築した方がいい。

(2)問合せないし検知されたインシデントから発生した変更要求は、CABと呼ばれる会議体で対応方針を決定するように運用する。

ITILのCABは、リリース確認会の合議体に相当する。
この場で、全員からレビューを受けて承認されなければ、そもそもリリースできない。
ITILのCABが、複数チームに関わる課題を調整したり、変更要求の修正の順序を決めたりする。
このCABがしっかり運営されないと、せっかく登録されたチケットが完了まで上手く回らない。

ホロンテクノロジーが提供するOSSソリューションのご紹介 (PDF)の12ページでは、チケット駆動型事案管理のワークフローイメージとして、「解決策確認会」というステータスが用意されているが、それがCABに相当する。

初心者歓迎! ITIL連載講座:ITインフラの変更管理プロセス (2/4) - ITmedia エンタープライズ

(3)チケット集計機能はもっと強化した方がいい。

普通は、障害報告票を真似て、チケットの属性をカスタムフィールドで増やし、障害報告に使えるようにする。
特に重要なのは、ワークフローに相当するトラッカー機能だ。
障害の種類、問合せの種類に応じて、トラッカーを作って運用した方が、チケットのテンプレートを切り替えしやすいし、ワークフローを微妙に変えることもできる。

でも、チケットの入力が煩雑になる弱点もある。
だから、チケット入力とチケット集計を天秤にかけて、運用がうまく回るように注意すべき。

【4】感想
ソフトウェア運用保守こそ、RedmineのようなITSが使われるべきだと思う。
なぜならば、現場の開発プロセスをサポートするような機能がITSにふんだんに揃っているからだ。

上記のような問題を解決するためにRedmineを導入する場合、自分たちで作りこんだ独自のプロセスとセットで運用することも可能だろう。
やり方はいくらでもある。
Redmineによるチケット駆動開発には、数多くの可能性が秘められている。

| | コメント (2)

2013/08/05

クラウドのもう一つの本質~ソフトウェアの可搬性を確保する

Hadoopフレームワークasakusaを使って、バッチ処理の基本であるEDIをAWSへ移行した記事を見つけた。
その記事の中で「クラウドがソフトウェアの可搬性を確保するのに効果がある」という事が書かれていたのでメモ。

【元ネタ】
クラウド上にEDIを「移行する」ということの意味 - 急がば回れ、選ぶなら近道

Hadoopの本質は分散I/Oにあり~クラウド時代の非同期処理: プログラマの思索

基幹系バッチ処理をHadoopで高速化: プログラマの思索

クラウドの本質はインフラ管理のIT化: プログラマの思索

クラウドデザインパターン~インフラ方式設計のベストプラクティス集: プログラマの思索

デブサミ夏2013のリンク: プログラマの思索

デブサミ夏2013のテーマはDevOps。
DevOpsの背後にある技術は、AWSとChef。
その技術のキーワードは、Infrastructure as Code。
つまり、インフラ管理のIT化。

インフラ構築は今まではWF型開発が主流だった。
ハードの購入、OSやミドルウェアのバージョンを決めてインストールなどの作業は、一度実行するとやり直しが効かないから、事前の計画づくりを重視せざるを得ない。
でも、AWSのようなクラウドを使うことで、試行錯誤しながら性能検証したり、アクセス数が増えれば動的にサーバーリソースを増やす対策を後から取ることができる。

でも、クラウドの利点はそれだけではない。

昨今のIT技術の流れとして、ソフトウェアとハードウェアの乖離が激しくなっている。
業務システムは一度作ったら10年ぐらいは普通に使うのに、WindowsやRDB、JDKのバージョンアップ、サーバーのリプレースによって、ソフトウェアも変えざるを得ない。
CPUやHDDの性能向上があるために、OSやミドルウェアのVerUpのために、3年おきにリプレースせざるを得ない時が多い。
このいわゆるリプレース作業は、レガシーマイグレーションとも呼ぶ。

レガシーマイグレーションの良い例は、Cobolを使う汎用機からJavaやPHPのようなWebシステムを使うオープン系への移行作業。
90年代からのPCの普及がそれを後押しした。
ハードウェアやミドルウェアを変えるだけでなく、プログラミング言語まで変えてしまうリエンジニアリング又はリライトゆえに、どのプロジェクトも大変だっただろう。
下記にその事情は書いた。

レガシーマイグレーションという名のシステム移行はデスマーチになりやすい: プログラマの思索

そして今は、サーバーなどのハードウェア資産を自社内に持つオンプレミスから、ハードウェア資産を変動費化するクラウドへ移行するレガシーマイグレーションの案件が少しずつ増えてきている。
一度クラウドに乗せてしまえば、ソフトウェアの可搬性は高まる。
何故なら、サーバーの性能は動的に拡張可能であるし、クラウド上でのデータやシステムの移行作業は速いから。
ソフトウェアの可搬性が良ければ、業務システムが使える期間も長くなるだろう。

ソフトウェアの可搬性は、ソフトウェアの品質特性における移植性に相当する。
ソフトウェアの品質特性における機能性や信頼性よりも、長く使うシステムを機能拡張しやすくするための保守性や、ソフトウェアを再利用したり、ハードウェアに依存せずソフトウェアの可搬性を確保するための移植性の方が重視される時代になってきている。

新しい技術が、ソフトウェアに求める品質特性を大きく変えてきているのだ。

| | コメント (0)

2013/08/04

デブサミ夏2013のリンク

デブサミ夏2013「DevOps」&「Mobile」のカンファレンスに行ってきた。
資料リンクを張っておく。

【参考】
Developers Summit 2013 Summer:エンタープライズに向けた「DevOps」&「Mobile」のカンファレンス

「夏サミ2013」開催、講演関連資料のまとめ:CodeZine

Developers Summit 2013 Summer (夏サミ2013) #natsumi - Togetter

平日にもかかわらず、600人近い参加者がいたらしく、とても人が多かった。
DevOpsバブルみたいだった。

DevOpsの各講演は参考になったが、抽象的な話が多かった。
下記のTwitterがDevOpsの今の状況を表していると思う。

Twitter / yusuke_arclamp: DevOpsの話、もはや概念論はいいから具体的なリポジトリ戦略やデプロイ戦略をどうしているのか知りたい。さらにQAとの絡みやbizとの調整とか、考えないといかんことが多い。まったくもって楽をするのは大変だ。

そんな中で最も地に足が着いたDevOpsの講演は、IIJさんの下記発表だと思う。

10年以上前から、DevOpsなんて会社では普通でした、という言葉が印象的だった。

それから、長沢さんの講演では、スライド資料21枚目のメトリクス「サイクルタイム」「MTTR」が気になった。
後で聞いたら、DevOpsにおいて、ビジネス側と開発・運用側でお互いが共有し合えるメトリクスはこの2つだと。

ビジネス側ではコストや売上高などのKPIで見たいだろうが、開発・運用側とマッチしない。
開発・運用側のITメトリクスは素人には難しすぎて、ビジネス側の人は分かりにくい。

サイクルタイムは、要求の発生からリリースまでの時間、つまり、開発リードタイムだから、ビジネス側も認識できる。
サイクルタイムが短いほど、システムをリリースできる間隔を短くできるから、その分、ビジネスの競争力が増す。
リーンソフトウェア開発で最も重視されるメトリクスの一つ。

MTTRは文字通り、障害修復時間。
障害が発生して、暫定対応なり修正対応して、業務が復旧するまでの時間。
MTTRが短いほど、稼働率が長くなるので、業務への影響が最小限に抑えられる。
システムの信頼性という観点では、稼働率のメトリクスの方が重要だろうが、アジャイル開発の文脈では、MTTRを重視して、たとえ障害が起きたとしても修正しやすいシステムを重視する。

アジャイル開発のメトリクスでは、ScrumのVelocityが有名だが、リーンソフトウェア開発やDevOpsの観点が混じってくると、サイクルタイムやMTTRのメトリクス採取も必要になってくるだろう。
しかしながら、サイクルタイムやMTTRの収集・集計・評価の注意点やノウハウはまだ広がっていないので、今後の課題になるだろう。

DevOpsがもたらした技術は、ChefやInfrastructure as codeのようなインフラ管理のIT化と、MTTRやサイクルタイムあるいは大量のログを収集・分析するメトリクス分析の2つだと思う。
インフラ管理のIT化だけが注目されているが、最近のビッグデータへの注目も考えると、ITにおける有用なメトリクスの収集とその使い方も再発見されるものがあるだろうと思う。

今後も情報を追いかけてみる。

| | コメント (0)

SysMLの要求図の書き方

SysMLの要求図の書き方についてメモ。
間違っていたら後で直す。

【参考】
astah 6.1 で「要求モデル」が目指している姿:An Agile Way:ITmedia オルタナティブ・ブログ

「何故システムモデリングが必要か」 | 株式会社オージス総研

第2回 SysMLとは何か | Think IT

第2回目 SysMLとは?SysMLの現状 : つれづれブログ

SysML : つれづれブログ

第3回目 SysMLセミナー感想 : つれづれブログ

The Rational Edge:汎用グラフィカルモデリング言語「SysML」 パート2:グラフィカルなモデル言語で製品構造を記述 (1/2) - ITmedia エンタープライズ

「システムエンジニアリングで SysML を使いこなす」第2章 実践編-電光掲示板を設計する(1)

astah* professional 6.1の要求図: プログラマの思索

TestLinkとEnterprise Architectを連携する: プログラマの思索

【1】SysMLは特に、組込みシステムの要件定義や方式設計で使えるモデリング図法。
UMLとかなり重複しているが、ブロック図のように、エンタープライズ系では使わない図法もある。
電気回路を作る所ならば、ハードウェア技師とコミュニケーションするのに役立つかもしれない。

僕は、SysMLの中でも要求図に一番興味がある。
業務システムの要件定義でも、Whyに相当する要求と要求仕様(SRS)を関連付けて、詳細化していく作業は重要だ。
設計していると、すぐにWhyの部分を忘れてしまいがち。
だから、要求図を使って、本来の要求を詳細化していく過程で、仕様と要求を常にリンクするようにしながら、要求と仕様のズレをなくしたい。

平鍋さんがastah 6.1 で「要求モデル」が目指している姿:An Agile Way:ITmedia オルタナティブ・ブログで書いているように、「モデルは要求を満たす(satisfy)」「テストは要求を検証する(verify)」のように表現したいのだ。

要求図が要件定義に使えるかどうか、以下検討してみる。

【2】astahならば要求図がすぐに書ける。
要求図のイメージは、ゴール指向分析。

要求工学 第14回:ゴール分析(エンタープライズICT総合誌 月刊ビジネスコミュニケーション)

SysML要求図をGSNと比較する

要求工学 第15回:iスター・フレームワーク(要求工学:Requirements Engineering)

つまり、定性的で曖昧な要求をゴールとしてとらえ、普通はツリー構造でゴールを分解しながら仕様へ詳細化していく手法。
SysMLの要求図も、要求(Requirement)をツリー構造で細分化していく。

【3】astahの要求図の書き方は下記が分かりやすい。

要求を整理してみよう (PDF、1568KB) - Astah

Astah* SysMLの各図の動画 要求図と要求テーブルの作成

astahの要求図における要求は、idとTextの2つの属性を持つ。
idは一意な番号。
Textは要求の内容。

要求同士の関係は以下の種類がある。

・Contain:包含
 →親の要求を複数の子の要求へ分解すると、親の要求は子の要求の論理積になる
  つまり、親の要求を満たすには、全ての子の要求を満たさなければならない。

・deriveReqt:派生
 →一方の要求が他方の要求から派生した要求の依存関係。
  この関係で要求を詳細化する時が多い。

・satisfy:充足
 →要求とその要求を満足させるモデルとの依存関係。
  例えば、ブロックやインターフェイスなどの振る舞い構造を持つ実装モデルと捉えられる。
  ゴール指向分析におけるソリューションに相当する。

verify:検証
 →要求とその要求をシステムが満たしていることを検証するテストケースとの依存関係。
  例えば、受入テストケースとして捉えられる。

refine:詳細化
 →要求とその要求を詳細化して得られるモデルとの依存関係。
  例えば、モデルはユースケースのような明確な機能要求として捉えられる。

copy:複製
 →クライアント要求とサプライヤ要求間の依存関係で、クライアント要求のテキストがサプライヤ要求の読み取りコピーであること。
  例えば、該当の要求が法令から派生している時に使われる。

trace:追跡
 →要求間の追跡の関係。使われない。

rationale
 →要求間の関係が、要求と根拠になっている。

problem
 →要求間の関係から生じる欠陥、制限などの望ましくない問題。

いずれの関係も矢印の向きは、子→親に向く。
UMLのクラス図と同じ。

【4】astahの要求テーブルは、要求図を表形式にしたもの。
要求のidとTextの一覧。

要求図の利点、使えそうな点についてメモ書きする。

(1)要求図の要求には、非機能要求を表現できること。
例えば、性能要件、耐障害性、ソフトウェアの保守性向上など。
UMLのユースケース図の弱点は、ユースケースが機能要求の詳細化という定義故に、非機能要求が書けないこと。

(2)要求図は、派生開発プロセスXDDPのUSDMに相当する。
第3回目 SysMLセミナー感想 : つれづれブログにも書かれている。
つまり、清水さんのXDDPの要件定義手法を、要求図の作成作業へ適用できる。

やはり要求を階層ツリーで表現するのは、それなりのテクニックの習熟を必要とする。
だから、XDDPのような日本人に向いた手法と組み合わせた方が確実だと思う。

また、USDMは絵としてとても見づらいが、要求図で書けば綺麗に書ける。

(3)要求図にゴール指向分析のアイデアを適用できる。
SysMLの要求図とゴール指向分析の比較は下記に書かれている。

SysML要求図をGSNと比較する

要求とゴールはほぼ同じ意味。
従って、要求のツリー構造とゴールのツリー構造はほぼ同じように書ける。
但し、ゴール指向分析にでてくるアクターや資源などはマッピングできない。

微妙に違う点もある。
ゴールツリーは戦略の分析なので、要求のツリー構造そのものに分解理由を表現できない。
そこで、要求図に「rationale(理由、根拠)」の吹き出しを入れることで代用できる。
rationaleには、要求の根拠や要求の前提条件を書くと良い。

要求図では、要求から設計モデルへの詳細化はrefine、要求の実現方法としての設計モデルはsatisfyで書ける。
つまり、要求から要求仕様への詳細化(実際はユースケース)はrefine、要求の実装(例えばアクティビティ図、状態遷移図、シーケンス図など)はsatisfyで書ける。
この手法は、ゴール指向分析の追跡にも使える。

ゴールツリーの追跡は、要求図のtraceで表現できる。
但し、要求図のtraceは推奨でないので使いにくい。

(4)要求図は、関与者利害関連表における各セルを詳細化した図である。

関与者利害関連表は、利害関係者と要求のマトリクス。
問題に対する利害関係者の要求を当てはめることで、利害関係者の要求が明確になり、要求項目の抽出が促進されて、網羅性が高まる利点がある。

例えば、Astah* SysMLの各図の動画 要求図と要求テーブルの作成を見ると、「スマートフォンの要求[マーケティング担当者の要求]」という要求図を作っている。
つまり、要求の発生元である利害関係者の観点から要求を抽出して整理しようとしている。

Road To IT-Engineer / ITエンジニアの生きる道: ユーザーより1歩先に行くための業務分析ノウハウ~業務スキルでユーザーと勝負しても勝てない! ユーザーをリードするためのモデル化の手法

Road To IT-Engineer / ITエンジニアの生きる道: アーキテクトを目指すITエンジニアのための「要求分析」

要求図のタイトルは、「req 要求図のタイトル[利害関係者の要求]」の形式であり、どの人の観点による要求をまとめたものか、を意識して書く。
だから、関与者利害関連表とセットで書くと、要求の関連が分かりやすくなる。

(5)要求図から、要求とモデル要素、要求とユースケースのマトリクスを作成できる。
これは、要求とユースケースのマトリクスは、XDDPのトレーサビリティマトリクスに相当する。

トレーサビリティマトリクスを意識することで、モデルはどの要求から発生したのか、モデルには全ての要求の制約条件が反映されているか、をチェックしながら書くことができる。
要件漏れや設計漏れの原因のほとんどは、要求から要求仕様、モデルへの詳細化が不十分であることだと思う。

従って、XDDPのトレーサビリティマトリクスの作成技法を適用すると良いだろう。

以上をまとめると、XDDPやゴール指向分析の手法を要求図へ適用すると、要求図を書きながら、質の良い要求分析が可能になるように思える。

【5】要求図を使うことで、要求の8つの品質特性(妥当性、非曖昧性、完全性、一貫性、順序付け、検証可能性、変更可能性、追跡可能性)を満たすように、作業できるか?

要求の品質特性を要求図で表現できるか、検討してみる。

チケット駆動開発を要求工学の品質特性の観点から考える~チケット駆動開発がAgile開発を必要とする理由: プログラマの思索

* 妥当性(正当性、必要性)
 要求仕様に全ての要求が網羅されている
 ソフトウェアが持つべき要求仕様が要求に含まれており、かつ、それ以外の要求を要求仕様に含まないこと
 ↓
 関与者利害関連表から要求図へ落とし込むようにすればよい。
 要求を更に分割する時は、containを使えば、要求を論理積に分割できるのでOK。
 XDDPのトレーサビリティマトリクスを使ってチェックしてもいい。

* 非曖昧性(無曖昧性, 明確性)
 すべての要求が一意的に識別できる
 何通りにも解釈できる書き方をしない
 ↓
 要求にはidが一意に振られるのでOK。

* 完全性
 要求仕様に必要な情報がすべて記述されている
 ↓
 要求のtextに必要な情報を書くことでOK。
 要求の根拠はrelationale、要求が法令から発生した内容を説明するにはcopyを使えば良い。
 XDDPのUSDMの手法を使うと、要求仕様を明確に書くことができるはず。

* 一貫性(無矛盾性)
 記述されている要求が互いに矛盾しない
 ↓
 要求図を作り上げる時に注意するしか無い。
 XDDPのUSDMやトレーサビリティマトリクスの技法と絡めて、要求の整合性に注意する。

* 順序付け
 要求が重要性や安定性について優先順位付けされている
 ↓
 要求図から設計モデル(ユースケース図、クラス図など)へ変換していく時に、順位付けすることになる。
 要求に順位というラベルを付けてもいい。

* 検証可能性
 要求仕様に含まれる全ての要求に対し、有限のコストで評価可能な手続きが存在して検証できる
 ↓
 verifyを使えば、受入テストケースとして検証可能な仕様としてまとめることができる。
 satisfyを使えば、要求の実現可能性について、実際の実装仕様まで落とし込める。

* 変更可能性
 要求の変更に対して、容易かつ完全で一貫性を保って修正可能である
 個々の要求が独立していることが必要
 ↓
 derivedで派生する要求に更に詳細化したり、refineで要求を設計モデルへ詳細化することで、変更可能な要求になるように調整する。
 RUPのようなオブジェクト指向分析が有効だろう。

* 追跡可能性
 それぞれの要求について,その背景,理由,意図などが明確で容易に参照できる
 ↓
 要求図のtraceがまさに相当するが、多分使いづらい。
 要求の根拠はrelationale、要求が法令から発生した内容を説明するにはcopyを使うことで、要求の発生源を辿ることができる。
 つまり、要求の前方追跡可能性はOK。
 
 要求の仕様化はrefine、要求の実装仕様はsatisfyを使うことで、要求の実現方法を辿ることができる。
 つまり、要求の後方追跡可能性はOK。

以上をまとめると、要求図の各技法は要求の品質特性を満たすように使える。
但し、XDDPのように、より具体的に要求分析する手法とセットで運用する方が、効果が高いように思う。

【6】要求図の課題

(1)参考にできる書籍がとても少ない。
まともに使えそうな本は「システムズモデリング言語SysML」ぐらいしかない。

実践SysML―その場で使えるシステムモデリング」も読みやすかった。

ネット上の情報も少ない。
まだ試行錯誤している途中みたい。

(2)要求図を書く場合、モデリングツールが必須。
僕はastah Professionalを使っているけれど、EnterpriseArchitectなど他にもツールがある。
ツールを使いこなすための習熟が必要。

(3)清水さんが提唱する派生開発プロセスXDDPの知識は必須だと思う。
要求図は書き方がいくらでもあるが、本当に使えるものにするには、それなりの習熟が必要。
XDDPは日本発の技法であり、日本の現場で実践例が結構あるので、適用する価値があると思う。

特に、要求の関連図であるUSDMはSysMLの要求図そのものだし、トレーサビリティマトリクスは要求の仕様化や追跡チェックで有効だ。
XDDPに関する書籍「要求を仕様化する技術・表現する技術 -仕様が書けていますか?」「「派生開発」を成功させるプロセス改善の技術と極意」があるので、参考にしやすい。

(4)ソフトウェアプロダクトラインにも適用できるか?
要求図は、プロダクトライン分析におけるフィーチャ図、可変性分析にも役立つらしい。
実際、要求図から設計モデル要素へ詳細化して、どの設計モデル要素を共通部品として作るか、という観点で整理すれば、プロダクトラインのコア資産を抽出できる。
但し、そのノウハウが公開されていない。

(5)要求図の適用分野が組込みシステムの方式設計に偏っている。
業務システムの方式設計にも使えるか?
多分使えると思うが、運用ノウハウがもっといる。

| | コメント (0)

2013/08/01

コプリエン著のアジャイルソフトウェア開発の「組織パターン」の感想

本日のDevelopers Summit 2013 Summer:エンタープライズに向けた「DevOps」&「Mobile」のカンファレンスで、和智さん翻訳・コプリエン著のアジャイルソフトウェア開発の「組織パターン」が販売されていた。
ラフな感想をメモ書き。

【1】コプリエンの論文「生成的開発プロセス・パターンランゲージ」はとても素晴らしかった。
その感想は以前書いた。

パターンランゲージの形式と正当性: プログラマの思索

組織パターンとプロセスパターン: プログラマの思索

Coplienの開発工程の生成的パターン言語を読むpart1: プログラマの思索

同様に、「組織パターン」でも、第1・2章に書かれているパターンの考え方や動機に関する洞察がすごいと思う。
特に「2.1.2節 最高傑作の欠点」に書かれているプロセス中心主義への洞察は非常に鋭いと思う。
プロセス中心主義の欠点を彼は次の3つで説明している、と僕は理解している。

【1-1】実践とプロセス定義が経験的に擦り合わされていない。

多くのプロセスは振れ幅(変動、揺らぎ)が大きいため、プロセスを定義しようとしても、他のプロジェクトではプロセスを再現しにくい。
したがって、プロセスの典型的なシナリオがどれなのか、を関係者が合意しにくいのだ。
そんな事情があるために、プロセス中心主義の組織は、理想的なプロセス定義(ToBeモデル)を作り上げるだけでなく、理想的なプロセス定義(ToBeモデル)をベースラインにしてしまう。
それゆえに、プロセス定義モデルは、現場の個別の状況(コンテキスト・AsIsモデル)とかけ離れているために、各チームは現場で編み出されたプラクティスに自信を持てない。
せっかく暗黙知から実践知として生み出したプラクティスというノウハウが、プロセス中心主義では生かされないのだ。

この指摘は、ToBeモデルありきではなく、AsIsモデルから指向すべきであり、AsIsモデルを少しずつ継続的に改善する適応型開発が良いという主張につながる。
つまり、まずは試してみて、実践知を貯めていきながら、製品を作り上げていくという適応型開発の方がうまくいくのだろう。

【1-2】プロセス中心主義は、タスクやイベント中心に考えていて、プロセスモデルが不十分。

WF型開発は、工程における作業の品質を重視するために、作業の手順やイベント(レビュー、テストなど)を重視する。
タスクやイベントを重視する方向性は、プロセスの自動化と相性が良い。
実際、手順化できるということは、手続き型プログラムに近くなるので、自動化することでプロセスを再現しやすくなるからだ。

それゆえに、組織のもう一つの側面であるロールや成果物を軽視している。
しかし、むしろ、ロールはプロジェクトよりも安定している、と。
チーム構成における役割は、どんな種類のソフトウェア開発であれ、それほど大きな差はないはずだ。

多分、ロール指向のプロセスという発想から、Scrumのフレームワーク(PO・CSM・チーム)が生まれたのだろうと推測する。

スクラムの新しさ: プログラマの思索

実際、Scrumは、3つのロール、4つのイベント、3つの成果物のフレームワークと呼ばれている。

重要なテクノロジーは10名以下のチームで作られた ~ Innovation Sprint 2011(後編) - Publickey

【1-3】プロセスが長期に安定するように抽象化できていない。

プロセス中心主義は、手順や工程を重視したタスク指向になりやすいが、タスクの優先順位は頻繁に変わるため、タスクはプロセス構造上、安定した基盤にならない。
例えば、設計、実装、検証などの中核プロセスはタスクだけでは把握できない。
設計した通りに作ってみたら、実は技術上の問題や性能上の問題がテスト工程で判明して作り直した、などの例は枚挙がない。

そして面白いことに、開発チームのほとんどは、公式プロセスではなく、実は、プロセス定義が認める例外的なプロセスの下で作業していた。
多分その理由は、プロセス定義というToBeモデルが現場の実情とかけ離れているために、現場では常に例外的な状況におけるプロセスでしかToBeモデルを実現できないからだろう。

また、最近のソフトウェア開発は高度な並行開発であり、イテレーティブかつインクリメンタルな開発にならざるをえない。
実際の現場では、WF型開発のような、鎖のように一直線の工程で連なるプロセスとして定義できないのだ。

例えば、経験豊富なプロマネは、WF型開発を実施していると標榜していても、実は、裏プロセスとして、プロトタイプを先行開発しながら、顧客から引き出した要件やアーキテクチャを検証するプロセスを並行して走らせたり、大規模システムを分割して段階リリースするという並行開発の手法を取っている時が多い。
つまり、並行開発のプロセスが必要だが、そのモデルはプロセス標準が定義するモデルと違うことは、開発者もリーダーも実は自覚している。

裏プロセスは並行プロセス: プログラマの思索

しかし、並行エンジニアリングを採用する組織は、逆説的に、プロセス中心主義が定めるプロセス定義に忠実になろうとしていた。
むしろ、ロールを元にしたモデルの方が、タスクやイベント指向のモデルよりも安定しているがゆえに、現場のプロセスにうまく当てはまるのではないか、と。

この主張は非常に同感。
但し、並行エンジニアリングを採用する組織は、なぜWF型開発に忠実であろうとする行動に陥るのか、本文では読み取りにくかった。
おそらく、並行開発で成功した現場は、自分たちが生み出した実践知をプロセス標準モデル(ToBeモデル)の枠組みに反映させることで、自分たちの実践知の正当性を評価して欲しいという気持ちが暗黙的に表現されているのだろうと推測する。

【2】そのような背景を元に、組織を「正式な組織」よりも「インストゥルメンタルな組織」として捉える。
和智さんに聞いた所、「正式な組織」は部署のような形式的な階層構造で規定された組織に対し、「インストゥルメンタルな組織」は自然発生的に人が集まり、各メンバーにロールが割り当てられたチームのような組織という意味だそうだ。

ロール指向の組織である「インストゥルメンタルな組織」は、組織のタックマンモデルを連想させる。
つまり、組織が有機体として力を発揮するには、各メンバーで対立や混乱を経た後に、ロールが各メンバーにアサインされて安定したチームが形成されるのだろう。

Educate.co.jp | タックマンモデル

新たな習慣へのトライ タックマンモデルを体感する

コプリエンは、組織をロール指向で捉えるための手法として、CRCカードを使って、ソシオグラムやインタラクショングリッドでグラフ化する。
ロール間の結合度や凝集度をグラフや表で表現するわけだ。

その手法を使うことで、優れた組織はどんなロール間の特徴があるかを探りだす。
それが組織パターンになる。

彼の調査方法は非常に帰納的で、社会学みたいだ。
ボーランドとAT&Tの2つのグループしか対象にしていないという弱点があるけれども、組織パターンの内容は普遍性があるように直感的に思う。

【3】全般的な感想としては、各パターンが叙述的で、ちょっと読みづらかった。
下記の本にあるCoplienの論文のパターン形式のように「コンテキスト」「フォース」「解決策」「適用結果」「論理的根拠」によるカタログの方が分かりやすい。
組織パターン」の文章のうち、どれがコンテキストで、どれがフォースなのか、を理解するのが面倒だった。

和智さんに聞いた所、各パターンをカタログ化するよりも、パターンを組み合わせた全体像を主張したかったのでしょう、と聞いて納得した。
実際、「プログラムデザインのためのパターン言語―Pattern Languages of Program Design選集」と比較すると「組織パターン」では、パターンの関連図が章の冒頭に記述されていて、パターン同士の関連性が分かりやすく書かれている。

【4】「組織パターン」を読んでみて、プロセス改善はToBeモデルありきよりも、AsIsモデルから小さく継続的に改善する方向の方が成功しやすい、という感想を持った。
プロセス標準モデルというToBeモデルをベースラインにしても、現場のプロジェクトは変動が大きすぎて、適用しにくいのだ。
むしろ、個別の現場で実践知を貯めて、少しずつ改善していくボトムアップアプローチの方が良いのだろう。

でも、その指摘はユーザ企業の業務改善(BPR)のやり方と何となく違和感がある。
いわゆるERP導入で業務改革する場合、ERPというToBeモデルを一気に導入することで、ユーザ企業の組織構造そのものも変えてしまう。
ERP導入はトップダウンアプローチが普通。

システムで業務を自動化することで、人を減らし、コストカットできるメリットを活かす。
ERPで実現されている業界のベストプラクティスを導入することで、業務の効率化を目指す。
AsIsモデルを残すことは、逆に従来の非効率なプロセスを残してしまい、改革が中途半端になる。

DOAの優れたアーキテクトは、AsIsモデルは描かずにToBeモデルから始める。
その理由は、AsIsモデルに囚われ過ぎると、本来のあるべきシステム(ToBeモデル)が曖昧になってしまうから、と言っていたのを思い出す。

とはいえ、ERP導入は失敗事例が多い。
その理由はToBeモデルありきでは、現場のAsIsモデルから生み出された実践知を無視しているからだろう。
アジャイル開発が現代のソフトウェア開発プロセスとして成功しやすい理由の一つは、現場の実践知を大切にすることで、自然に、変化に富んだビジネスに対して適応型開発を実現できるからだろうと思っている。

| | コメント (0)

« 2013年7月 | トップページ | 2013年9月 »