« 2017年10月 | トップページ | 2017年12月 »

2017年11月

2017/11/30

Redmineをもっと強化できるポイントpart2~コミュニケーションツール連携・かんばん機能

Redmineをもっと強化できるポイントpart1~上流工程のトレーサビリティ強化」の続き。

【1】障害チケットの活動ログをSlackのようなコミュニケーションツールと連動させる

結合テストや総合テスト工程では、従来は、朝会や夕会でメンバー全員を集めて、障害の優先順位付け、障害の担当者割り振り、修正状況の進捗確認などが行われていた。
メンバー全員の手が一時的に止まるので、結構ロスも多かった。

そこで、Jiraでは、Hipchatでチャットルームを作り、Hipchatに障害チケットの更新通知を流し、議論のやり取りをチャットにしてしまう運用があった。
つまり、Hipchatのチャットルームは、いわゆるWarRoom。
この運用で、総合テストの朝会や夕会で全メンバーが集まり、進捗状況を確認する運用がなくなった、とのこと。
なぜなら、オンライン上でリアルタイムに作業状況や進捗状況がやり取りできるので、全員が集まる必要がないからだ。

この運用は、RedmineからSlackへ障害チケットの更新通知をリアルタイムに配信し、Slack上でコミュニケーションを取ることで解決できるのではないか。

たとえば、テスターが障害チケットを起票したら、Slackに流れて、誰かがその障害を担当するか、Slack上でやり取りして決める。
決まったら、障害チケットに担当者が正式にアサインされ、その後の修正と動作確認はチケットのコメントで残す。

また、大規模プロジェクトでは、各チームの障害チケットがSlack上に流れるので、どのチームの障害が多いのか、どの人がどんな仕事をしているのか、というやり取りが全て見える化される。
見える化するような仕組みづくりは不要になる。

最近のソフトウェア開発では、Slackのようなコミュニケーションツール上で、仕様を議論したり、進捗状況を確認したりする時が多い。
なのに、逐一メール通知で気づくというやり取りは、情報連携のスピードが遅い。

SlackをSIerに導入した話。そしてSIerの未来 : 小野和俊のブログ

歴史あるSI企業でSlack導入に成功した方法――そして社内の風通しが良くなりムダや停滞感も消えていった (1/3):EnterpriseZine(エンタープライズジン)

今後は、Slackのようなコミュニケーションツールとチケット管理システムの連携が重要になってくるだろう。
RedmineにもSlack連携プラグインがあるが、最新バージョンでも動くのかな?

redmine-slack プラグインを使ってみたメモ - Qiita

sciyoshi/redmine-slack: Slack notification plugin for Redmine

【2】ガントチャートだけでなく「かんばん」も標準機能にして、場面ごとに使い分ける

Redmineが使えない、という人たちは、チケット一覧画面を多用しすぎる。
無造作に蓄積された多量のチケットに途方に暮れている。
乱発されたチケットを定期的に棚卸しする工夫を行わないと、すぐにチケットは放置されて、ゴミ箱になる。

だから、チケット駆動開発では、大量のチケットが発行されるので、何らかの方法でチケットをグループ化したり、他のチケット集計ビューを使ったりすることで、チケット管理を行うのが普通。

また、日本の普通のSIやメーカーのプロジェクトリーダーは、ガントチャートによるチケット管理が大好きだが、メンバー個人の立場ではガントチャートは使いにくい。
むしろ、小規模チームやメンバー個人では、タスクかんばんの方が作業しやすい。

たとえば、以前の東京Redmine勉強会の講演でも、IOT企業では、ガントチャートとかんばんを使い分けてチケット管理している、という事例があった。

RedmineがIoT企業に異常にマッチしてしまった話 - 僕のYak Shavingは終わらない

「RedmineがIoT企業に異常にマッチしてしまった話」の記事がすばらしい: プログラマの思索

第11回東京Redmine勉強会の感想~Redmineエバンジェリストが日本各地で出現しているらしい #redmineT: プログラマの思索

Redmineでは、複数プロジェクト機能があるので、かんばんもプロジェクト単位に分割できる一方、上位プロジェクトで横断的にかんばんのチケットを見ることもできるのがメリットになる。

よって、Redmineのようなチケット管理ツールでは、従来のマネージャ層向けのガントチャートと、メンバーが自身の担当状況を把握するためのかんばんの2つのチケット集計ビューが必須だろうと思う。

残念ながら、Redmine標準でかんばん機能はないので、実現されて欲しいと思う。

【3】「上流工程のトレーサビリティの強化」「コミュニケーションツール連携」「かんばん機能」は、最近の有償のチケット管理ツールにはどれも付属しているだろう。
これら機能は、プロジェクト状況の見える化、情報共有を現代風に強化したものと思える。

これら機能の効果は、以前よりも大規模な人数による大規模開発や、地理的に離れた開発チームによるオフショア開発がやりやすくなることだ。
つまり、大人数の開発者同士、地理的に離れた開発者同士のコミュニケーションをリアルタイムに行えるようにして、情報共有、さらには信頼関係を促進する方向へ、チケット管理ツールがどんどん進化している。

従来のソフトウェア工学では、コミュニケーションパスが増えるほどソフトエアの複雑性も非線形で増大するが、その問題を根本的に解決する方法はない、みたいな話があったように記憶する。
しかし、チケット管理ツールはその問題の症状を和らげて、より大規模かつ地理的に広範囲なチームでもソフトウェア開発できる環境を整備しようとする方向へ進化している。

この流れをRedmineの機能にも盛り込んでいきたい。

| | コメント (0)

Redmineをもっと強化できるポイントpart1~上流工程のトレーサビリティ強化

最近のJiraを見る場面があって、この機能はRedmineに取り入れた方がいいな、と感じたことをラフなメモ書き。
Redmineがもっと強化できそうなポイントは3つあると感じた。
そのうちの1個を書いておく。

【1】議事録Wikiと課題チケットを相互リンクさせる

【1-1】たとえば、要件定義や設計工程では、要件定義ヒヤリングや設計レビューが定期的に開催される。
そのタイミングで、Wikiにその場の議事録を全て書く。
そして、議事録でまとめられた決定事項以外に、課題となった内容は、チケット化する。

その時、Wikiから課題チケットを1クリックで新規作成したい。
そうすれば、ヒヤリングやレビューの打合せ時に、議事録をWikiに書きながら、その場ですぐに課題チケットを発行できる。
後で、課題チケットの詳細を書いて、チーム内で割り振りすればいい。

また、議事録Wikiには、発行した課題チケットのリンク一覧が自動生成されて欲しい。
そうすれば、議事録Wikiを見れば、どこまでが決定して、どこまでが残課題として残っていて、課題がどんな進捗状況なのか、一目で分かる。

【1-2】つまり、議事録Wikiと課題チケットを相互リンクさせるように機能強化することで、トレーサビリティを強化したいのだ。
すなわち、課題チケットの発端となった要件定義ヒヤリング、設計レビューの議事録Wikiと相互リンクさせることで、開発時やテスト工程で要件を探したり、保守フェーズで要件が変更されていった経緯を探すことに使いたいのだ。

現時点でのRedmineでは、構成管理ツール連携によって、ソースコードの変更履歴と障害チケットのトレーサビリティは実現できる。
つまり、開発やテスト工程以後の下流工程のトレーサビリティは標準機能で実現済みだ。

しかし、要件定義や設計工程などの上流工程のトレーサビリティは、機能と運用が上手く調和が取れていないと思う。
「チケットを起票してくれない」「チケットが放置されてしまう」理由の一つは、ここにあるのではないか。

以前の僕は、チケットをストーリーカードにすることで、チケットに要件を当てはめて、タスクに落とす方法を考えていた。
WF型開発におけるWBS駆動によるチケット化も同じ。

ITの地殻変動はどこで起きているのか?: プログラマの思索

しかし、要件や仕様、議事録をチケット化するのは経験上、あまり上手く運用できていないように感じる。
理由は、チケットの機能がすごく柔軟であるので何でもチケット化してしまうと、チケットをフローとして流したいのにストックの性質も持っているために、チケットを安易にCloseできなくなってしまうから。

【1-3】「議事録Wikiと課題チケットを相互リンクさせる」メリットは、課題チケットの発端となるヒヤリングやレビューという打合せがWikiに残ること、そして、課題や作業のようなフローはチケット、議事録はWikiでストックのように使い分けできることだ。
つまり、チケットはフローの処理だけに特化すればいい。
よって、チケットは基本はサクサク流れる。

