Redmineのチケットパネルプラグインが待ち遠しい

チケットパネルプラグインの記事があったのでラフなメモ。
リリースされたら使ってみたい。

【参考1】
新機能「チケットパネル」 プロジェクトの状況を視覚的に捉え、ドラッグ＆ドロップで直感的に操作 | My Redmine

チケットパネル（Issues Panel) | My Redmine

新機能「チケットパネル」 プロジェクトの状況を視覚的に捉え、ドラッグ＆ドロップで直感的に操作 | My Redmine

プロジェクト管理クラウド『My Redmine』に新機能「チケットパネル」 プロジェクトの状況を視覚的に捉え、ドラッグ＆ドロップで直感的に操作｜ファーエンドテクノロジー株式会社のプレスリリース

チケット管理をやるからには、かんばんのような機能は是非とも欲しい。
タスクを一覧表示するよりも、ドラッグ・アンド・ドロップでチケットを操作できる機能が欲しい。
かんばんならば、一目見るだけで、タスク量や作業負荷を直感的にイメージしやすい。

アジャイル開発では、かんばんによるタスク管理の手法は随分前から研究されて、かなりやり尽くした感がある。
「リーン開発の現場 カンバンによる大規模プロジェクトの運営」では、かんばんをソフトウェア開発の工程管理にカスタマイズして運用する事例だった。

Redmineでかんばんプラグインを使うメリットは、その他のチケット集計機能も併用することで、進捗・品質・コストなどの観点で多面的にモニタリングできる点だ。
１日に数枚以上のチケットが作成されて流れていく場合、かんばんビューの方が、リアルタイムな動きが見える化されて、分かりやすい。

一方、ガントチャートのビューでは、イナズマ線を表示すれば、どのタスクが遅れてるのか、一目で分かる。
他方、ロードマップのビューを見れば、マイルストーンでもあるバージョン単位の進捗率が表示されるので、ゴールまで後どれだけ残っているのか分かる。
サマリのビューを使えば、担当者・カテゴリ・トラッカー・バージョン・ステータス単位ごとに、全チケットの枚数が表示されるので、健康診断の血液検査みたいな感じに見える。

かんばんによるタスク管理は、見ていて楽しい。
かんばんはチケット集計機能の一つに過ぎないけれど、Redmine初心者がチケット管理ツールに触る敷居を下げてくれるメリットがあると思う。
こどもRedmineテーマとかんばんを組み合わせたら、小中高生のタスク管理にも使えると思う。

【参考2】
My Redmine インストール済みプラグイン | My Redmine

（引用開始）
My Redmineでは、厳選した以下のRedmineプラグインがご利用になれます。プラグインにより標準のRedmineの機能が拡張され、活用範囲が一層広がります。

Issue Templates - チケット新規作成時のテンプレートを登録
View Customize - CSSとJavaScriptによる画面カスタマイズ
メッセージカスタマイズ - 画面の文言をカスタマイズ
My Page Blocks - マイページを拡張
チケットパネル - チケットをかんばん風に表示
（引用終了）

@g_maedaさんが厳選したプラグインという風に見てしまうので、上記プラグインはRedmine利用者にとって推奨なのかもしれない。

Redmineのチケット管理はフロー型とストック型で運用方法が異なる

Redmineのチケット管理は、フロー型とストック型で運用方法がどのように違うのか、考えてみた。
ロジカルでない、ラフなメモ書き。

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

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

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

【1】フロー型のチケットは、チケット集計機能で見える化したい気持ちがその背景にある。
プロジェクトリーダーの場合、メンバーに個別に進捗状況を問い合わせるのではなく、Redmineを通じてリアルタイムに状況を把握したい。
だから、メンバーが自身の最新状況をチケット入力してくれれば、彼らの作業にプロジェクトリーダーが介入する必要はない。

チケット属性があれば、色んな見せ方がある。
たとえば、ガントチャート、ロードマップ、カレンダー、サマリーなど。
つまり、フロー型のチケットでは、チケット全てを集計して、進捗や品質、コスト状況、障害、課題などの状況をリアルタイムに把握したい。
そうすることで、プロジェクトリーダーは、今どの部分でプロジェクトの進捗が遅滞しているのか、どこにボトルネックがあるのか、をいち早く察知して、対処したいのだ。

