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

2021/07/23

心理的安全性は日本企業では実現しにくいかもしれない

「心理的安全性」という概念は、まだ、日本人には早すぎる。 | Books&Appsという記事がとても参考になったのでメモ。

【参考】
「心理的安全性」という概念は、まだ、日本人には早すぎる。 | Books&Apps

Masanori Kusunoki / 楠 正憲さんはTwitterを使っています 「日本で個人主義が根付いてないというのは、漱石の昔から言い古されてきた話題ではあるけれども、だから日本人には早すぎるなんて緩いことをいってると、いよいよオワコンに / “「心理的安全性」という概念は、まだ、日本人には早すぎる。 | Books&Apps” https://t.co/NPzz4gkmFs」 / Twitter

akipiiさんはTwitterを使っています 「良い記事。心理的安全性は人間関係のリスクを取っても率直に言える組織風土を指す。いまもいじめがはびこる日本では根付かないかもしれない。「心理的安全性」という概念は、まだ、日本人には早すぎる。 https://t.co/9Em4UXSWCe」 / Twitter

僕は心理的安全性という概念をきちんと理解できていなかったと思う。
「心理的安全性」という概念は、まだ、日本人には早すぎる。 | Books&Appsの通り「ハーバードビジネススクール教授、エイミー・C・エドモンドソンは、「心理的安全性」の定義を「対人関係のリスクをとっても安全だと信じられる職場環境」としている」ならば、対人関係を気にせず率直に意見を述べられる組織風土や組織文化を指すわけだ。

そういう心理的安全性の定義を踏まえると、特に日本の企業や学校では、心理的安全性はとても実現しづらい。
同調圧力、集団主義的傾向、権力者への従順さなどが日本人という個人を脅かすから。

日本人は、相手と話す時に彼との序列順位をいつも気にしている。
日本人は、年功序列、多重下請け構造という目に見えない社会構造をいつも気にしている。
気にしなければ、生活できない人が多いから。

でも、ソフトウェアを中核としたビジネスモデルで発展させていくには、優秀な人材を集めて、彼らが率直に意見をぶつけて、知的バトルの中から、規模の経済を打ち倒すアイデアや方策を生み出さねばならない。
だから、心理的安全性という組織文化は非常に重要なのだ。
「心理的安全性の低い組織には、賢く、有能な人間は集まらない。パフォーマンスが著しく落ちるからだ。」
たぶんそういうところが従来の既存企業には欠落しているのだろう。

とはいえ、特にIT人材は日本人だけでは今後不足していくので、早晩、海外のIT技術者を日本企業も取り込んでいかないといけなくなる。
そんな状況で、心理的安全性を自ら実践していけるのか?

昭和や平成初期の時代の雰囲気から抜け出せない人を外すしか解決できないのでは、と思ったりもする。

| | コメント (0)

2021/07/18

規模の経済から個人の能力重視へビジネスモデルが変化している

製造業からソフトウェアのビジネスモデル変換の鍵に、規模の経済から個人の能力重視の観点があるツイートを見つけて、なるほどと思った。

akipiiさんはTwitterを使っています 「すごく参考になる。規模の経済から個人の能力重視への変化」 / Twitter

r.ishibashiさんはTwitterを使っています 「この例えは良いな。 https://t.co/xLQjAuij1m https://t.co/17u8ZF9jgM」 / Twitter

(引用開始)
"シスコはスキルがスケール(規模)に勝った唯一の例だと考えていたが、そうではないのだ、と。シスコがうまく活かしているのは、一企業、一産業の枠を超えた大きなうねりなのである。  従来コンピュータや通信機器の分野で成功するには、数十億ドル規模の大型プロジェクトで大量のエンジニアをとりまとめ、さらに大量の労働者を管理して複雑な電子機器を製造することが必要だった。それをやれる能力が備わっていたから、 IBMや AT& Tは繁栄し、日本は技術集約型の成功を収めることができたのである。だが一九九六年の時点では、成功のカギを握るのはソフトウェアになっていた。そしてソフトウェアなら、大企業でなくても、頭の良い連中が何人かそろえば書き上げることができる。規模の経済から個人のスキルへ──これが、大きな変化のうねりだった。戦争の主流が、正規軍の衝突からゲリラ戦に移ったようなものである。"
― from "良い戦略、悪い戦略 (日本経済新聞出版)"
(引用終了)

以前読んだ記事で、スクラムは組織の仕組みで駆動するのではなく、メンバー個人の能力を重視して、個人のパフォーマンスで駆動しようとする内容を思い出した。

アジャイル開発とウォーターフォール型開発の違いについて再考: プログラマの思索

アジャイルとウォーターフォールは文化や価値観のレベルで異なるという話 - たなかこういちの開発ノート

ソフトウェアビジネスが主流になる以前は、設備やリソースなどの資本を集約することで、規模の経済を実現し、コスト削減メリットを活用するのが戦略の基本だった。
一方、ソフトウェアビジネスでは、人月の経験則の通り、プロジェクトメンバーが増えるほど生産性は限界逓減する。
つまり、少ない優秀なメンバーでソフトウェア開発をやり抜く方が生産性が圧倒的に高い。
そのやり方を実現した方法の一つがアジャイル開発であり、スクラムである、と捉えた方が、より真実に近づける気がする。

ブルーカラー労働者主体、事務処理主体のホワイトカラー主体の社会では、設備や人員を大量にかき集めて規模の経済で圧倒する戦略がビジネスモデルの基本だった。
一方、専門技術職のホワイトカラー主体の社会では、メンバー個人の能力をいかに活用できるか、が鍵を握るし、そのための労働環境づくりが大事になってくる、というストーリー。

規模の経済については以前、色々考えていた。
今でも事業を発展させていくと、必ず規模の経済に即した経営戦略を取らざるを得なくなるが、一方でソフトウェアビジネスを生業にする場合は、スクラムのような個のスキルで駆動する開発スタイルを取り入れるべきという考え方も持っておきたい。

ビジネスの基本戦略には規模の経済があるのではないか: プログラマの思索

規模の経済と経験曲線効果のメモ: プログラマの思索

