« 2021年9月 | トップページ | 2021年11月 »

2021年10月

2021/10/31

PJ管理におけるQCDのトレードオフ

PJ管理を考える時、「QCDのトレードオフ」はWF型開発でもAgile開発でも、普段の定常業務におけるマネジメント業務でも必要だ。

今、仕事の品質がボロボロだった時、もっと時間をかけて品質を担保するか、他の人に頼ったり、外部へ作業委託したりしてコスト超過を見越して品質を担保するか。
つまり、品質の担保をスケジュール遅延、コスト超過でカバーしようとしている。

他方、短納期の仕事であれば、8割程度の品質で合意を取って、まずは一旦納品する戦略を取る場合もある。
あるいは、手順が分かっているなら、複数人で分担して並行作業して、最後に統合する戦略もあり得る。
つまり、短納期をそこそこの品質かコスト超過でカバーしようとしている。

以前、ローバー、火星を駆ける―僕らがスピリットとオポチュニティに託した夢
を読んだ時、火星探査の調査機オポチュニティを製作する過程で、エンジニアは理論一本槍、技術一本槍ではなく、QCDのバランスを絶妙に取る能力が一番大事、という一節を思い出した。

「ローバー、火星を駆ける―僕らがスピリットとオポチュニティに託した夢」の感想: プログラマの思索

(引用開始)
もう一つは、科学者とエンジニアの宿命的対立と、それを乗り越えた科学者とエンジニアの共同作業による成果の偉大さだ。

つまり、科学者の立場は、真実の探求、自然界の仕組みの探求、制約なしの研究の結果を重視する。理想主義者。
一方、エンジニアの立場は、技術的課題の単なる解決ではなく、最も優れた方法で問題解決する。限られた予算、開発スケジュール、納期の制約の下、「まずまずのところ」で折り合って解決する。がんこな現実主義者。

しかし、科学者とエンジニアは宿命的な対立構造があるが、それを乗り越えたら、偉大な成果が得られる。
(引用終了)

PJ管理におけるQCDのトレードオフの考え方は、自分がチームやPJを運営していたり、メンバーを統率している時に、時々忘れがちなのでメモしておこうと思った。

| | コメント (0)

2021/10/30

ソフトウェアPJの企画フェーズの責任者は誰なのか?

ふと思いついてメモして、Blogに書くまで昇華できていないアイデアを書き殴っておく。
初心者のロジカルでないメモ。

INSPIRED 熱狂させる製品を生み出すプロダクトマネジメントの感想~日本に足りないのはプロダクトマネジャーだ: プログラマの思索

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

プロダクトマネジメントの感想~プロダクトオーナーはもっとチームの外のユーザに寄り添うべき: プログラマの思索

アジャイル開発は必ず2度失敗する~「正しいものを正しくつくる」の感想: プログラマの思索

一般の日本企業では、メーカーであれ、ユーザ企業であれ、SI企業であれ、予算駆動だから、システムが必要になったら、その企画フェーズが必要で予算取りの根拠を作らねばならない。
では、その企画フェーズを担当する最終責任者はいったい誰なのか?

要件定義フェーズをSIerに準委任契約で作業してもらって、開発フェーズの詳細な見積もりが確定する時は、SIに見積もりの責任があり、ユーザ企業は請負契約で開発リスクを全て負わせることができる。
しかし、経験上、企画フェーズでは責任者がはっきりしない場合が多かった。

本来は、ユーザ企業の業務部門の担当者自身がシステム企画を担当すべきだ。
しかし、実際は彼らが担当すると、変な方向に向いたり、コストが膨れ上がったり、業務とシステム要件がミスマッチになりやすく失敗しやすい。
ユーザ企業もそれを知っているので、ITコンサルやITベンダの優秀なPMにBPRの構想を描いてもらって、システムに落とし込んでシステム要求まで確定させる作業を委託する場合がすごく多い。

たぶんその理由は、業務を知っているだけでは不十分であり、今のIT技術でBPRを実現するにはこういうシステムがQCDのトレードオフから現実的な解になる、というアーキテクトの能力が必要だからだろう。
以前聞いた話では、営業マンあがりのシステム企画屋はダメで、SEあがりで業務を知っているシステム企画のコンサルしか担当できないね、という話をよく聞いた。
営業マン上がりの企画担当者も自分でBPRの構想やゴールを描いても、途中でシステムにどう落とし込むか、という所では、開発チームのPMやSEを呼び出して、一緒に作業してもらう場合が多かった。
結局、業務もITも両方知っているアーキテクトでなければ、企画フェーズを担当できないね、という身もふたもない結果なのだろうと思う。

