Redmine

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/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/07/11

テストカバレッジの目標値はどれくらいの値が良いのか

テストカバレッジの現状について記事を漁ったので、リンクをメモしておく。

【参考】
Google Testing Blog: Code Coverage Best Practices

テスト駆動開発で品質は上がるのか。Googleの事例などを参考に考察。 - サックルMAGAZINE

Ericssonの『ユニットテストカバレッジの神話』を読んでみる - ソフトウェアの品質を学びまくる2.0

コードカバレッジでのブランチカバレッジとデシジョンカバレッジは何が違う?|Tsuyoshi Yumoto|note

ホワイトボックステストの必須知識! コードカバレッジをご紹介! | Qbook

カバレッジ(網羅率)分析とは | ソフトウェアの検証の種類 | テクマトリックス株式会社

カバレッジ - MATLAB & Simulink

過信は禁物!コードカバレッジの種類と落とし穴 | Qbook

グーグルはあれほど多くのソフトウェアのテストをどのように行っているのか? - Publickey

テストカバレッジ100%を追求しても品質は高くならない理由と推奨されるカバレッジの目標値について - Qiita

Martin Fowler氏のテストカバレッジ

Analyzing statement coverage at Google

テスト自動化は品質向上に直接的に役立つ。
特に、既存機能への回帰テストでは重要な役割を果たす。

Redmineでは、テストカバレッジの一覧が下記で公開されている。
全てのソースが100%ではないが、いつでも回帰テストを実行できるからこそ、高品質を維持できて、10年以上も世界中の開発者に利用されてきたのだと思う。

Redmine code coverage

では、テストカバレッジの目標値はどれくらいの値が良いのか?
ほどほどによい目標値はどれくらいなのか?

GoogleTestBlogではこんな説明がある。

・Googleでは、60%を「許容可能」、75%を「推奨」、90%を「例示的」という一般的なガイドラインを提供しています。
・90%のコードカバレッジから95%に到達する方法に執着するべきではありません。
・プロジェクト全体で90%を超える目標は価値がない可能性が高いですが、コミットごとのカバレッジ目標である99%は妥当であり、90%は適切な下限しきい値です。

Analyzing statement coverage at Googleによると、
「C0(命令網羅, Statement Coverage) 目標値 85%+」らしい。

Martin Fowler氏のテストカバレッジによると、
「カバレッジ(C0?、C1?)の目標値 85% - 99%」らしい。

テストカバレッジ100%を追求しても品質は高くならない理由と推奨されるカバレッジの目標値について - Qiitaでは「クリティカルなコードではない限り、カバレッジ(C0 / C1)の目標値は 85%程度 に設定すべきである。」とあった。

85%程度が一つの閾値のようだが、定理や法則のようにどこでも使えるものではない。

テストカバレッジの目標値は高ければ良いわけでもない。
しょせん単体テストレベルなので、元々の機能設計のミス、要件漏れは発覚できない。
C2のコンディションカバレッジでは、禁則になる組み合わせも多いから、意味ある組合せだけを特定して、大量の組合せのパスをテストするのは、工数の割に無駄も多い。

今なら、テストカバレッジの目標値を指定したら、AIでテストコードを生成して、実際に回帰テストを実行して、目標値以上になるように実現してくれるのではないか、と勝手に夢想している。

AIを活用した次世代テスト自動化ソリューション「mabl」の 販売パートナーシップ契約締結のお知らせQA活動を効率化、サービスやプロダクトの品質向上を推進|ニュース|ソフトウェアテスト・第三者検証のベリサーブ