また、毎回の打合せ議事録Wikiに、新規作成したチケット一覧が課題一覧として自動生成されると良い。
現時点のRedmineでは、WikiListプラグインを使って、毎回の議事録から発生した課題チケットのみを一覧抽出して表形式で記載する方法でカバーできる。

Wiki Lists - Plugins - Redmine

Redmine Wiki ListプラグインでTracのクエリのように使うアイデア: プログラマの思索

このような機能が洗練されれば、課題チケットから発端となった要件ヒヤリングやレビュー議事録にさかのぼれるし、過去の議事録からどんな課題が発生して解決されたのか、という観点でドリルダウンすることもできる。
つまり、課題チケットと議事録Wikiの間でトレーサビリティを実現できる。

特に、上流工程では、要件や仕様がぶれやすいので、要件から仕様書やソースコードに至るまでの成果物へのトレーサビリティが非常に重要になる。
せっかく顧客の打合せで合意した要件が作業漏れで仕様書に反映されなかったり、設計レビューの指摘事項が上がっているのに仕様書に反映されなければ、下流工程で発見することは不可能だから。

【1-4】もっと突き詰めると、議事録Wikiは、Redmineのバージョンと連動できる方が良い。
なぜなら、要件ヒヤリングや設計レビューは定期的に打合せが開催されるので、そのタイミングで作られる議事録は、イテレーションに対応付けやすいから。
そうすれば、上流工程でも、アジャイル開発のような反復的なリズムで、作業できるようになる。

また、チケットに議事録Wikiと連動したRedmineバージョン情報が自動設定されれば、チケットを見るだけで、どの打合せから課題が発生したのか、分かるし、バージョンのリンクから発生源の打合せにさかのぼれる。

さらに、Redmineバージョン単位に打合せから発生した課題チケットが自然にグループ化されるので、チケット集計もやりやすい。
ロードマップ画面に各バージョン単位で、議事録Wikiの内容と、紐付けられた課題チケット一覧が表示されるし、チケット全体の進捗率も表示される。
よって、ロードマップ画面上で、打合せ単位の決定事項、議論の内容、残課題の内容を全て把握できる。

つまり、要件ヒヤリングや設計レビューでは、Redmineバージョンを打合せのタイミングと同期させ、さらに、RedmineバージョンのWikiに議事録を残すように運用すれば、自然に反復型開発をRedmine上で実現できるはずだ。

【1-5】では、議事録Wikiを発生源として、上流工程のトレーサビリティを実現する仕組みを作る上で、Redmine標準に足りない機能は何か?

一つ目は、Wikiから課題チケットを1クリックで作成する機能。
さらに、バージョン設定画面のWikiページから課題チケットを1クリックで作成できた場合、チケットのバージョン欄に、バージョン設定画面のWikiページのバージョン情報を自動設定するようにしたい。

そうすれば、議事録Wiki→1クリックでチケット作成、チケットのバージョンリンクから議事録Wikiへ追跡、という前方追跡のトレーサビリティが実現される。

二つ目は、議事録Wikiに、作成した課題チケットを一覧表示させる機能。
そうすれば、議事録Wikiの課題一覧表→リンク押下で各チケットへ遷移、という後方追跡のトレーサビリティが実現される。
現時点では、WikiListプラグインを使って、手作業で課題チケット番号を収集して、表形式にまとめなければならない。

但し、議事録Wikiをバージョン設定画面のWikiページで置き換えるならば、ロードマップ画面に、バージョン単位に紐付けられた課題チケット一覧が自動で表示されるので、課題は解決できる。

三つ目は、議事録Wikiの履歴を残す機能。
議事録Wikiをバージョン設定画面のWikiページで置き換えるならば、ロードマップ画面が議事録の履歴になるので、課題は解決される。

【1-6】今後は、Redmineのあらゆる画面で、チケットを1クリックで起票できる機能が強化されると良いと思う。
さらに、起票元の画面にチケットのリンクが残せるように設定できるなど、チケットと起票元の画面で相互リンクできるとなお良い。

理由は、チケット経由のトレーサビリティの範囲を拡張したいからだ。
チケット管理ツールがMSProjectやExcelよりも優れているメリットが、トレーサビリティ機能なので、その範囲をもっと広げて、Redmine単体でトレーサビリティの設定を制御したい。

現状は、構成管理ツール連携による成果物の修正履歴とチケットの相互リンクだけだが、Wikiやフォーラム、ニュースなどとも相互リンクできるようにしたい。
そうすれば、過去の要件や仕様の変更の経緯をRedmine上で追跡できるし、ソース修正がどの仕様に影響して他の機能にどれだけ影響を及ぼすのか、を考えるきっかけにもなるだろう。

実は、以前、似たような機能として、Redmineのフォーラムのメッセージからチケットを起こすプラグインもあった。
しかし、現在のRedmineでは使えないと思う。

Haruyuki Iidaさんのツイート: "フォーラムのメッセージからチケットを起こすプラグイン。フォーラムでの議論から課題が発生することはよくあるので良いかも。Redmine: Activity - Plugins: Issue from message plugin http://t.co/OkR3LWd"

Issue from message - Plugins - Redmine

Redmineプラグインあれこれメモ: プログラマの思索

【1-7】上記のように、チケットを簡単に発行できる機能と相互リンクさせる機能を強化することで、チケット管理ツールの強みであるトレーサビリティの範囲をもっと広げられるはずだろう、と思う。

上記の考えを発展させれば、下記のように整理できるだろう。

1)プログラミングなどの開発工程では、構成管理の配下にある成果物駆動でチケットを起票して、作業状況を管理していく。
もちろん、構成管理の配下にある成果物とチケットは相互リンクされる。
また、ロードマップ画面で、リリースバージョン単位に作業チケットがグルーピングされ、コミットされた成果物までドリルダウンできる。

2)テスト工程では、障害駆動でチケットを起票して、障害状況を管理していく。
もちろん、ソースの修正履歴と障害チケットは相互リンクされる。
また、ロードマップ画面で、リリースバージョン単位に障害チケットがグルーピングされ、修正ソースまでドリルダウンできる。

3)要件定義、設計工程では、顧客との要件ヒヤリング、設計レビューの打合せ議事録駆動で、チケットを起票して、課題状況を管理していく。
打合せ議事録はWikiでバージョン付けされて、課題チケットと相互リンクされる。
また、ロードマップ画面で、打合せの単位で、議事録・確定した仕様・残課題チケットが一覧表示される。
さらに、課題チケットであがった指摘内容は、構成管理の配下にある設計書へ随時コミットされ、チケットと相互リンクされる。

すなわち、上流工程から下流工程まで、チケットの発生源と作業状況を管理するチケット、成果物を相互リンクさせる運用によって、要件から成果物までのトレーサビリティを実現できるはず。
そして、上流工程のトレーサビリティの課題は、「打合せ議事録をWikiで一元管理して、Wikiに課題チケット一覧を生成する」運用で解決できるはず。

つまり、上流工程の顧客打合せで要件や仕様が決まった経緯はWikiに残し、Wikiからチケット経由のトレーサビリティが全てRedmineで一元管理できれば、ナレッジシステムへ進展できるはず。

このアイデアを試してみる。

| | コメント (0)

2017/11/25

Redmineが今後発展する方向のアイデアpart2

2017年末の時点で、Redmineが今後発展する方向について、考えたことをメモ。
2014年時点に書いた時から、幾分状況も変わっている。
以下はラフなメモ書き。

【参考】
Redmineが今後発展する方向のアイデア: プログラマの思索

日本の大企業におけるRedmineの利用事例の資料のリンク: プログラマの思索

以前、僕が考えていた時は、アジャイル開発への適用、プラクティスやアンチパターンなどのパターン言語への適用が主だった。

僕が今、Redmineによるチケット駆動開発で考えているテーマは下記になる。
幾分重複している。

【1】SW工学への適用
【2】PJ管理ツールとしての開発基盤
【3】Redmineと組織の関係
【4】チケット駆動がもたらす効果
【5】フローとストック、変更管理と構成管理の関係

【1】SW工学への適用

もう一度、Redmineに各種のプロセスや手法を適用した時に、フィットギャップ分析や導入・運用時の注意点などをまとめたい。

【1-1】PMBOKの実装
 →EVMはその一つ。

【1-2】CMMIレベル4を実現するためのRedmine運用方法

たとえば、パナソニック子会社の事例では、CMMIレベル4を目指すために、Redmineを導入・運用することで解決しようとしている。
開発現場を救うプロセス改善の進め方 - SPIJapan2014

