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

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)

2019/05/19

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

昨日の第16回東京Redmine勉強会の感想をラフなメモ書き。
疲れているのでラフなメモ。

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

第16回東京Redmine勉強会『Ver4に上げよう Redmineのさらなる進化と多用性!』 #redmineT (18ページ目) - Togetter

第16回redmine.tokyo勉強会 まとめ

redmine.tokyo 16 感想 - アカベコマイリ

redmine.tokyo 第16回東京Redmine勉強会に参加してきました。 - みずりゅの自由帳

「Redmine 4.1 新機能選抜総選挙」で紹介できなかった新機能 10選 - ファーエンドテクノロジー株式会社

【1】昨日のRedmine勉強会でちょっと嬉しかったことは、@rechiba3 さんに初めてお会いできたことと@ohnukiさんに5年ぶりにお会いできたこと。

akipiiさんのツイート: "#redmineT 東京Redmine 勉強会から離脱しました。講演者、スタッフ、参加者の皆様ありがとうございました?? 懇親会の参加率が約7割で50人で盛り上がりが凄いと思います。今回は7年越しに @rechiba3 さんとお会いできたのが収穫でした。ユーザー層も老若男女、開発者からPMOまで幅広くて来る度に面白い"

@rechiba3 さんの下記の資料を以前読んでBlogに感想を書いたことがあったので気になっていた。

TiDDでウルトラハッピーな開発フロー実践しちゃおう!

WebディレクターによるRedmine運用事例: プログラマの思索

また、@ohnukiさんは、5年前の勉強会が大雪だった時にLTで講演して頂いたことを覚えていたから。

第6回勉強会 - redmine.tokyo

他にも@MzRyuKaさんから、懇親会でこんな話もあって盛り上がった。

みずりゅさんのツイート: "#redmineT https://t.co/XfSENoynLn 初参加、どれも凄く楽しかったけど、あえて一番を選ぶとしたら懇親会でakipiiさんとお話しできたこと。 数年前に会社のブログで書いた記事を取り上げてもらったことに、やっとお礼を言うことができました。"

チケット駆動開発の運用例part4: プログラマの思索

BlogやSNSのおかげで、実際に会ったことがなくても、すぐに仲良くなれる。
そういう場をコミュニティが提供してくれて本当にありがたい。

【2】10個以上の講演があったので、記憶に残った所だけ書き残す。

【2-1】@netazoneさん「ある工場の Redmine バージョンアップ」では、プラグイン作者にVer4.0対応を自らお願いしまくった結果、そうなったからには自分のRedmineをバージョンアップしなくては、という行動に至った気概に強く共感した。
数多くの日本人プラグイン開発者が対応してくれたからこそ、Ver4.0に安心してバージョンアップできるからだ。

つまり、Redmine本体だけでなく、主要なプラグインがVerUpに追随することは、Redmineユーザにとって非常に重要な要素である、という事実を明示していると思う。
よって、RedmineコミュニティがRedmineプラグイン開発者を巻き込んでRedmineを盛り上げていくことは、非常に重要な活動なのだ、と改めて感じた。

【2-2】@agilekawabataさん「LycheeカンバンとRedmine運用の事例紹介」では、Lycheeプラグインの機能紹介が多くなってしまったけれど、メーカーのRedmine利用事例の話に興味を惹かれた。

akipiiさんのツイート: "#redmineT 複数案件を複数チームで進捗管理するにはどうする?メーカーなら、エンジンチーム、ボディチームなどの複数チームがあるが、トラックプロジェクトと乗用車プロジェクトの親チケットから派生した子チケットは、それぞれのプロジェクトで管理したい。"

例えば、自動車メーカーでは、トラックプロジェクト、乗用車プロジェクトの2つのプロジェクトが別々にある一方、エンジンチーム、ボディチームの2チームも別々にある。
トラックプロジェクトの機能(親チケット)には、エンジンチーム、ボディチームの開発タスク(子チケット)でぶら下がるが、チームごとのプロジェクトで扱いたい。
理由は、チーム単位のタスク管理がしたいこと、各プロジェクト単位で他者には情報を見せたくないことがあるから。
現状の標準Redmineでは、Redmineプロジェクトを跨ぐ親子チケットや関連チケットは作ることができるので、ある程度は運用できるだろうが、もっと細かなニーズを実現して運用する場合は、色々問題が噴出するだろう。
おそらく、それら問題となる利用シーンでは、Redmineのカスタマイズやプラグインによる機能拡張が必要になるだろうと想像する。