たぶんScrumは、その役割をプロダクトオーナーという人物で具体化して明確にしたのが最大の功績なのではないか、と思っている。
今の日本企業にプロジェクトマネージャはいても、プロダクトオーナーという人物はほとんど存在しないし、聞いたこともないから。


| | コメント (0)

AWSサービスとSW品質特性のマッピングはどうなるか

ふと思いついてメモして、Blogに書くまで昇華できていないアイデアを書き殴っておく。
AWS初心者のロジカルでないメモ。

AWS Fargate とは?「コンテナ」と「仮想マシン」の違い|AWS上のコンテナ関連のサービス | FEnet AWSコラム

AWS Fargateとは?Amazon ECSとの関係性やメリット・デメリットを解説|コラム|クラウドソリューション|サービス|法人のお客さま|NTT東日本

AWSサービスとSW品質特性のマッピング一覧を作ることで、クラウドが何を解決しようとしているのか、整理したいと思っている。

AWSの最大の恩恵は移植性だろう。OSパッチやセキュリティパッチの作業から基本は解放される意義は大きい。
他にも、障害耐性などの機能性やAutoScalingなどの効率性もあるだろうが、盲点なのは保守性ではないだろうか。

Infrastructure as Codeにより、サーバー構築は全て構成管理の配下に置かれ、保守性を大きく担保する。
しかし、それはアプリケーション層のApacheのhttpd.confの構成管理を意味しているわけではない。
むしろ、AWSがNW機器の物理的実体からデータプレーン、コントロールプレーンという論理的実体へ分離することで、膨大なネットワーク機器を一括管理し構成管理できるようにした点が大きな利点のはず。
AWS上で「データプレーン」を提供しているのは「AWS Fargate」と「Amazon EC2」、AWS上で「コントロールプレーン」を提供しているのは「Amazon ECS」と「Amazon EKS」です、という文言を偶然拾って、ああそういうことなのか!と気づきを得た。
だから、Kubernetesが画期的な技術なわけだ。
CCNAを取得したおかげでこの辺りの意義がなんとなく実感できたから。

インフラ関係のPJをレビューしていていつも思うのは、専用回線の切り替えやDNS切り替えだけのNWリプレースの作業のPJで割と本番障害が多くて、なぜたかがNW機器の入れ替えぐらいでそんなに作業ミスが多いの?といつも思ってた。
DNS切り替えなんて所詮、向き先を変えるだけでしょ、と思ってた。
たぶん、その背後には、数多くのNW機器があり、その設定ファイルを手作業で書き換えて、手作業で検証する必要があって大変なのだろう。
だから、NW層のレベルで構成管理できる意義はとても大きいのだろうと推測している。

| | コメント (0)

2021/10/24

いいねをもらえなくて鬱になる負のインセンティブが働くという事象

いいねをもらえなくて鬱になる負のインセンティブが働くという事象についてメモ。
適当なラフなメモ。

えとみほさんはTwitterを使っています 「Netflixの「監視資本主義」が面白かった。 「いいねを作った時は愛を広げたかった。いいねをもらえなくて鬱になっていく10代の子や政治的な二極化は予想外だ」 作り手たちも困惑するSNSの現状。北米のトレンドは2?3年遅れで日本に来るが、この流れもきっちりやってきた。 https://t.co/K8jCUnt22s」 / Twitter

監視資本主義: デジタル社会がもたらす光と影 | Netflix (ネットフリックス) 公式サイト

akipiiさんはTwitterを使っています 「後で読む。いいねは愛を広げる設計なのに、いいねをもらえなくて鬱になる負のインセンティブもあるのか」 / Twitter

2021年という時代では、SNSから離れた生活は非現実的。
単に人と繋がりたい、という単純な気持ちだけでなく、SNSに最新の情報やニュースが流れている。
TVや新聞の方が情報は正しいと言われているが、実際は彼らも、Twitterの最新の動向や流行ををキャッチして、そこから記事を書き起こしているな、と思う時も多い。

すると、ほとんどの人たちは、自分の時間の何十%かをSNSに吸い取られていることになる。
その危険性は、特に成長過程の子供に大きな影響がある点なのだろう。

小さい子供、特に小さい男の子は、無意味な万能感を持って夢を語る場合が多かった。
しかし、現代では、SNSで簡単に現実を見れるし、そこから自分のリアルな状況を直視して比較評価されるので、そういう無意味にな万能感は他人からも自分からも訂正されてしまう。
結局、他人に認められてもらうために、みんなが同じような価値観や基準に収斂されることになる。

その世界では、いいねをもらなくて鬱になり、自信をなくす人が多くなる。
万人の競争を経て評価を確立できていない人が大多数になるのだから、多数の敗者が生まれる。