CMMIレベル4を実現するには、Redmineのどの機能を使って、CMMIの各プロセス領域を実装すべきか?
フィットギャップ分析して、Redmineの標準機能が不足していると判明したら、その問題をどのように解決するか?
プラグインを作ってRedmineに組み込むか?
ExcelマクロやBIツールなど、外部システムで解決するか?

【1-3】GTD
 →かんばんを使えば実装可能と思っている。
  課題は、より使いやすくするには、かんばんのUIをどのように実現すればよいか?

【1-4】ITIL
 →問合せ管理、サポートデスクの運用もこの範疇に入る。
  ITIL特有の課題は、複数の相異なるワークフローをどのように組合せて、一つのプロセスを実装すべきか?

【1-5】メトリクス収集/集計のためのプロセス基盤
 →各種ソフトウェアメトリクス、進捗・品質・コストのメトリクスを出力する。
  KPIもその一つ。
  たとえば、最大放置日数、平均完了日数(=平均リードタイム)、平均サイクルタイムなど。
  基本はチケット集計のビューを増やせばいい。
  それらメトリクスを使うと、どんな結果や効果を示せるのか?

【1-6】BPMや汎用帳票ワークフロー基盤の適用

【1-7】派生開発、ソフトウェアプロダクトラインへの適用

【1-8】ISO9001、ISMSへの適用

【2】PJ管理ツールとしての開発基盤

Redmineの柔軟な外部I/Fを洗い出してみると、汎用的な開発基盤とみなすことができることは以前書いた。

第6回品川Redmine勉強会発表資料「開発基盤としてのRedmine~Redmineをカスタマイズするポイント」

【2-1】では、「RedmineはPJ管理の実験ツールである」と考えた時、標準のRedmineでは何が足りないのか?
今までのRedmine勉強会、redmine.tokyoの Unofficial Redmine Cooking を見た限り、いくつかある。

概要 - Unofficial Redmine Cooking - redmine.tokyo

カスタムフィールド内部の項目値設定は、システム管理者以外の権限でも有効化したい。

Redmineのワークフロー設定を拡張する機能提案~Redmineは汎用的なBPMツールになりうるか: プログラマの思索

ロードマップ画面で、チケットをD&Dで並び順に変更する。
この機能は、アジャイル開発でプロダクトバックログを整理する時に使う。

カレンダー画面はもっと改良して欲しい。
ユーザ別に週別カレンダー表示など、チーム内でどのメンバーがどのチケットを担当を予定しているのか、一目で分かるようなビューが欲しい。

文書、マイページなども、もっと画面改良できるはず。

他に、開発基盤であるからには、チケット画面のUIは今風にしたい。
スマホなどに慣れていると、RedmineのUIは古くなっている部分がある。

ViewCustomizeプラグインで、どの程度、RedmineのUIを改善できるか?

【2-2】他に、外部ツールとのツール連携はどのように構成すべきか?という課題がある。
たとえば、構成管理ツールGitlab、ビルド管理ツールJenkinsをRedmineと連動するのは普通だろう。

それ以外に、連携した方が良い外部ツールはあるか?

SW構成管理を実現するプロジェクト管理サーバー

【3】Redmineと組織の関係

経験上、「日本では、Redmineは組織に従う」。
日本企業は、自分達の標準プロセスに合うように、Redmineをカスタマイズしたがる。

実際、日本の大手SIが持つ自社の標準プロセスは、工程の名前が微妙に違うけれど、WF型開発の構造と何ら変わらないのに、自社の標準プロセスに非常にこだわりがある。
日本のメーカーも同じ。

【3-1】大規模組織にRedmineを導入した場合、小規模チームで編み出されたチケット駆動の運用ルールがそのまま適用できない場合がある。
複数の部署があり、部署ごとに異なる組織文化があれば、単純な一つのルールで実現するのは難しい場合もあるだろう。

大規模組織で多種多様なプロセスをRedmineで実現して運用する場合、どんな点に考慮すべきなのか?

第15回RxTstudy『大規模組織や多様な業務におけるRedmineの課題』

【3-2】また、Redmineインスタンスと組織、プロセスの関係という問題が出てくる。
大規模組織では、唯一のRedmineインスタンスで標準プロセスを強制して、運用すべきなのか?
あるいは、あえて複数個のRedmineインスタンスを許し、各チームのプロセスに合ったRedmineへカスタマイズすることを許容すべきか?

Redmineインスタンスとプロセスの関係~Redmineは組織に従うのか、Redmineに合ったチームを作るべきか: プログラマの思索

たとえば、気象庁ではあえて複数個のRedmineインスタンスで運用されている。
なぜ、このような運用を採用したのか、その理由や背景、意図が知りたい。

気象庁の数値予報課におけるRedmine利用事例: プログラマの思索

数値予報モデル開発のための 基盤整備および開発管理 - 気象庁

(引用開始)
開発管理サーバの特徴として、一つのサーバ上に複数の Redmine を運用している点が挙げられる。
指針が定める開発管理サーバの利用範囲は、気象庁本庁と気象研究所を含めた複数の課室を想定していることもあり、管理する開発対象が非常に多岐にわたっている。
こうした背景からサーバ上で複数の Redmine を運用し、各 Redmine の管理方法の細目は利用するコミュニティに委ねる方式を採用している。
(引用終了)

【4】チケット駆動がもたらす効果

一方、「Redmineが組織文化に変化をもたらす」場合もある。
そもそも、Redmineを新規導入したいという意図を持つ組織では、Redmineがもたらす効果を得たいために目指しているはずだから。

それは、単なる作業の見える化だけではない。
予定していなかったチケット駆動の副次的効果ももたらす。

たとえば、機能別組織で縦割りの雰囲気があっても、Redmine上ではあたかもPJ型組織の構造となり、メンバー間のコミュニケーションが活性化する。
あるいは、障害修正のように、テスターと開発者があたかもペア作業のようにキャッチボールしながら、障害を直していく。
たとえ、オフショアという地理的に離れたメンバーであっても、コミュニケーションの活性化がメンバー間の信頼関係を促進する、という場面を僕は何度も見てきた。

たとえば、Redmineの標準機能で不足している、と感じたならば、システム管理者が言わなくても、メンバーが自発的にExcelマクロやプラグインなどを作り出す。
つまり、ツールがプロセス改善の雰囲気を醸し出し、プロセス改善の方向へメンバーを動機づける、と言う場面を僕も何度も見てきた。

つまり、「Redmineが組織文化に好影響をもたらす」事例を抽出し、それら効果を整理したい。
そして、その効果を得るためには、Redmineの運用で何に気を付けるべきなのか、を明確にしたい。

【5】フローとストック、変更管理と構成管理の関係

【5-1】チケット管理ツール特有の観点として、フローとストックを別々に管理できて、フローとストックの間でトレーサビリティを実現できる点がある。

ストック型チケットは記憶媒体、フロー型チケットは流通媒体: プログラマの思索

その時、Redmineのどの機能をフローとみなすか、ストックとみなすか、で違いが出てくる。
チケットはフローでもあるし、ストックともみなせる。
たとえば、チケットをXPのタスクカードとみなせば、フローであるし、障害管理票や課題管理票や議事録とみなせばストックになる。

【5-2】では、Redmineでは、フローやストックはどの機能に相当するのか?

フローとストックのアイデアを突き詰めると、変更管理と構成管理の概念に行き着く。
フローは変更管理、ストックは構成管理の対象になるからだ。

昨今ではGit+チケット管理によるモダンな開発が主流だが、その開発プロセスでは変更管理と構成管理が自然に実装されているので、あまり気にする必要がない。

【5-3】しかし、ISO9001などの運用で、構成管理されるべき成果物がExcel設計書である場合、問題がたくさん出て紛糾していると経験上思う。

理由は、変更管理されるべきExcel変更依頼書やExcel作業指示書と、構成管理されるべきExcel設計書が同じようなステータス管理の対象となって混乱しているからだ。
特にメーカーの運用はそうだろう。

チケット管理システムは作業の構成管理と同じ: プログラマの思索

混乱している理由は、Excelドキュメント自体がGitなどの構成管理ツールで管理できていないので、昔ながらのフォルダ管理で運用されているから。
また、作業指示書であるExcel変更依頼書がチケット化されていないために、それもステータス名の付いたフォルダに手作業で移し替える事で、ステータス管理されているから。

【5-4】では、Excel設計書などの成果物は、どのように構成管理すべきか?

