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

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

Slack導入がDXに繋がる話

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

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

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

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

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

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

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

| | コメント (0)

2021/08/29

リーダーシップと意思決定の分布では日本が独特のポジションにある

リーダーシップと意思決定の分布では日本が独特のポジションにあるというツイートをメモ。
ロジカルでないラフなメモ書き。

【参考】
日本企業においてリーダーシップが生まれにくい理由~リーダーシップを取る事の割の合わなさ問題~ - Togetter

心理的安全性は日本企業では実現しにくいかもしれない: プログラマの思索

中野 仁 (AnityA)さんはTwitterを使っています 「リーダーシップと意思決定の分布が日本が独特という話。 階層主義で合意形成を重んじるとなると、上下左右全部に話を通して凄まじいコミュニケーションコストがかかる上に、上と左右からはとりあえず意見だけは言えるのでリーダーに対して投げられる石がだいたい当たるという事では…。 https://t.co/bqHxAufImN」 / Twitter

akipiiさんはTwitterを使っています 「このスレッドのリーダーシップ分析が素晴らしいのでリンクしておく。リーダーシップの適切な日本語訳がないのは、日本人がそういう概念を持ってないと言う恥ずかしい事実。」 / Twitter

中野 仁 (AnityA)さんはTwitterを使っています 「確かにリーダーシップに適切な日本語訳が無いという話に繋がるかも知れませんね。 無理やり似た様な概念をひねり出すと、村長シップ、マイルドヤンキーシップ…みたいな。 義侠心(中国発)かなぁ。」 / Twitter

akipiiさんはTwitterを使っています 「@Jin_AnityA ちきりんさんのVoicyを聞いて、ビジネスや組織戦略、ITにカタカナ用語が多いのは日本語に適切な言葉がない、つまり日本人はそんな概念を生み出せなかったと言う事実に気付きました。リーダーシップは統率力や指導力だけではないです。」 / Twitter

中野 仁 (AnityA)さんはTwitterを使っています 「ボトムアップ&合意によるプロセスの複雑性がわかりやすく出るのがワークフローシステム ・とにかくフローが長い。承認階層が5段階とかある。 ・兼務があちこちにあって分岐の数が多い。例外処理が多い。 ・念の為に参照する人が大量にいる。フローに入ってなくてもひっくり返す事ができる。」 / Twitter

akipiiさんはTwitterを使っています 「ワークフローの複雑さと合意形成のルートの長さは相関関係があるのか、なるほど」 / Twitter

【1】日本人の意思決定やリーダーシップでは、階層主義でボトムアップの合意形成を重んじるタイプ。
一方、アメリカやイギリスは日本と正反対で、フラットでトップダウンのタイプ。
他方、中国やロシア、インドでは、階層主義でトップダウンのタイプ。
なぜか日本だけ特異なタイプになっている。

米英では、フラットに互いに議論して対立しても、最後はリーダーが専制主義のようにトップダウンで決める。
大統領制は民主的な王政に近いスタイルだろうか。

アジアに多い階層主義でトップダウンのタイプは、目に見える身分制度、目に見えない階層があって、専制主義的にトップダウンで決める。
絶対主義王政、東洋的君主制などの過去の歴史を眺めればこのタイプは理解しやすい。

【2】階層主義でボトムアップなリーダーシップを持つ日本は、どんな特徴を持つのか?
目に見えない身分階層は日本でもよく見られる。
建築業界やメーカー、IT業界にはびこる多重請負構造、男女間の目に見えない格差などが思い浮かぶ。
しかも、忖度や根回し、腹芸など日本独特の気遣いもある。

すると、トップは権限を持っていても、実際に権限を振るうとメンバーのサボタージュにあって、にっちもさっちもいかない。
結局、参謀役を使って事前にメンバーに根回しして、ゆっくり推し進めるみたいな感じになる。
ただ、こういうスタイルでなぜ集団主義的傾向が出て、皆が同じような価値観を強いられるのかが不思議だ。
実際は、そういう圧力に反対する人もいるし、力があるなら無視すればいいから。