| | コメント (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/04/18

Excel駆動でWBSやガントチャートが作れない人はどこに原因があるのか? #redmine

Excel駆動でWBSやガントチャートが作れない人は割といる。
ExcelからガントチャートやWBS管理を作ろうとしているが、その品質が悪い。
Excelで出来上がったガントチャートやWBS一覧の完成形を見せつけられているので、Excelで作ろうとするが、上手く完成できない。

若手のプロジェクトリーダーでもガントチャートに穴がある時があるし、いつもタスクのこなしが遅い人はそもそも全てのタスクを洗い出せていない。
だから、進捗管理をやろうとしても、何が遅れてやばいのか、どこに課題があるのか、を一つずつ解決できていない。
最初から全てExcel上で、PJ計画の作業をするのがそもそも間違っている、と思う。

では、どこに原因があるのか?

1つの観点として、そういう人たちは、PERT図を描いた経験がないのだろうと思う。
つまり、タスクの全体の構造が見えていない。
タスク同士の因果関係、タスク同士の依存関係が見えていない。

たとえば、ガントチャートを作る前にタスクをExcelで洗い出すだろう。
しかし、Excelで縦列に並べたタスクを見ても、その先行・後続の関係や優先度はそれぞれ違う。
それらをつなげて一つのガントチャートを作った、という経験がないようだ。

進捗管理の基本はクリティカルパスをきちんと管理することだ。
クリティカルパスとなるような重要なタスクさえ抑えれば、他のタスクはクリティカルパスから追跡できる。
そういう考え方をしていないリーダーがいた。

つまり、Excel上で、タスク一覧をこねくり回しても何も進まない。

では、どうやると治療できるのか?
一つの案では、連関図法のように、タスクを付箋紙で全て書き出して、グルーピングして、先行・後続でつなげていく、という作業を何度か経験すればいい。

そうすれば、タスクをグルーピングして依存関係を考えるうちに、このタスクも必要だから付け足そう、このタスクは他のグループにまとめたほうがいい、とか、これらのタスクは並行で稼働させたらメンバーを有効活用できる、とか、色々気づくはず。
あるいは、インフラ担当のメンバーが1人しかいないので、彼のタスクは全てクリティカルタスクになってしまう、とか、担当者のタスクが溢れている、とか分かれば、早めにメンバー確保するとか、色々対策を打つはず。
そういう試行錯誤が重要だ。

結局、付箋紙で洗い出してタスクの先行後続、依存関係を考えている、ということは、PERT図を描いているのと同じ。

具体的な案として、Redmineのチケットで全てのタスクを一括登録して、それらチケットをつなげてPERT図でを作り、先行後続の関係をガントチャート上で編集して、ガントチャートを作る。
あるいは、リリース日の単位でチケットをグルーピングしてロードマップを作る。
そういう作業をやってみれば、実際に気づきが多いはず。

Redmineのガントチャート標準機能では、ガントチャートの編集はできないが、LycheeGantChartを使えば、先行・後続関係を付けたり、ガントバーを移動したりできる。

Redmine Lychee Enterpriseシリーズの解剖part1~Redmineの本来あるべきガントチャート機能 Lychee Gantt Chart: プログラマの思索

Redmine Lychee Enterpriseシリーズの解剖part2~RedmineでEVMを実現 Lychee EVM: プログラマの思索

RedmineをMSProcjetっぽく使う事例: プログラマの思索

Redmineを使わないならば、OSSのMSProjectクローンであるProjectLibreを使えばいいだろう。
Excelでタスク一覧を作っておき、ガントチャート画面で先行・後続関係を付けられる。

OSSのMSProjectクローンProjectLibreの使い方: プログラマの思索

OSSのMSProjectクローンProjectLibre: プログラマの思索

実際は、ガントチャートの保守は非常に面倒だ。
単に、タスクの先行後続をつなげればいい、だけの話ではない。

たとえば、1人日は8時間しかないのに、1人の作業が1日15時間働くような作業を組んだガントチャートになりがちだ。
だから、リソースヒストグラム画面で行き来しながら、作業負荷を考えて、タスクの分担を調整する。
いわゆる山崩しだ。

たとえば、ガントチャートを作るとPERT図という別のビューで見れるので、TOCの合流バッファの考え方を適用して、合流バッファには余裕をもたせることで、クリティカルチェーン上にゆとりをもたせて納期を厳守する。

たぶん、こういうガントチャートの管理手法は、メーカーの生産計画の手法と相性がいいので、本来はもっと自動化されるべきだろう。
しかし、ソフトウェア開発は、ハード製品を大量生産するケースとは全く違うので、PJ計画時に立てたガントチャートは、あくまでもイメージに過ぎず、たくさんの課題や障害が発生する都度、解決して、何とかリリースにこぎつける、みたいなパターンが多いはず。

だから、Excelのガントチャートが完成形に見えたとしても、所詮それは幻想に過ぎない。
そういう計画作業で得られた知見、試行錯誤して考えているうちに気づいたリスク、という方が大事だと考える。

次回の東京Redmine勉強会のパネルディスカッション「Excel中毒者のためにRedmineワクチンを施してみた」ではそんな話をする予定。
是非、参考にして欲しい。

第20回勉強会 - redmine.tokyo

| | コメント (0)

2021/03/26

ITの技術や知識はツールの習得と表裏一体である

ITの技術や知識はツールの習得と表裏一体ではないか、というアイデアをラフなメモ。
とても当たり前の内容かもしれない。

【1】昨年からもう一度、コンピュータの基本技術を習得すべきと考えて、Ruby、Python、Linux、ネットワーク、機械学習、深層学習、コンパイラなどを勉強し始めた。
でも何か分かったような気がしなかった。
何か真似事しているだけのような気がした。
なぜだろうか?
いろいろ考えた結果、やっぱり基本技術が分かってないなあ、という思いがあった。

【2】ITの技術や知識の習得は、財務や法律、経済学などの分野の知識の習得とは異なる気がする。
具体的には、ITの技術や知識を知っているだけでは意味がなくて、その技術や知識を実装しているツールを使いこなせて、そこから新しいものを生み出すことができて初めて意味を持つのだ、と思う。

理由は、2つある。

【3】1つ目は、ITの技術や知識を知っているだけで、プログラミングの開発環境、Linuxコマンドを動かせるサーバー環境、UMLやデータモデルを描いて実際に画面まで動かす、などの実際に動かせる環境でツールを使いこなせなければ、実際の仕事に使えないからだ。

たとえば、RubyやPythonの文法を知っていると言っても、実際に動くアプリを生み出すには、プログラミングの開発環境を揃えて、デバッグしたり、コンパイルしたり、デプロイする環境が必要になる。
昔なら、VisualStudioでVBやC++を書いていた時も、VisualStudioに数多くのパッチを当てたり、SQLServerなどのバージョン依存に泣かされていたのを思い出す。

今でも、単にRubyやPythonの文法を習ったとしても、実際に開発環境を揃えるのは割と大変だ。
実際、Railsは優れたWebフレームワークだが、VerUpが激しいし、大量のGemが必要になるので、慣れていなければ、バージョン依存ですぐに動かなくなる。
PythonもNumpy、Pandas、MatplotLibのVerUpは激しいので、すぐに古いバージョンのAPIは使えなくなっている。
ただし、Pythonの場合、Anacondaがあるおかげで、以前よりもバージョン依存地獄にはまらなくなったように思う。

たとえば、WordPressやTracなどのWebシステムを通じて、Webアプリの機能や特徴を理解したとしても、Linux上にソースをデプロイして、負荷分散に耐えられるようなネットワーク設計を行ったり、不正なアクセスを制御するようにアクセス制限を課す、とか、いろんな設定作業が必要になる。
特に、インフラ周りの開発環境は、一昔前まで構成管理できない環境だったから、設定ファイルを一度修正すると、元の環境に戻せないリスクが多かった。
それゆえに、数多くの「○○_backup_yyyyMMdd.ファイル」みたいなファイルがたくさんできてしまって、ゴミファイルなのに消せなくなる、とかいろいろな苦労もあった。
ただし、今なら、DockerなりAnsibleで、環境構築の構成管理が可能になったので、いつでも環境を複製したり、再現することが楽になったのはありがたい。

たとえば、UMLでオブジェクト指向設計を習得しても、データモデリングの手法を通じて業務システム設計が分かったとしても、実際にUMLやDOAのモデルを描けるツールが必要だ。
実際にモデルを描いてみると、数多くのモデル間の整合性を取るのが大変なのが分かるし、実はモデリングの記法に制限がありすぎて、あるべき機能を描きにくい、という気づきもあったりする。

特に、データモデリングの手法は日本では昔から技術が蓄積されていて、そのノウハウも十分にあるし、業務システム設計にとても役立つのに、さほどそのノウハウが普及していないのは、データモデリングのツール自体がオープンソースで提供されていなかったり、使われていないからだ。
ER図を描くだけでも気づきは多いのに、ER図を描けるモデリングツールはそもそも標準がないのが実情。
だから、データモデリングの考え方自体も普及していない。

【4】2つ目は、ITの技術や知識を使ったベストプラクティスは、ツールの一機能として実現されているので、ツールの機能を使いこなすことで、自然に知識やノウハウを身につけられるからだ。

たとえば、Rubyの開発環境で最も優れているのはRubymineだろう。
RubymineでRubyを書いてみると、デバッグもできるし、ブレイクポイントを置いて、実際に動く変数の中身もウォッチできる。
しかも、RubymineにはRubyという動的言語であっても、リファクタリング機能が付属しているので、ちょっとした変数名の置換、ロジックをメソッドで抽出する、などの操作を簡単に行える。
つまり、リファクタリング本で知られているリファクタリングのベストプラクティスがRubymineのツールの1機能として実現されているので、Rubymineを使いこなしていくうちに、リファクタリング技術にも慣れて、きれいなコードを書くノウハウも身に付く。
もちろん、テストユニットのソース支援機能もあるから、自動テストも実装できるから、そういう機能を使っていくうちに、プログラミングの能力も身についていく。

たとえば、CCNAのようなCisco機器の知識、ネットワークの一般的な知識を身に着けたい場合は、Ciscoのルータやスイッチを実際に中古品で購入して、オンプレのネットワーク設計を行いたい。
しかし、実際はそこまでお金を払わなくても、PacketTracerのようなシミュレータ、GNS3のようなエミュレータが無料であるので、それらを使ってPC上でネットワークのトポロジーを作って動かしてみればいい。

実際に試してみると、L2スイッチでVLANやSTPの設定、ルータでRIP、OSPF、デフォルトゲートウェイ、サブネッティングによるIPアドレス付与、などの基本的なネットワーク設計は非常に難儀な作業であることがよく分かる。
IPアドレスの数字がちょっと間違えただけでも、すぐに疎通できなくなる。
100人以上の社員がいる社内ネットワーク構築で、ルータを10個以上配置する場合、ネットワークの冗長化や負荷分散、セキュリティ面をきちんと考えておかないと、すぐにユーザからクレームが来るだろう。
そういう設計を行うための技術は、たとえば、STPやHSRPのような冗長化や負荷分散、ACLやPortSecurity、AAAのようなセキュリティの機能があるので、それらをCisicoコマンドで実際に実現すればいい。
そういうネットワーク設計をルータやスイッチのような実機ではなく、PacketTracerやGNS3のような無料ツールで事前にネットワーク・トポロジーを試しておけば、いろんなノウハウが身に付くだろう

たぶん、クラウドも同じように、実際にAWSで色々試しながら、身につけた方が習得が速いはず。

たとえば、Redmineは単なるITSやBTSではなく、プロジェクト管理ツールとして使われるようになった。
すると、プログラマ出身だが、プロジェクトリーダーの役割は初めての経験で、そんなにチームビルディングに自身がない人であっても、Redmineというツールの機能を駆使すれば、基本的なスケジュール管理や課題管理はこなせるようになる。
また、アジャイル開発のプラクティスとRemdineの各機能は相性がいいので、チームビルディングやコミュニケーション活性化に活用することもできるだろう。
つまり、Redmineの機能を十分に把握できれば、自然にプロジェクト管理力も身についていく。
Redmineのいろんな機能は、10年以上のOSS開発を通じて、世界中の開発者の要望が実現されていて、それらは全て、ソフトウェア開発に役立つように作られたからだ。

逆に言えば、PMBOKのような知識を持っていたとしても、実際のプロジェクトの現場で発揮できなければ意味がない。
Excelで自前でガントチャートによるスケジュール管理を作ったり、自前で工数管理のVBAやEVMのVBAを作り込んだりしていたプロジェクトリーダーを実際に見てきた。
たしかに彼らはそういうツールを作り出すだけのVBA能力があり、マネジメント能力もあったわけだが、僕はOSSのプロジェクト管理ツールとかGitHub、GitLabなどを使いこなすことで自然にベストプラクティスが身についていく、という成長のやり方の方が好きだ。
「ツールがプロセスを改善していく」という発想が僕は好き。

ツールでプロセスを実装すべきか、プロセスを確立してからツールを導入すべきか: プログラマの思索

チケット駆動開発はツールによる改善か、プロセスによる改善なのか: プログラマの思索

ツールがサポートすれば考え方も変わる: プログラマの思索

チームの開発環境が開発プロセスの品質を向上させるのに導入されない理由: プログラマの思索

ツールが開発プロセスを改善する: プログラマの思索

開発プロセスの型をツールで構築する #tidd: プログラマの思索

【4】そんな事を思うと、ITの技術や知識はツールの習得と表裏一体である、という事実を改めて感じている。
換言すれば、プログラミング開発環境、サーバー環境、ネットワーク環境、プロジェクト管理ツール、ソースコード管理ツールなどのツールを使いこなしていけば、そのツールの機能に実装されているベストプラクティスは自然に身に付くのだ。

それらのツールの機能には、長年の蓄積で得られたコンピュータ科学やソフトウェア工学の理論、数多くのプログラマやネットワーク技術者が苦労して導いてきた泥臭いノウハウが数多く詰まっている。

だから、教科書を通じてIT技術の知識を習得するよりも、実際に開発環境を揃えてプログラムを書いたり、サーバーを動かしたり、プロジェクト管理ツールを準備して実際にスケジュール管理や課題管理をやってみる、という体験の方が重要だと思う。
そして、そういう試行錯誤は、20代のような若いうちにやった方がいい。

最近気づいたが、年齢を取るほど、PCの前に長時間座ってコマンドを叩くのが割ときつくなってくる。
いくらツールを通じて知識を習得すればいい、と言っても、ツール自体もどんどん進化するから、それらにキャッチアップしていくのも大変。
視力が落ちてくるし、老眼になってくるし、体力面も厳しくなる。

昨今のDXというバズワードの流行を見ると、ビジネスも生活もあらゆる場面で、全てがソフトウェアで代行されていくだろう。
そういうソフトウェアを自分のものとして制御していくためにも、ソフトウェアの基本的な知識や技術は習得しておきたい。だからこそ、ツールの機能を習得することで、自然に知識やベストプラクティスが得られるように、そのやり方にも慣れておきたい。

| | コメント (0)

2021/03/21

Redmine 4.1.2がリリースされた

1年ぶりにRedmine 4.1.2がリリースされた。

Redmine 4.1.2 and 4.0.8 released - Redmine

コロナ禍のためだろうか、JPLが忙しいせいだろうか、RedmineのVerUpが直近1年間なかった。
もちろんRedmineは日々コミットされて、パッチは積み上げられているので、Redmineは生きている。
しかし、正式バージョンが定期的にリリースされないと、ソフトウェアは死んでいるように思われてしまう。

とにかくRedmineがリリースされて良かった。


| | コメント (0)

2021/02/12

信頼度成長曲線の落とし穴

@MadoWindaheadさんの信頼度成長曲線の記事を読み直して、色々感じたことがあったのでメモ。

【参考】
信頼度成長曲線を語る夕べに参加 | マドびっ! Madosan's View

信頼度成長曲線については、過去に、SRATSのようなツールを試していた時もあって、色々考えていた。
個人的には、信頼度成長曲線は品質管理の中で華のような技術の印象を持っていた。
なぜなら、その他の品質管理の技法よりも、見た目は美しいが実際の中身は統計処理が含まれて割と複雑なので、研究するのにお手頃だから。

また、テストの収束傾向やテストの終了条件の判定に最終的に使うので、リリース判定というタイミングで使われるから、品質管理の中ではかなり重要な位置を占める。

いつテストを終わらせるか?: プログラマの思索

SRATSの使い方: プログラマの思索

「バグの潜在期間が長いほど修正時間が短い」ソフトウェアに対する信頼度成長曲線の論文が面白い: プログラマの思索

テスト消化曲線とバグ発生曲線のパターン診断: プログラマの思索

アジャイル開発はメトリクスが取りやすい: プログラマの思索

忘れ去られた日本のIT技術~DOAと品質管理: プログラマの思索

しかし、上記の記事の書いてある通り、信頼度成長曲線は前提条件がある。
前提条件とは「単位テスト時間あたりの検出される不具合の数はテスト期間中を通じて一定している」こと。

信頼度成長曲線は別名、バグ収束曲線でもあるから、バグの発生傾向やバグの発生頻度が重要な観点になる。

僕の理解では、信頼度成長曲線の前提では、テスト作業プロセスそのものにバラツキはないと想定する。
つまり、「単位テスト時間あたりの検出される不具合の数はテスト期間中を通じて一定している」。

一方、システムの機能に依存したバグ数にばらつきがあっても良い。
実際、システムの機能に関係なくバグが機能毎に全て一定の割合で埋め込まれていたら、S字型曲線にはならず、直線になるはずだから。

具体的には、システムテストでバグ出ししていくと、最初はテストは順調に進んでバグもあまり出ないが、途中からバグが出る機能にぶち当たって、大量のバグを検出するフェーズになる。
そして、何とかバグを全て解決して、最後は、全ての機能をテストし終える頃には、潜在バグも残存バグも抽出しきって、バグも収束傾向になって落ち着く、というイメージ。
すなわち、バグ収束曲線はS字型曲線、イメージとしてはロジスティック曲線みたいな感じになる。

そういう経験則が成り立つ状況であれば、開発規模や過去のバグ密度の経験値、システム特性などを元に、信頼度成長曲線の予定曲線をゴンペルツ曲線とか、S字型曲線に似た曲線で予定しておく。
そして、システムテストでのバグ管理の実績を取ることで、信頼度成長曲線の予実管理を行って、バグの収束傾向を見て、残存バグが出し尽くしたか否か、を判定するわけだ。

しかし、実際のシステム開発の経験では、そもそもバグ累積件数はS字型にならない。
むしろ、一直線に発散する感じの場合が多い。
特に新規加入した開発者が多いチーム、過去のシステム保守の経験がないチーム、新しい技術を使った案件などでは、試行錯誤して、ハンドルが荒れた車の運転みたいな感じになるから。

また、横軸にテスト実施日を取ると、テストしない日とか、テストケースの実績が少なければ、信頼度成長曲線は自然に横向きになるが、それはバグが収束した傾向を示すとは限らない。
横軸には、テスト工数を引くとか、テスト作業そのもののバラツキをなくすように、正規化する必要がある。

こういう処理をExcelでやるのはとても面倒。
信頼度成長曲線はBTSがあればデータをExcelにプロットするだけで実現できるのがメリットの一つだが、実際に正確なグラフを描き出すのは面倒。

結局、信頼度成長曲線にせよ、ソフトウェアメトリクスは、安定したプロセスで初めて有意義な意味を持つ。
そういう意味では、一発限りの請負型案件ではとても使いづらい。

Redmineのようなチケット管理ツールは、最終的にはソフトウェアメトリクスを集計・出力するプロセス基盤であると僕は思っている。
しかし、安定したチームで長期間活動するのは、日本のSIではとても実現が難しいので、ソフトウェアメトリクスを効果的に使えた経験は正直少ない。
パッケージ製品の自社開発、長期間の自社の基幹システム保守のように、長期間のPJでは当てはめやすいかもしれない。

| | コメント (0)

2021/01/25

キャズム理論をプロセス導入の問題解決に使うアイデア

「BABOK入門」を読んでいたら、ERP導入の難易度と組織文化をマトリクスで整理していたのが非常に分かりやすかった。
そのマトリクスの考え方の背後には、キャズム理論がある。
なるほど、そういう考えなのか。
適当なラフなメモ。
間違っていたら後で直す。

「BABOK入門」を読むと、キャズム理論は、ERP導入だけでなく、PMOが新しい標準プロセスを導入する時に、どういう対処をすれば運用を拡大して推進できるか、という示唆が得られると思う。

まず、キャズム理論は、ERP導入や開発プロセス導入対象の組織文化のレベル分けに使える。

ビジョナリーは、イノベータなので、最新のERP、最新の開発プロセスに興味を持ち、導入してくれる。
アーリーアダプターは、実利重視なので、自分たちの目的に叶うならば、リスクを背負って導入してくれる。
アーリーマジョリティは、保守的なので、他社が多数導入して、デファクトスタンダードになってから導入し始める。
ラガードは、自分たちの組織文化に誇りを持ち、他の価値観を受け入れないので、そもそも導入しないか、導入しようとしても自分たちの組織文化に合うように、ERPをカスタマイズしまくったり、プロセスをカスタマイズしまくる。

他に、キャズム理論は、ERP導入やプロセス導入の問題解決に使える。
キャズム理論では、アーリーアダプターとアーリーマジョリティの間にあるキャズムを乗り越えるのが重要、と知られている。
だから、ERPであれ、新しいプロセスであれ、キャズムを乗り越える対策が必要。

キャズム理論が教える所では、ホールプロダクト理論が知られている。
ボウリング・ピンのように、主要ターゲットを狙って成功させて、その後は次々にターゲットを定めて落としていく。
同様に、ERP導入でも、プロセス導入でも、主要ターゲットを定めて確実に成功させて、周囲のボウリングピンを一つずつ落として、シェアを高めて、デファクトスタンダードに近づけていく。

アジャイル開発の導入でも、Redmineの導入促進でも、同じような苦労があったことを思い出した。

今、PMOが導入しようとしているフェーズは今どこなのか、自分の足元を確認しながら、進めていくべきなんだな、と改めて気づいた。


| | コメント (0)

2021/01/04

変更管理プロセスが弱いとトラブルが多い

以前、ITILの研修を受けた時、講師から「変更管理プロセスが弱いとトラブルが多い 」という話を聞いて、非常に心に残った。

【1】ITシステムは変更に起因するインシデントによって、必ず変更が起き、それが遠因となってトラブルが起きやすい。
例えば、OSやソフトのバージョンアップ、システム移行、マイグレーションなど。

つまり、今まで「あるべき姿」で稼動していたのに、ある時点で「おかしくなった現在の姿」へ方向が変わり、時間が経つにつれて、ギャップが生じる。
このギャップがトラブルだ、と。

だからと言って、ITシステムの変更を生じるインシデントを全て拒否することはできない。
むしろ、ITはバージョンアップすることで、使いやすくしていくのが最大の特徴だから。
そこに矛盾がある、と。

【2】ITシステムは変化があって当然だし、その変化を受け入れて、その変化をコントロールする技術を持つことが重要だ。
その技術が、変更管理プロセスであり、構成管理プロセスであったりすると考える。

つまり、プログラミングやモデリングそのものに問題があるわけではない。
それら技術の進化が激しく、5年も経てば老朽化が当たり前で、5年おきにリプレースしてシステム移行だけでなく業務移行も伴う。
そういう変化をコントロールする術をあなたは持っていますか?と問われている気がする。

ITILはそういう変更管理プロセスに着目した考え方だと思う。

僕は、そういう変化をコントロールできる開発基盤として、Redmine+Gitが必要ではないか、と考えている。
そのアイデアも膨らましてみる。

変更管理の基盤は構成管理が支えている: プログラマの思索

XDDPと言う派生開発: プログラマの思索

派生開発プロセスXDDPの講演メモ: プログラマの思索

開発プロセスを管理することでしか、ソフトウェアの品質は管理できない: プログラマの思索

| | コメント (0)

より以前の記事一覧