本来は、ライフサイクルの長いExcel成果物はGitなどで構成管理すべき。
しかし、Excel文書は構成管理ツールの差分が見れない、などの問題がいくつかある。

JAXAでは、構成管理ツールではなく、Redmineの文書機能拡張のDMSFプラグインで運用していた。

第13回東京Redmine勉強会の感想~『Redmineの今と未来』 #redmineT: プログラマの思索

“CODA” チケット管理システム | JSS2@JAXA

一方、@akahane92さんの現場では、Excel設計書は全てSubversonで構成管理されている。

「効率・品質・統制」の共通課題に着目した現場主導による ITS 導入事例~OSS 運営ツールで効率的・低コストな導入を実現~ (IPA 「先進的な設計・検証技術の適用事例報告書 2016 年度版 」)

「効率・品質・統制」の共通課題に着目した現場主導による ITS 導入の効果検証~SQIP2014

どちらのやり方が良いのか、というのではなく、Excel文書の構成管理の実装方法をもっと整理したい。

【5-5】僕は、変更管理と構成管理を区別する、という考え方は重要と思う。
なぜなら、チケット駆動で運用しようとしてもチケットが起票されない、という問題の原因の一つに、チケットを仕様書のように細かく書こうとして入力コストが大きくなるから、という事象もあるのではないか、と思っている。

チケットをフローとして流すのを優先するか、ストックとして残すのを優先するのか。
その背後には、変更管理と構成管理の混乱があるのでは、と思ったりする。

【6】上記のように、Redmineで今後試すべき課題とその方向性を思いつくままリストアップしてみた。
「Redmineは先進的なプロセス基盤の実験場」とみなすならば、もっと色んなアイデアが出てくるし、色んな課題が出てくるだろう。

また、上記のアイデアはRedmineに限定されず、他のチケット管理ツールでも同様に実験することができるだろう。
そして、他のチケット管理ツールで実装できている機能は、Redmineに移植することができるはずだし、逆も然りだ。

さらに、「RedmineはPJ管理の汎用的な開発基盤」とみなすこともできるので、ソフトウェア工学やプロセスに興味を持つ人達だけでなく、Ruby開発者も上記の課題解決に加わることができるだろう。
背景の違う人達が数多く議論することで、より有用な結果が得られるだろう。

【追記】
門屋 浩文さんのツイート: "@akipii いろいろ意見だしあいましょう 4の副次的効果は同感です"

akipiiさんのツイート: "@MadoWindahead @MadoWindahead さんのつぶやきを読みながら、チケット駆動の副次的効果を整理した方がいい気がしました。導入する人は、予定していない副次的効果も期待しているから。それを説明できれば、より納得してくれるでしょう。"

門屋 浩文さんのツイート: "@akipii その辺りを具体的にまとめたいなあ ツール利用の副次効果で「信頼関係ができる」だけでは薄そうなので 今年も言って回ってますけど 感じてない人には響いてなさそう"

| | コメント (0)

2017/11/22

Redmineのもう一つのEVMプラグインEVM Calculation Plugin

先日の東京Redmine勉強会で、アンケート資料にあるプラグインを見ていたら、EVMプラグインがあったのでメモ。

【参考】
Redmine.tokyo 13回 参加者アンケート結果

EVM Calculation Plugin - Plugins - Redmine

redmine_issue_evm/README_ja.md at master ・ momibun926/redmine_issue_evm

チケット駆動開発にEVMの概念を導入してみる: プログラマの思索

RedmineにおけるEVMの考え方: プログラマの思索

RedmineプラグインRodmapsにEVMの機能を追加する: プログラマの思索

RedmineからPMBOKのEVMを計測する方法: プログラマの思索

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

RedmineにおけるEVMの実装方法は、過去にたくさん書いてきた。
また「チケット駆動開発」「Redmineによるタスクマネジメント実践技法」にもアイデアは書いた。

上記のEVMプラグインは、OSSなのにほぼ実用的に使える機能が整っている。
Redmineに予定工数、実績工数が入力される運用があるなら、EVMを使いたくなってくるだろう。

従来はExcelでEVMを管理するしか方法がなかったので、きちんとプロジェクト管理を徹底しているリーダーは、自分でExcelマクロで実装している人が多い。
EVMをきちんと運用できれば、プロジェクトの状況を正確に把握しやすくなる。
特に、製造業の製品開発のように、リードタイムがソフトウェア開発よりも多少長い場合は有効だろう、と思う。

しかし、EVMは運用が難しい。
理由は、いくつかある。
一つは、予定工数と実績工数を入力させる運用は手間がかかること。
しかも、仕様変更や進捗遅れでリスケするたびに、ガントチャートの保守が面倒になる。
そういう場面のために、仕様変更やリスケのタイミングでベースラインを設定して、進捗やコストを比較したいわけだが、その運用も結構面倒。

もう一つは、EVを計算しても、リーダーの感覚ではシステム上計算されたEVとプロジェクトの現状が合致していない場合が多いこと。
普通のEVMでは、WBSの進捗率を元にEVを計算するわけだが、進捗率が50%や90%で停滞したまま放置されてくると、プロジェクトの現状と合わなくなるのは当然。
たぶん、進捗率ベースのEVMの運用は悪手だと思う。
完了チケットでEVを計測する方がいいと思う。

なお、プラグイン上の注意点は、
・EVは進捗率を使わずに完了チケットで計算していること
・バージョンとは別にベースラインを設定してEVMを比較できること、
・チャートの表示にはHigthChartを使っていて商用目的では利用のできないライセンスであること
だろう。

つまり、EVはプロジェクトの現状よりも低めに計算されやすいので、こまめにチケットを分割したり棚卸ししたりすることが必要だろう。
また、ベースライン機能があるので、プロジェクトのスコープが変化した時にEVMの履歴が残せるのは便利。
但し、チャート表示のライブラリのライセンスには注意。

| | コメント (0)

2017/11/19

第13回東京Redmine勉強会の感想~『Redmineの今と未来』 #redmineT

昨日の勉強会は参加者、スタッフの皆さん、お疲れ様でした。
あいにくの雨にもかかわらず、参加率が約90%で大変盛り上がりました。
楽しかった余韻が冷めないうちに、感想をラフなメモ書き。

【参考】
第13回勉強会 - redmine.tokyo

第13回勉強会 - redmine.tokyo ~『Redmineの今と未来』(2017/11/18) #redmineT - Togetterまとめ

redmine.tokyo 第13回勉強会 - connpass

“CODA” チケット管理システム | JSS2@JAXA

【1】数多くの参加者に感想を聞いた所、JAXA様の講演が聞きたかった、という話もあったが、LTも含めて運用事例からプラグイン開発などの技術、最新バージョンの紹介、ちょっとしたプラグインの利用事例、家庭内のRedmine利用事例など、幅広いテーマで面白かった、という話があった。
また、参加者層も初心者から10年近い利用者まで、年代層も20歳から40代まで幅広かった。

akipiiさんのツイート: "#redminet 今日も参加率90%で驚異的でした。利用事例から技術まで幅広いテーマで面白かったと言う声をたくさん聞けてスタッフ一同嬉しいです。参加者層も初心者より数年経験者の人が半数以上いた。Redmineコミュニティが今後も長続きできるといいなと思う。"

さらに、女子の参加が10名を超えたのも初めてではないかと思う。(正確に数えてない)

akipiiさんのツイート: "#redminet 今日の東京Redmine 勉強会は過去最高で女子率が高くて華やかだったと思う。以前、@agilekawabata さんが、Redmine はおっさんのツールだから若い人や女子は少ないんですよ、と言ってたが、時代が変わった?"

第7回Redmine.tokyoの感想 #redmineT: プログラマの思索

そんなことを振り返ると、多種多様な年齢層や女性という人口的変数、プロジェクトリーダーだけでなくSEPG等の品質保証部の人からプラグイン開発者までの心理的変数というセグメントが幅広くて、たくさんの化学反応があって面白かったと思う。
幅広い利用者が集まるコミュニティになれば、ある人はRedmineを使っているなら常識と思っていても、他の人にとっては新鮮な内容であることも多いだろうから、そういう数多くの議論が発生して、さらに理解が深まるだろうと思う。

たとえば、Redmineのそんな所でつまずくのか、という質問が、実はRedmineというツールではなく、プロセス保証やプロジェクトマネジメントの根本的な問題に触れていたり、とか。
僕も色々気づきがあった。

【2】JAXA様の利用事例で、興味深い点は二つある。

“CODA” チケット管理システム | JSS2@JAXA

