2017/09/15

Redmineをポータル基盤にするアイデア

Redmineをポータル基盤にするアイデアについてラフなメモ書き。
不足部分は後で書き足す。

【1】そもそも、Redmineにポータルの機能を持たせたくなる理由や背景は何か?
今までの経験上、下記の要望があった。

ユーザ側としては、グローバルWikiが欲しい。 自分が所属しているPJメニューの一覧だけが欲しい。
自分の担当チケットの詳細を見るために、マイページをもっとカスタマイズしたい。

つまり、ユーザ側としては、自分がプログラマの場合、社内ではほとんどRedmineばかり使っている。
出社したら、まずRedmineの画面を開くから。

ゆえに、Redmineにログインした後、自分が担当中のチケット一覧がぱっと分かったり、担当中のチケットのステータス数を表示してどれが最優先なのか、表示して欲しい。

すなわち、ポータル画面のようにRedmineで、担当チケットの一覧や、担当チケットのステータス状況を把握したいのだ。

一方、マネージャやPMO側としては、PJメニューが欲しい。進行中のPJ一覧が見たいから。
全員に告知するバナーが欲しい。

つまり、マネージャやPMOとしては、事業部で進行中のPJ全てがどれくらいあって、各PJの進捗がどういう状況なのか、をぱっと見たい。
現在のRedmineでは、プロジェクト画面には多数のPJの概要とリンクが表示されるだけで、PJ数が数百もあると分かりにくい。
また、各PJの進捗を1個の画面で把握したいのに、今のプロジェクト画面は使いにくい。
さらに、事業部の中で、各PJの本番リリース日や重要なマイルストーンを全員に告知したい。

すなわち、ポータル画面のように、事業部で進行中のPJの一覧、それらPJの進捗状況を把握したい。
また、Redmineに、全員に告知する機能も欲しい。

そんな要望を聞いてみると、たぶん、Redmineにポータルのようなシステム機能が欲しくなるのだろうと思う。
普通のポータルの基本機能は、ログインユーザが使える利用システムのリンク、全社・事業部向けの記事の公開・告知、チャットや掲示板などの機能等がある。

その中でも、ログインユーザが所属しているPJ情報、ログインユーザが担当しているチケット情報、事業部内向けの記事の公開・告知、などの機能がRedmineにも欲しいのだろう。

【2】一般に、ポータル製品はCMSの一部としてたくさんあり、エンタープライズ向けのOSSツールとしては、Liferayが有名。
Liferayなら、BitnamiでインストーラやVMが提供されているので、簡単に検証できるのも良い。

オープンソースのポータル/CMS/Liferayとは

オープンソースで構築する企業ポータル「Liferay」を知る--日本法人を新設、本格普及狙う - CNET Japan

Liferay Cloud Hosting, Liferay Installer, Docker Container and VM

【3】Redmineにポータル機能を持たせた場合、現状の機能とあるべき機能のFitGap分析を考えてみる。

Redmineに足りないポータル機能は、下記3つをもっと機能拡張すればいいだろうと思う。

・PJ一覧画面
・マイページ
・Wiki

確かに、現在の最新バージョン3.4でも、PJ一覧画面やマイページ画面は使いにくい。
これら機能は、UIも含めてもっと改善できるはず。

【3-1】PJ一覧画面に進捗バーを出すプラグインはある。
しかし、PJ一覧画面で、所属PJだけ絞り込むとかできないし、数百のPJが表示されると見づらい。

stgeneral/redmine-progressive-projects-list: Redmine plugin provides projects list with progress bars for every project and version

【3-2】マイページ画面は、@g_maedaさんが以前から気にされていて、色々改善されようとしている。

Redmineのマイページをより便利にする My Page Blocksプラグイン | Redmine.JP Blog

Feature #1565: カスタムクエリを表示する新たなマイページパーツ「チケット」 Redmine 3.4 新機能紹介 (3/5) | Redmine.JP Blog

