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

2018/09/25

Redmineのチケット駆動開発では、チケットに複数の意味を持たせて運用した方が上手く回る

Redmineのチケット駆動開発の面白さは、最初は課題チケットでしかなかったのに、いつの間にか作業チケットに変わった、というように、チケットにストックとフローの二重性を持たせて、チケットに複数の意味を持たせている点にあると思う。
以下、ラフなメモ書き。

【参考】
Redmineによるチケット駆動開発はストック型プロセスとフロー型プロセスの二面性を持つ: プログラマの思索

ストック型チケットは記憶媒体、フロー型チケットは流通媒体: プログラマの思索

チケット管理システムは作業の構成管理と同じ: プログラマの思索

【1】以前、下記のツイートがあった。
最初はRedmineでチケット管理して上手く回っていたのに、ガントチャートで厳しく管理し始めたら、内容が空っぽのチケットが大量発生して、チケット駆動でなくなった、というアンチパターン。

【1-1】
akipiiさんのツイート: "ガントチャートはもう時代遅れなのかな?RT @kabukawa: Redmineはチケットからガントチャートが自動で作られて便利なんだけど、ガントチャートを目的に導入すると、Excelより入力が面倒で使わなくなるか、設計とか実装ってタイトルの中身が空のチケットか沢山できて、時々脱力する。"

門屋浩文@redmineeva☀️さんのツイート: "個人的には品質状態(中身)が見えないガントチャートは時代遅れだと思いますよ ごまかせるもの… "

あさこ@センチちうさんのツイート: "ガントはあくまでも、参照かなー。 誰がなんのために見るか、使うかを区別しないと手段が目的になってしまう。 時代遅れとかではなく、手段の違いだと思います。 ガントで見ることができるものをちゃんと区別していないと、ごまかしとかが生まれてくる。見るべきものを適切なもので。… https://t.co/aw4zR2QAQw"

門屋浩文@redmineeva☀️さんのツイート: "目的を理解して使ってる人 ほとんど見たことないよ(疲れていてネガティブです) うーん、見たことあるかなあ? 俺はWBS辞書 つまりチケット一覧をソートして見る派なので 期間にかかる工数も成果物の精度も見ないで何がわかるのかわからないから パッとみで安心したって意味ないもの… https://t.co/AAWOZvyaXo"

昌。さんのツイート: "まどさんがネガティブ!いかんですな。確かにぱっと見安心する使い方してる人たちいますけども。 私は最アジャイルさんのLycheeのおかげでRedmaineにおけるスケジュール見える化はプロセスわからない派にも使えるかもと思うことができましたさ。… https://t.co/4uE4LNBrDL"

門屋浩文@redmineeva☀️さんのツイート: "ネガティブ続きですが、、、ガントチャートが問題の早期発見や解決につながってないんじゃないかなと感じてるから時代遅れと言った 把握してる人に責任押し付けたって誰も幸せにならんから ガントチャートのみ見て改善につなげられる凄腕なら別だが 時系列で5つ並べてみたら気が付けるかなあ俺… https://t.co/fPxjDRBRLu"

あさこ@センチちうさんのツイート: "ガントだけだと、早期発見なんてほぼできないよね。その目的で使うならば間違いなく、「それじゃないっすよ」と答えるかなー。 ガントの強みってなんだろうねー。 タスク同士の流れとか、いつまでに何が終わるのか、どのくらい終わってるのかを見るだけのツールとして今は使っているかも。… https://t.co/xSecapQWwY"

昌。さんのツイート: "ガントに限ったことではありませんが、ツールに対してこれダメ!ってなる人は弊社の場合は大体が目的見失ってるかツールに夢見てるひとですかね。あなたが使ったようにしか使えませんよー、ってなる。… "

やっさん🍶さんのツイート: "管理者より担当者視点だと (関連あれば)チケットを前後で関連付けちゃうので、前後の関係とか、並列度とかを見るくらいですね。ガントチャートの利用って。… "

akipiiさんのツイート: "ガントチャートはメーカーの製造工程や発注作業の管理に向いていて、ソフトウェア開発のように、作業が不明確で、担当者がコロコロ変わり、管理単位が1日未満で粒度が小さい場合は向いてない。所詮、ガントチャートはマネージャがプロジェクト管理で使うビューの一つに過ぎないと思う。… https://t.co/wc6TLz0MKc"

【1-2】akipiiさんのツイート: "知りたい。RT @g_maeda: Redmineのガントチャート、実は社内では全く使ってない。ガントチャート機能を使ってる組織ってどのくらいの割合なんだろう。"

あさこ@センチちうさんのツイート: "うちは、お偉いさんたちが、プロジェクトのMilestoneとガントチャート、リスク管理表と合わせて見るということをしてくれています。 Milestoneに対してどうか、間に合うか、作業的にリスクがあるかという観点で使ってますね。 ガントチャート一本で何かを見るということは難しい…… https://t.co/uuNqP8gYWb"

あさこ@センチちうさんのツイート: "多分、そのリソースやスケジュール確認するのも、目的が合って、そこにたどり着くまでの一つのプロセスになってますよね、ガントチャート。 なので、みたい観点もある、って感じですかね?… "

昌。さんのツイート: "です。>みたい観点 個人的にしっかりプロセスてか目的に沿ってチケット運用してる限りタブ切り替えるだけで自分やメンバーのタスクが見える化されてるから便利〜なので、とりあえず朝イチとか進捗確認時に眺めたり確認したりな感じです。… https://t.co/pcMefEEx29"

【1-3】akipiiさんのツイート: "第3回 Lychee Redmineユーザ会 - connpass https://t.co/5O2rOzCMxx 「Redmine + Lychee導入のアンチパターン」の講演は、チケット管理が回っていたのに、Lycheeガントチャートを使いだしたら、空っぽのチケットが増えてチケット駆動でなくなった、というアンチパターンだろうか?笑"

【1-4】akipiiさんのツイート: "読み返したら、当初の目的が忘れられて、手段が目的化してしまった、という症状に思えてきました。チケット管理がうまく回っていたのに、ガントチャートの監視を厳しくしたら、チケットの中身よりチケットの進捗率が重要になって、チケットが忘れ去られた、みたいなイメージ。… https://t.co/u1P1tcsDZB"

りょうまさんのツイート: "そうですね。私はガントチャートは進捗の俯瞰とインデックスだと捉えてるので、その奥に詳細があるのが当たり前だと思い込んでいました。… "

昌。さんのツイート: "ひとは簡単に目的と手段が逆転しがちなので気をつけねばいけませんね。いつも、目的はなんだ?と自分にも問いかけるようにしてます。… "

【1-5】その真因は、本来のチケットは、プロジェクトで発生する変更要求、課題、作業、障害など、プロジェクトで管理すべき対象全てが起票されるはずなのに、進捗管理だけの側面だけ重視されてしまい、チケットの2重性がなくなって、スカスカの空っぽのチケットになってしまった、ということだと思う。

つまり、本来のチケットは、課題の検討履歴、変更要求の作業履歴というストックの側面を持ち、かつ、チケットの納期や作業進捗も合わせて管理できると言うフローの側面も持ち、2重性があったのに、担当者の作業進捗だけ気にするようになってしまい、フローの側面だけ残り、ストックの側面がなくなってしまった、というアンチパターンが発生したわけだ。

【2】以前、ISO9001のQMSの運用の現場を見た時、変更要求や変更管理に関するExcelの作業依頼書と、設計書やリリース手順書などのExcelドキュメントの2種類のExcel帳票が管理されていた。
その運用は非常に煩雑で、最新版のドキュメントが連携されなかったり、リリース漏れが発生したり、非常に手間がかかっていた。
今どき、Excel帳票で管理する現場はありえないと思うが、古い製造業ほど、Excel帳票がはびこっている。

チケット管理システムは作業の構成管理と同じ: プログラマの思索

その原因も上記と同じ。
つまり、ISO9001で実現する時、Redmineでチケット管理せず、Excel帳票で管理する場合、作業依頼書という変更管理に関するフローの側面と、設計書やリリース手順書などの構成管理対象になるストックの側面は、2つのExcel帳票に必ず分かれる。
そして、その2種類のExcel帳票を常に最新化しながら、申請承認フローに沿って厳密に管理せねばならない。

【3】では、なぜ、Excel帳票の運用は必ず失敗するのか?

【3-1】なぜなら、昨今のように経営環境がすぐに大きく変化する場合、Excel帳票で逐一管理する運用は、その変化についていけないからだ。
変更管理の運用と構成管理の運用はシステム開発ではとても重要だが、2種類のExcel帳票で管理するのは煩雑すぎて、現実として運用できないだろう。

結局、Redmineのようなチケット管理ツールで、フローの側面であるワークフロー管理と、構成管理の側面であるソース管理連携機能の双方を実現しなければ、経営環境の変化のスピードにシステム開発そのものが付いていけいないだろう。

例えば、最初は課題チケットで起票したが、課題に対して複数の代替案を出して検討し、一つの解決案を決定した履歴を残す。
さらに、その対策の作業状況も履歴として残し、課題が解決されるまで、チケットに全ての情報が残す。
すると、そのチケットのステータスが変わるたびに、裏では、その時々の意思決定の状況が管理され、マネージャによる承認プロセスを経て、システムに反映されてリリースされていく。

例えば、最初は顧客からの変更要求の仕様変更チケットで起票したが、その変更要求の発端を記録しておく。
また、チームでそのアーキテクチャや実現方法を検討した経緯を記録しておく。
すると、そのチケットのステータスが変わるたびに、裏では、担当者の作業状態が管理され、マネージャや利害関係者の承認プロセスを経て、システムに反映されてリリースされていく。

つまり、当初は課題チケットや変更要求チケットだったのに、チケットが更新されるたびに、作業チケットの意味合いに変わり、チケットが進捗管理対象になる。
さらに、チケットが更新されるたびに、変更管理の承認プロセスの意味も込められて、チケットが変更管理対象にもなる。

すなわち、チケットはストックとフローという2重性の性質が一つの実体として実現されている。
チケット管理では、ストックとフローという2重性の性質を、マネージャやメンバーが深く意識しなくても運用できるような仕組みを提供しているわけだ。

【3-2】本来あるべき姿のチケット管理では、チケットに変更管理や進捗管理というフローの側面と、成果物の構成管理や課題や作業の履歴管理というストックの側面を故意に持たせることで、スムーズに運用させる。