つまり、複数プロジェクトと複数チームのタスク管理を横串でプロジェクト管理する手法を、Redmineが支援できる可能性がある。
そうすれば、組織をまたいだ複数案件のPJ管理のように、より大規模なPJ管理もRedmineがカバーできるようになるだろう。
本来、Redmineという一つの箱にWF型開発案件もAgile案件もデータが格納されているので、横串のデータ集計はRedmineのようなチケット管理ツールが得意な所。
その機能をさらに大規模なPJ管理にも適用していくには、Redmineにどんな機能が標準で必要になってくるのか、という問題を提起してくれた点が面白かった。

【2-3】@yassan168さんのLTでは、クラウド上でDockerを使って、Redmineを含めたサーバー構築を行った、という点が興味を惹いた。
Redmineサーバーだけでなく、リバースプロキシやDNS設定などは、オンプレサーバー上のインフラ構築作業と全く同じなのに、クラウドの方がものすごく簡単に構築できるわけだ。
オンプレミスのインフラ構築は、本当に面倒な作業だった。
たとえば、iptableをいじったり、hostsをいじったりしていたから。

しかし、@akabekobekoさんと話しながら、簡単に構築できる理由は、DockerでOSに依存しないミドルウェアの構築ができるので、後はそれらをつなぐ構成をすればいいだけ、ということで理解した。
よって、今後はAnsibleよりもDockerの方が有用だろうという気がした。

【2-4】hin-tさんのLTでは、定期的にチケット登録するプラグインを紹介していた。
営業事務の定形業務で、物忘れせずに役立つんですよ、という発言があった。
どのプラグインか忘れたので後で探しておく。

定期的なタスクをチケット登録するRedmineプラグイン: プログラマの思索

【2-5】石川さんのLTでは、message_customizeプラグインが興味を引いた。
このプラグインは、ymlに書かれた文言を修正して表示できること。
メリットは、ymlを書き換えなくても、管理画面で修正できるので、viewCustomizeプラグインに似た感覚で管理者が操作できることだろう。
すると、@netazoneさんが発した問題「海外ユーザと1個のRedmineインスタンスを共有する時、ステータスやトラッカーを日本語・英語で併記しない方法はあるか?」に対応できないか、考えてみたくなる。
一方、@g_maedaさんの話では、Redmineの画面をリロードしたらhtmlからlang=ja,enは取得できるので、その情報を元に、ログインユーザ毎に修正文言を表示できるはず、と言っていた。
たぶん、message_customizeプラグインとviewCustomizeプラグインを駆使すれば、その問題は解決可能だろうと思う。

GitHub - ishikawa999/redmine_message_customize: This is a plugin for Redmine.

GitHub - onozaty/redmine-view-customize: View customize plugin for Redmine

【2-6】堂端さんのLTでは、Redmine大阪で話したGitHub連携プラグインの続きだった。
興味を引いたのは、RedmineチケットとGitHubブランチを紐づけた後、Github上でプルリク受付、プルリク承認、masterマージという一連の作業ごとに、Redmineチケット一覧画面でチケットのアイコンが更新される機能があったこと。

つまり、GitHubからRedmineへフックさせているわけだ。
裏では、GitHubのクローンがRedmineサーバー上にあるので理解できるが、Redmineチケット一覧でプルリクのステータスをアイコンで判別できる機能は良いな、と思った。

但し、RedmineチケットとGitHubブランチを紐づける時に、「xx@#チケット番号」のようにブランチ名にプレフィックスを付ける手順がいる点は注意。

GitHub - agileware-jp/redmine_github

【2-7】@miokakusuさんのLTでは、MSのVisualStudioからTFSへチェックインする時に、Redmineチケットと同期させる仕組みを作った事例。
TFSの通知メールからRedmineとREST APIで連携する処理が面倒ですね、という話が興味を引いた。
仕掛けについては、@ryouma_nagareさんからアドバイスをもらったので理解できた。