【2-1】一つは、フローの管理とストックの管理を明確に別々に分けていること。

akipiiさんのツイート: "#redmineT JAXAでは、議事録はチケット、構成管理すべき文書は、文書管理機能、実際はDMSFプラグインで管理を区別してる。フローの管理はチケット管理、ストックの管理は構成管理ツールでなく文書管理プラグインで制御してる。全文検索プラグインで文書も全文検索できると、かなり良… https://t.co/AVf8WAHtsc"

Redmine本来の設計思想では、日々流れるフローのような管理対象はチケットにする。
タスク、かんばん、ISOの変更依頼書のように、作業指示書のようなレベルのものは、ステータス管理の方が重要だ。
つまり、日々のフローで管理する時、担当者とステータスに着目する。

一方、ストックのような管理対象は基本は、GitやSubversionのような構成管理ツール、あるいはWikiに蓄積する。
たとえば、ソースコードやExcel設計書は構成管理ツールの配下で履歴管理したり、技術や共有情報などのナレッジはWikiに蓄積する。
あるいは、チケットそのものを議事録にしたり、障害管理票のようにチケットに障害の発生原因や修正履歴を追記して、チケットそのものをナレッジにしてもいい。

Redmineのメリットは、フローとストックの管理を一つのツールで一元管理できるので、フローとストックの間で相互リンクを貼ることにより、トレーサビリティを実現できることだ。
よって、成果物から要件の発端まで前方追跡して変更理由を探したり、発端となった要件から成果物まで後方追跡して仕様変更の影響範囲を探る、といった使い方ができる。
この運用ルールが「No Ticket, No Commit」であり、他のプロジェクト管理ツールにないチケット管理ツール特有の最大の特徴でもある。

しかし、JAXA様の運用では、ストックの管理はRedmineの文書管理にDMSFプラグインを入れて活用されている。
この点がRedmine本来の設計思想と大きく異なる。

その理由を推測すると、成果物の対象がExcelであるため、構成管理ツールだけでは文書の変更の権限制御がやりにくい点があるのだろう。
そこで、DMSFプラグインを入れることで、Excel文書の変更履歴を残したり、Excel文書の参照・更新の細かな権限制御を付けることで、より使いやすくしているわけだ。

たとえば、外部委託したベンダーには特定のExcel文書は参照権限はあるが、更新権限は与えない、といった使い方をしたい場面があるのだろう。

【2-2】もう一つは、Redmineではボトムアップで運用ルールを柔軟に変更して、より良くしていく手法がある点。
Redmineは管理画面にあるワークフロー、ロール、トラッカー、カスタムフィールドを細かく制御できるので、運用しながら標準プロセスを固めていくことも可能だし、そういうやり方の方が普通なのではないか。

akipiiさんのツイート: "#redmineT Redmine の良さは、管理機能をフレキシブルに変更できる点。実際の運用は、かなり試行錯誤した、とのこと。プロセス標準化は一夜にしてならず、ですね"

akipiiさんのツイート: "#RedmineT 更新ロールと参照ロールに分ける。基本ワークフローは、全般トラッカーと名付けて、プロジェクトごとでカスタムフィールドを切り替えて利用する。つまり多様なプロジェクトの構造を管理画面の機能で制御するわけだ"

たとえば、Redmineの基本ロールは「PJ管理者」「開発者」「報告者」だけだが、実際に運用してくると、PJ管理者とシステム管理者の間のロールが欲しくなってくる。
その場合、「ロールのORルール」を用いて、「システム管理者でない管理者」のロールを新規作成し、各プロジェクトで各ユーザにそのロールを追加付与すればいい。
すると、既存のロールをいじることなく、既存ロールにパッチを当てる感じで、権限を細かく制御できるようになる。
たとえば、基本ロールと追加ロール、参照ロールと更新ロールのようにロールを細かく作っておけば、ロールのORルールを適用して、数多くのバリエーションで権限制御できるようになる。

すなわち、運用で試行錯誤しながら、ロールやワークフローを再定義したい時に、Redmineではパッチを当てる感じで既存の運用フローを修正していくことが可能なのだ。
こういう運用が可能な理由は、Redmineの管理画面の機能が豊富で柔軟であるからだろう。
換言すれば、Redmineの豊富で柔軟な機能をもっと理解しておけば、最初からトップダウンで完璧な運用を目指すのではなく、運用しながら標準プロセスを固めていく、といった、アジャイル的な発想を取り込めるはずだ。

僕はアジャイル開発が好きなので、ソース修正だけでなくプロセス構築にもアジャイル的なやり方を組み込むことは、実現不可能と思っていないし、むしろ、トップダウンでガチガチに固めてしまってメンバーのやる気を失わせるよりも、メンバーのより良い意見を取り入れながらチーム一丸でRedmineをより良く使いやすくしていくことは可能だと思っている。

【3】前田剛さん、堂端さんからRedmineの次期バージョン4.0に関する講演があり、興味深かった。

Redmineウォッチャーとしては、Railsの最新バージョンに追随する形でRedmineもどんどん最新化して欲しい。
性能面、セキュリティ面、今後の機能追加のしやすさ、を考慮すれば、開発基盤の最新バージョンに追随して欲しいから。
講演によれば、Ver4.0は早めにリリースしたい、とJPLが言っていた、とのこと。

Ver4.0で問題になってくるのは、既存プラグインがそのままでは、ほぼ使えなくなることだろう、とのこと。
Rails5に追随できるようにプラグインの修正が必ず発生する。
過去のRedmneのバージョンアップでも、追随できなかったプラグインは数多くあったので、利用ユーザは注意すべきだろう。

前田剛さんのアドバイスでは、古いRedmineはあらかじめVer3.4へVerUpしておくべきこと。
理由は、Rails5ではRuby2.2.1未満は切り捨てられるので、Ruby2.2.1に対応済みのVer3.4のRedmineで動作できるようにしておくと事前に検証できるから。

【4】他の講演も面白かった。
Redmineの利用が深まる中で、色んな問題意識があげられていて、興味深かった。

RedmineとSlackなどのコミュニケーションツールは、どのように使い分けた方がいいのか?

お子さんの宿題管理にRedmineを適用し、EVMや分析を行ったが結局使いこなせなかった、とのこと。
このLTも、普段のRedmineとは違う観点で面白い、という別の参加者の感想もあった。
個人的には、Redmineが使いこなせなかった理由には、Redmineが見れるPCをお父さん部屋しか置かず、子供の導線上で見える化しなかった点もあるのでは、と思った笑。

akipiiさんのツイート: "お母さんの反省点はRedmineが見れる端末を廊下と子供部屋に置くことかな笑。RT @agilekawabata: お母さんの反省会で導線が大事だったということで、JAXAの事例にもあったように、ホーム画面に担当者が必要となる導線を置くことはとてもいいと思う #redmineT"

【5】Redmineの面白さは、プロジェクトリーダーや品質保証部の観点でプロセスを自分で構築できて運用を試せる一方、プログラマの観点で不足機能をカスタマイズしたりプラグイン開発してより使いやすくできる、という両面があることだろうと思う。

すなわち、前者の観点では、Redmineは標準プロセスの運用基盤またはメトリクス収集・集計のプロセス基盤である一方、後者の観点では、Redmineはプロジェクト管理ツールの汎用的な開発基盤とみなせることだ。
つまり、ソフトウェア工学の観点とRuby開発の観点の両面からRedmineをいじくり倒せる点が、面白い点なのだろうと思う。
そして、その両方に詳しい人はほとんどいないので、Redmineコミュニティで多種多様な人達が集まることで色んなメリットが出てくる。

僕もRubyやRailsをちょっとずつ勉強しなくては、ね。。

他の資料はコチラ。

| | コメント (0)

2017/11/15

データ分析の課題はどこにあるのか

「データ分析の力 因果関係に迫る思考法」を読んで、データ分析の課題はどこにあるのか、理解できたことをメモ。
ロジカルでないラフなメモ書き。
初心者の妄想なので、間違っていたら後で直す。

【参考】
データ分析の面白さはどこにあるのか: プログラマの思索

【1】データ分析の課題はどこにあるのか?

僕の感想では、現時点におけるデータ分析の課題は、次の3つがあると思う。

・データ分析から得られる結論の再現性はあるのか?
・データ分析したい研究者は、自由にデータを収集できる環境にあるか?
・得られた因果関係はマクロレベルだけでなく、個人というミクロレベルでも正しいのか?

【1-1】データ分析から得られる結論の再現性はあるのか?

