« 2014年1月 | トップページ | 2014年3月 »

2014年2月

2014/02/28

TOCの思考プロセスの使い道~プロマネの説明責任に応用する

ゴールドラット博士の論理思考プロセス―TOCで最強の会社を創り出せ!」を読んで、TOCの思考プロセスをプロマネの説明責任に適用できそうな気がした。
ラフなメモ書き。

【1】背景
【1-1】プロジェクトマネージャの仕事のほとんどは、利害関係者の間で発生する課題の解決、ないし利害関係者への調整だ。

例えば、顧客は、システムのこの要件は納期までにリリースされないと困る。
しかし、開発チームは、その要件は実現可能性が難しく、納期までに間に合わない、と言って、対立が生じる。

あるいは、テスト工程で一挙に問題が噴出し、要件漏れ、設計漏れ、単体テスト漏れなどの障害が多発し、何が問題なのか、という構造も見えなくなる時もある。

プロジェクトにまつわる色んな問題は、どんな構造を持っているのか?
利害関係者同士で対立が発生した時、どのように解決するのか? あるいは調整するのか?

【1-2】自分自身の体験としてはPMOのような役割でプロジェクト支援に入った時に、いつも気になることがある。
それは、利害関係者ごとに問題の観点が違うので、それを解きほぐし、本来の問題とゴールを導いて、納得してもらうのに、ものすごくパワーがかかること。

例えば、部課長であれば、プロジェクトが黒字になるように仕事してくれ。
プロジェクトリーダーならば、納期までに無事にリリースしたい。
新しい技術が好きなプログラマならば、新しい技術を試したり、自分の華麗なコーディングを見せつけたい。
新人プログラマならば、先輩のように、自分も早くアウトプットを出して、能力があるのを見せたい。
皆の立場で、プロジェクトに対する意識は全く違う。

最近、TOCの論理思考プロセスの対立解消図でこんな一節があった。
「対立は現実には存在しない。認識の中にだけ存在する」

まさにそうで、利害関係者の頭にある現実が衝突しているだけ。
彼らの頭にある前提条件を崩せば、対立は消える。
そのために、いかに彼らを説得し、世界観を変えてもらうか、にすごくパワーが要る。

説明のロジックとして、対立解消図が使えないか、色々探っている。

【2】TOCの思考プロセスには、5つのツールがある。

【2-1】現状分析ツリー

現状分析ツリーは、現状の問題点から原因をツリー構造で深掘りしていく手法。
原因と結果のロジックを突き詰めて深掘りしていく。
個人的印象としては、ロジカルシンキングで問題を深掘りしていくのに似ている。

以下の記事が詳しい。

要求工学 第27回:論理思考プロセスと現状分析ツリー(要求工学:Requirements Engineering)

思考プロセス入門(3) 現状問題構造ツリーの作成方法 | TOC | 飯塚革新コンサルティング

問題認識の手法4―現状分析2: サラヒン ~ サラリーマンによるサラリーマンのための仕事のヒント

問題解決の7ステップ1: サラヒン ~ サラリーマンによるサラリーマンのための仕事のヒント

現状分析ツリーで面白い点は「問題は2つの原因を持っている」という特有の考え方があるらしい。


(引用開始)
この思考プロセスで目からウロコが落ちたのは、

 ・問題は単独では発生しない
 ・問題は2つの原因を持っている

というところ。
これからすっかりTOCの信者になりました。
(引用終了)

(引用開始)
このTOCを学ぶ前までは、すごく単純に

 原因 → 問題

のような図式で考えてました。つまり、ある問題にはたった一つの原因がある。
(中略)
ところが、多くの業務をする上でのプロセスというのは、非常に複雑なので、このプログラムのような単純な要因になるものではありません。その時に、

 ある事象とある行為が重なると問題が起きる
 ある行為とある行為が重なると問題が起きる

という考え方が、TOCにはあります。
(引用終了)

現状分析ツリーでは、問題を引き起こす原因が2つ以上あった場合、OR条件、AND条件、増幅条件の3つで表現する。
OR条件は、原因がそれぞれ独立している。
AND条件は、複数の原因が同時に発生して、初めて問題が現れることを意味する。
増幅条件は、複数の原因が加算されて増幅されることを意味する。

これらの原因には微妙な違いがあるので注意。

現状分析ツリーでは、「もし~(原因)~ならば~(問題)~になる」と読む。
その内容で、なにかおかしいと感じたら、論理に破綻が生じているので直す。

現状分析ツリーの使い道は、問題の症状と原因の構造を明確にすること。
それは、問題が起きている現状のスナップショット。
根本原因を突き止めることで、問題を引き起こす制約条件を見つけることができる。

普通は、悪循環の構造を持つ問題が発生したら、その構造を壊すような変化を与えることが解決の糸口。
つまり、故意に変化を起こすことが解決方法の一つ。

問題の構造を壊さなければ、現状は何も変わらないから。
その時に、制約条件を突き止めることが出来れば、その部分をいじることで、変化を起こすことができる。

【2-2】クラウド(対立解消図)

例えば、対立している状況では、2つの選択肢のどちらかを選ばなくてはいけないが、どちらの選択肢も全ての利害関係者を納得させられない。
あるいは、対立が隠れており、そのために現場が停滞している状況もある。
後者は、問題が認識されているにもかかわらず、どうやっても解決できず、無力感が漂う状況などがある。

普通は、対立した状況では、妥協ないし、どちらかの選択肢を選択してWin-Loseの関係にする場合が多い。

このような対立の状況から、Win-Winの解決策を可能にするのがクラウド。

クラウドの別名は対立解消図。
ある目的(ゴール)に対し、利害関係者が相反する要求を出し、対立を起こしている構造を明確にする。

クラウドでは、ゴール←2つの要件←2つの前提条件 という構造で表し、2つの前提条件が対立しているように表示する。

クラウドによる解決方法は、どちらか又は両方の前提条件を崩し、別の解決方法(インジェクション)で要求を満たすようにする。

対立の解消は、プロマネの調整技法としてとても重要だ。
利害関係者との調整とは、妥協とトレードオフが一般的で、誰かに不満を残す。
クラウドを使えば、相手の前提条件を崩し、新たな解決策を提示して、Win-Winの関係を実現する事が可能。
プロジェクトマネジメント手法として、クラウドは重要な技法の一つ。

【2-3】未来現実ツリー

未来実現ツリーは、リスク対策に使う。

未来実現ツリーは、実施したい変革方法に対し、その影響結果をツリー構造で書いていく。
すると、良い影響もあれば、予期しない結果や、好ましくない結果が出てくる時もある。
つまり、今から実施する対策のシミュレーションとして使える。

【2-4】前提条件ツリー

前提条件ツリーは、PERT図そのものだ。

前提条件ツリーは、目標(ゴール)に対して、中間目標をツリー構造でブレイクダウンしていく。
すると、目標を実現するためのネットワーク図になる。
これがPERT図に相当する。

【2-5】移行ツリー

移行ツリーは、前提条件ツリーで図示したPERT図を具体的な作業手順のツリーへ詳細化したもの。

【3】TOCの思考プロセスが使える状況

上記の思考プロセスを使う状況は下記があげられるだろう。

・「現状分析ツリー」で、問題の構造を把握する or 問題の構造を説明する
・「クラウド(対立解消図)」で、利害関係者の対立を解消し、別の案を提示する
・「未来実現ツリー」をリスク対策の検証に使う
・「前提条件ツリー」「移行ツリー」でプロジェクトの概要スケジュールを作る

つまり、プロマネがやるべき仕事において、これらのツールはとても有効だ。
顧客や上司、開発チームのメンバーに対し、以下のような説明をする時が多い。

現状の問題の構造はこういうものだ。だから、この構造の背後にあるこの制約条件を壊してみよう。

2つの意見の対立は実はこういう構造を持っているが、実は、この前提条件は正しくなくて、このように考えれば、こんなアイデアで解決できる。

この対策を実施すると、こういう好ましい効果が得られるが、副作用として、このような不都合な結果も出てくるから、注意しよう。

この目標に対して、中間目標(マイルストーン)はこれこれであり、それぞれはいつまでに終わらせないといけないのが分かるよ、と。

こういう説明を論理的に行い、理解してもらうことで、人は初めて動く。
特に、IT業界のように能力の高い専門家集団の場合は、威圧的に一方的に指示を出せばメンバーが動くわけではない。
むしろ、論理的に説明して納得してもらって、メンバーの能力を引き出せるのだ。

まだ実際の経験が足りないので、以上のアイデアを試してみる。

| | コメント (0)

Scrumの入門資料リンク

Scrumの入門資料リンクがあったのでメモ。
これだけの資料があれば、すごく参考になる。

SCRUM/アジャイル開発の入門資料を全力でまとめてみた - 酒と泪とRubyとRailsと

初心者向けとはいえ、資料が幅広い。
他人にScrumを説明する時に役立ちそう。

| | コメント (0)

ImpactMappingの感想~アジャイル開発が主流の時代のライトウェイトな要件定義手法

ImpactMappingの感想をメモ。
僕の感覚では、ImpactMappingはペルソナ分析に似ている。

【元ネタ】
「IMPACT MAPPING」まとめ その2 - @izumii19のブログ You play with the cards you’re dealt

「IMPACT MAPPING」読みました - Yasuo's Notebook

文化の違う者同士が言葉を交わすために:無心に仕様書と戦う生活は終わりにしたい - @IT

アジャイル時代のモデリング: アジャイルチーム拡大のためにはコードの次に何を保つべきなのか

NUCON に参加しました!:An Agile Way:ITmedia オルタナティブ・ブログ

デブサミで、『インパクトマッピング』のお話をしました!:An Agile Way:ITmedia オルタナティブ・ブログ

アジャイル時代のモデリング: アジャイルチーム拡大のためにはコードの次に何を保つべきなのか


【1】ImpactMappingの背景

文化の違う者同士が言葉を交わすために:無心に仕様書と戦う生活は終わりにしたい - @ITの記事が分かりやすい。

(引用開始)
開発現場では、しばしば指示された機能を作る際に「この機能は何のために作るのか」「どのように使うのか」という闇に覆われ、ただただ無心に仕様書と戦わなければならないことがある。
このような状況に陥ると、制作物に魂を込めることが難しくなる他、精神衛生上も良くない。
一方、指示する側の人間からすれば「なぜ、やってほしいことが伝わらないのだろう」となる。こうして、両者の間に距離が生じ始めるのだ。

平鍋氏は、このようなすれ違いを軽減するために、「IMPACT MAPPING(インパクトマッピング)」という手法を提案する。
IMPACT MAPPINGとは、マインドマップを使ってビジネス視点、技術者視点、デザイナー視点など、異なる視点を持つ人同士の対話を手助けし、「ビジネスの目的」を共有できるようにするものだ。
イベントでは、平鍋氏自らが運営するツール「astah*」の有償ユーザー数増加施策を用いてIMPACT MAPPINGの使用例を紹介。
(引用終了)

従来の要件定義では、大量のドキュメントを要件定義書として残し、開発チームに渡す。
しかし、その大量の要件定義書を元に、開発チームは全体像を理解し、システムの実現可能性を調査し、システムの詳細仕様へ落とさなければならない。
しかも、途中の工程で仕様変更が起きるのは普通だから、どんどん要件定義書が変わってしまい、膨大な要件をコントロールするのは難しくなる。

本番リリース時には、プロジェクト初期に作られた要件定義書とかけ離れたシステムになっているのが普通だろう。
そんな風景を開発者は何度も経験しているから、要件定義書を誰も読まなくなり、単なるキングファイルとして飾られる。

アジャイル開発では、ロードマップを元に、バックログからストーリーを順に実装して、順次リリースしていく。
要件は粒度の小さいストーリーに分割されており、バックログで優先順位付けされている。
ストーリーの優先順位は、ロードマップに従っている。
ロードマップは、プロダクトオーナーが決めた戦略方針に基づいている。

そのような仕組みがあるからこそ、アジャイル開発では、要件定義書は必要最低限でよく、必要な時に必要なだけ作る。
そのために、要件定義の作成プロセスは各スプリントに分散され、プロジェクト初期だけとは限らない。

しかし、要件定義の重要性がなくなったわけではない。
アジャイル開発においても、なぜ、そのストーリーを実装するのか、という理由は、開発チームになかなか伝わらない。
だから、本来のシステムとは違った機能として実装されるリスクはアジャイル開発でもある。
但し、アジャイル開発では、スプリントが終わるたびに利害関係者がデモで評価するので、早めにリスクを検知して、大きな失敗を回避することはできる。

【2】ImpactMappingの手法

ImpactMappingは、マインドマップを使った要件定義手法。
ビジネスの目標をアクター(システム利用者)の利用シーンを明確にすることで、本来のストーリーの存在意義を開発者に伝えようとする。

ImpactMappingで書かれるマインドマップの要素には、以下がある。

ゴール(Goal):ビジネスの目標
アクター(Actor):システムの利用者
行動(Impact):システムの利用者に期待する行動
成果物(Delivery):利用者の行動を促すシステムの機能