akipiiさんのツイート: "#redmineT TFSの通知メールをRedmine がキャッチして、RESE APIで、チェックインとチケットを紐づけた。ごめん、この辺りがよく分からない。"

りょうま@redmine.tokyo終了でRedmineロスさんのツイート: "ですね。 メールサーバで受信したメールを標準出力でスクリプトが受け取る 本文解析して、チケット番号、内容、ステータスを生成 REST APIでRedmineサーバにアクセス です。メールサーバかRedmineに同居している必要もないです… "

【2-8】@naitohさんのアンケート集計では、Git利用率が下がっている点が気になった。
たぶん、Git中心で開発する場合、GitHubやGitlabだけの運用に流れているのかもしれない。
つまり、RedmineとGit連携の機能が弱い点は、今後、Redmineの弱点になってくるかもしれない。

【3】@ohnukiさんから、コミュニティ運営を褒められたことは一スタッフとして嬉しかった。

Hiroshi Ohnukiさんのツイート: "久しぶりの参加、第一印象ですが運営が素晴らしい #redmineT"

【4】Redmineコミュニティに関わって8年経つが、なぜRedmineコミュニティを継続できたのか、とふと疑問に思う。
僕はコミュニティ経験がまだ浅いけれども、過去を振り返ると、コミュニティの浮き沈みはとても激しいと感じる。
長期に渡って熱気を維持できるコミュニティは正直多くない。

その理由は、Redmineというツールが、日本における市場の潜在ニーズをうまく汲み取ってきたから、ではないかと考えた。
つまり、日本の官公庁や大企業における非効率な業務にRedmineが当てはまるケースが多いのだろう、と考える。

たとえば「プラットフォーム革命」にはこんな一節がある。
プラットフォームビジネスの機会を見つけるには、「取引コストが高い所」「複雑で見過ごされているネットワーク」「大規模で分断された未活用な資源がある所」に注目せよ、と。

この言葉を念頭に置いて、以前、CoderDojoの関係者と話していたら、まさに日本の教育業界はとても非効率な業界なので、ベンチャー企業が参入しやすいという印象を受けた。
実際、日本の学校ではIT化が進んでおらず、プログラミング教育や英語教育などの外部環境の大きな変化に揺さぶられていて、教育者だけで自力解決できず、袋小路になっている印象だ。
そんな非効率な業界だからこそ、CoderDojoなどのITコミュニティやITベンチャー企業はちょっとした改善ツールを導入するだけでも、すごく通用する。
そういう話を聞きながら、CoderDojoは本当に良いマーケットを持っているなあ、今後しばらくはその業界でビジネスをやっていけるだろう、という印象を持った。

同様に、日本の官公庁や大企業は、メールやExcel帳票の文化で凝り固まっている現場が多いので、昨今の最先端のIT企業から見れば、非効率極まりない利用シーンが非常に多く見受けられるだろう。
だからこそ、そういう業務にRedmineを単純に導入するだけでも、それなりの改善効果を得やすい状況があるのだろう、と思う。
よって、そういう非効率な市場が残っている限り、まだ今後しばらくは、Redmineは日本で根付いていくだろうと思っている。

| | コメント (0)

2019/02/03

クラウド(対立解消図)の考え方

クラウド(対立解消図)を誤解していたので、ラフにメモしておく。
自分用の参考リンク。

【参考】
ジレンマ解消! TOC思考プロセスの基本を学ぶ(2):社内の対立を解消するツールとその使い方を伝授 (1/3) - MONOist(モノイスト)

クラウド(対立解消図)の書きかた | 問題解決・悩み相談アプリサイト【sekasuku】|TOC思考プロセスのWebツール

クラウド(対立解消図)とは、「問題を正確認識するために、コンフリクトを明確にする」ツールだ。
「クリティカルチェーン」の一節にこんな文章がある。

(引用開始)
TOCでは、サイエンスで用いられる定義を使用します。
「問題を正確に認識する」ということは、2つの必要条件の間にコンフリクト、つまり対立点があることを示すことです。
コンフリクトを示すことができなければ、問題を正確に認識したとは言えません。
(引用終了)

