« 2010年6月 | トップページ | 2010年8月 »

2010年7月

2010/07/31

Moodleインストールメモ

OSSのLMS(Learning management system)であるMoodleをXAMP上にやっとインストールできたのでメモ。
結構はまった。

【参考資料】
Moodle入門

Moodleを使って授業する!

Moodle1.5.3.pdf

【インストール方法】

XAMPのphp.iniで、cURL、opensslのextensionのコメントを外しておく。
又、php.iniで、memory_limit = 50M へ変更しておく。

XAMPPでcurlやopensslなどのPHPエクステンションを有効にする方法:phpspot開発日誌

下記からダウンロードして、XAMPのhtdocsへmoodleを配置

Moodle.org: Download standard packages

install.phpで、environment.xmlを取得している部分を絶対パスへ変更する。
この変更を行わないと、テーブル生成でエラーになる。

INSTALL MANIAX | Moodle

下記の手順に従って設定を進める。
必ず日本語パックのボタンを押下しておかないと、英語で設定されてしまう。

moodleをインストールする方法

コース設定画面まで来たら正常にインストール完了。
しかし、Windows上ではカレンダーが文字化けしている。
下記の手順でソースを修正すれば、正常表示される。

Moodle | お勉強の軌跡

【Moodleがもたらすもの】
下記を見ると、Moodleを使っている大学は多い。

Moodle 利用大学

大学ならば、先生もサーバー設定に強いだろうし、Webで授業の情報を一括管理できれば楽になるだろう。
下記のBlogでは、100人規模の授業において、Moodleのおかげで資料の配布や情報の伝達が楽になっただけでなく、100人の生徒のコメントを公開することで生徒が互いに刺激しあえるという利点も書かれている。

ある大学人のつぼやき: 大人数授業でMoodleを利用する

何よりも、研究者の観点から見れば、Moodleに貯まった授業に関する情報を分析して、教育学や社会学への研究に応用もできる。
Moodleには、授業の情報だけでなく、アンケートや小テスト、フィードバック、掲示板などの機能もあるので、貯まったデータを自作プログラムで集計すればいい。
教育に関する小集団のトランザクションにどんな傾向があるのか、分析すれば、教育に関する一つの知恵に昇華できるだろう。

実際、ネットを検索すれば、山のようにMoodleに貯まったDBを分析した資料や論文が溢れている。
大学の先生も、自分の研究目的にMoodleを使いたいのだろう。

OSSの業務系Webシステムには、世界中のユーザの要望から機能が実装されているから、その業務特有のベストプラクティスが隠れている。
色々調べてみたい。

| | コメント (2) | トラックバック (0)

SugarCRMの運用サイクル

実践!オープンソースCRMアプリケーション入門 (ネクストエンジニアSELECTION)」を読んで、SugarCRMの運用サイクルがようやく分かったのでメモしておく。
#あくまでも僕の理解に過ぎないので、誤りがあるかもしれない。

SugarCRMはOSSのCRM。
顧客管理システムゆえに、いわゆる営業支援のソフトに近い。

営業のプロセスはどの会社であっても、下記のフローに集約される。


集客と集まった見込み客リストの整備

見込み客リストへのアプローチの順番の優先順位付け

見込み客へのアプローチ

提案や見積もり

クロージング

販売後フォロー

SugarCRMは営業フローを一通り支援する機能を提供しているようだ。
SugarCRMの運用サイクルは下記になる。

まず、SugarCRMではターゲットリストを作成する。
ターゲット(見込客)のリストを作成し、製品やサービスの提供を行うマーケットを決める。
SugarCRMでは、既存の取引先やリード、新規顧客を選んで選択することになる。
この作業はマーケティング担当者が、市場調査を行って、戦略を決定してから行う時が多いだろう。

次に、キャンペーンを作成する。
キャンペーンとはターゲットリストに対する集客であり、見込客へアプローチをかける準備を行う。
電子メール、ニュースレター、電子メール以外のキャンペーンの3種類から選ぶみたい。
自社から顧客へ営業やニュースレターを送るアウトバウンドメールも集客に含まれるだろう。
もちろん、大ホールを借りてイベントを開催して集客する時もある。

電子メール - SugarCRM日本語ドキュメントプロジェクト

そして、リードを生成する。
リードとは、マーケティング部門に到達した潜在顧客であり、メールやニュース、Webなどから自社製品に興味を持ってくれた顧客を指す。
リードソースは、リードがアプローチをかけたチャネルを指す。
例えば、メールやWeb以外にも、既存客、飛び込み、自己生成などがある。
リードソースはチャネルであるから、ビジネスフレームワークの4Pのプロモーションに当たる。

リード - SugarCRM日本語ドキュメントプロジェクト

リードは、SugarCRMの中でも重要な概念。
リードソースを分析することによって、新規顧客の候補に効率的にアクセスできるルートを探せる。
営業マンならば、普通に飛び込み営業で新規顧客に足を運んでも100人中3人しか、お話させてもらえない。
リードの確率を上げることが営業では重要。

マーケティング担当者はリードへ営業マンをアサインし、営業マンはリードに営業しに行く。

営業マンにアサインされたリードは取引先になる。
SugarCRMでは、取引先に顧客の会社情報、取引先担当者に実際の担当者情報を設定する。

取引先 - SugarCRM日本語ドキュメントプロジェクト

営業マンは取引先へ提案は販売などの商談を行う。
SugarCRMの商談には商談ステージというステータスがあり、その商談が今どんなステータスか、そして最終的にどんな結果になったのか、を管理できる。

商談 - SugarCRM日本語ドキュメントプロジェクト

営業マンは受注を目指すが、当然、失注するときもある。
商談で履歴を残すから、失注した原因も後で分析できるから、その後の営業活動にフィードバックできる。

SugarCRMでは、コール、ミーティング、タスク、ノードなどの機能を使って、営業のタスクや活動を管理していくみたい。

そして、見積もりして、最終的に契約して受注する。
これがクロージングに相当する。

しかし、OSSのSugarCRMでは、見積もり・受注・売掛金の回収・請求書の発行などの契約管理の機能がない。
プラグインや商用機能で提供しているらしい。
OSSではこの機能がないので、営業でもっとも重要なプロセスはフォローできてない。

最後に、契約して販売した後の顧客へフォローアップする。
最近のビジネスを見ると、フォローアップがうまく管理出来ていないと、クレームで評判を落としたり、逆に顧客から訴えられる危険もある。

SugarCRMでは、まずケース管理で顧客からの質問、要望、問い合わせを管理する。
つまり、ケースで顧客からの対応履歴を残し、履歴を分析して、クレームの原因を突き止めたりしたりする。
BTSチケットに似たような機能だ。

ケース - SugarCRM日本語ドキュメントプロジェクト

また、受注して受託開発を開始したら、1個のプロジェクトでタスク管理を行いたくなる。
SugarCRMには、簡易のプロジェクト管理の機能もあるみたい。

プロジェクト - SugarCRM日本語ドキュメントプロジェクト

また、社外からの問い合わせ窓口を担当しているカスタマーサポート部門は、SugarCRMのインバウンドメール機能を使うと便利だろう。
インバウンドメールは、info@で始まる問い合わせ用のメールアドレス。
Wikiの解説が詳しい。

インバウンドメール - SugarCRM日本語ドキュメントプロジェクト

(中略)
これらの電子メールアドレスは sales@example.com などのように部門を表す一般的なメールアドレスになっていて、そのアドレスを1人以上の担当者で共有し、インバウンドの電子メールで寄せられた問い合わせに対応しています。
かつて、問い合わせがほとんど電話であったころ、電話はほとんどの場合に一対一の会話になるので、誰が問い合わせに対応しているか、また、誰が折り返しの電話をしなければならないかは簡単に決まっていました。
しかし、電子メールは複数の担当者が同時に受信することが多々あるので、誰がどの問い合わせの担当なのか、また、誰がどの問い合わせに回答したかを厳密に管理することが非常に難しいのです。
SugarCRM 4.0では、このような対応履歴管理の難しいインバウンドメールの管理を効率的に行うことが出来ます。