ソフトウェアの複雑性は本質的な性質であって偶有的なものではない: プログラマの思索

| | コメント (0)

2021/07/04

マッキンゼーの報告書「2030 日本デジタル改革」が手厳しい


マッキンゼーの報告書「2030 日本デジタル改革」が手厳しいと感じたのでラフなメモ。
【参考】
2030年に向けた日本のデジタル改革 | McKinsey
ホームページ | Digital Japan 2030
2030 日本デジタル改革~デジタル競争力と生産性を向上させるための大胆な一手
ソフトウェアの政治的影響力とは何だろうか: プログラマの思索
みんなのPython勉強会#65の感想~社会変革の鍵はIT技術者にあるのかもしれない: プログラマの思索
デジタル庁が解くべき課題とITエンジニアの役割の勉強会の感想~CTOの役割とは何ですか?: プログラマの思索
プログラマとスクラムが社会実装を変えていく #Findy_GovTech: プログラマの思索
デジタル庁が解くべき課題とITエンジニアの役割の勉強会の感想~CTOの役割とは何ですか?: プログラマの思索
【1】2030 日本デジタル改革~デジタル競争力と生産性を向上させるための大胆な一手によれば、日本と世界の対比は下記になる。
日本 → 世界
デジタル競争力 27位 → 米国:1位
デジタル人材割合 1% → 米国:3%
ソフトウェア関連プログラムを開講する大学の数 29 → 米国 117
行政: デジタル行政アプリを使用する市民の割合 7.5% → エストニア:99%
スマートシティランキング - IMD 79位 (東京) → シンガポール:1位
モバイルバンキング浸透度 6.9% → 中国35.2%
ITコストに占めるクラウド割合 3% → 米国10%
時価総額のスタートアップ割合 1% → 米国31%
ユニコーンの数5社 → 米国320社
(引用開始)
日本にとってデジタル化はもはや選択肢ではなく、必須である。最新の動向を見ると、日本のデジタル競争力が低下しているため、日本が世界第三位の経済的地位を維持することは不可能になるだろう。
2020年のIMD 世界デジタル競争力指数によると、日本の世界ランクは27位で、2015年と比べて4つ順位を落としている( 図表2)。
アジア経済において、日本のデジタル競争力は、シンガポール、香港、韓国、台湾、中国、マレーシアに次いで7位にランク付けされている。
他の国々は、デジタル化をいち早く推進するために懸命に取り組んできた。
香港はここ5年間で14位から5位に、韓国は18位から8位に、中国は33位から16位に、それぞれ世界ランキングを上昇させている。
(引用終了)
日本でもITを強化すべきだ、という議論は20年以上前からずっと言われてきた。
しかし、なぜ世界と比較すると、日本の地位は低いのだろうか?
ITコミュニティに参加している限り、日本のIT技術者も危機感を感じているし、実際に色々行動している人も多い。
ソフトウェアに関係する企業、従事者もそんなに少なくないはずだ。
この原因は知りたい。






| | コメント (0)

2021/06/26

PMBOKガイド第7版はアジャイルの観点へ大幅に内容が変わるらしい

PMBOKガイド第7版はアジャイルの観点へ大幅に内容が変わるらしい、という記事をメモ。
これが本当なら、昔のPMBOKで習得した知識は捨てて、新しいPMBOKで習得し直すくらいの激変と思う。

最新情報:PMBOKRGuide 第7 版 への変更について - JPSビジネスカレッジ

あきやま??さんはTwitterを使っています 「PMBOKの第7版が大幅に変更されるとTLで読んで、変更ポイントをググったら、プロセス重視からアジャイル的な方法へシフトしたということなのかな。よき。 https://t.co/aPO0o7siVG」 / Twitter

akipiiさんはTwitterを使っています 「PMBOKも10の知識エリアから8つのパフォーマンスドメインへ、成果物から価値へ変更されるのか。今までの知識は古くなるな。最新情報:PMBOKRGuide 第7 版 への変更について - JPSビジネスカレッジ https://t.co/Rq1ycVgO8i」 / Twitter

「PMBOKガイド 第7版への変更のポイント」を読むと、QCDのコントロールを基盤とした予測アプローチから、不確実性のもとで価値提供を重視したアプローチに変わるらしい。
気になる変更箇所は下記がある。

・これまでのようなプロセス重視ではなく、原理・原則(プロジェクト・マネジメント・プリンシプル)に基づいて再構成される。
・インプット・ツールと技法・アウトプットの記述がなくなり、大幅にコンパクトになる。
・成果物ではなく、価値(価値提供)に焦点が当てる。
・”10の知識エリア”が、”8つのパフォーマンスドメイン”に変わる
・”5つのプロセス群”が、”プロジェクトの提供における12の原則”に変わる

PMBOKといえば、5つのプロセス群、10個の知識エリアが有名だった。
それが全てなくなるらしい。どんな内容に変わるのか、結局本を読まないと分からない。

PMBOKといえば、有期限のあるプロジェクトのQCDをいかに守って、予実管理をベースに予測可能な状態へコントロールしていくPJ管理手法のイメージだった。
PMBOKの技法を読んで実践してみると、プロジェクト計画フェーズに感覚的に8割以上の労力を注いで緻密に計画して、そこから予実管理で差異分析しながらQCDを守っていく感じ。
だから、請負契約でソフトウェア開発を行う場合、PMBOKの手法は発注者のプロマネにはとても相性が良く、一連の知識体系が揃っていて役立っていたと思う。

しかし、コロナ禍の時代では、1年先、いや今ではオリンピック終了後の3ヶ月先の予測すら難しい。
いくらプロジェクト計画を緻密に作った所で、こんな時代ではすぐに現実に対応できなくなる。

だから、「第7版は、このような様々な変化に対応し、先を見越した、革新的かつ機敏な対応ができるような柔軟性を与えることを目的とし、プロジェクトに携わる人々が、予測的アプローチ、アジャイルアプローチ、適応的アプローチ、ハイブリッドアプローチなど、各プロジェクトに適したアプローチをより柔軟に選択できるようになります」という方向に変わるらしい。
PMBOKをまとめた人は本当にすごいと思う。
この記事だけでは当然全くわからないので、一度読み直してみたい。