一方、Excel帳票でそれらを管理しようとすると、フローの側面のExcel帳票と、ストックの側面のExcel帳票の2種類に必ず分かれてしまう。
なぜなら、ステータスだけ管理したいExcel帳票と、リリース対象の成果物として厳格に構成管理したいExcel帳票は、管理方法が大きく異なるので、具体的な実体として分けざるを得ないからだ。

すなわち、Redmineのチケット駆動開発は、2種類のExcel帳票の具体的な実体が1つのチケットに合体されている。
そういう背景を、チケット駆動で運用している人は、意識しているだろうか?

【3-3】Redmineでのチケット駆動開発では、メンバーはストックの側面のチケット管理を意識しているが、その背後では、変更に関する申請承認という変更管理、そして、進捗の作業状況の把握という進捗管理、というフローの側面も裏で持たせている。

2種類のExcel帳票で分けて二重管理している運用が、チケット管理では、チケットという1つの実体で管理できるので、非常に運用しやすくなる。

よって、Redmineのチケット駆動開発ではチケットに複数の意味を持たせて運用した方が上手く回る、と僕は思う。

【4】僕の経験上、メンバーはストックの面だけ意識してもらえばよく、フローの側面はそんなに気にしない方が、チケット管理は上手く回ると思う。
もちろん、変更管理や進捗管理は重要だが、その意識が強すぎると、チケットのライフサイクルが長くなり、チケット駆動のメリットが薄れるから。

チケットに対するフローの側面を意識し始めると、ストックの側面を忘れてしまう。
チケットのストックの側面こそが重要なのに、その部分が軽視された運用になってしまうのだ。
ガントチャート重視のチケット駆動開発が、空っぽのチケットを大量発生させるアンチパターンはまさにそれだ。

一方、ストックの側面ばかり強調すると、チケット入力の運用のコストが上がってしまう。
チケットは手軽に起票して、記録して欲しいのに。
誰も更新しなくなるRedmineは、ゴミ箱と同じ。

だから、チケット管理の運用では、フローの側面を強調しすぎると空っぽのチケットが増えて破綻するし、ストックの側面を強調しすぎると、誰もチケットに起票しなくなって破綻する。

チケットの2重性という奇妙な性質を活かすには、そのバランスが重要だ。
フローの側面だけ、ストックの側面だけ、という運用では、チケット駆動のあるべき姿を実現できないし、チケット駆動の効果が得られない。

そのバランスを維持するための運用ノウハウは、実は数多くの現場で暗黙知となっていると思うので、収集してみたいと思っている。

| | コメント (0)

2018/09/09

第2回astah関西の感想 #astahkansai

昨日の第2回astah関西の感想をラフなメモ書き。

【参考】
第2回astah関西勉強会「開発現場のモデリング事例紹介」 - connpass

Mix Leap Study 特別編 -「開発現場のモデリング事例紹介」(astah勉強会) - connpass

7/7土の第2回astah関西の見所 #astahkansai: プログラマの思索

第2回astah関西勉強会(2018/9/8)のスライドが公開されました | astah in 5 min

【1】7月の西日本豪雨で1度流れ、4日前の台風の影響で参加者は減りましたが、参加者の熱気もあって盛り上がり、雰囲気はとても良かったように思います。
講演の内容もビジネスモデリングから組込み系、astahのより良い使い方など盛りだくさんで、飽きない感じでした。

講演中のアンケートでは、astahの利用または経験者が多数いた事、組込みエンジニアまたは組み込み系コンサルタントの方が半数以上いた点が興味深かったです。
僕自身は、業務系Webシステム開発をベースとしたビジネスモデリング系だったので、グループディスカッションでは、全く違う層の人たちと、最近の電気自動車や組み込み機器のセンサー化、機械学習の動向などの話が聞けて面白かったですね。

以下、講演内容について感じたことをメモしておく。

【2】兒玉さんの講演では、astahに描いたアクティビティ図から、astahAPIで情報抽出するデモを見せてくれた。

考え方としては、レガシーなCプログラムから手作業でastahのアクティビティ図へリバースしてモデリングする。
その時、アクティビティ図の吹き出しに、該当ソースの行番号も書いておく。
その後、astahAPIを用いて、JavaScriptでアクティビティ図の吹き出しにあるソース行番号の情報を抽出し、Excel設計書に貼られたCプログラムと照合して、合致した行番号に色塗りする、という仕組み。

つまり、astahのモデルとCプログラムの照合作業をastahAPIを使って自動化する、という作業を実現されている。
もちろん、astahのモデルは手作業で描くし、ソース行数も手作業でモデルに埋め込む必要はあるが、モデルを作っておけば、後はastahAPIでいくらでも情報を抽出できるので、照合やカバレッジなどの作業を自動化できる点は面白い。

astahを起動せずにJavaScriptで情報を取得する方法: プログラマの思索

また、astahAPIは、公開されているJavaDocだけでなく、astahからXML出力されたXMLファイルのXPATHを参考にすると良い、という話もあった。
つまり、XPATHからJavaDocにあるメソッドを連想しやすくなる、ということで、これは面白いなと思った。

astah* API

astah* API概要

astahAPIを使いたいと思っていても、大量のJavaDocから見当を付けるのが面倒でいつも何とかならないかな、と思っていたので、この発想は使ってみたいと思った。

【2】高井さんの講演では、組込みシステムのソースのリバースエンジニアリング作業は、プログラマだけでなく、熱力学など自然科学の専門家、自動車や家電機器などの業務の専門家も関係していて、彼らドメインの専門家のリバースエンジニアリングの観点は異なるので、SySMLという共通言語によって有益な情報を組合せることができる、という主張が面白かった。

確かに、プログラマはCやC++は強いだろうが、熱や振動などの自然力学の法則に詳しいわけではないから、アルゴリズムの本来の意味まで分からない。
自然科学の知識を持つ専門家であれば、このアルゴリズムが表す制約条件は、鉄板の強度や耐熱や振動の範囲を示す、などの知見を言い当てることができる。
そうすれば、自動車や家電製品の設計エンジニアは、材料の強度や耐熱、振動などの制約条件を元に、製品の形状や大きさはこういう範囲で設計しなければならない、等の知見が得られる。

すなわち、リバースエンジニアリングした内容は、プログラム層、自然科学のドメイン層、業務ドメイン層等で解釈が異なるわけだ。
そんな事を理解すると、ソフトウェアを組み込んだハードの設計や開発を真に理解するには、プログラミングだけでなく、自然科学の知識や製品の知識まで知る必要があり、膨大な範囲になる。
だから、組み込み機器の設計開発は、どんどん難しくなっているのだろう、と推測した。

もう一つ面白いと思った話は、SysMLはソフトウェア技術者の地位を高めた、という話。
つまり、今まではハードの部品ができた後で、ソフトウェア開発を行うので、ソフトウェア開発者は限定された仕様の中でプログラミングせざるを得ず、主導権を取ることができなかった。
しかし、ハードの部品が開発される前に、SysMLを用いて、製品の論理構造をモデル化できるようになり、ハード技術者へソフトウェア開発に必要な仕様や制約条件を事前に伝えられるようになった、と。

確かに、ハードの部品や製品は、材料の購買・発注・組み立てなど数多くのコストがかかるので、そう簡単に作り直しはできない。
一方、ソフトウェアはいくらでも変更できるので、無理な要望を受けてしまいがち。
しかし、ハードを発注する前の設計段階で、ソフトウェア開発では、これだけのメモリや性能は必要です、という情報を事前にハード設計者に伝達できれば、ソフトウェア開発もやりやすくなる。
SysMLはそういう波及効果があった、という話が面白かった。

【3】細合さんのSTAMPの講演後、僕は、そういう機能安全設計のモデリング技法は、一般事象のリスク識別に適用できるのではないか、と質問してみた。

僕の理解では、自動車の機能安全設計のモデリング技法STAMPでは、対象のハード製品の利用シーンをユースケースとみなして、そこからハザード分析し、人命に関わるリスクを識別し、そのリスクを潰す為の安全設計の仕様を導き出す。
そうならば、PMBOKのリスク管理に出てくるリスク識別において、ある事象のリスクを、何らかの対象の相互作業(I/F)をユースケース(利用シーン)とみなすことで、STAMPの技法を適用できるのではないか、と連想したからだ。

しかし、後で、宿口さんから、STAMPとリスク管理は観点が違いますよ、と教わった。
宿口さんの話を理解した限り、PMBOKに出てくるリスク管理は発散系の技法に近いが、STAMPは収束系の技法である。
仕様が固まっている製品に対し、製品の利用シーンを想定して、それを元にハザード分析していく手法なので、根本から手法が異なる、と。
話を聞いた限り、STAMPの技法は、ロジカルに説明できるような資料作りに役立てる技法の一つ、という印象を受けた。
僕はPMBOKもSTAMPも詳しくないので、この辺りはまた考えてみる。

【4】稲田さんの匠メソッドによるビジネスモデリングでは、経験に基づいた試行錯誤の話が興味深かった。

彼の講演の中で、ビジョンから業務要求・IT要求・仕様へ至るまでモデリングしていく中で、モデルを書いていると、ダブリやつじつまが合わなくなる時がある。
特に、数多くのステークホルダーにヒヤリングしてその内容を収集すると、そういう傾向が出やすい。
だから、その内容を早めにフィードバックして、何を最優先すべきなのか、何を妥協すべきなのか、を決めていく、と。

【5】僕の講演では、astahのRedmineプラグインの紹介。

AstahのRedmine連携プラグインが公開されました: プログラマの思索

言いたかったことは、単にプラグインの紹介だけでなく、その背景にあるモデリングツールが今後発展するために必要な機能追加の要件だ。
それは、モデルのグルーピング機能とモデル間の相互リンク機能を追加することだ。
それらは、モデルの粒度やモデルのトレーサビリティという、モデリング作業の問題解決に直結すると考えている。

モデル間のトレーサビリティと粒度、変更管理に関するastahのあるべき姿: プログラマの思索

モデルの粒度とトレーサビリティ、変更管理の問題は、モデリングツールではなくUMLそのものに真因があるのではないか: プログラマの思索

astahで設計書とモデル、プロセスをつなぐ為の資料のリンク: プログラマの思索

高井さんと話していて、モデルを沢山書いていくと、astahでもモデルのタブを切り替えるのが面倒になってくる、という話があった。
モデルが3個ぐらいなら問題ないが、10個、50個と書いていくと、モデルを探す作業に相当の時間が取られるから、とのこと。
つまり、モデルの関連や情報を検索するのに時間がかかっているのだ。