最近のパワフルな環境で、いくらデータ分析できたとしても、その結果に再現性がなければ無意味。
間違った前提条件でデータをこねくり回しても、その検定処理が有意であるか、とはすぐには言えない。

「データ分析の力 因果関係に迫る思考法」を読むと、データ分析の結果の再現性を保証するために、数多くの理論が提唱されている。
また、そういう理論の前提条件を満たしているか、というデータの事前準備の方にかなり神経を使っているのがよく分かる。

【1-1-1】「データ分析の力 因果関係に迫る思考法」では、データ分析の再現性を保証するための手法として、いくつか紹介されている。
まず、「ランダム化比較試験」が最も推奨される方法。
次に、「自然実験」と呼ばれる手法があり、「回帰不連続設計法」「集計分析」「パネル・データ分析」があげられている。
(個人的には、「疑似実験」と呼ぶ方がしっくりくると感じる。
あたかも、反実仮想の条件が揃った、という意味を連想させるから)

確かに、フィッシャーの3原則「局所管理(小分け)の原則」「繰り返し(反復)の原則」「無作為化(ランダム化)の原則」を思い出せば、サンプルをランダムに抽出するようにデータを作ればいい。
その理論は、既に数十年以上前から知られている。
よって、ランダム化比較試験では、データ分析よりも、実験しやすいようにランダムとなるデータを事前準備することに注力する、という点で最も納得できる。

すると、ABテストのように、Webシステムやセンサー機器の方が、ランダム化比較試験を実施しやすいだろう。
広範囲なデータ収集のコストが低いので、システム側でコントロールしやすいだろうから。
換言すれば、ビッグデータとかIOTのようなバズワードが流行するのは、ランダム化比較試験の環境を構築しやすい点にあるからだろう。

そのデータ分析手法が、最先端のIT会社で使われて新たなビジネスモデルを生み出し、さらに政府の政策効果の評価手法にまで影響を及ぼしているわけだ。
昨今のアジャイル開発、リーンスタートアップという手法も、ランダム化比較試験を用いたデータ分析による高速なPDCAサイクルと見なせば、より理解しやすくなるのではないか。

【1-1-2】一方、既に得られたデータや公開されている各種統計データから、データ分析する手法「自然実験」もいくつかある。

たとえば、「回帰不連続設計法」は、非連続となる境界値に着目して、因果関係を見出す手法。
「集計分析」は、境界値が階段状となる制約条件に着して、因果関係を見出す手法。
「パネル・データ分析」は、時系列の統計データで、自然に介入群と対照群が分かれているデータに着目して、因果関係を見出す手法。

たとえば、「回帰不連続設計法」の例では、70歳の分岐点で日本人の医療費が極端に上昇する点に着目して、70歳に医療費負担が3割から1割に減る政策によって、逆に医療費が増えている、という因果関係を示している。
「集計分析」の例では、自動車の燃費規制の政策が、車の重量が増えることで燃費の制約が下がる負のインセンティブを発生させて、車体を重くすることで燃費の悪さを助長し、交通事故の損害を増やしている、という因果関係を示している。
「パネル・データ分析」の例では、デンマークで所得税率を下げることで、優秀な移民が増えている効果がある、という因果関係を示している。

そういう事例と実験手法を読むと、得られた因果関係の結論が面白い一方、その結論の再現性や正しさを保証するのに相当苦労している、と感じる。

【1-1-3】他にも思いつく課題をいくつか、適当に書いておく。

データ分析で得られた因果関係は、実験対象の集団や個人の範囲を超えて、他の集団にも適用できるのか?
データ分析の再現性は、どこまで言えるのか?
外的妥当性と内的妥当性の問題。

「実際には起こらなかった潜在的な効果を測定できない」という「因果的推論の根本問題」はどこまで解決できるか?

因果関係が出た事象に対し、「そうではなかった場合」=反実仮想をどうやって作り出し、データ分析する実験をどうやって準備すべきか?

実験をやることによって、実験対象の集団に副次効果が発生して、実験当初の前提条件を崩してしまう場合がある。
その話は、「風が吹けば桶屋が儲かる」「バタフライ効果」を思い出させる。
ほんの少しの発端から始まった因果関係が、大きな影響を与えているのではないか、という考え。

そんな課題を洗い出してみると、社会科学の実験は、自然科学の実験手法を流用しながらも、いかに結果を再現させるか、という課題を解決するために、ものすごく労力を費やしているように思える。
逆に言えば、再現性に関する面倒な議論は、そういう発端があるのだ、と考えればいいかもしれない。

ABテストのような実験環境を、Webだけでなく人間の集団にも適用して、因果関係の発掘をどんどん推し進めたいわけだ。

【1-2】データ分析したい研究者は、自由にデータを収集できる環境にあるか?

【1-2-1】ランダム化比較試験をやるには、いくらWebシステムなどで自動収集できるといっても、システムを構築するコストが発生する。
ゆえに、研究者個人が手っ取り早く、データを集めて研究したい時、既存の統計データを流用して、自然実験の各種手法を使ってみたい。

しかし、社会や教育など、個人情報に関わるデータはそう簡単にアクセスできない。
個人情報が削除されたデータは、個票の属性情報がかなり抜けているだろうし、そのデータの信憑性が悪い。
たぶん、研究者が使いたいレベルの詳細な情報を取得するには、たぶん公開されている統計データだけでは不足する場合が多いのではないか。

学力の経済学」のように、本来は税金を投入して集められた学力テストのデータを個人レベルまで収集し、そのデータを使って、いろんな観点で因果関係を分析したいはずだ。
しかし、そういう個人情報が含められたデータは、そのまま公開されると悪用されやすい。
また、政治的影響も大きいだろうから、中途半端なデータとしてしか収集できていないのではないか。

【1-2-2】「自然実験」の各種手法では、いかに良質なデータにアクセスできるか、という課題がある。

本来は、政府が経済・社会・教育などのデータを収集して、一元管理して、研究者に公開したり、もっと一般に広く公開するのがいい。
そうすれば、オープンソースのように、優秀な技術者や学者が、無料でそれらデータを分析してその結果を公開してくれるはず。
実際、「学力の経済学」では、南アフリカでは国の統計データが公開されているらしいが、その理由は、公開しておけば、世界中の学者が統計データを使って、補助金を出すことなく無料で研究してくれて、その成果を出してくれるからだ、という一節があった。

その流れが、オープンデータという考え方なのだろう。

オープンデータ - Wikipedia

オープンソースの魅力である「世界中の優秀な開発者や熱心なユーザの力を利用して、無料でソフトウェアを構築・改善していく」手法を、データ分析の世界にも適用したいわけだ。
そういう発想が進んでいるのが米国などの欧米諸国なのだろう。
そして、日本はたぶんその流れに遅れているのだろう。

とはいえ、日本でもオープンデータの流れがある。

総務省|ICT利活用の促進|オープンデータ戦略の推進

現在の日本の環境でも、個人レベルでクラウド環境は整備できるし、R言語やPythonなどのプログラミング環境もあり、そのノウハウもネット上にいくらでもあるのだから、個人の研究者レベルでデータ分析して研究する、というやり方も現実的なはず。

【1-3】得られた因果関係はマクロレベルだけでなく、個人というミクロレベルでも正しいのか?

データの再現性の問題は「外部妥当性」がどこまで保証されているか、という内容と関係する。
つまり、実験対象の集団を超えて、他の集団にも因果関係を適用できるのか?

「データ分析の力 因果関係に迫る思考法」では、ランダム化比較試験では外部妥当性まで保証できる、と言われているが、他の実験手法では限界がある時もある、とのこと。

でも、データ分析して得られた因果関係は実験対象の集団に適用できても、その集団の中にいる個人まで適用できるのか?
集団にはそういう傾向がある、と言っても、個人レベルでは、その傾向の濃淡は様々だ。

経済現象では納得できても、教育や政治などのセンシティブな話題で個人レベルまで適用されると、自分は違うよ、と天邪鬼になる人も多いのではないか?

この辺りはまだよく分からない。

【2】現在のデータ分析にそういう課題があるとしても、今後はますます有用性が高まるに違いない。
なぜなら、統計学の理論は既に広く深く成立していて、プログラムとすごく相性がいいからだ。
また、データが膨大であっても、クラウドに配置すればいいし、処理性能もクラウド環境の方が調整しやすいから。

特にWebシステムでは、個人の行動履歴をログとして自然に蓄積しやすいので、データ収集のコストがすごく低い。
後は、コンピュータの性能に任せて、大量データをいくらでもデータマイニングすればいい。

