2017/08/15

制度的リーダーシップの考え方が何となくしっくりきた

エラスティックリーダーシップ ―自己組織化チームの育て方」を読みながら、リーダーシップとは一体何だろう、と疑問に思った。
すっきり腑に落ちなかったけれど、「制度的リーダーシップ」という概念で改めて考えてみたら、自分としては納得できそうだった。
ラフなメモ書き。
間違っていれば後で直す。

【参考】
セルズニックが提唱した制度的リーダーシップの意味が何となくわかった | 日々の練習

戦略論の復習④…SWOT分析と戦略立案プロセスの発展|田舎者の受験日記

制度的リーダーシップ(せいどてきりーだーしっぷ)とは - コトバンク

第11話 企業経営理論④ リーダーシップ論 ~自称週末ファーマーの国家試験受験記~ - 自称週末ファーマーの菜園ブログ

金井 一賴 | ビジネス基礎講座経営組織04

「連結ピン」とは? - 『日本の人事部』

連結ピン(リッカート提唱)とは?マネジメントに必要な連結ピン | BizHint HR(人事の悩みにヒントを届けるニュースサイト)

【1】リーダシップのある人は、外から見るとオーラがある。
その人に皆が付いて行く感じ。
アジャイル界隈なら、平鍋さん。

コミュニティでは、そのオーラは、その人の個性、人格、能力から発生する時が多いと思う。
その人が発する意見、言動から、自然に周囲の人が感化されて、たんぽぽみたいに散らばっていくけど、その種は絶えることはない。
コミュニティでリーダーシップのある人は、影響力という能力を自然に持っている。

一方、企業のような硬い組織でも、リーダーシップらしきものを見かける時がある。

企業は所詮、営利団体なので、売上と利益が全て。
売上と利益を目標にした企業行動があり、その影響を受けて、管理職も社員も追随する。
管理職がそういう話をする時、無茶な売り上げや利益が出るときもあるから、普通は話半分で聞いている人が多いのではないか。
ある組織構造の利益責任を直接負うのは管理職以上であり、社員は単独の案件の管理責任に閉じているから。

すると、企業のような組織ではリーダーシップは見えにくいように思われるが、そうでもない。
特に社長は、自分は将来、こうしたいのだ、と宣言して、実際に行動する。
たとえば、組織構造をいじったり、大きな人事異動をしたり、M&Aをやったり。
その行動を見ると、違った意味でのリーダーシップを見ているような気がしている。

では、何が違うのか?

【2】セルズニックが提唱した制度的リーダーシップの意味が何となくわかった | 日々の練習では、こんなコメントがあって、なるほどと思った。

(引用開始)
「制度的リーダーシップ」は、かねてから意味が飲み込めずに困っていた用語であった。
原価計算論の教科書トレーニングで予算のところを練習していたところ、
予算の計画機能の具体的アクションとしては各管理者の目標を公式化することがある
と書かれてある箇所に、
組織内に制度として組み込む
というメモ書きがあった。
おそらく教科書にある記述を先生が別の表現で説明してくれたのだろう。
制度化とは公式的に組織に組み込む、ということがわかった。
とすると、制度的リーダーシップとは、
リーダーシップという精神、考え方、コンセプト、ぼんやりした抽象的なものを、
見える形でシステムとして組織に取り込むこと
だといえそうだ。
これならしっくりくる。
一応は納得することができた。
(引用終了)

(引用開始)
企業が外部環境の変化に対応するため組織を変更すると(命題:組織は戦略に従う)
組織は内部整合性をとるために新たな価値を注入する必要がある(命題:制度的リーダーシップ)、
といった具合に外部・内部環境を関連させて考慮するようになったのです。
(引用終了)

企業という組織は、売上目標や利益目標が必ずある。
その目標を達成するために、何らかの行動を起こさなくてはならない。

普通は、社長などの経営陣が売上目標や利益目標、経営戦略を立てて、その方針を実行するのが管理職。
すると、管理職は「連結ピン」の役割を担うと同時に、事業部の売上目標・利益目標を実行する具体的な行動をリーダーシップとして制度的に埋め込むわけだ。

つまり、管理職は必然的に、組織からリーダーシップを強制される。
そういうリーダーシップという性質を管理職が持たなければ、社員は影響されないし行動しないから。
それが制度的リーダーシップというものなのだろう。

たとえば、簿記1級の管理会計では、事業部の業績評価と事業部長の業績評価は異なる、という指摘がある。
事業部長が管理可能なコストと、事業部のコストは一致しないから。

事業部長は自身の評価を上げるために、組織の売上目標・利益目標を達成しようとする。
そのために、彼自身はリーダーシップを発揮する必要があり、それは、制度的リーダーシップとして、組織から公式的に与えられたミッション、リーダーシップとして付与されるわけだ。

【2】制度的リーダーシップの概念で、過去に思っていた幾つかの疑問は解けた気がしている。

【2-1】以前、役職が上がる人ほど、実際の言動は厳しくても、言う言葉がすごく綺麗事になっている気がしていて、不思議に思っていた。
そんな綺麗事を言っていても、実際の行動は違うじゃないか、と。

その理由は、社会的地位が高くなるほど、そういう人達は自然に制度的リーダーシップを持つようになるのだろうと推測する。
社会的地位という組織構造が、制度的リーダーシップを個人に強いるわけだ。
リーダーシップを発揮するように、その人個人を変えてしまうこともあるだろう。

「立場が人を作る」という言葉は、役職に就いた人が制度的リーダーシップによって成長した、という道もあることを示唆しているのではないか。

【2-2】制度的リーダーシップは、組織構造から離れると、その人からリーダーシップは消えてしまうのではないか。

なぜなら、事業部長という役職にいるからこそ、そのリーダーシップは発揮されているわけで、役職を外れたら、ただのおじさんに過ぎないから。
制度的に埋め込まれたリーダーシップを外された事業部長が、自身でリーダーシップを発揮できるのだろうか?

会社一筋に生きてきた人が、会社から離れると、すごく影響力がない人に変わってしまう現象があるが、その理由は、そこにあるのだろうと推測する。

