MS PlannerはRedmineと違って使いにくいのは複雑なワークフロー管理ができないから

Microsoft Plannerを使ってみたら、Redmineと違って使いにくかったと感じたのでメモ。
その理由は、自分の用途に合っていないだけ。
ラフなメモ。

【参考】
Microsoft Plannerの活用事例紹介！ガントチャートでチーム運用状況がすぐわかる！ - エク短｜Extan.jp

【1】Plannerは、簡易なToDo管理ツールと思った方がいい。
Plannerのチケットは、下記で決められていて、カスタムフィールドは増やせない。

・バケット・・・プルダウンで選択する。選択肢は自由に設定できる。
例えば「機能」「顧客」に使う。
Redmineで言えばカテゴリ。トラッカーではない。
この機能が一番大事。

・タグ・・・2個以上自由に設定できるラベル。
タグなので、種類に使う。
Redmineにタグはないので欲しい。

・進捗状況・・・固定のステータス。未着手→進行中→完了で決まっている。
ステータスが固定なので、ワークフローを自由に設定できない。
結局、課題管理に向かないし、現場でカスタマイズしたいワークフロー管理を実現できない。

・担当者・・・複数のユーザを割り当てられる。

・優先度・・・固定の優先度。Redmineの優先度と同じ。

・開始日、期日・・・Redmineと同じく、予定日と実績日は同じ。
・メモ・・・説明欄。
・チェックリスト・・・チケットにチェックリストを作れるのは便利。
しかし、実際に運用してみると、タスクボードにチェックリストは表示されないので、逐一開かないと、チェックリストをどこまで消し込んだのか分からない。

【2】Plannerを使ってみて、ToDo管理以上の進捗管理には向かないと分かった。
Plannerのアンチパターンもある。

【2-1】バケットをステータス代わりに使うアンチパターン。

バケットにワークフローのステータスを割り当てると、Plannerのダッシュボードに円グラフや棒グラフで表示されるのは良い。
しかし、バケットにワークフローのステータスを割り当てる本来の意図は、Plannerの進捗状況は固定ステータスで使いにくいので、その代わりにバケットで制御しようとしているわけだ。
すると、実際の運用では、チケットをCloseする時、バケット＝完了、進捗状況＝完了の2つを設定する必要があって、割と操作が面倒。

こういう運用は、昔のBugzillaやMantisを思い出す。
BugzillaやMantisでも、Statusとは別に、Resolutionフィールドがあって、Resolutionでバグの解決状態をわざわざ設定する運用があった。
僕はこの運用が嫌いだった。
Redmineのように、ステータス1個で完了にすれば、わざわざ2つの項目で完了の意味をもたせる必要はない為だ。

また、バケットを複雑化したワークフローのステータスに割り当てると、複数のトラッカーのワークフロー制御をしたくなってきて、10個以上のステータスをバケットに割り当ててしまう。
すると、2本上のトラッカーのステータスが混じっているので、バケットから選ぶときに混乱してしまう。

結局、複雑化したワークフローや、複数の業務のワークフロー管理には向いていない。

【2-2】チェックリストをステータス代わりに使うアンチパターン。

チェックリストは、作業リストを分解して、それぞれの細かい作業を割り当てて、細かい作業が終われば消し込んでいく。
当初使っていた時は、自分1人の作業をチケットに書き、その作業をチェックリストに分解して消し込むのはやりやすかった。
しかし、チェックリストとは、結局、1個の作業の流れの中で、今どこまで作業を消し込んでいるのか、というステータスを表しているだけに過ぎないと分かった。

また、チェックリストの項目が10個以上あると、正直使いにくい。
普通は、チェックリストは上から順に消し込んでいくべきだが、10個以上あると、歯抜け状態のような形で消し込むケースが増える。
チェックリストの状況を一目で把握しにくくなる。

さらに、チェックリストはタスクボードに表示されないので、チェックリストが作業順序に並んだ作業の進捗状況を表しているならば、逐一チケットを開かなければ、その状況は分からない。

【2-3】タグをステータス代わりに使うアンチパターン。

タグにステータスを表示させる運用も考えたが、ワークフローのステータスが10個あった時、10個のタグが初期状態で表示されていてそれを1個ずつ消し込んでいくとか、ステータスが進むごとに以前のタグを消しで新しいタグを付け直すとか、運用は煩雑すぎる。
現実的でない。

【2-4】こういうアンチパターンを考えていると、結局、現場で管理したいステータス管理をPlannerでどのように実現すべきか、という問題に苦労しているのが分かってくる。
つまり、Plannerのステータスが固定である為に、現場で出てくる複雑なワークフロー管理をPlannerにフィットさせるのが非常に難しいのだ。

