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

2017年8月

2017/08/27

第17回Redmine大阪の感想 #redmineosaka

昨日開催された第17回Redmine大阪の感想をラフなメモ。
疲れているので書きかけ。

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

Redmine大阪 第17回勉強会「Redmineの全文検索エンジンとRedmine3.4.0の徹底解説!」#redmineosaka - Togetterまとめ

【勉強会メモ】Redmine大阪 第17回勉強会 - radioc@?

Redmine大阪 第17回勉強会 LT発表内容(足羽川永都(エイト)) - カクヨム

Redmine大阪 第17回勉強会 - 全文検索でRedmineをさらに活用! #RedmineOsaka - ククログ(2017-08-27)

「Redmine大阪 第17回勉強会」で弊社代表の前田が新機能を活用した便利な使い方について発表 - ファーエンドテクノロジー株式会社

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

@g_maedaさんの講演を聞いて、Ver3.x以降、Redmineはサポートデスク向け機能がすごく充実しているように思えた。
たとえば、管理画面で「ロールごとのトラッカーの参照更新制御」を使えば、1個のプロジェクトで顧客と社内担当者がチケットを共有している時、お客に見せないトラッカーを指定することで、チケット管理できる。

他に、最終更新者のフィルタを使えば、顧客が最終更新してレスしていないチケットを抽出できる。

つまり、Redmineの最新機能をより深く理解することで、Redmineの新たな機能をサポートデスクの業務にフィットギャップ分析すれば、かなりの範囲をカバーできるだろう。
そうすれば、サポートデスク業務は、Redmineでほとんどカバーできるだろうし、Redmineの痒くて使いやすい機能によって、業務を効率化することができるだろう。

Redmineの最新機能を、どの業務のどのユースケースに使用すべきか、を考えるのは、とても楽しい。
Redmineによる新しい利用方法が、業務をITによりフィットさせてくれるからだ。
その感覚はパズルに似ている。

【2】須藤さん、赤羽根さんの講演を聞いて、Redmineをナレッジシステムにするには全文検索の機能強化が重要であると改めて認識した。

5月の東京Redmine勉強会当時よりも、全文検索プラグインはさらに機能強化されて、性能もより強化されたらしい。
また、現在実装中だが、類似Issueの画面キャプチャの紹介があり、興味がそそられた。
つまり、入力したチケットを開くと、説明欄の下部に、類似した過去のチケットが数件表示されるらしい。

この機能は面白い。
Amazonの関連商品表示、GoogleAdsenceと同じように、あなたのチケットはこのチケットに似てませんか?とRedmineが示唆してくれるわけだ。
たとえば、似たような障害修正、似たような問合せのチケットが表示されるので、チームに加入したばかりの人にとっては、とても参考になるはずだ。

さらに、@sakaba37さんが言われるように、担当者ごとの傾向も表示できれば、プロセス改善に役立てることができるだろう。
たとえば、障害チケットを起票したら、最近、あなたは異常系のバグが多くないですか?気を付けましょう、みたいにRedmineがサジェストする、とか。

akipiiさんのツイート: "#RedmineOsaka RT @sakaba37: 類似チケットが気になった。担当者でもヒットするなら、パグの傾向が分かるかも。 https://t.co/pOGlpByw21"

すなわち、全文検索エンジンによって、Redmineに蓄積された障害・問合せ・仕様変更の履歴をデータマイニングして価値ある情報を抽出して、ユーザにフィードバックできる可能性がある。
さらに、機械学習や人工知能などの最近のライブラリを適用すれば、類似Issue機能をより強化できるだろう。

akipiiさんのツイート: "Redmineに機械学習や人工知能を適用する事で更なる効果を目指す野心的な事例。 RT @ktou: Redmine大阪 第17回勉強会での資料です! - 全文検索でRedmineをさらに活用! - https://t.co/kdERFEYVvY #RedmineOsaka"

但し、1点気になったのは、Redmineのチケット枚数が少なすぎる場合、サジェストできるデータが少ないために、精度が低くなり、類似Issueやスマートナビのような機能のメリットが出てこないのでは?と思った。

しかし、パネルディスカッションで須藤さんの回答を聞くと、他の社内のRedmineインスタンスのデータを活用したり、ネットに溢れているデータを活用できれば、カバーできるのではないか、と。
つまり、デフォルトのメタデータをあらかじめ持たせておけば、それほどずれないサジェストができ、じきにチケットが蓄積されれば、精度が上がる、というようにできないか、と。

この辺りは考えると色々面白そうだ。

また、赤羽根さんの講演によれば、Redmine3.4+全文検索プラグインによって、Redmineの性能上の弱点はほぼなくなる、とのこと。
全文検索プラグインを入れるメリットは、単純に検索が高速化されるだけでなく、検索結果がスコア表示されて有用な情報が上位に出てくるので、より使いやすくなる、とのこと。

個人的には、Redmineプラグインは日本人が開発したものに限定する方針がいいと思っているので、クリアコードさんの全文検索プラグインもRedmineのVerUpに追随してくれるはずだから、入れてみてもいいと思った。