【3】では、リーダーシップとは、個人が自然に持つ性質と、組織から公式的に付与されて制度として組み込まれる性質(制度的リーダーシップ)の2種類があるとしたら、その違いの本質は何なのか?

リーダーシップには、個人に由来する性質と制度に由来する性質がある。

制度に由来するリーダーシップは電磁石みたいなもの。
電気があれば、制度的リーダーシップは発揮されるが、電気がなくなると磁力が切れてしまうのと同様に、制度的リーダーシップも消えてしまう。

一方、個人に由来するリーダーシップは天然磁石みたいなもの。
その人個人が自然に持つ影響力(磁力)が自然にリーダーシップに変わる。

そう考えることは出来ないだろうか。

【追記】
門屋 浩文さんのツイート: "@akipii 職務に忠実なリーダーシップは本当のリーダーシップな?と懐疑的です あくまで職務に忠実なだけなのでは? 職務に忠実なのも大事なことですが"

akipiiさんのツイート: "@MadoWindahead そう、本当のリーダーシップなのか、という疑問は同意です。実際の組織の現場では、制度的リーダーシップによってリーダーシップを発揮している管理職の事例はよく見かけませんか? 僕はよく見かけます。"

| | コメント (0)

2017/08/12

Redmineにプロジェクト報告を機能追加するLycheeProjectReportプラグインが面白い

アジャイルウェアさんがLycheeProjectReportプラグインを公開されていた。
デモ画面を見て、色々アイデアが浮かんだのでラフなメモ書き。

【参考】
プロジェクトレポート | Lychee Redmine(ライチレッドマイン)でプロジェクトの見える化を。そして管理ももっと楽にしよう。

Kawabata Mitsuyoshiさんのツイート: "\Lychee Redmine更新のお知らせ/ Lycheeプロジェクトレポートがリリースされました! https://t.co/cbzZSIF03f... https://t.co/y3sdKxncWj"

akipiiさんのツイート: "興味深いプラグイン。経営層向けにRedmine をアピールできるだろう。RT @agilekawabata: Lycheeプロジェクトレポートがリリースされました! https://t.co/iK2E6kOTui... https://t.co/yBsSWACS9h"

門屋 浩文さんのツイート: "@akipii @agilekawabata 精度の高いプロジェクトKPIの決め方についてコンサルが必要になりそう"

akipiiさんのツイート: "@MadoWindahead @agilekawabata どこの会社でも、事業部ごとの目標利益率はあるので、それとの整合性が必要でしょうね。また、経営層のマクロの観点とプロジェクトリーダーのミクロの観点は違うので、どう運用すべきか?面白いネタと思います"

【1】下記の宣伝文言がある。

(引用開始)
Redmineを利用している多くのPMOが、「親子プロジェクトの俯瞰的な確認」「マイルストーンの確認」「進捗・品質・コストの管理」に、頭を悩ませています。
Lycheeプロジェクトレポートは、「複数のプロジェクトの営みを統合管理したい」というPMOの悩みを解決します。
(引用終了)

長年経験してみた結果、Redmineというプロジェクト管理ツールは、現場のチーム向けのツールであり、経営者向けのツールではないと思う。
受託開発プロジェクトでタスク管理を行うと、計画していた当初のタスク以外に、予期しなかったバグや突発的な仕様変更がたくさん湧いてくる。
むしろ、そういう「予定していない」障害管理、「外部環境の変化や顧客要望の変化による」課題管理や仕様変更の管理の方がはるかに重要だ。

よって、Redmineのチケット管理では、細かな粒度でチケットを作っては消していくことが多くなる。
なぜなら、そういうバグ、課題とか、仕様の変更管理は、細かな粒度で発生する時が多いからだ。
あるいは、そういう細かな点まで気配りして、変更管理しなければ、すぐにソース管理でデグレが発生したり、マージ漏れが発生したりするからだ。

つまり、プロジェクトリーダーの観点では、Redmineのチケット管理を通じて、ミクロな観点でプロジェクト管理を運用していく。

【2】一方、部長や事業部長など経営層に近い人の観点では、マクロの観点であり、個別案件のマイクロマネジメントには興味はない。
彼らは、事業部全体で、複数のプロジェクトの進捗や採算の動向を把握したいのであり、個別案件の進捗管理や利益責任はプロジェクトリーダーに任せているからだ。
経営層は、事業部の配下にある複数のプロジェクトの採算全ての責任を負っているので、観点が違う。

すると、経営層としては、各プロジェクトの進捗や品質、採算の観点で毎週、毎月の報告が見たくなる。
つまり、経営層はRedmineの各プロジェクトの現状をまとめたサマリが欲しいのだ。

Redmineがいくら良くても会社の上司や経営者が見なければExcelがはびこってしまう事例: プログラマの思索

従来は、このサマリがプロジェクト報告書であり、毎月末にプロジェクトリーダーがExcelの報告書を書くのが習わしだった。
この作業に、プロジェクトリーダーのかなりの管理工数が割かれているはずだ。

プロジェクトの現状は、Redmineチケットに全て蓄積されているが、そのままではプロジェクト報告にはならない。
トラッカー別、日別・月別、ステータス別など数多くの観点でチケット集計し、それらチケットを精査しなくてはならない。
経営層向けに報告するために、数値の正確さはもちろん、報告の文章と数値の整合性が取れていなくてはならないから、結構神経を使う。

しかも、PMOからは、各プロジェクトの進捗状況をお天気マークで表示しろ、とか、進捗や品質の閾値を元に進み具合を報告しろ、などと言われる。
いわゆる、プロジェクト報告の標準化を強いられるわけだが、プロジェクトリーダーの工数をさらに増やすだけ。

そして、実際の案件会議では、各プロジェクトの報告時間は限られるので、労力を使った報告書もさほど読まれないという悪循環があるだろう。

そういう実情を考えると、LycheeProjectReportプラグインのように、Redmineにプロジェクト報告の機能があればいいな、と以前から思っていた。

【3】では、プロジェクト報告に必要な機能は何なのか?