【3】Plannerでは、バケットの使い方が重要みたい。
なぜなら、ユーザが自由にカスタマイズできる機能は、バケットしかないから。
その他の機能は固定ステータスや担当者、期日のように、すでに用途が限られているからだ。

バケットに、分類すべき業務を設定すれば、ダッシュボードで担当者別・ステータス別にグラフ化してくれる。
つまり、バケットには、ToDoリストのタスクを分類したい観点を割り当てるべき。

【4】PlannerのタスクボードをExcel出力した場合、注意すべき点が色々出てくる。

Plannerのチケットに2個以上のタグを付けると、１セルに複数のタグがカンマ区切りで表示される。
つまり、１セルに入ったタグをExcelマクロで分割して取り出す、という操作が必要になってくる。
タグを使いすぎる時は注意。

同様に、担当者も２人以上割り当てられるので、１セルに複数の担当者名がカンマ区切りで出力される。

【5】Plannerで一番不満なのは、Redmineのクエリに相当する機能がないことだ。
全チケットのタスクボードと、自分にアサインされたタスクボードの２つしか選べない。

フィルタでバケット、日付、担当者などをフィルタリングできるが、その検索条件を保存できない。
だから毎回フィルタリングする必要がある。

結局、より複雑なクエリが欲しければ、Excel出力して、Excelデータをいじくり倒すしかない。

【6】こんなことを考えていると、Plannerの設計思想はタスクかんばんなので、そもそも複雑なワークフロー管理をしようとするのが間違っているのだろう。

Plannerをタスクかんばんとして扱うならば、小さな作業を割り当てて、１チケット＝１担当者でアサインし、基本は１日１内にCloseする運用にすべきだろう。
そうでなければ、数多くの情報をチケットに詰め込められないので、すぐにタスクが溢れてしまうからだ。
ToDoリストであるからには、どんどんCloseして消し込んでいった方がいい。

つまり、PlannerはGTDと相性がいいのだろうと思う。
タスクをどんどん書き出して、日々消し込んでいくが、毎週の週次レビューで全チケットを見直す。

換言すれば、日々の業務をPlannerに落とし込んで運用できた場合、その業務はかなりルーチン化されていて、細分化されたタスクになっているだろう。
そういうフィットギャップ分析についても考えてみたい。

計量経済学における統計上の根本問題

Rによる計量経済学 第2版を読んでいたら、興味深いことが書かれていたので、考えたことをメモ。

【１】経済学の実証が物理や科学の実験と異なる点は、経済現象は実験室で観察できないこと。
社会や人間をこちらの指示通りに配置したり、再現性があるように何度も繰り返し実験することができない。
採取できた政府の統計データすら、すでにバイアスが紛れ込んでいる。

また、取得できるデータは受け身になっている。
自分たちから積極的にデータを採取することは、昨今のSaaSやSNSのおかげで、大量のデータをビジネスの副産物として採取できる。
しかし、それらはまだ一部に限られていて、世の中にあふれているデータを元に、自分で収集して分析する場合も多い。
すると、それらのデータにはバイアスが紛れ込んでいて、そのままでは使えない。
パネルデータ分析に使おうとするなら、その前提に合うようにデータを精製しなければならない。

Rによる計量経済学 第2版で最も考えさせられたことは、経済現象の分析にあたって、誤差が古典的最小二乗法でおかれる仮定を満たさない場合が多いということだ。
よって、生データのままでは、回帰分析すら行えなくなる。

実際、新聞やネットニュースでいろんな統計データを元にした意見や主張が出てくるが、そもそも古典的最小二乗法を満たさない場合の考慮を踏まえて、正しい推定が行われているのか、疑問に思える場合がかなり多い気がする。
奥村先生のツイートを読んでいると、そう感じる時がある。

【２】古典的最小二乗法の仮定は下記の5つがある。

１・誤差はプラス側やマイナス側に偏らない
２・誤差同士の大きさに関係がない。（自己相関なし）
３・誤差の大きさの平均は一定。（均一分散）
４・誤差と説明変数の大きさに関係がない
５・誤差は正規分布に従う

しかし、経済現象を考えると、この５つの過程を満たさない具体例が簡単に見つかる。

１・誤差はプラス側やマイナス側に偏らない

生産における投入と産出の関係を分析する時に発生する問題。
投入量と産出量には物理的関係がある。
生産プロセスでは何らかのロスが発生するので、物理的生産可能量を基準にすると、回帰分析の誤差はマイナス側だけ発生する。

２・誤差同士の大きさに関係がない。（自己相関なし）