つまり、フロー型チケットでは、ステータス、トラッカー、開始日・終了日、予定・実績工数、カテゴリ、バージョンなどの属性項目が重要だ。
それらの属性を用いて、進捗・品質・コストなどの色んな観点で見える化したいから。

最終的には、プロジェクトリーダーは、顧客や上司に対する進捗報告は、Redmineのチケット集計機能で代用したい欲望があるはずだ。

チケット駆動開発は進捗報告作りをどのように解決しようとするか？: プログラマの思索

【2】一方、ストック型のチケットは、入力のしやすさが大事。
チケットの属性項目よりも、チケットの説明欄が重要だ。
Issueテンプレートプラグインはまさにそう。
チケットの説明欄をテンプレート化することで、たくさんの情報を書き込んでいく。

すると、蓄積したチケットを後から検索して、必要な時に取り出したくなる。
過去の障害や問い合わせはどうだったっけ？
なぜ、こんな複雑なパッチを書いたのか、その意図は何か？

つまり、全文検索機能も大事。
蓄積したデータをいつでも取り出せるようにする。
これは、全文検索プラグインで解決できる。

すなわち、ストック型チケットでは、チケットの説明欄への入力と、その情報を強力に検索できる機能が必須だ。
おそらく、サポートデスクやシステム運用保守チームでは、日々の進捗管理も重要だが、作業記録を残してナレッジを蓄積していくことが大事だろう。

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

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

Redmineの全文検索プラグインでついに類似チケット機能が実装された: プログラマの思索

第19回Redmine大阪の見所 #redmineosaka: プログラマの思索

【3】では、フロー型とストック型の運用スタイルは、Redmineではどの機能に対応付けられて、どのように運用されているのだろうか？

実はRedmine は、ストック型の機能が多い。
チケット以外にも、文書、ファイル、Wiki、フォーラムなど。
しかし、Wiki以外は、これら機能はあまり使われてないように思える。

チケット管理がフロー型の場合、Redmineのストック型の機能を別に使ってる場合が多い。
たとえば、ソース管理、Wikiとか。

たとえば、作業の構成管理はチケット、成果物の構成管理はソース管理で行うとうまくいく。
ISO9001のシステム監査をはたから見ていると、余計にそう感じる。

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

たとえば、チケットの代わりに、Wikiがストックのイメージ。
Wikiに書かれるものは、たとえば、新規メンバーが加入した時に必要な環境構築、設計情報、技術情報のポータル情報とか、案件で定期的に実施されるふりかえり（KPT）の内容、顧客打合せや内部打合せの議事録、など。

あるいは、過去の障害や課題などのチケットから蒸留した情報をWikiに書く時が多い。
すなわち、システム開発やシステム保守で得られたナレッジをWikiにまとめて、メンバーは誰でも共有できるようにしたい。
そういう運用が自然に回れば、自分たちでシステム開発を改善していく雰囲気が醸し出されるはず。

一方、議事録をチケットにするのはストック型の運用だ。
だから、議事録をWikiにする人は、チケットをフロー型で運用している。

議事録の運用に優劣があるのではなく、チケットをフロー型で意識しているのか、ストック型で意識しているのか、で使う機能が違うだけだ。

【5】まとめると、フロー型はチケット集計機能によるプロジェクトの見える化を重視し、ストック型はチケットの入力や全文検索の機能を重視する。

現状のRedmineの機能を見ると、チケット集計機能は機能改善がすごく多い。
たとえば、ガントチャート、ロードマップ、サマリ、チケット一覧などの画面は、UIや機能も含めて、頻繁にパッチが当てられている。

【5-1】最近のRedmine本家のチケットで気になる機能改善は、カレンダーのUIをHorizontalだけでなく、Vertical list layoutでも表示できるようにしたい、という内容だ。

Feature #33682: Calendar UI proposal (Vertical list layout) - Redmine

#33682の添付画像を表示。

カレンダー画面は正直あまり使われていなくて残念に思っていた。
上記のVertical list layoutが実現できると、縦列は日付、横列はユーザごと・トラッカーごとで表示できる可能性がある。
そうすれば、かんばんに近い感じのUIになって、別の使い道が生まれるだろうと期待している。

あるいは、縦列に日付、横列に時間帯を付ければ、GoogleCalendarの代わりにもなる。
特に、システム保守チームでは、1日でこなすべきチケットを、ガントチャート画面ではなくカレンダー画面で見たいはず。
そういう使い方がしたい要望があれば、カレンダー画面をもっと改善できるはず。