セールスフォースや他の会社の商用CRMも、SugarCRMに似たような機能を持っている。
OSSだから、各種のプラグインはハックもあるみたい。

OSSの業務支援ツールは、RedmineやTrac、TestLinkのように、その分野特有の概念を機能へ昇華してくれているので、使い方に慣れると自然にスキルアップできる。
OSSの業務支援ツールの機能には、その業務のベストプラクティスそのものが含まれているからだ。
現状の業務をそのままシステム化するよりも、このようなツールを導入して改善する方が中小企業の場合は良いのかもしれない。

色々試してみると面白いと思う。

| | コメント (0) | トラックバック (0)

2010/07/29

プロジェクトファシリテーションに足りないもの

プロジェクトファシリテーションに足りないもの。
それは、分散した環境におけるチームやメンバーの間のコミュニケーション方法。

現代では、地理的に離れたチーム同士で開発する場合が多い。
オフショア開発がいい例だろう。
その場合、どのようなコミュニケーションを取れば、チームとして有機的に動くのか?

本来、プロジェクトファシリテーションはアジャイル開発をバックボーンとして、チームビルディングの一手法として生まれた。
つまり、一つの小規模なチームでどのようにコミュニケーションを取って、チームを形成するか、という点に力点が置かれていた。
従って、地理的に離れたチームやメンバーがどのようにコミュニケーションを取ればいいのか、という問題意識はそもそもなかったように思う。

現代のソフトウェア開発は、日本と中国、東京と地方、などのように地理的に離れたチームを形成して開発する時が多くなった。
そういう環境はアジャイル開発に適さない、プロジェクトファシリテーションに適さないと言っても、時流はその方向に向いている。
たとえ一つのビルの中にプロジェクトがあっても、プロパーとパートナーのように、コンプライアンス上、部屋に分かれて仕事せざるを得ない場合もある。
オープンソース開発でも、開発者が日本とアメリカで分かれていれば、同じ状況だ。

従って、物理的に離れた空間で共に開発するために必要なコミュニケーションとは何か?という問題点が出てくる。
そして、大規模プロジェクトになるほど、分散開発は当たり前になる。

分散開発では、対面や口頭のコミュニケーションよりも、書いたものによるコミュニケーションの方が断然大きくなる。
入門Gitの「パッチベースのワークフロー」の章では、メールによるやり取りの注意点が詳しく書かれている。
それも一つのコミュニケーション方法だろう。

だが一番知りたいのは、プロジェクトファシリテーションが編み出した朝会、KPT、ふりかえり、ニコニコカレンダー、バーンダウンチャートなどのプラクティスを、分散したチーム環境へ応用できないのか?

- プロジェクトファシリテーションTOP

多分、そこにはツールが必須。
Wikiによる情報共有。
SkypeやWebカメラ、UStreamなどでのコミュニケーションの同期。

いろんなアイデアを試してみたい。

| | コメント (1) | トラックバック (0)

2010/07/28

エンタープライズアーキテクチャというバズワード

エンタープライズアーキテクチャについてInfoQに懐疑的な記事があったのでメモ。

【元ネタ】
InfoQ: アーキテクチャの戦略と原理

エンタープライズアーキテクチャ - Wikipedia

ビジネスモデルをIT化する、あるいは、業務をIT化する際に、ビジネスの戦略的観点から設計し直したら、エンタープライズアーキテクチャ(EA)に行き着くだろう。
しかし、その姿を実際に見た人はいるのだろうか?

業務分析や要件定義は、EA、SOA、BPR、ERPというバズワードに埋め尽くされて、肝心のモデリング技法やモデリングのパターンが十分に使いこなされているとは言えない。

しかし、実は日本独自のモデリング技法が発達していて、OOAのドメイン分析と実は肩を並べている。
その名はDOA。
梅田弘之さん著「グラス片手にデータベース設計~販売管理システム編 (DBMagazine SELECTION)」と渡辺幸三さん著「業務別データベース設計のためのデータモデリング入門」「生産管理・原価管理システムのためのデータモデリング」は僕も読んでみて、浅海さんの言う通り、内容はとても優れていると思う。

ドメイン・モデル - 浅海智晴プログラマ日記

(中略)
ドメイン・モデルに関する分野は和洋問わずデータ・モデリング系の情報が充実している。さらに、日本製の本が第一級の情報を提供しているという点でも、ソフトウェア技術の分野としては特異である。
世界と戦うという意味で、理論系では弱いものの、現場の実践が強い、という他の技術分野と同じような傾向になっているようである。また、大小織り交ぜてさまざまなシステム開発を長期間行ってきた日本の産業界の底力と考えることもできるだろう。
(後略)

忘れ去られた日本のIT技術~DOAと品質管理: プログラマの思索に書いたけれど、日本発の優れたIT技術を日本人自身が忘れている。
もう一度、見直してもいいのではないだろうか?

| | コメント (0) | トラックバック (0)

2010/07/26

ビジネスパターンによるモデル駆動設計

ビジネスパターンによるモデル駆動設計」を立ち読みした時の感想をメモ。
ラフなメモ書き。

【元ネタ】
第3回 分析やビジネスモデリングのためのソフトウエアパターン | Think IT

REAとビジネスパターン入門(1) - 要求開発アライアンスのビジネス・モデリング道場:ITpro

REAとビジネスパターン入門(2) - 要求開発アライアンスのビジネス・モデリング道場:ITpro

REAとビジネスパターン入門(3) - 要求開発アライアンスのビジネス・モデリング道場:ITpro

REAとビジネスパターン入門(4) - 要求開発アライアンスのビジネス・モデリング道場:ITpro

OOAと言えばドメイン分析。
概念モデルをクラス図で書きながら、ビジネスを分析していくスタイルが王道。
僕もいろんな本を読んできたけれど、結局使いこなせていない。

ビジネスパターンによるモデル駆動設計」にあるパターンは、確かに面白いけれど、「アナリシスパターン」に比べると奥が浅いように感じた。
ビジネスパターンによるモデル駆動設計」の発想は、悪く言えば、T字形ERと勘定パターンの組み合わせに過ぎない。

モデルの対象をR(Resource:資源)、E(Event:イベント)、A(Agent:エージェント)というモノ・コト・ヒトに分ける発想は、T字形ERのイベントとリソースの拡張版。
ビジネストランザクションが経済リソースの交換であり、片方が増加すれば、片方も増加ないし減少するという発想は、簿記の仕訳そのものであり、そのモデルはアナリシスパターンに出てくる勘定パターンで表現できる。

モデリングは単なる分析ではなく、その過程でそのビジネス特有のビジネスルールを抽出していく所が腕の見せどころで面白いのであるから、その部分をもっと見せて欲しいのだ。
だが、そこまで詳しく書かれていないように感じた。

むしろ、業界ごとにモデルのパターンを羅列してくれる方がはるかに役立つのに。

アナリシスパターンに出てくるモデルは確かに優れているし、なるほどと思わせる。
だが、OOAは詳細設計から開発の部分はとてもスムーズで、書いていて楽しいけれど、要件定義やそれ以前の業務分析では、声高に叫ばれているほどの実績がないように思う。
色々調べてみたい。

| | コメント (1) | トラックバック (0)

Redmine Theme Changerプラグイン

HaruさんがRedmine Theme Changerプラグインを昨日公開されていたのでメモ。

【元ネタ】
Twitter / MKinside: Redmine Theme Changer導入!素晴らしすぎる…。テーマをコツコツため込んでおいた良かった。後輩と作ったテーマが一番好きだけど、たまに変えて気分転換するようにしよう。

Haru's blog: Redmineのプラグインを新たに2つ作りました。

r-labs - Theme Changer - Redmine

Redmineのテーマをユーザ毎に設定できるのが素晴らしい。
僕はデフォルトのテーマが好きだが、Tracのような色合いが好きな人もいれば、Mantisのような色合いが好きな人もいる。
テーマを変えるだけでもモチベーションが上がる。

RedmineはCSSを変えるだけで簡単にテーマを変えることもできる。
日本語環境で使い易いテーマもあるらしいので、色々試してみたいと思う。