特に直近1年間、自分が持っていた経験や知識があっという間に古くなっていると痛感する。
アジャイル開発もPMBOKも品質管理も、もちろん他の分野も急激に何かが変化している気がする。
この時代の変化に追随していくために、色々調べてみる。

(1) Yuji SakataさんはTwitterを使っています 「これ日本のPMの人、どうすんの的なところある」 / Twitter

(1) akipiiさんはTwitterを使っています 「@Bondra PMBOKから、今までのプロマネが習得したであろう、10個の知識エリア、5つのプロセス群が全てなくなります。PJ管理のバイブルの内容が一夜にしてガラリと変わってしまった感じなのですが、現場のプロマネはどうするのでしょう??」 / Twitter

| | コメント (0)

2021/06/23

DXとは組織論である

DXとは組織論である、と思った。
適当なラフなメモ。

【参考】
最近読んだ本 - ブログ@kaorun55

(引用開始)
3月、4月くらいからいろいろ本を読み始めました。
主に人、組織、技術の実装あたりです。
最近はHoloLensの土台としてのDXの必要性を感じているのですが、DXは実際には組織論だと考えていて、自分の組織含めて組織の考え方について触れるようにしています。
(引用終了)

DXとは「1980年代の呪縛」を解き放つこと|市谷 聡啓 (papanda)|note

(引用開始)
あるミーティングで、何気ない流れの中である人が言った「DXとは組織を変えることだ」と。その言葉が特に何の違和感も、言い過ぎ感もなく、その場で受け止められて、皆の血肉となるよう消化されていく。凄い時代を迎えたと思った。
組織を変える。経営からマネジメント層、現場まで、気負いなくその言葉があげられる。もちろん突きあげられるような危機感とともに、その言葉が口にされる組織もある。いずれにしても、単なるフレーズではない。大いなる共通の目標となっている。
(引用終了)

kaorunさん、市谷さんのBlogをたまたま読んで、2人とも同じような意見「DXとは組織論である」を書かれていた。
2人ともすごい方だが、同じような問題意識を持っている点に興味を持った。
たぶん、今のコロナという時代では、心あるIT技術者は、DXの本質は何だろうか、と考えているのではないだろうか?

僕は、「DXとは組織論である」という意見は2つのコンテキストを持っていると考える。
1つは、ソフトウェア開発に向いた組織構造は何か?という問い。
もう一つは、ユーザ企業の情報システム部門が、社内の業務システムを一括コントロールするためにはどんな組織形態や運用制度が必要なのか?という問い。

前者は、逆コンウェイ戦略の観点の話になる。
つまり、アーキテクチャは組織に従う、というコンウェイの法則によって、ソフトウェアはどんどん複雑化して肥大化して手に負えなくなるのだから、それを逆手に取って、ソフトウェア・アーキテクチャを開発チームが制御できるように、アーキテクチャに合った組織構造を作ってしまえ、ということ。
最終的には、スクラムチームを作ることと同義。
それは、単なるソフトウェア開発チームだけでなく、全ての部署がスクラムチームになることと同義。

逆コンウェイ戦略のメモ~望ましいアーキテクチャを促進するためにチームと組織構造を進化させる: プログラマの思索

マイクロサービスアーキテクチャはなぜ最近になって注目されるのか~マイクロサービスは組織論の側面も持つ: プログラマの思索

しかし、従来の製造業のビジネスモデルに適した組織構造では、ソフトウェア開発に適した組織構造がとても作りにくいのだ。
そして、ソフトウェア開発に向いた組織文化は、従来のビジネスモデルに適した組織文化と全く異なるので、そのまま組織を作っても、組織文化をトップダウンで適用してもうまく行かない。
「文化は構造に従う」「アーキテクチャは組織に従う」経験則に縛られてしまう。

だから、ソフトウェア開発に向いた組織を作るには、出島を作ったり、関連子会社で別会社にするとか、そういう携帯にならざるを得ない。

文化は組織構造に従う: プログラマの思索

後者は、今の日本政府のデジタル庁で悪戦苦闘している問題点と同一と思う。
日本の大企業はどこも、皮を剥いで中身を見れば、事業部制組織という中小企業の連合体になっている。
だから、プロフィットセンターである事業部が利益に物を言わせて、自分たちの好きなように業務システムをどんどん社内に勝手に作った結果、数多くのメインフレームがまだたくさん稼働した状態で蛸壺となってしまって、コストセンターである情報システム部門はそれらを制御する権力もなく、社内のシステムが野放図になって、IT統制もできていない、みたいな感じ。

今まさに、もう一度、情報システム部門が全ての事業部から業務システムを取り上げて、決められた予算や今後の経営戦略に従って、システムの新規開発やリプレースのロードマップを計画し、セキュリティ面や個人情報保護、コンプライアンスも含めた観点で作り直そうとしている、みたいな感じ。
本来であれば、もっと以前から、メインフレームは撤廃して2025年の崖の問題はとうの昔に片付けて、オープンなアーキテクチャを元に、守りの業務システムよりも、ビジネスに直結するシステムを開発してどんどんビジネスを拡大させていく、みたいなイメージでやりたい。

しかし、デジタル庁の問題も同じく、今まさにそういうことを、地面0メートルの所から巨大なビルを作り出そうとしているわけだ。
たぶん、どこの日本企業も、レガシーなメインフレームの業務システム、あるいは、古すぎてセキュリティ上危ない業務Webシステムをたくさん抱えて、二進も三進も行かなくなっている。

僕は、DXとは、既存ビジネスを持つユーザ企業が、ソフトウェアを根幹としたビジネスモデルを構築して変革していくことと思っている。
そのためには、結局、古い数多くの社内システムを一括コントロールし、捨てるべきシステムは捨てて、システム保守に多額のコストを払うのではなく、売上拡大につながる新たなシステムへ投資できるように、経営判断を促す仕組みを作るべきだ。
そういうことが求められているのだろうと思う。

IPAがDXのパターン・ランゲージを公開している~新しい組織文化が新しい経営戦略を生み出す: プログラマの思索