また、古いプラグインだが、マイページにカレンダーなどのパーツを表示できるようにするなどの機能がある。

Redmine 自体に手を入れずにマイページのブロックを追加する方法 - すえひろがりっっっっ!

しかし、個人的には、マイページ画面はまだ使いにくい。
担当チケットの状況以外にも、Redmineの各機能に対し、ログインユーザの情報を表示したり、自由に配置できるようにして欲しいのだ。

他にも、プロフィール画面と個人設定画面は機能が似ていて混乱しやすい、という指摘もある。
この辺りの設計ポリシーも見直しが必要かもしれない。

MAEDA, Goさんのツイート: "Redmineのプロフィール画面(users/:user_id)と個人設定画面(my/account)は統合されるべき。Redmineを10年近く使っているが、いまだに時々間違える。"

【3-3】ポータルの記事に対応するRedmineの機能は、Wikiになるだろう。
しかし、WikiのUIはIT初心者が使いやすいとは言えない。

Wisywigエディタ機能をRedmineのWikiに持たせたら、Wikiをもっと使ってくれる人も増えるだろう。
たとえば、WordpressのCKEditorみたいなUIがあるといいだろう。

UIがIT初心者にも優しくなるのは良いことだから。
Redmine本家にも要望チケットがあるし、プラグインもあるみたい。

Feature #617: wiki: thoughts of WYSIWYG - Redmine

redmine_wysiwyg - Plugins - Redmine

CKEditor - Plugins - Redmine

【3-4】RedmineにはCMS pluginなるものがあるらしい。
コメントを読むと、WordPressみたいな操作感らしいが、実際はどうだろうか?

New CMS Plugin: WordPress-like websites in Redmine

【3-5】自分の担当チケットの状況を簡易表示するプラグインとして、@akiko_pusuさんが作成したIssue Badgeプラグインがある。

Issue Badge - Plugins - Redmine

右上のメニューに担当チケット数がリアル表示されるのは便利。

一般のポータルシステムでも、稟議書ワークフローシステムから現在のステータスや枚数を表示する機能があるが、それと同じ。

【3-6】全員に告知する機能としては、@akiko_pusuさんが作成したbannerプラグインがある。

Banner - Plugins - Redmine

Redmine本体のバージョンアップ案内、各PJの重要なマイルストーン案内を全員に告知したい時に役立つ。
一般のポータルシステムにある、全員が参照できる記事の機能と同じ。

【3-7】RedmineにグローバルWikiの機能が欲しい、という要望は以前からあがっていた。
つまり、Redmineにポータルな画面=グローバルWikiをログイン時のトップ画面にしたい、という要望だ。
今はまだ未実装。

Feature #1040: Global wiki - Redmine

Feature #381: general wiki for the whole site - Redmine

他に、startpageプラグインを使えば、トップページを任意のWikiページなどに設定できる。
つまり、トップページ=ポータルな画面にするわけだ。

Redmine Start Page - Plugins - Redmine

Redmine startpageプラグインでトップページを任意のWikiページなどに設定する - torutkの日記

但し、グローバルWikiという機能を別途作るのが良いかどうかは正直分からない。
Redmineでは、Wikiは各PJごとに配置されている設計思想なので、むしろ、startpageプラグインのように、特定PJのWikiをトップページへ遷移するように変更する方が良い気もする。

【3-8】@haru_iidaさんのWiki Extensionsプラグインを使う方法もある。
Wikiをもっと機能拡張してくれる素晴らしいプラグインだ。

Wiki Extensions - Plugins - Redmine

Redmine wikiを使いやすくして情報共有をはかどらせる - Qiita

RedmineのWikiに「ページトップへ戻る」ボタンを追加する - kengo700のナレッジベース

上記のように、「Sidebarにリンク集、アクセス数ランキング、タグクラウドなどを追加してアクセスしやすくする」「Footerでアクセス数を表示する」などができる。
WikiをCMSみたいに、もっとリッチで使い易いUIにしたい場合、Wiki Extensionsプラグインはとても有用。