Redmine - Theme List - Redmine

日本語環境で読みやすいRedmine用テーマ「farend basic」公開 | Redmine.JP Blog

| | コメント (0) | トラックバック (0)

2010/07/25

ドメイン駆動設計

ドメイン駆動設計に関する良い資料があったのでメモ。
InfoQにログインすれば、概要をダウンロードできる。

【元ネタ】
InfoQ: Domain Driven Design(ドメイン駆動設計) Quickly 日本語版

無料で読めるDomain Driven Designの概要

上記は「Domain-Driven Design: Tackling Complexity in the Heart of Software」に関する概要資料。
「はじめに: なぜドメイン駆動設計なのか」の節でなるほど、と思った。

マーチン・ファウラー の「エンタープライズ アプリケーションアーキテクチャパターン (Object Oriented Selection)」によれば、オブジェクト指向による実装は本来、テーブルモジュールでもなく、トランザクションスクリプトでもなく、ドメインモデルにある。
つまり、OOAの本領は、ドメイン分析にある。

しかし、2000年代前半は、オブジェクト指向分析の花盛りだったが、実際の開発ではそれほどOOAを使わなかった。
何故なら、EJB、SOAなどのバズワードに侵されて、本来のオブジェクトを分析する風潮ではなかったから。

そして、今もオブジェクト指向分析は普及したとはいえ、日本ではそれほど認知されていないように思う。
RUPは確かに優れているのかもしれないが、日本では反復型開発というよりもウォーターフォール型開発の一つみたいだ。
あまりにもドキュメントが多すぎて、大型タンカーを操縦しているような雰囲気。

OOAに関する書籍は良い本がいくつかある。
アナリシスパターン―再利用可能なオブジェクトモデル (Object Technology Series)」をもう一度読み返してみて、図はUMLでないので分かりにくいけれど、モデリングの試行錯誤が分かりやすかった。

でも、OOAは要件定義以後の詳細設計や開発ではとてもスムーズだが、要件定義や業務分析ではあまり威力を発揮しないように経験上感じる。
UMLは詳細設計における分析ではピカイチだが、要件定義やビジネスモデルを描くプロセスでは、使いにくいし、本来のイメージを描ききれない。

OOAはAgile開発と密接に関係するし、アジャイラーは優れたモデラーもあった。
だが、要件定義や業務分析は、日本独自のDOAの方がいいのではないか、と思ったりもしている。

そんなことを思っていて、最近、OOAに懐疑的になっている。
要件定義や業務分析のプロセスでは、UMLやOOAが役立たない。
そして、アジャイル開発もうまく機能していない。
色々試行錯誤している。

| | コメント (0) | トラックバック (0)

費用や生産性のメモ

大前研一が、英語・IT・財務がサラリーマンの三種の神器と言っている。
特に財務について、考えたことをラフなメモ書き。
#初歩的な内容なので注意。

【元ネタ】
はじめての財務管理

決算診断情報:決算診断「第14回 損益計算書のカンタンな見方(3)」

決算診断情報:決算診断「第33回 経営分析解説―生産性(1)」

付加価値

付加価値のつかみ方(分析ポイント講座⑦): salon tamaken

N's spirit 損益分岐点とは 損益分岐点分析とは CVP分析とは

IT技術者ならば、英語とITは日頃からたぶん慣れている。
でも、財務だけは取っつきにくい。
財務とは業務知識の元ネタであり、簿記を知らなければ理解できないだろう。
普通は、簿記3級程度の知識は必須であり、簿記2級の商業簿記まで理解しなければ、実際の株式会社の業務フローは、最終的にモデリングできないだろうと思う。

簿記を習得した後、業務モデリング以外に、その知識はどのように使えばいいのか?
もし管理職、経営者ならば、実際の会社の財務マネジメントに使えばいい。

財務マネジメントの基本と原則」を読んで、BS・PL・CSをこの本のように使えば、その会社の財務体質が分かるようになる、という雰囲気を受けた。
まだきちんと読めていないので、分かった部分だけメモしておく。

IT企業もPL・BS・CS、会社の属性情報はHPなどで公開されている。
それらを見ると色々分かる。

下記の公式で考えてみよう。

【1・費用のマネジメント】
・限界利益=売上高-変動費(≒固定費)
・限界利益率=(売上高-変動費)/変動費
・損益分岐点売上高=固定費/限界利益率

費用のマネジメントの観点は、会社にとって最適な費用構成は何か?という点。
営利企業である限り、利益がでないビジネスはありえない。
だから、損益分岐点が低いほど、利益が出やすくなる。

損益分岐点が低い傾向、限界利益率が高い傾向、限界利益が低い傾向がいいわけだから、固定費はゼロに近い傾向、変動費が費用に占める割合が高い傾向の方が、利益が出やすくなる。
つまり、変動費主体の会社は固定費主体の会社よりも、低い売上で利益を出しやすくなる。
実際、利益=0の場合、限界利益=固定費となるから、固定費以上の売上を上げなければ、利益が出ないことになる。

固定費は工場などの設備コスト、社員の人件費など。
例えば、普通のIT企業ならば、サーバーやPC等の機器の減価償却費、データセンターのコスト、社員の人件費だろう。

変動費は営業や製造に関わるコスト、外注費になる。
例えば、ITプロジェクトに関わった経費、下請けの会社にソフトウェア開発を外注した費用になるだろう。

財務マネジメントの基本と原則」には、家具販売ビジネスの例がある。
家具販売ビジネスを始めたとき、工場や店舗や店員を用意したら、利益を出すにはまずその固定費以上の売上を稼がなければならないから、ハードルは高くなる。
しかし、家具製造を外注し、インターネットで販売すれば、固定費をぐっと下げられるので、利益が出やすくなる。
インターネット企業のハードルが低いのはそういう理由があるからだろう。

【2・生産性のマネジメント】
・付加価値=売上高-変動費
・付加価値率=付加価値/売上高
・損益分岐点売上高=固定費/付加価値率
・一人当り付加価値=付加価値/従業員数

生産性のマネジメントの観点は、会社の生産性はどれくらいなのか、という割合。
社内の管理職、経営者はこの付加価値を重要視する。
管理会計の一部とみなしてもいいかもしれない。

付加価値は売上高-変動費なので、売上を増やし、変動費を減らせば増える。
付加価値が多いほど利益が出やすい体質であり、会社の勢い(生産性)が高いことの証でもある。

例えば、IT企業ならば、たくさんのプロジェクトを請け負って、プロジェクトの経費をとことん減らせば、付加価値は上がる。
売上はそう簡単に増えないから、内部でコントロールしやすい変動費を減らす方向に走る時が多い。
変動費を減らす最大の方法は、自社で作らず、外注して費用を減らすこと。
あるいは、社員のマネジメント力や技術力を高めたり、一人の社員が複数プロジェクトを掛け持ちで作業させること。
だからIT業界は厳しいのかもしれない。

売られている本を読んだ知識、何となくの経験から言うと、一人当たり付加価値は1500万円、一人当たり売上高は1000万円以上の会社でなければ、たぶん赤字になっている。
実際、普通の中小のIT企業は、この数字近辺にいるから、利益がほとんど出ない。
マイクロソフトが凄かった時期は、一人当たり付加価値や一人当たり売上高は7000万円以上あったように記憶している。

普通のIT企業は固定費が少なく、変動費主体のはずなので、社員の技術力やマネジメント力を高めれば、理論上は高い付加価値を稼げるはずだと思う。

| | コメント (3) | トラックバック (0)

2010/07/24

Hinemos+Redmine for ITILで運用保守を改善する

Hinemos+Redmine for ITILのセミナーが東京であるみたい。

【元ネタ】
セミナー「コスト削減できる!監視運用業務の効率化」 ~コストを抑えてITILに準拠した統合運用管理を始めましょう!~ - イベント情報 - ZDNet Japan

Redmine for ITILの特長|ホロンテクノロジー[Holon Technology]--サービス&ソリューション--

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

Hinemosと言えば、OSSの統合監視ツール。
サーバーのジョブ管理、サーバー監視機能を持つ。
IBMのTivoliみたいなもの。