(引用開始)
サイエンスの世界ではコンフリクトが発生した場合いったいどうするのでしょうか。
科学者のリアクションは、私達のとはずいぶん違います。
私達は、何とか折り合いのつくところで妥協点を見出そうとしますが、サイエンスではそんな考えは微塵たりとも起こりません。
スタート地点からして違うのです。
妥協を全く許さないのです。
この世の中にコンフリクトなど存在しないと考えるのです。

二つの方法がともに広く認められている方法だとしても、科学者は本能的にいずれかの方法に問題がある、論理上の仮定が間違っていると結論付けるのです。
そうした時、彼らは、間違った仮定を探して修正することに全精力を注ぎ込みます。
(引用終了)

クラウドが何らかの対立を図示していることは知っていたが、問題の構造を明確にするために使うのが目的だった、という点まで腹落ちしていなかった。
なるほど、確かにこの考え方ならば、同じ目的の手法なのに、2つの方法で全く違う結果が出たとしたら、どちらかの方法が間違っていることが分かる。
そこで、背理法のように、前提が間違っているからおかしな結果が出てきたのだ、と考えることができるわけだ。

| | コメント (0)

2018/12/10

チケット駆動開発のアイデアがRedmineへ与えた影響は何か

この記事は Redmine Advent Calendar 2018 の12月25日分です。

Redmine Advent Calendar 2018 - Adventar

チケット駆動開発というアイデアがRedmineに与えた影響を改めて考察してみる。
以下はラフなメモ書き。

【1】チケット駆動開発の発端とは?

Redmineを導入運用する時、「チケット駆動開発」という言葉を使う場面がある。
既に、さかばさんがチケット駆動開発の由来と経緯について書かれている。

TiDD:チケット駆動開発: ソフトウェアさかば

必然から生まれたチケット駆動開発 - XP祭り関西2009 その3-: ソフトウェアさかば

チケット駆動開発の概念は、2007年にTracのチケット管理から生まれた。
その素朴なアイデアは、「チケット無しのソースコミット不可」「No Ticket, No Commit」。

2008年頃、そんなチケット駆動開発のアイデアをRedmineで試してみたら、XPに基づいたアジャイル開発に適用できることに気づいた。
そんな僕の経験を熱く語っていたら、さかばさんが「チケットはXPのタスクカードと同じ」と上手くまとめてくれた。
この言葉がヒントになって、Redmineによるチケット駆動開発を運用した時のPJ管理の技法、チームビルディングの技法に対し、既存の専門知識を片っ端から適用してみた。
たとえば、アジャイル開発、ソフトウェア工学、PMBOK、ITIL、品質管理、など。
そういうアイデアを専門知識で補強することで、より理解が深まる一方、理論はそのまま適用できず、効果を出すには前提条件や制約条件が色々あることにも気づいた。

【2】チケット駆動開発はどのように定義されているのか?

【2-1】Redmineでチケット駆動開発を実践した時のプロセスをフレームワーク化する試みは、下記から始まった。

脱Excel! Redmineでアジャイル開発を楽々管理 (1/5):エンジニアがお薦めする 現場で使えるツール10選(3) - @IT

【公開】KOF2008講演資料「Redmineでチケット駆動開発を実践する~チケットに分割して統治せよ」: プログラマの思索

【2-2】チケット駆動開発をアジャイル開発プロセスとみなした時の運用サイクルは以下になる。

1・プロジェクトで発生するタスク、課題、障害は、「XPのタスクカード」とみなし、全てチケット化する(Ticket First)。
チケットは作業指示書であり、課題管理票、障害管理票でもある。

2・それらチケットは、リリースするタイミングで、Redmineのバージョン単位にグループ化する。
Redmineのバージョンは、XPのイテレーション、Scrumのスプリントに相当する(Iteration is a version)。

3・リリースまでのPJ管理は、Redmineの優れたチケット集計機能、構成管理ツール連携機能でリアルタイムにモニタリングすることで実現する。
「No Ticket, No Commit」で、ソース修正履歴は全て、チケットで把握できる。

4・Redmineのバージョンの進捗が100%になったらリリースする。

