Redmine

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)

2020/12/24

若手プロジェクトリーダー向けのRedmine教育資料の構想

最近、若手プロジェクトリーダー向けのプロジェクトマネジメント教育に、Redmineによるチケット駆動開発の資料がありませんか、とよく聞かれる。
本来は、自分が書いた本「Redmineによるタスクマネジメント実践技法」「チケット駆動開発」を渡せばいいだろうが、何せ2011, 2013年出版なので、Redmineの内容も古く、若手向けの内容ではない。
そこで、若手PL向けのRedmine教育資料の構想について考えてみた。
ラフなメモ書き。

なお、この記事は、Redmine Advent Calendar 2020の記事です。

【参考】
Redmine Advent Calendar 2020 - Adventar

akipiiさんはTwitterを使っています 「最近、若手リーダー向けにRedmine教育の良い資料はありませんか、と複数人から問い合わせを受けているが、いい本がない。僕の本も既に5年経っているので、最新バージョンに合っていない。うーむ、新しい教育資料が必要なんだけど、僕がストーリーを話したら誰か書いてくれない?笑」 / Twitter

akipiiさんはTwitterを使っています 「それから、PMOの立場でのRedmine資料の問い合わせも受けている。この手の話はそもそも少なくて、 @MadoWindahead さんのブログ記事と発表資料くらいしかない。昨今の導入事例の話を聞くと、Redmineの全社展開が多いのでニーズはあると感じる。アイデアを話すので誰かまとめてくれないかな?笑」 / Twitter

【1】Redmine教育資料が必要とされる背景とその需要の原因

市販のRedmine本が既に古くなっている。
実際、@g_maedaさんの本「入門Redmine 第5版」も2016年を最後に止まっている。
もちろん、自分が書いた本「Redmineによるタスクマネジメント実践技法」「チケット駆動開発」は2010~2012年なのでもう10年前になってしまう。

その間、Redmineは着実にVerUPして、不足している機能についてあれこれ考えていた内容はほぼ実装されてきている。
たとえば、親子チケット、構成管理ツール連携後のチケットNoの修正、など。

すると、最新の機能を持つRedmineをどのように扱えばよいか、という話にVerUPすべき。

もう一つは、チケット管理の考え方が普及して当たり前になったこと。
特に、BacklogやJiraなどのユーザ数が圧倒的に多い。
ここはウォーターフォール市、アジャイル」では、Backlogのチケット管理が当たり前のように運用されていた。

すると、チケット管理が当たり前の時代では、従来のプロジェクト管理手法ではなく、今の時代に合った手法や考え方を提示すべき、となる。

【2】Redmine教育資料の立場はどこにあるのか

ニーズとして、20代の若手のプロジェクトリーダー候補、またはプロジェクトリーダーに初めてなった人が対象になる。
こういう人たちに、チケット駆動開発という当たり前の考え方に慣れてもらい、ツールを使いながら、プロジェクト管理を実践して欲しい、という考えになる。

もう一つの立場は、PMO向けの資料だ。
つまり、単独のプロジェクトではなく、複数PJのQCDをチェックして報告すること、問題プロジェクトを一早く検知してリスク対策したい、という役割を持つ。
おそらく、最近は全社的にPJ管理ツールを導入し、社内へ標準化を推進して展開する現場が多くなったのではないか、と想像する。

【3】Redmine教育資料がもたらす効果は何か

Redmine教育資料があれば、初めてPJ管理ツールに触れるリーダーには、こういうチケット管理の考え方なら上手くいくのか、というイメージが湧くので、実践しやすくなる。
教える側としては、PMBOKのようなPJ管理の共通的な考え方にも触れながら、チケット管理して欲しい。
あるいは、スクラムのようなアジャイル開発手法、プラクティスを上手く使って、チケット管理と組み合わせて運用して、効果を出して欲しい。

【4】Redmine教育資料の観点や論点は何か

観点はいくつかあるだろう。
従来のWF型開発であれば、PMBOKベースに、PJ立ち上げ→PJ計画・実行・監視→PJ終結の流れに沿って、Redmineのチケット管理でプロジェクトのQCDを維持する考え方を習得することになるだろう。
特に、PMBOKはWBS駆動が多いので、WBS管理とRedmine機能の対応が重要になると思う。

もちろん、ウォーターフォールであっても、アジャイル開発のプラクティスとチケット駆動開発は相性がいいので、チームビルディングにも適用できる。