「ソフトウェアが世界を飲み込む理由」「ソフトウエア、それが問題だ」の記事のメモ: プログラマの思索

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

デジタルトランスフォメーションとはソフトウェア企業になることを意味する: プログラマの思索

マイクロサービスアーキテクチャはなぜ最近になって注目されるのか~マイクロサービスは組織論の側面も持つ: プログラマの思索

ソフトウェアが世界を動かす時代: プログラマの思索

| | コメント (0)

2021/05/22

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

本日の第20回東京Redmine勉強会の感想をメモ。
Redmineを思いもつかない利用シーンで使われる事例ばかりで、久しぶりに刺激を受けた。

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

【オンライン開催】第20回redmine.tokyo勉強会 - connpass

2021/5/22 第20回勉強会 - redmine.tokyo #redmineT - Togetter

【1】@g_maedaさんの講演で、Redmineは細かな機能改善だけでなく、セキュリティ強化にも注力している印象を持った。
たとえば、2要素認証、通知メールのドメインの制限など。
OSSとはいえ、セキュリティホールがあると企業の基幹業務では使えないが、Redmineは世のトレンドの追随して、セキュリティのパッチもいち早く当てて対応しているのは信頼が持てる。

akipiiさんはTwitterを使っています 「二要素認証がVer4.2で機能追加された。Redmineを外部インターネットに公開する時は、このコロナ時代でDX時代では、もう必須の機能ですね。 #redmineT」 / Twitter

akipiiさんはTwitterを使っています 「チケット更新メール通知機能の制限強化。セキュリティ面の強化は、Redmineをエンタープライズ面で利用するために必須。ISMSの観点でも必須。 #redmineT」 / Twitter

また、メール送受信のEndToEndでデータを暗号化通信するMIMEプラグインを使った事例もあった。
つまり、SMTPやPOP3という、今となっては相当古いプロトコルであっても、暗号化通信で機能強化することで、Redmineの通知メールを安全に取り扱うこともできる。

akipiiさんはTwitterを使っています 「Redmineの最新バージョンの2要素認証、メールドメインの制限、に加えて、MIMEプラグインでメールの暗号化でセキュリティ強化に貢献できた、と。 #redmineT」 / Twitter

UIの使いやすさも重要だが、セキュリティ機能の強化でユーザが安全に使える安心感をもたらすことも重要だから。

【2】Backlog x Redmine対談では、プロジェクトマネージャに必要とされる能力や役割が、コロナ時代やリモートワークによって急激に変化した印象を持った。

akipiiさんはTwitterを使っています 「プロジェクトマネジメントという言葉が嫌なのは、元請けSIのマネージャと下請けプログラマの開発者、みたいな役割が固定されてしまう響きがあるから。どうしても契約上の力関係がより強固になり、自発性を生み出さない、心理的安全性を生み出さない雰囲気がある。 #redmineT」 / Twitter

akipiiさんはTwitterを使っています 「チケット駆動の開発スタイルでは、マネージャの指示によるマイクロマネジメントは正直やりにくい。細かい作業が膨大になってチケット保守はマネージャ1人では回らないから。 #redmineT」 / Twitter

akipiiさんはTwitterを使っています 「結局、担当者にチケット保守を権限移譲して回す方針でないと、チケットは腐りやすい。マネージャ、開発者の役割は関係なく、チーム一体でチケットを消していくゲームにする。それがチケット駆動開発と思います。 #redmineT」 / Twitter

akipiiさんはTwitterを使っています 「MoreEffectiveAgileに出てくる「開発チームをブラックボックスとして扱う」「マネージャはチームのInputとOutputだけを管理して作業の中身はマイクロマネジメントしない」やり方はチケット駆動開発に活かせると思います。 #redmineT」 / Twitter

akipiiさんはTwitterを使っています 「#redmineT マネージャも担当者もリーダー経験があると、マネージャはチーム管理が本当にやりやすくなると思います。リーダーの苦労が分かるので、先取りして準備段取りしてくれる。」 / Twitter

akipiiさんはTwitterを使っています 「ヌーラボでは、データを整備して意思決定しようとする環境を整備しようとしています。エビデンスベースドな意思決定は企業も政府も求められますね。チケット管理ツールはそのデータ基盤を与えてくれると思う。 #redmineT」 / Twitter

akipiiさんはTwitterを使っています 「そうそう、門屋さんが言うように「自分がやったことがない技術を使ったシステム開発をマネジメントをする必要がある」。だからPJ管理力に要求される能力は非常に難しくなってきたと思う。特に複数ベンダーに開発委託する案件のマネージャは本当に大変。 #redmineT」 / Twitter

【3】もう一つは、チケット管理に至った結果までの道のりが、各発表者ごとに全く違っていたことも興味深かった。

たとえば、Googleスプレッドシートの情報をRedmineに集約する。
たとえば、チャットや描画ツールでラフな議論をした内容をタスクや課題としてBacklogに落とし込む。
たとえば、工場の現場でExcelのタスク管理をExcelライクなUIにお化粧してRedmineに載せる。
たとえば、全社のワークフローシステムは既にあるが、一つの事業部内の事務処理フローはRedmineに一元化して、全ての申請承認フローを載せた。

たとえば、コロナ感染サイトをRedmineで作った。
たとえば、人や店の地理情報をGoogleMapのAPIを使ってチケット情報に載せた、とか。
たとえば、RPAを使って、テストケースをRedmineに書いて、テストを実行し、テスト結果をExcelに吐き出して、それをチケットに添付して、チケットを更新する一連の作業を自動化する、とか。

とにかくいろんな発想、モチベーションを元に、チケット管理ツールを使いこなそうとしている。

akipiiさんはTwitterを使っています 「#redmineT 今日の勉強会で面白かったのは、Redmineがテーマなのに、Redmineという言葉の同音異義語が多かったこと。工場もあれば、事務の人も使うし、コロナ情報サイトでも使うし、チケット管理に至るまでの道のりも違うのに、参加者同士で話が通じ合うのもすごい。」 / Twitter