Hinemos+Redmine for ITILのイメージは、Hinemosで検知した障害(インシデント)をRedmine上で追跡できるようにし、そのワークローはITILで運用するということだろう。

Redmineはメールを送信したらチケットを登録する機能もあるし、Ver1.0からREST APIもサポートしているから、Hinemosのような監視ツールでRedmineのチケットを登録したり更新することも原理的にできる。
つまり、HinemosがRedmineというBTSをキックするわけだ。

Redmineのチケットでインシデントを追跡するようにすれば、Redmineの優れたチケット集計機能で、好きなように障害を分析できる。
インシデントや障害の傾向分析が行えれば、Redmineは強力なツールになるだろう。
どんな時間帯に障害が多いのか、どんな種類のインシデントが多いのか、という傾向が分かれば、抜本的な対策をとることもできる。

Redmineはアジャイル開発のツールだけでなく、サーバー運用保守のサポートも可能だ。
上記の会社はRedmine for ITILの運用ノウハウを持っているのだろうから、実際に聞いてみたいものだ。

| | コメント (0) | トラックバック (0)

2010/07/22

アジャイル開発とソフトウェアアーキテクチャの緊張関係

アジャイル開発の発想を上流工程へ応用できないか?
アジャイルモデリングは、モデリングにアジャイルの概念を注入できるのか?

【元ネタ】
アジャイルモデリング(AM)ホームページ

アジャイル・モデリング (AM)

モデリングを突き詰めると、ソフトウェアアーキテクチャにぶち当たる。
ソフトウェアアーキテクチャは目に見えないが、何らかの秩序がある。
デザインパターン、パッケージの原則などもソフトウェアアーキテクチャに含まれる。

しかし、「システムアーキテクチャ構築の原理 ITアーキテクトが持つべき3つの思考 (IT Architects’Archive ソフトウェア開発の実践)」の第7章「アーキテクチャ定義プロセス」によれば、ソフトウェアアーキテクチャとアジャイル開発には緊張関係がある。
つまり、アジャイル開発者とソフトウェアアーキテクトの間には緊張関係がある。

アジャイル開発の本質である小規模リリースと、ソフトウェアアーキテクチャを作りこんだ後に大規模開発に着手するやり方は相反しているということ。

だが、XPを生み出したKent BeckやMatin Faulerなど見れば、彼らは一流のモデラーだ。
何故彼らは、アジャイル開発とソフトウェアアーキテクチャの緊張関係に遭遇しなかったのか?

もう少し考えてみる。

| | コメント (2) | トラックバック (0)

2010/07/19

Redmine 1.0.0 released!

ついに待ちに待ったRedmine 1.0.0 がリリースされた。

【元ネタ】
Redmine - Redmine 1.0.0 released - Redmine

Twitter / Eric Davis: Redmine 1.0... today

Twitter / Eric Davis: Redmine 1.0.0 released

Redmine 1.0.0(RC) リリース | Redmine.JP Blog

Redmine 1.0のCHANGELOG (日本語訳付き) | Redmine.JP Blog

目玉の機能は、チケットの親子関係とREST APIサポート。
チケット駆動開発を進化させる上で重要な機能やバグ修正が他にも沢山盛り込まれている。
主要なプラグインも早くVer1.0に対応して欲しいと思う。

リリースニュースに書かれたEric Davisのコメントが素直でとてもいいと思う。
コミッタがJean-Philippe LangからEric Davisに変わった(みたいに見える)ことにも関係しているのだろうか?

Finally, I personally wanted to thank everyone who has helped Redmine over the past four years. Without everyone's contribution, the project wouldn't be as awesome as it is now. Thank you.

(超翻訳)
最後に、個人的に、過去4年間Redmineを支援してくれたすべての人々に感謝したいと思う。
皆さんの貢献なしでは、このプロジェクトは今ほど素晴らしくならなかっただろう。
Thank you。

| | コメント (0) | トラックバック (0)

2010/07/18

今後のアジャイル開発の方向性

アジャイル開発が銀の弾丸ではない。
むしろアジャイル開発を実践すると、ソフトウェア開発特有の難しさがはっきり出てくるように思う。
ラフなメモ書き。

【元ネタ】
InfoQ: アジャイルプロジェクトが遅れる理由

InfoQ: アジャイルにおけるプロジェクトマネジャーの役割

Agile2.0は何を解決しようとしているのか?: プログラマの思索

第二期アジャイルムーブメント ~ アジャイル開発の商業的取り組み と Agile2.0 ないし 「2週目の世界」 について - kawaguti の日記 (id:wayaguchi)

今は「Agile2.0」「2週目のアジャイル」と呼ばれる時期に到達している。
初期のアジャイル開発で克服できなかった課題、アジャイル開発のアンチパターンなど、各種の知識も増えてきた。

Agile2.0では、Scrumのようにプロジェクトマネジメントを強化する方向もあれば、チケット駆動開発やツールベンダーの注目のようにアジャイル開発の環境ツールでを強化する方向もある。
それらの背後には、アジャイル開発のスケールアップという動機があるように思う。

初期のアジャイル開発では、少人数のチームでアジャイルに開発スタイルを実践して、その利点は色々知られてきた。
しかし、チームやシステムが大規模化するとアジャイル開発の恩恵が受けにくい弱点は、アジャイル開発が生まれた当初から言われ続けてきた。

その流れを見ると、ソフトウェア工学が生まれた頃に、プログラミングをプログラマの職人芸からプログラマのチームによる開発へスケールアップしていった方向に何となく似ている。
チームやシステムを大規模化しようとすると、もう一段上のハードルを乗り越えなくてはならない。

その現象は、分割統治やオブジェクト指向でモジュール単位の開発の生産性が上がったとしても、モジュールを組み合わせると性能やセキュリティなどの非機能要件に絡む問題が出てくるように、大規模化して初めて現れてくる問題にも似ている。

下記にあげた資料や書籍を読んでみると、従来のAgile開発では解決できなかった課題、そしてそれらを乗り越えようとする可能性について、ヒントが沢山ある。
整理してみたい。

Agile2.0時代で必要な技法を示唆している資料: プログラマの思索

Agile2.0時代のAgile開発が目指す方向を示唆する書籍: プログラマの思索

| | コメント (0) | トラックバック (0)

2010/07/17

アート・オブ・プロジェクトマネジメントを読み直してTiDDを補強する

アート・オブ・プロジェクトマネジメント」を読み直して、チケット駆動開発を運用した経験から、そうだよ!と何度も頷くところがあった。
ラフなメモ書き。

【元ネタ】
「 アート・オブ・プロジェクトマネジメント」の検索結果1 - 脱・下流エンジニア (仮)

「 アート・オブ・プロジェクトマネジメント」の検索結果2 - 脱・下流エンジニア (仮)

【12章 リーダーシップが信頼に基づく理由】

「表明」とはコミットメント、約束を意味する。
メンバーが表明することによって、小さな約束が積み重ねられて、一つのシステムが完成する。

チケット駆動開発では、チケットファーストの原則に表明の概念が組み込まれている。
プロジェクトで発生する全ての作業は、チケットに起票してから開始する。
WBSから起こされたタスクも、突発的な事件によって発生したタスクも、まずチケットに起票する。
そのチケットには、開始日と終了日、そして担当者が必ずアサインされている。

チケットを見れば、誰が何をしているのか、誰でも分かる。
開発者がチケットを担当して作業していることをプロジェクトリーダーも信頼しているし、そのアウトプットが納期通りに高い品質であることを期待している。
逐一進捗報告をもらわなくても、Redmineの優れたチケット集計機能によって、リアルタイムに知ることが出来るからだ。

チケットでタスクを見える化することは、単にプロジェクトの風通しを良くすることだけではない。
チケットをこなしていくことによって、プロジェクトリーダーとメンバーの信頼関係を育むのだ。

【13章 ものごとを成し遂げる方法】

アート・オブ・プロジェクトマネジメント」の中で僕が好きな章の一つだ。
この章は「優先順位は力なり」の言葉で集約されている。

