プロジェクトマネジメント

2020/11/11

「製造業アジャイル、静岡での実践!」を聞いてRedmineはコミュニケーション管理ツールなのだと気づいた #devlove #静岡ギルド

今夜行われた「製造業アジャイル、静岡での実践!」を聞いてRedmineはコミュニケーション管理ツールなのだと気づいた。
ラフなメモ書き。

【参考】
静岡ギルド(準備中)勉強会「製造業アジャイル、静岡での実践!」 - DevLOVE | Doorkeeper

詳細は上記ページの通り。
1回目は、POもSMも開発チームもScrumの初心者だった。
やる気はあったが、やはり色んなトラブルが出て、POや開発チームのコミュニケーションも悪くなり、進捗遅延で増員されるたびに開発案件がどんどん膨らんでしまう。
最後に、SMの役割を果たせず、案件から抜けてしまう。

再起を期した2回目はいろんな工夫をした。
その話を聞くと、ポイントは2つあると思う。
それは、組織構造と組織文化の2つ。

組織構造の面では、POを2人体制にしたり、開発チームに進捗報告担当のトラッカーを立てたり、SMも時には開発に入ったり課題管理に直接関わったりしたこと。
Scrumの本来の姿ではないかもしれないが、各人の役割と責任に対し、権限と責任が一致できていないならば、補佐を立てて強化したり、あるいは自ら作業に加わったりする。
目的は、Scrumを運用することではなく、開発案件を成功させることなのだから。

組織文化の面では、TeamsでPOと開発者が頻繁にコミュニケーションする。
コメントに、いいねやハートのアイコンをつけることで、ちょっとしたニュアンスを伝えられた。
TeamsのPlannerでPBIを書いて5つのステータス(ToDo、Ready、Doing、Reviewing、Done)でかんばん風に管理したり、TeamsのPlannerで書き足りない内容はRedmineのチケットに詳しい仕様や課題を管理し、Sprint計画はRedmine上でロードマップ画面を使った。
スプリントレビューのデモでは、Teamsのカメラ機能を使って、実際にスマホアプリの動作をステークホルダーに見せて、その場でフィードバックをもらえた。

最初は、TeamsのPlannerでストーリーカードをかんばん風に管理して、詳細化したタスクカードをRedmineのチケット管理で実現したと思っていたが、TeamsのPlannerにはたくさんの情報を書き込みできないなどの不便があったので、Plannerはステータス管理に注力し、Redmineチケットのリンクを書いておいて、課題や状況の管理はRedmineで行っていたらしい。
後で、Redmineのチケットパネルプラグインを入れたら、親チケットはチケットパネル機能でかんばんで管理し、詳細なタスク管理は子チケットで管理するといいのでは、と提案してみた。

そんな話を聞くと、RedmineやTeamsはコミュニケーション管理ツールなのだと感じた。
ガチガチの進捗管理をツールで実現するのはすぐに可能だが、実際はそう簡単には回らない。
一方で、チーム内のコミュニケーションを活性化するには、POやメンバー同士の信頼関係が前提条件だ。
そのために、デイリースクラムではSMはメンバーに進捗遅延を責めることはしないし、POは開発メンバーに見積もりが多すぎるのではとあえて口を挟む権限を付与したりする。
つまり、お互いに本音で言い合える関係をツールで実現することが重要だと感じた。

もちろん、ツールさえあれば開発案件が成功するわけではない。
自分の経験を振り返ってみると、結局は、ソフトウェア開発案件は開発者とリーダーの能力にすごく依存する。
開発者とリーダーの能力を最大限に発揮するには、プロジェクトの体制図という組織構造で権限と責任を明確にし、権限と責任を一致させて、各メンバーの意思決定を迅速させることが重要だし、メンバー全員が最終ゴールを認識していて、その実現のために目標達成意欲を高揚させる雰囲気作りが大事だ。
そして、コミュニケーションを円滑に進める基盤として、RedmineやTeamsのようなツールがあるわけだ。

組織構造を整える部分は、プロジェクトの体制図を決める時に決まるから、おそらくプロジェクトの立ち上げ時に既に決まっている。
組織文化を整備する部分も、RedmineやTeamsを事前に整備しておく必要があるから、プロジェクトの立ち上げ時に既に決まっている。
そんなことを考えていると、Scrum云々というよりも、プロジェクトマネジメントという基盤の考え方が使えるのかな、と思ったりもした。


| | コメント (0)

2020/10/16

仕事が上手じゃない人は取り掛かりが遅い

Redmineヘッドラインを読んでいたら、「仕事が上手じゃない人は取り掛かりが遅い」という記事があったのでメモ。

Redmineヘッドライン ? プロジェクト管理ツールRedmineの今の話題をまとめて紹介

「部下を育てる」ことを「部下の能力を上げる」ことだと勘違いしていた、という話 | Books&Apps

結騎 了さんはTwitterを使っています 「転職を数回経験して、直近の数年は上司を体験させてもらってるけど、「仕事が上手じゃない人」の多くに共通点があると感じている。それは、「取り掛かりが遅い」。とにかくこれに尽きる。シンプルな怠惰、考えすぎ、極端な慎重派、仕事を断れなくて量を抱える人......。何より着手までが遅い。」 / Twitter

結騎 了さんはTwitterを使っています 「「取り掛かれば10分で終わる仕事」をとにかく後回しにして、30個くらいコレクションして常に「忙しい?忙しい?」と言っている人がいる。仕事コレクターの多くは、何度アドバイスをしても中々改善されない。残念ながら。貴方が持っている間に仕事が腐って次にそれに触れる人が迷惑しているのに。」 / Twitter

(引用開始)
皆さんも経験ありません?
やること自体は明確なんだけど、複数タスクが並んでいると、「まずどれから着手するか」ということから考えてしまって、なかなか着手出来ないこと。
これ、上司からちゃんと優先順指示されてても、「次のタスク」が気になって心理的ハードルが上がっちゃうことってあるんですよ。

まして、タスクの優先順とそのゴール地点自体が不明瞭だったりすると、着手のハードルは天井知らずに跳ね上がります。
「あー」とか「うー」とか言いながらモニターの前で思わずネットサーフィンを始めちゃうこと、ありますよね。

しかもこれ、割と人間の根源的な問題なんで、改善ってすごーく難しいんですよ。
上司や周囲がいくら叱っても、直らないもんは直らないんです。
「他者による能動的な改善」が非常に難しい部分なんです。

で、私の部下にもそういう人いまして、とにかく「まずタスクを開始出来るまでがやたら遅い」という問題があったんで、普通にある時こう言ったんですよ。
「ブラウザのスタート画面をredmineのカスタムクエリにしましょう」って。
(引用終了)

こういう人はいるなあ、と思う。

| | コメント (0)

2020/09/02

問題解決アプローチを見極める『クネビンフレームワーク』のメモ