その問題の真因には、モデルの粒度とモデルのトレーサビリティがあると思う。
大規模なシステムになるほど、概念モデル、論理モデル、物理モデルなどモデルにも数多くのレイヤが発生し、区別せざるを得ない。
すると、それらモデルの粒度を合わせるために、グルーピングしたくなる。
しかし、そういう機能がUMLの仕様そのものにないし、astahにもない。

また、一つのシステムを静的な観点、動的な観点、状態遷移図、利用シーンなど数多くの観点で分析したモデルを作ったとする。
それらモデルは、一つのシステムの射影にすぎないので、相互にリンクさせることで、追跡できるようにしたい。
そうすること、重複や考慮漏れに気づくことができ、モデルの精度を上げることができるはず。
しかし、そういう機能がUMLの仕様そのものにないし、astahにもない。

つまり、astahを含めた既存のモデリングツールは、大規模なシステムの分析にはたぶん力不足。
もっと大規模で複雑なシステムを、数多くの観点で数多くのモデルで分析した時に、それらモデル間の整合性をとるために、モデルの粒度とモデルのトレーサビリティという考え方が必要になってくると思う。

一方、アプリ開発者の観点では、モデルのグルーピング機能は所詮、フォルダ分けという機能にすぎない。
また、モデルの相互リンク機能は、モデル間の相互のハイパーリンクという機能にすぎない。
つまり、モデルの粒度とモデルのトレーサビリティという問題解決に必要なモデリングツールの機能改善は、さほど難しいわけではない。

しかし、そういうちょっとしたUIの機能改善が、モデリングツールを洗練させるし、モデリング作業そのものを効率化させていくものと思っている。

モデリング技術の習得とモデリングツールの習得は表裏一体: プログラマの思索

【6】本勉強会のスコープは、「製品astah」「astahで描けるモデリング技法全般」というかなりマニアックな内容だったので、今後の勉強会の継続を懸念していた。
いくら僕が勉強会をやりたい、と思っても、そもそも人が集まるのだろうか、という不安があった。

しかし、参加者から好意的な感想も多く、また、本勉強会を以前からウォッチしていた、という方もいて、勉強会のニーズはある、と感じ取った。

いつまで続けられるか分からないけど、緩く長く続けられればいいな、と思う。

| | コメント (0)

2018/03/09

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

以前のSQIP2016で、チームの開発環境が開発プロセスの品質を向上させる点を指摘していた資料があったのでメモ。
そこから、未だにチームの開発環境が導入されない理由も考えてみた。
途中で書きかけなので、後で書き直す。

【参考】
モダンなチーム開発環境を追求しよう : SQiPシンポジウム2016 SIG8 - MassKaneko.Out

(引用開始)
チーム開発 とはソフトウェア開発における技術分野の呼び名であり、"チーム開発実践入門(技術評論社, 2014)"*1 の発刊を機に日本で普及している技術分野名だと思います。バージョン管理・課題管理・継続的インテグレーションなどの技術分野をひとまとめにしているのが特徴で、組織的におけるソフトウェア開発のワークスタイルを大きく決定づける技術分野だと考えています。国際的に "チーム開発" と同義の用語が存在するか確認が取れていませんが、ソフトウェアライフサイクルプロセスの規格である ISO/IEC 12207 におけるサポートプロセスと多くの技術領域が重なります。

ここ5年くらいの国内のチーム開発分野におけるトレンドを振り返ると、チケット駆動開発, Pull Request, 継続的インテグレーション, ChatOps が思い浮かびます。例えば2012~2013年には国内大手/有名サービス企業においてGitHub Enterprise の導入事例が報告され*2、SlideShare にてツールの名前で検索すると、カンファレンスや勉強会における企業からの発表資料が多くヒットします。

一方、SQiPシンポジウムはソフトウェア品質を扱うシンポジウムであり、企業での事例が毎年20件以上報告されるのですが、チーム開発技術にフォーカスをあてた発表は何年か振り返っても多くは見当たりません。本文執筆時点で公式ウェブサイトでは2009年からの発表資料・論文が公開されていますが、それらのうち私から見てチーム開発技術にフォーカスをあてている、またはチーム開発のツールが発表内容に大きく関係していると判断できるものは5件でした。
(中略)

私は経験上、チーム開発技術は品質向上に大きく寄与し、数あるソフトウェア工学技術の中でも優先的に取り組むべきものと考えておりますので*3、なぜSQiPシンポジウムではチーム開発の発表が少ないのだろうと疑問を持ちました。理由として "もう当たり前で語ることが少ない" ということも考えられますが、「いや、絶対そのようなことは無いし需要はあるはずだ。」と信じてSIGを主催することにしました。
(引用終了)

【1】僕は、「私は経験上、チーム開発技術は品質向上に大きく寄与し、数あるソフトウェア工学技術の中でも優先的に取り組むべきものと考えております」という意見に、完全同意だ。

製造業の品質管理に影響を受けすぎている人達は、Excelドキュメントによる標準プロセスの構築ばかりに意識が行きたがる。
しかし、そのやり方が実際の案件で作業にブレーキを掛けたり、逆にシステムの品質を向上させない症状を生み出している現場を色々見てきた。

むしろ、チームによる開発を支援する共通基盤を準備した方が、開発スピードも早くなるし、品質向上にも役立つ結果になる。

では、なぜ、彼らはチーム開発の開発基盤を構築して運用する方向に目が向かないのか?

【2】いくつかの理由が考えられる。

【2-1】開発環境の構築に投資する発想がない。

開発基盤を作ると、保守コストがかかる。
日本のプロジェクトマネージャには、開発環境に投資する、という発想がない。
管理コストに投資する発想がない。
案件をまたいだ共通の開発基盤に投資する場合、社内の稟議申請が必要になり、経営層を納得させるだけの理由が作りにくく、普通は通りにくい。

但し、OSSの開発基盤ならば、プロジェクトマネージャに技術力さえあれば、自身の人件費以外はほぼ無料で導入できる。

【2-2】従来通りの開発スタイルによる過去の成功体験があるから

以前、新しい開発ツールを導入して失敗した経験がある。
新しい開発ツールの考え方に慣れることを嫌う。

特に、有償のパッケージ製品には、販売元の会社のプロセスが埋め込まれている為、現場のプロセスにはなかなかフィットしない。

Redmineの理想と現実~RxTStudy #12 「ITS活用最前線~現場からの実践報告」の感想: プログラマの思索

標準化作業は、SDCAの考え方。
つまり、誰もがいつ、どこでも同じ作業をやれるような仕組みを標準として定め、その標準に従って、DCAを回すべき、という発想。

PDCAサイクルとSDCAサイクル【品質改善と維持管理の考え方】

この標準化の考え方は、工場のブルーカラー、外食チェーンや他店舗展開の小売業の作業者、コールセンターやサポートデスクのオペレータの管理には向く。
しかし、IT技術者のようなクリエイティブな人には向かない。

アジャイル開発は常識だ: プログラマの思索

なぜなら、IT技術者である限り、最新技術のキャッチアップは必須。
よって、過去の経験が全てクリアされて、一から学習し直す覚悟がいる。
しかし、その学習コストを各自で責任を負うのはハードルが高い。

【2-3】既に投資した社内ツールを捨てられないから

社内に既に、内製化したツールがある。
従来の社内ツールを捨てられない。
従来の社内ツールに、数多くのプロセス資産が蓄積されているので、埋没コストになる。

一般に、2000年頃にBTSが必要と認識した、レベルの高い会社で、そういう社内ツールを内製化した場合が多い。
しかし、OSSの発展に比較すると、UIが古かったり、機能改善が追いつかず、OSSよりも機能が劣っている場合が多い。
なのに、社内ツールを廃棄すると、埋没コストになるから捨てられない。

Redmine運用の感想を集めてみた: プログラマの思索

Sean Osawaさんのツイート: そういうのってホントにあるんだなぁ〜 RT @sonoyu670 あるお客さんのところでは「それredmineでええやん」という使い勝手の悪い独自のPJ管理システムを持ってて、これウン千万とかかけて作ったんだろうな、馬鹿だな、って思ってた。

(引用開始)
フリーのBTSがまだ普及していない頃、障害管理やタスク管理の重要性に気づいた会社は独自でBTSやITSを作り込んでいた。
そういう会社は先見の明があったに違いない。
だが、長年使ってくると、オープンソースのBTSやITSの方が普及してかつ高機能になって、逆に足枷になっている場合が見られる。
システムを長く使うのか、それとも新しいシステムにリプレースして移行するのか、判断が難しい。
(引用終了)

すなわち、組織変革の障害になりうる。
結局、変革に対抗する力となり、組織慣性として惰性のまま現状維持が続く。

埋没コストとは・意味|MBAのグロービス経営大学院

サンクコスト(埋没費用)とは | カイロスのマーケティングブログ

【2-4】開発環境は衛生要因であり、動機づけにつながらないから

開発環境が導入済みだとしても、動機づけにつながるとは限らない。
環境がなくても、従来通りやり続けてきた。

一方、優秀なチームでは、開発環境が導入されていないと、モチベーションを落とす。
むしろ、開発環境は導入されていて当たり前。
つまり、開発環境の導入は衛生要因であり、動機づけ要因にならない。

ハーズバーグの動機づけ・衛生理論 |モチベーション向上の法則

ハーズバーグの二要因理論 ? リーダーシップインサイト

【2-5】チームの成熟度が低く、Redmineを使いこなせないから

開発環境が既に用意されているとしても、上手く使いこなすか否かは、チームの成熟度に依存する。

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

Redmineインスタンスはチームの組織文化や慣習を表す: プログラマの思索

チームの成熟度に対するPMOの支援度合いは、リーダーシップの状況適合理論(SL理論)で説明できるのではないか。

2/4 リーダーシップは部下の成熟度で変化させる [リーダーシップ] All About

SL理論 ? リーダーシップインサイト

SL理論(状況対応型リーダーシップ) | マネジメントオンライン

たとえば、チームの成熟度が指示待ち人間のレベルである場合、Redmine導入と運用は、RedmineエバンジェリストやRedmine警察の役割の人達が、逐一メンバーにコマンドコントロールする必要がある。
つまり、PMOは指示型リーダーシップを発揮して、チームに相当介入せざるを得ない。