akipiiさんはTwitterを使っています 「ヌーラボでは、チャットのTypeTalkや描画ツールCaCooなどを使っている。何となくこんなのはどうなの?という話や雑談に近い話はBacklogだけでは吸い上げられない。そこでこんなイメージを絵にしたり、オンライン会議したり、色んなツールを駆使してる。 #redmineT」 / Twitter

akipiiさんはTwitterを使っています 「ヌーラボでは、モヤモヤしたテーマや話を見える化した後でBacklogのチケットに書いて、管理しやすくする。門屋さんの場ではGoogleスプレッドで何でも書いてしまうのでRedmineに情報を集約しようとする。チケット管理ツールに行き着く道が違うのが面白いね。 #redmineT」 / Twitter

akipiiさんはTwitterを使っています 「情報の乱雑度合い、散在度合いを下げるために、チケットに集約してエントロピーを下げようとする。その道程は、アイデア発散→課題に収束のパターンもあれば、あちこちのデータを集約、のパターンもある。#redmineT」 / Twitter

akipiiさんはTwitterを使っています 「全社WFの社内システムはあるが、組織内のWFシステムはないのでExcel管理になってしまう。そこでRedmineで組織内WFを構築して上手くいった。あるある。これいいですね! #redmineT」 / Twitter

akipiiさんはTwitterを使っています 「都道府県=PJ、感染者=チケットに割当。Redmineの機能にフィットギャップ分析してる。ViewCustominze、MessageCustomize、Tagsなどのプラグインでチケット一覧の見た目をかなりカスタマイズしている。 #redmineT」 / Twitter

あさこさんはTwitterを使っています 「データを可視化するときに、頭の中でDBが動いてた次元構造化をされたんだろうな・・・めちゃくちゃセンスのよさと頭の良さを感じる・・・DBの知識かなり深い方なんじゃないだろうか・・・ #redmineT」 / Twitter

akipiiさんはTwitterを使っています 「RPAでテストして、テスト結果をExcelに書いて、チケットに添付して、チケットを更新する一連の動作を、RPAで実現した事例。RPAはWindows10でも簡単に使えるので色々試せそう。 #redmineT」 / Twitter

akipiiさんはTwitterを使っています 「Shelperのイメージは、チケットにテストケースを書いたら、チケットの更新時に、RPAがキックされて、シナリオ通りにテストされてテスト結果をExcelに残し、それをチケットに添付する一連の動作が自動化された、わけか。Redmine+RPAでテスト自動化ツールになるイメージかな。 #redmineT」 / Twitter


【4】だから、「なぜ、Redmineを使おうと思ったのか?」という理由を講演者に聞きたくなる。

昌。さんはTwitterを使っています 「#redmineT だからなぜこれをRedmineでやろうと思うのw」 / Twitter

akipiiさんはTwitterを使っています 「#redmineT Redmineは、改革者を、何にでも解決できそうなツールに惑わせるのです。理由はないのですw」 / Twitter

y503Unavailable@Redmine Kindle本出版unofficialcookingさんはTwitterを使っています 「@aj15_aj15 そこにRedmineがあるから #redmineT +そこにRedmineTokyo勉強会があるから」 / Twitter


【5】Redmineがもたらす組織面の効果は、はっきりとあると思う。
たとえば、Redmine利用者がシステムの機能やUIに目が肥えてしまい、社内のシステム保守担当者に厳しく要求する場合も増えた、という話もあった。

akipiiさんはTwitterを使っています 「Redmineを利用する事務の社員がシステムを見る目が厳しくなって、他システムへの八つ当たりが大きくなった笑 これは良い副作用?効果?ですね。 #redmineT」 / Twitter

たとえば、工場の現場ではベテランが経験を元にノウハウを伝承するが、若手はツールにすぐに慣れるので、逆に若手からベテランにRedmineの使い方を教え合う、という相互作用が生まれた、とか。

たとえば、Redmineの予実管理の機能を使って、見積もり能力を鍛えることができるよ、というメッセージ、とか。

yukiaさんはTwitterを使っています 「工数の予定と実績の管理をチームがしてる時点で、 そのチームは本当にすげぇと思う。 それがボトムアップ発なら、もう奇跡なんじゃないかとすら思う。 #redmineT」 / Twitter

akipiiさんはTwitterを使っています 「#redmineT 工場などの製造業では、工数管理は非常にシビアなので、予定工数と実績工数の管理は、作業管理と同じくらい重要でした。デメリットは、工数管理の間接作業の工数が割と多すぎて非効率な場面もあることですね。」 / Twitter

【6】グループディスカッションで話をしながら、プロジェクトマネージャに必要な能力は何だろうか?と考えていた。
僕は、一つは見積もり能力、もう一つはリスク対応力、と考えている。

akipiiさんはTwitterを使っています 「見積もりスキルのギプスとしてのRedmine。マネージャの能力の大半は「見積もり」能力と思っている。 #redmineT」 / Twitter

僕の数少ない経験上、プロジェクトマネージャの仕事の大半は計画づくりだ。
実際、PMBOKでもプロジェクト計画フェーズだけで、PMBOK本の半分を占めている。
スクラムやアジャイル開発でも、緻密で精細な計画で確定した計画ではないが、チームの開発の羅針盤としての計画は必ず作る。

その計画づくりに必要な能力は、見積もり力とリスク対応力。
これくらいの作業工数がかかる、これくらいの開発規模になる、という予測がなければ計画は作れない。
もちろん、要件定義前の企画フェーズでは、見積もりの精度は低いが、見積もりに必要な要素を探し出そうとすることで、システムのあるべき姿を描いていく。
最初は見当外れに近い仮説かもしれないが、イテレーションを経るごとに、段々と骨格が定まっていき、あるべき姿は明確化されていくので、見積もり精度も後になるほど高くなる。
アジャイル開発では、検査と適応により、フィードバックを重視するので、ソフトウェア開発にも学習による経験曲線効果を活かすことがきると思う。

