Redmine

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)

2021/01/02

カンバンはステータス名が大事

カンバン仕事術」を読んで、気づいたことをメモ。

【1】カンバンの運用では、ステータスはどんな観点で作るべきなのか?

カンバンはチケット管理と相性が良い。
なぜなら、カンバンのステータスはチケットのステータスと同じだから。
チケット一覧をタスクボードでビジュアライズすれば、障害修正プロセスのどの工程でボトルネックが発生しているのか、一目で分かる。

では、カンバンのステータスはどんな観点で作るべきなのだろうか?
一般に、Redmineのワークフローでは、新規→進行中→解決→完了 がデフォルトだが、現場で運用する場合は必ず変更した方がいい。
チケットのステータスと同じ、と言っても、それぞれの現場でワークフローはかなり違う、という経験をしてきた。

たとえば、デフォルトステータスのまま運用すると、実は、ステータスに対応する担当者がいない時もあれば、複数人もいる時がある。
たいていの場合、SIの開発プロセスはインフラ基盤・デザイナー・アプリ開発・DB基盤・設計レビュー担当のように部門ごと、役割ごとに縦割り組織になっているので、割と複雑だ。
よって、ステータスが組織と対応付けられていないと混乱しやすい。

では、カンバンのステータスはどんな観点で作るべきなのか?

【2】カンバンのステータスは、役割やチームごとに割り当てる

カンバン仕事術」のイントロでは、Jiraを例として、カンバンのステータスを決める場面がある。
最終的には、ToDo→分析→開発→テスト→受入→運用待ち→本番 に決まる。
決め方は、各ステータスに役割ごとの担当者がアサインされる。

最後に「完了」ステータスがない理由は、チケットのタスクを実装して運用待ちになっても、リリース作業は別のベンダーが担当するので、自分たちで本番リリースしてバグがなかったことを見届けられないからだ。
本番リリースしたとしても、バグが出れば、また戻ってくるので、完了という呼び名が合わない、とチームで決めたからだ。

この場面を読んでいると、カンバンのステータスは、作業の役割ごとに決められる点だ。
開発プロセス、組織構造の部門ごとに、作業の役割は細分化されるので、その単位ごとにステータスが対応付けられる。
Redmineのデフォルトステータス「新規→進行中→解決→完了」ではステータスが少なすぎる場面が現実では多い。

経験上、メーカーのように生産工程が、生産計画部・製造部・品質保証部などのように縦割りになっている場合、ステータスの個数が増える傾向が多い。
メーカーの生産工程を模倣したWF型開発や、ソフトウェア工場のプロセスでは、通常のソフトウェア開発よりもさらにステータスが多くなりがち。

たとえば、開発者がバグ修正してコミットしても、テストサーバーにアップするには、構成管理担当者に連絡してアップしてもらい、別のテスターに検証してもらう、といった手間がかかる場合は、「構成管理担当者によるリリース待ち」「リリース終了・テスト検証前」のようなステータスがないと、誰がボールを持っているのか、混乱しやすい。

とは言え、現状を表したステータスをつけて、ワークフローを作るべき。

別の話では、リーン開発の考え方により、バリュ・ストリーム・マッピングの手法を使って、複雑になりすぎたワークフローをリファクタリングしてプロセス改善しましょう、というやり方もある。

【3】ボトルネックになるステータスの前に、キューを置け

役割ごとにステータスをアサインして実際に運用すると、ボトルネックとなる作業者の前に仕掛作業が滞留し、ボトルネックとなる場合が多い。
その原因を探ると、単純に、WIPが少ないからだけではない。

たとえば、受入ステータスのWIPが4になっているが、常に受入可能なチケットが埋まっているわけではない。
基本は、受入可能なチケットがあれば、担当者はすぐに検査・テストして、リリース可能と判断できれば、運用待ちステータスへ流す。
しかし、WIPが4より小さいと、テスターは常に張り付いて作業しないといけないが、出張や会議などで不在の時は対応できない。
一方、WIPが4より大きいと、テスターがフィードバックを戻す前に、開発者は別の作業に仕掛中になってしまって、すぐに対応してくれなくなる。