5・リリース後、チームはふりかえりを行うし、顧客からの改善要望を収集して、次のイテレーション計画へフィードバックして再修正する。

【2-3】上記によって、チケット駆動開発によって明確になったプロジェクト運営のやり方は2つある。

一つは、プロジェクト内で発生するあらゆる作業や課題などをチケットに記録することで、プロジェクト運営はチケットのライフサイクルに置き換えられること。
もう一つは、RedmineバージョンをXPのイテレーション、Scrumのスプリントと同一視することで、Redmineのロードマップ機能は、長期のリリース計画と短期のイテレーション計画に置き換えられること。

つまり、プロジェクト運営の日々の作業は全てチケットでリアルタイムに追跡できるし、それらチケットはRedmineのロードマップ機能など数多くの優れた機能で、プロジェクトの長期の計画づくりにも使えるようになった。
すなわち、チケット駆動開発の概念をRedmineに導入することで、プロジェクト運営の全ての管理プロセスをコントロールできるようになるメリットがある。

【2-4】では、このメリットによって、PJ管理技法がどのように変化するのか。
僕がチケット駆動開発で運用した時に、プロジェクトリーダーとして一番意識したことは「チケットの取捨選択」だった。

プロジェクト運営では、日々数多くのチケットが発生し、計画当初のタスク以外に、納期までに収まらないタスクが発生する。
それらチケットを1つずつ精査し、対策を打ち、1つずつ潰していかなければならない。
見て見ぬふりして放置しても、悪い状況は何も変わらないから。

すると、ガントチャート保守という面倒な作業が必ず発生し、その作業に多大な管理工数を取られて、悪循環に陥る。
一方、チケット駆動開発では、ガントチャートは所詮、1個のビューに過ぎない。
ロードマップ、チケット一覧、カレンダー、かんばん、EVM、リソースヒストグラムなどのビューをチケット集計機能として実現できるし、それらでモニタリングすればよい。
1個のビューにこだわらず、必要な状況で必要なビューを使い、手を打てばよいのだ。

それら機能を使っていくと、バージョン単位にグループ化したチケット群を精査して、優先度の高いチケットから一つずつ潰していくようになる。
もちろん、それらチケットは時々刻々変わるが、Redmineの優れたチケット集計機能で把握できるので、プロジェクトリーダーの意思決定を支援できる。
すると、チケットを分割して次バージョンへ延期したり、捨てる意思決定が多くなると思う。
「直近の納期までに何が必要なのか」をプロジェクトリーダーに徹底的に考えさせる基盤をチケット駆動開発は提供してくれるからだ。

つまり、PJ運営を「チケットの取捨選択」というミクロな意思決定に落とすことが、実はマクロな観点のPJ運営を実現しているわけだ。

【3】チケット駆動開発の具体的な特徴は何か?

チケット駆動開発をRedmineで実装すると、下記の3つの特徴が見えてくる。

チケット駆動開発の戦略: プログラマの思索

【3-1】Redmineの優れた構成管理連携により、要件からソースコードまでのトレーサビリティのインフラが整う。これにより、Redmineは本来の(真の)構成管理ツールとして実現される。

「チケット無しのコミット不可」の運用ルールにより、チケットとソースが密関係で相互リンクされる。
つまり、チケットが作業指示書であれば、チケットを発生させた要件や仕様書からソースやビルドモジュールまで、相互にリンクで遷移でき、追跡可能になる。
よって、要件からビルドモジュールまでのトレーサビリティを理論上は実現できる。

過去のソフトウェア工学の書籍を読むと、トレーサビリティの重要性は謳っているが、その実現方法はExcel台帳でソースやバージョンを管理するなど非常に面倒に思えた。
他方、Redmineであれば、事実上、トレーサビリティを実現できる「真の」インフラになりうる。

また、Redmineはツール連携できるI/Fを持っているので、GitやJenkinsなど数多くのツールと連携すれば、「プロジェクト管理サーバー」なるものを実現できる。
つまり、PMBOKの言う「PMIS(プロジェクト管理システム)」を初めて実現できる。
僕は、PMBOKが目指していたものは、たぶん、こういうインフラが前提であって初めて理解できるのではないか、と思った。