「優先順位付けによって物事が成し遂げられる」という言葉は、チケット駆動開発を経験して実感する。
実際のプロジェクトでは、コロコロ変わる顧客の要望、仕様変更や突発的なタスクによって、優先順位はコロコロ変わる。
駄目なプロジェクトリーダーは、今何を優先すべきか、という判断材料を持っていないから、決断できない。

Redmineならばロードマップこそが、そのチームの優先順位付け一覧に相当する。
ロードマップは単なるリリース計画だけではない。
そのチームの意思決定の源。
直近のバージョンでリリースするには、いつまでにどんなタスクをこなさないといけないのか、がロードマップで一目で分かる。

この優先順位一覧表は、目標・機能・作業項目などの観点に別々に作られる。
Redmineならば、チケット一覧は、ロードマップ・ガントチャート・カレンダー・サマリ・変更記録など各種のチケット集計画面に表示できるから便利。
各種のチケット集計画面を見ながら、プロジェクトリーダーは、優先順位を決めていくのだ。

プロジェクトリーダーの最優先の仕事は、ロードマップの作成とその最新化にある。
チームの羅針盤がロードマップ。
その羅針盤は状況で頻繁に変わるために、チケットの作業順序を入れ替えたり、チケットを捨てたり、チケットを変更・追加したりして、状況をロードマップへ反映する。
このチケットの取捨選択こそが、マネジメントそのものになる。

「PMは優先順位付けマシンとなるべし」とは、プロジェクトリーダーの仕事は、ロードマップを見ながら、チケットを取捨選択して、チームの方向性を提示することを意味している。

すると、チケットの作業順序からクリティカルパスが見えてくる。
クリティカルパスにあるチケットを抑えれば、優先順位の低いチケットは自ずから解消される。
個人的には、Redmineにクリティカルパスを計算するプラグインがあればいいだろうなと思う。

【14章 中盤の戦略】

この章も「アート・オブ・プロジェクトマネジメント」の中で僕が好きな章の一つだ。
プロジェクトが立ち上がり、ある程度進行している状況でのマネジメントが書かれている。

「飛行機の前方を飛行する」とは、戦闘機のパイロットが一歩か二歩先を読みながら操縦すること。
突発的な仕様変更やリスクによって、プロジェクトはすぐに傾く。
だから、その慣性力に負けないように、早めに手を打つ必要がある。

チケット駆動開発では、この作業はロードマップの最新化の作業に相当する。
イテレーションをバージョンに見立てて、現在作業中のバージョンだけではなく、その一つ二つ先のバージョンのチケットも見ながら、先手を打つのだ。
チケット駆動開発ならば、イテレーション単位にバージョンをリリースできる。
ウォーターフォール型開発ならば、段階リリースに相当するだろう。

この章で重要な言葉は「コーディングパイプライン」。
UnixのPipeのように、複数の担当者が連携して作業することを示す。
設計者が設計書を用意して、開発者が設計書に従ってコーディングし、テスターがそれをテストする。
このパイプラインがスムーズに流れるように、プロジェクトリーダーはあらかじめ準備しておく。

コーディングパイプラインは、Redmineの優れたワークフロー管理機能によって、意識しなくても、チケットの作業状態によって自動的に置き換わる。
駄目なプロジェクトは、このワークフローのバリエーションが少なすぎてチームが回らなかったり、逆に多すぎて混乱する。
コーディングパイプラインは、バグ修正と検証のワークフローにもなる。

「表明を破棄する」は、状況によって以前約束した作業を変えることを意味する。
チケット駆動開発ならば、チケットの見積もりよりも工数がかかった場合、チケットを分割したり、担当者を入れ替えたりするだろう。
この作業は、変更管理につながる。
「変更のマネジメント」はPMBOKやITILの変更管理で既に具体化されている。
そのフローをチケット駆動開発上で実現すればいいだろう。

「動いている標的を狙う」はまさに「変化を抱擁せよ」。
最初に作ったロードマップ(計画)がその後も変わらないことはありえない。
むしろ、状況に応じてロードマップも変えていく。
だからと言って、ロードマップ(計画)は不要ではない。ロードマップはチームの羅針盤だから。

実際のプロジェクトでは、リスクを見つけたものの、現時点では優先順位が低い場合がある。
でも、後になったら、そのリスクが大きくなるかもしれない。
だから、そのリスクは課題として一旦チケットへ登録しておき、後のイテレーションでそのチケットを作業すればいい。
チケット駆動開発では、チケットという単位は作業だけでなく、リスクとして扱える。

【15章 終盤の戦略】

この章も「アート・オブ・プロジェクトマネジメント」の中で興味深い章の一つだ。

「大きな期限は小さな期限の集合体にすぎない」とは、「最終リリースは小さなイテレーション単位のリリースの積み重ね」を意味している。
XPの小規模リリースを実現していれば、リリースをこなすたびに品質も使い勝手も向上していく。

終了条件の定義は、リリース判定条件でもある。
Redmineによるチケット駆動開発ならばその条件は明確だ。
「バージョン(イテレーション)に属する全てのチケットが100%で終了したこと」になる。
Redmineのロードマップを見れば、バージョンが100%であるかどうかはすぐに分かる。

プロジェクト終盤になると降下速度の調整が重要になる。
残作業がたくさんあるのに急角度で終わらせようとすれば、メンバーに負荷をかけることになる。
かといって、納期が迫っているのに、のんびり作業することもできない。

降下速度の調整では、Velocity(チームがタスクをこなす速度)が重要になってくる。
Velocity以上のスピードでチームがタスクをこなすのは無理。
Redmineで、チケットに予定工数をきちんと入力する運用をしていれば、Velocityを計算出来るし、どれだけのチケットをこなせるのか、判断する材料になる。

この時期では、残ったチケットを今のバージョンに含めるのか、次のバージョンで対応するのか、精査する作業が重要になる。
そして、その作業は顧客の合意を取る必要もある。
プロジェクトリーダーの政治力が問われる時期でもある。

バグのマネジメントは、まさにBTSによる障害管理そのものだ。
駄目なチームは、バグを番号で管理していないために、無駄なコミュニケーションロスが生じる。

そして、BTSに貯まったチケット数から、アクティブ(未完了)なバグ数を累計すれば、アクティビティチャートを出力できる。
残バグ数はバーンダウンチャートに相当するだろう。
全バグ累積数を時系列に出力すれば、バグ収束曲線になるだろう。

これらの指標の利点は、まだやるべき作業があるのか、あるいは、やるべき作業はもうすぐなくなるのか、傾向が分かること。
ハードウェアの信頼度成長曲線のように綺麗な図にならないだろうが、バグが収束しつつあるのかどうか、傾向を知ることはできる。

アート・オブ・プロジェクトマネジメント」で面白いのは、いくつかの指標が書かれていること。
「バグ修正のペース」は修正率、つまりMTTR(平均修復時間)に相当する。
修正率がバグ発生率よりも高ければ、バグはどんどん減っていくはず。
MTTRを短くするには、元々のプログラムの保守性を良くしておくとか、コーディングパイプラインを上手に流用するなどがあるだろう。

「発生されたバグと承認されたバグの数の比率」も興味深い。
「発生されたバグ」は、テスターが発見したバグ。
「承認されたバグ」とは、「発生されたバグ」を分析して、同種バグをまとめたり、仕様そのもので正しいバグなど、判断を下したもの。
バグの分析では、類似のバグを見つけて、同種バグを徹底的に洗い出すのが重要。
ゴキブリ退治のように、卵から潰さなければ、何度も同じようなバグが出てしまうからだ。

「バグがアクティブになっている期間」とはバグの残存期間。
バグの残存期間が長いほど、発見して直すのが難しくなる。

「開発者あたりのバグ数」とは、開発メンバーの作業負荷の分散に関連する。
一人のメンバーにアクティブなバグが集中していると、コーディングパイプラインが停滞する原因になる。
だから、定期的にバグのトリアージを行って、作業負荷を下げる必要がある。