その時に、各種の統計理論を使って、どの理論がとても有効であるのか、という理論の評価もできるはず。
つまり、従来はこの理論の方が良いと考えられていたとしても、実際に使ってみたら、そうではなかった、とか、むしろ、この理論であるべきだ、という知見がもっと出てくるだろう。

たとえば、「How Google Works」の本では、人の能力は、身長のような正規分布ではない、むしろべき分布のように偏っている方が自然だ、と主張していて、なるほどを思った。
こういう知見は専門家からすれば当たり前なのかもしれないが、素人からすれば非常に興味深い。

個人的にはそういう新たな知見をもっと知りたいし、研究してみたいなと思う。

【3】他に、僕が興味を持っているアジャイル開発やRedmineにも、データ分析の知見を活用することはできるか?

アジャイル開発だけでなく、リーンスタートアップ、MVPによるビジネスモデルの仮説検証は、データ分析の手法なくして実現できないのではないか?
換言すれば、AARRRのようなWebデータ解析手法が整ったからこそ、リーンスタートアップのようなWebのビジネスモデルの検証がやりやすくなったのではないか。

また、Redmineはソフトウェア工学に関するデータ収集基盤である、と位置づければ、今までのデータ分析の手法を使って、新たな知見を導き出すことができるのではないか。
たとえば、組織文化が異なる2つのチームに対し、Redmineのチケットをデータ分析したら、いくつかの因果関係を示せた、のようなことはできないか?

考えたことはまたまとめてみる。

【追記】
「小中学生のワクチン集団接種を止めると、高齢者のインフルエンザ死亡率が高まる」という記事が紹介されている。
この内容は、自然実験である「パネル・データ分析」を使った統計分析手法を使っているのではないか、と推測される。

小中学生のワクチン集団接種 をやめたら、インフルエンザ で亡くなるお年寄りが増えた。なぜ? (ハフポスト日本版) - Yahoo!ニュース

akipiiさんのツイート: "「小中学生のワクチン集団接種が高年齢者のインフル死亡率を下げていた」という事実を統計的分析から示している。統計学の有用性を示す良記事。小中学生のワクチン集団接種 をやめたら、インフルエンザ で亡くなるお年寄りが増えた。なぜ? (ハフポスト日本版) https://t.co/oHGgNoT0tR"

なぜなら、予防接種を受けた時代とそうでない時代の時系列の統計データが既にあり、その統計データを元に、介入群と対照群にきちんと区別できるように統計処理して、小中学生のワクチン集団接種率と高齢者のインフルエンザ死亡率の相関関係や因果関係を分析しているのではないか、と推測されるからだ。
予防接種は政府が推進した政策であるので、事前準備のデータもその効果を測定したデータもきちんと記録されていて、データの精度も高いのではないか、と思うからだ。

そういう統計データを元に、今年のインフルエンザ大流行の真因を分析できること、そして、その対策の効果について、数多くの人達に知らしめることができる、ということを考えれば、統計学の有用性は非常に高いのだろう、と思う。

| | コメント (0)

2017/11/11

データ分析の面白さはどこにあるのか

最近、統計学を勉強してみて、データ分析の面白さと課題について、色々感じるものがあった。
長くなったので、「データ分析の面白さ」だけ書いてみる。
以下はラフなメモ書き。
初心者の妄想なので、間違っていたら後で直す。

【参考】
データサイエンスのすゝめ — シリコンバレーに全てを飲み込まれる前に – learn data science

【1】データ分析の面白さはどこにあるのか?

【1-1】時代がようやく統計学の理論に追いついた、という点が面白いのだろう、と思う。
コンピュータが貴重であった頃、データ量が多いほど、データ分析は手計算では正直無理。
だから、いかに計算を省略するか、という所に力を入れて研究されていた。

また、大量のデータを収集する作業そのものも難しかったから、いかに少ない標本数でデータ分析の精度を高めるか、という研究が多くなされていた。
たとえば、コンピュータがない時代で、国勢調査で全国民からアンケート用紙を記入して回収し、集計する作業がどれだけ大変だったか、コストがかかるものだったのか、考えればいい。

しかし、今は、コンピュータの処理能力が劇的に向上し、Excelでも簡単に計算できるようになった。
今は、Excelで箱ひげ図も描ける。
データ量が増えても、クラウド環境、R言語などの優れたプログラミング言語などの開発環境が揃って、問題ない。
また、Webシステムや組込システムのセンサーのように、人手をかけずに機械が自動的にアクセス・ログを集集する仕組みが整ってきている。
むしろ、データがたくさんあるほど、幅広く奥深くデータを検証できる。

さらに、統計学の理論は既に固まっている。
したがって、データ分析の手法の仕様が決まっているので、プログラムに落としやすい。

また、あるいは、データ分析で得られた因果関係を、他の環境でも再現できる確率はどれくらいなのか、とか、データの再現性に関わる議論は、既に数多くの理論で提唱されている。
たとえば、データ分析の手法がどこまで、因果関係や相関関係などの正しさを保証できるか、とか。
そういうデータ再現の保証が理論で提示されているので、データ収集の前提条件さえきちんと詰めておけば、いくらでもプログラムでデータ分析できるし、今まで知られなかった因果関係を導き出すことができるはず。

【1-2】統計学の応用は、昔から幅広く行われていた。

医学の分野では、コレラとか流行の病気の原因追求、新薬の効き目の効果測定など。
経済学なら、国勢調査で、人口統計や住所、財産などの傾向分析など。
教育・心理学なら、学力テストによる知能の測定とか、アンケートによる行動の分析、とか。
生産管理なら、大量製造による量産品の品質管理。管理図とか、散布図とか。

つまり、コンピュータが使われる以前から、数多くの方面で統計学は応用されていたし、データ分析もなされていた。
では、最近はどういう点が違っていて、どういう点が面白いのか?

【1-3】今は、教育・人事やマーケティング、経済学への適用が興味深いのだろう、と思う。

【1-3-1】「郊外の小売店では、ビールと紙おむつが関連購買でよく売れる」という都市伝説は、データマイニングによるマーケティングへの応用。
大量のPOSデータから関連購買を分析すればいい。

特に、Webの販売サイトでは、アクセスログや購買履歴を個人レベルで簡単に蓄積できるので、データクリーニングさえできれば、いくらでもデータマイニングできる。
そういう経緯もあって、販促の経験則も、AIDMAからAARRRへ変わったのだろうと思う。

「AARRR」 今更だけど抑えておくべきグロースハッカーのコンバージョンの見方 - Content Hub(コンテンツハブ) | ナイル株式会社

たとえば、ユーザのアクセスログから、導線を推測して、逆にユーザを誘導して購買させるWebサイト作りへ変化させる。

また、ABテストも、Webシステムだからこそやりやすい手法。

ABテストとは ? 今さら聞けないABテストの基礎中の基礎まとめ | 株式会社アッション

多数の人達から、無作為に選んでもらう環境作りは普通は難しいが、Webサイトでは、フィッシャーの3原則「局所管理(小分け)の原則」「繰り返し(反復)の原則」「無作為化の原則」の条件を整えやすい。
つまり、Webサイトでは、ランダム化比較試験のような環境を作りやすいので、得られたデータ分析の結果も効果が出やすいのだろう。

最近、ソフトウェアが世界を食うという事象が頻繁に見られる理由は、Webサイトから安価に大量の顧客データを収集できて、それらをデータ分析で因果関係や相関関係などの結果を導き出し、より効果的な施策を実施できるビジネスモデルができているからではないか。
そういうビジネスモデルを持たない従来の企業は、そういう新興企業に押されている、という状況なのだろう。

「ソフトウェアが世界を飲み込む理由」「ソフトウエア、それが問題だ」の記事のメモ: プログラマの思索

【1-3-2】心理学への統計学の応用では、人の行動に焦点を当てた分析結果が有用だろうと思う。
たとえば、リーダーシップ条件適応理論では、リーダーシップは部下の成熟度で変化させるべきだ、という結論がとても参考になった。
皆薄々感じているけれど、実際の計測データを元に導き出された結果なので、信頼性が高いのだろう。

日本データ分析をバックにした理論が少ないと聞くが、三隅二不二によって提唱されたリーダーシップ理論であるPM理論が唯一の理論らしい、と聞いた。