「機能ではなくビジネスゴールをデリバリする」という意味は、「システムを導入するだけではなく、ユーザにビジネス価値を届ける」事だと思う。
システムの機能は、ユーザにある場面でこう使って欲しいという「利用シーン」を提供している。
つまり、機能の背後には、ユーザがいる。

ここで、システムの機能は、全てのユーザが使うわけではないし、特定のユーザがシステムを使う場面(利用シーン)の一つにすぎない。
そのユーザの利用シーンを開発者に意識させてくれる。

利用シーンを開発者が意識すれば、こんなユーザインターフェイスがいいだろうという発想につながって、ユーザビリティや性能要件の改善にもつながるだろう。
また、利用シーンを受入テストのシナリオにマッピングすれば、受入テストの精度も高くなる。

Twitter / akipii:@hiranabeさんのImpactMappingの使い方が参考になる。製品よりも製品を使うユーザ、ユーザの利用状況を開発者に伝えるわけか。文化の違う者同士が言葉を交わすために:無心に仕様書と戦う生活は終わりにしたい - @IT http://www.atmarkit.co.jp/ait/articles/1402/27/news021.html

平鍋さんのImpactMappingの例がとても分かりやすい。

・ゴール:astah*の海外有償ユーザーの増加

・アクター:利用ユーザー、TDM(テクニカルディ シジョンメーカー:CTO)、Rock Star(人前で話をする人)、マスメディア、販社、大学の先生、ソリューソンパートナー、広告代理店

・行動(Impact):
 →ユーザ:プラグインや評価レポートを書いてもらう、SNSでシェアしてもらう
  TDM(CTO):成功事例を公表してもらう
  Rock Star:テンションを高めるためにプレゼンで製品を紹介してもらう

・成果物:(略)

【3】ImpactMappingの効果

ImpactMappingで解決できる要件定義プロセスの問題は以下になる。

1・スコープクリープ(スコープの肥大化)
2・誤ったソリューション
3・誰かの好みで追加した機能
4・誤った仮説
5・場当たり的な優先付け

【4】ImpactMappingの感想

ビジネスに結びつける要件定義手法は、ImpactMapping以外にも、ビジネスモデル・ジェネレーション、リーンスタートアップなど、色々ある。
それらの中で、ImpactMappingが優れていると思う点は、具体的ですぐに使えることだ。

僕の感覚としては、ImpactMappingはペルソナ分析に似ている。
つまり、業務システムやWebサービスを使うユーザをペルソナとして想定し、ペルソナが使う利用状況をシナリオとして作り、そのシナリオを実現するような機能をシステムで提供する。

ペルソナ分析は以前から知られた手法だったが、ImpactMappingはマインドマップを使うことで、作成する敷居を大幅に下げている。
マインドマップを普段から使っている人なら、そんなにギャップを感じずにやれるだろう。

但し、ImpactMappingが要件定義の全ての問題を解決するわけではない。
平鍋さんが書かれた絵を見ると、ImpactMappingの立ち位置が垣間見える。

Twitter / hiranabe: マーケや企画と開発を繋ぐ手法っていろいろあるなぁ、Impact Mapping, User Story Mapping, Kano Model, 要求開発、と並べてみた。 pic.twitter.com/qMki8tjFPT

また、アジャイル時代のモデリング: アジャイルチーム拡大のためにはコードの次に何を保つべきなのかの記事にも、平鍋さんが、要件定義と成果物(システム、ソース)の間のギャップを埋めるために、どんな仕組みや手法が必要なのか、をラフなイメージ図で提示している。

平鍋さんの下記のTwitterも興味深い。

Twitter / hiranabe: 僕はこの10年間アジャイルとモデリングを押してきたが、両方ソフトウェア開発の本質を突いてると(自分では)思っている。今年は、この二つが結びついた形を探索したい。「コミュニケーションデザイン」としてのソフトウェア開発。

僕も、平鍋さんのやっている事に興味があるし、追いかけてみたいと思う。

【参考】

| | コメント (0)

アジャイル開発におけるユースケース駆動の要件定義手法~ユースケース2.0

InfoQのユースケース2.0の記事をリンクしておく。

【元ネタ】
アジャイルでユースケースを利用する - ユースケース2.0,スライシング,ラミネーティング

背景はこうだ。
従来の要件定義は、プロジェクト初期段階で、クライアント、ビジネスアナリスト、プロダクトオーナーが議論して要件を確定し、要件定義書を完成させる。
その要件定義書を開発チームに渡して、WF型開発で滝が流れる如く開発していく。

アジャイル開発の時代では、要件定義はプロジェクト初期段階に限定しないし、少数のモデラーやアナリストだけに限定しない。
必要十分な要件定義になるように、詳細が必要になった時にドキュメントを作る。
すると、アジャイル開発で使われるロードマップ、バックログに要件をリンクさせる要件定義手法が必要になってくる、と。

ここで、ユースケースは、オブジェクト指向分析・設計技法で要件定義の肝となる手法。
しかし、個人的には、ユースケースは余り役立った経験がない。
ユースケース図は、Excelの機能一覧、要件一覧と同じであるに過ぎず、情報量が少なすぎる。
ユースケース定義書は、重量すぎて、無駄なOffice文書を大量に発生させる。
その修正コストは結構大きい。

InfoQの記事では、アジャイル開発で使われるバックログに使えるようなユースケース定義手法を模索しているようだ。
詳細はよく分からないが、ユースケース簡易版を使って、バックログに入れるストーリーカードを代用しているように思える。

個人的には、ImpactMappingを使って、アクターから利用シーンを導き出し、要件を抽出する方が、もっと簡単に開発チームにその意図を伝えられると思う。


| | コメント (0)

2014/02/23

Redmineのワークフロー管理で見えるもの~いい加減なプロセスが見える化する

最近、Redmineエバンジェリストみたいに見られて、あちこちでRedmineを導入する役割を担う時が多い。
その時に、気付いたことについてメモ。

【1】開発チームが初めてRedmineを運用する場合、必要なトラッカーを最初に洗い出す。
その理由は、開発チームが必要とするワークフローは何か、を見つけ出したいからだ。
ワークフローの種類がその開発チームが持つべき開発プロセスの種類に相当する。

ワークフローは「タスク」の1種類だけではない。
「障害」管理もあるし、「課題」管理もある。
普通は、タスク・障害・課題の3種類は、ステータスもステータスの遷移もカスタムフィールドも違う。

【2】ステータスが違えば、ワークフローは別に増やした方がいい。
僕は、開発チームのプロジェクトリーダーやメンバーにヒヤリングした後、ワークフローのアクティビティ図や状態遷移図を書いて、このイメージで合っているか、を全員に確認する手法を取る。

すると、ワークフローで何らかのプロセスの漏れが判明する時がある。

例えば、仕様に従ってコーディングした後、タスクを終了にする時の判断基準は何か?を問う。
すると、メンバーがリーダーへ単なる報告をするだけで、自分でチケットをCloseするチームがいる。

話を聞くと、リーダーは複数の案件を抱えており、メンバーの作業や彼らが抱えている課題をチェックしていない。
だから、勝手に自分の都合で「終わった」と判断するらしい。
普通は、そういうチームは単体テストもろくにせず、そのまま納品して、結合テストで全く動かないという事例がとても多い。
つまり、リーダーによる作業の受け入れ検証が全くできていないのだ。

同様に、オフショアに設計書を送ってプログラムを納品してもらうが、その受入検証を社内で行わずにそのままスルーしてしまうことが判明したこともある。
ワークフローを書いてみると、オフショアの作業を納品した後の受入検証ないしリーダーの承認というプロセスがなかったのだ。

上記の例は、いわゆる「Doneの基準」がその開発チームではあいまいであり、リーダーとメンバーの間で合意が取れていなかった事実があったことが、ワークフロー設定で判明したわけだ。
そんなザルのようなワークフローならば、品質も悪く、納期に間に合わない案件が多くなるだろう。

おそらく他チームや他の会社でも、Redmineのワークフロー設定をする時に、開発プロセスの欠点が見える化されるのではないか、と考えている。
なあなあでやっているチームほど、ワークフローに穴が多い。

【3】カスタムフィールドも、各チーム、各案件によって微妙に違ってくるので、トラッカーを別に増やす時が多い。
同じ「タスク」であっても、設計やテスト、レビューではステータスの遷移は同じでも、カスタムフィールドが異なる時がある。
その理由は、普通は、成果物一覧(設計書)、テスト結果報告書、レビュー報告書などの帳票が別途必要であるために、それら帳票の項目をチケットに追加して記録したいために発生する。

普通は、プロジェクトリーダーにヒヤリングすると、そのような帳票は顧客や上司に提出するために必要であると聞くけれど、メンバーは実はそんな帳票の存在を知らなかったりする。
プロジェクトに必要な帳票が明確にされて、チーム全員で共有できるようになると、なぜこんなトラッカーが必要になるのか、という理由をメンバーも理解してくれるようになる。

つまり、プロジェクトリーダーが報告用に作る帳票を見える化したことで、今まで隠されていた開発プロセスが明確になったわけだ。

【4】かと言って、ワークフローをガチガチにすると、運用が面倒になる。
僕の経験で、ステータスを10個以上に増やして、10個以上のステータスを遷移して初めて終了できるようなワークフローを見かけた時がある。
すると、そのワークフローでは確かに厳格に管理できるが、チケットの滞留時間が長くなるために、チケットの棚卸しの管理工数がかなり大きくなる。

特に、ITILを導入した運用保守では、インシデント管理・問題管理・変更管理などの各チームや各プロセスへエスカレーションする仕組みになってしまうため、どうしてもステータスが増えやすく、ワークフローも複雑になりやすい。

リーン開発が教える所によれば、チケットの滞留時間はサイクルタイムに相当し、サイクルタイムが長いほど、顧客に価値ある製品をリリースできる納期がどんどん長引くことを意味している。
つまり、残チケットが多すぎるバックログになっていると、顧客の要望が即座に反映されない糞詰まりのような開発プロセスになっているのだ。
だから、バックログに残すチケットはできるだけ少なくする方が、顧客の新規要望を素早く反映できるようになる。

リーン開発で出てくる「WIP(Work In Progress)」という概念によって、バックログに入れるチケットの総数にWIPという最大値で制限をかけて、バックログが大きくなり過ぎないようにする。

【5】Redmineのワークフロー管理は最終的には、システム監査における証憑になるだろう。
つまり、プロジェクト内で発生するすべての作業は、しかるべき変更管理に基づいて、申請・承認のフローがあり、プロセスが改ざんを起こすことはない、という保証にもなるはずだ。

チケット駆動開発の良い点は、ワークフローはチケット管理システムの一機能に隠れているため、メンバーやリーダーもチケットを流すだけでよく、あまり考えなくてもいいことだ。
ツールがワークフローを保証してくれているので、流れてくるチケットを粛々とこなしていくだけでいい。

ワークフロー管理とその設定には、開発プロセスの問題点を全員の目にさらしてしてしまう特徴があるのがすごく面白い。
他にも考えてみたい。

| | コメント (0)

2014/02/22

PFD(プロセスフローダイアグラム)で開発プロセスを設計する

PFD(プロセスフローダイアグラム)についてメモ。

【元ネタ】
オブログ ? アクティビティ図で描くプロセスフロー

PFDによる開発プロセスのモデリング - 千里霧中

PFDの書き方(PDF)

Twitter / akipii: 後で見る RT @hiranabe: "アクティビティ図で書くプロセスフローダイアグラム" http://objectclub.tumblr.com/post/77009751972 …

開発プロセスを設計するという発想: プログラマの思索

【1】PFDが必要な背景

開発プロジェクトを受注して、プロジェクトマネージャがこれから計画を立てようとした時、普通は、MSProjectやExcelを前にして、手が止まってしまう場合がある。
どんな作業が必要なのか、それらの作業全てをすぐに思い浮かべられない時がある。

いわゆるWBS作成作業が必要になってくるが、その洗い出しはかなりあいまい。
そんなあいまいなWBSから詳細見積して、実際に開発してみたら、当初の計画とはかなり違っていた、という話はよく聞く。

そんな問題の背景には、PM・PLクラスの人達が開発プロセスを設計するという意識が薄いのが原因の一つではないか。
WF型開発で開発するといっても、各プロジェクトの成果物もプロセスも、どれも微妙に違うのが普通。
そのわずかな違いを意識せずに、標準プロセスをプロジェクトにそのまま当てはめると、痛い目にあう。

【2】PFDとは

XDDPという派生開発プロセスを提唱している清水吉男さんは、PFDというダイアグラムについて語っている。
PFDは、開発プロセスのDFD(データフローダイアグラム)みたいなもの。
つまり、開発プロジェクトのプロセスと成果物を図式化したもの。

PFDが書けるということは、開発プロジェクトに必要なプロセス(作業)と成果物の全貌が見えていることと同じ。
つまり、PFDを書くことによって、開発プロセスを設計していることになる。

例えば、PFDでプロセスと成果物が結ばれていなければ、それらは必要でないなら除去できるし、逆に見落としているプロセスや成果物を見つけ出すこともできる。
つまり、WBSの漏れをチェックする作業にPFDが使える。