「欠陥フィードバック率(FFR:Fault Feedback Ratio)」とは、バグ修正によって引き起こされるリグレッション率。
1個のバグ修正で2個のバグが引き起こされたら、FFRは2.0になる。
ワインバーグによれば、FFRの受け入れ可能な値は、0.1~0.3らしい。
つまり、10回バグ修正したら、1~3回もデグレ又は別のバグが発生するが、まだフォローできることを意味している。

テスト管理や品質管理でよく知られているのは、バグ修正の時に、別のバグを埋め込んでしまいがちなこと。
仕様を正しく理解していても、プログラムの修正の影響範囲まできちんと分からない時が多いのだ。
だから、バグ修正する時は、別のバグを埋め込んでしまわないようにレビューするのも重要。

Redmineを使っていれば、バグ管理にも使えるから、上記のメトリクスも原理的に計算できるだろう。


Redmineによるチケット駆動開発を実践すれば、単にアジャイルに開発できるだけでなく、プロジェクト管理の奥深さも実感できると思う。

| | コメント (0) | トラックバック (0)

2010/07/14

ソフトウェア工学の光と影

平鍋さんがソフトウェアシンポジウムで発表された資料が公開されたのでメモ。
以下ラフなメモ書き。

【元ネタ】
『ソフトウェア工学の分岐点における、アジャイルの役割』:An Agile Way:ITmedia オルタナティブ・ブログ

ソフトウェア・シンポジウム2010 - SS2010

ソフトウェア工学には光と影がある。
ソフトウェア工学はこれまでに優れた業績を上げてきた。
でも、実際のソフトウェア開発にほとんど貢献できていないのではないか?
ソフトウェアの社会的影響力は増しているのに、デスマーチが減ったという話は聞かない。

ソフトウェア工学とはそもそも何なのか?
ソフトウェア開発者、ソフトウェア開発チームに対する社会学。

ソフトウェア工学は、ソフトウェアに従事する人と組織に関わる社会学と捉えよう。
だからこそ、コンピュータサイエンスと違って、人間的要素が混じり、自然科学よりも社会科学に近い観点が必要になってくる。
そこに矛盾を感じる。

| | コメント (2) | トラックバック (0)

コンピュータサイエンスをなめるな

ビューティフルコード」の末尾に、まつもとさんの対談があり、「コンピュータサイエンスをなめるな」というコメントに惹かれたのでメモ。

【他の感想】
404 Blog Not Found:コードの宝石箱 - 書評 - ビューティフルコード

良いもの。悪いもの。: ビューティフルコードとmalloc/free論争


僕が「ビューティフルコード」で興味を惹いた章は、下記の二つ。

21章 ERP5:最高水準の適応性に向けた設計
23章 MapReduceでの分散プログラミング

OSSのERPであるERP5の設計思想が面白かった。
また、MapReduceは、Hadoopが出るまで、Googleしかその実装モデルを持っていなかった話も面白かった。
だからこそ、GoogleはWebの世界で強力なわけだ。

Smalltalkerの青木淳さんは、年に1万行のプログラムを書くこと、年に数万行のプログラムを読むことを自分に課している話を聞いたことがある。
プログラムを書くのと同じぐらい、プログラムを読むのも必要。
そして一流のプログラマが書いたソースを読むのは特に重要。

「コンピュータサイエンスをなめるな」というコメントには、今まで積み上げられてきたプログラミングの歴史を侮るな、という意味が込められているように思う。

| | コメント (0) | トラックバック (0)

2010/07/11

営業支援ツールSugarCRMとeラーニング支援ツールMoodleのリンク

営業支援ツール SugarCRMとeラーニング支援ツール Moodleの解説や事例のリンクを貼っておく。

【営業支援ツール SugarCRM】
SugarCRMカタログ

SugarCRM 5.0 エディション機能比較表

OSS ビジネスモデル:顧客管理システム SugarCRM - まつした・ひろのぶ

SugarCRM社内導入事例のご紹介 & OSSへの取り組みについて

SaaS型顧客管理システム

Sugar 製品ラインの概要

【eラーニング支援ツール Moodle】
Moodleを使ってみよう・三重大学のMoodleの事例

京都大学全学共通教育における外国語教育でのMoodle の実験的運用と使用方法

SugarCRMを営業支援のCRMとして導入する場合、営業マンはITリテラシーが高くないから、導入が難しい。
まずは、営業マンが集めた名刺をSugarCRMへ取り込んで、名刺管理や取引先管理からまず使うのが無難みたい。
そこから、見込み顧客(リード)の管理や商談管理、顧客からの問い合わせ(ケース)管理、営業マンの実績管理へ発展させればいいだろう。
そして、営業支援のキャンペーンメールの管理などもやればいいだろう。
リード、ケース、インバウンド、アウトバウンド、などのマーケティング用語がSugarCRMの機能として実現されているので、慣れれば面白いと思う。

Moodleは、教育支援のWebシステム。
コースなどの独特の言葉があり、慣れるまで難しいかもしれない。
でも、Googleで検索してみると、大学の教育に使っている事例が意外と多い。
三重大学の奥山晴彦さん(Latexやアルゴリズムの本で有名)の事例が非常に参考になる。
生徒と先生の間のコミュニケーションをWebシステムへ一元化することで、やりとりも簡単になるし、コミュニケーションが活発になるのだろう。

いずれもOSSだし、LAMPなので、Bitnamiでワンクリックでインストールが可能。

BitNami :: SugarCRM
BitNami :: Moodle

Redmineによるチケット駆動開発を経験して、SugarCRMやMoodleのように、Webシステムで業務を改善する仕組みに興味を持っている。
ツールを導入すれば全ての問題が解決されるわけではないが、ツールを導入することで、情報が一元化されて、管理が楽になるために、コミュニケーションが活発化したり、ワークフローが具体化されて、自然にプロセス改善できる利点がある。

Bitnamiには、ファイルサーバーの代替WebシステムであるAlfresco、掲示板システムphpBB、Wikipediaと同じWikiであるMediaWikiなどのように、OSSで優れたWebシステムがワンクリックでインストールできる。
それらのツールを導入して、どんな業務でどんな状況に導入したら効果的なのか、まとめたら面白いだろうと思う。

| | コメント (0) | トラックバック (0)

2010/07/10

忘れ去られた日本のIT技術~DOAと品質管理

最近、上流工程のモデリング技術として、DOAを見直している。
その過程で、忘れ去られた日本のIT技術とその歴史があるように感じた。
考えたことをラフにメモ。

【DOA(Data Oriented Analysis)】

DOAはデータモデリングというモデリング技法、上流工程の設計技術の一つ。
DOAは日本独自で発展してきた歴史がある。
椿正明さんのTHモデル。
佐藤正美さんのT字形ER。
渡辺幸三さんの渡辺式DOA。

THモデルは古くは1970年代から発展してきたようだ。
他のDOAも、日本で、メインフレーム上の業務システムを開発する経験から育まれてきた。
歴史があるからこそ、DOAを知れば知るほどノウハウがある。

例えば、エンティティにはリソースとイベントの2種類がある。
イベントには必ずタイムスタンプ(日付)が振られて、業務の流れに従ってイベントが変わる。
リソースとイベントの個数を比較した時、普通はイベントはリソースの2割ぐらいしか作られていない時が多い。
つまり、リソースの組み合わせでいくらでもイベントを作る可能性があるし、新規ビジネスを起こすチャンスがあることも意味している。

DOAは業務ノウハウの塊なのだ。
そういうノウハウがあるだけでも、要件定義や設計の品質が上がる。

DOAは上流工程に特化した技術。
メインフレーム時代は、DOAを極めることで、モデリング技法を設計者が習得して、モデリング技術を高めてきた歴史があるのだろう。

しかし、現在を見渡すと、DOAは殆ど使われていないと思う。
OOA(Object Oriented Analysis)やUMLに押されて、皆忘れている。

DOAは習得が難しい。
THモデルやT字形ERは優れているかもしれないが、記法が独自で分かりにくい。
佐藤正美さんの本「論理データベース論考―データ設計の方法:数学の基礎とT字形ER手法」は、論理学を絡めている技法もあるので、哲学みたいで受け入れがたい。
渡辺幸三さんの本「業務別データベース設計のためのデータモデリング入門」「生産管理・原価管理システムのためのデータモデリング」だけは例外で読みやすいが。