【3】しかし、なぜ日本だけが階層主義でボトムアップなリーダーシップになりやすいのか?
この辺りは、昭和の頃にすごく流行した日本文化論を思い出す。
日本人は世界から見て特別な人種なのだ、特別な文化を持つのだ、といろんな識者がいろんな観点で解説していたけれど、何かしっくり来なかった気もする。
いくら集団主義的傾向を持つ日本人が多いからと言っても、そこからはみ出た人も多いし、自分の意見をはっきり主張して周囲との軋轢を気にしない人もいるし、一概にそうとは言えない。

【4】こういう傾向を持つ日本人の弱点は、戦略がない点、リーダーシップの経験を持つ人が圧倒的に少ない点だろう。
結局、そういう弱点が今いろんな所で社会に出ているのだろうと思う。
問題は皆分かっているのに、自分の利益を侵害されるとその人達は反対するので、全体最適な観点ではなく局所最適化しやすい。

【5】心理的安全性は日本人の間では非常に難しい文化と思う。
たぶんその理由も、お互いのプライドや人格を傷つけてしまう意識が強すぎるために、忖度や根回し、腹芸のような変なテクニックが必要となり、お互いの心理的安全性を上っ面で維持しようという方向に傾くのだろう。

心理的安全性は日本企業では実現しにくいかもしれない: プログラマの思索

| | コメント (0)

2021/08/18

ベロシティをコース定数で理解する

ベロシティをコース定数で理解する記事がとても良かったのでメモ。

【参考】
アジャイルな見積もりを理解する「コース定数」という概念 - だいくしー(@daiksy)のはてなブログ

Dai Fujihara | mabl(メイブル)ノーコードテスト自動化SaaSさんはTwitterを使っています 「こんな定数あるのか。山の高さや行程ふまえての数値はわかりやすいなー / アジャイルな見積もりを理解する「コース定数」という概念 https://t.co/O5HeylyzvJ」 / Twitter

Miho??NagaseさんはTwitterを使っています 「身近なベロシティのたとえで図らずも山行について学べてしまった / “アジャイルな見積もりを理解する「コース定数」という概念 - だいくしー(@daiksy)のはてなブログ” https://t.co/QMsU1aw12a」 / Twitter

プロジェクトのリスクはコストの増減で管理する: プログラマの思索

【1】アジャイル開発を日本のSIの現場でやる時に、5本の指に入るくらい壁があるのが、ベロシティやプラニングポーカーによる見積もりだろう。
日本のWF型開発案件は、PJ計画時にスケジュール、コストを可能な限り再現性のある絶対数値で見積もらなければならない。
一度決まった見積もりは計画と実績の予実管理のための指標となり、独り歩きして、その見積もりから離れられなくなる。

一方、アジャイル開発では、相対的な数値で見積もりする。
しかも適当な数値ではなく、フィボナッチ数を使って相対的な比較をもって見積もりする。
それをスプリントごとに計測して、実際の実績値を計測し、チームの生産性をベロシティを算出する。
ただし、ベロシティはあくまでも相対比較の数値なので、他チームの生産性と比較することは無意味だ。

WF型開発でもアジャイル開発でも、定量的なデータ管理は必須要件だ。
しかし、その扱いが全く異なる。
つまり、WF型開発は絶対的な数量、アジャイル開発は相対的な数量で算出する。

【2】以前、プロジェクトのリスクはコストの増減で管理する: プログラマの思索の記事で、リスクもコストという数値で定量化して測定すべきなのだ、という気づきがあった。
定量化した数値があるからこそ、洗い出した複数のリスクを比較して、意思決定できる。
そもそも、リスクというからには、リスクを回避したり、リスクを低減したり、リスクを解消するには、それなりの費用がかかるはず。
だから、リスクという、今は潜在的で分かっていない対象を費用という数値で定量化することで、見える化し、意思決定の根拠にするわけだ。