もう一つは、スクラムをベースとして、PJ立ち上げ→スプリント計画・デイリースクラム・スプリントレビュー・スプリント・レトロスペクティブ→PJ終結、という流れがある。
ここでは、スクラムのイベントとRedmineの機能の対応付けが重要になる。
Ver2.x時代はScrumの良いプラグインがあったが、今は無いので、Redmineの標準機能でどこまで対応付けて運用するか、という点が論点になる。

一方、カンバンをベースにしたチケット管理の手法もある。
カンバン仕事術」を読んでいたら、チケット管理とカンバンはとても相性が良いという点に改めて気づいた。

実際、「ここはウォーターフォール市、アジャイル」でのBacklogのチケット管理は、カンバンの運用にそっくりだ
なぜならば、統合認証基盤チームではシステム保守が仕事なので、開発プロジェクトというよりもシステム運用でエンドレスな仕事になるため、カンバンで常に流れるタスクを管理したい動機があるからだ。

結局、PMBOK+WF型、スクラム+アジャイル開発、カンバン+ITILという3つの運用について、Redmineと組み合わせたPJ管理手法を説明すべきだろう。

【5】Redmineによるチケット駆動開発の注意点、よく聞かれるFAQ

上記の3つの論点でRedmineによる運用を教育資料で伝えたとしても、気に留めておいた方が良い注意点はある。
実際の現場では、そんなきれいな運用ではないからだ。

また、よく聞かれるFAQもあるので、それらも追加しておきたい。
困った時に、そのFAQを思い出せるだろうから。

このFAQを煮詰めて共通化してストーリー化したら、パターン言語になるだろうと思う。

最後に、こういうRedmine教育資料が公開されたり出版されたりしたら、需要はありますか??

| | コメント (1)

2020/12/20

PMO観点でRedmineの使い方とは何か

PMO観点の教育資料の要望も割と多いと思う。
ラフなメモ。

【参考】
akipiiさんはTwitterを使っています 「それから、PMOの立場でのRedmine資料の問い合わせも受けている。この手の話はそもそも少なくて、 @MadoWindahead さんのブログ記事と発表資料くらいしかない。昨今の導入事例の話を聞くと、Redmineの全社展開が多いのでニーズはあると感じる。アイデアを話すので誰かまとめてくれないかな?笑」 / Twitter

【1】IPA資料:ITプロジェクトの「見える化」総集編のP.78では、IPAの観点で、PMOの類型を紹介している。

ITプロジェクトの「見える化」総集編

当初は、問題プロジェクトの撲滅にある。
すなわち、問題になるPJの事務局を作り、PMOがPL/PMを支援していく。
これは事務局型PMOであり、PMOはPLの世話役みたいな立場である。

そして、PMOは標準化推進型PMOになる。
これは、全社標準でプロジェクトのQCDをコントロールし、安定させるために、進捗・品質・課題・コスト管理の標準ルールを定めて、経営陣に報告させて、プロジェクトをモニタリングする。
こういう役割の仕事が、PMOの主なお仕事。

すると、全社横断的なリスク管理指向の「リスク対応型PMO」プロジェクト管理に進展する。
つまり、全社から見て、早めに問題プロジェクトを検知し、そのリスクを摘み取るようにPMOは動く。
実際は、プロジェクトの各フェーズでゲートを設けて、経営陣や管理部門、技術部門がレビューする運用が多い。
よくある例は、受注前の企画や予算確保、要件定義での開発費用の確定では必ず、経営陣のレビューが入る。
そして、テスト計画やテスト完了、リリース判定のレビューが多いだろう。

ITプロジェクトの「見える化」総集編にある「戦略型PMO」は、たぶん経営企画部みたいな役割だろうか。
このレベルになると、PMOではなく、社長直属の経営企画室みたいな感じだろうか。

こういう類型を踏まえて、それぞれのPMOの役割、期待される機能、実際の活動とRedmineの機能をフィットギャップ分析することになるだろう。

【2】PMOとRedmineに関する資料は、PJ管理の事例に比べるともっと少ない。
門屋さんの資料ぐらいしかないのが現状。

予防型PMOがRedmineでのプロジェクトモニタリング方法を伝授する | マドびっ! Madosan's View

門屋さんの記事のポイントは2つあると思う。
一つは、PMOがPJの現状を把握する時に、Redmineのどの機能に着目するのか、という点。

注目すべき点は、チケット一覧だけでなく、活動タブを重視している点。
PJの活発度合いから、PJの傾向を定性的に見ている。