【3】PFDの面白い点

PFDで面白いのは、インプットとなる情報には、要件定義所や設計書などのドキュメント以外に、「○○さんの知識」「○○さんの経験」のような暗黙知となる情報も記載できる点だ。
例えば、リプレース案件において、従来のシステムに熟知した人がいたとすれば、その人の暗黙知を元に、リバースエンジニアリングする作業もあるだろう。

あるいは、要件定義において、顧客からヒヤリングしながら要件をまとめる場合、顧客のヒヤリングが要件定義プロセスのインプットになるだろう。

すなわち、インプットとなる情報は、設計書のように目に見えるモノだけでなく、特定の人の知識・経験・ノウハウという暗黙知も含まれている場合があるのだ。
そういうプロセスは、アウトプットを作るために必要な情報を引き出すのが難しいだろうから、リスクがあり、何らかのリスク対策も必要であると、事前に考えることもできる。

他に注意すべき点は、プロセスが見積可能であること。
例えば「調査する」というプロセスでは、調査対象が未知で不明な場合、あいまいなプロセスになってしまい、見積りしづらく、プロジェクト実施後に大きく工数が狂う危険がある。
その場合、調査項目を抽出するプロセスと調査するプロセスに分けることで、調査項目のボリュームによって調査プロセスの工数を見積しやすくなる。

あるいは、プロセスがループするような図は要注意。
例えば、テストしてバグ修正して、さらにテストするような流れの場合、ループした図を書いてしまいがち。
しかし、実際はテストのプロセスは、バグ発見のプロセスとバグ修正の検証プロセスでは、作業量も作業内容も違う。
ループするプロセスを含むPFDを書いてしまう人は、プロセス設計の細部が見えてない場合が多い。

清水吉男さんが書かれた下記のPDF資料を参考にすると良い。

PFDの書き方(PDF)

【3】PFDの書き方

PFDはDFDみたいなものなので、Excel、PowerPoint、Visioなどで書くことができる。
Enterprise ArchitectでPFDを書くこともできる。

Enterprise Architect:プロセスフロー図(PFD)作成アドインについて

興味深いのは、オブログ ? アクティビティ図で描くプロセスフローにあるように、アクティビティ図でPFDを代用することだ。
そうすれば、UMLの一種として書けるから、astahのようなツールで簡単に書くこともできる。

【4】PFDの意義

PFDが明確に指摘することは、開発プロセスは設計すべき対象であり、各プロジェクトの現状に合うように柔軟であるべきことだ。

日本のSIが持つ標準プロセスは、WF型開発を基本としていて、業務標準化の名のもとに、「プロセスが固定」されている。
マーケットの変化によって、製品開発の内容が変わってしまえば、標準プロセスを一斉に適用するのはすごくリスクがある。

組織パターン」にあるように、変化の速いマーケットに対応できるように、並行開発やインクリメンタルな開発に対応している組織は、標準プロセスの例外に位置しており、その乖離をプロジェクトマネージャ自身も知っている。
なのに、プロジェクトマネージャは相変わらず、WF型開発に基づいた標準プロセスに合わせて、標準プロセスの範疇にあるように見せたがっている。
自分のプロジェクトは会社標準に従っている、と見せたいのだ。

PFDを使うことで、開発プロジェクトの特徴に合わせて、自由に開発プロセスを設計できるようになれば、WBSに落とし込んで見積しやすくなるだけでない。
プロジェクト後半に、進捗遅延の状況でリカバリー対策を立てる必要がある時、PFDを書いて、開発プロセスを再設計することもできる。
例えば、納期に間に合わせるならば、どのプロセスや成果物を省いたらよいか、どのプロセスを並行に作業させて納期を縮めるか、という発想をPFDが支援することもできる。

色々試してみる。

| | コメント (0)

Redmineのバックアップ処理

Redmineのバックアップ処理をメモ。

【元ネタ】
Redmineなど汎用的に使えるバックアップ処理(shellscript+cron+rsync) - Qiita