DOAの弱点は、所詮は箱に過ぎないこと。
逆に、OOAの利点の一つは、上流工程と下流工程を一気通貫で設計と開発を一緒にできること。
つまり、UMLで設計して、ソースをそのまま出力すればいい。
実際はそんなことはないけれども、DOAに比べれば、オブジェクト指向プログラミング言語と相性がいい。

また、オブジェクト指向言語とDOAの相性が悪い弱点もある。
いわゆる、ORマッピングが面倒で、フレームワークで吸収できなかった歴史がある。
しかし、最近は、ActiveRecordのように、ORマッピングを意識しなくても、普通にDBをプログラミング言語で操作できるようになった。

そして、日本独自で発展してきたDOAがIT業界で忘れ去られた最大の理由は、ERPという汎用的な業務パッケージ製品を作れなかったことに尽きるのではなかろうか?
DOAのモデリング技術とDOAで培われた業務ノウハウで、SAPのようなERPを日本で作って販売できたはず。
しかし、日本では著作権やら業界の慣行が厳しくて、パッケージ製品を作ることができない風土があったのではなかろうか?

また、DOAのノウハウがあるにも関わらず、GoFのようなデザインパターンに業務ノウハウが整理されていない。
海外では、「The Data Model Resource Book」「Data Model Patterns」「アナリシスパターン―再利用可能なオブジェクトモデル (Object Technology Series)」のように業務パターンがまとめられているのに、日本人が書いた書籍がない。
但し、「実践的データモデリング入門 (DB magazine selection)」には「The Data Model Resource Book」「Data Model Patterns」の一部のパターンが紹介されている。

だから、若い日本人技術者のモデルとなるような業務パターンがないので、いつまで経っても、要件定義は難しいと言われているのだろう。

DOAは所詮、受託開発のモデリング技法としてしか、細々と使われているにすぎないのだろう。

【品質管理(Quality Management)】

ソフトウェアの品質管理は、製造業が発端で、日本のお家芸とも言える。
QC7つ道具、プロセス改善など、製造業のノウハウを生かして、ソフトウェアの品質管理に適用してノウハウが貯められてきた。
品質管理の一番の花形は、信頼度成長曲線(SRGM)、別名はバグ収束曲線。

時系列にバグの累積数をプロットして、歩溜まりに達したならば、バグがほぼ摘み取られて、品質が安定したと判断できる。
信頼度成長曲線を使えば、リリースしてよいかどうか判断できるのが最大の利点。

その他にも、プロセス改善がある。
日本人はプロセス改善が大好きだ。
現場で問題を発見して、現場の人たちが自主的に解決していく。
そのノウハウが品質管理につながり、日本の製品は品質がよいという神話につながった。

しかし、最近は品質管理の技法をあまり聞かないように思う。
CMMIやITILに押されているのが実情ではなかろうか?

製造業ならば品質保証部門は普通に存在するのに、SIerで品質保証部門やテスト部隊を抱えている所は少ないのではなかろうか?
つまり、SIerは受託開発専門が多いため、開発部隊が多く、テスト部隊は存在しないか軽視されてきた。

日本で行われてきたプロセス改善は、現場からのボトムアップのため、部分最適の罠に陥りやすい。
全体最適で行わなければ解決できない問題がソフトウェア開発には多いのではないか?

CMMIが一世を風靡し、大手SIの品質保証部門がCMMIをそのまま取り入れて、CMMIの推進部門になってしまったのは、日本のプロセス改善が理論的な体系になっておらず、全体最適の観点が漏れていたのではなかろうか?
日本の品質保証部門は、CMMIでプロセスを評価する部門に過ぎず、その役割が官僚化しているような気がする。
実際、開発部隊とテスト部隊はお互いに牽制しあっていて、信頼関係がないのが普通だろう。

あるいは、運用保守のプロセスを日本のSIがフレームワーク化できていないため、ITILのような海外の運用保守のフレームワークに乗っ取られたのでないか?
奈良さんの「ソフトウェア品質保証入門―高品質を実現する考え方とマネジメントの要点」は確かに内容は優れているし、現場で鍛えられたノウハウが入っていると思うが、正直整理されていないような印象を持っている。
ITILの観点を入れれば、運用保守のプロセスはもっと整理されて分かりやすくなるのではなかろうか?

でも、TestLinkでテスト管理してみて、日本の品質管理やテスト管理の技法やノウハウは生かせると感じている。
個人的には、TestLinkに日本の品質管理やテスト管理のノウハウを機能として実装してほしいと思う。


DOAや品質管理は、正直、今の日本人技術者は忘れている。
JavaやC#、クラウドやiPhoneなどに押されて、その技術が生かされていないように思う。
けれども、その技術はもう一度見直されてもいいと思う。

| | コメント (0) | トラックバック (0)

2010/07/06

もうすぐRedmineのVer1.0がリリースされる

yusuke-kokuboによれば、もうすぐRedmineのVer1.0がリリースされるようだ。

Twitter / yusuke-kokubo: 今週中には #redmine 1.0.0 がリリースされる予定です。

Twitter / Eric Davis: All issues are now closed for Redmine 1.0. Will be doing the final testing and packaging this week.

Redmine - ロードマップ - Redmine

実際、Ver1.0.0 RCのチケットは全て終了している。
リリース予定日である2010/7/3は過ぎたけれども、そろそろリリースされそうだ。

Ver1.0は数多くの機能が実装されているから楽しみだ。

| | コメント (0) | トラックバック (0)

2010/07/04

iPadの使い道

iPadはiPhoneとは違った使い方がある。
タッチする画面が大きくなっただけで、これだけ使い方が変わるとは。
ラフなメモ書き。

【1】電子書籍

電子書籍の作り方については、既に調べた。

電子書籍の作り方: プログラマの思索

電子書籍の作り方part2: プログラマの思索

電子書籍の作り方part3: プログラマの思索

一番お手軽で簡単な方法は二つ。
一つは、SkypeBookやi文庫で、テキストファイルを読むこと。
もう一つは、GoodReaderやCloudReaderでPDFを読むこと。
二つとも、すごく簡単。

いずれは、Blogのような私的な文章でさえも、電子書籍として販売可能だ。

「本を書いてみませんか?」――ブログ感覚で電子書籍を作成・販売 ペパボ「パブー」 - ITmedia News

つまり、文章と名のつくものは、全て電子化すれば、販売可能な時代。
たとえ300円で売られようとも、Web2.0のマーケティングの特徴であるロングテールのおかげで、絶版になることはない。
しかも、場所は取らないし、在庫コストもゼロ。

勝間和代の本では「Blogを公開して地力をつける。本を出版して世界が変わる。」と書かれているが、その文言が本当ならば、電子書籍でその名を広く知られれば、誰でもアルファブロガーになれる可能性がある。

【2】電子カタログ

通販のカタログやお中元のカタログを電子カタログにするのは誰でも考えつく。
しかし、これから結婚しようとするカップルへウェディングドレスをiPadでイメージしてもらうサービスはなかなか思いつかない。

ウエディングドレスの販促にiPadを活用――ノバレーゼが試験導入 - ITmedia プロフェッショナル モバイル

iPadのようなタッチパネル形式のツールがあれば、医療や教育では有望な用途だろう。

ビジネスで活用進むiPad、レストランや製薬会社でも - ITmedia News

【3】写真集

JPGの画像をまとめてPDF化すれば、iPadやiPhoneで写真集のように見ることができる。
iPad/iPhoneのPDFリーダーはGoodReaderやCloudReaderを使えばいいだろう。

PDF作成 - テキスト・画像ファイルPDF変換・仮想プリンタドライバ

デジカメで撮影した私的な写真を、簡単に自分だけのオリジナルの写真集でiPadで楽しむことができる。

【4】絵本

iPhoneと絵本が合体!? 「PhoneBook」誕生| ブログ「石原明の経営のヒント」|石原明.com