【追記1】
@akiko_pusuさんの言う通り、「検索が賢ければ、記録した後は安心して忘れることが出来る」のは心理的なメリット。

あきこさんのツイート: "プラグインの組み合わせ確認で初めて試してみました。groonga入れる&エンジン確認するのにちょっと手間取ってしまいましたが、検索が賢くなるのはとても良い!私は忘れっぽいし休んだりが多かったので、検索が賢ければ記録した後は安心して忘れることが出来る。本当に良い気がします。 https://t.co/n2xYyWjMRy"

【追記2】
Redmineが度重なる機能追加で重くなる中で、最新版のRubyやRailsが地味にRedmineの性能改善に貢献している、という重要な指摘があった。

Redmine大阪第17回勉強会に参加した - Basic

(引用開始)
「Redmineチューニングの実際と限界 ~ 200万チケットでもサクサクなRedmineの作り方~ 改訂3版」 (赤羽根州晴さん)

Redmineの管理を専門に担当されていた方の講演。
RubyやRedmineのバージョンの違いによるパフォーマンス測定の結果も紹介されており、「機能が増え続けるRedmineの処理の重さを、RubyやRailsの足回りが地道に改善してカバーしている」状況がよく理解できた。
(引用終了)

【3】他の資料は下記。

| | コメント (0)

2017/08/23

RedmineでExcelの概要スケジュールを表示する方法

RedmineでExcelの概要スケジュールを表示する方法が公開されていたのでメモ。
これは面白い。

【元ネタ】
RedmineにExcelBookを表示する(ViewCustomizePlugin) - Qiita

(引用開始)
やろうと思った経緯
良くあるのですが、Redmineでチケット駆動開発をしている中で、上司は、中日程をエクセルで管理して共有しています。

エクセル資料をサーバーに置いて、メールでも添付して資料を見てください。

・・・という事をやっているのですが、
部下はサーバーの資料をあまり見に行ってくれません。

メールに添付した資料も、他のメールに埋もれてしまって、見ようと思いません。

上司も、部下がほとんど見ない資料をメンテする事になるので、そのうちサーバー資料のメンテを放置してしまいます。

結果
Redmineに、サーバーのエクセル資料を表示する様にしました。
チケット画面やガントチャート画面の下にエクセルブックを表示しています。
ViewCustomizePluginの機能で実装しています。

いつも見ているチケット画面に表示されるので、ちょいちょい目に入り、中日程が気になったら、すぐに見られる様になりました。
上司も今までと同様に、サーバー上のエクセルファイルを修正するだけで良いので、情報共有が楽になった様です。
(引用終了)

普通、マネージャは、パワポやExcelで大まかな概要スケジュールを作っている。
その概要スケジュールを共有ファイルサーバーに置いて、皆見てくれ、と言うが、普通は見ない。
そのうち、ファイルパスすら忘れて、概要スケジュールの存在すら忘れてしまう。

なぜなら、マネージャはRedmineを使わず、Excelで仕事をしているが、プログラマはRedmineやGitで仕事しているので、利用場面が違うからだ。
むしろ、Redmineにすべての情報を共有するようにした方がいい。

実際は、概要スケジュールに書かれているマイルストーンの方が重要だ。
たとえば、結合テスト開始日、総合テスト開始日、本番リリース日などをプログラマと共有することで、チケット管理でも配慮してくれるようになるだろう。
しかし、その情報は、Excelやパワポに埋もれている場合が多い。

上記の例では、概要スケジュールのExcelをマクロでExcelbook(HTML)へ変換して、Redmineサーバーにアップして、ViewCustomizeプラグインでチケット一覧やガントチャート画面の下部に表示するようにしている。
この手順を自動化できるならば、マネージャがイメージしている概要スケジュールをプログラマも見てくれる。
マイルストーンを共有できれば、チケットのリズムも生まれやすい。

しかし、残念なことに、運用は上手く回っていないらしい。

(引用開始)
設置したExcelマクロを自動実行させて、
サーバーにあるExcel資料(日程.xlsx)を、html形式で保存する作業を自動処理させます。
これをするには、Excelマクロを起動するPCにExcelがインストールされている必要があります。
結局、これは自分の個人PCから実行する様にしました。

(中略)
・上司は資料をsubversionで管理してくれない。(コミットトリガ設定できない)
などなど。。。

残念。何か良い方法ございましたら、どなたか教えて下さい。。。
(引用終了)

結局、ボトルネックは、マネージャがExcelをきちんと管理してくれないのが原因みたい。
個人的には、マネージャに、FTPアップロード用フォルダに定期的にExcelを配置してもらう運用にするのがいいかな、と思う。
マネージャも技術者でしょ、と。

こういう地味で、泥臭い運用ルールは役立つので集めてみたい。

| | コメント (0)

2017/08/20

セマンティック・バージョニング、チームの依存関係のメモ

セマンティック バージョニングのルールについて、改めてメモ。
主張のないラフなメモ書き。

【参考】
セマンティック バージョニング 2.0.0 | Semantic Versioning