T2-Wonderland: 【ゼロから構築するRedmine】 第五回 Redmineの定期バックアップとリストアをするよ!(`・ω・´)

社内の数人の開発チームのタスク管理をRedmineでやる場合、最初は定期バックアップなんてあまり考えない。
でも、事業部全体、社内全体にRedmineが広がり、Redmineなしでは開発プロジェクトが回らなくなるような状況になると、定期バックアップは必要になる。
Redmineが壊れた、HDDが壊れた、ネットワークインフラが不安定になってRedmineが使えない、などの状況になると、Redmine中心のチケット駆動の開発プロジェクトでは、支障が出てくる。
文字通り、Redmineがソフトウェア開発の基幹システムになっているからだ。

ローカルサーバーに定期バックアップするだけなら、Redmineなど汎用的に使えるバックアップ処理(shellscript+cron+rsync) - Qiitaに書いてあるシェルスクリプトが一番簡単。
でもサーバーが壊れた場合も想定するなら、rsyncで別サーバーと同期する方がいいだろう。

ついでに、SubversionやGitリポジトリも定期バックアップするようにすればいい。

(引用開始)

redmine_backup.sh
#!/bin/bash

# Redmine Backup

# 定義
# バックアップ先フォルダ
TO_BK_DIR=/backup/to

# 現在日付(バックアップファイル名に使用)
NOW=`date +%Y%m%d%H`


# DBバックアップ
mysqldump -u DB_USER -pDB_PASS DB_NAME | gzip > $TO_BK_DIR/redmine/redmine_db_$NOW.sql.gz

# アップロードファイルバックアップ
gzip -rc /REDMINE_ROOT/files > $TO_BK_DIR/redmine_upload_$NOW.tgz

# 世代管理(更新日が7日以前のものは削除)
find $TO_BK_DIR/ -mtime +7 -type f -exec rm -f {} \;

# バックアップサーバと同期
rsync -avz --delete -e ssh $TO_BK_DIR/ username@remote_server:$TO_BK_DIR/

(引用終了)


| | コメント (0)

2014/02/18

アジャイル開発はメトリクスが取りやすい

アジャイル開発はメトリクスが取りやすいのではないか、というアイデアについてメモ。

【1】日本のWF型開発では、メトリクスは特にテスト工程で重要な意味を持つ。
バグ密度、テスト密度、コード行数(LOC)などの品質目標をテスト計画時に立てて、その品質目標をクリアしたという判定によって、リリースOKの決定が下される仕組みにあるから。

しかし、WF型開発では必ず結合テストでビッグバンテストになって火を噴く。
障害が多発して、その分テストケースも増えてしまい、バグ密度やケース密度も当初の品質目標を大幅に超えてしまう時が多い。
すると、その品質評価が良かったと結論付けるために、プロジェクトリーダーは四苦八苦しながら、テスト報告書を書く羽目になる。

【2】アジャイル開発では、メトリクスは次のイテレーションへの予測として使われる。
例えば、XPが見つけてScrumがフレームワークとして組み込んだメトリクス「Velocity」は、開発チームのイテレーション単位の平均開発規模だ。
つまり、Velocityは開発チームの開発ペースに相当する。

Scrumでは、4週間の1スプリントで、ストーリーポイントで計測した開発規模によって、開発した実際の開発規模を得る。
それが、Velocityになる。
すると、次のスプリントでは、直近のスプリントのVelocityから、かなり精度の高いVelocityを予測することができる。
そこから、次のスプリントでも、同じくらいの開発規模を作れるだろう、と予測できる。

リーン開発では、1機能を開発チームが受け付けてリリースするまでの時間をサイクルタイムとして計測する。
サイクルタイムが短いほど、顧客の要望を素早くリリースできることにつながり、売上やROIを高めることに貢献する。

かんばんを使って、1機能を1枚のPostItに書き、受付日とリリース日を記録すれば、簡単にサイクルタイムを採取することができる。
サイクルタイムを短くするために、仕掛り中の作業の数(WIP)を制限したり、バックログに組み込まれるストーリーカードを減らす、などの是正対策を取ることになる。

WF型開発のメトリクスは、テスト工程というプロジェクト後半にならなければ、バグ密度、テスト密度、コード行数(LOC)などが得られない。
そこで得られたメトリクスも、本番リリースが終わってしまえば、プロジェクトも収束し、プロジェクトにかかわったメンバーも散り散りになるために、そのメトリクスを次の2次開発で使ったとしてもあまり精度が高いとは言えない。

アジャイル開発の方がWF型開発よりも、直近のメトリクスを収集しやすく、そのメトリクスを直後のイテレーションで試すから、精度はかなり良いだろう。

【3】そもそも、なぜそんなメトリクスが必要なのか?
WF型開発では、メトリクスはリリース判断基準として使われる。
アジャイル開発では、メトリクスは次のイテレーションの開発規模の予測として使われる。

だが、メトリクスの本来の使用目的は、PDCAによるプロセス改善に使うべきものだ。
すなわち、メトリクスという指標によって、開発の現状のどこに問題があり、どの部分を改善すべきかを診断するために使うべきだ。

メトリクスは、健康診断のようなもの。
例えば、コレステロールが高い、血圧が高い、血液検査の一部の値が悪い、などの指標(メトリクス)を定期的に計測することで、健康状態をよくするための処置を施す。
同様に、アジャイル開発やリーン開発では、Velocityやサイクルタイムを1イテレーションという定期的なタイミングで計測することで、開発チームの生産性や品質を評価できる。
それによって、開発チームの問題点を目の前にさらし、メンバーに改善を促す雰囲気を生み出すことができる。

WF型開発では、プロジェクトの最後でしか本番リリースしないために、メトリクスを採取するタイミングが遅く、採取したメトリクスを開発チームにフィードバックするタイミングがとても短い。
どうしても、開発チームを改善していくというスタイルになりにくいように思える。

【4】メトリクスに関しては、他にもいろいろ問題がある。
メトリクスを定期的に収集して評価することで、メンバーの行動を局所最適化してしまうという「メトリクスの罠」が有名。
メトリクスは、メンバーの行動をより良い方向へ向かわせるのではなく、都合の良い評価になるように、本来の目的と違った行動にしてしまう悪影響が多い。

また、従来の開発環境では開発プロセスのメトリクスを計測しにくいという弱点もあった。
メンバーに予定・実績工数を入力させたり、障害票を入力させたりするのは、Excelや紙ベースだった時代は大変だったはず。
同様に、プロジェクトリーダーが入力された予定・実績工数をメンバー単位、期間単位、プロジェクト単位に集計したり、テスト消化曲線や信頼度成長曲線を作成するのは、従来は大変だったはず。

しかし、Redmineによるチケット駆動開発というインフレがあれば、そんなメトリクスはすべてチケット集計機能で置き換えることができる。
それによって、メトリクスを使ってプロセス改善に適用するというやり方も、もっと手軽に行える。
メトリクスの罠は、アジャイルチームにおける自律的なチームを目指せば解決できると考えている。

「メトリクスを使ってプロセス改善する」という古くからのやり方は、現代のIT化のトレンドの中で、もう一度、その形式をブラッシュアップすべきだろうと思っている。

| | コメント (0)

2014/02/17

ツール革命でソフトウェア開発が変わる

第6回品川Redmine勉強会のつぶやきで、気になったコメントをメモ。

【元ネタ1】
Redmine勉強会でJIRAの紹介をしてきました #47redmine - 製品とサービスのブログ - リックソフト

(引用開始)
ツール革命が起こっている

今回は、日経システムより「Redmine超入門」 の発売を記念しての開催ということで、講演1は日経システム副編集長の中山さんより、この本を出した背景の説明がありました。その中で一番記憶に残っている言葉は、

"なぜ、この本を出版したか?ツール革命がおこっているから"

とのこと。全く同感です。
(引用終了)

【元ネタ2】
第6回品川Redmine勉強会(2014/2/15) #47redmine - Togetterまとめ

第6回勉強会 - shinagawa.redmine

Twitter / ohnuki: #47redmine なぜRedmine超入門を出したか?ツール革命が起こっているから。

Twitter / tkusukawa: 95年の時はアメリカで流行ったことが日本に入ってくる構図があった。 #47redmine

Twitter / ZuQ9Nn: 学ぶのはアメリカではなく、ネット系の企業、エンタープライズ系の企業は、かなりツールの導入、活用が遅れてている、そして、その差がどんどんと広がっている  #47redmine

【元ネタ3】
shinagawa.redmine 第6回勉強会に参加してきた - njuntechのブログ

(引用開始)
・日経SYSTEMSとしては、アメリカの先進企業を見て、それから日本
 アメリカではやったものが、半年~1年遅れて、日本に来る
・日本では・・・
 エンタープライズ系は遅れている
 が、ネット系は進んでいる
 ツールをどんどん使っている
・CI/CDツールを使うにしても、Redmineをポータルとすることができる
 まずはRedmineを入れる
・本当の入門書がない
 当時、Xperiaの入門書がはやった
 画面のイメージがずらっと並んだようなもの
 Redmineでも同じようなものを作る必要がある(ニーズがある)のでは?
(引用終了)

「ツール革命が起きている」という話はとても同感。
GitHubによるソーシャルコーディング、Redmineによるチケット駆動開発、JenkinsやChefなどによる「Infra structure as Code」など、ソフトウェア開発環境周りの技術革新が昨今は激しい。
このツール革命の流れに、エンタープライズ系企業、特にメーカー系企業やSIが遅れているように思える。

例えば、日本の製造業のやり方を真似た「ソフトウェアファクトリー」という考え方がある。
この開発プロセスは、ソフトウェア開発をソフトウェア工場にしてしまうという発想と同じ。
しかし、このやり方が、現代のソフトウェア開発では通用しなくなっているように思う。

日本型ソフトウェアファクトリーこそ真の敵 - 勘と経験と読経

ソフトウェアファクトリー - Wikipedia

プログラマは工場労働者と同じで、設計書に従ってプログラムを製造(メーカー系企業やSIではプログラミングとは言わず「製造」と呼ぶ)し、出荷(メーカー系企業ではリリースと呼ばずに出荷と呼ぶ)する。
プログラマは知的労働者ではなく、設計書に従って開発する人に過ぎないという発想は、おそらく、アジャイル開発とは相入れない。

ソフトウェアファクトリーのやり方は、メインフレームとCobolの世界のように、ハードとソフトが密接に絡んで、クローズドな世界では通用した。
しかし、現代のように、数多くのオープンソースないしミドルウェアの製品を連携してシステム化する場合では、従来のノウハウが生きにくい。
ノウハウそのものも、ソフトウェアのVerUpに追随しなければ、何の役にも立たない。

アジャイル開発の面白さの一つは、XPのTDDやCIのように、ソフトウェア開発環境の効率化に注力する点にある。
そんな話は以前から知っていたよ、とCobol時代の人も言うけれど、従来はそんな開発環境が高価でオープンソースで公開されておらず、社内で閉じていたから、時代の流れに取り残されたように思える。
時代に合わせて、開発プロセスをVerUpしながら進化させていく、という発想がソフトウェアファクトリーにはないように思える。

特に、エンタープライズ企業のソフトウェア開発環境は遅れているように思う。
その理由は、従来のウォーターフォール型開発にとらわれ過ぎていることに問題があるのだろうと思う。

| | コメント (0)

GitHubライクなRedmineテーマ

GitHubライクなRedmineテーマが公開されていたのでリンクしておく

【元ネタ】
GitHubテイストなRedmineのテーマを自作してみた | kwLog

makotokw/redmine-theme-gitmike

GitHubライクなGitリポジトリ管理ツールといえば、GitLabだろう。
GitHubのデザインやUIは確かに使いやすい。
Redmineでも、GitHubライクなデザインを使えば、GitHubを多用しているプログラマも使いやすいだろう。

「GitLab 6.4」が登場、Diffビューの強化やアーカイブ機能の追加などが行われる | SourceForge.JP Magazine

GitLab: Self Hosted Git Management Application

僕は、@g_maedaさんの会社で公開された「farend basic」テーマを愛用している。
チケット一覧画面で、優先度ごとに赤色の濃淡で表示したり、期日が遅延したチケットはオレンジ色で表示してくれる機能を持つ。
チケット一覧画面で、優先度の高いチケットや期限が遅れたチケットに気づきやすくなる利点がある。

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

farend/redmine_theme_farend_basic

Redmineに入れたプラグイン一覧part4: プログラマの思索

Redmineテーマは再起動せずとも配置するだけで使えるので、いろいろ試せて便利。

| | コメント (0)

2014/02/15

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

東京で雪だるまができるくらい積もったにも関わらず、第6回品川Redmine勉強会は、スタッフは全員、参加者も7割も参加して開催されました。
懇親会も27人も集まり、大変盛り上がりました。

参加者の方には足元が悪い中、来てくださりありがとうございました。
また、会場を提供して頂いたフューチャーアーキテクト様、そして協賛して頂いたアジャイルウェア様に厚くお礼申し上げます。

【元ネタ】
第6回勉強会 - shinagawa.redmine

第6回品川Redmine勉強会(2014/2/15) - Togetterまとめ

【1】Redmine超入門のお話

中山さん、@naitohさん、@tkusukawaさんから、Redmine超入門に絡んだお話があった。
本の執筆はやはり大変。
中山さんの見積では、90ページ書くのに2人月かかるらしい。

そこで、品川Redmineスタッフも加わって執筆したものの、並行作業になったので、最後に成果物を結合した時に整合性を取るために苦労されたらしい。
ソフトウェア開発でも、結合テストでビッグバンテストで苦労するのと同じく、並行作業は時間短縮できるが、結合した時に初めてリスクが発生する。

執筆作業でもソフトウェア開発でも、並行作業には、時間短縮の利点と同じくらい、ビッグバンテストのリスクも大きい。

【2】開発基盤としてのRedmine

日本のSIの現場で、Redmineはかなり普及している印象を僕は持っています。
最近の僕も、Redmineエバンジェリストの立場で、色んな現場にRedmineを導入する時が多いです。
その時にいつも苦労するのが、開発者の評判は良いのに、マネージャからは、Redmineが使いづらいというフィードバックが多いのです。

その理由は、マネージャは、プロジェクトの進捗だけでなく、コストや品質、リスクをサマリとして集計した結果を週次または月次で報告が欲しいのに、そんな機能がRedmineにはないからです。
そのため、Redmineをカスタマイズして、もっと使いやすくしようという動きが最近多いように見受けられます。

Redmineのカスタマイズで注意すべき点は、要約すると2点あります。
一つは、現場の運用とRedmineの機能のフィットギャップ分析をきちんと行うこと。

現場にRedmineを導入する場合、何も考えずに導入すると、マネージャだけでなく開発者も抵抗勢力になります。
やはり、現場の運用のレベルに合うように、Redmineのワークフローを合わせたり、チケット管理の運用ルールについて説明会(いわゆる導入時研修)を開いて十分に説明したりすることが必要になります。
2014年の今でも、TracやJiraなどのITSを触ったことがない人も多いので、そんな人達には丁寧に、Redmineの利点を強調しながら説明する必要があります。

また、Redmineは柔軟性が高いため、トラッカーやワークフロー、カスタムフィールド、ユーザ、プロジェクトをあらかじめ決めておかないと、すぐに運用することはできません。
そのため、現場にヒヤリングしながら、Redmineの機能を現場に合わせる必要があるのです。

一度Redmineを導入してしまえば、20代の若い人ほど、すぐに慣れてくれます。
逆に、Excelで20年管理をやってきた40代のマネージャほど、Redmineに染めるのが難しい。

もう一つは、Redmineを機能拡張する時に、Redmineの外部接続I/Fを利用してデータの取得や更新処理を行うようにすること。

Redmineは機能改善やユーザインターフェイスの改善の開発速度が早く、VerUpがとても頻繁に起こります。
そのため、RedmineのVerUpに追随する方が、新しい機能を自然に使えるようになる利点があります。
下手に、自分たちでRedmineのソースを弄ってユーザインターフェイスを改善するよりも、VerUpに追随する方がコスト的にも安全かもしれません。

また、Redmineの外部接続I/Fは、RESTやJSONP、rakeなどのインターフェイスが豊富にあるので、それを有効利用する方が、RedmineのVerUpの影響を受けることもありません。
RedmineのVerUpが発生すると、自分たちが作ったプラグインや機能修正した箇所がデグレしていないか、回帰テストする工数がVerUPのたびに発生します。
そのコストは、VerUpの回数が多いほど、結構かかります。

RESTを使えば、HTTP通信で、チケットのデータを簡単に一括取得したり、一括更新できます。
また、JSONPインターフェイスを使えば、例えば、Redmine画面の一部の領域を非同期通信で画面更新するプラグインも簡単に作れるでしょう。

さらに、rakeインターフェイスを新規開発すれば、日次バッチ処理のように、データを一括取得したり、Redmineチケットの内容を定期的にメール送信するなどの処理も実現できるでしょう。
Twitterのタイムラインを読むと、パスワードの一括初期化もrakeで実現できるのでは、という話もありました。

個人的には、rakeコマンドでRedmineにあるデータを一括処理するバッチ処理には、大きな可能性を秘めているように思います。

【3】Lychee Enterprise製品

アジャイルウェアの@agilekawabataさんが、Redmineのエンタープライズ向け製品として、3つの製品を紹介されました。
3つの製品の位置づけとしては、マネージャの観点で、プロジェクト管理のQCD(品質・コスト・納期)を支援する製品と位置づけられています。

Lychee Enterprise

LycheeGanttChartは、Redmineガントチャート画面から、チケットを直感的に操作できるプラグインです。
ガントバーをドラッグ&ドロップで移動したり、日数を縮めたり延ばしたりできます。
また、ガントバー同士に先行・後続の関係を、ドラッグした矢印で簡単に引くことができます。
さらに、親子関係も右クリックから簡単に設定できます。

マネージャとしては、個々のチケットよりも、プロジェクト全体のタスクを俯瞰的に眺めて分析したいので、LycheeGanttChartのようにガントチャート画面で直感的に操作できるプラグインがあると、すごく便利でしょう。

LycheeEVMは、PMBOKのEVM(出来高管理システム)を実現したプラグインです。
マネージャは、要員表と実績工数をにらめっこしながら、プロジェクトの原価をいつも気にしています。

だから、EVMをRedmine上で見ることが出来れば、現在の開発ペースで進むと、いつ予算オーバーになるのか、を予測できるし、早めにリスク対策を実施することもできます。
また、SPIやCPIも日次で時系列に表示するので、ScrumのVelocityのグラフのように、開発チームがアウトプット(出来高)を増やして成長しているのか、逆に、大きな問題にぶつかって進捗が遅延しているのか、を分析することができます。

LycheeAssociationChartは、Redmineチケット同士の関連をグラフ化したプラグインです。
WBSっぽく親子チケットを作っているならば、ツリー構造のようにチケットの関連図を表現できます。
あるいは、チケットの先行・後続関係をきちんと反映していれば、PERT図のようにチケットの関連図が表現されます。

特に、チケットとソースのリビジョンのグラフも表示されるので、WBSの最下層にある作業タスク(ワークパッケージ)と成果物(ソース管理のリビジョン)がリンクされていなければ、成果物ができていないので、その原因を探っていく、という使い方もできます。

川端さんの話では、品質管理部の方が、リリース前の出荷時に、LycheeAssociationChartを使って、チケットと成果物のチェックに使われているそうです。

昨日まで行われたデブサミ2014のブースでもLychee製品のデモを行い、評判が良かったという話も聞きました。
皆さん、Redmineのエンタープライズ向け製品は結構気にされているみたい。

【4】大貫さんのJiraの話、神谷さんと大和田さんのEPM-Xの話

Jiraでも、ガントチャートをカスタマイズしたり、テストケース管理したり、色々な機能があるそうです。
Redmineにある改善要望は、Jiraでも同じように出てくるでしょう。

神谷さんの話で興味深かったのは、ツールの進化にマネージャや経営層が付いていけてないこと。
僕の経験でも、40代以上のマネージャやSEは、Cobolや汎用機の技術で止まっていて、Rubyはおろか、Javaなどのオブジェクト指向やWebシステムの技術を知らない。

彼らはプログラミングしていないので、技術動向の細かな内容まで把握できていない弱点があります。
そういう人達が抵抗勢力になり、日本のSIの技術力の進化を妨げている部分も大きいと思います。

また、従来のソフトウェア工学では、机上でたくさんの理論を作っているものの、定量データを収集し集計するコストが高かったり、そのような定量データ管理ツールの実装が難しかったという背景があって、机上の空論に過ぎない場面が多かったのではないかと思います。

でも、現代は、RedmineやJira、Jenkins、Gitなど優れたツールを連携することで、ソフトウェア開発で発生する作業ログは全て記録できます。

したがって、現代では、それらトランザクションデータをBIツールで分析する機能も簡単に実現できるはずです。
それによって、プロジェクトのリスクを事前に検知して是正対策を実施できたり、次のプロジェクトへ向けて過去のノウハウを生かすといったことも可能になるでしょう。

既にソフトウェア工学では、CMMI、品質管理、PMBOK、ITILなどで仕様は既に公開されているので、それらをツールで実現していくだけなのです。

【5】今回の勉強会で感じたことは、「Redmineによるタスクマネジメント実践技法」「チケット駆動開発」で執筆したものの、まだ実現されていない機能が製品として現れたことでした。
ツール連携、チケット集計の機能強化というRedmineの課題は、もっともっと可能性を秘めていると思います。

【追記】
@tkusukawaさんの発表「Redmineって何ができるの?」と大和田さん、大貫さんの資料を追加した。
とても分かりやすい資料です。

| | コメント (0)

2014/02/14

ビッグデータはプロセス改善を促進する

最近の統計学ブーム、データサイエンティストやらビッグデータなどのバズワードに関して、ラフなメモ書き。

【1】ビッグデータ: 言語は本当に重要か?

Twitter / akipii: ビッグデータ: 言語は本当に重要か? http://www.infoq.com/jp/news/2014/02/bigdata-languages#.Uv31cO3iSXw.twitter … PythonやRに人気があるらしい。「Rはデータサイエンスの博士号を持つ人たちには人気があるが、データが主流になるにつれて、Pythonが優位になっている」

統計学ブーム: プログラマの思索

業務やプロセスなどをIT化した場合、すぐに現れる利点は日々のトランザクションデータを分析することで、PDCAサイクルによるカイゼン、ないし、プロセス改善の元ネタになることだ。
なぜなら、日々の業務や業務プロセスのメトリクスを簡単に集計できるため、毎日の健康診断のように、業務プロセスの品質・コスト・進捗をリアルタイムにモニタリングできる。

メトリクスが正常な値から外れた異常値になっていれば、その業務は普通と違って何かおかしな状況が発生している、と推測することもできる。

ここで、業務システムで蓄積されたトランザクションデータというビッグデータは、ソフトウェア工学の観点ではメトリクス、経営の観点ではKPIと訳される。

Twitter / akipii: ソフトウェアが進化してビッグデータを容易に扱えるようになったおかげで、メトリクスの収集・集計・分析が非常にやりやすくなった。既に統計学や確率論の理論があるから、その仕様に従って、ソフトウェアを適用して仮説検証できる。ソフトウェアはPDCAサイクルというプロセス改善を促進する。

Twitter / akipii: プロセス改善にはメトリクスが必要。ソフトウェア工学ではメトリクスと呼び、経営ではKPIと呼ぶ。リーンスタートアップなら「measure」のプロセスがある。アジャイルでもVelocity、リーン開発ならサイクルタイムというメトリクスがプロセス改善の発火源になる。

だが、メトリクスは諸刃の剣。
個人の行動を対象としたメトリクスやKPIは、本来のあるべき行動を促進するのではなく、メトリクスの数値が高くなるような行動を引き起こし、その行動は局所最適化されやすい。
特に、ソフトウェア工学に出てくるメトリクスは、開発者のモチベーションを落とすようなメトリクスが多い。
もっと、開発者が生き生きとするようなメトリクスを提示して、開発者が自発的に行動するような雰囲気になるようにできないのか?
Googleの20%ルール、3M社の15%ルールのように、社員のモチベーションを生かすようなKPIが経営学ではあると言うのに。

Twitter / akipii: ソフトウェア工学には、バグ密度やテスト密度のように、なぜ、開発者のモチベーションを落とすようなメトリクスしか出てこないのだろう? もっと開発者のヤル気を起こし、ソフトウェア開発を促進させるようなメトリクスはないのか?他業界のKPIにはそのようなメトリクスがあると言うのに。

【2】Twitter / akipii:統計学のR言語とSQLの対応表の記事。これは面白い。気になるのはR言語の性能要件だがどうだろうか? RとSQLを対応付けてみた - あらびき日記 http://d.hatena.ne.jp/a_bicky/20110529/1306667230 …

統計学をプログラミング言語で実装して操作したい場合、R言語という別のプログラミング言語を使うのが多いらしい。
特に、データサイエンティストと呼ばれる人達は、R言語を使っている人が多いらしい。
そのR言語は、SQLに似たような構造があるようだ。
その指摘が正しいならば、とても興味深い。
R言語のようなデータ操作の言語は、SQLと同じく、集合論理の上で実装されるのだろうか?

また、OracleでR言語が使えるらしい。
RDBに貯められたデータをSQLだけでなく、R言語のような別のデータ操作言語で集計できれば、データの利用価値が上がるだろう。

Twitter / akipii:OracleデータベースをR言語で操作できるらしい。統計学の知識を生かしたプログラムが書けるだろうか。 Oracle R Enterpriseの概要 http://docs.oracle.com/cd/E49329_01/doc.121/b71357/intro.htm …


【3】Twitter / akipii: 得票数から散布図を(おそらく)R言語で作成して分析している。目の前のデータを散布図やパレート図で描画するだけでも、十分プロセス改善の元ネタになる。 23区のヤンキー度と反原発度 - 都知事選結果より ? タイトルは後で考える
http://cognitom.roon.io/23

23区のヤンキー度と反原発度 - 都知事選結果より ? タイトルは後で考える

先日の東京都知事選の分析のために、散布図を作成して批評している記事があった。
区別ごとに、候補者の得票率を並べただけだが、散布図の作成にR言語を使っているように思える。

散布図や回帰直線は、2つの変数に相関関係があるかどうかを見るために使われる。
数値を並べるよりも、グラフ化される方が分かりやすいし、インパクトも強い。
R言語のようなプログラミング言語を自由に操ることができれば、CSVの生データをいくらでも分析できる利点がある。

散布図などの統計学的手法を駆使した学術的結果として、下記のWebページがとても面白い。

社会実情データ図録 Honkawa Data Tribune

社会統計学は面白い: プログラマの思索

「酒呑みと愛煙家が多い県・少ない県」「世界各国のセックス頻度と性生活満足度」など、国が公開したオープンデータを上手く使って分析すれば、いくらでも面白い結果を得られるようだ。

このオープンデータの発想は、税金で収集され集計されたデータは、市民のものであり、市民がいつでも使えるようにすべきだ、というガバメント2.0の考え方に発展するだろう。
すなわち、国が保持している多様な各分野の社会統計データや、そのデータを取得するAPIを公開することで、新しい産業を生み出す可能性を秘めている。
日本政府もオープンデータや電子政府と言う概念で、普及に足を向けているようだ。

ティム・オライリー特別寄稿:ガバメント2.0―政府はプラットフォームになるべきだ | TechCrunch Japan

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

電子行政:キーワード - オープンデータ とは:ITpro

【4】Twitter / akipii: この本を読みたい。ソフトウェアによるビッグデータ解析、いわゆるデータマイニングが簡単に実現可能になったらこそ、統計学が注目されてきた。 『異端の統計学 ベイズ』 "信念"を数字に - HONZ http://honz.jp/34624

僕は統計学は詳しくないけれど、ベイズ統計学は、高校数学で習ったいわゆる条件付き確率に関係しているらしい。
ベイズ統計の概念は、今まで日の目を見なかったらしいが、スパムメールのフィルタリングのアルゴリズムにも使われている。
こういう記事を読むと、きちんと学習して来なかった統計学をきちんと勉強したいと思う。


| | コメント (0)

2014/02/11

ビッグデータだけでは将来は予測できない~シグナル&ノイズの感想

シグナル&ノイズ 天才データアナリストの「予測学」」を読んだのでメモ。

【参考】
【書評】『シグナル&ノイズ 天才データアナリストの「予測学」』:シロクマ日報:ITmedia オルタナティブ・ブログ

未来を予想したいひとのための思考のエッセンス:「シグナル&ノイズ」(日経BP刊) | Lifehacking.jp

『シグナル&ノイズ』 ネイト・シルバー・著 vol.3466 | 「ビジネスブックマラソン」バックナンバーズ

・序章は「情報が増えれば問題も増える」「ビッグデータへの期待と落とし穴」。
 シグナル=予測の参考となる真実、ノイズ=真実から目をそらし予測を外すもの。

・2010年現在で、予測がうまく機能している数少ない事例は、野球予測システム(「マネーボール」で語られたPECOTAシステム)や天気予報。

・予測がほとんど当たらない、または外れやすい事例は、地震予知、経済予測、インフルエンザ流行、金融市場、など。

 経済データはノイズが多い。
 しかも、経済学のモデルは現実と合っていない場合がある。

・統計学におけるベイズ統計の復権。
 ベイズの定理が有名。
 ベイズ統計の適用事例は、メールのスパムフィルタ。

ベイズの定理

第4回 ベイズの定理でプロジェクトの失敗を予測 | Think IT

スパム対策に欠かせないベイズ理論とは? (1/2) - ITmedia エンタープライズ

[ThinkIT] 第4回:押さえておきたいスパムフィルタの技術 (1/3)

参考書としては「異端の統計学 ベイズ」が面白いらしい。


| | コメント (0)

SQLとACIDは別の話、NoSQLというよりNoACID

@akahane37さんのつぶやきから、NoSQLとRDBの比較の資料を見つけたのでメモ。

筑波大学でデータベースの話をしてきました - kuenishi's blog

Twitter / akahane92: モヤモヤが少し晴れた気がする。”SQLとACIDは別のはなし、NoSQLというよりNoACID” / 筑波大学でデータベースの話をしてきました - kuenishi's blog http://kuenishi.hatenadiary.jp/entry/2014/02/01/234447 …

(引用開始)
言いたかったことの流れを僕なりにまとめると

・SQLが登場する前はみんなNoSQLデータベースだった
・NoSQLのポイントは、スケーリングの問題、整合性、可用性が大きなみっつの問題
・スケーリングは二通りの流儀がある
 ・整合性はアトミックブロードキャストプロトコルで頑張る
 ・整合性の話はふたつの文脈がある(トランザクションとレプリケーション)
・死活監視のデモでCrash Failure, Crash Recovery, Timing Failure, Silent Failureなどを体感
・Paxosの説明に失敗
・可用性とCAP定理
・ACIDとBASEは異なる概念なので混同どころか比較できない
・データストアの分類 NoSQLではなくNoACIDがおもしろい
 ・これはよい質問があってそのときはどう答えたのか覚えていないのだけど、今答えると、データベースは関係代数のデータモデルとトランザクション管理のふたつの部分から成っているのだけど、NoSQLは前者に対応するべきで、NoACID的なのは後者に対応すべき。なのだけど世間では混同されているのでここは注意した方がよい
・それなりの分類軸のはなし
・スキーマとかスキーマレスとか、ドキュメント指向とかカラム指向とか
 ・実は、ドキュメント指向DBはJSONだけでなくXMLもドキュメントとして扱うものがおおいのだけど、実はXMLは2階の正規モデルだかなんだか?になっていてふつうにSQLでクエリが書ける…という指摘をいただきまして、確かにドキュメント指向DBがアヤシいところのひとつではある。ただ、これは2000年代のデータベースのトレンドだったと記憶しているんだけど実は現実世界で役に立っているところをあまり見たことがない。

というところで、データベースを知る観点をひととおり説明して、Riakはこうしていますよという話をして終了。
(引用終了)

RDBのスケールアップという問題解決の一つとして、NoSQLが現れた。
NoSQLは、RDB以前の先祖返りに近い。
でも、クラウドによる並列処理とNoSQLを組み合わせると、特にWebサービスのニッチな問題を解決できる。

ACIDとBASEというDBの特性の違いが面白い。
SQLはデータ操作言語、つまりデータ操作のI/Fであり、ACIDとは関係しない。

そして、CAPの定理において、RDBやMongoDBなどがAとC(つまり、可用性と一貫性)を重視し、RiakやCouchDBがAとP(耐障害性と可用性)を重視しているという指摘は分かりやすい。

| | コメント (0)

2014/02/09

単語帳をスマートフォンで管理する~勉強法にITツールを導入する効果

単語帳もiPhoneやAndroidなどのスマートフォンやタブレットで管理できるアプリが出ている。
考えたことをメモ書き。

【元ネタ】
単語帳アプリ(iPhone,iPadで使える)が人気の理由 | 反転授業等のICT教育に関する情報共有ブログ

【英語】暗記ソフトAnkiをつかった英語の暗記まとめ - NAVER まとめ

決して後退しない学習ーAnkiを使うとどうして一生忘れないのか? 読書猿Classic: between / beyond readers

学習の効率をググッと上げるソフトウェア「Anki」の正しい使い方 | iGotit

暗記系の勉強に役立つツール「Anki」*二十歳街道まっしぐら(FC2ブログ時代)

瞬間英作文や単語暗記に役立つソフト「Anki」とアプリ「AnkiDroid」 | TOEIC 900点&英会話上達をめざす英語勉強法・参考書まとめブログ Enjoy Life in English!

暗記系の勉強に役立つツール「Anki」*二十歳街道まっしぐら(FC2ブログ時代)

i単語帳 / iPhone Application

Sonoran Blue | Mac & iPhone アプリケーション開発

マイ単語帳・マイ四択問題 iPhone・Androidで手軽に暗記学習!

スマホ単語帳「i暗記」で情報処理技術者試験の対策を! おすすめカードデッキご紹介! | i暗記 Developer's Blog - i暗記の開発者たちが書いています。

基本的な使い方 - i暗記マーケット

すいすい覚えられるスマホ単語帳の定番「i暗記」カテゴリ1位の実績

【1】単語帳が必要な背景

最低限の知識を覚えて、その知識の背景にある概念を自分の言葉で表現しようとすると、語彙が少なければ支障が出る。
だから、受験勉強や資格勉強をしていると、どうしても暗記せざるを得ない状況が出てくる。
特に最近は、小学生から英語が必須になったり、大手企業の管理職への昇格条件がTOEICの高得点になったりしたために、英単語を覚えるのは必須になってきている背景があるだろう。

あるいは、会計士や弁護士、税理士、社会保険労務士などのように法律とその概念を大量に暗記する資格試験や、特有の概念が多い情報処理試験でも、単語帳を作る意義はとても大きい。
まずは専門用語を覚えて、専門用語を使って自分の意見を表明する小論文が書けなければならない。

その時に、単語帳に覚えたい用語や概念、英単語を書いて、通学やトイレ、散歩などの隙間時間に見て暗記するようにしたい。

しかし、単語帳を作るのは結構面倒だ。
僕が小学生の頃は、1枚の紙からカードの大きさに切って、表面に覚えたい単語、裏面に単語の意味や説明を手書きで書いていた。
鉛筆や赤ボールペン、マーカーなどを駆使して書くのは、楽しいが手間がかかる。

そして、その単語帳のうち、覚えた単語は外して、自分の不得意な単語を残したり、追加して、ブラッシュアップしていかなければならない。
その手間も大きい。

また、単語の数が増えると単語帳もかさばり、ポケットに入らなくなる。

そもそも単語帳を作って暗記する作業よりも、単語帳を作成する作業を通じて、概念が知識マップになるように関連づけられていく方が重要だ。
単語帳を作る作業そのものも勉強の一環なのだ。

つまり、既存の紙媒体の単語帳は、紙の帳票であふれるオフィス、無駄なExcelドキュメントにあふれているIT現場と同じような問題をはらんでいる。

そのような単語帳の作成作業に、スマートフォンのようなITツールを利用できないか?

【2】単語帳アプリの構造と単語帳マーケット

iTunesやAndroidMarketを見ると、iPhoneやAndroid上の単語帳アプリはいくらでもある。
それら単語帳アプリの構造は、以下の説明が分かりやすい。

manual - Anki日本語マニュアル Wiki*

基本的な使い方 - i暗記マーケット

はじめてのAnki ? まず使ってみる | the right stuff, luminousspice

i暗記?記憶のコンシェルジュ? PV - YouTube

・単語を暗記する処理フローは、過去の脳神経学や教育学の理論を背景にしたものが多い。
 →長期記憶に残すための方法は過去の理論からある程度知られているものが多い
 
 →例:能動的に思い出すテスト (active recall testing)
    間隔をあけた復習 (spaced repetition)

・単語帳の構造は、単語とその意味の2つで十分だが、バリエーションがある。
 →例えば、Ankiでは、伝統的な単語帳とは違い、いくつかのFact(情報)の集合として登録する。
  単語帳の構造は、一つのデータモデルまたは概念モデルとして表現できる。
 
従来の単語帳の例:
 ・タイピングの量が多い
 ・書き間違いが起こりやすい
 ・単語をランダムに生成するのが面倒

Q: 酸素 の化学記号は?
A: O

Q: 酸素 の原子番号は?
A: 8

Q: O の元素名は?
A: 酸素

Ankiによる例:
 ・問題と答えの組をカード (card) と呼ぶ
 ・カードの集合を単語帳 (deck) と呼ぶ
 ・ファクト (fact) は互いに関連したいくつかの情報の集合で、カードを作るために使われる
 ・ファクト (fact)は複数のフィールド(Field)を持つ
 ・カードの表(質問)と裏(答え)に何が表示されるべきかという設計図をテンプレート (template)と呼ぶ
 ・テンプレートのリストと、ファクトに格納されたフィールドのリストをモデル (model) と呼ぶ

<Model>
Chemical Elements
以下のFieldとTemplateを属性に持つ。

<Field>
Name, Symbol, Number

<Fact>
Name: 酸素
Symbol: O
Number: 8

<Template>
Q: {{Name}} の化学記号は?
A: {{Symbol}}

Q: {{Name}} の原子番号は?
A: {{Number}}

Q: 化学記号 {{Symbol}} はどの元素を表す?
A: {{Name}}

・単語帳を使った学習内容を記録し、グラフ化する機能がある。
 →○月×日に△問を解いて、□問間違えた
 →時系列にいくつの単語を覚えたのかを表示
 
 つまり、自分で作った単語帳の学習記録のメトリクスを表示してくれる。
 →自分の弱みを分析できる。
  積み上げてきた学習記録は、モチベーション向上になる。

・単語帳の問題をランダムに生成したり、重要度や難易度の観点で出題もできる
 →問題の並び順で覚えてしまう危険性をなくせる
  気分を変えて問題を変えることもできる

・単語帳データをCSVで作り、一括インポートする方が便利。
 →PC上で単語帳データを作る方が簡単。
  閲覧はスマフォで使い分ける。

・テキストだけでなく、画像や音声も登録できる機能がある
 →文字で覚えるよりも、図やグラフ、概念図で覚える方が記憶に残りやすい。
  単語帳を音読する機能があれば、満員の通勤電車でも、イヤホンから聞くだけでも可能。

・作った単語帳をネットで公開する機能がある
 →英単語帳や資格試験用の単語帳は、他の人にもニーズがある
  みんなで単語帳を共有すれば、単語帳をいろんな観点で改善できる

 →i暗記マーケットでは、自分が作った単語帳を有料で公開することもできるみたい

・ソーシャルな機能があると便利
 →自分で作った単語帳の評判や指摘内容をフィードバックしてもらえれば、作成者のモチベーションにもなる
  自分が困っていることは皆困っているのだから

 →GitHubのWatchやStar、FacebookのLikeボタン、Twitterのリツイートやお気に入りのような機能を単語帳マーケットに追加できるはず

【3】単語帳アプリから透けて見える従来の教育の問題点、その解決の方向性

僕も携帯電話やPCが普及する前に教育を受けた世代なので、勉強は本とノートで書いて暗記するのが普通と思っていた。
そして、大教室に大量の学生を入れて、教師が一方的に長時間話して終わる講義が普通と思っていた。

しかし、従来の教育制度や学習方法は、IT技術がこれだけ進歩した現代には合っていないのではないか?

過去の脳神経科学や教育理論などの成果は既にあるのだから、それら理論を実践して検証できるようなツールをどんどん作って使って試してみるべきではないか?
特に、隙間時間の勉強方法にスマフォを活用する方法はもっと研究されるべきだと思う。

また、教育にもっとソーシャルな機能を実現すべきではないか?
FacebookのLikeボタンのように、自分の学習結果に教師や友人から「いいね」と評価されるのは、学生のモチベーション向上にもなる。
また、自分の学習結果を友人にも共有できるようにすることは、他人への思いやりや、他人と協力して成果を出すという行動を促すことにもつながるだろう。

過去に既に知られている教育理論を従来はコストなどの制約で検証できない場合が多かったけれど、「「世界はひとつの教室 「学び×テクノロジー」が起こすイノベーション」」でカーンアカデミーが実践しているように、ITツールを使って、たくさんの生徒の学習記録を残し、その記録をデータマイニングして評価検証すべきだ。
そうすれば、従来の教育で見過ごされていたたくさんの子供たちの可能性を切り開くこともできるはず。

教育にソフトウェアによるプロセス改善サイクルを導入する~カーンアカデミーによる教育の未来: プログラマの思索

単語帳アプリのようなツールは、業務システムやWebショッピングシステムに比べれば、そのモデルも簡単ですぐに作れるだろう。
しかし、特に教育現場でその効果は大きいだろうと思っている。

今もなお、教育制度や学習方法は従来のままで、現代の社会の流れに合致していない。
ITという優れたツールを用いて、プロセス改善できる可能性がすごくあると思っている。

| | コメント (0)

2014/02/08

教育にソフトウェアによるプロセス改善サイクルを導入する~カーンアカデミーによる教育の未来

世界はひとつの教室 「学び×テクノロジー」が起こすイノベーション」を読んだ。
ものすごくインスピレーションを受けた本だった。
今、大学で教育学を受講している学生がいたら、この本を読むことを強く勧める。
感想をラフなメモ書き。

【1】カーンアカデミーは本来、カーンさんの従妹が数学の単位換算が分からない質問に対し、カーンさんがビデオで講義してYouTubeに公開する所から始まった。
その活動が数年たつと、ものすごい影響を及ぼす。
最終的には、グーグルやビルゲイツの支援も受けて、世界中に教育ビデオとソフトウェアを無料で発信している。

本の著者であるカーンさんの文章を読むと、金融アナリストやプログラマという側面だけでなく、哲学者のような雰囲気を受ける。
すごく頭の切れる人なのだろう。

教育は人文科学の中でも、最も根本的な問題をはらむ学問だ。
「人に創造性を育てることはできるか」
「効率的に学習していくには何が必要なのか」

従来の教育制度は、プロイセン式の軍隊スタイル。
40人ほどの教室に子供たちを年齢別に押し詰めて、年齢に応じて学習内容を教師が一方的に教える。
そのスタイルは、国家が未熟な頃は良かったけれど、現代のように、暗記能力よりも創造性やリーダーシップを重視する流れでは、限界が来ている。

そういう問題に対し、ソフトウェアとビッグデータを使って、教え方の仮説を立てて、生徒の学習記録から検証し、経験則を見出していく。
まさに、PDCAのプロセス改善サイクル。

例えば、本の一節に、2つの6年制クラスに、数学を「1+1」の初歩から教えるクラスと、5年レベルの授業から教えるクラスに分けて、習熟度をテストした話がある。
つまり、いわゆるABテスト。

A/Bテストとは何ですか? - Mizeni

その結果は、実は「1+1」の初歩から教えたクラスの方が、最終的には成績もよく、学習能力も伸びたという驚くべき事実。

その理由の一つは、例えば、微積分を理解するには、三角法や指数・対数などの基礎を知っておく必要があるのに、それら一つが欠けていると、理解できない事実と似ているという指摘。
つまり、微積分は難解であるのではなく、前提となる基礎的な知識を理解していない限り、微積分を自由に操る能力は生まれない。
その理由と同じ現象が、小学6年生の算数にも表れたわけだ。

カーンさんはそういう事象をスイスチーズ的学習と呼ぶ。
スイスチーズは表面はきれいだが中身はスカスカらしい。
つまり、テストをクリアするなどの目先の目標にとらわれて、理解が不十分なまま、先に進んでしまって、理解に支障が生じる現象を指す。

このエピソードは、ソフトウェアが教育を変えるという事実だけでなく、ソフトウェアはビッグデータやABテストなどの手法を使うことで、自然にPDCAの改善サイクルを生んでいる事実の方が面白かった。

ソフトウェアの凄い点は、ネットで提供することで場所や時間に依存しないことだけでなく、人の行動を記録することで、その中から意味ある経験則を見出す可能性があること。
つまり、たくさんのデータから帰納的に法則を見出す研究がソフトウェアのおかげでとてもやりやすくなったという事実があるだろう。

さらにソフトウェアが重要な点は、仮説を立てて、その結果を記録し、評価して次に向けて是正対策を立てるというPDCAサイクルを自然に実践していることだろう。
PDCAサイクルはプロセス改善の基本的な構造だ。
このサイクルがあるからこそ、人もチームも成長する。

リーダーや管理職ならば、自分だけでなく、チームにも、PDCAサイクルを適用して、変化をもたらす手法を身に着けないといけない。

しかしながら、プロセス改善を回した経験がないというリーダーもとても多い。
そうなると、「これだけ! KPT」に書いてあるように、プロセス改善を回した経験のない管理職がどんどん増えて、自分たちの組織が成長できなくなる。

でも、ソフトウェアが書けるプログラマは、PDCAサイクルを回すプログラムを自分で書くことができる。
自分の仕事の記録、工数の記録、学習した記録、何でもいいから記録を残して、その記録から意味ある経験則を見出すアルゴリズムを適用するプログラムを書いて、PDCAサイクルを回せば、プロセス改善できるきっかけになる。

【2】「世界はひとつの教室 「学び×テクノロジー」が起こすイノベーション」の本には、教育の根本問題に関する優れた洞察が書かれている。

・カーンアカデミーが提供するレッスン時間は10分にする。
 学生が集中できる時間は10~18分に過ぎない、という過去の教育理論家の研究がある。
 なぜ、学校は今でも45分も長時間の授業をするのか?

・ビデオには、人は出ない。音声と動画だけ。(当初は)
 人は生まれつき顔に注目するので、黒板の方程式よりも教師の言動に注目してしまう。
 教師と顔を合わせる時間と学習時間は別にする。

・カーンアカデミーの教育プログラムは、完全習得学習という教育理論に支えられている。
 つまり、生徒はある学習内容を十分に理解したうえで、次の高度な内容に進む。
 完全習得学習の効果については、過去の教育理論家が既に研究して残している。
 
 なのに、今の学校は、生徒の理解度が分からなくても、先に進んでしまうのはなぜか?
 理由は、従来の教育ではコストがかかることと、官僚主義という名の惰性。
 現代は、ソフトウェアによって、そのコストはほとんど無料に押し下げることが可能。

・完全習得学習の効果として、生徒が当事者意識を持つことがあげられる。
 完全習得学習プログラムを経験した生徒は、自らの学習に対する責任を引き受けるようになった。
 つまり、なぜわからないのか、と自発的に掘り下げて、理解できなかった知識を習得できるように自発的に身に着けようとする。

・知識マップを使う。
 数学、国語、歴史、物理などの教科は単独で教えるのではなく、学習した内容をつなげて、有機的につなげる。
 知識の記憶は、複数の知識に紐づけると残りやすい。
 そのために、学習記録から学習内容の知識マップをプログラムで自動生成する。
 さらに、学習内容に関する問題生成プログラムを自動生成し、生徒の学習結果を評価する。
 生徒は、今まで自分が習ってきた「いままでの場所」、これから学んでいく「これから行く場所」の全体像をイメージさせる利点がある。

・ソフトウェアを使った学習の利点の一つは、マイペースで学習できること。
 時間や場所に依存しない。

 従来の教育制度で最も非効率な部分は、夏休みという学習しない無駄な期間。
 夏休みは、農業が基本的だった社会の名残りであり、現代の情報化社会には向かない。
 1か月も学習しなければ、忘れてしまう。
 むしろ、会社の有給休暇のように、学校も自由に休みを取れるようにすべき。

・ソフトウェアを使った学習の利点の二つ目は、学習した記録が残り、いつでもアクセスできること。
 黒板の内容は消されることもないし、教科書が紛失することもない。
 学習履歴が残っているので、復習できるし、過去の学習内容の関連性を思い出させる利点もある。

・従来の教育は、プロイセンの教育制度から生まれた。
 当時は、税金による公的で普遍的な義務教育制度によって、たくさんの中流階級が生まれた。
 しかし、現代では、規律や従順を重視する従来の教育方法よりも、創造的・論理的な思考が求められており、矛盾が発生している。

・テストで70点を取って合格したという意味は、本当に理解したことになるのか?
 テストは、その人のすべての能力、あるいは潜在能力を評価するのではなく、ある時点のある能力のスナップショットに過ぎない。
 
・テストとは、そもそも何をテストするのか?
 テストとは、ある時点における学習内容の一部について、生徒の記憶と理解のおおよその状況を測定するものにすぎない。

・テストには、政治や経済が混じりこむ。
 本では事例として、ニューヨーク州が標準テストをお金をかけて見直した話が掲載されている。
 変更前の古いテストでは、問題内容が予測しやすく、テスト対策をしたら得点が上がるため、上がり過ぎて標準であるという信頼性を失った。
 そこで、テスト作成会社が作ったら、翌年は得点は急落し、生徒の能力が落ちたという批判を逆に受けた。
 すると、州は彼らを首にして、別のテスト作成会社に、細かなガイドラインを提示した。
 ひねくれた問題はなくす、ややこしい否定形の問題はなくす、読解文の登場人物は前向きで模範的な人に限る、など。
 (日本でも、こんなエピソードはどこの学校でも出てきそう。)

 新しいテストは、古いテストよりも信頼できるものになったのか?

・プロイセン教育制度における能力別クラス編成は、多くの生徒から潜在能力を発揮する機会を奪っている。
 「あなたには能力が足りないので、たぶん社会に貢献できない」メッセージを送っている。

・創造性はどう測り、どう育てればよいのか?
 創造性はそもそも教えられるのか?
 カーンさんの結論は「その人を見たら創造性があるかどうか分かる」。

・宿題の正しい量はどれくらいか?
 誰も分からない。場合による。

・宿題は子供の教育に両親を巻き込むための手段である。
 だから、高学歴の両親を持つ子供ほど、成績が良くなる傾向がある。
 「高学歴な親を持つ方が子供も学歴が良くなる」経験則は、宿題の副作用ではないか。
 つまり、伝統的な宿題は不平等を促す効果があり、公教育の目的にそぐわない。

・カーンアカデミーでは「自宅で講義、教室で宿題」のやり方を試している。
 この手法を「教室をひっくり返す」と呼ぶ。
 (この考え方は、教育理論家によって以前から提唱されていたらしい)

・自宅で聞く講義は、バスでも公園でもどこでも聞ける。
 自分の好きなペースで勉強できる。
 教室で問題を解くようになれば、分からない問題や思い違いがあれば、先生や友達が助けてくれる利点がある。

・従来の教育制度はうまく機能していないかもしれないのに、間違いなくコストも高い。
 子供が小学校から大学を卒業するまで、どれだけのお金がかかるのか?
 学校、教室、教科書などの設備を用意するのに、どれだけお金がかかるのか?
 学校ごとに、教員や警備員を配置するコストがかかる。
 
 新しいテクノロジーを適用すれば、コストは無料まで抑えられるはずだ。

・新しいテクノロジーを従来の教育制度に入れても、学習う方法を変えなければ、お金をどぶに捨てるだけである、と一部の教育理論家は言っている。
 教室を再構築しない限り、iPadは有効な学習ツールにならない、と。

・教育の理論構築と実践、その検証に、ソフトウェアとビッグデータを適用する。
 教育のような人間の根本問題に関わる実証主義的研究は、従来は結果を出すのに30年以上かかっていた。
 しかし、ソフトウェアとビッグデータをうまく使えば、医学である薬剤の効果を実証する研究と同じように、数か月ないし数年で仮説検証できるはずだ。

・カーンアカデミーによるマイペースで取り組めるビデオと練習問題、教室でのプロジェクトを組み合わせた手法は、特定の生徒や先生に共感を呼ぶらしい。
 その有力な証拠が事例的にも統計的にも提出できる点に、大きな意義がある!!!!!
 (もちろん、ソフトウェアとビッグデータを使ったPDCAの改善サイクルが背景にある)

・生徒が数学の学習内容を完全に理解できていない自信のなさの原因は何か?
 一つは、中心となる内容を「概念」としてしっかり理解できていないため、何を尋ねられているのか、問題を解くのにどんな概念を使えばよいか、確信が持てないから。
 もう一つは、自分たちが理解でき当ていない自覚があり、プライドを傷つけられるから。

 その問題に対し、数学の問題を出すごく簡単なソフトウェアを作った。
 負の数の足し算引き算、簡単な指数の計算をランダムに出すだけの基本的なソフト。
 
 このソフトに、各生徒が何問正解して何問間違えたか、どれくらいの時間を要したか、何時に問題を解いたのか、などを記録するようにした。
 この学習記録を講師がフィードバックを受けることで、生徒が何を学習しているかだけでなく、どのように学んでいるか、も分かってきた。

 論理ステップを追ってコツコツと解答したのか、それともパターン認識によって答えが閃いたのか。
 間違ったのはケアレスミスか、それとも関連性を完全に把握できていないからなのか。
 生徒が学習内容を真に理解した時、何が起きるのか。
 それは事例を積み重ねて徐々に起きるのか、突然起きるのか。
 色々な概念をミックスした問題ではなく、一つの概念だけに絞った問題をたくさん解くと何が起きるのか。

・生徒の数が増えても、ソフトウェアを使えば、簡単に学習記録やその次に進む学習内容へのアドバイスなどの情報を管理できる。

・「特定の内容を習得した」ことをどのように定義するのか?
 カーンアカデミーでは、「ある科目の問題を10問連続して正解できれば、基本的な内容を理解できていると判断してよい」。
 この定義は、カーンさんの直感的なやり方。

 この定義に至った理由は、テストには生徒への期待という人間的な要素がある。
 低いハードルは、子供は自分の能力を疑うし、そこそこでいいという後ろ向きな考えになる。
 10問連続して解けるぐらいの基準は、メトリクスとしても簡単で、教師も生徒に期待しているというメッセージを送れる。

・ある州の夏期講習で、カーンアカデミーのプログラムを適用した時に、「1+1」から始めるクラスと5年生レベルから始めるクラスでA/Bテストを実施した。
 結果は、「1+1」から始めるクラスの方が断然、成績が良かった。
 5年生レベルから始めるクラスでは、壁にぶつかって進歩がみられない生徒もいた。

 6年生、7年生レベルの学習内容が分からないのは、もっと前のレベルの内容でつまずいているからだという測定結果が得られた。
 つまり、大部分の生徒は何らかの矯正を必要としており、そのギャップの発見と修復に時間をかければ、長い目で見ると時間とコストが節約され、学習も深まる。

・経験豊富な先生がカーンアカデミーのプログラムに改良点を指摘してくれた。
 「今の機能は素晴らしい。でも本当に欲しいのは、生徒がいつ立ち往生しているかを教えてくれる簡便なシステムです」と。

・学習には必ず「分かった」と「分からない」の間にある「立ち往生」の状態がある。
 カーンアカデミーのシステムでは、立ち往生を「50問解いて10問連続正解が一度もなければ立ち往生している」と定義した。
 この大まかなメトリクスでも、先生には十分に役立った。

・さらに、生徒が立ち往生しているかどうかを先生に伝える仕組みとして、生徒と学習内容のクロス集計表を毎日作成するようにした。
 これを見れば、誰がどの教科で立ち往生したか、一目瞭然。

・立ち往生のフィードバックによって、教室の在り方が根本的に変わった。
 ソフトウェアというテクノロジーを活用したことで、1対1のやり取りが促進され、どの生徒に配慮が必要か、先生もすぐに分かる。
 さらに、特定の学習内容をマスターした生徒と悪戦苦戦している生徒をペアにしたり、同じところでつまずいている生徒同士をペアにすることで、協力して障害を乗り越える経験が得られる。
 このような人間的なやり取りは、学習時にとても必要。

・カーンアカデミーのフィードバックシステムが優れている点は、生徒の習熟度に応じた学習方法を個別に提供できること。
 つまり、飲み込みが遅い生徒でも、マイペースで学習して基礎をしっかり固める機会さえあれば、上級と認められる生徒になりうる仕組みを提供したこと。
 ソフトウェアで学習記録を解析することで、生徒の立ち往生をタイミングよくフィードバックし、生徒の学習を支援する。

・生徒の習熟度を個別に管理できる学習システムがあるならば、年齢別にクラス編成する必要はない。
 むしろ、いろいろな年齢が混じっている環境の方が、年上の子も年下の子も得るものがある。
 年上の子は年下の子供に責任を持ち、リーダーシップを発揮する経験ができる。
 年下の子は年上をを尊敬し真似る。
 年齢別クラス編成は、子供にチーム運営やリーダーシップを発揮する経験を奪っている。

・カーンアカデミーが理想とするのは、年齢の区別のない「一つの教室」。
 年上の生徒やできる生徒が、理解が遅い生徒や年下の生徒に教えることで、自分の理解を深め、リーダーシップの経験を得る。
 年下の生徒は、お兄さんやお姉さんから色々なお手本に接することで、能力を伸ばす。

・年齢混合クラスを推進するならば、先生と生徒の比率はそのままで、もっとクラスを合併して大きくすることもできる。
 例えば、100人のクラスに4人の先生という配置も可能。
 複数教師制度はメリットが多い。
 教師が協力し合えるし、教師の得意分野を生かした配置も可能。
 何よりも、教育では先生と生徒の相性という人間的な要素が大きいため、複数の先生がいれば、自分に合った相性の先生を見つけることもできる。

・教師もチームスポーツのコーチのように、教師は生徒の味方であるというメッセージを送るべき。
 カーンさんは言う。
 教室での授業は実社会での競争に対する準備に他ならない。
 テストは、生徒にレッテルを貼って恥をかかせるのではなく、生徒の能力を計測するためにある。100点が取れなかったのは、頭が悪いのではなく、取り組むべき課題がまだあるからだ、と。

 可能な限り、創造的な、自分の頭で考える人間になって欲しいからこそ、基礎概念から完全に習得してもらわないと意味がない、と。

 2010年に小学校に入った全世界の子供たちの65%は、将来、今は存在しない仕事に就くだろうという予測がある。
 例えば、コンピュータやインターネットが世の中にあふれて、産業構造も大きく変わった。
 だからこそ、子供たちに何かを教えるのではなく、どのように独学の姿勢を身に着けるか、にある。

・現在の学校制度において、夏休みは全面的に見直すべきだ。
 今の夏休みは、時間とお金の壮大な無駄だ。
 世界中で、1か月間以上、校舎や体育館、教室という教育インフラが使われていない。
 先生も事務員も仕事せず、生徒も学習しない。
 生徒の継続的学習を阻害している。
 農業が基本的な産業だったころの名残にすぎない。
 未来の学校は、必要な時にいつでも休めるように、会社と似たような有給休暇の仕組みを作るべきだ。

・学校における生徒の成績表も根本的に変えるべきだ。
 従来の古い教育スタイルを変えるには、カーンアカデミーのような学習フィードバックシステムと、二つの評価方法がある。
 一つは、生徒がこれまで何を学んできたか、という学習記録。
 もう一つは、生徒の創造的な業績のポートフォリオ。

・前者については、現代のソフトウェアによって、生徒の進捗状況や勉強方法、問題解決手法を学習記録から簡単に追跡できる。
 フィードバックシステムは学校ごと、生徒ごとにカスタマイズできるし、生徒がどの程度進歩したか、一定期間の学習ペースなどを定量的に把握できる。

 興味深いのは、定量データによるフィードバックだけでなく、定性データの方だ。
 学習意欲、粘り強さ、復元力などの人格的要素を、学習記録から拾い出せる可能性がある。
 例えば、ジョニーは立ち往生している。彼は、そこで逃げ出すのか、分かるまで勉強を頑張ろうとするのか。
 例えば、モーは、勉強に不熱心で学習時間も少なかったが、突然、生物の勉強に励むようになったのは、なぜなのか?
 生徒の成長ぶりや特定分野の潜在能力を物語る事実が含まれているのではないか。

・現在は生徒評価に全く考慮されない特性「他人を助けようとする能力」もフィードバックシステムで記録できると良い。
 例えば、学習内容を他の生徒に説明するのがうまい生徒は、その内容を深く理解しているし、他人に対しても寛容だろう。
 そのようなデータが記録し続けることができれば、生徒を多面的に評価することもできる。
 
 これが後者の評価につながる。

・カーン氏は生徒の成績表の中心となる「クリエイティブ・ポートフォリオ」を提案する。
 特定の科目ができるかどうかよりも、好奇心や創造性を発揮しているか、に目を向けて、その結果を記録し、評価し、フィードバックして改善していく。

・教育にはいくつかの根本問題がある。
 一つは、最善の学習方法とは何か。 たとえば、完全習得学習スタイル。
 二つ目は、社会化とは何か? たとえば、仲間同士の協力や年齢混合クラス。
 三つ目は、資格認定制度はどうあるべきか?

・現代のテクノロジーを使った思考実験をする。
 大学から、学生を教える役割と資格を認めるという役割を切り離したらどうなるか?
 どこの大学を卒業したのか、ではなく、国際的に認知された厳格なアセスメントテストを受け入れたとしたら、何が起きるか?

 現実では、フルタイムで働きながら短大で好成績を収めるような子供は、間違いなく有名大学卒業生よりも冷遇されている。
 でも、アセスメントテストがあれば、貧富も関係なく、卒業した大学も関係なく、有名大学の卒業証明書と同程度の知識があることを証明できる。
 エリート校も独自性を発揮しようと特化するだろう。
 つまり、資格認定のコストが下がり、大学の権威が増すだろう。

| | コメント (0)

2014/02/04

Redmineに「応援する」リンクをつける

@kawanishi_ameyaさんから、Redmineに「応援する」リンクをつけるプラグインを教えていただいたのでメモ。

【元ネタ】
Twitter / tkusukawa: redmineのチケットにとても良いコメントがあり、いいねボタンが欲しいと思ったw

Twitter / akipii: いいねボタンが欲しい時がある RT @hito_asa: 社内Redmine、Backlogと違って味気ないというか、スターつける仕組みもないしなんだかコミットしてて寂しくなってくるのです。スター重要。

Twitter / akipii: @nmrmsys @hito_asa FacebookのLikeボタンではなく、Redmine内部ではてなスターみたいに、いいねを表示する機能が欲しいですね。チケット画面とチケット一覧画面に表示する仕様だけだから、プラグインで誰か作ってくれないかな?

Twitter / kawanishi_ameya: @akipii 昔作ったので最新で動くかは知らないですが https://github.com/ameya86/redmine_ouen … https://github.com/ameya86/redmine_ouen/blob/master/sample/ouen2.png … https://github.com/ameya86/redmine_ouen/blob/master/sample/ouen1.png … なものはあるにはあります。

【参考】
ameya86/redmine_ouen

Ouen1


Ouen2

【1】Facebookが急速に普及した理由の一つは「いいね!」リンクがあることだろう。
共感できたら、その気持ちを「いいね!」で表現する。
「いいね!」がたくさんあるほど、共感した人が多い事実を意味する。

Twitterならリツイート回数やフォロワーに相当するだろうが、「いいね!」の方が直感的でわかりやすい。

はてなスターもそうだし、Backlogにもそんな機能があるのに、Redmineにはなかなかなかった。

【2】RedmineにもFacebookのLikeボタンのプラグインはある。
しかし、社内のRedmineサーバーにFacebookでログインすることはセキュリティ上できなかったりする。

Like button - Plugins - Redmine

だから、Redmine内の閉じた中で、Likeボタンのような機能があるとうれしい。
インスピレーションを働かせてくれるチケットやコメント、おお!と驚くようなコメントがあれば、Likeボタンを1票付けたい気持ちが出てくる時がある。

上記のプラグインでは、「応援!」「頑張れ」のフラグの回数をカウントする機能がある。
プロジェクトリーダーならば、障害チケットの修正作業で手こずっている開発者がいれば、そのチケットに思わず「頑張れ!」「応援!」のフラグを立てたくなるのではないだろうか?

とは言っても、結合テストで50個もバグが出たら、そのたびに障害チケットにがんばれフラグを立てると、どう見ても進捗を催促しているように思えてしまうかもしれない(笑)

他にも、下記の記事のように、完了チケットに「Good job!」を表示するプラグインもある。

Redmineを使うのが楽しくなるプラグイン3つ

【3】GitHubが単なるソースを管理するリポジトリサービスだけでなく、ソーシャルな関係をサポートする洗練されたサービスを提供することで、Gitの普及に大きく貢献した。

GitHubでは、WatchやFolkがそのソースコードの人気度を表す。
たくさんの人がフォークすれば、それだけたくさんの修正パッチや改善機能のパッチが送られることになり、ソースコードの品質も機能も大きく拡張されるだろう。
つまり、GitHubは、ソースコードを他人に公開して共感してもらえることが楽しい、という新しいサービスを生み出したわけだ。
これがいわゆる「ソーシャルコーディング」と呼ばれるものになる。

ソーシャルコーディングの考え方は、単なるプログラムだけでなく、憲法や法律、著作物などのテキストで表現される実体にも拡張できるし、それによって、より多くの人を政治的参加や創造に向けることになるだろう。
ソーシャルな機能は単なるお遊びだけでなく、多くの人達をまきこんで、一つの運動を生み出す可能性を秘めている。

GitHubによるソーシャルコーディングが法律や出版物を変革させる可能性: プログラマの思索

この1年間で作成されたリポジトリは550万件にも:GitHubのリポジトリが1000万件に到達 - @IT

Redmineによるチケット駆動開発に、ソーシャルな関係を強化する機能を追加して、チケット管理をもっと楽しめるようにできないか?
チケット管理を楽しくするための技術はもっと研究される余地があるだろうと思う。

【追記】
こんなフォローがあったのでメモ。

Twitter / kawanishi_ameya: プラグインのReadmeにも書いていますが、言語ファイルを書き換えることで「いいね!」や「+1」にすることが出来ます。 RT @akipii Redmineに「応援する」リンクをつける http://bit.ly/1bZ8Pxp

| | コメント (0)

2014/02/02

「これだけ! KPT」の感想

天野勝さんが出版された本「これだけ! KPT」がとても良かったのでメモ。
ラフなメモ書き。

【1】天野さんの体験談
・チームの分裂を回避するためにKPTを実施
  KPTを実施してみたら、実はチーム内では対立していなかった

・KPTのデジャブ
  以前の会社で、完了報告書にベストプラクティスを教訓として残す作業があった
   何が嬉しい?
  繰り返し型開発でKPTを実施したら、自然にプロセス改善された
   Keep=ベストプラクティス、教訓
   Problem=問題
   Try=対応策

【2】KPTの使い方

・学びを整理するKPT
  教訓を残す

・現状打破のためのKPT
  行動を促す
   より良くするため
   問題を取り除くため

・カイゼンのKPT
  継続的改善のため
  Problem→Try→Keep
   問題解決
  Try→Keep
   新しいことに挑戦する
  Keep→Try→Keep
   良かったことをもっと良くする

【3】PDCAサイクルを回せない管理職が多い

・理由:PDCAを回した経験がない
    プロセス改善の経験がない

→PDCAを回すには練習が必要
  1週間単位がやりやすい
   3か月~1年のサイクルは長すぎる
   回すだけでも大変

・理由:有益な情報がないので、Planを立てられない

→CheckとActionから始める
  PDCAではなく、CAPDにする
  現状:Keep、Problem
  課題:Try
  そこから対応策を計画にする

【4】KPTのやり方

・10分KPT
・30分KPT
・60分KPT
・120分KPT

【5】KPTの注意点

・意見の取捨選択
 影響度 * 発生頻度のマトリクスで、優先順位付けする

・KPTと相性の良いフレームワークがある。
 KPTで問題を深堀するための観点として使う。
  7つのムダ
  5S
  4P
  3C
  SWOT

【6】KPTのアンチパターン

・わがままTry
 状況:TryはKeepになるが、Problemが残ったまま

・計画先行
 状況:Tryが多すぎる。KeepやProblemが少ない。前回のTryが評価されていない。

・言ったもの負け
 状況:Tryは少数意見のみ。Tryを言い出せる雰囲気がない。チームの成熟度が低い。

・救われないProblem
 状況:Problemが多すぎ。問題の深堀だけで、行動(Try)につながらない。

【7】KPTの仕組み

・チームの成長プロセスは、タックマンモデルに従う
  形成→混乱→統一→機能
  チーム間の対立は、チームが一体化するために必要な作業
   雨降って地固まる

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

・KPTと相性の良いテクニック
 ファシリテーション
 見える化
  タスクボード、バーンダウンチャート
 改善活動

【8】感想

プログラマからリーダーになると、チームとしてのアウトプットが要求される。
リーダー個人の能力が優れていても、チーム全体で進捗が進み、成果物を出せなければ、リーダーとしての管理能力がない。
それは、一つのマネジメントスキル。

いきなり技術者がマネジメント能力を身に着けるのは難しいと思う。
しかし、KPTによるプロセス改善から、チームを回す能力を身に着ける方法は結構有効だと思う。

アジャイル開発やスクラムで言われるサーバントリーダーシップは、リーダーが万能で指示命令型ではなく、メンバーを信頼し、メンバーが最大限の能力を発揮できるように、自律化を促す。
そのためには、メンバーに目標と対応方法とモチベーションを渡すのが必要。
KPTにはそのテクニックが十分に埋め込まれていると思う。

なお、P.169にKPTの指標(KPI、メトリクス)の一覧がある。これはすごく便利そう!
ぜひ使ってみたい。

| | コメント (0)

第6回shinagawa.redmine勉強会の前に中間フィードバック #47redmine

@naitohさんが昨年6月の品川Redmine勉強会で収集したアンケート結果を公開されていたのでメモ。

【元ネタ】
第6回shinagawa.redmine勉強会のご紹介と中間アンケート結果 #47redmine - @naitohの日記

記者の眼 - 「新3種の神器」で開発現場を改革しよう:ITpro

第6回品川Redmine勉強会をデブサミ2014の翌日に開催します #47redmine: プログラマの思索

第6回勉強会 - shinagawa.redmine

(引用開始)
33名分の中間集計ですが、どのようなRedmine の利用者が勉強会に参加されようとしているか参考にしてみてください。

Redmine 2.3/2.4 を利用している人が大半ですが、最新のRedmine 2.4への移行が始まっている感じです。
バージョンアップはプラグインが対応しているかでつまづくポイントなので、
Redmine 1.4 止まりの人が多少おられますが、この辺りも一つのハードルと思われます。
(※複数回答なので、古い環境も平行して使われている人もいるようです。)

プラグインの利用数は、3~6個ぐらいが多いみたいです。10個以上使用している人は少ないんですね。
ちなみに、自分は仕事では10個以上使っているのでバージョンアップ時は各プラグインの動作確認が非常に大変です…。

バージョン管理ツールは、Subversion だけでなく Git を使っている方も結構おられますね。
Mercurial な方も1名いらっしゃいます。
(引用終了)

最近は、RedmineのVer1.xで運用しているものの、Ver2.x以降のバージョンに更新できない、という話を聞く。

Ruby1.9/2.0への対応、RailsのVerUp、Prototype.jsからJQueryへの移行などがあり、古いバージョンのRedmineから構造ががらりと変わっている。

また、RedmineをVerUpできない事例を聞くと、プラグインを入れていたり、パッチを当てているために、スムーズにVerUpできない理由があるようだ。

そんな話を聞くと、改めてRedmineというプロジェクト管理ツールもERPのVerUpないしリプレース作業に似ているなあ、と感じる。
普通は、MySQLのデータ移行だけで十分なはずなのに、カスタマイズしたソースを洗い出し、さらに回帰テストも実施しなければ、今までと同じ機能の品質を保証できない。

このあたりの話やRedmineをカスタマイズする時の注意点は、2014/2/15に開催する第6回勉強会 - shinagawa.redmineでお話しする予定です。

ぜひ聞きに来てください。

| | コメント (0)

2014/02/01

WindowsクライアントアプリRedmine Desktop Client

RedmineのWindowsクライアントアプリとしてRedmine Desktop Clientがあるらしいのでメモ。

【元ネタ】
Redmine Desktop Client - 常時手元においておきたいデスクトップRedmineクライアント|オープンソース・ソフトウェア、ITニュースを毎日紹介するエンジニア、デザイナー向けブログ

redmine-desktop-client - A port of the original RedmineClient to use the REST API of Redmine - Google Project Hosting

redmine-net-api - Redmine .Net API - Google Project Hosting

RedmineのREST APIを利用して、Windows上でチケット操作できる。
ブラウザで操作するのが面倒な時に便利そう。

| | コメント (0)

« 2014年1月 | トップページ | 2014年3月 »