この分野で目を引くのは、Googleの施策ではないか。
「ワーク・ルールズ」の本を読むと、Googleでは人事施策や組織文化に関する問題解決手法とデータ分析を頻繁に使っている。
人の能力、モチベーション、業績評価などをより良いものにするデータ分析を使って、どんどん改善していく。
その様は、生産管理における品質管理のカイゼン手法を連想させる。
人も部品と同じように、品質管理されて、良い品質を保つように改善されていくわけだ。

「ワーク・ルールズ」の感想: プログラマの思索

日本の品質管理がISO9001やシックスシグマに変わっていった歴史: プログラマの思索

【1-3-3】計量経済学という分野がまさに統計学と密接に関わる分野になるらしい。

経済学は自然科学とは違い、規範的な学問であるという立場を主張するならば、政治での政策効果や費用対効果を計測することで、政策を評価することが重要になってくる。
たとえば、ある政党がある政策を採用して実行すると決めたならば、その政策の効果が本当に出たのか検証すべきだし、その結果、効果よりもコストが大きくて損したならば、その政策はやめるべきだ。

つまり、各種の条件や前提をおいた後で、補助金や予算による政府の投資でどれだけの効果があるか、事前に推定できるならば推定して、政策実行を判断したいし、実際に実行した結果と事前推定の結果との比較分析からさらに多くの知見が得られるだろう。

そもそも、ミクロ経済学では、消費者行動や企業行動をパレート最適などの前提条件のもとで、消費者や企業は経済合理的に最適な行動を選択する、と仮定しているので、理論を当てはめやすい。
本当にそうなのか、は不明だが。

エビデンス・ベースの政策作りが米国では流行している、と聞くが、その理由は、経済学の理論や統計的手法とコンピュータによるデータ分析がうまく組み合わさって、政策の効果測定が簡単に実現できるようになったから、という背景もあるのだろう。
そういう雰囲気が進めば、Webシステム開発やデータ分析のできるプログラマはより重宝されるようになるのだろう。

【1-3-4】最近では、政治の世界でも経済学の重要性がすごく大きくなっている。
政治の政策作りの殆どが年金、医療、教育、中小企業に関わる補助金のバラマキが主になってくれば、そのばらまきが本当に効果があるのか、経済学の知見を使いたくなってくるのだろう。

教育経済学という分野を初めて知ったけれど、教育という古い分野に経済学における費用対効果の手法を適用することで、教育施策の政策効果を測定し、より効果的な教育政策を採用しよう、という考え方は面白い。

「エビデンスベースト」が日本の教育を変える?中室牧子氏に聞く | eduview

たとえば、少人数学級の方が効果があるのか、紙の書籍よりもiPadを与えた方が効果があるのか、大学生に奨学金を与えると効果が出るのか、とか。
こういう教育政策はとてもセンシティブな内容なので、得られたデータ分析の結果は本当に正しいのか、と疑ってしまいがちだが、経済学と統計学の手法を組合せて簡単に政策効果を評価できるなら、どんどん使っていくべきなのだろう。

従来の政策を運用したコストよりも効果が少なければ、その政策はむしろ破棄すべきだろうから。

【1-3-5】最近、IOTが注目される理由は、スマートフォンのみならず、全てのハードウェアにセンサーを組み込んで、いくらでもログを簡単に収集できる仕組みが整った点だろう。
つまり、Webシステムで緩やかにログを収集する構造と同じ仕組みを、Web業者だけでなく、メーカーも作れることが大きなメリットなのだろう。

たとえば、メーカーも収集したログやデータを分析することで、機械が故障する予兆を事前に把握して予知保全を行う、などといった手法を取れる。
あるいは、機械を扱うユーザの行動をログで記録して、CRMで分析して次世代の新製品開発に活用する、という使い方もできる。
さらには、ABテストみたいに、製品利用の課金サービスの売上を上げるために、製品が運用される環境を故意に作ってランダムにテストし、どのパターンが最も効果的なのか、を検証することもできる。

すなわち、Web業者が販売システムでAARRRやCRM、ABテストなどのデータ分析・活用をやっているのと同じやり方を、メーカーも行える基盤が整った、という点がIOTで最も重要な観点なのだろう。
メーカーも、GoogleやAmazonなどと同じ土俵にようやく立てる基盤が整ったわけだ。
但し、だからといって、メーカーがすぐに、最先端テクノロジーを持つWeb系ライバル業者と競争できる力を持てるわけではないだろう。

あくまでも、シリコンバレーのAmazon、Google、Facebookのような企業と同等の開発基盤を、メーカーにもIOTによって同じように持つことができるようになっただけに過ぎない。
メーカーの組織文化は、シリコンバレーのIT企業のそれとは全く違う。
どこまで彼らが変化できるのか、じっくり見てみたい所。

| | コメント (0)

第13回東京Redmine勉強会の見所 #redmineT

@madowindaheadさんが第13回東京Redmine勉強会の見所を公開されていたので、自分も書いておく。
以下、ラフなメモ書き。

【参考】
第13回勉強会 - redmine.tokyo

門屋 浩文さんのツイート: "来週の第13回https://t.co/EeqCzge6c7の見どころ! #redmineT https://t.co/7T2RrBBjUb @madowindaheadさんから"

第13回redmine.tokyoの見どころ! | MadosanPlace 新しい風をプラス!

【1】今回のテーマは『Redmineの今と未来』。
スタッフと企画した時に、Redmineの運用や管理面の講演は現時点の話、次期バージョン4.0に伴う技術面の講演は未来の話だね、という意見が出て、このテーマに決まった。

【1-1】運用面の話は、見える化の話とJAXAの利用事例のお話。
Redmineのチケット集計結果を見える化する内容は、特に、プロジェクトリーダー層が興味を持つだろう。
彼らから改善要望として出てくる意見のほとんどが、このテーマに関わる内容だからだ。

また、JAXAのRedmine利用事例をようやく東京でも講演頂けるようになった。
昨年夏にRedmine大阪で講演して頂きましたが、その時の内容からブラッシュアップされている、とのこと。

JAXAのスーパーコンピュータ活用課でRedmineを使ったチケット管理システムの経験論文: プログラマの思索

日本の大企業におけるRedmineの利用事例の資料のリンク: プログラマの思索

JAXAのRedmine利用事例で興味深いのは、Redmineの機能を論理モデルの観点で階層構造でモデル化していること、その分析内容を元に「ロールのORルール」「カスタムフィールドのANDルール」などのプラクティスを生み出して、利用プロジェクトの多様性をRedmineの機能で制御しようとしている点だ。

JAXAのRedmineモデル~Redmineはレイヤ構造になっている: プログラマの思索

これは、アナリシスパターンにおける「知識レベル・操作レベル」に相当する、という指摘もあった。
その後、他にどのようなプラクティスを研究されているのか、楽しみ。

【1-2】Redmineの次期バージョン4.0では、Rails5に対応が予定されているので、アーキテクチャが大幅に変わることになる。
特に、既存のRedmineのプラグインは、現状のままでは全く動かなくなる、という指摘があった。

そこで、Rails5におけるプラグイン開発の内容、さらに初心者向けにRedmineプラグイン開発のお話も合わせて、アジャイルウェアの堂端さんに講演を依頼することになった。
日本では、OSSのプラグイン開発者が多いし、スタッフにもプラグイン開発者がいるので、直接的に役立つだろうと思う。

【1-3】LTでは、数多くの方に講演していただくことになった。

特に、ファーエンドテクノロジーの石川さんのお話が個人的に興味がある。
理由は、Redmine本家にガントチャートの改善パッチを送られているからだ。

Redmineのガントチャート改善パッチに注目している: プログラマの思索でも書いたけれど、Redmine標準のガントチャートは正直使いにくい。
チケットタイトル欄の枠を広げたい、担当者を表示したい、ガントチャート画面上で編集したい、などの改善要望は2010年頃からずっと、Redmine本家にも要望があがっていたのに、ずっと改善されて来なかった。
しかし、ようやく、石川さんがパッチを送ってくれて実現可能性が上がった。
今は、Ver4.1のターゲットバージョンで設定されている。

Redmineを改善するパッチを書いて、OSSへの貢献もする仕事 - ファーエンドテクノロジー株式会社

また、日本ではRedmineの利用度合いが高いのに、Redmine本家へのフィードバックが少ない状況に対し、石川さん他幾人から、Redmine本家へのパッチが最近あげられている。
まだ少ないけれど、利用ユーザだけでなく開発者として日本人も貢献できればいいな、と思う。
(自分もやらねば、ね。。)

| | コメント (0)

« 2017年10月 | トップページ | 2017年12月 »