たとえば、新規加入したPJメンバーがこういうリッチなWikiを見る運用にすれば、説明会も不要だし、アクセス数やアクセスランキングが表示されることで、ちょっとモチベーションも上がる。

【3-9】アバターは、Redmine標準ではGravatorなど外部サービスを使っているので、社内Redmineでは使いにくい。
そこで、下記のアバタープラグインを使えば、ユーザのアバターを画像表示できる。
Redmineで息抜きしたり、楽しくするために必要なプラグインだろう。

ncoders/redmine_local_avatars: Local Avatars for redmine - initially imported from https://bugs.launchpad.net/redminelocalavatars

DBマイグレーションもなく、画像ファイルをアップするだけなので、インストールに問題もない。

【3-10】CMSやポータルシステムならば、ユーザごとにテーマをカスタマイズできるのが普通。
Redmine標準では、テーマはサイト固定だが、@haru_iidaさんの下記プラグインで、個人ごとにテーマを変更できる。
Redmineを楽しくしたり、息抜きできるようにするためにも、必要なプラグインだろう。

Theme Changer - Plugins - Redmine

【3-11】Redmineのサイドバーを隠すプラグインがある。
Redmineの画面を広く使いたい時に有用。
もちろん、View customize pluginでもカスタマイズ可能。

Hide Sidebar - Plugins - Redmine

Redmineでサイドバーを非表示にする(View customize plugin) - Enjoy*Study

RedmineのUIが古臭い、と言われる理由の一つは、画面レイアウトがTopメニュー・サイドメニュー・メインレイアウトのように固定されていて、一昔前のiframeのWebページに似ているからだろう。
だから、Redmine本家でも、サイドバーをユーザが無くせる機能改善のパッチが提供されいてる。

Patch #21808: Make the Sidebar collapsible, stateful - Redmine

世界中の開発者も、Redmineの古臭いレイアウトを変更したい、と思っているのだろう。

【3-12】ポータルシステムでは、SNSやチャットの機能は普通ある。
Redmineにも、slackと連携するプラグインはある。
Redmineの活動ログよりも、Slackの方が使いやすい、という場面は多いだろうから。

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

また、掲示板の機能は標準のフォーラム機能で代用できる。

【3-13】今時のWebシステムなら、レスポンシブデザインに対応しているのは普通だろう。
RedmineもVer3.2で対応された。
このおかげで、スマホでも画面サイズに合ったレイアウトになる。

Redmine 3.2新機能紹介: レスポンシブレイアウトによるスマートフォン対応 | Redmine.JP Blog

なお、RedminePMというRedmineクライアントアプリもある。

iPad / iPhone / Android対応のRedmineクライアントアプリ「RedminePM」 | Redmine.JP Blog

【3-14】ポータルサイトでは、記事の全文検索は必須機能だ。
記事が蓄積されるほど、過去の記事を検索したくなってくる。

また、社内のポータルサイトでは、ファイル共有の機能も普通は付いてくる。
GoogleDriveみたいに、Officeファイルを共有して、事務処理手続きや設計書を共有する。

その時、ファイル共有した全てのファイルに対し、全文検索したい。
なぜなら、過去に作成した資料を参照したり、他人が作った資料を流用したい時が多いから。

だから、ポータルサイトでは、記事の全文検索だけでなく、ファイル共有内のファイルの全文検索も重要な機能の一つになる。

Redmineの場合、記事の全文検索の解決策は、全文検索プラグインを導入することで解決できるだろう。
ポータルの記事がRedmineのWikiに対応するように運用できるならば、Wikiにデータが蓄積されるほど、全文検索プラグインで有用な結果が上位に表示されて便利になる。

さらに、添付ファイルを全文検索できるパッチもRedmine本家に提供されているので、このパッチがRedmine標準の機能になれば、全文検索プラグインの威力が更に増すことになる。
なぜなら、チケットやWikiだけでなく、添付ファイルの中身も全文検索の対象になることで、Redmineにすべてのデータを一元管理するメリットがより大きくなるからだ。
是非、実現して欲しいと思う。

