Agile

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/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/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)

値オブジェクトの設計がオブジェクト指向モデリングの最初の登山口

先日7/14に開催された「アジャイル開発におけるモデリング活用実践セミナー」のオンライン動画を見ていて、興味深かった。
羽生田さん、増田さん、原田さん達の会話が面白かった。
気になった発言をラフなメモ。
自分の感想も混じっていて、全くロジカルでない。

【参考】
「アジャイル開発におけるモデリング活用実践セミナー」(2021.07.14開催) - UMTP 特定非営利活動法人UMLモデリング推進協議会

ドメイン駆動設計が好きで、ベンチャー企業のWebサービスの開発で使っている

最近は、基幹系システムのリプレースでドメイン駆動設計を使いたい、という話も多く来ている
すごく難しいけど、やりがいもあるし面白い

オブジェクト指向モデリングのワークショップでモデルを書こうとすると、みんな、フレームワークが前提でモデルを書いてしまう
ドメインの外側ばかり話している
肝心のドメインをプログラミングしようとすると、意外に誰も書けない
まずは値オブジェクトから始めよう
みんな、値オブジェクトでプログラミングできない
増田さんのオブジェクト指向モデリング本「現場で役立つシステム設計の原則 ~変更を楽で安全にするオブジェクト指向の実践技法」は、値オブジェクトから書こうとしているのでお勧め

intやStringのデータ型だけではトランザクションスクリプトみたいに書いてしまう
値オブジェクトが大事
オブジェクト指向では、Immutableな値オブジェクトから始まる
関数的プログラミングとも相性がいい
ドメインに特化してプログラムを書こうとすると、必ず値オブジェクトから始まる
値オブジェクトの設計がオブジェクト指向モデリングの最初の登山口

エンティティを重視するとデータモデリングになってしまう
手続き型プログラミングで、でかいエンティティを書いて、長いトランザクションスクリプトを書くと失敗する
書いていて怖い
データモデリングとオブジェクト指向モデリングは違うと考えた方がいい

エリック・エヴァンスのDDD本「エリック・エヴァンスのドメイン駆動設計」に出てくる例では、OODBを使っていた
昔はデータのストアはOODBでいい、という感じだった
OODBでは性能が出ないので廃れた

業務の複雑さに関するデータのモデリングは、データモデリングの方が一日の長がある

1990年代にモデリングが盛んだったのに、現代ではモデリングが廃れたのは、モデリングが伝承されなかったからではない
むしろ、現代的な課題に対して、長年知られていたモデリング手法のこの部分は今も使えるが、この部分は今は使えない、という交通整理された本がほしいね

2010年代にピアソン本が絶版されたので古いオブジェクト指向モデリング本が手に入らなくなり、エリック・エヴァンスのDDD本「エリック・エヴァンスのドメイン駆動設計」だけが唯一残った
そのために、オブジェクト指向モデリングの歴史に断絶がある

メソッドは3個まで
それができない人は、クラス化、カプセル化が分かってない
入出力処理は手続き型になりやすい

顧客との対話では、UMLを普通に使う
ただし、アクティビティ図、コンテキスト図、データフロー図を使う場合が多い
システム要件に落とす時は、UMLをガンガン使う

要件定義でモックを作るときはHTMLを使う
最近はいい感じですぐにモックデザインが作れる
実データを画面で見せた方が早い

プロダクトオーナーとの対話では、RDRA2.0を使って話する時が多い
システム設計では、UMLを使っている
図を書くのが目的ではなく、会話や意思決定のために使っている

DDDのエンティティはミュータブル?イミュータブル?
Webならイミュータブルが普通でしょ
setter, getterと無関係なモデルにしている
イミュータブルが普通
エンティティに状態は持たせない
void実行でなく、新しい状態のオブジェクト、エンティティを別で返す
Webならイミュータブルが普通
エンティティの状態をSetして変更すると、バグが出そう
イミュータブルだからFreezeしているのでCloneする必要もない

アジャイル開発プロセスとモデリング作業の事例は?

モデリングでも、概念モデルのレベルでプログラミングを書く
合わせてDFDやER図を書く
事業分野の可視化はシステムで書きにくいので、シナリオ、バリューチェーンを書く
バリューチェーンで、どこのプロセスに差別化要素があるか、強みがあるか、を分析する
ビジネスを理解するモデリングとシステムとして動かすプロトタイプの2つを行き来している

増田さんのドメインモデルのサンプルが分かりやすい
パッケージ図でクラス図を分割して、HTMLで一覧にしている
さらに、ユースケースのシナリオからパッケージ図、クラス図まで一気通貫でHTMLにしている
軽量で明快なモデリング
ビジネスモデルとDFD・ER図をつなぎつつ、パッケージ図・クラス図で方にしてHTMLで見せている
増田さんのクラス図は値オブジェクトが中心
取引日、貸し出しも全てクラスになっている
増田さんにとって、モデル駆動とはドキュメント駆動のイメージ
ソースコードとモデルを行き来していて、モデルが自然にドキュメントになっている

Scrumで開発する時に、ユーザーストーリーマッピングを使う場合が多い
このメソッドを実装する時、このメソッドはこの要件から来ていて、この要件はユーザーストーリーマッピングのこの部分に対応する、と辿れる

【感想】
エリック・エヴァンスのドメイン駆動設計現場で役立つシステム設計の原則 ~変更を楽で安全にするオブジェクト指向の実践技法を読むと、ドメインのソースコードが値オブジェクトになっている場合が多い。
その理由は、ドメインをプログラミングに注力しているから、と見ると分かりやすい気はする。
オブジェクト指向でプログラムを書くと、状態を持たせるエンティティが頻出して、バグが出やすい箇所はたいていその部分であり、デバッグしないと追跡できない場合が多いのを思い出した。

| | コメント (0)

2021/07/18

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

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

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

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

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

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

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

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

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

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

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

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

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

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

| | コメント (0)

より以前の記事一覧