個人的にはいくつかあると思う。
1つは、プロジェクトの現状を指標(KPI)で数値化し、事前に決められた閾値で評価すること。
2つ目は、報告内容が記載できて、報告内容のテンプレート機能があること。
3つ目は、報告の履歴が残せて、それらを一覧で見れること。
最後に、プロジェクトの種類でKPIや閾値を分けて管理できること。

【3-1】プロジェクトの定期報告は、従来はExcelの報告書が多かったと思う。
しかし、経営層が欲しいサマリ情報は、Excelの報告書ではなく、Redmineに蓄積されたチケット情報を元に抽出された指標(KPI)が欲しいはずだからだ。

それらの情報はRedmineから即座にチケット集計でメトリクスを抽出できる。

たとえば、進捗は、全チケットのステータスや進捗率から計算できるだろう。
品質は、障害チケットからステータス別に集計すればいいだろう。
コストは、予定・実績工数が入力されている前提として、工数ベースでEVMを計算すればいいだろう。
その前提であれば、進捗もEVMからSPIで進捗度合いを評価できるだろう。

つまり、プロジェクト報告を保存する時点で、チケット集計するバッチを動かせば、その時点のメトリクスを保存できる。
KPIの採取はシステムによって自動化すれば、プロジェクトリーダーはその数値を参照して、報告内容を書くだけで良い。

毎月報告する運用であれば、毎月末にQCDの観点でKPIが保存されるので、報告の履歴から各KPIの時系列の推移も見れるはずだ。
そうすれば、第三者も、プロジェクトがどこで遅延が発生したか、どこで採算が悪化したのか、を把握しやすくなる。

また、進捗や採算の評価は、プロジェクトリーダー個人の判断ではなく、事業部で決めた閾値でもって判断するようにしたい。
なぜなら、事業部には社長から言い渡された目標売上高、目標利益率があるので、それらをブレイクダウンしたら、各案件の最低の利益ラインは分かるはずだから。

【3-2】また、そのKPIに、プロジェクトリーダーがコメントした報告の文章があると良い。
できれば、報告のテキストエリアには、IssueTemplateプラグインのように、報告テンプレートがあるとなお良いと思う。
なぜなら、各プロジェクトリーダーの報告内容は、記載ルールがなければ、バラバラになってしまい、本来書いて欲しい内容が漏れてしまいがちだからだ。

経営層やPMOの立場としては、QCD(進捗・品質・採算)の観点だけでなく、現状のプロジェクトのリスクや課題は何であるか、懸念事項は何であるか、も報告して欲しい。
普通は、どのプロジェクトも進捗遅延になりがちなので、遅延した原因と対策、今後の動向が知りたいのだ。

そして、彼らとしては、報告内容にある懸念事項の内容から、プロジェクトリーダーのリスク管理能力を見たいのだ。
進捗遅延の状況で、今のプロジェクトリーダーにそのまま任せても大丈夫か?
火を吹いた状況で、今のプロジェクトリーダーには、現状を改善できる能力はあるのか?

報告内容から、プロジェクトリーダーの分析能力、リスク対応能力を推量したいのだ。

LycheeProjectReportプラグインには、そういう報告テンプレート機能はあるのかな?

【3-3】実際の運用では、さらに、プロジェクトの種類ごとに、KPIや評価の閾値も分別して管理したい。
なぜなら、受託の新規開発案件ばかりではなく、定額請求の保守案件もあるだろうし、実費請求の要件定義プロジェクトなど多種多様な案件があるからだ。
特に、保守案件に、新規開発案件のKPIをそのまま適用しても上手く評価できないだろう。

保守案件は普通、毎月の定額請求なので、毎月の検収金額は決まっている。
すると、その案件に張り付くメンバーも固定されていて、彼らの人件費や工数は既に大枠は決まっている。
その予算内で回るように、進捗管理すべきだから。

普通のSIerでは、新規の受託開発案件で1次開発は赤字であっても、2次開発以後や保守案件では黒字化するのが普通なので、そういう保守案件のコスト管理の方が重要だったりする。

したがって、受託開発、保守、請負契約、定額請求、実費請求などの種類に応じた指標や閾値を設定できるようにしたい。
特に、大企業や大きな事業部では、PJの数も多いし種類も様々なので、PJの種類別の指標値の設定管理の機能はすごく重要だろうと思う。

LycheeProjectReportプラグインを見ると、進捗・品質・コストごとに、指標を新規登録できて、閾値も区別できる機能がある。
つまり、そういう観点では、よく考えられていると思う。

【4】第三者の観点で好き勝手に言わせてもらえれば、プロジェクト報告プラグインは、EVMやリソース管理、ガントチャート、信頼度成長曲線などと連動しているとなお良い。
なぜなら、経営層が各プロジェクトのサマリを報告機能で見ていた時、もっと詳細な情報を知りたいと思ったら、EVMやガントチャートを見たくなるからだ。
彼らも、サマリ情報からドリルダウンして、詳細な情報を見たくなるだろうから。

但し、彼らはチケット一覧の画面は見たくないだろう。
なぜなら、チケット一覧を見ても、たくさんのチケットが無造作に蓄積されているだけであり、そこから意味ある情報を読み取るのは面倒だから。
むしろ、EVMやガントチャート、信頼度成長曲線を見た方が、進捗状況や採算状況が分かりやすいから。

つまり、プロジェクト報告の機能は、QCDの観点によるチケット集計の画面と連動している方が使いやすいはず。
たとえば、プロジェクト報告の画面で、報告内容の横にあるKPIの数値にリンクがあり、そのリンクから、EVMやリソース管理、ガントチャート、信頼度成長曲線の画面へ遷移できるといいだろう。

実際、そこまで作り込んでいるかどうか知らないが、色んな可能性を秘めていると思う。

| | コメント (0)

2017/08/10

法律の背後には経済学の理論があるという仮説

法律の背後には経済学の理論があるという仮説についてメモ。
以下は主張がまとまっていないが、素人によるラフなメモ書き。