また、プロジェクトのリスクがどこにあるのか、をいち早く検知することも大事。
マネージャは船の船頭みたいなもので、プロジェクトは一度動き出すと統制を取るのは難しいが、何とか、前進方向を保とうとする。
岩場にぶつかったり、天候異変で思わぬ方向に行きそうになったり、予測しきれない場面もがあるが、そういう場面をあらかじめリスクとしてイメージできるようにしたい。
リスクを全て洗い出すことは難しいが、リスクを拾っていき、そのリスクを自身で保持するのか、別の人に転嫁するのか、リスクの事後対応策や予防策を準備するのか、をイメージしながら、進めていく。

とはいえ、実際は難しいとは思う。
特に、内製開発チームのように、全てのリソースがマネージャの手の内にあればコントロールしやすいが、ステークホルダーが多く、複数ベンダーに開発を委託している案件であれば、複雑なパズルを解くような感覚になる。

【7】Redmineの面白さは、Redmineというツールがたくさんの可能性を秘めているだけでなく、Redmineを使って問題解決する人たちがこういうコミュニティに集まって議論できること。
コロナ感染サイトのように、Redmineをこんな所に使う発想、なんて誰が予想できただろうか?

実際にサイト運営者の方にお話を聞いたら、すごい悲壮感を持っているわけでもなく、なにか作ってみたかった、という気持ちから実現された、とのこと。
仕事はソフトウェア開発に直接関係しないのです、と謙遜されていたが、PythonのPandasでデータをパースしたり、Python-Remdine APIでRedmineにデータを取り込んだり、5種類以上のプラグインを駆使してUIをカスタマイズしたり、本当にいろんな技術を試されているのは、すごい。

自分が持っているアイデアやモチベーションを元に、即座にアイデアを実現できるツールの一つとして、Redmineがある。
僕自身も改めて、モチベーションをもらった感じ。


| | コメント (0)

2021/05/14

日本人の弱点は忖度しすぎること、理論化できないことではないか

4月末と今夜、平鍋さんがアジャイル開発について語る勉強会を聞いた。
日本人の弱点は忖度しすぎること、理論化できないことではないか、という気づきをラフなメモ書き。

【参考】
今こそ必要な実践知リーダーシップとスクラム - connpass

BPStudy#164?アジャイル開発とスクラムの今を語ろう - connpass

【1】野中先生の肉声を初めて聞いた。
86歳らしいので、平成上皇と同い年らしい。
すごくハキハキした口調で、英語の論文にも慣れているのだろうか、知的バトル、とか、割と英単語が出た。

スクラムを生んだジェフがすごいのは、ベトナム戦争で偵察機の経験があったこと。
その経験をベースに、スクラムを生んだ。
ソフトウェア開発の手法は幾多数多あるが、それを理論化できたのはジェフがフィロソフィーを持っていたから。

野中先生の論文でも、スクラムでも、共感ありきで始まる。
欧米の哲学は、デカルト以来、コギト、我思う故に我あり、から始まるが、そうではなく、共感をベースにした。
だから、上手くいく。

一方、日本人は、元々共感力があるので、スクラムをやるのにもっと共感を重視しようとすると、忖度しすぎてしまう。
忖度するのではなく、もっと知的バトルをすべきだ、と。

僕らの頃は、ジャパン・アズ・ナンバーワンと言われていたが、DXの流れに乗れず、今はその面影もない。
だから、またジャパン・アズ・ナンバーワンを目指してほしい、と。

【2】日本人の弱点は忖度しすぎること、理論化できないことではないか、という考えを思い巡らすと、今まで読んできた本のいろんなフレーズを思い出してくる。

【3】「採用基準」「生産性」はマッキンゼーの元コンサルが、日本人や日本の組織に足りない要素2つを書いている。
それは、日本人には問題解決リーダーシップの能力が足りないこと、問題解決の生産性の意識が低いこと、の2つ。

リーダーシップ経験のない日本人が多すぎるから、評論家ばかりで、実際の問題を泥臭く解決していこうとする能力も意識も低い。
リーダーシップとは、自分の意見を持ち、周囲を巻き込んで、リスクを取って、問題を解決していく。
しかし、リーダーシップを発揮する日本人は、出る杭は叩かれる、ばかりに思われるので、たぶん自然に忖度してしまう。

また、生産性をコストダウンの事ばかり考えすぎる。
日本人が得意なプロセス改善の手法は、コスト低減による付加価値を上げる手法の一つに過ぎない。
生産性=付加価値/コストで考えるならば、コスト低減よりも、付加価値を圧倒的に増やす方がはるかに生産性は上がるはず。
しかし、日本人サラリーマンは斜陽産業でコスト低減ばかり経験しているので、ホワイトカラーが付加価値を上げるために、今までの手法を捨てて、全く新たなアイデアや手法を採用して、リスクを取っていく、という発想も能力もない。

【4】「経済数学の直観的方法 マクロ経済学編」では、世界の経済戦争の重心が、製造業の競争力強化から、世界全体の資金の流れを上手く誘導して流す方向に変わってしまった。
しかし、日本は、製造業があまりにも成功したので、マクロ経済学における動的均衡理論を取り入れる機会を逸してしまった。
そして、世界中の中央銀行がインフレターゲット政策を運用し始めた頃、慌てて、動的均衡理論を学習しようとしたが、従来のケインズ経済学とは異なり、解析力学をベースとした高度な数学理論を使うので、とても学習しづらい。

ちょうど、欧米では、これを学んだ人たちが政治経済の中枢に占めているのに、日本では学習し損なった世代がブランクになり、そのギャップを埋めることが難しい状況らしい。

かつて、日本では、ケインズ理論に従って、政府の公共政策による景気浮揚策は良いことだ、という理解が、割と世間の人たちも認識が共有されていた。
ちょうど、その頃は、日本の製造業が無敵の時代だった。
しかし、コンピュータやITが直近の四半世紀でまたたく間に普及して、ITなしでは生活もビジネスも経済も成り立たなくなった。
経済学の主導権もケインズ理論から動的均衡理論に代わったが、日本は追いつけていない。
さらに、世界中の資金を自国に誘導するように、情報や経済理論を整備して発信していく、というやり方に日本は乗り遅れてしまった。
「ミクロでマクロを制する」という発想は、日本人は弱いらしい。