一方、チームの潜在能力は高く、Redmineのような新規ツールを欲しているならば、RedmineエバンジェリストやRedmine警察の役割の人達は、コーチングや運用支援のようなスタッフ的な立ち位置で支援すればいい。
つまり、PMOは、コーチングのような説得的リーダーシップ、参加的リーダーシップを発揮して、チームを支援すればいい。

最終的には、チームの成熟度が自律的になっていれば、PMOは委任的リーダーシップ、つまり、サーバントリーダーシップに似たリーダーシップを発揮して、チームにRedmine運用そのものを委任すればいい。

そうなると、各チームは自チームに特化したRedmineが欲しくなるので、チームごとに複数のRedmineインスタンスを提供する方式になるのではないか。
つまり、野良Redmineが普通の状況になるかもしれない。

個人的には、現代において、PMOが教示的リーダーシップ、指示的リーダーシップを発揮してチームをコマンドコントロールしなくてはならない状況は相当減っているはず、と思う。
ネット上に情報もたくさん流れているので時代の方向性は理解できるし、若い人ほど潜在能力が高いように感じるから。

【3】他にも色々考えてみる。

【追記】
akipiiさんのツイート: "個人的には、@MadoWindahead さんがPMOでチームに関わる立場はSL理論でどのポジションにいるのか、知りたいかな。指示的リーダーシップはさすがにないと思うし、委任型リーダーシップであれば、そもそもPMOがチームに関わらなくてもいいので、説得的または参加的リーダーシップかなと推測。… https://t.co/lg3gcKgLZ7"

門屋 浩文さんのツイート: "指示型は敢えてやらず 説得と参加、不安の軽減、やってみせて、効果を感じてもらうことかなあ サーバントリーダーシップはどこまでできてるかの評価は分かれるところかも… "

| | コメント (0)

2017/05/14

第12回東京Redmine勉強会の感想 #redmineT

第12回東京Redmine勉強会では、講演者、参加者、スタッフの皆さん、お疲れ様でした。
大雨の土曜日のために、突然キャンセル40人以上発生したにもかかわらず、参加率90%という驚異的な勉強会。
感想をラフなメモ書き。
間違っていたら後で直す。

【参考】
第12回勉強会 - redmine.tokyo

第12回東京Redmine勉強会 - Togetterまとめ

第12回東京Redmine勉強会の見所: プログラマの思索

akipiiさんのツイート: "#redmineT 東京Redmine 勉強会から離脱しました。今日は参加率90%で驚異的でした。ディスカッションでは土木建築、デザイナー、ゲーム、メーカーなど多様な業界でRedmine が使われてた。レベル別、セグメント別で議論して、Redmine の運用方法を洗い出してみたい"

【1】@g_maedaさんの発表は、3月のRedmine大阪の発表の改良版。
気になる点は、最後の「Redmine3.4.0になれなかったパッチたち」。

サイドバー折り畳みは、欲しい。
PCの画面が小さいと、フル画面でチケット一覧を見たくなる。
チケット一覧の表示項目が増えると、横スクロールが必要になって、うっとうしい。
また、スマホ、タブレットなど数多くの閲覧媒体が増えてきているので、レスポンシブ対応だけでなく幅広く対応してほしい。

コードハイライト言語を増やす機能追加も早くやってほしい。
特に、VB、C#のコードハイライトがない、という要望は従来からすごく多い。

バージョン内のチケットのD&D機能も早く追加してほしい。
アジャイル開発におけるプロダクトバックログの精査の作業に直結する作業だからだ。
つまり、チケットのリリースの優先順位づけを並び順で表現することは、リリース計画をプロダクトオーナーと開発者が共有しやすくなる点にも直結する。
アジャイル開発の観点では、チケット一覧画面よりも、ロードマップ画面の改良にもっと力を入れて欲しい。

【2】@Madowindaheadさんの講演では、チームの変化やチームの成長を活動画面から事前調査して、支援しているとのこと。
この部分はRedmineの優れた機能そのものだし、チームの成長がRedmineに記録されていく点はチームのモチベーションにもつながるだろう。

あさこさんのツイート: "「決定に関する内容も分かります」 活動内容をどういう粒度で記入するかをしっかり決められているいい事例ですね!! #redmineT"

akipiiさんのツイート: "#redmineT 成長していることを、変化していることで捉える。まさにRedmine の得意なところ"

また、PMxTMのポジショニングマップが重要だと思う。
縦軸=PM技術力、横軸=ツール利用度で、開発チームや開発メンバーをプロットして、どこのセグメントが問題なのか、あるべき姿へどうやってマネジメント力を向上させていくべきか、という観点で分析するのに使える。

特に、Redmineを導入したけど、社内でなかなか広まらない、という時に、どこのセグメントに問題があるのか、という分析のヒントになるだろうと思う。

スライドで面白い点は、社内でRedmine利用度を上げることでマネジメント力を向上させるパターンを経験上3種類あげている点だ。

一つ目は、PM力が大変低く、ツール利用経験も大変低い層。
このセグメントは、「目標になるメンバーと一緒に成長ラインに乗せる」。
つまり、新入社員のように、まだ技術もPMの経験が浅い人は、OJTのような仕組みが有効なのだろう。

二つ目は、PM力は中間くらいだが、ツール利用の経験が浅い層。
このセグメントは、「この位置のメンバーは成長ラインに乗せやすい」。

その理由は、既にマネジメントの経験があり、PMに必要なスキルや概念はある程度分かっている人たちなので、そのスキルを生かしやすい環境としてRedmineを提供すれば、自分たちで問題解決していけるようになるはず、ということだろうと思う。

三つ目は、PM力は高いが、ツール利用度が大変少ない層。
まさにExcelおじさん。
このセグメントは、「メンバーの成長を意識させることで、成長ラインに乗せる」。
この点は、なるほど、と思う。

このセグメントは、自分たちのやり方を持っている人が多いので、なかなか新しいツールを使ってくれない。
でも、自分の立ち位置やメンバーへの影響力は、自分でも分かっている人が多い。
すると、自分がRedmineを使わなくても、メンバーがRedmineを使って自然に成長していけば、自分もちょっとはやってみようか、という気になるのだろう。
つまり、いきなりツールを使いこなせ、とトップダウンでやるのではなく、ボトムアップで攻めていくわけだ。

このパターン集で面白いのは、4象限のうちの右下の部分「ツール利用は多いがPM経験が少ない」セグメントのパターンがないこと。

講演でちょっと触れていたが、このセグメントはヒントを与えたり、支援すれば、自力で解決していってくれる。
個人的には「プログラマ上がりのプロジェクトリーダー」が多いのではないか、と想像する。
そういう人たちには、得意とする技術力をベースとして、Redmineでマネジメント経験を増やしていけば、自然に力が付くのではないか、と想像する。
僕自身もそういう経験があった。

【3】@ktohさんのRedmine全文検索プラグインの話も興味深かった。

たとえば、チケットが数十万枚、数百万枚に増えた場合、それらチケットやWikiなどの情報を、欲しい時に即座に検索できる機能は、Redmineをナレッジシステムとして使うために重要な機能と考える。
Ver3.3では、右上の検索ボックスは表示中のPJだけにデフォルトで絞り込み検索するので早くなっているが、全PJ横断の検索はまだ遅い。
そのような問題を解決するプラグインなので、Redmineをナレッジシステムとして価値を向上させるために有用な機能だと思う。

Redmineの検索機能の改善はチケット管理システムにとって重要な要件だ: プログラマの思索

Redmineの全文検索を高速化するプラグインfull_text_searchのリンク: プログラマの思索

全文検索プラグインで興味を惹く点はいくつかある。

一つは、検索ノイズがなく、ランク別・更新時刻順に表示される点。
Groongaという拡張DBエンジンを使うので、スコアを調整して、有用な検索結果を上位N件に表示してくれる。
注目すべき点は、デフォルトの全文検索結果と全文検索プラグインの検索結果は、件数は同じでもソート順が違う点。
つまり、Google検索みたいに、役立ちそうな情報が上位に表示されるので便利。

また、Google検索のように、AND・OR・NOT検索ができるのも便利。
たとえば、「(Groonga OR Mroonga) -PostgresSQL」みたいに、GroongaまたはMroongaを含むがPostgresSQLを含まないように検索できるらしい。
この機能が検索で使えるならば、過去の障害や仕様変更の履歴を探したい時に、より詳しい検索条件で書けば、より早く到達できるようになるだろう。

さらに、更新時刻順にソートできるのもうれしい機能だ。
検索したい状況をふりかえると、直近で自分や他の担当者が書いた内容を検索したい時が多いからだ。
直近の障害情報、直近の課題やQAを見つけたい時が多いから。

二つ目は、高速である点。
この内容は、既に@akahane92さんがツイートされている。

Kuniharu AKAHANEさんのツイート: "200万チケット@MySQLでやってみたよ。検索時間は約380ms。 #Redmine の未来が広がって嬉しいな。ありがたいな。/Redmineで高速に全文検索する方法 - ククログ(2016-04-11) https://t.co/s7FA4gSThu @_clear_code"

neta@世界は私のオイスターさんのツイート: "@akahane92 さん! 今クリアコードの人が 赤羽根さんの全文検索380ms のツイート紹介してました。プラグイン適用前の処理時間を知りたいらしいですよ! #redmineT"

Kuniharu AKAHANEさんのツイート: "@netazone (ご参考まで) Redmineチューニングの実際と限界 / https://t.co/fRU2MvH4my の114ページです。"

三つ目は、まだ未実装だが、類似チケットの検索。
これは、Amazonのお勧め商品表示と同じく、協調フィルタリングとか機械学習みたいな機能を使って、この障害チケットに似た過去のチケットはこれこれです、みたいに表示する。
たとえば、障害チケット起票時に、過去の類似バグを表示してくれると嬉しいだろう。

四つ目は、まだ未実装だが、検索ボックスやチケットのタイトル欄などで、入力補完する機能強化。
これは、PJプルダウンのインクリメントサーチのように、検索ボックスで1文字入れたらGoogle検索みたいにコードアシストしてくれる機能みたいなイメージ。
この機能があれば、チケット内容の入力間違いを減らせるし、途中までの文字入力で自動補完してくれるので、チケット入力コストをかなり減らせるはず。

つまり、ただでさえチケット入力は鬱陶しい、と言われがちな弱点に対し、検索エンジンの強化によって入力補完をサポートすることで、チケット入力者の作業コストを減らし、チケットの内容の精度向上に役立てることができるわけだ。