そして、このアイデアは、ソフトウェアプロダクトライン(SPL)にもつながっていく。

さらに、チケット管理システムはソース管理と同じように、作業のUnDo、ReDoを行う為のリポジトリとみなすこともできる。

チケット管理システムは作業の構成管理と同じ: プログラマの思索

【3-2】Redmineの優れたワークフロー管理機能により、プロジェクト管理のフレームワークへ昇華・汎用化できる。

Redmineのワークフロー設定画面が意味するものは、三位一体論だ。
つまり、業務フローというアクティビティ図、ワークフローの状態遷移図、ワークフローの状態遷移表という3つの機能は、Redmineの1つの機能として実現される。

よって、PJ運営に出てくる全ての業務フロー、開発プロセスは、事実上、Redmine上で全て実装できる。
このアイデアにより、Redmineでは、WF型開発も、Agile開発も共存して運用できるメリットが出てくる。
もちろん、PMBOK、ITIL、サポートデスク、会議体管理、PC資産管理など、ソフトウェア開発以外の業務にも適用できるようになる。
ここが、Redmineの運用で一番面白く、そしてホットな部分だろうと思う。

【3-3】チケット集計結果をソフトウェア・リポジトリ・マイニングによって、色んな角度からメトリクスを採取して、プロセス改善の材料にできる。

Redmineに蓄積された過去の大量のチケットは、データマイニングの宝庫だ。
PMOや品質保証部にとって、ソフトウェア工学のメトリクスを実際に研究できる元ネタになりうる。
信頼度成長曲線というメトリクスも、こうやって作るのか、ということも初めて体験できた。

しかし、実際は、チケットの内容が詳細に記載されていないと、なかなか理論通りのメトリクスが得られないことも分かった。
他方、PMBOKのEVMやリソースヒストグラムは、こうやって実装できるのか、ということも体験できた。

チケットと言う一つのデータが蓄積できれば、PJ管理で使われるビューのうち、既存の理論をRedmineで簡単に実装できる。
さらに、Redmineは柔軟でカスタマイズしやすい特徴を活かせば、新たな観点のPJ管理のビューを生み出す可能性があるはずだ。

【4】チケット駆動開発で最も面白い特徴は、「チケットはストックとフローの二重性を持つ」ことだ。

Redmineによるチケット駆動開発はストック型プロセスとフロー型プロセスの二面性を持つ: プログラマの思索

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


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

チケットはタスクカードであるから、フローとして流れる「流通媒体」。
一方、チケットは障害管理票、課題管理票でもあるから、ストックとして蓄積される「記憶媒体」でもある。

この2つの特徴が混在しているので、チケットの粒度を標準ルールでガチガチに定めるのは難しくなる。
なぜなら、流通媒体のチケットは細かくなるし、記憶媒体のチケットはどうしても大きくなりがちだから。

また、1つのチケットという実体は、ステータスが変更されるたびに、流通媒体と記憶媒体に性質が変わる特徴も持つ。
たとえば、タスクのチケットはフローとして流れるが、途中で仕様変更やらソース修正の内容など、ストックの内容が蓄積される。
他方、障害管理票のチケットは、当初は障害内容や対策を詳細に書いてストックとして蓄積されるが、テスターと開発者の間でやり取りする時、チケットはフローとして流れる。
そのおかげで、チケットはキャッチボールのような雰囲気になる。

つまり、チケットは障害や仕様変更の内容をストックして持つ一方、チケットで進捗管理でき、ワークフロー設定に沿って変更管理が自然に行われる。
すなわち、チケットは、データマイニングの元ネタやナレッジ基盤となる「記憶媒体」の側面と、進捗管理や変更管理などを回す「流通媒体」の側面が既に埋め込まれている。
よって、チケットの粒度に悩むよりも、このチケットの二重性を意識して運用したり、その特徴を活かすように知恵を絞る方が良いと思っている。

【5】チケット駆動開発の今後の課題は何か?

課題は3つあると思う。
一つ目は、チケットの粒度、チケットの完了条件について、考え方を整理すること。
チケットの粒度は、ソフトウェアの本質的な複雑性に由来すると考えているので、それを逆手に取って、ソフトウェアの本質をチケット駆動開発で探ることもできるはず。