【1】とある会合に出た時、そこでは、参加者やスタッフが中小企業への施策を色々議論して、アイデアをまとめていた。
最終的には、それらのアイデアを施策としてまとめて、中小企業庁へ持参して、提案書として渡したらしい。
そして、今年度の中小企業への施策に、提案の内容が盛り込まれており、やった意義があった、という報告があった。
その時に、こういう施策が実行されると、我々士業にもお仕事が舞い込むんですよ、という話があった。

その話を聞いて、すごいな、と思うと同時に、別の考えが浮かんだ。
政治では、基本は法律を策定して、企業や人間の行動を規制したり、補助金のようなインセンティブを与えてある方向へ誘導したりする。
つまり、法律は、世の中の社会において、みんなの不利益となるような企業行動は規制し、将来の産業育成や弱者保護のような方向へ企業行動が向くようにインセンティブを与える。

法律の暗黙の前提には、人間は全てが善人とは限らず、悪人もいるので、そういう人たちを規制しなくてはいけない、という考えがあるような気がする。
すると、個人一人の思いや行動というミクロではなく、集団や企業、国家のように人間を集団というマクロで見て、その全体を規制したり、ある方向へ誘導するように制御したくなる。
実際、すべてを自由に任せていたら、悪い行動は誰も規制できなくなる。
そのために法律があるのではないか。

つまり、法律という制度によって、企業行動や人間の行動を規制して、ある方向にインセンティブを持たせるように仕向けているわけだ。
この考え方は、経済学における「制度経済学派」の考え方に近いのではないか。

【2】マンキュー経済学の本でも、「経済学の10の原理」で、「人々は様々なインセンティブに反応する」「通常、市場は経済活動を組織する良策である」「政府が市場のもたらす成果を改善できることもある」という原理があるが、それらを連想する。

経済学の十大原理

経済学の十大原理(マンキュー入門経済学) | 経済を10分だけ学ぶ

普通は、市場経済で自由に任せた方がいい。
企業も人間も、自由にアイデアを作り出し、事業を生み出して、自由に経済活動をすればいい。
でも、自由な市場経済原理で上手く行かない場合も多い。
そこで、法律という制度で、大企業が独占しないように規制したり、補助金を新産業で活動している中小企業に与えたりして、その方向へ他の企業が向くようにインセンティブを与えたりする。

【3】他に、独占禁止法が存在する理由がまさにそう。
独占・寡占市場に対しては、独占禁止法が対処法の一つ。

「市場の機能がうまくはたらけば、資源が効率的に配分される」というのが基本的な経済学の考え方だが、独占・寡占によりそれがうまく機能しない場合が「市場の失敗」。
そうならないように、自由な競争を生み出すように独占禁止法が存在し、公正取引委員会もある。

独占禁止法の存在意義には、経済学の理論が根底にある。

【4】他に、SCPパラダイムという言葉を知って、何となく関係があるような気がした。

SCPモデル/パラダイム - techdmba

SCPパラダイム - 人材開発・組織開発コンサルタント「ZOFFY」の日記

戦略論の復習②…ポジショニングアプローチ|田舎者の受験日記

SCPパラダイムは、ある業界の構造を分析する際の枠組み。
市場構造(Structure)が市場行動(Conduct)を規定し、市場行動が市場成果(Performance)を規定する(つまりS→C→P)という考え方で、外部環境が企業の行動を規定し、企業の利潤を規定する、という考え方。

この発想を展開すると、ある業界で独占利潤を得ている大企業がいて、消費者が不利益を被っているならば、余剰利益を得ている企業(P)に対し、その企業の行動を法律などで規制し(C)、とどめに法が無くても企業が余剰利潤を得られないような市場構造にする(S)というロジックも成り立つ。
つまり、法律によって、企業行動を規制することで、独占利潤を得られないようして、自由競争になるような方向へ誘導する。

おそらく、独占禁止法だけでなく、下請代金支払遅延等防止法など数多くの中小企業向けの法律も、そういうロジックがあるのだろう。
つまり、本来は、弱者である中小企業を守るという政治的事情として法律が作られているのだろうが、大企業が独占利潤を得にくいように、経済学の理論で補強できるように法律を構成しているのではないか。

換言すれば、そういう理論を背後に法律を作っているならば、現実を規定する法則に即しているので、その法律はすぐには廃れないだろう。

| | コメント (0)

2017/07/26

第17回Redmine大阪勉強会の見所~Redmineをナレッジシステム、そしてプロセス保証のツールへ進化させたい #RedmineOsaka

第17回Redmine大阪勉強会が8/26土で告知された。
見所を公開しておく。

【参考】
Redmine大阪 第17回勉強会 - connpass

Redmine大阪 第17回勉強会の懇親会 - connpass

【1】今回のテーマは「Redmine3.4.0と全文検索エンジンの徹底解説!」。

(引用開始)
2017/7/2にRedmineのメジャーバージョン3.4が無事にリリースされました。
Ver3.4には、Redmineのかゆい所に手が届く機能改善が多数リリースされているので、Redmineを利用できる場面がもっと増える効果があるでしょう。

今回の勉強会では、Redmine3.4.0の徹底解説と、Redmineの全文検索機能を強化することでRedmineをナレッジシステムへ飛躍させる可能性を秘めるお話の二つをメインテーマとして提供します。
Redmineの初心者から、Redmineをバリバリ使う経験者まで、興味のある方はぜひお越しください。
(引用終了)

【2】@g_maedaさんには、Redmine3.4.0の徹底解説やRedmineのVerUp手順、今後のRedmineの展望などを講演して頂く予定。
Ver3.4のメジャーバージョンのリリースに至るまで1年かかったが、リリースされた機能改善の内容は、Redmineの使い勝手を心地よくしてくれるものばかり。
現時点では、Ver3.4.2までリリースされていて、細かなバグはかなり潰されている。

個人的に興味があるのは、次のメジャーバージョン4.0の内容だ。
Ver4.0では、Rails5についに対応する。

今から知っておきたいRails 5の新機能・変更点 - Qiita

ざっくりRailsの各バージョンの流れ - kasei_sanのブログ