一方、ストック型の機能はあまり機能改善が見られないように思える。
たとえば、Wiki、文書、ファイル、フォーラムなどの機能は、あまり進歩がない。

【5-2】個人的には、RedmineのWikiは仕様書になるように、もっと機能が欲しい。
たとえば、Wiki のサイトマップを自動生成して欲しい。
あるいは、WordなどのOfficeで書くUIの機能をもっとWikiに実装して欲しい。
つまり、WikiはWordやExcelの代わりに書けるもの、という運用を根付かせたい。

以前、Jiraの人に聞いたら、JiraではExcel設計書などの構成管理は考えていない、それら仕様書はConfluenceというWikiで代用できるはずだと考えているから、と聞いたことがあった。
つまり、Jiraでは、設計書はExcelで書いて、Gitで構成管理するのではなく、Wikiに直接書いてしまい、Wikiの履歴管理機能で蓄積できるはず、という設計思想らしい。
同様に、Redmineでもその設計思想は実現できるはずだ。

そうすれば、Redmineをプロジェクト管理ツールとして採用したシステム開発案件では、ExcelやWordなどのOfficeを全て排除できるはず。
ソースコードはGitで管理して、Remdineと構成管理ツール連携をすればいい。
設計書だけでなく、議事録や進捗報告の類も、全てWikiにしてしまうことで、全文検索プラグインでいつでも欲しい情報を取り出せるようになる。
納品物として必要ならば、一括PDFで出力してしまえばいいだけだ。

【5-3】文書機能もまだまだ可能性があるはず。
DMSFプラグインがRedmine本体の文書管理機能を乗っ取ってしまった感じだが、本家の機能ももっと改善したい。

【5-4】そんなことを思うと、Redmineにあるフロー型の機能やストック型の機能はどんなものがあるのか、それら機能に欠点があるならばどんな改善をすればいいのか、を考えたい。
つまり、Redmineの本来のあるべきフロー型やストック型の機能は何なのか、をもっともっと妄想しながら考えてみたい。

第21回 Redmine大阪の感想 #RedmineOsaka

第21回 Redmine大阪で初めて実施したオンライン勉強会が無事に終了しました。
参加者、講演者、スタッフの皆さん、お疲れ様でした。

【参考】
第21回 Redmine大阪 Online - connpass

Redmine-osaka-021 - Redmine.Osaka

第21回 Redmine大阪 Online(2020/7/11) - Togetter

RedmineOsaka 2020 夏の陣｜makoto0119｜note

第21回Redmine大阪でみんなの苦労と工夫を知る　#redmineosaka | マドびっ！ Madosan's View

【1】Redmine大阪は4月から2回延期してようやく実現できたので、スタッフの立場ではとにかくホッとした。
この3ヶ月間、世間では色々あったし、コミュニティは全てオンライン配信に変わってしまった。
そんな中、アジャイルウェアさんがZoomウェビナーを提供してくれて、redmine.tokyoのスタッフ2人が配信を手伝ってくれて、そして、3ヶ月以上も待ち続けてくれた参加者がいて、初めて無事に終わった。
特に今回は、関西在住の人達よりも、東京など遠方の参加者が多かった。

そういうことを思うと、Redmineコミュニティはすごく熱気があっていいなと思う。

勉強会の講演で興味を惹いた点をラフなメモ書き。

【2】前田さんの発表では、RedMicaに3つのプラグインを推奨プラグインとして取り込んで、開発者にフィードバックする発表があった。
それは、Issue template plugin, View Customize plugin, message customize pluginの３つ。
いずれも日本人が開発しているので、プラグイン開発者にとって、RedmineのVerUpに追随する上で品質向上に役立つだろうと思う。

akipiiさんはTwitterを使っています 「まさにそうなんですよね。RT @RyohHAMADA2: オーナー以外唯一のコミッタから推奨されるとか、称号として最強といえよう・・・ ＞ 推奨プラグイン #RedmineOsaka」 / Twitter

また、Redmineコミッタが、優れたプラグイン開発者と連携することで、Redmineの付加価値が上がることも期待できる。
そういう政治的影響として重要と思った。

【3】みうみうさんの発表では、Redmineのアンチパターンの新規概念を提唱しているように思えて参考になった。