Feature #306: Full Text Search of files - Redmine

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

【4】以上のような機能評価を考えると、ポータルシステムとは多機能なCMSであるがゆえに、Redmineにはそういう機能は正直ない。
Redmineの本質はチケット管理システムであり、CMSではないからだ。

しかし、RedmineにはWikiがあるがゆえに、Wikiを機能拡張することでCMSに近い機能を持たせることはできる。
また、全員に告知できるbannerプラグイン、担当チケット数をリアル表示するIssue Badgeプラグインのような機能は、ポータルシステムでは普通にあるので、Redmineにも標準であると使い勝手は上がるだろう。

そんな事を考えてみると、RedmineのUI改善の方向性は、CMSやポータル基盤が進化した歴史を参考にすると良いような気がする。
実際、それらの機能をRedmineに追加したい要望が多いからだ。

色々考えてみる。

| | コメント (0)

2017/09/11

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

東京Redmine勉強会のLTで、複数のRedmineインスタンスからデータ収集してAgile開発する利用事例があった。
もう一度見ながら、ラフなメモ書き。

【1】RedmineはOSSで無料であり、インストール手順はネット上に公開されているので、誰もがすぐに運用できる。

すると、最初は自分たちのチームだけで使っていたら、各案件、各チームごとに社内でRedmineインスタンスが乱立してしまう。
このような状況は、野良Redmineと呼ばれていた。

あるいは、社内標準で設置されたRedmineは、各案件の特徴にあった運用ルールやプロセスに準じておらず、使いづらいために、こっそり自分たちのRedmineを使い始めた、という話もよく聞く。
このような状況は、闇Redmineと呼ばれていた。

第10回redmine.tokyoの感想~Redmineユーザはメトリクスがお好き #redmineT: プログラマの思索

最近よく聞くRedmineのFAQ~Excel添付のチケットから野良Redmineまで: プログラマの思索

Redmineを運用している規模について - Google グループ

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

Redmineの運用が大規模化していく上での課題~@Will_meaningさんとのやり取り - Togetterまとめ

そのように、多数の複数Redmineインスタンスが乱立している状況では、各チーム・各案件の進捗状況を横串で把握しにくい問題が出てくる。
そこで、複数Redmineインスタンスの進捗状況を横串で把握できる仕組みが必要になってくる。

あるいは、組織の統廃合などで、複数Redmineインスタンスを一つに集約したい要望が出てくる。

【2】このような要望や問題を考えると、その課題はいくつかあげられる。

【2-1】一つは、複数Redmineインスタンスの情報を一括集計する方法は何か。

複数Redmineインスタンスを現状運用しながら、全体進捗を一括集計したい場合、RedmineのREST APIを使う方法があげられるだろう。

上記のLT資料は以下の通り。

(引用開始・多少編集)
【問題意識】
受託開発案件のRedmine利用率、なんと100%
1 プロジェクト、1 Redmineのパターン
それぞれの顧客から自分のRedmineを使いたいね

【やりたいこと】
やりたいことは 複数のRedmineでAgile開発を楽にしたい
● 一目で、それぞれのプロジェクトの進捗状況が知りたい
● Agileスプリントの作成・編集を行いたい
● スプリントごとの進捗を Burndown chart式で見たい
● スプリントごとのタスク進捗をカンバン式で見たい
● Velocityを測りたい
● 見積のないタスクをすぐに特定したい

一目で、それぞれの プロジェクトの進捗状況が 知りたい!!!

【解決方法】
救世主:Redmine API できることは結構ありそう
● プロジェクト、バージョン、タスクなどの操作
● タスクの更新履歴が取れる!
● 複数のRedmineサーバから集計できそう!
(引用終了)

この仕組みを自分たちで作って「Redmine Tracker」と名付けたらしい。
まだ未公開のようだが、OSSで公開してくれるとすごく嬉しい。