問題解決アプローチを見極める『クネビンフレームワーク』を知ったのでメモ。
結論のないメモ。

【参考1】
akipiiさんはTwitterを使っています 「クネビンフレームワークの説明が参考になった。問題のドメインが時代で変化しているからソフトウェア開発プロセスも変化する。非開発者のためのアジャイル開発入門 by @haradakiro #agile #complex https://t.co/2iCYVDeddY」 / Twitter

More Effective Agile ? “ソフトウェアリーダー”になるための28の道標|かず|note

複雑な世界を捉えるためのカネヴィンフレームワーク(Cynefin Framework) ? ゲームを用いた企業研修なら| 株式会社HEART QUAKE

(引用開始)
カネヴィンフレームワークは1999年にIBM Global Servicesのデイブ・スノーデン(Dave Snowden)らが提唱したもので、状況・問題を大きく4つのドメインに分類するフレームワークです。(上画像)

1.Simple(シンプル):単純
⇒問題の因果関係・構造が明確

2.Complicated(コンプリケーティッド):煩雑
⇒少し分析すれば、因果関係・構造が明確

3.Complex(コンプレックス);複雑
⇒因果関係が複雑、調査・探索が必要

4.Chaotic(カオス):混乱
⇒因果関係が不明確で、状況や問題を理解することも難しい

その他.Disorder(ディスオーダー):無秩序
⇒直面する問題に適切な解決策がない

さらに、1のSimpleと、2のComplicatedを予測可能な問題、3のComplexと、Chaoticを予測不可能な問題と分類することもできます。
(引用終了)

製造業における製品製造の大量生産方式のビジネスと、エンジニアやコンサルタントなどの知的労働者がプロジェクトで仕事するビジネスは、本質的に何かが違うといつも思っていた。
その理由の一つは、問題解決アプローチが全く違う、という指摘を、クネビンフレームワークは教えてくれる。

クネビンについて講演してきました | サーバントワークス株式会社

(引用開始)
(クネビンフレームワークが必要とされる)背景としては、「正解がない」多様化した問題と現実解に対しての理解を深めることが第一義です。第二儀としては、アジャイルの必然性の腹落ち感があります。
(引用終了)

アジャイル開発が昨今必要とされる背景には、従来の問題解決の手法が通用しなくなってきていて、新しいフレームワークや考え方による問題解決手法が必要とされているのだろう。
「More Effective Agile ~“ソフトウェアリーダー"になるための28の道標」では、アジャイル開発による問題解決の観点はクネビンフレームワークの「複雑(Complex)」に当たるのではないか、という内容があるらしいので、今度読んでみたい。

【参考2】
複雑な世界を捉えるためのカネヴィンフレームワーク(Cynefin Framework) ? ゲームを用いた企業研修なら| 株式会社HEART QUAKE

クネビンフレームワーク Cynefin Framework :臨機応変の意思決定手法 ? I & COMPANY / アイ&カンパニー

カネビン・フレームワークで問題解決策を見極める

クネビンフレームワークを使ったテクニカルサポートチームの行動指針の立案 | Developers.IO

問題の解決アプローチを見極める『クネビンフレームワーク』をざっくりまとめる - コード日進月歩

(引用開始)
これをエンジニアのロールに置き換える広木さんのツイートはすごいなと思ったので参考まで
(引用終了)

広木 大地/ エンジニアリング組織論への招待さんはTwitterを使っています 「CTO/VPoE/TechLead(スペシャリスト)の仕事って一体どう言う役割分担なの?みたいなことを聞かれる。 これはクネビンフレームワークで捉えるとわかりやすい CTO は Chaoticな問題 -> Complex VPoE/EMは Complexな問題 -> Complicated TechLeadは Complicatedな問題 -> Simple 不確実性が減っていく https://t.co/un1FX3QQ53」 / Twitter

akipiiさんはTwitterを使っています 「クネビンフレームワークでカオスで複雑・複合的な問題を分類する。CTO/VPoE/TechLeadというエンジニアのロールはクネビンフレームワークで整理すると分かりやすいという指摘。 問題の解決アプローチを見極める『クネビンフレームワーク』をざっくりまとめる - コード日進月歩 https://t.co/exz3rCJnfw」 / Twitter


| | コメント (0)

2020/07/07

ソフトウェアの政治的影響力とは何だろうか

今年になって、台湾の天才IT大臣の記事をチラホラ見かける。
ソフトウェアの政治的影響力を上手に使いこなしているな、と感じたのでメモ。
ラフなメモ書き。

【参考1】
「マジで胸アツ」台湾の天才IT大臣、東京都の新型コロナ対策サイトの修正に自ら参加し話題に

(2) akipiiさんはTwitterを使っています 「時代の変化は速いよね。「マジで胸アツ」台湾の天才IT大臣、東京都の新型コロナ対策サイトの修正に自ら参加し話題に https://t.co/drVTKoZz74」 / Twitter

新型コロナ“神対応”連発で支持率爆上げの台湾 IQ180の38歳天才大臣の対策に世界が注目 (1/4) 〈dot.〉|AERA dot. (アエラドット)

新型コロナ“神対応”連発で支持率爆上げの台湾 IQ180の38歳天才大臣の対策に世界が注目 (2/4) 〈dot.〉|AERA dot. (アエラドット)

新型コロナ“神対応”連発で支持率爆上げの台湾 IQ180の38歳天才大臣の対策に世界が注目 (3/4) 〈dot.〉|AERA dot. (アエラドット)

(引用開始)
タン氏にインタビューした経験がある前出の近藤さんは、こう話す。
「両親の職業がジャーナリストということもあり、彼女は『情報』が人々にどのような影響を与えるかをとても理解しています。
また、現役の閣僚でありながらも特定の政治的立場に立つのではなく、むしろ意見の対立をIT技術で可視化して、解決につなげることを考えている。
入閣した時に『公僕の中の公僕になる』と宣言したとおり、特定団体の利益のために動くのではなく、テクノロジーを駆使して台湾の人々と行政院をつなぐ“パイプ”になっています」
(引用終了)

akipiiさんはTwitterを使っています 「ITによる可視化で政治的対立を消化させる道具にする発想が素晴らしいと思った。Redmineにも通じる。「むしろ意見の対立をIT技術で可視化して、解決につなげることを考えている」新型コロナ“神対応”連発で支持率爆上げの台湾IQ180の38歳天才大臣の対策に世界が注目 AERA dot. https://t.co/GORTP5vWb4」 / Twitter

【参考2】
台湾の天才IT担当大臣オードリー・タンに訊く、新型コロナウイルスの先にある未来の国家とは - Engadget 日本版

akipiiさんはTwitterを使っています 「ソフトウェアの政治力を良く知り尽くして活躍されてる事例。参考になる。” 台湾の天才IT担当大臣オードリー・タンに訊く https://t.co/zxSe7tNwVZ」 / Twitter