時系列データを分析する時に発生する問題。
データの発生に順番があるので、過去データが直近であるほど現在のデータに影響を与えてしまい、後のデータの誤差に影響を与える。
指数平滑法を連想する。

経済活動では瞬時に終了することはないので、一定期間が必要になる。
そのため、前期のデータが後期のデータに影響し、自己相関の現象が発生しやすい。
経済学では時系列データが多いので、自己相関をいかに排除するか、に注力しているように思える。

３・誤差の大きさの平均は一定。（均一分散）

クロスセクションデータを扱う時に発生する問題。
たとえば、ある国のデータを集めると、大国と小国では規模が異なるので、大国の方が誤差が大きくなる。
つまり、誤差分散の大きさは一定ではない。
経済学では、大国と小国、大企業と中小企業などのデータが混じっていて比較するから、不均一分散の考慮も重要になる。

たとえば、パネルデータ分析では、仮定２と３、つまり、自己相関なしと均一分散の仮定を満たす必要がある。

４・誤差と説明変数の大きさに関係がない

連立方程式体型の経済モデルを扱う時に発生する問題。
市場の分析では、需要関数と供給関数が近郊を決定する時にお互いに影響し合うので、誤差と説明変数に影響が出てしまう。

たとえば、需要均衡など市場で数量と価格が決定される場合など、経済が複数の関数で表現される構造を保つ場合、回帰式に現れる誤差の大きさは、様々な影響を受けて決定される。
その結果、説明変数との間に関係を持ってしまうので、古典的最小二乗法では正しい推定ができない。
つまり、回帰分析に正当性がなくなる。

５・誤差は正規分布に従う

正規分布は左右対称であるが、定性的尺度（働く＝０、働かない＝１）、比率（耐久財の普及率）ではそのままでは満たさない。

【３】僕は計量経済学の知識不足だが、古典的最小二乗法の仮定を満たさない場合にどこまで推定できるのか、古典的最小二乗法を部分的に満たすような場合はどこまで推定できるのか、を直近３０年くらいで研究が進められているように思える。

信頼性革命や構造推定は、たぶんそういう流れの研究ではないか。

経済学は信頼性革命や構造推定により大きく変貌している: プログラマの思索

そんなことを考えると、大量データをクラウドやプログラムで簡単に統計分析できる現在、計量経済学は非常に面白い分野になっていると思う。
IT技術者は積極的にこの分野に関わってもいいと思う。
なぜなら、IT技術者はすでにツールを持っているので、実際の生データを片っ端から分析してみることで、統計学を習得できるからだ。小難しい理論は後から理解すればよい。
具体例をたくさん経験した後で、統計学の本を読み直せば、自分の経験を整理するだけで簡単に理論を生身の知識として理解できるからだ。

今は面白い時代になっているのだろうと思う。

Slack導入がDXに繋がる話

Slack導入がDXに繋がるツイートがあったのでメモ。

【参考】
創業135年のカクイチがSlackを導入したら課長職が不要になった話：日経ビジネス電子版

石倉秀明 | Mr.リモートワークさんはTwitterを使っています 「いやー、これですな > Slackの導入で経営陣の情報がじかに社員隅々まで伝わるため、情報を伝達するだけだった立場に優位性がなくなってしまった 情報格差を作ることで権力を保持してたタイプの管理職からすると、チャットコミュニケーションは脅威なのかもね https://t.co/hfLTAIQTMA」 / Twitter

えとみほさんはTwitterを使っています 「この記事、とてもリアルで良かった。 　「カルチャーの変革とデジタルは一緒に取り組んだほうがいい」 ほんこれです。DXというのは、上部だけ便利にすることではなく、働く人のマインドやカルチャーを変えること。」 / Twitter

経営陣の意見が末端社員までリアルに届く環境になると、単なる伝書鳩の中間管理職はいらなくなる。
DXとは、コミュニケーションルートを変革することで組織構造だけでなく組織文化まで変えてしまうこと。

つまり、課長という役職がなくなることで組織構造が劇的に変わり、その結果、社員の行動を規制する価値観が変わって、社員の行動そのものが以前から変化してしまうこと。

「DXとは組織論である」とは、たぶん、そういうことを意味しているのだろうと思う。

民主主義の呪い

「民主主義の呪い」という言葉を見かけたのでメモ。

【参考】
RIETI - 民主主義の呪い：2020年の教訓