この辺りの機能を欲しいと思う日本人ユーザ、Redmine利用企業は意外に多いのではないだろうか。
なぜなら、Redmineを利用している現場は増えているし、すでに数年以上運用してかなりの枚数のチケットを蓄積している日本企業も多いと思うからだ。
@ktohさんが支援を要請しているので、興味のある人は声掛けしてはどうだろうか。

すさんのツイート: "第12回https://t.co/YxfaKONoze勉強会の「GroongaでRedmineを高速全文検索」の資料です!今後の野望を一緒に実現したい人はぜひ連絡をください! https://t.co/FEBfQvAVk4 #redmineT"

今後の野望については、下記の記事でアップされている。

redmine.tokyo第12回勉強会:GroongaでRedmineを高速全文検索 #redmineT - ククログ(2017-05-15)

なお、AWSへのセットアップでは、下記のツイートがあるので注意。

Kawabata Mitsuyoshiさんのツイート: "AWSだとmroonga入れられないという質問があったが、最近だとRDSから、MySQL on EC2にmaster-slaveでレプリケーションして、MySQL on EC2側で検索処理するが定石っぽい #redmineT https://t.co/SwD3IFyeVt"

MAEDA, Goさんのツイート: "Redmine本体は現状PostgreSQL推奨です。MySQL 5.6以降だとデッドロックが発生するケースがあります。 #redmineT https://t.co/zRSmVfGY8T https://t.co/y9KtUtJ8SG https://t.co/AS0A6KDeaZ"

【4】宮本さんの「チケット駆動開発基盤とプロダクトライン型開発の融合手法の検討と評価実験」も興味深かった。

ストーリーとしては、既にRedmine+GitLab+Jenkins+Maven+Artifactoryという開発環境がそろっていて、その上にプロダクトラインのプロセスを実装しようとするお話だった。
お話としては大変興味深いのだが、肝心のRedmineの機能にどのようにマッピングさせたのか、という点はぼかされていて、分からないところが残念笑。

但し、講演中の一言「Redmine が要件、タスクなどエントリーポイント。MavenやArtifactoryがプロダクトラインでは肝となる所」という話から想像すると、こんな感じかな。

akipiiさんのツイート: "#redmineT Redmine が要件、タスクなどエントリーポイント。MavenやArtifactoryがプロダクトラインでは肝となる所。プロダクトそのものの構成管理がやりたいからだろう"

Redmineには、要件や仕様、それに基づくタスク・課題・障害の情報は一元管理されていて、そのチケットから作業は駆動される。
そして、ソースや設計書などの成果物はGitLabで構成管理されていて、複数の製品ファミリーはGitのブランチで管理されている。

その時、それぞれの製品ファミリーのリリースされたソフトウェア製品は、バージョンでタグ付けされて、それらはArtifactoryでビルドモジュール単位のバージョン管理がなされている。
つまり、各製品は、共通ライブラリやコア基盤となるようなビルドモジュール(たぶんJarやWar)とアプリケーション資産(これもJarやWar)がパッケージングされていて、各製品がリリースされたタイミングで、共通ライブラリのどのバージョンに依存しているか、はMaven+Artifactoryで構成管理されているのだろう。

つまり、ソフトウェア製品とソフトウェアモジュール(汎用ライブラリ)は、ビルドモジュール単位で構成管理されていて、その構成管理が重要、ということなのではないだろうか。
この考え方はちょうど、業務システムがOracleやApache、.NET Frameworkの特定のバージョンに依存して作られていて、それらも含めて構成管理されている、みたいな考え方と同じではないだろうか。

すると、Redmineにある発端となった要件や仕様から、それに紐づくソース、そこからビルドされてリリースされたソフトウェア製品へトレースできる(後方への追跡性)し、逆に、あるバージョンのソフトウェア製品から要件までトレースできる(前方への追跡性)。

そのような開発プロセスを作りたい、という動機も別途あるのだろうと推測する。
そして、その仕組みは、Redmineのチケット管理や構成管理ツール連携という機能を使えば、チケット駆動のトレーサビリティ機能が導出されて実現できる、みたいなストーリーではないだろうか。

チケット駆動開発を要求工学の品質特性の観点から考える~チケット駆動開発がAgile開発を必要とする理由: プログラマの思索

【5】講演資料はコチラ。

| | コメント (3)

2017/02/27

Redmineの親子チケットの功罪

RedmineのFAQとアンチパターンを整理していると、最近は、親子チケットに絡む内容が多いような気がした。
Redmineは先進的なプロジェクト管理を行う実験場であり、まだまだ改善の余地はたくさんあると思う。
考えたことをラフなメモ書き。

【1】最近、ソフトウェア開発者以外の人達から、Redmineを業務に使えないか、質問を受ける場合が多い。
彼らの目的は、タスク管理や、昔のNotesの代わりの事務処理ワークフローに使いたいみたいだ。
Excel帳票やExcel管理台帳が溢れていて、それを何とかしたい、という動機みたい。

そういう場面に、Redmineは導入しやすいし、運用して効果も期待できる。
OSSで無料だし、小さく運用を始めて様子見した後、大人数へ横展開することもできる。

特に、大規模に使っていく場合、Redmineのメリットがとても良く出てくる。
つまり、Redmineのメリットである「親子プロジェクトの階層は無限」「親子チケットの階層は無限」を上手く適用できれば、多数の組織も管理できるし、多数の作業もまとめて管理できる。

換言すれば、Redmineの「プロジェクトやチケットの階層が無限に作れる」特徴は、とても柔軟な機能なので、いろんな業務に適用しやすい。
だから、色んな人達が色んな業務にRedmineを適用しようと試している。

しかし、話を聞くと、業務がRedmineに完全にフィットしない場面もあるらしい。
どうやら、特に親子チケットの作り方に問題があるような気がしている。

【2】では、Redmineを実際に運用した場面で、親子チケットを使った時にどんな問題が噴出しているのか?
色々集めてみた。

【2-1】親子チケットにし過ぎる

個人のToDoを子チケットで登録して、親チケットにぶら下げる人がいる。
他の人には不要なチケットだ。
チケットが乱発されて、登録した本人ですら、チケットの棚卸しができなくなる。

根本問題は、チケットの粒度があまりにも細かすぎる点だと思う。
解決策としては、他人と共有すべき作業内容に限定する運用ルールを作る。

僕が最も推奨するのは、TODOレベルは、チケットにチェックリストを追記する運用に変更することだ。
なぜなら、個人のToDOレベルのタスクが全て終わったことが、その人のチケットの完了条件とみなせば、他人と進捗状況を共有しやすくなるからだ。
つまり、個人のToDOはチェックリストにすべきだ。

たとえば、Checklistsプラグインを入れてもいいかもしれない。

Checklists - Plugins - Redmine

但し、チェックリストを作ったとしても、チケットに未チェックが残っても、チケットが完了できてしまうリスクもある。
その場合は、下記のように、完了できなくなるパッチを当てればいい。

Redmine Checklists pluginで未チェックの検証を雑に行う - Qiita

あるいは、プライベートチケットを使う方法もあるだろう。
プライベート機能を使えば、他人には見えないから、ToDOチケットは邪魔にならない。
しかし、共有すべきチケットが存在すれば、埋もれてしまうリスクもある。

【2-2】親子チケットで、開始日・期日・予定工数のロールアップを止めたい

よくある例は、WF型開発の案件で、親チケットにSEが開始予定日・終了予定日・予定工数を入力した後、子チケットにPGが実績の開始日・終了日・自分で見積もった予定工数を入力すると、親チケットの開始日・期日・予定工数が消えてしまう問題だ。

Redmineの本来の仕様は、「WBS 100%ルール」であり、WBSに漏れがあってはいけないから、親チケットは子チケットの情報をロールアップする。
しかし、WBS 100%ルールは、実運用に合わないケースが多い。
結局、WF型開発も綺麗に運用できるわけではない。

SQIP2015の講演後の質問でも、この質問が最も多かった。

【公開】SQIP2015講演資料「チケット駆動開発の運用パターン集~問題はチケットに分割して統治せよ」 #Redmine: プログラマの思索

実は、対処としては、RedmineのVer3から、Redmineの設定画面で「子チケットから独立」を選択することで解決できる。
また、親チケットの予定工数と、子チケットの予定工数の合計は別カラムとして表示されるので、問題なくなった。

しかし、この運用が本当に良いかどうかは分からない。
WBS 100%ルールを止めるということは、WBS作成の基本ルールを破棄していることだから。

【2-3】未完了のチケットが残っているのに、親チケットが完了できてしまう

これは、WBS 100%ルールではありえない問題だが、Redmineの機能には実装されていない。
実は、RedmineのVer3.4で対応済みだ。