こーじさんはTwitterを使っています 「>その一方でパニック買いなど、噂による行動は防ぐ必要があります。そこに対しては、インフォデミック(≒情報の氾濫)より面白いユーモアを発信するという対策に取り組みました。 これ凄い面白い取り組みだな」 / Twitter

akipiiさんはTwitterを使っています 「@saba1024 台湾のIT担当大臣は、人々がシステムやSNSを使うと、どんな行動に走るのか、それを遠くまで見通して意思決定している点が凄いです。ソフトウェアの開発力だけでなく、その政治的影響力、行動経済学の知見、社会心理学の知見を知り尽くしてる、そんな気がします」 / Twitter

こーじさんはTwitterを使っています 「@akipii まさに仰るとおりですね! 時代が人を作るのか、人が時代を作るのかというのはよく言われる話題では有りますが、この方は間違いなくこの時代に必要とされる方ですね。」 / Twitter

台湾の天才IT担当大臣の振る舞いをツイッター上で眺める限り、ソフトウェアの調達方法や影響力の行使の仕方をよく理解しているな、と思う。
たとえば、コロナ感染症サイトへのプルリク、マスク在庫サイトの構築方法、記者会見をすべてオンライン化などがすぐに思い浮かぶ。

彼女のやり方で参考になる点はいくつかある。
1つ目は、ソフトウェアの開発はベンダー委託ではなく、オープンソース開発者のコミュニティを使って、アジャイルに開発していること。
公的なソフトウェアの開発は、官公庁の内部調整やベンダーへの委託によるリスク回避など、数多くの組織的な壁がボトルネックになりがちだ。
しかし、本来、公的なソフトウェアは国民全てがその利益を享受できるものだし、その重要性は高いのだから、いち早くリリースして、漸進的にVerUpしながら開発していくべきだ。
しかも、ソフトウェアは請負契約で作ったら終わりではなく、SaaSと同じく、運用しながらどんどん改善していく開発スタイルなので、ベンダーへの一括委託は元々なじまない。
現在のソフトウェア開発の技術革新の場所は、ベンダーではなく、オープンソースコミュニティに移っているのだから、彼らの力を利用して、国民すべての利益にかなうようなソフトウェアを作るべきだろう。
彼女の言動や行動した結果を見ると、ソフトウェア開発の特徴をよく理解しているように思える。

2つ目は、情報を発信すると人々がどのように影響を受けて、どんな行動に移るのか、という事を彼女はよく考えて理解しているように思えることだ。
「現役の閣僚でありながらも特定の政治的立場に立つのではなく、むしろ意見の対立をIT技術で可視化して、解決につなげることを考えている」という記事の言葉から想像すると、行動経済学の知見をよく知っているのではないか、と思う。

実際、コロナ感染が流行している時期にマスクの情報を何の仕掛けもなく公表するとどうなるのか?
本来マスクが必要な人に情報を知らせるにはどうすればよいのか?

皆が混乱している時に、その情報をIT技術で見える化することで、真実を共有し、そこから各人のあるべき行動を促す。
IT技術は本来、そういう問題解決に使うべきものであるはずだ。

そして、単に、マスク在庫のシステムをアジャイルに作るだけではない。
彼女や他の大臣が率先して、その規範を示していることも大事だ。

「例えば、支給マスクの色がランダムで、ピンクが当たった男子生徒が登校拒否になっているという声が届きましたが、その翌日には閣僚の男性陣によるピンクマスク着用のキャンペーンが始まりました。」という記事の通り、大臣自らが率先して見せれば、他の人も自然にその行動変容を受け入れてくれる。

「組織文化は組織のトップが作り出すもの。組織のトップはもっと汗をかくべき」と、とある先生から組織論の授業で習った。
僕が理解するには、人がたくさん集まっても、単なる集団であり、何かの目的を成し遂げるための組織にはなりえない。
トップがリーダーシップを発揮して、共通目的を語り、メンバーの貢献意欲を引き出し、コミュニケーションを活性化して初めて、集団は組織に変わり、人々の行動を変容させる。
また、社会や組織の中にいる人達は、社会的地位が低かったり、経済力がなかったり、政治力がないために、他の力の強い人達の影響を受けやすい面がある。
だからこそ、規範となるべき人があるべき姿や目的を語ることで、人々の意欲を引き出し、人々の行動を変容させる。
つまり、社会に流通する価値観や規範は、そのトップのリーダーシップから生まれるものだ。

そして、昨今の環境では、SNSを使えば、簡単に周知させやすい。
人の気持ちを盛り上げて、意欲を引き出すような言動をリツイートさせることで、人々に行動を変えさせる事が以前よりも格段に簡単に、かつ、その影響力が大きくなった。
その分、この使い方も難しい。
行動経済学が考えているように、人は合理的な存在ではなく、時代や環境に依存したバイアスを持って価値判断を下し、経済効果を生み出す。
そういう考え方を利用する方法もあるだろう。

| | コメント (0)

2020/06/17

相殺フィードバックを再考

システム思考で出てくる相殺フィードバックをメモ。

【参考1】
学習する組織 - ごろにゃ~の手帳(備忘録)-パーソナルMBA的な

(引用開始)
強く押せば押すほど、システムが強く押し返してくる
よかれと思って行った介入が、その介入の利点を相殺するような反応をシステムから引き出す現象である。
私たちは誰もが、相殺フィードバックに直面するのはどんな感じか知っている。
押せば押すほど、システムが強く押し返してくる――つまり、物事を改善しようと努力すればするほど、 さらに多くの努力が必要に思えてくるのだ。
(引用終了)

【参考2】
組織は「苦労」や「一生懸命努力すること」を美化してはいけない。 | Books&Apps

(引用開始)
MITスローン経営大学院のピーター・M・センゲは著書「学習する組織」においてこの現象を「相殺フィードバック」と呼ぶ。
多くの企業が、自社製品が突然に市場での魅力を失い始めるとき、相殺フィードバックを経験する。企業はより積極的な売り込みを推し進める―それが今までいつもうまく言っていたやり方だ。宣伝費を増やし、価格を下げるのである。
こう言った方法によって、一時的には顧客が戻ってくるかもしれないが、同時に会社からお金が流れ出ていくので、会社はそれを補うために経費を切り詰め、サービスの質(例えば、納期の早さや検査の丁寧さ)が低下し始める。
長期的には、会社が熱心に売り込めば売り込むほど、より多くの顧客を失うことになるのだ。
(中略)
私が見た現象は、サービスの質を改善せず、全員を「テレアポ」と「飛び込み」などの労働集約的な仕事に邁進させる、というやり方だったが、上と全く結果は同じであった。顧客は流出し、人材は会社を辞め、競合にシェアを奪われたのだ。
(引用終了)

相殺フィードバック: プログラマの思索でも書いたが、IT業界は相殺フィードバックによる問題発生が多い。