ソフトウェア開発の費用は、スーパーで売っている生鮮食料品、家電量販店で売られている電気製品とは違って、定価や希望小売価格を決めづらい。
なぜなら、価格の妥当性の根拠をとても説明しにくいのだ。
実際、ITに詳しくないユーザ企業の経営者から見ると、こんなボロカスで20年以上前の古いシステムの保守費用がなぜ数千万円、数億円もかかるのか、疑問に思いながらも、ベンダロックインされているためにベンダの言いなりになっているだろう。

その費用や価格を絶対的な数値ではなく、アジャイル開発では、相対的な比較で数量を見積もる点が上手。
相対比較であれば、その判断の根拠も簡単だ。
また、相対比較に必要な数値を算出する作業工数も少なくできる。

一方、WF型開発の見積もりは、プロマネが非常な労力をかけて案を出し、数多くの有識者のレビューを受けて初めて確定するから、見積もりを出すまでの工数が非常に膨大にかかりすぎ。
その割には、その見積もりは不安定であって、要件が少しでも変わってしまえば、その見積もりはすぐに無駄になる。
また1から作り直さなければ、正確な見積もりは定まらない。
なぜなら、要件の要素が一つでも変われば、その影響は要件同士の整合性、後工程へのスケジュール、新たな担当者のスキルなどの数多くの変数を考慮して、正確に見積もる必要があるからだ。
それくらい、WF型開発の見積り金額は、金額の妥当性の根拠を問われるから。

そういうことを考えると、アジャイル開発はソフトウェア開発特有の難しさを上手く飲み込んで対応しようとしているように思う。

| | コメント (0)

2021/08/08

redmine.tokyo10周年を祝う会でふりかえりしました #redmineT

redmine.tokyo10周年を祝う会が開催されたのでメモ。

【参考】
Redminetokyo 10周年を祝う会 - redmine.tokyo

shinagawa.redmine キックオフミーティング が開催されました - secretbase.log

akipiiさんはTwitterを使っています 「https://t.co/i2sJFMVOU3 の初回の打合せの参加者は、割といましたね。@tkusukawa @tech_machii まるやまさんもおられましたね。#redmineT」 / Twitter

はるかさんはTwitterを使っています 「あきぴーさんの記事はこれですね。https://t.co/DjjTZPJ3S2 #redmineT」 / Twitter

redmine.tokyo10周年を祝う会で歴史を堪能する #redmineT | マドびっ! Madosan's View

【1】redmine.tokyoのコミュニティですごいと思うのは3つある。
1つ目は、コミュニティが10年続いたこと。
自分がスタッフとして関わったコミュニティで、熱量が維持されて10年も続いたコミュニティは、redmine.tokyoとSEA関西ぐらいだろうか。
アジャイルのコミュニティも他のコミュニティも、10年も長続きしなかった。
どのコミュニティも浮き沈みがある。
ブームに乗って盛り上がった時もあるが、スタッフが高齢化したり、熱量を持つスタッフが減ってしまったりする。

あるいは、熱量を持つスタッフが複数人いて最初は良かったが、視線のベクトルが異なってしまって、コミュニティとして分離してしまったり、とか。
いくら仲が良くても、思想や性格も違うので、それがきっかけで別れてしまう時もある。

そんな経験を経て、「コミュニティは細く長く続けること」が大事かなと思っている。

【2】2つ目は、redmine.tokyoは初期立ち上げのスタッフが多数残っていること。
@tkusukawaさん、@naitohさん、@ohwadaさん、@haru_iidaさんが残ってくれている。
もちろん離れたスタッフもいるが、10年も続いた縁は本当に長いと思う。
人間関係は長いほど、その人の性格や価値観も分かってくるし、そういう安心感もある。
熱量が減ったとしても、同窓会みたいな感じで戻れる場があるのは心強い。

【3】3つ目は、KPTを10年続けていること。
会社でも、コミュニティでも、KPTのふりかえりを実施している所は少ないのではないか?