2016年11月のRedmine開発状況 | Redmine.JP Blog(Feature #10989: 未完了の子チケットを持つ親チケットのクローズを禁止)

Redmineの次期バージョン3.4の見所: プログラマの思索

Feature #10989: Prevent parent issue from being closed if a child issue is open - Redmine

「Feature #10989: 未完了の子チケットを持つ親チケットのクローズを禁止」のパッチによって、WBS 100%ルールが実現できるおかげで、親チケットのステータスを明確に判別できる。

【2-4】親子チケットでどこまで深く階層化するか?

Redmineの実運用では、ExcelのWBSのように5~10階層までブレイクダウンしたい目的が多い。
つまり、ExcelやMSProjectみたいに、WBSの深い階層をRedmineチケットで表現したい。

しかし、WBS 100%ルールを厳格に運用するとデメリットが大きくなると感じている。

普通、タスクは階層化しやすい。
しかし、障害やQAは階層化に合わない。

そして、深い階層のチケットは、チケット一覧画面では見通しが悪い。
むしろ、ガントチャートが向く。
ガントチャートならば、階層構造が綺麗に表現されるからだ。
だが、Redmineのガントチャートで編集できない弱点がある。

また、深い階層のチケットのデメリットはいくつかある。
一つは、 性能が悪くなること。
浅い階層では問題ないが、かなり深い階層とか、数千件の子チケットを持つチケットの操作のパフォーマンスが悪くなるらしい。
そのパフォーマンス改善のパッチがRedmine本家に提供されたが、Ver3.4ではリジェクトされている。

2016年12月のRedmine開発状況 | Redmine.JP Blog (Defect #23318: 大量の子チケットを持つチケットで #lock_nested_set メソッドが遅い問題の改善)

実際、Redmineの実ソースでは、子チケットを表示する時に、select ~ for updateを使っているみたいだ。
つまり、ロックを故意にかけているので、性能が悪くなる可能性はある。

もう一つは、親子チケットを一括登録しようとすると一手間かかることだ。
実際、親チケットを採番しないと子チケットを一括インポートできない。
なぜなら、親チケットNoを採番しなければ、子チケットの親チケットNoを指定できないからだ。
すると、階層の数だけ、一括登録のインポート処理を繰り返し、その都度、親チケットNoを取得してはセットする手間が必要。
手作業で親子チケットは簡単に作れるが、MSProjectで作った5階層のWBSを一括インポートしたい需要はあるだろう。
どこかのツールで手軽に実行できないかな?

さらに、深い階層の親子チケットは、チケット保守が大変になる。
親子構造を変えにくかったりする。

また、バージョンが古いRedmineでは、WBS 100%ルールが実運用に合わないことは前に触れた。

そして、深い階層の親子チケットでは、WBS漏れを検知できるか?
要件チケットから成果物までのトレーサビリティをRedmineは実現できるのが、もう一つのRedmineのメリットだが、階層の深いチケットを作ると、WBSがどこかで漏れていたとしても、Redmine上ではすぐには分からない。
結局、CSV出力して、Excel上でWBS漏れを探した方が早いだろう。

あるいは、Lychee LACという有償プラグインを使って、Redmineの階層構造とトレーサビリティをツリー構造で図で表示する方法があるかもしれない。

プロセスフロー図をRedmineチケットで表現するアイデア~Lychee Association Chartで実現できるか: プログラマの思索

Redmine Lychee Enterpriseシリーズの解剖part3~Redmineのチケット関連図 Lychee Association ChartとRedmineの予実管理をサポートする Lychee Actual Date: プログラマの思索

【2-5】チケットの棚卸しがやりにくい

親子チケットにすると、チケットの棚卸しがやりにくそうに感じる。
最下層の子チケットを棚卸ししなければ意味がないが、どうしてもチケットが多すぎるからだ。
駄目なプロマネはRedmineのチケット一覧で頑張ろうとして、溢れたチケットに溺れてしまう。

チケット一覧で棚卸ししようとして詰まるみたい。
すると「放置されたチケット」「停滞したチケット」「乱発されたチケット」のようなアンチパターンが生まれてしまう。

個人的には、親子チケットを使わすぎず、ロードマップを使う方が良いと思う。
つまり、バージョン=納品日、締切日として運用して、ロードマップ画面でチケットを取捨選択する運用に切り替えるわけだ。
僕がRedmineを運用して、これがアジャイル開発の本来のマネジメントなのだ、と気づいた機能の一つ。

チケット駆動開発の戦略: プログラマの思索

Redmineのロードマップ画面では、右クリックでチケット編集コンテキストメニューを出せるので、ロードマップ画面上で優先度を考えながら、チケットの属性を編集できる。

しかし、Redmineのロードマップ画面も機能不足と感じる。
ロードマップ画面で、チケットの優先順位を付ける機能がないからだ。

現状では、下記の3つしかやり方がない。
しかし、チケット枚数が増えるとロードマップ画面でも厳しくなる。

1・チケットの優先度を設定する
→なる早が増える

2・先行・後続の関連を付ける
→チケット操作が複雑。ガントチャート画面で編集できない。

3・バージョンを設定する
→チケット枚数が増えるとチケットが溢れる。本来は、チケットの並び順で優先度を付けたい。

本来は、ロードマップ画面で、チケットをD&Dして並び替えて、チケットの並び順で優先度を付けたいのだ。
このパッチは、実はRedmine本家で既に提供されている。

Feature #22802: Add the posibility to set/change the position of an issue in a version - Redmine

2016年9月のRedmine開発状況 | Redmine.JP Blog(Feature #22802: バージョン内のチケットをドラッグ&ドロップで並べ替え)

ここで、Scrumのプロダクトバックログでは、タスクカードの並び順が作業順序である。
つまり、開発者は、バックログの一番上からタスクカードを取り出して、作業をこなしていけばいい。
開発者は優先順位について考える必要はない。

一方、プロジェクトオーナーやプロダクトオーナーは、プロダクトバックログを常に精査して、どのフィーチャの実現を優先すべきか、取捨選択して、並び順を優先順位として考えればいい。

つまり、Redmineのロードマップ画面はもっと改良できる余地がある。
Feature #22802: Add the posibility to set/change the position of an issue in a version - Redmineでは、ロードマップ画面の並び順だけでなく、チケット一覧画面の並び順も考慮すべきでは?という議論があるが、それはナンセンスだ。

チケット一覧画面は、クエリによってある特定の検索条件でチケットのリストを抽出だけの機能だ。
しかも、ソート順も検索条件の一つになっている。
そもそも、D&Dでチケットの並び順を変更する必要もない。

一方、ロードマップ画面はリリース計画で使うべき機能だ。
この画面こそが、チケットの取捨選択を行うべきRedmineの中核機能だ。
だからこそ、Redmineにもっとアジャイル開発の特徴を取り込みたいのだ。

個人的には、Feature #22802: Add the posibility to set/change the position of an issue in a version - Redmineに数多くの人が「+1」のコメントを付けて、Redmineの機能の一つとして実現して欲しいと思う。

【3】こう考えてみると、Redmineは先進的なプロジェクト管理を行う実験場であり、機能面でも運用面でもまだまだ改善の余地はたくさんあると思う。
チケット管理には、プロジェクト管理を効率化させる可能性がまだまだ秘められていると思う。

【追記】
皆さんのツイートがとても興味深いので、メモしておく。
もっと、皆さんの経験に基づいた奥深い議論がしたい。

門屋 浩文さんのツイート: "@akipii WBS関連で親子関係についてはいつも議論になりますがプロジェクトのベースを合わせることを意識した説明、意識づけをしてます ロードマップは合わないかなと思い説明はしてません"

akipiiさんのツイート: "@MadoWindahead 個人的には、ロードマップ画面こそがRedmineの中核機能と思います。でも機能が足りない。チケット一覧画面で皆頑張ろうとしすぎ。親子チケット、親子PJの運用方法はまだまだ改善の余地がある。"

ニートン 岩崎さんのツイート: "親子チケットは罪しかないので、親子チケット作らないようにして、それに該当するのはカテゴリやマイルストーンで代用してる https://t.co/vx7eXRiBPZ"

akipiiさんのツイート: "@neeton_iwasaki Redmineの親子チケットや親子PJは、メーカーのような機能別組織にとてもマッチしてます。親チケットは設計部門が作り、製造部門が子チケットにタスクをぶら下げて、進捗管理するとか。多分、日本のSIやメーカーは親子チケットが好きなのでしょう笑"

| | コメント (0)

2016/09/23

ソフトウェア開発でバグ管理はなぜ必要なのか

「品質・バグ管理はなぜ必要なのか」という質問があって、回答が面白かったのでメモ。
以下は、深く考えずにラフなメモ書き。

【参考】
Redmine - 品質・バグ管理の必要性についてご意見をお聞かせください。(10612)|teratail

BTSを制する者がソフトウェア開発を制する: プログラマの思索

akipiiさんのツイート: "数人の回答が面白い。僕なら「BTSを制する者がソフトウェア開発を制する」という言葉で回答するかな。「品質・バグ管理の必要性についてご意見をお聞かせください。故障票などに記載(Redmine的なものです)」 https://t.co/L5LKK7hDEd #teratail"

【1】(引用開始)
タイトル通りですが、品質管理・バグ管理の必要性について質問させてください。
個人的には、「100%必要ない!」とは思っていませんが、厳重に管理したバグ票やらを必死に分析して最終的に何に使うのでしょうか?
(中略)

例えば、「あるexceptionによるシステムエラー」が起きたとしたら
1.なぜバグが起きたのか?
→exceptionをキャッチしていない
2.なぜcatch文をいれていないのか?
→設計書から見落とした
3.なぜ見落としたのか?
→凡ミス
4.なぜ凡ミスが起きたか?
→疲れていた、作業効率の低下、特に理由なし

ここで最後の回答をしたところで、管理者は「なるほど、気をつけて」としか言いようが無いし、作業者としても「疲れていた」とは言いにくいものもあります。
バグの内容にもよりますが、明らかに大したバグではない、凡ミスのようなものに追及していく必要はあるのでしょうか?
それより、さっさと改修しても良い気もします。
一つの現場だけでなく、だいたいどの現場も同じ漢字なので不思議です。
(引用終了)

ソフトウェア開発でバグ管理が重要な理由は、障害管理のプロセスがソフトウェア開発の全てのプロセスの根幹をなすからだ。
つまり、BTSを使いこなす者はソフトウェア開発を制する。
以前、Blogにその考えは書いた。

BTSを制する者がソフトウェア開発を制する: プログラマの思索

Bugzilla、MantisからTrac、Redmine、Jiraに至るまでのBTSには、世界中のソフトウェア開発者のベストプラクティスが埋め込まれている。
だから、できるだけ最新のBTSに慣れた方がソフトウェア開発のスキルも向上できるはず。

【2】なお、製造業の品質管理とソフトウェアの品質管理は別物とみなした方がいいと最近は思っている。
製造業の立場から見れば、ソフトウェアの品質管理は、正直笑ってしまうぐらいの低レベルと思えてしまうだろう。

製造業の品質管理が知りたいなら、たぶん、QC検定2級レベルの知識を一度見てみればいいと思う。
彼らは、大量生産される工業製品の品質管理を統計学的手法で、細かな部分までコントロールしようとしている。
統計学における仮説検定、相関・回帰分析などが必要とされるので、相当にレベルは高い。

QC検定とは? | 一般財団法人 日本規格協会

QC検定2級って奴 受けてみた - Pass Hunter

製造業の品質管理は、管理図を使って、製品の規格のばらつきを抑えるように、工程や作業を改善するのが王道だと思う。
たとえば、ネジを作っていて、そのネジの大きさや長さにバラつきがあれば、どの作業工程でそのバラつきが発生したのか、どの人が担当するとばらつきが大きいのか、などを細かく突き止め、原因を把握して、作業方法を改善していく。

一方、ソフトウェアの品質管理は、製造業の品質管理を真似ようとして色々試されているが、そのレベルまで到達しているようには思えない。

とは言え、ソフトウェア工学では経験則としていくつか知られている知見はある。
たとえば、人月の法則とかコンウェイの法則、リーマンの法則とか。

リーマンの法則~ソフトウェアもエントロピー増大の法則を避けられない: プログラマの思索

【3】製造業とソフトウェアの品質管理が全く違うように思える理由は、生産プロセスが全く違う観点で存在するからではないかと思う。
製造業は徹頭徹尾、WF型開発のように、生産計画重視で大量生産が王道。

大量に仕入れして原材料費を安く交渉し、大量に販売して売上を大きく稼ぐ。
大量生産するには、見込生産が必要で、そのためには、どの程度の需要があるか、計画段階で決めなければならない。
さらに、大量生産するための土地や工場、機械が必要なので、膨大な額の設備投資という資金も必要。
半導体産業が典型例だろう。

akipiiさんのツイート: "アジャイル開発はソフトウェア開発特有の考え方。製造業とは全く違う。 @koshian: アジャイルもスクラムも日本の製造業から来たものなのになぜ日本始めアジアで普及しないと言われてしまうのか。アジャイルはなぜアジアで普及しないか” https://t.co/2UtpidH2zo"

akipiiさんのツイート: "アジャイル開発が日本で普及しない原因の一つは、予算取りや設備投資の発想にあると思う。製造業は、工場への設備投資で、規模の生産性を生かして、大量に安く作り、市場を独占して先行者利益を得たい。政府も、設備投資は不景気のカンフル剤として有効だから、金利を下げて煽る。"

一方、ソフトウェア開発は、大量生産と言うよりも、個別受注生産して、その製品を長く保守することで売上を確保する。
つまり、ソフトウェア開発プロセスは、ビジネス上も保守プロセスの方が重要なのだ。

そのためには、BTSのように、ソフトウェア保守のために特化したツールが必要で、そんなツールがなければ効率化できない。
ソフトウェアの品質管理が低レベルと言っても、BTSチケットに本番障害を記録していけば、何らかのルールは見出だせる。
また、障害修正のワークフローは、仕様変更や派生開発、新規開発にも拡張できるので、BTSをしっかり運用できる開発チームは、他のプロセスにもすぐに馴染むと思う。
その考えの中に「チケット駆動開発」というアイデアも含まれる。

【4】個人的には、製造業で言われる5S活動(整理・整頓・清掃・清潔・躾)とか、3S(単純化、標準化、 専門化)という概念や活動は、ソフトウェア開発には適さないと思う。

たとえば、製造業の人は「標準化」という言葉が大好きで、確かに、生産プロセスでは標準化活動がすごく効果を持つ。
しかし、ソフトウェア開発に「標準化」という概念を適用しようとすると、すぐに標準化されたプロセスや技術は陳腐化してしまう。
プログラマの創造性を逆に阻害する遠因になりやすい。

製造業の生産管理による標準化手法はソフトウェア開発に適用できない: プログラマの思索

そもそも、メーカーと無関係のソフトウェア企業で、5S活動を社内で推進している所はあるのだろうか?
5Sの順番にも意味がある、とか、3Sの順番にも意味がある、とか、そういうことまで理解して活動しているのだろうか?
少なくとも、日本の製造業の人たちは理解しており、そこまで細かく管理しているが、ソフトウェア企業はそこまでやっているのか?
たぶんやっていないし、創造性が重視される場のソフトウェア開発ではたぶん必要ではないかもしれない。

| | コメント (0)

2016/09/15

OSSのMSProjectクローンProjectLibreの使い方

OSSのMSProjectクローンProjectLibreの使い方に関するWebページを見つけたのでメモ。

【参考1】
ProjectLibreのインストールと使い方、基礎、入門 - SEO対策 大阪

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

づめメモ Projectlibreで日付の書式を変える方法

MS Projectの基準計画の使い道: プログラマの思索

ProjectLibreを使ってみたら、MSProjectとほぼおなじアプリと考えていい感じだ。
実際、ProjectLibreでガントチャートをXML出力すれば、MSProjectで読み込んで開ける。
つまり、プロジェクトリーダーはMSProject、MSProjectのライセンスを持たないユーザはProjectLibreで使い分ける、という運用は可能だ。

僕が使う操作はこんな感じ。

ExcelでWBS、予定工数、担当者を作る

ProjectLibreにプロジェクトを新規作成

ProjectLibreのガントチャート画面でWBS、予定工数、担当者をコピペする

ProjectLibreのリソース画面で担当者全員もコピペする

ProjectLibre上で、WBSを階層化する。

ProjectLibre上で、WBSの先行後続関係をマウス操作で付けて、綺麗にして入力完了

MSProjectの最大の利点は、WBSの先行後続関係がマウス操作だけで簡単にできることだろう。
ProjectLibreも同様に、WBSで先行後続関係を結ぶには、先行タスクをドラッグして、矢印線を後続タスクへロドップすればいい。
そうすると、鎖アイコンが表示されて、先行後続関係のリンクが貼られる。

ProjectLibreのガントチャート画面で作業負荷の山崩しをやりたいならば、ビュー>ヒストグラムを画面下部に表示させて、100%以上の負荷のタスクをずらすか、担当を変更すればいい。
この辺りもMSProjectと似たような操作感で簡単にできる。

他に、タスク>更新で実績入力できるし、タスク>ベースライン保存で、基準計画を保存できる。
基準計画の個数も11個あり、MSProjectと全く同じなのが何となく笑える。

MSProjectに慣れたマネージャなら、ProjectLibreは全く問題ないと思う。
但し、無料版ではイナズマ線やクリティカルパスは表示されないので注意。

個人的には、MSProjectにある機能は全てRedmineのガントチャート機能で実現して欲しいと思う。
そうすれば、Redmine上でプロジェクト計画も実績管理も全て一元管理できる。

最近はRedmineのガントチャートを機能拡張した有償プラグインが続々出ているので、取り入れてみたらいいと思う。
たぶんMSProjectのライセンスよりも安いだろうと推測する。

【参考2】
MS Projectを使いこなせない理由: プログラマの思索

RedmineのガントチャートはMS ProjectのWeb版になりうるか?: プログラマの思索

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

Redmineのもう一つのガントチャートプラグインEasyGanttのリンク: プログラマの思索

もう一つのRedmine製パッケージ製品ANKO REDMINE: プログラマの思索

| | コメント (0)

2016/08/17

MS Projectの基準計画の使い道

MS Projectの基準計画の機能についてメモ。

【参考】
MS Project を使おう!さんのツイート: "MS Projectを使うに当たって、「基準計画」を使いこなすことは非常に重要です。これがあって初めてアーンドバリューなどの進捗管理方法で予定と実績の比較が可能になります。 #MSProject"

STEP 5-1: プロジェクト計画の確定-基準計画の保存 | Quantum Harmony Corp.

プロジェクトが計画通りに進んでいるかどうか「基準計画の保存」で比較検証を行う(Microsoft Project) | 雑記 BOOOKs

MS-Project の使い方 | ins13の日記 | スラド

プロジェクトリーダーならば、普通はMSProjectが必需品だろう。
MSProjectは、計画を立てるのがやりやすい。
WBSをExcelでざっくり作り、MSProjectに貼り付けて、先行後続関係をつければ、とりあえずラフなスケジュールを立てることができる。
その後、担当者にタスクを割り振り、実績管理していく。

その時、基準計画時という機能で、プロジェクト計画時点やリスケ前に、計画情報一式を保存すると良い。
基準計画はベースラインと同義。

その時点の計画をベースラインとして保存し、予実管理だけでなく、当初の計画と現在の計画がどれくらい変化したか、比較評価する時に使う。

プロジェクト立上げ時では、開発者を確保できず、担当者未定だったりするが、テスト工程の1ヶ月以上前になれば、担当者を誰にするか決まってくる。
あるいは、顧客の仕様変更でリスケが発生し、予定工数も増えた場合も考えられる。

もちろん、当初の進捗よりも遅れてしまい、リカバリーせざるを得なくなる場合もある。

そんな時に、基準計画というベースラインを定期的に保存して、計画情報を比較評価できるようにしておけば、現実的なスケジュールを作りやすくなるだろう。

但し、MSProjectの古いバージョンでは、基準計画は11個しか保存できない、という制約があるので注意が必要かな。
Redmineにもそんな機能があるといいなと思ったが、何と、LycheeGanttChartにはそんな機能があると言う。

MSProjectに慣れたプロマネなら、Redmineに有償のプラグインを導入して、ガントチャートをMSProjectのように修正できると便利かもしれない。

【追記】
Kさんのツイート: "@akipii Redmine Easy GanttプラグインのPRO版=有償版にもベースライン機能があるので参考までに。 ▼URL https://t.co/itdMAcXNrH ▼動画(44秒〜) https://t.co/VipO4SqNyk"

| | コメント (0)

2016/07/23

Redmineがいくら良くても会社の上司や経営者が見なければExcelがはびこってしまう事例

Redmineのようなチケット管理ツールがとても威力があっても、上司や経営者が見なければExcelがはびこってしまう事例を見かけたのでメモ。
チケット管理ツールに限らず、営業支援システム、日報システム、経営状況の見える化の為の情報系システムでも同様の症状がよく発生する。

【参考】
golangでRedmineの情報をExcelにするコマンドラインクライアントを作った - write ahead log

Big Sky :: コマンドラインからredmineを扱える「godmine」作った。

【1】(引用開始)
SIerに所属している方ならわかると思いますが(あんまりわかって欲しくもないですが),体質の古い会社だとRedmineを使っていても「Excel表がない」と文句を言われたりします.

面倒なのが「プロジェクト一覧表がない」とか「課題管理表がない」とか「バグ一覧表がない」とか....etcです.

実装担当者はRedmineを使う運用で問題なかったりするのですが,役職持ちの方から「Redmineはわからないから」とか「移動中にExcelで見たいから」などと言われると断れないのがサラリーマンの辛いところです.

あとは受託だとユーザとか元請にRedmineを強要できないので結局Excelになったりします.(しません?)
(引用終了)

【2】Redmineのようなチケット管理ツールを、開発チームがボトムアップで使っているのではなく、上司や経営者が上から目線で導入させたとしよう。
すると、Redmineは確かに現場に導入されるが、現場ではRedmineが必要で導入したわけではないから、なかなか根付かない。

一方、Redmineが普及して、会社の上司や経営者もPJ状況を見て欲しい、と思ったとしよう。
しかし、部課長や社長クラスの人は、管理作業や営業などで忙しすぎるので、Redmineをわざわざ触って、見る暇もない。
むしろ、メールで報告させたり、Excelを送ってもらって、印刷したプリントで見た方が楽だったりする。

すると、上司や経営者から、Redmineを見るのは面倒なので、メールで報告してくれ、とか、ExcelでPJ状況を出してくれ、と言われたりする。
そのための進捗報告書を作成するのに、プロジェクトリーダーは無駄な工数がかかったりする。
せっかくのRedmineが、上司や経営者の目には届かないのだ。

【3】その状況は、営業支援システムの事例でも聞いたことがある。

営業マンが顧客にアポを取ったり、契約状況を記録するために、営業支援システムを作り、営業担当者に日報を書かせて、上長がその日報を読んで管理できるような素敵なシステムを開発した。

しかし、営業部の課長クラスは、自身も営業しているし、打合せも多いので、営業支援システムにわざわざログインして、大人数の営業担当者の日報を毎日読む暇もない。
すると、営業担当者にとっては、日報入力という無駄な作業が増えているのに、その日報を上司が少しも読まないし、反応もない、と分かると、誰も営業支援システムを使わなくなった、と。

結局、メールやExcelベースの情報連携に戻ってしまった、という事例。

他にも、ERPに蓄積された財務情報やPJ情報を経営者向けに見える化したい、という情報系システムを多額の資金を投資しして開発したものの、経営者はそんなにシステムに明るくないし、システムの操作も最初から覚えるのは面倒なので、結局使われない。
すると、大金をはたいた、経営情報の見える化システムも使われなくなってしまう、という話もよく聞く。

【4】結局、会社の上司や経営者が、情報系システムを使いこなさなければ、現場に定着しない、という身も蓋もない話。
経営者向けの情報系システムは、大金をはたいた割りには、使用頻度が低く、誰も使わないシステムになりやすい。

いくらBIツールでビジュアルに見える化したとしても、彼らはそもそも情報系システムを使いこなそうという動機はさらさらないのだ。
個人的には、古い頭の日本の大企業に多い症状のような気がする。

そんなことをふりかえると、「見える化」という言葉は経営者は大好きだが、実際に使いこなせていない場合がすごく多い。
むしろ、現場主導で、自分たちの現場がやりやすいように、使いこなした方が賢明だ。
無駄なメトリクスの抽出、見える化プログラムの実装は、不要だと思う。

【追記】
言いたかったのは下記のコメントの通りかな。

はてなブックマーク - 岡崎良徳 のブックマーク - 2016年7月23日
(引用開始)
見ないものを見える化するのは無駄だよね、というお話。
(引用終了)

【追記2】
アカベコマイリさんが詳しい運用ルールを説明されている。参考になる。

Redmine 運用について 1/3 – はじめに – アカベコマイリ

| | コメント (0)

2016/06/19

大規模組織におけるRedmineを巡る諸問題~組織構造がRedmineに与える影響

大規模組織におけるRedmineを巡る諸問題について、色々考えている。
以下、ラフなメモ書き。
特に主張なし。

【1】最近は、Redmineに組織構造がどのように影響して、Redmineのプロセスや運用ルールが変形されるか、という問題意識を持っている。
下記3点について考えてみる。

1)Redmineプロジェクトに組織構造が出てくる点

但し、下記2点は後回し。

2)機能改善の要望への対処
3)保守コスト増に対する対処