チケット駆動の罠~複雑さはチケットの粒度に関連している: プログラマの思索

TiDD初心者から必ず聞かれる質問~「チケットの粒度」と「チケットの完了条件」 #47redmine #redmine: プログラマの思索

チケットの粒度と進捗ビューの関係: プログラマの思索

2つ目は、チケット駆動開発で実装できるプロセス基盤の種類を整理し、それらプロセスの特徴・メリット・デメリット・プラクティス・アンチパターンを明確にすること。
たとえば、WF型開発、Agile開発、PMBOK、ITIL、サポートデスク、PC資産管理、など。

Redmineが今後発展する方向のアイデア: プログラマの思索

Redmineが今後発展する方向のアイデアpart2: プログラマの思索

3つ目は、チケット駆動開発と組織の関係を整理し、「組織がチケット駆動開発をどのように複雑化させるのか」「チケット駆動開発は組織にどんなメリットをもたらすのか」を明確にすること。

第15回東京Redmine勉強会の感想~Redmineの2つの顔が相異なる2つのユーザ層を生み出している #redmineT: プログラマの思索

大規模組織におけるRedmineを巡る諸問題~組織構造がRedmineに与える影響: プログラマの思索

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

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

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

Redmineとチケット駆動開発は表裏一体と思っているので、Redmineを使うことで、色んな実験ができると思う。
それらアイデアを試してみたい。


| | コメント (0)

2018/12/03

ソフトウェア開発に心理学や行動経済学の概念を適用した記事のリンク

ソフトウェア開発に心理学や行動経済学の概念を適用した記事がとても素晴らしいので、リンクしておく。
このアイデアを育ててみたくなった。

【参考】
ソフトウェア開発に役立つ 心理学的現象、行動経済学の概念など 15題 - Qiita

ソフトウェア開発に、製造業や生産管理のベストプラクティスを適用しても、あまり有効でない。
むしろ、認知心理学や行動経済学の知見を適用して、開発者の心理や開発チームの行動に着目した方が、うまくコントロールできるのではないか。
そんな感触をずっと持ち続けてきた。

上記の記事はまさにピッタリ。
そう、こういう記事が読みたかった。

現場の開発者や開発チームは、独自の存在であり、全ての存在が同じではないけれど、それらの行動を現象として見ると、驚くほど共通的な特徴が見つかる場合も多い。
そういうバラバラな共通的な現象を、的確な概念でその本質を表現できればいいのに、と思っていた。

たとえば、認知心理学の概念として、認知的不協和、グループシンク(集団浅慮)、リスキーシフト(リスク志向の集団極性化)、コーシャス・シフト(安全志向の集団極性化)、有能性の罠(competency trap)、訓練された無能、などがある。
それらを実際にソフトウェア開発に適用してみれば、当てはまる事例は多いのではないか?

具体的には、要件定義で数多くの利害関係者の意向を取り入れると、本来は業務を刷新する革新的なシステムを導入するはずだったのに、現状の業務の焼き直しに過ぎないリプレース案件になってしまった、という事例は、コーシャス・シフトの一例ではないか、とか。

僕は、認知心理学の概念の適用も面白いと思うが、行動経済学の概念を適用する方が面白いと思っている。
経済学の基本理念「限られた資源を有効活用する」ことは、ソフトウェア開発でもまさに同じだ。
優れた開発者、優れた開発チームという唯一無二の資源をいかに有効活用して、ビジネス価値を作り出すか、という目的と一致するからだ。

たとえば、技術的負債やリファクタリングは、時間割引や割引価値の観点で説明できるだろう。
犠牲的アーキテクチャは、埋没価値(サンクコスト)や機会原価の観点で説明できるだろう。
意固地な言動は、バイアスで説明できるかもしれない。

アドレナリンジャンキー」にあるプロジェクト管理のアンチパターンも、認知心理学や行動経済学の知見で整理して説明し直すと面白いかもしれない。

プロジェクト管理のアンチパターン集~アドレナリンジャンキー: プログラマの思索

| | コメント (0)

より以前の記事一覧