たとえば、過去に直したバグ修正が、今の障害の発生原因になっている。
たとえば、以前下した判断や意思決定が、今回の問題の発生原因になっている。
その時は良かれと思ったことが、実は場当たり的な対応であって、より一層症状を悪化させた。

僕の経験上、相殺フィードバックという症状は、ソフトウェア開発で非常に発生しがちと思う。
従来のソフトウェア開発の現場では、元請けのPMと下請けのプログラマが混成チームを形成するが、彼らは顧客と切り離されているので、顧客からのフィードバックを得るタイミングが最初と最後のフェーズしかない。
だから、現在の意思決定がどんな影響を及ぼすのか、想像できない。

ソフトウェア開発は自己目的化しやすい: プログラマの思索

相殺フィードバック: プログラマの思索

僕は、相殺フィードバックをなくすには、システム思考に出てくる因果ループ図のような発想方法よりも、ランダム比較化実験を使って行動経済学の知見を導き出す手法の方が効果的ではないか、と直感している。
最初から、相殺フィードバックにはまらないような意思決定を下すのは難しい。
できれば、傷が浅い程度の失敗は許容できる時期に、2つの意思決定をランダム比較化実験で試して、人間の行動や集団行動がその後にどのような影響を与えるのか、を見極めた方がいいと思っている。

以前はそういう手法が使えなかったが、今はWebアプリはクラウド上で即座に作れるし、スマホ経由でランダム比較実験をしてみるのは易しい。
行動経済学の知見をソフトウェア開発やソフトウェア工学に活用するアイデアは試して見る価値があるように思える。


| | コメント (0)

2020/05/04

Redmineとチャットツールはどのように使い分けるべきなのか

「Redmineとチャットツールはどのように使い分けるべきなのか」という疑問についてラフなメモ。

akipiiさんはTwitterを使っています 「第18回勉強会 - https://t.co/i2sJFMEe2v の議題は、やはり、テレワークにRedmineをどのように有効活用して運用できるか、という点と思います。多分Redmineを普段運用していればスムーズに移行できたはず。今回の緊急事態宣言によってRedmineのメリットが明確になったはず。 https://t.co/XHELA5jGsZ」 / Twitter

akipiiさんはTwitterを使っています 「Redmineを利用する一方、チャットツールを皆さんは何を使っているのか、も気にしてます。チケットに書くほどでないコミュニケーションはChatツールを使うならばRedmineとチャットツールを使い分ける基準は何か? チャットが重視されるとRedmineのチケット起票が重く感じられる為。」 / Twitter

y503Unavailable@Redmine Kindle本出版unofficialcookingさんはTwitterを使っています 「@akipii 先月からTeamsですが、チャットはフローでありストックではないことを明確にしています。 相談程度はチャットで軽く進め、途中経緯をRedmineにコピペし蓄積。 チケット起票しないと設定しない程度の運用を確立していれば回ると思います。」 / Twitter

齋藤さんはTwitterを使っています 「@y503Unavailable @akipii Teams には、内容のコピペとかコピーとかの配慮があまりなくて、長くなると面倒なんですよね。是非、そこは強化して欲しい。」 / Twitter

門屋浩文@redmineエバンジェリストの会1号さんはTwitterを使っています 「@akipii ストックとフローの話はどこかでやりましょう コミュニケーション設計からコストを下げるような」 / Twitter

たけちゃんさんはTwitterを使っています 「@akipii @MadoWindahead chatはTeamsを使ってますが、コミュニケーションとタスク管理で用途を分けているつもりが、プロジェクト毎に線引きが異なって来ました。Teamsもシェアポイントでのファイル共有ができるので、ちょっとしたファイルはこっちでやり取りしちゃう人も出てきます。」 / Twitter

akipiiさんはTwitterを使っています 「@ta_ke_chan_ @MadoWindahead そう、よく分かります。GSuiteを使ってると、Google Chat, HangoutMeetを使ううちにGoogleスプレッドシートなどで課題管理やタスク管理し始めてしまったり。ツールの利用シーンはどうしても組織文化が出てくる」 / Twitter

門屋浩文@redmineエバンジェリストの会1号さんはTwitterを使っています 「@akipii @ta_ke_chan_ そう、GSUITE派なのでどうしても二次元管理が横行してます 二次元で大丈夫なものはそれでもいいと判断したいので、redmineがいいパターンを出したい あと、chatやSNS系(salesforceなど)の長所短所もまとめればいいのかな? たけちゃんはhttps://t.co/EeqCzfWvkz参加ですね よろしくお願いします」 / Twitter

neta @ redmine.tokyo 5/23(土)オンラインやりますさんはTwitterを使っています 「@MadoWindahead @akipii @ta_ke_chan_ ウチは G Suite 『Google ( Hangout ) Chat』なので、まずは Redmine の通知を連携することからはじめたいと思ってる」 / Twitter

テレワーク中のシロくまさんはTwitterを使っています 「テレワークができる環境づくりに役立ったもの ペーパーレス⇒プロジェクト管理(Redmine) コミュニケーション⇒チャット(Microsoft Teams 秋から会社方針でGoogle Meets) 固定電話⇒クラウドPBX(Dialpad) 次は仮想オフィスツールがねらい目でしょうか。」 / Twitter

吉澤さんはTwitterを使っています 「パン工場じゃ無理だけど、WBS書いて、redmineでチケット切るようになれば、日本の事務職の生産性は飛躍的に向上すると思う。 https://t.co/E6V2xJhGIZ」 / Twitter

【1】昨今、急にテレワークの作業環境を強いられた場合、Redmineのようなプロジェクト管理ツールでプロジェクト運営していなかったら、案件で開発するのは非常に難しいだろう。

一方、従来からRedmineでプロジェクト運営していたら、VPNさえ確保できれば、オンライン上で作業の管理を継続できるので、スムーズに移行できているだろう。

しかし、日々にコミュニケーションはオフラインのチャネルが全て駄目になったので、オンライン上で何かしらのコミュニケーションが必要になってくる。
もちろん、Redmine単体でチケットのやり取りを通じて、日々の課題やタスクは管理できるが、それだけではコミュニケーションは足りない。
たとえば、非公式なコミュニケーション、ZoomやGoogleMeetによるオンライン打合せを補強するチャットなどでチャットツールが欲しくなる。
おそらく一般には、Slack、MSならTeams、GooleならGooleChat、他に、FB Messenger、LINE、Discordなどが使われているだろう。
つまり、Redmineのようなプロジェクト管理ツールだけではプロジェクト運営は不十分であり、もっと気楽でレスポンスの早いチャットツールが必要ではないか、と思われる。

【2】では、Redmineとチャットツールはどのように使い分けるべきなのか?
また、Redmineとチャットツールを併用することでどんな問題が噴出して、どんな課題が出てくるのか?