Agile開発に特化しているので、WF型開発案件やその他の種類の案件では使いにくいかもしれないが、ニーズはとても多いのではないかと思う。

【3-2】もう一つは、複数Redmineインスタンスを1個のRedmineにサーバー統合する方法はあるか。

複数のRedmineインスタンスをサーバー統合する方法は、一筋縄ではいかない。
利用事例としては、下記の発表資料がある。

QA #247: 複数のRedmineサーバを統合したい - Unofficial Redmine Cooking - redmine.tokyo

乱立してるRedmineを一つにまとめる話 agileware-jp/douhashi-slides

他システム(Notes)からRedmineへの移行(第3回品川Redmine勉強会)

NGK2012BでRedmineとRedmineを統合した話について発表してきた | Dabits

いずれも相当苦労している。
理由は、RedmineのIDはDBシーケンスなのでID変換用の中間テーブルが必要であることや、データ移行用のツールを別途開発する必要があることだろう。

たとえば、アジャイルウェアの堂端さんの事例では、17個のRedmineインスタンスを1個のRedmineに統合して、チケット数9万以上、プロジェクトは1千個以上に膨れ上がったらしいので、恐れ入る。

【4】1個のRedmineに集約するメリットは、チケット入力の運用ルールさえ徹底できれば、1個のRedmineのデータから、社内の全PJの進捗や品質の情報を集計できることだ。

実際、Redmineには複数プロジェクト機能や親子チケット、柔軟なワークフロー設定などがあるので、案件がWF型開発でもアジャイル開発でも実費請求の保守案件であっても、1個のRedmineインスタンス内で、別々のプロジェクト設定やワークフロー設定で区別して管理できる。

つまり、PMOや品質保証部から見れば、多種多様な案件があったとしても、Redmineという一つの箱を見れば、進捗や品質も一元管理できるのは最大の効果だ。
すわなち、Redmineの柔軟性が、多種多様なプロセスを全て飲み込んでくれるわけだ。

チケット駆動でソフトウェア開発のメトリクス分析を行うアイデア: プログラマの思索

第13回RxTStudy勉強会の感想 #RxTStudy: プログラマの思索

【5】一方、複数のRedmineインスタンスでの大規模な利用事例としては、気象庁のRedmine利用事例があげられるだろう。
資料を読むと、インフラ構成も公開されているので、インフラ関係者は必見だろう。

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

また、各Redmineインスタンスで運用ルールが異なっている点も興味深い。
そのような運用の背景には、各部署の権限が強く、組織文化も大きく異なるので、あえて1個のRedmineではなく、複数のRedmineの方が運用しやすい、という判断があったのではないか、と想像する。

【6】複数のRedmineインスタンスで運用している場合、Redmineインスタンスごとに運用ルールが異なるので、第三者の観点で見ると、社内で数多くのチームがバラバラに動いているように見える。
ゆえに、それぞれのチームの文化がRedmineと一体化しているので、1個のRedmineに統合するのはとてもハードルが高いだろうと想像する。

なぜなら、「アーキテクチャは組織に従う」「プロセスは組織に従う」という発想と同様に、「Redmineは組織に従う」「Redmineはプロセスに従う」経験則が見られるからだ。
よって、「標準の唯一のRedmineに全案件のプロセスを従わせる」というやり方は、大企業になるほど難しいかもしれない。

Redmineは戦略に従う。そして、Redmineは組織に従う~システム運用フローの背後にある組織構造の影: プログラマの思索

Redmineに向いている組織はPJ型組織やマトリクス型組織ではないかという仮説: プログラマの思索

【7】一方、各チームがアジャイルに開発したいならば、チームごとにRedmineインスタンスを提供して、自分たちの開発に合わせたプロセスへどんどんカスタマイズした方が良い、という考え方もできる。
つまり、運用されているRedmineはチームの組織文化や慣習を表しているので、あえて全社統一のプロセスに標準化するよりも、変化の激しい状況に対応できるように、チームごとに動けるようにするわけだ。