akipiiさんはTwitterを使っています 「#RedmineOsaka ロール、権限にやたらヒエラルキーを持ち込むアンチパターン。ネーミングがいいな、使おう」 / Twitter

akipiiさんはTwitterを使っています 「なるほど、ロールや権限の機能がチームを分断するのか。RT @tw_yukia: #RedmineOsaka　Redmineって利用者をファーストステップとしてそこから開発者と運用管理者に派生していく気がするんですがはじめのステップは共通なのでSlackのチャットサロンのようなものがあるといいんだろうなとボンヤリ。」 / Twitter

Redmineのロール、権限にやたらヒエラルキーを持ち込むアンチパターンは、まさに組織文化をRedmineに押し付けるイメージ。
現場の業務、標準プロセスにこだわりがあるとはまりやすい。

(1) akipiiさんはTwitterを使っています 「#RedmineOsaka 内向きRedmine と外向けエクセルはよく聞くが、Redmine で裏プロジェクトがあるのか！」 / Twitter

Redmineで顧客向けPJと内向けPJを使い分けたくなる、というアンチパターン。
日本人しか分からない、本音と建前みたいな感じ。

(1) akipiiさんはTwitterを使っています 「#RedmineOsaka 人力ポーリングのネーミングがいいな」 / Twitter

チケットに書いているんだから、人力で常時見ておけ、というアンチパターン。

いずれも押し付けがましい感じ。

akipiiさんはTwitterを使っています 「#RedmineOsaka Redmine は、ぽーたるなどの静的情報、タイムラインなどの動的情報、ソースコードなどのリソースに３つに分類される、という主張」 / Twitter

Redmineなどのチケット管理ツールでは、情報の蓄積場所はチケットだけではない。
Wikiやフォーラム、構成管理ツール連携など色々ある。
その場合、その情報は3種類に分けられる、という主張は参考になった。

いわゆるチケット集計機能は、動的情報に相当する。
ガントチャート、サマリ、チケット一覧、カレンダーなど。
これらは、チケットの集計結果を表示するタイミングで確定する。

僕は、こういう「データの見える化」がプロジェクト管理で最重要と考えている。
なぜなら、プロジェクトは日々変化しているのに、その最新状況を把握できない、という問題をプロジェクトリーダーはいつも持っているから。
だからこそ、Redmineのようなツールが欲しくなる。

(1) akipiiさんはTwitterを使っています 「#RedmineOsaka データは鉱山。見せ方が大事。僕も、見える化が大事と思う一方、蓄積の仕方が大事という門屋さんの意見もある。」 / Twitter

一方、静的情報は、プロジェクト関係者で共有すべき情報を指す。
普通は、運用ルールや技術情報、設計思想などをWikiに書き溜めるだろう。

その場合、複数のチケットに記載された情報から、蒸留した情報をWikiで共有したくなる時がある。
プロジェクト特有、システム特有、チーム特有の情報は、実際に活動したノウハウとしてまとめて、今後に役立てたいから。

(1) akipiiさんはTwitterを使っています 「#RedmineOsaka そう、蓄積した情報を蒸留した情報も欲しいんだよね。自動化できればいいけど」 / Twitter

他方、リソース情報は、ソースコードや設計書など、構成管理で管理すべき成果物。
チケット管理ツールは、チケットとSCMのトレーサビリティの機能によって、その付加価値を高めている。
Excelではできない芸当。
個人的には、このトレーサビリティ機能を何らかのサマリ機能として表現する機能が欲しい、と思っている。

【3】junoさんのLTでは、DockerでRedmineと10個くらいのプラグインを入れた環境を作る話。
講演のストーリーは簡単かもしれないが、個人的にはとても重要と思っている。
理由は、Redmineとプラグインはバージョン依存があって、構築するのにかなり手間がかかるからだ。
本来は、Redmineを使いたいだけなのに、RubyやRailsにハマってしまうのはナンセンスだから。

akipiiさんはTwitterを使っています 「#RedmineOsaka DockerでRedmine＋プラグイン込みの環境を作る事例。初心者にとっては、プログラミングしたり、アプリを動かす前に、環境を構築する時に挫折してしまう。やはりRailsの環境は癖があるので、Dockerで環境を丸ごと作ってしまうのが吉と思う。」 / Twitter

(1) akipiiさんはTwitterを使っています 「#RedmineOsaka Redmine のラストワンマイル問題。優れたプラグインがあっても、環境構築が難しい。ホントこれ。」 / Twitter