「顧客ごとにチャネルがこれだけ違うとは。リアル過ぎて参考になる。RT @_alimika_: 顧客A→Slack 顧客B→Facebook Messenger 顧客C→Chatwork 顧客D→Microsoft Teams 顧客E→メールオンリー 顧客F→Backlog オンリー 顧客G→Confluenceオンリー 顧客H→Redmine オンリー 顧客I→GitHubオンリー」 / Twitter

【2-1】一般には、Redmineのチケットは記録して残す内容、チャットは日々流れて消えてしまう内容、というように使い分けているだろう。
しかし、その使い分けは人によって様々に異なる。

Slackでは、数多くのスレッドをチャネルとしてどんどん追加できるので、チーム間や1対1のやり取りが非常にやりやすい。
すると、そのチャットのやり取りだけで、仕事が捗るので、チケットにわざわざ残すのが億劫になる。
チケット上で成果物のレビューをキャッチボールするのが非常に時間がかかるように思われて、チケットに逐一残すのが面倒に感じてしまう。

特に、気心の知れたメンバーであれば、チケット化しなくても、お互いの暗黙知でいい感じに何とかなってしまう時も多い。
すると、課題やToDoがあったとしても、お互いの頭の中に共有されていて、チャットで常に同期されている感覚になる。
わざわざチケットでやり取りするほどでもない、みたいになってしまう。

【2-2】一方、チャットでは大量の発言が流れる場合が多いので、何が決まったのか、どんな経緯で結論に至ったのか、を把握するのが難しくなる。
作業がスムーズに運ぶ場合はチャットで十分だが、試行錯誤しながら振り返りを参考にして進める場合には、何かしらのログを残したくなる。
しかし、チャットで議論した内容をチケットにまとめる作業は割と手間はかかる。
その手間とチケットの起票更新のコストのトレードオフを無意識に計算しているような気もする。

他方、Githubでプルリクをやり取りするプロジェクトであれば、ソースコードのコミットとプルリクが重要であるから、その部分は必ずチケット化される強制力は働く。

【3】Redmineとチャットツールの間の情報連携にも、いくつか問題や課題はある。

【3-1】ITS(Redmine)→チャット(Slackなど)へ連携する運用は多い。
その理由は、Redmineのチケット・Wiki更新の通知をメールではなく、チャットで把握したいからだ。

Redmineの通知メールは正直うっとうしい。
たとえば、コメントなしの単純なステータス更新、項目更新だけでも通知メールが飛ぶので、プロジェクトが活発になると、1日100通以上のメールが飛び合うのはよくある。
大量のメールに更新内容が埋もれてしまうよりも、チャットで流れた方が正直扱いやすい。

【3-2】一方、チャット(Slack)→ITS(Redmine)の情報連携は手作業でやるのが多い。
REST APIを駆使すれば、チャット内容をチケットに起票できるだろうが、チャットの手軽さの文化と合わない気はする。

しかし、チャットで議論された内容をチケットに記載したい場合は多い。
議論していくうちに、こういう課題は検討すべきだ、とか、ここまでは解決できたから残りはこのToDOだけだね、とか、色々出てくるはずだ。
それらの内容はチケットに残して、誰が担当してボールを持っているか、その課題はどんなステータスにあるのか、を後日把握したいからだ。

そういう運用をしたい時に、チャット→ITSの情報連携をもっと気軽にやりたい課題がある。

【4】Redmineとチャットツールの情報連携の問題点は、たとえば、RedmineやJenkins、GitLabなどの開発基盤の連携とは観点が異なる。

後者は、作業の起点がチケットであり、チケットが更新されていくたびに、Gitへコミットされたり、JenkinsやCircleCIなどでビルドされて、ビルドモジュールがリリースされていく。
つまり、ソースコードという成果物の構成管理が、利用シーンに応じて各種ツールで管理されていくべきだ、という観点になる。

一方、前者は、プロジェクト内のコミュニケーションは、どんなチャネルでやり取りすべきなのか、という点が本質的な観点だ。
議論で発散していくフェーズならばチャット、発散した議論を収束させて検討すべき課題や残タスクにまとめて管理していくならば、Redmineのようなチケット管理ツールが必要になる。
つまり、チームで議論している内容を、チャネルごとに無意識に使い分けているのではないだろうか。

だからこそ、コミュニケーションチャネルをどんな利用シーンでどのツールでやるべきなのか、をプロジェクトリーダーは明確に意識しておくべきだろう。
コミュニケーションチャネルを意識することで、Redmine単体で運用している時よりも、チーム内のコミュニケーションが活発になり、単純な命令伝達だけでなく、メンバーのモチベーション向上も期待できるだろう。

この辺りの事例も色々収集してみたい。

| | コメント (0)

2020/04/01

オンラインのリーダーシップとは何だろうか

リモートワークの推進によって、リーダーシップの振る舞い方も変わってきているように思う。
オンラインのリーダーシップの概念が必要になっているように思う。
ラフなメモ書き。

【1】リモートワークのノウハウについては、倉貫さんの会社が日本で一番持っているのではないだろうか。

[議論]新型コロナでリモートワーク急拡大、でも少し変じゃない?:日経ビジネス電子版

相手に「伝わる」ビデオ会議、14の鉄則。全社員リモートワークのソニックガーデンに聞く | iXキャリアコンパス

リモートワークで生産性を上げる仕組みやノウハウが非常に細かく書かれていて参考になる。
そんな記事を読んでいると、いくつか疑問が出てくる。

今までは会社、学校というオフラインの場所で、仕事や教育を行ってきたし、その仕組みに特化するように、洗練されていた。
しかし、昨今のコロナウイルス流行の影響でオフラインの場所を確保できない状況になり、一時的であっても、オンラインで仕事や教育を実施する必要性が出てきた。
すると、感染症が終わって正常の世界に戻った場合、既にリモートワークで生産性が上がっているならば、以前のオフラインの世界に戻る必要はない。
その意味では、現在の感染症は、オフラインの仕組みに依存してきたビジネスモデルそのものも劇的に変更されるだろう。
もはや会社や学校という物理的な場所はなくてもビジネスも教育が回るからだ。
感染症が終わった後の世界では、会社も学校も大きな環境変化が生じているだろう、と推測する。

【2】では、オンラインとオフラインの環境の本質的な違いとは一体何だろうか?

オンラインの作業についての問題点もいくつか出ている。
その問題点は、技術的課題と適応的課題の2つに分けられるだろう。

技術的課題は、オンラインのツールに慣れない、普及しない、環境が揃っていない、など、技術を克服すれば解決できるもの。
たとえば、「強い者や賢い者よりも変化に速い者が生き残る」という言葉は、まさに、オンラインの環境にいち早く適用した人ほどその利益を得やすい事実を示唆していると思う。