「セマンティック バージョニング」を読んだのでバージョニングについてまとめた - Qiita

t32k、怒られる!セマンティック バージョニングしてますか? | HTML5Experts.jp

Ruby 2.1.0 以降のセマンティックバージョニングについて

【1】(引用開始)
バージョンナンバーは、メジャー.マイナー.パッチとし、バージョンを上げるには、

APIの変更に互換性のない場合はメジャーバージョンを、
後方互換性があり機能性を追加した場合はマイナーバージョンを、
後方互換性を伴うバグ修正をした場合はパッチバージョンを上げます。

プレリリースやビルドナンバーなどのラベルに関しては、メジャー.マイナー.パッチの形式を拡張する形で利用することができます。
(引用終了)

(引用開始)
例えばVersion 3.2.1の場合、メジャーバージョンは3、マイナーバージョンは2、パッチバージョンは1ということになります
(引用終了)

【2】ソフトウェアはハード製品とは違って、バージョンの依存性関係の管理がすごく重要だ。
特に、OSやミドルウェア、ライブラリのバージョンが違うだけですぐに動かなくなる。
また、バージョンアップの頻度も多いのが普通なので、ライブラリのバージョンアップを追随するのにも結構労力がかかる。

一方、バージョンアップしないライブラリは、進化していないので危険。
たとえば、最新のセキュリティパッチが考慮されていない場合もあると、すごく危険。

僕は、どの開発プロジェクトであっても、そこの構成管理の運用ルールをまずは見る。
ソース管理やビルド管理だけでなく、設計書の版管理はどのようにタグ付けされて、リリースバージョンとしてリリースされるのか?

構成管理はソフトウェア開発プロセスの基本であるが、意外に運用がまちまちだったりする。
今でも、リリース管理台帳というExcelで、リリースモジュールとバージョン番号を記録して、初めてリリースできる運用を行なっている所も多いのではないか。

すると、Excelのリリース管理台帳がロックされて書き込めない、リリース管理台帳が最新化されていない、リリース管理台帳そのものの履歴管理ができてないのでデグレした、とか、諸々の問題点が色々出てくる。

【3】また、バージョンのネーミングルールも重要だ。
メジャーバージョンとマイナーバージョンの違いを認識せずに、何となくナンバリングしていないか?

t32k、怒られる!セマンティック バージョニングしてますか? | HTML5Experts.jpでも「『いっぱい変更したのでメジャーバージョン上げてみるか』、『今回の修正は軽微なものだし、マイナーバージョンを上げるか』」とバージョニングしていたら、ロシアのサンクトペテルブルク在住の青年エンジニアに怒られた、という内容があった。

(引用開始)
彼の言い分は、「APIを変更したので、この場合はSemantic Versioningのルールに従ってメジャーバージョンを上げるべきであり、そうすることでユーザーも予測・対応しやすい」とのことです。
(引用終了)

すごく参考になる。
セマンティック バージョニングによるバージョン番号によって、ユーザに影響箇所を認識させることができるメリットがあること。
数多くのOSSも、そういうバージョン番号になっている。

だが、単一のアプリではなく、数多くの共有ライブラリに依存した大規模システムになると、依存関係の管理が難しくなる。
一つの共通ライブラリのバージョンアップで、回帰テストの工数が増えるリスクもある。
Javaでは、Maven、Ivy、さらにはGradleを使っていたが、今はどうなのかな?

【4】依存関係については、ライブラリだけでなく、チーム間の依存関係の例もある。
100人月以上の大規模システムになると、複数のチームが連携するのが普通だが、他チームのライブラリや成果物に依存するために、開発が滞る時がある。
あるいは、インフラ基盤に依存する場合、アジャイルチームとWF型開発チームが混在している場合、などの例もあるだろう。

下記の記事がすごく分かりやすい。

スクラムで依存関係を取り扱う方法 | Ryuzee.com

【5】この記事を読みながら、「ドメイン駆動設計」のパターンを幾つか連想した。
普通は、依存しあう二つのチームには、権力や影響力の優劣が存在する。
では、力の優劣のあるチームの依存関係では、どんなパターンがあるのか?

「顧客・供給者の開発チーム」パターンなら、上流のチームに対し、下流のチームが顧客として振る舞う。
これが理想。
本来は、上流のチームが「公開ホストサービス」「公開された言語」パターンで、下流のチームが使えるようなAPIを準備して公開すべき。
昨今のマイクロサービスの流行は、この方向性だろう。

「順応者」パターンなら、下流のチームは上流のチームに従順に従うしか無い。
下流のチームにとっては最悪のパターンなので「腐敗防止層」パターンでガードしたり、「別々の道」パターンを採用する。
たとえば、レガシーシステムの開発チームが強い場合は、こうならざるを得ない場合が多いだろう。

セマンティックバージョン、ライブラリの依存関係、チームの依存関係については、既に数多くの知見やベストプラクティスがあるので、それをまとめると面白いかなと思う。

| | コメント (0)

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年7月 | トップページ | 2017年9月 »