【追記】
平鍋さんが「先生へお礼のメッセージを送ろう」とtwitter 上で平鍋がよびかけ、集まったコメントが公開された。

野中郁次郎先生へのみなさんからの手紙

自分のコメントも掲載されていて恥ずかしい。
今一度読み直すと、日本人には共感力よりも、知的バトル、知的コンバットが必要なのだろう。
つまり、対立することを恐れず、もっと知的論争をすべきであり、お互いにもっと衝突して、その後で握手する事が大事なのだろう。
知的論争に忖度は無駄。


| | コメント (0)

2021/05/08

『オブジェクト指向でなぜつくるのか』第3版が出版された

『オブジェクト指向でなぜつくるのか』第3版が出版されたのでメモ。

【参考】
『オブジェクト指向でなぜつくるのか』第3版

オブジェクト指向でなぜつくるのか 第3版|日経の本 日経BP

「オブジェクト指向でなぜつくるのか」は良い本だ: プログラマの思索

「オブジェクト指向でなぜつくるのか」は良い本だ: プログラマの思索では、第2版を改めて読み直してみた。
オブジェクト指向プログラミングがヒープ領域を使っていることから、UMLによる汎用の整理術、XPに至るまでのアジャイル開発、そしてパターン言語まで幅広い。
こういう一大ストーリーでまとめているのはすごいと思う。

僕が思うに、オブジェクト指向の考え方をアジャイル開発、特にスクラムに適用している所が一番興味はある。
たとえば、「More Effective Agile “ソフトウェアリーダー”になるための28の道標」では、「スクラムチームはブラックボックスとして扱うべきだ」という主張が何度も使われている。
つまり、スクラムチームはInputとOutputだけ管理すればよく、プロジェクトマネージャはマイクロマネジメントする必要はないし、マイクロマネジメントすべきでない、という主張が一貫して流れている。
これもオブジェクト指向のカプセル化がわかっていれば、とても腑に落ちる。

More Effective Agileは良い本だ: プログラマの思索

「オブジェクト指向でなぜつくるのか」本はずっと読まれ続けてほしいと思う。

| | コメント (0)

astah*の因果ループプラグインがいいね

astah*の因果ループプラグインを教えてもらったのでメモ。
使ってみるとなかなか良いです。

【参考】
snytng/inga astah*の因果ループプラグイン

思考力と注意力のトレードオフを因果ループ図で描いてみた: プログラマの思索

因果ループ図を再考する~問題の症状をシステム構造として捉えて解決策を見つける: プログラマの思索

astah*の因果ループプラグインのメリットは、因果ループ図からロジックをリバースしてくれること。
要因Xが増えれば、要因Yが増えるのか、要因Yが減るのか、表示してくれる。
ロジックを見直す時に役立ちそう。

【1】教員希望者が減っているニュースを見て、その背景にあるロジックを書いてみた。

教員の過酷な労働実態相次ぐ投稿でオンライン上の報告会開催 | 教育 | NHKニュース

小学校教員倍率、過去最低2.7倍 質の確保急務: 日本経済新聞

Photo_20210508114201

ニュースでは、下記のロジックが読み取れる。

「教師希望者」が増えれば、「教師の質」が増える: 1 (自己強化=1, バランス=0)
→「教師の質」が増えれば、「モンスターペアレント」が減る: 1 (自己強化=1, バランス=0)
→「モンスターペアレント」が減れば、「教師の作業負荷」が減る: 1 (自己強化=1, バランス=0)
→「教師の作業負荷」が減れば、「教師希望者」が増える: 1 (自己強化=1, バランス=0)

そこで、教師希望者を増やすために、教師増加キャンペーンを実施したわけだが、本当に効果があるのか?
レバレッジポイントはそこなのか?
他の要因を増減させるような施策の方が優先ではないか?

他にも隠れたロジックがないか?
色々考えが思いつく。

astah*の因果ループプラグインの他の機能では、下部欄の因果関係をクリックすると、因果ループ図の線にフォーカスしてくれる。
ただし、Same(+)は実線、Opposite(ー)は破線なので注意。

| | コメント (1)

2021/04/29

デジタル庁で応募中のアイデンティティアーキテクトは昔のDAと同じ役割か?

デジタル庁でアイデンティティアーキテクト、データアーキテクトを応募しているツイートを見つけたのでメモ。
ラフなメモ書き。

【参考】
yoshi sanさんはTwitterを使っています 「アイデンティティアーキテクトなる独立したポジションがあるんだ。」 / Twitter

からくりさんはTwitterを使っています 「アイデンティティアーキテクトってなんだよと思ったけどめちゃまともな内容だった」 / Twitter

Yoshikazu NojimaさんはTwitterを使っています 「デジタル庁のアイデンティティアーキテクト、超重要かつ超高難易度な仕事にしか見えないのだけど、どんなキャリアパスを積んで、どれほどの研鑽を積めば担えるのか想像もつかない。 https://t.co/2iU02v4WLr」 / Twitter

akipiiさんはTwitterを使っています 「アイデンティティアーキテクトとは、昔のDAと同じ役割か?」 / Twitter

からくりさんはTwitterを使っています 「アイデンティティアーキテクト?- 中途採用|デジタル庁創設に向けた準備サイト https://t.co/raIDjeGhb9 めちゃくちゃ楽しそう(発狂しそうなほど大変だと思うけど)」 / Twitter

ミジンコOLさんはTwitterを使っています 「アイデンティティアーキテクト、あの先輩しか思い浮かばない。 ・行政証明書コンビニ交付サービスの開発経験有 ・某メディア企業の大型サービス利用ID統合経験 ・プラポリにも詳しい ・認証・認可詳しい ・IPA上級資格9割持ってる ・泥臭いPJTの中でも爽やか #デ https://t.co/Ue6JVxsyLh」 / Twitter

【参考】
中途採用|デジタル庁創設に向けた準備サイト

『アイデンティティ管理技術解説』システムアーキテクトを志す方のために IPA

【参考1】
アイデンティティアーキテクト?- 中途採用|デジタル庁創設に向けた準備サイト