Rails5に対応する最大のメリットは、RubyやRailsの最新版に追随することで、Redmineの寿命を長持ちできること。
RedmineはSIにおける事実上の基幹業務システムなので、機能面だけでなく、セキュリティや性能面でも安定運用したい。
幸いなことに、RubyやRailsはVerUpするごとに安定しており、しかも性能アップになっているので、その恩恵をRedmineも受けられる。

個人的に注目する点は、最近流行のシングルページアプリケーションに対応できる点だろう。
最新のWebアプリケーションに慣れた人からは、RedmineのUIは古臭い、とよく言われるが、Rails5に対応することでUIは改善されていくだろうと思う。

但し、RedmineがRails5に対応することで、既存のRedmineプラグインはそのままでは事実上動作しなくなるリスクがある。
日本人のプラグイン開発者は多いので、Ver4にも早めに対応して欲しいなと思う。

akipiiさんのツイート: "ついに来たか!RT @g_maeda: RedmineのtrunkがRails 4.2.8 から 5.1.2 へ移行。 https://t.co/ly5mTOwwde https://t.co/BwoRWZbw4k"

neta@世界は私のオイスターさんのツイート: "@g_maeda @akipii プラグイン大量死の歴史がまた 1ページ ですか?"

【3】@ktohさんは全文検索プラグインのお話、@akahane92さんは全文検索プラグインの性能評価やRedmineのチューニングのお話。
前回の東京Redmine勉強会でも須藤さんに講演して頂いているが、今回は、そのお話に加えて、全文検索プラグインの可能性やそのアーキテクチャの説明もお願いしている。

第12回東京Redmine勉強会の感想 #redmineT: プログラマの思索

個人的には、全文検索プラグインはRedmineをナレッジシステムにできる可能性を示唆している、優れたプラグインだと思う。

Redmineの添付ファイルを全文検索するパッチの可能性~Redmineをナレッジシステムにするための要件とは何か?: プログラマの思索

Redmineの検索機能の改善はチケット管理システムにとって重要な要件だ: プログラマの思索

【3-1】Redmineの運用が数年も経てば、チケット枚数は軽く10万枚を超えるだろう。
50万枚~100万枚ぐらいまでチケットが蓄積されているRedmineもあるのではないか。
すると、デフォルトの全PJ横串の全文検索では応答速度が遅くなるのは知られていた。
(ただし、Ver3.0以後、全文検索は、表示されたPJだけに限定されるようにデフォルト設定されているので、性能悪化は感じない)

Redmineでは、チケットと構成管理ツール配下の成果物に対しトレーサビリティは保証するように運用できるし、Wikiやチケットに各PJの作業履歴、知見は全て蓄積されている。
しかし、Redmineにいくら、障害や課題、仕様変更のチケット、技術情報のWikiを蓄積したとしても、即座に検索できなければ、欲しい情報が取り出せない。
Redmineという一つの箱にデータが集約されているのだから、Redmineのデータを好きな時に好きなだけ検索して、過去の有用な知見を引き出したいのだ。

全文検索プラグインによって、200万チケットでもレスポンスに問題なし、という結果は、今回、@akahane92さんが回答してくれるはず。
つまり、Redmineに全文検索プラグインによる機能追加で、検索の性能要件は問題なくなる。

また、全文検索プラグインでは、Google検索のように、有用なランク別にソートしてくれるので、検索結果にノイズがない。
おそらく、他の検索プラグインよりもかなり使い勝手が良いだろう。

【3-2】さらに、全文検索プラグインで興味を引くのは、入力補完や類似Issue表示、類義語管理などの、Redmineの操作性を向上させる機能を秘めている点だ。

第12回東京Redmine勉強会の感想 #redmineT: プログラマの思索

Redmineのチケット入力は面倒、という声はよく聞くが、チケット入力時に、Google検索やGoogle日本語入力みたいに、ある程度の文字列を入力したら、コードアシストみたいに文字列を補完してくれてもいいはずだ。
しかも、個別のRedmineに蓄積されたチケットデータを元に、個別のRedmineに応じて入力補完してくれたら、プログラマだけでなく、普通の事務担当者やサポートデスクのオペレータにも優しいシステムになるだろう。

つまり、入力補完によって、チケット内容の単語や表記の揺れが少なくなりデータの精度が上がるし、入力する人にとっても、最初にいくつかの文字を入力するだけで、Redmineが勝手にサポートしてくれると便利なはず。
すなわち、Redmineをナレッジシステムにしていく、という動機づけにもなるはず。

【3-3】そして、最終的には、Redmineがナレッジシステムとして運用できるようになれば、製造業におけるISO9001やISMSなどのシステム監査やサービス監査にも適用できるだろうと思う。
おそらく、日本の企業が最終的に目指したい点はそこにあるだろうと推測するから。

すなわち、Redmineのチケット入力さえ徹底できれば、各PJでは、標準プロセスに基いた成果物は構成管理ツールの配下にあり、プロセスの作業履歴はRedmineに一元化されて蓄積されていて、そのトレーサビリティもRedmineの運用ルールで保証できる。
そうすれば、Redmineに蓄積されたデータ(作業履歴、成果物)に対し、検索するだけで、ランク別に検索結果が表示されているので、監査に必要かつ、有用な情報をいつでも即座に取り出せるようになるはず。

【3-4】さらに、Redmineをナレッジシステムにした場合、プロセスに基づいた作業構造や、プロセスに必要な成果物の一覧を出力したくなる。
プロセスに基いて作られたチケットに対し作業漏れがないか、プロセスに必要な成果物(設計書だけでなくソースも含めて)は漏れていないか、をチェックするために、ツリー構造の一覧を出力して、プロセスの網羅性や完全性を保証したいのだ。

そうすれば、PL法(製造物責任法)に対して、事故が起きたとしても、メーカーはプロセスに基づいて必要十分な作業を行ったので、そこまでのリスクは取る必要はないから、メーカーは無過失責任から免れる、と主張することができるはず。

製造物責任法(PL法)入門