(引用開始)
活動
どのくらいの頻度で更新されているか
新規と完了の比率はどのくらいか
利用メンバーはどのくらいいるか

チケット一覧
親子チケットを多数使う管理方法が主です
カスタムクエリ「親チケット別整列」を利用する
(ソート順に親チケット・昇順を追加したもの)

全体像とチケットの設定具合を比較する
何割程度チケット化されているか

次のトラッカーごとの確認において
必要に応じてカスタムクエリを作る

トラッカーごとの確認
「WBS」
チケットの粒度について
大日程レベル・作業まで落とし込まれているか
開始日・期日の登録具合はどの程度か
週あたりの完了数を算出し
進捗に問題がないかを把握できればベスト

「課題・障害」
動きがあるチケットは実施者に任せる
動きがないチケットは問題ないか確認する
動きがありすぎるチケットは話がずれていないかを確認

課題の傾向を確認するときは全件を確認する
類似課題、一部機能に偏っている
などの癖を見つけて
今後の作業において予防できないか考える

収束時期を読むときは、残を確認する
発生数・完了数を日別に追えれば良いが
定点チェックのほうが多い
(週ごとのチェックなど)
作成日や更新日からも判断する

チケットの注記の確認
更新回数が多いチケットについては
注記から話がずれてないか、混乱していないかを確認する
(引用終了)

他に面白い点は、週毎のチケットの完了日数や完了チケット数を元に、PJの進捗度合いを定量的に見ている点。
つまり、リードタイムやベロシティも見ているわけだ。

また、PJの途中の工程で、概要スケジュールを元に、詳細化したWBSがどこまで実現されたのか、その割合も見ている。
実際、PJ計画時に担当者レベルまで落としたWBSまでは作れないから、各工程が始まる時点までには詳細化されているはずだ。
それを元に、全体スケジュールのうちどこまで実現可能なスケジュールに落とせたのか、実際の進捗はどこなのか、を把握することができる。

【3】もう一つは、PMOで長年PJの状況を調査した結果、プロジェクトリーダーが能力を向上させて成長していくパターンに傾向がある事。
PMxTMマトリクスの考え方が参考になる。



PJ管理のようなマネジメントは経験しないと向上しない。
しかし、誰もが経験できるわけではない。

一方、実際のPJ管理では右往左往しやすい。
そういう時に、PJの状況を把握し、PJをコントロールできるような管理基盤が必要だ。

そんな管理基盤としてRedmineのようなツールが必要となる。
なぜ、そんな管理ツールがあるとメンバーのマネジメント力は上がっていくのか?

理由は2つあると思う。
一つは、管理ツールによってプロジェクトをモニタリングでき、PJで問題が発生しても、その状況や原因を把握しやすく、対応しやすいから。
チケットに状況が最新状態で書かれていれば、問題解決のためにメンバーがどう動くべきか、を的確に指示できる。

もう一つは、特にチケット管理は、PMBOKの言うコミュニケーション計画のイベントやスクラムのようなアジャイル開発のイベントと相性が良いから。
毎日の朝会でチケット状況を共有する。
毎週の課題確認会で、チケットの棚卸しをする。
毎週・毎月のチームふりかえりで、メンバー全員で改善策を上げて、改善活動を実施していく。

つまり、イベントにチケット運用を対応付けて、チケットを見ながらメンバーと状況確認すればいい。
そうすれば、「問題 対 私達」という関係を作れるので、議論しやすくなる。

【4】他にPMOで必要な観点は何だろうか?
PMOは、SEPG(Software Engineering Process Group)の役割もあるので、チケットのデータを元に、PJやソフトウェアのQCDの情報を集計分析したくなる。

プロダクトの品質分析、ゾーン分析、テスト工程ごとのトレンド分析、信頼度成長曲線、プロセスの品質状況の分析とか。
リードタイム、ベロシティ、サイクルタイムなどの進捗や生産性の情報とか。
つまり、プロダクト、プロセスの両方の観点でQCDのデータを分析したくなる。
そして、その情報を元に、PJ側にフィードバックして、PJの改善活動に役立てたい。

すると、メトリクスを得るにはチケットにQCD分析用カスタムフィールドを設定すればいいのか、どんなメトリクスがどの場面で効果的なのか、という問題が出てくる。
この辺りは一般論もあれば、個々の現場では異なってくるだろう。
いろんな知見もあると思う。

そういう内容も整理してみたいと思う。

| | コメント (0)

より以前の記事一覧