以前なら、海外の子供やビジネスと比較する必要もなかったが、今は違う。
世界中の食材も商品も簡単に手に入り、人々の交流が増えるにつれて、日本人の子供も欧州や米国の子供だけでなく、中国や韓国の子供と学力を比較されることになるだろう。

単純にいいねをもらえず鬱になるだけでなく、全世界の子供と比較評価されて、自分が上から何番目にいるのか、を簡単に評価されてしまう時代になってしまったのかもしれない。

SNSから離れて、自分1人だけの世界に閉じこもって、自分だけの能力を磨くことが難しい時代なのかもしれない。


| | コメント (0)

ソフトウェアPJの工数に対して工期が3乗根に比例する経験則の理由

ソフトウェアPJの工数に対して工期が3乗根に比例する経験則の理由について、参考になるツイートを見つけたのでメモ。

【参考】
広木 大地/ エンジニアリング組織論への招待さんはTwitterを使っています 「ソフトウェアPJの工数に対して工期が3乗根に比例することが経験的に知られている。 しかし、なぜそうなるかについては説明がされていない。 これは、一般的なソフトウェアプロジェクトのリソースヒストグラムが放物線という二次関数になるからだ 工数はその積分であるから三次関数になる。」 / Twitter

広木 大地/ エンジニアリング組織論への招待さんはTwitterを使っています 「リソースヒストグラムを書く-ax^2+bx という放物線を0 - b/a の区間で積分するとb^3/(6a^2)となる。」 / Twitter

PM(プロジェクトマネージャー)になったら絶対に読むべきおすすめの本6選(転載) | Books&Apps

ソフトウェア見積り | スティーブ マコネル」では、統計に基づくスケジュールの基本公式:
スケジュール(月)=3.0×人月(^1/3)
が載っていて、よく知られている。

でも、なぜスケジュールは工数の3乗根になるのか、という理由が分かってなかった。

僕の理解では、こんなイメージ。
一般的なソフトウェアPJの要員計画(リソースヒストグラム)x日数のグラフを書くと、放物線(y=ax^2)になる。
工数は、要員計画の積分値だから、3次間数になる。

工数=日数^3
より、
スケジュール(日数、つまり工期)=工数^(1/3)
となる。

このロジックで気になる点は、ソフトウェアPJの要員計画(リソースヒストグラム)が放物線になるのか?
その前提条件は正しいのか?

一般的に、要件定義や設計フェーズは少数精鋭のSEが担当し、開発・テスト工程で大量のプログラマを雇って、最後のリリース直前にPJメンバーを一気に減らす。
保守フェーズでは、たくさんのメンバーは不要なので、開発経験があり優秀なプログラマとSEのみの少人数チームになる。

だから、経験から考えると、要員計画は定数でもないし1次関数でもない。
よって、グラフは、1次関数の次の2次関数という放物線になるだろう、という推測は直観的には正しいと思う。

ただし、実際の要員計画は離散的だし、左右対称のグラフでもないから、あくまでも目安として使うだけだろう。

| | コメント (0)

2021/10/20

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個以上のタグを付けると、1セルに複数のタグがカンマ区切りで表示される。
つまり、1セルに入ったタグをExcelマクロで分割して取り出す、という操作が必要になってくる。
タグを使いすぎる時は注意。

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

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

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

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

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

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

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

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

| | コメント (0)

2021/10/10

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

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

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

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

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

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

(3) Haruhiko OkumuraさんはTwitterを使っています 「RT @M123Takahashi: 通常の最小二乗法では,誤差項の正規性の仮定が満たされていなくても,中心極限定理により,大標本なら統計的推測に問題は起きないとされています.具体的に標本がどれぐらい大きければよいかについて,この論文では1変数あたり観測値10以上あればよいとしています.(続く)」 / Twitter

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

1・誤差はプラス側やマイナス側に偏らない
2・誤差同士の大きさに関係がない。(自己相関なし)
3・誤差の大きさの平均は一定。(均一分散)
4・誤差と説明変数の大きさに関係がない
5・誤差は正規分布に従う

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

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

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

2・誤差同士の大きさに関係がない。(自己相関なし)

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

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

3・誤差の大きさの平均は一定。(均一分散)

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

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

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

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

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

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

正規分布は左右対称であるが、定性的尺度(働く=0、働かない=1)、比率(耐久財の普及率)ではそのままでは満たさない。

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

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

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

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

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

| | コメント (0)

Slack導入がDXに繋がる話

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

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

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

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

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

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

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

| | コメント (0)

2021/10/04

民主主義の呪い

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

【参考】
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とは組織論である: プログラマの思索


| | コメント (0)

« 2021年9月 | トップページ | 2021年11月 »