実装方法としては、チケットがWBSと一致しているならば、チケットからPERT図を出力できるし、PERT図にある最下層のWBSは必ず、どれかの成果物に紐づくはず。
Lychee Association Chartがそのイメージに近いが、品質保証部によるシステム監査などの作業に耐えれるレベルまでの機能かどうかは不明。

プロセスフロー図をRedmineチケットで表現するアイデア~Lychee Association Chartで実現できるか: プログラマの思索

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

Redmine Lychee Enterpriseシリーズの解剖part3~Redmineのチケット関連図 Lychee Association ChartとRedmineの予実管理をサポートする Lychee Actual Date: プログラマの思索

つまり、Redmineをプロセス保証のツールにまで進化させたい。
現時点では、これらはまだ構想段階に過ぎないが、Redmineの可能性を更に広げてくれるはずと思う。

【4】LTでは、大阪以外の人達の講演があるので楽しみ。

akipiiさんのツイート: "まだ空きがあります。@ktou さん、@g_maeda さん、@akahane92 さんとRedmineの濃い話ができます。@8amjp さんとRedmineファンタジー小説の話もできます。Redmine大阪 第17回勉強会の懇親会 https://t.co/LO1oeglZx4"

| | コメント (0)

2017/07/19

情報システム部門の問合せ管理をRedmineで行う事例のリンク

情報システム部門の問合せ管理をRedmineで行う事例のリンクをメモ。

【参考】
情シスへの申請・問い合わせ管理を Redmine で効率化する | KDL 情's Cafe BLOG

neta@世界は私のオイスターさんのツイート: "イイっすね! ウチも『情シスへの依頼・問合せ』という Redmine の全社公開プロジェクトがありますが、残念ながらそこに入れてくれるのは1割程度、残りはメールか電話。 現状はこちらで起票して、チケットで返事を返してる。 早くここまでたどり着きたい。 https://t.co/RgEGCmbfpw"

【1】社内の情シス部には、社内のユーザから数多くの問合せを毎日受け取る。
単純な質問から、クレームのメール、怒りの電話まで、日々多数発生しているだろう。
情シスは、コールセンターでないのに、その業務に忙殺される時も多いのではないか。

上記の記事では、情シスの問合せで色々試行錯誤していたらしい。
やはりどこにでもある問題。

(引用開始)
情シスはもともと兼任で運用していたため、情シス宛てのメーリングリスト宛てに定型フォーマットで申請する簡易的な運用をしていましたが、下記の問題がありました。

・申請タイプが増える度に定型フォーマットを用意しないといけない(そして守られない)
 ⇒申請者、対応者双方に負担。
・誰が担当者になっているのか分かりにくい
・申請のステータス状態が分かりにくい
・メールだと情シス担当者や組織変更に伴い過去の履歴や共有が困難
・申請数や対応数など、運営業務としてのデータ分析と改善サイクルが回しにくい

そしてこれらの問題を解決するためにシステムやサービス利用も検討しましたが、スモールスタートで始めるには機能過多でした。
(引用終了)

【2】そこで、Redmineを導入してみたらしい。

(引用開始)
情シスといえば、ユーザーからの申請や問い合わせなどのユーザーサポートが多いですよね。
完全に無くなるものではないので、いかにして効率化するかというのが重要になりますが、弊社情シスでは Redmine をうまく利用すると良い感じで運用できていますので、カスタマイズ方法をまとめておこうと思います。
(2014年~のため、3年以上運用しています)
(引用終了)

(引用開始)
メール運用時代の問題はすべて解消され、運営業務としての効率は格段に向上しました。
(引用終了)

興味を惹くのは、ワークフローとカテゴリ。
ワークフローは、新規→対応中→対応済み→フィードバック→完了 のようにシンプル。
チケットを申請者と情シスの間で、キャッチボールするように扱うのがコツ。

(引用開始)
申請・問い合わせ = Redmine チケット として対応を管理しますが、申請者と情シス担当者間でチケットステータスに関する認識を合わせておくことで、「今どういう状態だったっけ?」となった時にすぐ把握できるようにしています。
(引用終了)

つまり、ステータスにアサインされた担当者がボールを持っていることになるので、ボールをできるだけ離すように回すようにすれば、自然にチケットはCloseされていくはず。

また、カテゴリを上手く利用している。
カテゴリを設定することで、申請後のチケット集計がやりやすくなるし、集計結果を元に是正対策も取りやすくなるだろう。
問合せ内容の件数を期間別に集計するだけでも、十分に見える化できるから。

(引用開始)
情シス管理対象のリソースへの申請・問い合わせを、カテゴリ、種別で整理しています。

カテゴリ例:
・PC
・メール
・ライセンス
・ファイルサーバ
・ネットワーク

種別例:
・PC アサイン申請
・PC 故障申請

定型申請は「種別」として切り出し、非定型は問い合わせしてもらい、問い合わせ内容から同じようなものが増えた場合は定型申請として専用リンクを用意する運用です。
また、「種別」は Redmine のトラッカーで分離しており、月次レポート等でどの申請・問い合わせが多いのかの分析にも利用しています。
(引用終了)

【3】他に興味深い点は、幾つかのプラグインを利用していること。

Wiki Extensions en - r-labs

About en - Issue Template - r-labs

martin-denizet/redmine_custom_css: Redmine plugin to easily input CSS to customize Redmine appearance.

Wiki Extensionsで、「FAQ や 各種手順、ポリシー など、良く参照されるものを Wiki にまとめ、グローバルメニューに表示させる」。
つまり、グローバルWikiを情シスのポータルサイトみたいに扱うわけだ。

Issue Templateで、「特定の トラッカー に紐付くチケットタイトルと本文にテンプレートを適用」する。
つまり、申請の種別ごとに説明テンプレートを作っておき、申請者が記入しやすくなるようにしておくわけだ。

Redmine Custom CSS pluginは知らなかったけれど、CSSをカスタマイズできるプラグイン。
DBマイグレーションが不要なのは良い。
「申請・問い合わせ画面としてより使い勝手を向上させるため、微修正に使っています」。