一方、適応的課題は、そういうツールや環境が揃ってきた上で、コミュニケーションや意思疎通をより深く太くしていく為には何が必要なのか、それぞれの現場や人、組織に依存したもの。
これらは、コンテキストに依存している場合が多いだろうから、出てきた課題を一つずつ皆で解決しながら、課題のレベルを上げていくしかない。

上記の記事を読んだ後、いかに一人ぼっちにさせないか、という仕組みが非常に重要になっているような気がした。
オンラインのリモートワークの環境になると、身近に物理的に人がいないので、困った時に声掛けできない。
そのために、Twitterのタイムラインのようなデータを流したり、顔を常時写したり、いろんな工夫がされている。

【3】僕が一番興味を持つのは、オンライン環境ではリーダーはどのようなリーダーシップを振る舞う動作が必要なのか、という問いだ。
あるいは、オンライン上のチームビルディングでは何が必要なのか、という問いだ。

倉貫さんの下記の意見に非常に興味を引いた。

(引用開始)
倉貫氏:改めて考えてみると、これまではなんて牧歌的な時代だったんだろうと驚きますね。チームビルディングを「同じ場所に集まる」という偶発的なものだけに頼って、ほとんど何もやらずにさぼってきたのかと、自分の反省も含めて思います。
(引用終了)

従来のチームビルディングの手法は、オフラインの環境に依存しすぎていないだろうか?
従来の手法をそのままオンライン環境に持っていっても、チームビルディングが上手く行かないのは明らかだろう。

【4】会社、役所、NPO法人、コミュニティなどの集団は、必ず何らかのトップとなる人がいて、彼らがその組織文化を生み出す責任を持っている。

組織文化はトップが作り出すものであり、その逆ではない、と僕は習った。
実際、どんな集団も共通目的があり、その目的に賛同した人たちが結集して、集団の目標を実現しようとする。
そういう集団を最初に作る創始者が組織文化を生み出し、メンバーとの化学反応を起こして集団をより進化させていく。

以前ならば、オフラインの空間では、実際に人が集まってトップの話をうやうやしく聞いたり、あるいは、実際にトップが自ら動いて汗をかく場面を見て、メンバーの貢献意欲が刺激されて、一致団結していく、などの事例があった。
しかし、オンラインでは、トップの行動も話も声もPCの画面を見なければ伝わらない。
TV演説に近い部分もあるかもしれない。
以前のオフラインのリーダーシップの発揮方法とは本質的に異なっている気がする。

特に、昔ながらのリーダーシップの発揮方法である「制度的リーダーシップ」は、オンライン環境では非常に難しくなっていると思う。
つまり、役職を前提としたリーダーシップは、オンライン環境ではその権力を影響させにくい。
オンライン環境では、社員が真面目に働いているのか、を管理職が逐一監視するのは難しいからだ。

制度的リーダーシップの考え方が何となくしっくりきた: プログラマの思索

最近では、トランプ大統領がツイッターでどんどん発言することで影響力を増しているように、オンラインのリーダーシップの発揮方法はいくつかのやり方があるように思う。
一方、オープンソースの開発のように、最終的に意思決定するリーダーがいたとしても、世界中に散らばった開発者の技術力を結集して、優れた成果物を作っていくやり方もある。

いずれにしても、まだ僕の中ではスッキリした答えは持っていない。
でも、世界を見渡せば、オンライン環境でもリーダーシップを発揮して、メンバーをあるべきゴールへ導くようにメンバーの意欲を向上させることができているリーダーもいる。
彼らはどんなやり方を使っているのか、そのやり方の本質的な特性は何なのか、考えてみる。


| | コメント (0)

2019/12/28

「マーケティングとは「組織革命」である」の感想

「マーケティングとは組織革命である」を読んで、「組織改革に社内マーケティングの技法を使う」という内容がすごく面白かったのでメモ。
結論のないラフなメモ。

【1】地位が下の立場の人が、自分の提案を通して、組織を変えていくのはとても難しい。
僕も知らない。
でも、この本では、マーケティング技法を社内組織に適用すれば、上手くいくよ、と提示してくれている点が非常に面白かった。

【2】以下、僕の理解を書く。

【2-1】組織文脈
まずその提案は、組織の目的や戦略に合っているのか。
提案の目的に大義がなければ、他人の心に響かない。
目的には、困りごと、不文律や暗黙知、普遍的価値(売上拡大など)がある。

次に、誰が意思決定者なのか?
意思決定者がターゲットになる。

3つ目は、上司のが提案を評価する基準を知っているか?
審判は必ずしもフェアではない。

これらをまず把握して、自分の提案の整合性を取る。

【2-2】ターゲットは2つある
意思決定者がターゲット。
そのターゲットには、組織目的に忠実な人、自己保存に忠実な人の2種類がいる。
成功の鍵は、ターゲットを理解すること。
伝え方の前にターゲット理解が9割。

提案を通すのが下手な原因は、独りよがりであること、ターゲット分析が不十分だから。
なるほど、ターゲットを特定し、そのターゲットの心理変数を分析することが重要なわけだ。

【2-3】便益も2つある
ターゲット2つに対し、その便益も2つある。
公の便益と個の便益。

組織目的という公の便益の観点では、提案が通らない原因は、実現可能性を示すスキルが不足しているから。
これは、なるほどと思う。
コトラーのターゲット設定の条件である測定可能性、維持可能性、実行可能性、到達可能性のうち、実行可能性(実現可能性)を重視せよ、と言っているわけだ。

個の便益という自己保存の利益の観点では、自己保存に忠実なターゲットに対し、実利系の利益を直接示したり、承認欲求の利益を提示することが重要。
ただし、日本人には実利系の利益を見せると建前上断られるので、伝え方が重要。

【2-4】伝える手段は4つある
伝える手段の4つのタイプ、攻撃型、積極型、反応型、消極型それぞれに対して伝え方がある。
この辺りは書籍の中で色々説明してくれている。

だめな営業マンは、客の幅が狭い。
その原因は、自分の相性に客の種類を当てはめすぎ。
無意識に、自分の相性に合う客層を選んでいるから。
つまり、ターゲット設定が狭い。
よって、自分の相性に合わない客にも対処できるように、客の幅を広げていくべき。

| | コメント (0)

2019/12/27

失敗の本質―日本軍の組織論的研究の感想

旧日本軍という当時最先端の高度な官僚組織が日本を破滅に陥れた原因を、組織論に求める、という内容だった。

(1)7つの失敗事例の詳細は、地図を見ながら読まないと完全理解できないと思うけど、失敗に至った話を読むと、とても身に沁みるように感じるのは、たぶん、自分も古い日本の大企業にいるからかもしれない。

改めて思うのは、80年前も今日も、日本のトップは、巨大な官僚組織を上手く使いこなすのが下手、ということ。
一人ひとりの部下を動かせても、「組織を動かす」という能力が足りない、という感触を受ける。

日本の大手企業や官公庁のトップは、その大きな組織の重みをコントロールできず、誰も舵を取らないまま暴走してしまい、破滅に向かう。