すなわち、逆コンウェイの法則「アーキテクチャに合うような組織を作る」という発想のように、あえてスクラムチームまたはアジャイルチームのような機動的なチームに細分化し、そのチームの文化やプロセスに合ったRedmineへカスタマイズする戦法もありうるはずだ。

「Redmineに組み込んだプロセスに合うチームを作る」という観点で、あえて野良Redmineを作り出す手法もあるだろう。

Redmineインスタンスはチームの組織文化や慣習を表す: プログラマの思索

逆コンウェイ戦略のメモ~望ましいアーキテクチャを促進するためにチームと組織構造を進化させる: プログラマの思索

【8】日本におけるRedmineの高い普及率の背景を見ると、Redmineと日本企業の組織文化の相性の良さが見えてくる。
おそらく、海外とは違った事情が日本の組織文化にあると、個人的には感じている。

日本で組織にRedmineを従わせる事例が多いのは「Redmineはとても柔軟なので、Agile開発にもWF型開発にも使える」「プラグインなどで機能拡張が簡単なので、組織構造や標準プロセスにRedmineを従わせやすい」理由があるのだろうと思う。

Redmineが日本人好みのツールであるという仮説: プログラマの思索

Redmineが日本人好みのツールであるという仮説 part2~日本の硬い組織構造をRedmineが柔らかくしてくれる: プログラマの思索

Redmineが日本人好みのツールであるという仮説part3~日本のRedmineコミュニティにはプラグイン開発者が多い: プログラマの思索

今後も色々考えてみる。

| | コメント (0)

2017/09/08

Redmineの最新機能でサポートデスク管理をより効率よく使う運用方法のアイデア

前回のRedmine大阪で、前田剛さん、須藤さんの話を聞きながら、Redmineの最新機能でサポートデスクをより効率よく使う運用方法について、考えたことをメモ。
ラフなメモ書き。

【参考】
第17回Redmine大阪の感想 #redmineosaka: プログラマの思索

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

【1】サポートデスクやITILによるソフトウェア保守の運用作業で、従来のExcelでやっていた頃はいろんな問題が噴出していた。
その内容は、4年前の下記のスライドで既に述べた。

「Redmineの運用パターン集~私に聞くな、チケットシステムに聞け」

その問題点は下記に集約されるだろう。

【1-1】突発的な問合せ、障害が発生すると、作業が混乱する
【1-2】問合せから、暫定対応や根本的な是正対応への作業連携が悪い
【1-3】問合せ対応や障害対応のナレッジが蓄積されない

そして、Redmineを導入すると、それら問題のほとんどは解決されることは資料で既に述べた。

そこで、Redmine大阪で前田剛さんや須藤さんの講演を聞きながら、Redmineの最新バージョンに盛り込まれた新機能や全文検索プラグインを使うと、上記の問題から出てきた課題は、かなりいい感じで解決されるように思う。

【2】突発的な問合せ、障害に対する暫定対応・根本的な是正対応への作業連携は、基本はすべてチケット化することでほぼ解決できる。
さらに、Redmineの最新バージョンの機能、いくつかのプラグインがより使いやすくしてくれる。
いくつかあげてみる。

【2-1】テキストエリアのカスタムフィールドのワイド表示を設定すれば、チケット入力画面で、障害原因や対策内容のエリアを広くできるので入力しやすくなる。
オペレータやプログラマも入力してくれるようになるだろう。

Redmine 3.4 新機能紹介 Patch #21705: 「長いテキスト」形式カスタムフィールドの「ワイド表示」オプション| Redmine.JP Blog

【2-2】ヘルプデスクPJでは、デフォルト担当者=オペレータのユーザグループに設定しておけば、問合せチケットを顧客が入力した時に担当者にデフォルト担当者が設定され、オペレータ全員に通知される。
その結果、顧客の問合せを見失った、という状況を減らせるだろう。