絵本ならば、iPadの方が読みやすいだろう。
iPadにデフォルトで入っているアリスの絵本だけでも、すごいと思う。

【5】電子辞書、電子百科事典

個人的には、辞書や百科事典が電子書籍化すればいいと思う。
英語などの言語、数学や物理、化学、医療などの専門的辞書は電子書籍の方が使い易い。
分厚い本を持ち歩くのは大変だし、索引を見ながら検索するのも手間がかかるから。

AppStoreを見ると、法律や医学などは約1万円で売られている場合もあるみたい。

【6】電子教科書

公開研究会 2010年度 第1回:電子書籍時代の教材:誰が作りどんな形になるのか

検定教科書も、しばらくしたら電子教科書になるかもしれない。
実際、知識さえあれば、ほとんどコスト無しで教科書を作って販売することは可能だ。
なにせ、教科書は学生の間しか使わない。

しかし、子どもたちに教える教科書の販売は、文部省や教育委員会が牛耳っている。
教科書を作る権威が、国でなくても、誰でも作れるとしたら、どうなるのか?

電子書籍は多分、今までの政治体制を揺るがす雰囲気があるから、皆が興味を持っているのかもしれない。

| | コメント (0) | トラックバック (0)

2010/07/03

XDDPとAgile、TiDDは相性がいい

「派生開発カンファレンス2010」の講演資料が公開されたのでメモ。
ラフなメモ書き。

【元ネタ】
「派生開発カンファレンス2010」開催案内

XDDPとUSDMでプロジェクトの課題解決

ソフトウェアの改造で悩んでいませんか? ~派生開発の品質と効率の向上を目指して~

派生開発は、既に運用されているソフトウェア製品に対し、保守したり、機能追加したり、それを移植して別製品を作ったりするアプローチ。
日本の携帯電話が、カメラ、着うた、オサイフケータイ、Edyなど次々に機能追加していく様は、まさに保守ではなく派生開発だ。
派生開発は組込製品やパッケージ製品でよく発生し、その難しさは以前から知られていた。

特に大規模プロジェクトほど、再利用可能な部品を作る設計にしておかないと、似たような部品を作っているのに、別チームで開発してしまって、工数やコストをかけすぎてしまいがち。
更に、似たような機能やソースがあちこちに散らばってしまうので、保守するのが難しくなり、品質はどんどん劣化する。

講演資料で目を引いたのは二つ。
一つは、XDDPとUSDMでプロジェクトの課題解決

PSPをまなぶとPFD、つまりXDDPのプロセスの理解が深まる。
XDDPは規律がある。だからPSPとも相性が良い。

XDDPを経験した開発者は、Agileを正しく理解する。
XDDPの本質は並行開発だ。だから自然にアジャイルになる。
何故なら、今稼働している製品(メインライン)を触らず、派生した製品用のライン(ブランチ)で設計書やソースを修正してテストするからだ。
元々の製品(メインライン)を不用意にいじってコミットせず、その差分を重視する開発スタイル。
まさに、パッチベースの作業を重視しているのだ。

一口サイズ見積りとチケット駆動開発。
全体計画を2週間単位の計画に分解する。
XDDPを経験した開発者は、小さな機能単位で見積もるから、見積もりの精度が上がるので、チケット駆動開発やアジャイル開発にすぐに馴染む。
アジャイルの利点であるイテレーション単位の開発スタイルを導入すれば、朝会がプロセス設計の場になる。

もう一つは、ソフトウェアの改造で悩んでいませんか? ~派生開発の品質と効率の向上を目指して~

XDDPは最終的にはSPL(ソフトウェアプロダクトライン)へ落ち着く。
XDDPは製品ファミリー開発につながる。
何故なら、成功した製品を元に移植して、特定のマーケットや顧客向けに派生した製品をどんどん作って売り出す開発が可能になるからだ。

すると、再利用可能な部品というコア資産が重要になってくる。
いかに以前作った部品を使い回し出来るか?
以前作った部品はあちこちの製品で運用されていれば、品質は担保されている。

コア資産を流用するには、ロジックは変えずに、I/Fを調整する方が多くなる。
Adapter、Facade、移譲のようなパターンを流用する時が多いだろう。

SPLで重要な品質は移植性や保守性。
移植しやすいプログラムでなければ、派生製品の開発速度が落ちるし、移植作業でバグを入れ込んでしまう。
保守性が高くなければ、独自ロジックを組み込んでしまって、再利用できなくなり、バグが発生したら修正範囲が広がって工数が多くなる。

XDDP、Agile、TiDD、SPLの関係性が面白い。

| | コメント (0) | トラックバック (0)

Redmineを使いこなせてチームに対するアドバイス

興味深いTwitterがあったのでメモ。

【元ネタ】
Twitter / kashisan: 最近行った #Redmine を使いこなせてチームに対するアドバイス。「チケットの説明には成果物を記載して、その成果物をリポジトリにコミットする」、「各トラッカーのステータスがどういう状況を表すか定義する」「それぞれのトラッカーがどういうフローになるかがわかる資料を作る」

Redmineを有効に運用出来ていないチームに対するポイントは3点ある。

1・「チケットの説明には成果物を記載して、その成果物をリポジトリにコミットする」
2・「各トラッカーのステータスがどういう状況を表すか定義する」
3・「それぞれのトラッカーがどういうフローになるかがわかる資料を作る」

ポイント1は、チケットファーストの原則。
プロジェクトにある全ての作業はチケットから始まる。
そのためには、チケットは成果物単位、つまりWBS単位である方が担当者も作業範囲が明確だし、管理者も成果物の進捗から、プロジェクト全体の進捗を測定できるようになる。
駄目なチームは、チケットのアウトプットが不明確だから、担当者も作業の目的が分からないし、管理者も進捗が分かりにくい。何よりもアウトプットの品質も悪くなる。

ポイント2は、作業の状態を明確化すること。
駄目なチームは、コミュニケーションのキャッチボールが悪い。
SEが設計書を作ったらPMががレビューするとか、PGがバグ修正したらテスターが検証する時には、各担当者の作業状態をチケットのステータスに関連付けると運用しやすい。
自然なペア作業になる。
二人の目を通すことによって、自然に品質が向上する。

ポイント3は、ワークフロー管理によってPMBOKやITILの言う変更管理プロセスを実現出来ること。
バグ修正と問い合わせのワークフローは全く違うのに、一つのワークフローですべての作業を制御しようとするのは、所詮無理がある。

また、顧客の要望を受けた場合、リリース範囲に含めるか、別のイテレーションに回すのかという判断、あるいは、誰がその要望を調査して分析するのか、その担当を決定するのが重要になる。
その場合、きちんとワークフロー管理しておかないと、何故システムに実現してくれないのか、何故放置されたままなのか、というクレームが顧客から来る。

だから、自分のプロジェクトでどんな業務があるのか、どんなワークフローが必要なのか、業務分析しておくのが重要。
実はSIer自身が、自分たちの業務範囲、自分たちの特徴、自分たちのワークフローを理解していないという現実がある。

実際は、朝会やふりかえりなどで、現場の開発者と試行錯誤しながら、自分たちのワークフローを作っていくのが現実的だと思うし、その方が自分たちの環境にフィットする。
パッケージ製品のお仕着せのプロセスを適用してもダメなのだ。

これがプロセス改善と呼ばれるものになる。

| | コメント (0) | トラックバック (0)

2010/07/01

Redmineの肝はワークフローとロードマップにある

yusuke-kokuboさんのTwitterがとても素晴らしいのでメモ。

【元ネタ】
Twitter / yusuke-kokubo: Redmineの使いどころはワークフローとロードマップにある。そこさえ抑えれば他はおまけ(というのは言い過ぎだけど)。

Redmineの肝、チケット駆動開発の肝を一言で言い表している。
チケットにプロジェクトの全活動の情報を集約すれば、ITSの機能であるワークフローによって、ツールでワークフローを管理できる。
更に、ロードマップに載せることによって、自然にアジャイル開発になる。

Redmineを使い倒して初めて分かる言葉だと思う。

| | コメント (1) | トラックバック (0)

« 2010年6月 | トップページ | 2010年8月 »