一方、アメリカや中国は、官僚組織を使いこなすのが上手い感じはする。
その違いは何にあるのだろうか?

| | コメント (0)

2019/11/03

第17回東京Redmine勉強会の感想 #redmineT

第17回東京Redmine勉強会が無事に終わりました。
参加者、スタッフ、講演者の皆さん、ありがとうございました。
感想をラフなメモ書き。

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

第17回勉強会 - redmine.tokyo (2019/11/2) - Togetter

第17回redmine.tokyoで自動化の極意と形式知を育む #redmineT | マドびっ! Madosan's View

【1】Redmineコミュニティは1年のうち、大阪で2回、東京で2回、合計4回行われる。
この定期的なリズムが非常に心地よいと感じている。
Redmineを通じて、運用プロセス、プロジェクト管理、インフラ周りやプラグイン開発などの情報をユーザ同士で共有できる場があるのは非常に役立つし、何よりも楽しい。
今回の勉強会で心に残った箇所だけ書いておく。

【2】前田剛さんの発表では、ファーエンドテクノロジー版RedmineであるRedMicaの発表があった。
意図としては、Redmine本家のメジャーVerUpが年1回になっているので、最新機能のパッチが取り込まれているのにユーザに使ってもらえない問題に対し、Redmineの安定版バージョンにtrunkのパッチを当てて、定期的にリリースする、とのこと。

実際、Ver4.1には200個以上の機能改善が含まれているが、1年以上リリースされていないため、せっかくのパッチが使われていない。
この問題意識は重要と思う。

(1) akipiiさんはTwitterを使っています: 「#redmineT ファーエンド版Redmine では、半年ごとにtrunkプラスで最新機能パッチを定期リリースする。リリース計画のお話。気になるのは、Redmine 本家との互換性だが、trunkベースで、相互に移行できるようにする、とのこと」 / Twitter

(1) akipiiさんはTwitterを使っています: 「この考え方は重要。RT @akahane92: 今朝リリースされた Redmica(レッドマイカ) https://t.co/bXt3Pl37Lt Redmine本家のFork版ではない。独自の機能開発は行わず、Redmine本家の機能を先行して提供することに特化するつもり。 #redmineT」 / Twitter

(1) akipiiさんはTwitterを使っています: 「#redmineT Redmine 正式バージョンのリリースが遅い問題意識あり。そこで、ファーエンドテクノロジー版Redmine として、最新機能を盛り込んだフォーク版を公開した。なるほど、パッチを取り込んだ最新機能を早く使えるようにしたいわけか」 / Twitter

一方、Redmineプラグイン開発者の観点では、RedMicaにプラグインを追随させることで、メジャーバージョンアップに事前に対応できる、というメリットもある。

(1) akipiiさんはTwitterを使っています: 「なるほど、プラグイン開発でむ有用なのか。RT @agilekawabata: RedMicaのLychee Redmine対応ですが、本家Redmineのバージョンアップに追随はインパクト大きくて急に大変になるので、定期リリースしていくRedMicaに追随していこうと思います #redmineT #LycheeRedmine」 / Twitter

気になる点は、過去にRedmineをフォークしたChiliProjectのように、Redmineコミッタとギクシャクした関係になったりしないか、という点。
この辺りは、前田剛さんももちろん考えておられて対処している、という印象を持った。
Redmine本家に追随しながら、Redmineの発展を支援していく方向になるといいな、と思う。

【3】アカベコさんのRedmineテーマの開発も興味深い。
テーマは、RedmineのUIを手軽に改善できる手法の一つだ。
沢渡さんの「Redmineをお化粧する方法」という言葉がまさに的確と思う。

(1) akipiiさんはTwitterを使っています: 「お化粧の言葉がいいですね!RT @amane_sawatari: アカベコさん @akabekobeko の講演。「あなたも作れる!Redmineテーマ」 →CSSとJavaScriptでRedmineのUIをお化粧する方法 #redmineT」 / Twitter

SCSSやDockerコマンドの説明は、初心者にも分かる様にすごく丁寧に話されてる点が良かったと思う。

RedmineのUIが古い、UIが使いにくい、という話は以前からよくあがっていた。
Redmineテーマの種類が増えたり、テーマの開発が活発になることで、よりユーザフレンドリーなUIに進化できるきっかけになるといいなと思う。

【4】@akahane92さんの全文検索プラグインのお話は、過去のIT全般統制の事例、性能チューニングの話を振り返りながら聞くと思い出深い。

akipiiさんはTwitterを使っています: 「#redmineT @akahane92 さんは、7年前にRedmine によるIT全般統制の事例を紹介された。その後、性能チューニング、そして全文検索プラグイン開発、と着々とプロセス改善されてる。そういう経過を振り返るとすごいですね」 / Twitter

僕が理解したストーリーとしては、メーカー情報システム小会社の立場として、Redmineを社内システムのPJ管理基盤として導入し、IT全般統制も取り入れて、プロセス基盤を固める。
すると、Redmineが持つチケット管理機能やトレーサビリティの恩恵を受けた後、次に出てくる課題は、チケット40万以上の蓄積されたデータを活用して、ナレッジシステム化していくこと。
もちろん、Redmineが肥大化することで、性能チューニングの課題も出てくる。

そこに、全文検索プラグインを導入することで、Redmineのチケット、Wiki、果ては添付ファイルやSVN配下の文書に至るまで全文検索の対象になり、Redmineは真のナレッジシステムになったわけだ。

@netazoneさんが全文検索プラグイン導入のLTをしてくれたが、@akahane92さんの話を聞くと、単に全文検索プラグインを入れるだけでなく、ChuperTextによる形態素解析、検索Jobの設定などミドルウェアの設定もかなり多い。
つまり、全文検索の精度向上や性能チューニングの為に相当なノウハウが込められている点は注意。

【5】パネルディスカッション「チケットを切れる人切れない人/なじむ文化なじまない文化」にパネラーとして参加させてもらった。
沢渡さんのお話は非常に軽快で楽しかった。
沢渡さんの発言から刺激を受けた内容を話したいという気持ちが強すぎて、言いたいことの半分も話せず、あっという間に終わってしまい、消化不良感が残ってしまった笑。

akipiiさんはTwitterを使っています: 「経験に基づくので参考になります。RT @amane_sawatari: 経験から学ばない残念な組織「4つのない」 ?言わない ?既知か未知か判断できない ?記録しない ?クローズしない (パネルディスカッションでの沢渡のキーメッセージ サマリ) #redmineT」 / Twitter

akipiiさんはTwitterを使っています: 「#redmineT 今日は皆様ありがとうこざいました。いつも熱気があって元気づけられます。久しぶりのパネラーで、Redmine には組織の色が出る、一方Redmine 導入でチームが活性化し、メンバーの貢献意欲を引き出してRedmine が組織文化を変える時もある、話までしたかったのに時間切れで消化不良でした笑。」 / Twitter