橘　玲さんはTwitterを使っています 「8/18日経「経済教室」成田悠輔エール大助教授「（民主主義の）優位性後退、崩壊の瀬戸際に」経済成長率でもコロナ対策でも、非民主陣営が成功し、欧米など民主国家は失敗しているという話題の論文の紹介。20世紀は先進民主国家が優位だったが、21世になって「民主主義の呪い」をかけられた。 https://t.co/s541sfnGl2」 / Twitter

橘　玲さんはTwitterを使っています 「テクノロジーと感染症の共通点は「常人の直感を超えた速度と規模で反応が爆発すること」。「超人的な速さと大きさで解決すべき課題が爆発する世界では、常人の日常感覚（＝世論）に配慮しなければならない民主主義は科学独裁・知的専制に敗北するのかもしれない」。」 / Twitter

橘　玲さんはTwitterを使っています 「残された道は「民主主義を守るための闘争」か「民主主義からの逃走」だとして、ピーター・ティールの海上自治都市計画が紹介されています。「上級国民」が自分たちだけの国家をつくるとしたら、こんな感じかも。https://t.co/KVn9IpykvR」 / Twitter

Aki TonamiさんはTwitterを使っています 「『経済教室』の連載とても読み応えがあった。（上）で民主主義はもうだめだ、として、（中）でいやそんなことはない、（下）で民主主義を良しとした上でその質を問う形。執筆者は全員80年代生まれの若手研究者で、米国の大学で博士号を取得した後、各国の研究機関と共同研究を精力的に行っている方々」 / Twitter

民主主義の未来(上)　優位性後退、崩壊の瀬戸際に: 日本経済新聞

民主主義の未来(中)　「権威主義の優位」 前提疑え: 日本経済新聞

民主主義の未来(下)　男女均衡参加、再生への鍵: 日本経済新聞

コロナ対応では、民主主義国と独裁国家の違いを見せつけられた。
根本問題は、全国民の安全を国家が守るには、個人の権利を制限する必要があるが、民主主義政府はそれを実行できるのか？ということ。
文字通り、ロックダウンで個人の自由な移動や自由な商売を制限し、ワクチン接種を強制的に実施できるのか？

つまり「政府行政のIT化の根本問題は、個人のプライバシーとどのように折り合いをつけるべきなのか」。
日本政府がデジタル庁でやろうとしている問題でも同じだと思う。
この問題をどのレベルで解決すれば良いのか、今もみんな苦慮している。

プログラマとスクラムが社会実装を変えていく　#Findy_GovTech: プログラマの思索

デジタル庁が解くべき課題とITエンジニアの役割の勉強会の感想～CTOの役割とは何ですか？: プログラマの思索

DXとは組織論である: プログラマの思索

astahのセミナーレポート「サンプルモデル図で解説、MBSEの流れとモデルの役割」の感想

astahのセミナーレポート「サンプルモデル図で解説、MBSEの流れとモデルの役割」の記事と動画が公開されていたのでメモ。
参考になった。

【参考】
セミナーレポート「サンプルモデル図で解説、MBSEの流れとモデルの役割」 | astah in 5 min

電気ケトルを題材にして、SysMLと安全性の観点からモデルを描いて詳細化していく流れ。

重要な考えは、モデル種類ｘ検討した観点のマトリクスでSysMLのモデルを使い分けること。
モデル種類には、用語、構造、接続性、状態、プロセス、シナリオの6種類がある。
前半がブロック図、後半は状態遷移図、アクティビティ図、シーケンス図に対応する。

検討した観点には、Usage、Function、Implementationなどがある。
順に詳細化していく感じ。

気づきは、SysMLのそれぞれの図は関連していること。
動画を見ると、ブロック図やユースケース図の要素にハイパーリンクがあって、リンク先にブレイクダウンしたシーケンス図やステートマシン図がある流れだった。
こういう風にモデルがトレースされて作られていくならば、説明しやすいし理解しやすいと思う。

ブロック図の使い方は分かっていなかったが、利害関係者を含むコンテキスト図やハードウェア部品構造、機能とハードウェア部品の関係に使うらしい。
SysMLではブロック図が一番重要なモデルに思える。
ちょうど、UMLではクラス図が一番重要であるように、SysMLではハードとソフトが関係するモデルとしてブロック図が設計図に相当するように思えた。

個人的には、モデリングのプラクティスみたいなものも資料に添えられたら役立つだろうと思った。
たとえば、オブジェクト指向設計でも、SOLID原則、GRASPパターンのような基本プラクティスがあり、そのプラクティスを使うことで、クラス図の責務割当がスムーズに行くからだ。
SysMLでも、オブジェクト指向設計のプラクティスは使えるだろうが、SysML特有のプラクティスや組み込みソフトウェアならではのプラクティスが知りたいところだった。

この辺りは色々調査してみたい。