よって、受入フェーズでは、バッファとなる「準備完了」と、実際の「作業中」でステータスを分ける。

つまり、何らかの理由で制約がある工程の前にキュー(バッファ)を置くことで、ワークフローの一連の流れが停滞しないようにする。

キューの役割は、作業の流れを平準化することだ。
すなわち、フローの中で、流量(つまりタスク)のばらつきを抑える役割を果たす。

一般にキューは、ボトルネックとなる作業の前後で置かれる場合が多い。
たとえば、ToDo、開発準備完了、開発完了、テスト待ち、リリース待ち、レビュー待ち、受入待ち、などの呼び名がある。

キューの有無を判断するには、ステータスの入出条件、退出条件から考えればいい。

【4】カンバンは奥が深い

キューは、アルゴリズムの基本の一つ。
FIFO。
ワークフローを作る際に、流れが悪い場面で使う事が多いと思う。
ふりかえりでプロセス改善する時に、思いつきやすいと思う。

カンバンが面白いのは、2つある。
一つは、ワークフローの改善に役立つこと。
もう一つは、メトリクスやKPIを採取しやすいので、プロセス改善の材料に簡単に昇華できることだ。

なぜなら、カンバンはフロー管理に特化しているので、流量を速度にたとえれば、チケットの枚数で計測化しやすい。
完了ステータスとなったチケットはアウトプットなので、生産性にたとえられる。

カンバン仕事術」では、下記のKPIを紹介している。

リードタイム:1枚のチケットが最初のステータスから最後のステータスに入るまでにかかった時間
スループット:一定期間(例:1週間)ごとに完了したチケット数

こういうKPIはグラフ化すると分かりやすい。
たとえば、チケット完了日xチケットのリードタイム で散布図をプロットすれば、問題解決について、色々議論しやすい。
なぜ、このチケットはこんなに時間がかかり過ぎたのか?
そこからどんな原因が分析できるか?

たとえば、リリース週xスループットを折れ線グラフにすれば、納期遵守の工夫が見つかるかもしれない。

つまり、これらのKPIを開発プロセスにフィードバックすることで、各ステータスのWIPを減らしたり多くしたり、ステータスを統合・分割する解決法が見つかり、プロセスを改善する行動につなげられる。

元々、Redmineはカンバンと相性が良いので、どのKPIがプロセス改善に役立つのか、そういうノウハウも蓄積できるはずだ。
いろいろ考えてみる。

| | コメント (0)

RedmineをPJ管理ツールと呼ぶのは嫌いだ、Redmineはチケット管理ツールと呼ぶべきだ

RedmineをPJ管理ツールと呼ぶのは嫌い。
「Redmineはチケット管理ツール」と呼びたい。

【1】PJ管理ツールと呼びたい場面では、プロジェクトマネージャーやPMO、経理部門、経営層が各PJの進捗・課題・コスト・品質管理を常に監視したい欲求がある。
彼らは、ソフトウェア開発の案件は常に赤字のリスクにさらされているのを身を持って知っているので、プロジェクトリーダーの定性的なPJ報告を信用していない。

プロジェクトリーダーは、PJ途中まで、進捗も問題ありません、と言いながら、リリース間近になって、品質が悪くて進捗が大幅に遅延しました、というPJ報告が多すぎるから。
プロジェクトリーダーも、90%症候群に慣れている。

よって、PJ管理ツールを全社に導入して、各PJのQCDを可視化し、常時監視できる状態にしたい。
すると、PJメンバーは毎日、PJ管理ツール上で、詳細化されたWBSに進捗率と実績工数を入力するように躾けられる。

一般に、高価な有償パッケージ製品のPJ管理ツールを導入して、社員だけでなく、内製開発にいる準委任契約の協力会社メンバー(BP)にもその運用を強制させる。
それにより、毎週・毎日のPJ報告では、進捗や原価は自動計算できるから、理論上は、毎日、PJ報告を提出させることで、PJのEVM、原価と粗利、営業利益を出力させることはできる。