自分が話したかった事をここで書き残しておく。

【5-1】Redmine導入の成功パターンは経験上2つある。
一つは、トレーサビリティの概念は経験済みであったこと。
つまり、すでに開発プロセスのイメージは僕の中で持っていたので、後はRedmineにプロセスを実装するだけだったので簡単だった。

ツールでプロセスを実装すべきか、プロセスを確立してからツールを導入すべきか: プログラマの思索

「Redmineによるタスクマネジメント実践技法」の感想を集めてみたpart17: プログラマの思索

もう一つは、システム保守のように、ルーチン作業と突発的作業が混在している環境だったこと。
こういう環境では、チケット管理ツールのような基盤がないと、正直仕事がやってられない。
沢渡さんはチケット管理ツールの特徴として「備忘録のようなもの」という発言をたびたびされていたが、システム保守の現場ではまさに備忘録の基盤が必要。
「備忘録」というキーワードは、@sakaba37さんもチケット駆動開発の説明でも使われていたので、既視感を感じた。

【5-2】チケットには「ストック」「フロー」という2つの特徴を持つ。
物理学における光が粒子と波動の二重性を持つのと同じように、チケットはフローとストックの二重性を持つ点が非常に重要と考える。

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

Redmineのチケット駆動開発では、チケットに複数の意味を持たせて運用した方が上手く回る: プログラマの思索

チケット管理の上手な人は、チケットをストックだけ、フローだけで回すのではなく、チケットという1個のインスタンスを状況に応じてストックで扱かったり、フローに見せたりして、2つの性質を同時に使わせようとしていると考える。
一方、Excel管理では、この二重性を持たせるのが非常に難しいので、上手く回らない。

WBS駆動チケットというアンチパターンは中身がスカスカのチケット、と紹介して、他のパネラーも共感してくれた。
チケットをトップダウンでフローだけで扱おうとして、ストックにならないから、中身がスカスカになってしまうわけだ。

【5-3】沢渡さんの話で、オフショアチーム連携では、チケット管理ツールとチャットツールの2つあれば回るという経験談が興味深かった。
NTTデータのお仕事のときは、自社製のITSやチャットツールで運用されていたらしい。

akipiiさんはTwitterを使っています: 「#redmineT 今日はお忙しい中パネルディスカッションありがとうございました。オフショアチーム連携では、チケット管理ツールとチャットツールの2つ有れば回ると言う話は共感しました。」 / Twitter

僕は、沢渡さんの考えでは、仕事をする環境では、タスクや課題を共有する基盤とリアルタイムにコミュニケーションする基盤が必要なのだ、と理解した。
沢渡さんの発言の中ではたびたび、口頭でのやり取りでは後に残らないので仕事にならない、チケットに残して安心して忘れるべきだ、と話されていたが、それを実現する基盤がそれらなわけだ。

今ならば、Redmine はストック、Slackはフローで役割分担するだろう。

akipiiさんはTwitterを使っています: 「@saito0119 #redmineT Redmine はストック、Slackはフローと言う役割分担ですね。」 / Twitter

個人的には、そういうチケットやコミュニケーションする環境を作るためには、心理的安全性という概念が重要になるだろうと思っている。
チケットには、課題やリスク、バグなど、プロジェクトの悪い話が出やすい。
そういう内容をどんどん見える化して、一つずつ解決する必要があるのに、悪い話を出すと周りから叩かれてしまう、という雰囲気では、チケットを切る文化は生まれない。
この辺りも同意してくれる人が多くて嬉しかった。

akipiiさんはTwitterを使っています: 「#redmineT パネルディスカッションのチケットを切る文化の話の中で、心理的安全性の言葉に反応してくれた参加者もいてくれて、嬉しかったな。チケットにはプロジェクトの悪い話が出やすい。そういう話題を1人が抱え込まずに見える化して、皆と共有できる場にしたい。」 / Twitter

【5-4】Redmineは組織に従う、という経験則があると思う。
特に、日本では、Redmineには日本の組織の色がすごくにじみ出る。
自分たちのプロセスに強いこだわりがあるため、Redmineのワークフローやトラッカーだけでなく、RedmineのUIや機能を組織に合わせようとして、カスタマイズして作り込んでいくパターンが非常に多い、と経験上感じる。
この点は、メリットなのか、デメリットなのか?も、参加者に問うてみたかった。

僕の考えでは、メリットもデメリットもある。
デメリットは、Redmineがカスタマイズされすぎた結果、Redmineの運用プロセスが複雑になりすぎてメンバーが使いにくくなること、VerUPの追随が難しくなることがあげられるだろう。
SAPなどの業務システムがいい例だ。

また、会社標準の単一Redmineを導入したとしても、複雑すぎて、現場に合わなければ、各チームごとに立てたRedmineインスタンスが乱立し、野良Redmineがはびこってしまい、標準プロセスから逸脱してしまう状況にもなるだろう。

だが、気象庁や田村さんの事例のように、各部署にRedmineインスタンスを配布して各部署に運用を任せた方が上手く回る、という事例もあった。
つまり、Redmineインスタンスは社内標準の1個がいいのか、各部署が複数個のRedmineインスタンスで個別運用したほうが良いのか、という課題が出てくる。
この辺りも、参加者に問うてみたかった。

一方、メリットは、Redmineが組織文化を変えてくれる場合があることだ。
既存のプロジェクト管理ツールのパッケージ製品には、その会社のプロセスが埋め込まれているので、自分たちのプロセスとフィットしない弱点が多い。
しかし、Redmineは非常に柔軟なので、自分たちの組織のプロセスにフィットさせやすいため、メンバーは慣れ親しんだやり方を変える必要がない。
Redmineの導入や普及の敷居は非常に低い。

すると、Redmineを導入することで、チームが活性化したり、オフショアチームとの信頼関係が強化されたりする場面がよく見られる。
マネジメント経験の浅いリーダーが、Redmineというツールを通じてプロジェクト管理を経験して成長する場面を僕も見てきた。
つまり、Redmineという一つのツールが、リーダーやチーム、そして組織を変化させていく力を持っている。
すなわち、Redmineは組織を変革する潜在能力を持ったツールなのだ、とみなせる。

むしろ、Redmineを導入したい人は、Redmineにそういう効果を期待しているはずだ。
そういうRedmineが人や組織を変化させるような話や事例をもっと集めたいし、聞いてみたいと皆思っているはず、と思っている。

【追記】
akipiiさんはTwitterを使っています: 「#redmineT チケットを切る文化の話が定着すると、次に出てくる問題が放置チケットやチケット棚卸しになる。ぼくはここがマネジメント層の腕の見せ所と考えてる。アジャイル開発はこの辺りのノウハウが上手いと感じる。」 / Twitter


| | コメント (0)

より以前の記事一覧