(引用開始)
募集背景・業務内容
デジタル庁(仮称)においては、行政サービスのデジタル化・ワンストップ化を推進するにあたって、利便性が高く安全な識別・認証の仕組みを構築することにより、多種多様なシステムにまたがった円滑なデータ連携を実現していくことが求められます。

アイデンティティアーキテクトは、各省庁の担当者や専門家と連携して、デジタルガバメントのサービス高度化に必要な、アイデンティティ管理、データ連携の枠組みを構想し、その整備を推進する役割を担っていただきます。

具体的な業務内容は、以下のとおりです。

政府情報システムに関わるアイデンティティ管理の計画策定全般

住民制度、公的個人認証、マイナンバー制度に関わる個人のアイデンティティ管理もしくはGビズID、商業登記電子証明書等に関わる法人等のアイデンティティ管理

行政事務と住民・事業者向けシステム、住民・事業者向けシステム間をつなぐ国のシステムを理解した上での、業務プロセスの見直し、移行計画の立案、変革の推進

国民・事業者向けサービスや各省庁のシステムにおける利便性の高い安全な識別・認証の仕組みづくり

各省庁や地方公共団体の専門家と連携した横断的なプロジェクトの推進
(引用終了)

【参考2】
データアーキテクト?- 中途採用|デジタル庁創設に向けた準備サイト

(引用開始)
募集背景・業務内容
データアーキテクトは、デジタル庁(仮称)において、社会全体のデータの現状と将来像を俯瞰し、データ戦略の策定を主導するとともに、標準やルールに加え基礎データ、プラットフォームなどを整備し、その活用を推進していくことが求められます。また、多数のステークホルダーとの調整を進めながら、デジタル時代の新たなスタンダードを構築していくための強いリーダーシップが求められます。

政府は、多量のデータを保有するデータホルダーとして、またデータプラットフォーマーとして、先導的な振る舞いを期待される立場です。本ポジションは、あらゆる社会・経済活動に不可欠なデータを、国の競争力の源泉とするために、また、豊かな生活を実現する上で不可欠な基盤とするために、中心的な役割を担っていただきます。

具体的な業務内容は、以下のとおりです。

体系的なデータ整備に係る中長期戦略・計画の策定

データ標準・データ連携プラットフォームの整備

政府内におけるデータサイエンスやAIの活用の推進

デジタル庁(仮称)内外のデータに関する人材育成

データに基づいたEBPM(Evidence-Based Policy Making、証拠に基づく政策立案)の推進

国際機関や関係各国との交渉
(引用終了)

【感想1】
デジタル庁でアイデンティティアーキテクト、データアーキテクトの募集背景・業務内容を読むと、本当にガチの内容だ。
個人的には、一昔前のデータアーキテクトの業務を連想する。

その頃は、テーブルを新規追加したり、カラム1個を追加するのに、わざわざデータアーキテクトに申請して、内容の詳細や対応期限を説明して、開発環境にやっと反映される、みたいな牧歌的な時代だった。
データアーキテクトは、ER図やデータディクショナリの保守担当者みたいなイメージを持っていたので、あまりカッコイイ職種には感じなかった。

しかし、実際の業務システムの要件定義では、データモデリングの技量の違いがその後の設計、開発の室に直結する。
業務フローのようなプロセスばかり書いても、フワフワしていて、テストでデスマーチになりがち。
データ基盤がしっかりしていれば、そこから業務の制約条件をプログラマも読み取れるし、テストデータを作ったり、保守していくのもかなり楽になる。

さらに、データアーキテクトの職種だけでなく、アイデンティティアーキテクトという職種まで応募しているのはとても興味深い。
単に、公共サービスのデータ基盤、データディクショナリを揃えるだけでなく、その根本となる一意な主キーを見出し、それを維持管理していく重要性を認識しているのだろう。
もちろん、マイナンバー制度という国民をユニークに識別する仕組みにも直結する。
国民を一意に識別してデータを管理できる基盤があれば、今のコロナワクチン予防接種の履歴管理に使えるし、今後のワクチンパスポートの発行にも発展できる。
他にも、収入や資産の追跡、税の徴収だけでなく、本当に困っている人たちを特定して補助金を直接届ける、という仕組みも作れるはず。

また、アイデンティファイアの整備は、認証基盤にも直結する。
政府の膨大な公共システムを利用する場合に、利用者の国民が安全に利用できるだけでなく、バックエンドの事務に携わる公務員や保健所の人たちが安全にログインできて、その操作履歴をきちんと管理できる仕組みも必要。
さらには多種多様な利用権限の制御まで考える必要もあるだろう。

つまり、価値ある公共サービスを提供するためにデータ基盤のアイデンティファイアは必須要件だが、人権やプライバシーの保護の観点からアイデンティファイアの認証・認可・アカウンティングの機能要件も必須という、高度なハードルがある。
想像するだけでも、アイデンティティアーキテクトという職種は非常にタフで難儀な内容であるのは間違いない。

だからこそ、こういう職種が必要ときちんと公開して打ち出しているのは信頼が持てる。

【感想2】
最近はITコミュニティ以外にも、官公庁の関係者がオンライン勉強会で登壇して色々話してくれる場が多くなった。

直近で、農林水産省とウーオが語る!林業・水産業をITで変えるチャレンジ - connpassを聞いた時、今の官公庁で最もデジタル化が進んでいるのは、実は農林水産省なんです、という発言を聞いて驚いた時がある。
その時の事例では、ベンチャー企業が、漁港で取った魚と都市部の魚市場のマッチング処理のシステムを開発して、お互いの利益を向上させる、という話だった。
他にも林業で、日本産の木材が、今はコロナなので実は高く売れている、そういう市場をITの力で支援している、という話もあった。

おそらく、楽天、メルカリのビジネスモデルのように、生産者と消費者のマッチング処理を農業や水産業の市場に適用して、両者がWin-Winになるような方向を目指しているのだろうと思う。
そんな話を聞くと、単に業務システムを開発したり、ITビジネスでお金を儲けるだけでなく、IT技術を社会の問題解決に適用し、多くの人達のために社会貢献する方向に進化しているように感じた。

| | コメント (0)

より以前の記事一覧