Redmine 3.4 新機能紹介 (2/5) Feature #482: プロジェクトごとにデフォルトの担当者を設定 | Redmine.JP Blog

【2-3】個人的には、ヘルプデスク管理や障害管理では、IssueTemplateプラグインは必須と思う。
なぜなら、たくさんのカスタムフィールドに入力させる運用よりも、説明欄一つに数多くの情報を入力する方が、入力者にとっては楽だし、説明欄に大量の情報があれば、全文検索プラグインの対象範囲が広がるので、有用な情報を検索しやすくなるから。

akiko-pusu/redmine_issue_templates: Repository for Redmine Issue Template (Ready to move Repository from Bitbucket to GitHub)

Redmineで高速に全文検索する方法 - ククログ(2016-04-11)

【2-4】チケット一覧に「更新者」「最終更新者」「最新コメント」を検索・表示できるようになった。
この機能を使えば、たとえば、最終更新者が顧客になっているチケットはオペレータが未対応なので即対応すべき、と分かる。
他に、チケット一覧で最新コメントを見れば、どこまで対応したのか、が一目で分かる。
オペレータ向けにクエリを作っておくと良いだろう。

Redmine 3.4 新機能紹介 (2/5) Feature #17720: チケットのフィルタに「更新者」「最終更新者」を追加| Redmine.JP Blog

Redmine 3.4 新機能紹介 (2/5) Feature #6375: チケット一覧に「最終更新者」を表示 | Redmine.JP Blog

Redmine 3.4 新機能紹介 (2/5) Patch #1474: チケット一覧で最新の注記を表示 | Redmine.JP Blog

【2-5】チケットの添付ファイル名称を検索できるので、顧客がこんな感じのファイルを添付したんですけど、みたいな時に役立つ。
やはり、エビデンスがないと対応しにくいから。

Redmine 3.4 新機能紹介 (2/5) Feature #2783: 新たなチケットのフィルタ「ファイル」 | Redmine.JP Blog

【2-6】オペレータやプログラマには、実績工数はチケットに付けて欲しいと管理者サイドでは思う。
チケットに実績工数があれば、集計された数値を元に、いろいろ分析できるから。

最新バージョンでは、チケット一覧の実績工数のリンクを押すと、工数明細が表示されるようになったので、ドリルダウンできるのは嬉しい。
なぜこのチケットはこんなに工数が多いのか、調べる時に役立ちそう。

Redmine 3.4 新機能紹介 (2/5) Patch #24649: チケット一覧の「作業時間」「合計作業時間」をクリックすると作業時間の一覧を表示 | Redmine.JP Blog

【2-7】サポートデスク用PJでは、チケット管理を顧客とオペレータが共有するが、社内タスクや作業連携用チケットは顧客に見せたくない場合がある。
そんな場合、管理画面で、トラッカーに対するロールベースの権限制御を行えば良い。

Redmine 3.3新機能紹介: トラッカーに対するロールベースの権限制御(チケットの閲覧/追加/編集/削除/注記の追加) | Redmine.JP Blog

たとえば、「問合せ」チケットは顧客もオペレータも参照・更新できるが、「社内用タスク」「社内向け課題」のように社内の開発部隊とやり取りするようなチケットは、顧客に見せないように設定できる。

以前は、社内向けタスク等のチケットはサブプロジェクトに登録する運用にするなど、一手間かかるのが面倒だった。
しかし、この機能を使えば、1個のプロジェクトで、顧客が見えるチケットと見えないチケットを細かく設定できるので、オペレータは何も気にせず起票すればいいから、チケット入力が楽になる。
顧客に見えるトラッカーは限定されているからだ。

【2-8】PJ設定画面で「新しいチケット作成時のデフォルトの対象バージョン」を設定できるようになった。
この機能を使って、デフォルト対象バージョンを「バックログ」に設定しておけば、顧客が問合せチケットを起票した時に、バックログに自動設定されるので、オペレータは対象バージョン=バックログのチケットを優先的に対応すればいい。