でも、実際にそんな運用をしたら、メンバーの進捗・工数入力の作業負荷が大きくなり、肝心のPJ作業時間が削られるので、そこまではやらないのが普通。

【2】しかし、PJ管理ツールの真の問題点は、PJメンバーのやる気を下げる点だ。
PJ管理ツールの目的は、PJのQCDの可視化であり、経営層や経理部門、間接部門にメリットがあるだけ。
大多数のPJメンバーの気持ちは全く考慮していない。

大多数のPJメンバーは、PJ管理ツールにデータを入力するだけの役割であって、PJ管理ツールやその運用を改善しようというインセンティブは働かない。
一般に、PJ管理ツールではユーザの権限制御が厳しく、一般のPJメンバーには、PJの採算情報はもちろん、メンバーの月額単価のようなマスタ情報にアクセスできないようにしているので、彼らが触るメニュー画面は、制限された機能が少しだけ載せられているだけであり、非常に貧弱な機能に過ぎない。

つまり、PJメンバーから見れば、PJ管理ツールは単なるデータ入力基盤に過ぎず、面倒なシステム以上のものではない。
ゆえに、PJメンバーにとって、PJ管理ツールを使いこなす動機やインセンティブがない。

【3】一方、Redmineのような自由なチケット管理ツールであれば、PJ管理ツールのデータを自分たちで分析しよう、そこからプロセス改善していこう、という仕組みを作れる。
「チケット駆動開発は、メンバー全員でチケットを消化していくゲーム」という雰囲気を醸し出せるからだ。

PJの外側にいる利害関係者たちのRedmineではなく、PJに実際に関わっている開発者のためのRedmineであれば、自分たちのPJをより良くしていくための仕組みとしてRedmineの豊富な機能を有効活用できる。

【4】僕もRedmineやプロセス改善に長年関わってきて、Redmineの優れた機能やUIを、PJのQCDを把握できるPJ管理ツールに発展させていく方向性を考えてきたし、Redmineの最終形は案件のQCDを管理するためのERPへ発展していくだろう、と考えていたこともあった。
しかし、ERPのような機能を盛り込んでしまうと、Redmineの良さがどんどん失われて、せっかく自分たちで作り上げた開発プロセスが、他人が押し付ける開発プロセスに変化してしまい、PJメンバーのモチベーションが落ちていく現象も何度も見てきた。

だから、RedmineをPJ管理ツールと扱うのは嫌いだ。
Redmineはチケット管理ツールとして扱うべきだ。

【5】そういう経験を振り返ると、Redmineは、外部のステークホルダーの為のPJ管理ツールというERPの側面と、PJ関係者の為のチケット管理ツールの側面の2つがあり、それらを同時に実現するのは難しいと考える。
現実としては、それぞれの役割を3層構造のシステム・オブ・システムにシステム分割する方向性ではないか、と考える。

たとえば、
View=チケット管理で進捗・課題・障害管理(QD)=Redmine、
Model第1層=コスト管理(C)=原価管理システム、
Model第2層=社内の会計システム
みたいな3層構造にする。

理由は、PJ関係者、PMOやSEPGや品質保証部門、経理部門や経営層の3つの役割ごとに、PJ管理ツールを使う目的が異なるからだ。
チケット管理に特化したUI層と、PJのQCDを見たい層、PJの原価や採算を管理したい層、の3つに分けて、Redmineで入力されたデータが裏では自動連携される仕組みになるべきだ。
そうすれば、PJメンバーのモチベーションやインセンティブが損なわれず、活発にプロセスを改善していく雰囲気を維持できるだろう。

そんなことを考えると、PJ管理ツールは最終的には、SAPのような会計システムと連動すべきERPの機能の一部と見なせる一方、RedmineはそういうERPに統合させるべきではない、とも考えている。

| | コメント (0)

より以前の記事一覧