Redmineのマイクロコア化は可能か~Redmineを開発基盤にして追加機能は着脱可能コンポーネントにできるか: プログラマの思索

【2】最近は、Redmineプロジェクトはシステム単位に作るべきなのか、組織単位で作るべきなのか、という問題を改めて感じている。

以前から、Redmineの複数プロジェクト機能のおかげで、製品の並行開発や製品の派生開発がやりやすい特徴があった。
しかし、大人数のユーザで使用し始めると、組織構造の影響がモロにRedmineに出てきて、逆に運用ルールが複雑化しがち。
特に、Redmineでは、プロジェクトツリーをいくらでも深く作れるので、Redmineプロジェクトをその時々の判断で作ってしまいがちだ。

そもそも、Redmineプロジェクトはどの基準で作るべきなのか?

【2-1】本来のRedmineの設計思想を振り返ると、Redmineプロジェクトはリポジトリと1対1に対応すべき、と考えられる。
Ver1.4までは、Redmineプロジェクトにリポジトリを1個しか追加できなかった。
その後、複数のリポジトリを追加できるようになり、GitもSVNも複数のSCMリポジトリも登録可能になったので、その設計思想があやふやになったけれど、たぶん変わっていない。

すると、その設計思想では、Redmineプロジェクトはシステム(ビルドモジュール)単位になる。
実際、ソフトウェア開発案件のタスク管理では、システム単位にプロジェクトを作る場合が多い。