第1回勉強会でKPTをWikiに残しているが、当初は僕がちょっとやりたかったという気持ちもあって気軽な感じだった。
それが10年もKPTを続けると、今回の勉強会で試して分かったことや良くなかった点を、次回に活かしたいね、という内容が出てくて、次回の勉強会に活かせるようになる。

年2回の勉強会なので、半年ごとのPDCAサイクルを自然に回していることに、後から気づいた。
KPTの活かし方はこんなものなのかな、と後から気づきが多かった。

【4】僕はコミュニティという場は好きだ。
理由は、コミュニティでは、同じ価値観や問題意識を持っている前提が暗黙的にあるおかげで、誰とでも気軽に人間関係を作れるから。
相手がたとえ社長のような社会的地位が高くて年収が高くても、コミュニティでは全く関係ない。
その人自身に能力があり、人格が優れていて、リーダーシップがあれば、自然に輝くし、自然に人間関係が作れる。
つまり、本音で話せる雰囲気が出やすい。

一方、会社では、組織上の地位や権限、権力関係が人間関係にも現れてくる。
どうしても、腹を割って話すのは難しい。
上司であれば、丁寧語を使ったり、相手におもねったり、忖度してしまう。
営利企業であり、仕事であるから、人間関係に請負契約みたいな雰囲気も出てしまう。

コミュニティではそういう責任がない点もあるだろうが、より純粋な人間関係が現れやすい気がした。

【5】redmine.tokyoも今振り返ると、浮き沈みはあったのではないか、と思う。
立ち上げ当初は、藤原さん、小久保さん、岡本さん、@haru_iidaさんのように、ツールの自動化の連携、アジャイル開発への適用に興味を持つ人が多かった。
あるいは、SIerのプロジェクトリーダーとして、ソフトウェア開発のPJ管理を自動化して、チーム運営する基盤を求めていた。
しかし、Scrumが普及し、ツール自動化が当たり前になって、その流れはある程度廃れた。

一方、2015年頃からRedmineユーザの兆候が変わってきた。
情シスやメーカーのような他業界の人達が入ってきて、いろんなRedmine利用事例を発表するようになってきた。
あるいは、PMOやSEPGのように、複数プロジェクトのQCDをモニタリングしたい第三者レビューの観点の人も入ってきた。
そんな話を聞くと、いわゆるプロジェクトリーダー層だけでなく、他業界で現場を回している係長クラスの人達にRedmineが当てはまっているんだな、と感じる。
つまり、Redmineユーザ層の変化が暗黙的にスムーズに行われたのではないか、と結果的に思う。

【6】参加者が現場に持つRedmineは、どれも唯一で、独自にカスタマイズされたRedmineばかりだと思う。
つまり、参加者が運用しているRedmineは、他のユーザの現場に持っていくと使えないだろう。
なぜなら、参加者が持っている問題意識や課題を解決するためのRedmineに特化しているので、他の現場ではコンテキストが違うからだ。

特に最近のredmine.tokyoのLTで聞かれるRedmine利用事例は、どれも個性的で、その現場でしか通用しないRedmineだ。
他に持って行っても通用しない。

だからこそ、そういうRedmine利用事例を聞くのは面白い。
そういう問題意識や課題から、なぜ、そんなカスタマイズしまくりのRedmineになってしまったのか、そういう経緯を知れるのが面白い。

【7】僕自身も最近はRedmineとチケット駆動開発の思索よりも、他のテーマのほうが多くなってきた。
今となっては、会計システムと同じように、チケット管理システムも普通の開発基盤になったように思える。
チケットでタスク管理することで、一元管理する発想は、もはや当たり前で、そこに新規性はない。

では、Redmineはどういう方向に進化すべきか?
どんな課題を解決していくべきなのか?
Redmineが提示すべき価値観とは何なのか?

その辺りは今後も考えていく。

| | コメント (0)

2021/08/01

OODAループの時代は、大事なのは使命であり、目標は使命達成のための手段に過ぎない

あるブログ記事で、OODAループの時代は、大事なのは使命であり、目標は使命達成のための手段に過ぎない、というメッセージが非常に心に残ったのでメモ。