この話は、Redmine運用に限らず、Railsアプリの開発でも同様の問題はある。
RubyもRailsもバージョンアップが激しい為に、機能は便利なのだが、開発環境やプログラミング環境を構築するのが初心者には難しい。
PythonのAnacondaみたいに、1個のパッケージを入れたら、RailsもRedmineもプラグインも簡単に動く、みたいな環境があればいいなと思う。

【3】パネルディスカッションでは、@ryouma_nagare さん 、@Madowindahead さん, @seizukio さんと「チケット駆動で成長し組織文化を変える」を発表した。
前回の東京で話せなかったネタをもう一度話すことができた。

内容は第21回Redmine大阪でみんなの苦労と工夫を知る　#redmineosaka | マドびっ！ Madosan's Viewの通り。

【4】懇親会でみうみうさんから、Redmineコミュニティでは管理者の観点の話が多すぎる、利用者の観点の話をもっと入れてみるべきでは、と言われた点が気になった。
この話は、Redmineコミュニティではもっと初心者向けの入門的な話を入れた方がいいのでは、という声が以前からあがっていたのに、なかなか実現していないからだ。

個人的な意見としては、テーマが偏らないレベルであれば、今のままでもいいかな、と思っている。
理由は、現在のRedmineの利用層はプロジェクト管理者や情報システム部門の人達なので、彼らに提供できる価値ある話をコンテンツに集めた方がいいから。
一方、Redmineの利用者の人は、受け身の立場なので、どうしても利用する以上のメリットがあまり感じられないように思えるから。

他に、みうみうさんと話していて気づいた点は、僕の興味は、Redmineの導入の手段ではなくて、Redmineをどんな場面で使うとより効果的なのか、自分がまだ知らない未知の使い方はないのか、Redmineを使ってプロジェクトをスムーズに進行させるだけでなく、チームやメンバーをRedmineでいかに変化させるか、にあることだ。
だから、Redmineの導入でなかなか浸透しない、という問題の解決はたしかに重要だけれど、その話だけにならないようにしたいと思っている。

実は似たような議論が、つい数年前までアジャイル開発の導入に関する話であった。
日本でアジャイル開発を導入・運用する事例やその講演では、いつも、アジャイル開発の導入のために現場の反対をいかに抑えて浸透させるか、という問題ばかりを10年以上もずっと話しているだけ、という指摘があった。

私は間違っていた。ごめん。ウォーターフォールは何のメリットも無い - メソッド屋のブログ

つまり、日本のソフトウェア開発のコンテキストでは、いつもアジャイルの導入部分の話ばかりで終わっていて、アジャイル開発を実践した後に、アジャイル開発にどんな可能性があるのか、その先にどんな世界が待っているのか、という議論が日本では欠落している、という指摘だ。

日本のアジャイルは導入部分ばかりで終わっている: プログラマの思索

よって、Redmineの導入に関する話の議論もこの方向の罠にハマってしまいそうで怖いと思っている。
本来は、導入が目的ではなくて、その先のメリットや、一段レベルが上った所での新たな課題解決を目指すべきはず。
たとえば、僕が議論したり考えたりしたいのは、Redmineの背後にあるチケット駆動開発はどんなメリットがあるのか、チケット駆動開発にはこういう可能性があるのにまだ実装できていない機能は何なのか、ということだ。

同様に、Redmineの利用者向けの話も、どうしてもRedmine導入のハードルを下げるための議論だけにハマってしまいそうな気がしている。
この辺りは色々議論してみたい。

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

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

シグモイド関数とソフトマックス関数の違い

以下はメモ書き。

教師あり学習には、クラス分類と回帰の2種類がある。
ディープラーニングの出力層の活性化関数は種類分けする。
2クラス分類ならシグモイド関数。
他クラス分類ならソフトマックス関数。
回帰ならば、恒等関数。

機械学習 - なぜシグモイド関数では多クラス分類できず、ソフトマックス関数では多クラス分類できるのか？｜teratail

回帰は予測するので、出力時に何も変えずにそのまま渡す。

シグモイド関数は滑らかなので微分できるゆえに、層を重ねるごとに伝播させやすい。
しかし、勾配消失/爆発しやすい。

ソフトマックス関数は、総和が1になる性質を持つので、確率分布とみなせる。
だから他クラス分類に使える。