Redmine 3.2.0 リリース | Redmine.JP Blog

Feature #1828: Default target version for new issues - Redmine

サポートデスク管理でも、対象バージョン=対応すべき納期で運用すれば、どの期日までにどの問い合わせチケットを優先すべきか、ロードマップ画面で判別しやすくなる。
また、対象バージョン=バックログの問い合わせチケットは、問合せの未対応の貯蔵庫と見なせるので、選択しやすくなるだろう。
問い合わせチケットはただでさえ、たくさん発生して、チケット一覧に埋もれてしまいがちだからだ。

【3】さらに、全文検索プラグインを追加すれば、過去の問合せや障害の履歴をランク付けして検索できる。
有用な情報がスコア表示されるので、Redmineに問合せや障害の情報が蓄積されるほど、価値あるシステムになるだろう。
つまり、全文検索プラグインはRedmineをナレッジシステムに進化させてくれる可能性を秘めていると思う。

また、須藤さんの発表資料のように、全文検索プラグインは数多くの可能性を秘めている。
たとえば、類似Issue機能、入力補完などの機能だ。

これらは、GoogleAdsenceやAmazonの関連商品表示のように、あなたが入力したチケットは過去のこのチケットに似てませんか?とRedmineが教えてくれるわけだ。
特に、チームに新規加入したメンバーは、問い合わせ対応や障害対応を知らないはずだから、システムが自動支援してくれる機能は非常に有効だろうと思う。

また、Google日本語入力みたいに、チケット入力時に、Redmineが単語を入力補完してくれるとありがたいはずだ。
特に日本語は同音異義語がすごく多いので、表記揺れや類義語があるだけでも、検索にヒットしない場合があるからだ。
たとえば、「打合せ」「打ち合わせ」で検索した時に、いずれも検索結果に表示されると嬉しくないだろうか。

サポートデスクのオペレータの観点では、入力時にあまり神経を尖らせることなく、簡単に入力できて検索できる方がありがたいはずだから。

つまり、Redmineに機械学習や人工知能の機能を追加することで、Redmineに蓄積されたデータを有効活用できるはずだし、本来のナレッジシステムに進化させることができるはずだ。
すなわち、このプラグイン実装の背景を考えると、昨今流行している機械学習や人工知能の技術をRedmineに簡単に適用できる事実を示唆している。
Redmineの未来にとって、とても興味深いだろうと思う。

たとえば、Microsoftが提唱する「働き方AI」みたいに、Redmineを使って、オペレータの業務を効率化することで、昨今の働き方改革の時流に乗り、AIを使って賢く働きましょう、みたいなことも、Redmineで実現できないだろうか?

働き方を自ら改革、機械学習とAIを活用するマイクロソフトの「Office Delve」と「MyAnalytics」 - クラウド Watch

マイクロソフトOffice365にAI機能「MyAnalytics」、これからは働き方をAIに聞く時代になるの? | ロボスタ

【4】以上のようなことを考えてみると、Redmineというツールは非常に面白いな、と思う。
世界中のユーザが使い込んでいくうちに、こういう使い方ができればいいな、という改善要望が1つずつ実現されることで、新たな使い道が発見され、そのアイデアに触発されて、さらに別の新たな使い方が見いだせる。

サポートデスク管理のように、Redmineが生まれる前からずっと存在している業務でも、Redmineのように、かゆいところに手が届くUIを提供してくれるツールが、サポートデスクをより効率化してくれる。
こういう細かな機能改善が、数多くの人たちが業務に触る時間を短縮し、本来の作業に注力できる環境を提供してくれるから。

そういうRedmineのバージョンアップの歴史を振り返ると、今後も期待できるし、それら最新機能をどの業務にどのように使えば効果的なのか、を考えることがとても楽しくなる、と思っている。

| | コメント (0)

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に追随してくれるはずだから、入れてみてもいいと思った。

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

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

【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)

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