【参考】
成績未達のものは、きつく叱責すべきか - ウィリアムのいたずらの開発?日記

PDCAサイクルは、1年毎の年間計画でよく使う。
しかし、超短期のサイクルでは使いづらい。
また、コロナ禍のような時代では、当初立てた計画が無意味となってしまった場合、PDCAを最初から作り直さないといけなくなる。

「PDCAサイクル全盛の時代は、目標を数値化してたてて、それを達成したらちょっと伸びた目標を立て続けていく」そんなやり方だった。
しかし、OODAループの時代では、「会社で大事なのは使命であり、目標は使命達成のための手段に過ぎない。」
つまり、「目標が達成しようがしまいが、目標と現実との差を常に感じ、使命達成のために行動する。そのためには目標の変更もあり得る。」

OODAループの考え方は、More Effective Agile ~“ソフトウェアリーダー"になるための28の道標で知っていたけど、腹落ちできていなかったと思う。
飛行操縦士が敵機を撃ち落とすための意思決定構造を形式化しただけ、というイメージで、ソフトウェア開発や経営に活用するイメージがなかった。

OODAループでは、目標よりも、価値や使命が最重要であり、目標や計画は達成するための手段に過ぎない。
目標や計画よりも、価値や使命が最優先であるという行動を誘発させること。

そんなことを考えると、OODAループはスクラムと相性が良いように思える。

| | コメント (0)

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

INSPIRED 熱狂させる製品を生み出すプロダクトマネジメントを読んで、日本に足りないのはプロダクトマネジャーだと改めて思った。
ラフなメモ。

【参考
ソフトウェア・ファーストの感想: プログラマの思索
プロダクトマネジメントの感想~プロダクトオーナーはもっとチームの外のユーザに寄り添うべき: プログラマの思索

「クライアント-ベンダーアンチパターン」という根本問題: プログラマの思索

プロダクトマネージャに必要なスキルは何か?~「世界で闘うプロダクトマネジャーになるための本 ~トップIT企業のPMとして就職する方法」の感想: プログラマの思索

(2) 伊藤 大地 / Daichi ITOさんはTwitterを使っています 「NHKのデジタル人材採用の募集要項に並ぶ言葉がもはや「メディア」ではなくて、「テック」企業のそれ。全てはソフトウェアの構築とその応用…というデジタルの性質が募集要項にそのままアウトプットされている。 https://t.co/yIZHbpQG5y https://t.co/Yu4YGX97Wu」 / Twitter

一括請負案件では、どうしてもプロダクトマネージャーという役割は持ちにくい。
プロジェクトマネージャが案件の中心にいて、顧客とプロジェクトマネージャが対峙するというクライアント・ベンダー・アンチパターンにはまりやすい。

では、日本では、どんなソフトウェア開発でプロダクトマネージャーという役割が必要になるのか?
INSPIRED 熱狂させる製品を生み出すプロダクトマネジメントのあとがきでは、日本でプロダクトマネージャーが必要とされる場面は、スマホアプリの開発だという。

なぜなら、スマホアプリの開発では、利用ユーザの観点で、利用ユーザの導線を極力簡素化すべきであり、そのために機能はできるだけ削ぎ落とし、シンプルでワクワクするUIをいかに作り出すか、が大事になるからだ。
実際、一括請負案件でも、スマホアプリの開発が混じってくると、従来のウォーターフォール型開発で要件をガチガチに固めた後に機能やUIを開発したとしても、最後のユーザ受け入れテストで数多くの不満が出て収拾がつかなくなる場合も多い。
スマホアプリを実際に触ってみて、初めて操作感だけでなく、本来のユーザ導線を考えるという手戻りも発生しやすい。
僕もそういう現場を見てきた。

つまり、スマホアプリの開発はとりわけアジャイル開発に適していて、利用ユーザのユーザエクスペリエンスを重視するには、プロダクトマネージャーという役割の人が統括する方がうまくいきやすいと思う。


| | コメント (0)

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)

より以前の記事一覧