確かに、問い合わせ画面の色やレイアウトをカスタマイズした方が、ユーザにとっては使いやすくなるだろう。
個人的には、ViewCustomizeプラグインでも、ほぼ同じカスタマイズ内容を実現できるだろうと思う。

【4】最終的には、メール運用→Redmine→kintone へ移行したいらしい。

(引用開始)
当時はベストな方法でしたが、運用している中で色々と問題はあるため、今後は kintone に置き換えられたらいいなと画策しています。
管理表を Excel から kintone に移行したため、そもそも kintone で同様の運用が実現できればよりシームレスになる!
このあたりは、情シスが Excel 管理表を脱却して kintone へ移行した話としてまとめようと思っています。
(引用終了)

確かに、kintoneみたいな「超高速開発ツール」の方が、もっと自由にカスタマイズできる。
但し、kintoneは有償製品であり、外部APIで実現できない場合は部品作りも必要なので注意。

個人的には、Redmineはサポートデスクに向いているのだから、サポートデスクの運用に必要な機能はプラグインで実現すれば、基本的には十分に運用が回るだろうと思っている。
なぜなら、サポートデスクの業務は、さほど難しい内容ではないし、むしろ、その問合せの内容を随時記録していくことが重要な業務の一つだからだ。

この辺りの運用ノウハウもまとめてみたい。

| | コメント (0)

2017/07/16

Redmineのガントチャート改善パッチに注目している

最近、Redmineのガントチャート改善パッチに注目している。
以下、ラフなメモ書き。

【1】Redmineの導入メリットの一つは、ガントチャート機能が標準で付属している点だろう。
開始日・期日のチケット入力さえ徹底できれば、ガントチャートは即座に表示できる。

日本ではSIであれ、製造業であれ、ガントチャートによる進捗管理が普通なので、ガントチャート機能は必須の要件。
Redmineユーザの観点では、頭の固いマネージャに対しては、きれいなガントチャートを見せておき、実際の開発現場では、チケット管理でアジャイルに作業していけばいい、と思っている。

ガントチャートは所詮、マネージャ向けのビューの一つに過ぎない。
本来は、チケット管理の運用が重要なのであり、そこが上手く回れば、進捗管理のビューはガントチャート以外にもいくらでもあるのだから。

しかし、Redmineのガントチャートは、まだまだ改善の余地がたくさんある。
たとえば、FS関係の表示、イナズマ線の表示、ガントチャートの日付の表示など、いくつかの機能改善はされてきたが、MS Projectに比べるとまだ機能不足の面がある。

それらに関しては、過去に色々考えてきた。

RedmineのガントチャートはMS ProjectのWeb版になりうるか?: プログラマの思索

Redmineのガントチャート機能改善の要望チケット: プログラマの思索

Redmineのガントチャート改善part2: プログラマの思索

Redmineのガントチャートに担当者を表示するプラグイン: プログラマの思索

Redmineのガントチャート画面に暦週や日付を表示するプラグイン redmine_gantt_with_date: プログラマの思索

Redmineでガントチャートの幅を広げるパッチ: プログラマの思索

MS Projectを使いこなせない理由: プログラマの思索

【2】最近、Redmine本家にガントチャート改善パッチが出ていて、いくつか注目すべきチケットがある。

【2-1】Feature #20481: Gantt: right and left resizable panel - Redmine

MAEDA, Goさんのツイート: "Redmineのガントチャートでチケットの題名の列をリサイズできるようにするパッチ。ガントが少しずつでも改善されてほしい。 Feature #20481: Gantt: right and left resizable panel https://t.co/XVwlWJhuHG"

akipiiさんのツイート: "親子チケットの階層が深いほど、ガントチャートのパネル幅を変更したい要望が多いのですごく欲しい。RT @g_maeda: Redmineのガントチャートでチケットの題名の列をリサイズできるようにするパッチ。 https://t.co/RiHNjL3BgO"

※画像は、Redmine本家のチケット#20481からリンク。

ガントチャートのチケット欄の幅をリサイズするパッチ。
これはとても欲しい機能だ。

利用シーンとしては、たとえば、親子チケットの階層が5階層のように階層が深くなった場合、チケット欄が狭いとタイトルが隠れてしまうので、そんな時に幅を広げたい。
僕も、Redmineでガントチャートの幅を広げるパッチ: プログラマの思索のように、わざわざ本体のソースにパッチを当てたりしていたので、このパッチが実現されれば、個人パッチが不要になる。

日本の利用企業では、おそらく、WF型開発でRedmineを運用しているだろうから、ガントチャートのチケット欄の幅を広げる機能改善は、ユーザにとってすごく大きなメリットだろう。

そして、リサイズのパッチが実現されれば、次は、チケット欄に担当者を表示する機能改善に注目されることになるだろう。
リサイズできるようになって画面に余白ができるようになれば、担当者を表示したくなるからだ。

Redmineのガントチャートに担当者を表示するプラグイン: プログラマの思索のように、担当者を表示するプラグインなども提供されているが、Redmine本体の機能の一部になればいい。

【2-2】Feature #10485: Add new context menu in Gantt view for each issue - Redmine

akipiiさんのツイート: "これはぜひ欲しい!!RT @g_maeda: Redmineガントチャートの右クリックでコンテキストメニューを表示。 Add new context menu in Gantt view for each issue https://t.co/diIt1pmeyw"

※画像は、Redmine本家のチケット#10485からリンク。

ガントチャート画面上で、チケット編集のコンテキストメニューを追加するパッチ。
これも非常に欲しいパッチ。

現在のRedmineのガントチャート画面は、単純な表示機能だけであり、編集することができない。
編集するには、別画面でチケット編集画面を表示する必要があり、操作が面倒。

ガントチャートにチケット編集のコンテキストメニューがあれば、チケット一覧画面の編集コンテキストメニューのように直感的に操作できる。

パッチの中身を見ると、RedmineにはコンテキストメニューのAPIが既に用意されているので、それをガントチャート画面のオブジェクトで呼び出しているだけ。
つまり、パッチの中身は難しくないので、おそらくバグもないだろうと思うので、本家に取り込んで欲しい。