さらに、その設計思想では、Redmineプロジェクトのライフサイクルは、SCMリポジトリが新規登録されて、システムが廃棄される期間と一致する。
すなわち、Redmineプロジェクトはシステムの生存期間と同期するので、Redmineは特定の期限を持つ案件の管理に向く。

【2-2】逆に、Redmineプロジェクトを組織と対応付ける運用はやりにくい。
組織内にはたくさんの案件があり、作業の種類も多いので、一つのRedmineプロジェクトでチケット管理すると、すぐに発散する。
かと言って、小さくプロジェクト分割しても、組織のメンバーの入れ替わりも激しかったりするので、放置されやすい。
僕の経験では、Redmineプロジェクトを組織に対応付けた場合は、上手くいった経験があまりない。

【2-3】この発想を突き進めると、Redmineでタスク管理を行うと、開発チームはプロジェクト型組織になりやすい。
つまり、開発チームのメンバーは、別々の組織のメンバーであったとしても、Redmine上では、あたかも一つの有機的なチームとして活動する雰囲気になる。
これは、Redmineが組織に与える「良い影響」だ。

たとえば、業務系Webシステムの開発がメインのSIならば、一つの事業部内では、インフラチーム・アプリチーム・デザイナーチームのように機能別組織に分かれている場合が多い。
インフラ・アプリ・デザイナー担当者に要求されるスキルや技術は全く違うからだ。
(と言っても、最近のWeb開発では、アプリ担当者がインフラもデザインも全て担当するようになってきているが)

そして、実際の受託開発案件では、案件ごとにインフラ・アプリ・デザイナーの担当者が一つのチームを形成するようにアサインされて、作業を開始する。
Webサーバーの構築、画面のモックやデザイン配置、実際の業務ロジックの実装など、それぞれの役割分担で、作業しなければならない。
すると、各担当者は、その組織に応じた考え方や、特有のスキルに応じた考え方を持っているために、別組織の担当者と衝突しやすい。
インフラ・アプリ・デザイナーは機能別組織に所属しているから、そう簡単に融合できないのが普通だろう。

しかし、Redmine上では、一つの作業チケットを複数人のメンバーがやり取りして、完了まで持っていく。
そういうチケットのやり取りを何度も消化していくうちに、各担当者のコミュニケーションが生まれ、各担当者同士でお互いの背景や考え方の認識のズレに気付き、協調して、一つの作業を完了していく。

つまり、Redmine上では、自分の組織の役割を主張し合って衝突するよりも、チケットのやり取りを通じて、あたかもペア作業のような雰囲気が生まれて、一つの有機的なチームが形成されやすい。
Redmineではアジャイル開発のプラクティスを適用しやすかった、という僕の経験は、おそらくそのような構造があったからだろうと思う。

【2-4】しかし、Redmineの運用対象はプロジェクト型組織が向いているからと言って、いつも、サイロ型組織の悪習を打破できるわけではない。

実際、Redmineプロジェクトをシステム単位ではなく、組織単位に作ってしまう場面もたくさん見てきた。
「工程単位のプロジェクト」はRedmineの一つのアンチパターンと僕は思っているが、そのような作り方をやりたい時もある。

例えば、ある大規模な受託開発案件で、製造フェーズのみ外注のオフショアベンダーに発注したとする。
すると、設計・結合テストは国内チーム、製造フェーズはオフショアベンダーのように、工程ごとに組織が分断される。

すると、Redmineプロジェクトは、設計・製造・結合テストのように工程ごとのプロジェクトに分割したくなる。
実際、1個のRedmineプロジェクトで管理したとしても、前工程のチケットが交じると作業しにくいからだ。

また、障害チケットを発行する時、その障害の発生工程がどこであるか、を記入する事が重要になるが、それが当たり前の時、記入するのも面倒だ。
特に、オフショアベンダーから納品後のプログラムをテストして障害が出た時、その障害チケットは、他工程の障害チケットと明確に分けて、目立つようにしたい。
なぜなら、障害修正の責任は国内チームではなく、オフショアベンダーにあるので、そのコストをベンダーに押し付けたいからだ。
たいていの場合、オフショアベンダーの仕様の理解が甘かったり、国内チームの設計が甘いという色んな理由で、ベンダー納品のプログラムの障害は多発しがち。

すると、単純なトラッカー名「障害」ではなく、「障害(ベンダー名)」とか「障害(結合テスト)」のようなトラッカーを作ってしまいがちだ。
トラッカー名を他の名前と変えて、大きく目立たせるようにしたいから、そのような運用になってしまう。
つまり、トラッカーやワークフローも増加してしまい、より複雑になりがち。

また、そんな雰囲気になると、Redmine上では、障害修正やその対応に関するQAのやり取りで、メンバー全員が疲弊してしまう雰囲気になる。
Redmineがプロジェクト型組織を促し、メンバー同士のコミュニケーションを活性化させて、有機的なチームを形成するような影響も出てこない。

【2-5】いろんな事例を見てくると、Redmineプロジェクトがシステム(機能)単位なのか、組織単位なのか、という観点は、下記の基準で評価できると思う。

Redmineプロジェクトをシステム単位に設定したい時は、メンバーが地理的にも組織的にも分散せずに、一つのチームで固まっている場合だ。

Redmineプロジェクトを組織単位に設定したい時は、工程単位に国内チームとベンダー、オフショアチームのように、地理的にも組織的にも分割されている場合だ。

そのように考えると、ソフトウェアアーキテクチャだけでなく、開発プロセスも組織構造に大きく影響を受けてしまう事実がよく分かる。
まさに、コンウェイの経験則の正しさがRedmineでも感じられるのだ。

| | コメント (0)

より以前の記事一覧