但し、このパッチで、ガントチャート編集が全て解決できるわけではない。
最終的には、下記チケットのような大幅な機能改善が必要だろうと思う。

Feature #2024: gantt chart editing - Redmine

上記チケットを見ると、2008年から2012年にかけて、数多くの日本人がパッチを提供していた。
日本の開発現場では、とても欲しい機能なのだろう。

【3】個人的には、Redmineのガントチャートは、最終的にはMS Projectが持つ機能をすべて実現する方向へ進化していくだろうと思う。
他に欲しい機能は下記があるだろう。

・ガントバーをD&Dで、期間を移動
・ガントバーをD&Dで操作して、期間を短くしたり、長くしたりする
・ガントバーの進捗率をD&Dで操作して、進捗率を設定
・先行後続の関連をD&Dで引く
・チケット欄で、チケットをD&Dして、階層間を自由に移動する
・チケット欄で、チケットを自由にソート
・予定と実績の明確な区別と表示
・クリティカルパスの表示

つまり、MS Projectにあるガントチャート機能は全てWeb画面上で操作したいのだ。
そうすれば、MS Projectのような高額なパッケージ製品を購入しなくても、OSSのRedmineで十分に運用できるようになるはず。

今後のRedmine本体の改善に注目している。

【追記1】
やっさんさんのツイート: "ガントの改善もすごく嬉しいのだけど、UIとしてカンバンも標準で欲しいなぁ…。そうするとweb系の人も使うようになって本家へのフィード・バックも増え、更に開発が加速しそう。 / “Redmineのガントチャート改善パッチに注目して…” https://t.co/yZZFxG8gj1"

【追記2】
akipiiさんのツイート: "ガントチャートに担当者は表示できないか、と言う問合せが多いです。日本人はガントチャート大好きですよねー。RT @g_maeda: ガントに担当者を表示するパッチができました。 https://t.co/BSIg61Ofba https://t.co/b7NKcNLwxJ"

Feature #26409: Show assignee on gantt - Redmine

※画像は、Redmine本家のチケット#26409からリンク。

【追記3】
改善パッチを作成した開発者のコメントが書かれている。

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

| | コメント (0)

第1回astah関西勉強会の感想 #astahkansai

第1回astah関西勉強会が無事に終わりました。

参加者は少なめでしたが、参加者層は、普段のアジャイル系の人達とは違った顔ぶりの人達が多かった。
astahを使っているか挙手を尋ねてみたら、大半の人は使用経験があるみたい。

一部の人達から感想を聞いてみると、マニアック過ぎた、という感想から、スクリプトやOffice連携のようなマニアックな使い方は面白いですね、という感想まで様々。
以下、ラフなメモ書き。

astah関西 第1回勉強会 - connpass

【告知】astah関西 第1回勉強会を7/14金に開催します #astahkansai: プログラマの思索

akipiiさんのツイート: "#Astahkansai 第1回目勉強会に参加者23人で狭い部屋が超満員です笑。関西でこんなにastahに興味を持つ人がいたんですね"

Masatoshi 0w0さんのツイート: "コードからモデル、モデルからコードはもちろん、モデルからXML出力やモデルデータ出力からのoffice連携。スクリプトやAPIすごいな。 #astahkansai"

Masatoshi 0w0さんのツイート: "限定的な使い方しかできてなかったことを再認識できました。もっとastah活用しよう。 #astahkansai"

Yoichi Nakayamaさんのツイート: "スクリプトプラグインで色々できそう。今度遊んでみよう #astahkansai"

Yoichi Nakayamaさんのツイート: "細合さんの濃い話面白かった。 #astahkansai"

勉強会の内容は、私から、ユーザの立場からのastahを使った感想やastahを使ったモデル(プロセス、システム設計、ビジネスモデル)の事例紹介。
細合さんから、astahの製品シリーズの紹介、astahプラグインの作り方、スクリプトプラグインを入れてEcmaScriptやGroovyやJRubyでスクリプトを書いてastahにメニューを追加したり、astahのモデルを操作する例、また、Office連携プラグインを入れてastahモデルとWordのクラス図を同期させる例などの紹介。

今回の勉強会では、チェンジビジョン社長の熊谷さんも参加されていて、astah製品の利用事例やastahの使い方のコメントを時々発言されて、とても興味深かった。

たとえば、astahGSNを使って、組込みシステムの開発プロセスだけでなく、業務システムの業務プロセスを設計してモデル化する時、リスク内容をモデルの中に埋め込みたい場合がある。
その場合、モデルに、リスク用のタグやステレオタイプを埋め込んでおき、スクリプトプラグインやastahプラグインを使って、モデルからリスク一覧を抽出して、リスク対策へつなげることもできる、という話もあった。

つまり、単にモデルをツールで描くだけでなく、astahのAPIによってモデルから必要な情報を抽出して別の用途に役立てる利用事例もある。
この手法のメリットは、モデルを再利用できること、さらに、モデルを色んな観点のビューで提供できることだ。
すなわち、個別のユースケースに応じて、モデルを再利用できるわけだ。

この観点は、熊谷さんの言葉「astahでモデルをしゃぶり尽くす」につながると思う。

僕としては、この勉強会を上流工程からのモデリング技法の探求、という観点だけでなく、プログラマの観点で、作ったモデルから、ビューを提供したり、ソフトウェアメトリクスを抽出したり、プログラムでモデルを再利用する議論もしたい、と思っていた。
単なるお絵かきの話だけで終わらせたくなかった。
だから、こういう濃い話ができて面白いな、と思っている。

astahのメリットは、直感的な操作がやりやすく、モデルを描きやすい、というのが最大のメリットだが、もっとプログラマの観点を入れてみたいのだ。

「プログラマの立場からのモデル再利用、モデリング技法の探求の勉強会」みたいな場にできたらいいな、と思っている。

| | コメント (0)

«Redmineの添付ファイルを全文検索するパッチの可能性~Redmineをナレッジシステムにするための要件とは何か?