Agile

2022/01/23

「ハリウッドリライティングバイブル」のマインドマップ

脚本術の本の一つ「ハリウッドリライティングバイブル」を読んだ。
映画や小説はどんな構造(ストラクチャー)とストーリー(感情を揺さぶる物語)を持つべきなのか、とても理解ができた気がした。
その時のマインドマップを後で自分が読むためにアップしておく。

物語を構成する要素はプロットである: プログラマの思索

なぜユーザーストーリーによる要件定義にピンとこなかったのか: プログラマの思索

小説分析ツールyWriterの機能を元にストーリーの構造や考え方を解説するpart1: プログラマの思索

小説分析ツールyWriterの機能を元にストーリーの構造や考え方を解説するpart2: プログラマの思索

「ストーリーマッピングをはじめよう」本の感想~ストーリーによる企画や要件定義はSaaSと相性がいい: プログラマの思索

【1】どうやら、直近5年間に脚本術の有名な本がどんどん翻訳されているらしい。
理由は知らないがニーズはあるのかな?

ゲームシナリオにハリウッド脚本術は使えるのか?おすすめ本の紹介とともに|卍凸凹|note

(引用開始)
ここ数年、ハリウッドの脚本術の本が色々と出版されています。
ハリウッドで定評のある本は、どれも非常に論理的にわかりやすく説明しており、シナリオを書く人にとっては何かしらの発見がある読み物かと思います。
(引用終了)

僕も、下記の本を読み上げた。
2000年代以前の映画をたくさん見た人にとっては、脚本術の本に載っている映画のストーリーやシーンが分かるから、より一層楽しめると思う。
映画は視覚の芸術だからこそ、小説とは違って、より緻密に構造化されていて、そのおかげで量産化できるようになってビジネスになり、大金をもたらす。
小説家や脚本家になりたい人だけでなく、ロールプレイングゲームを作りたい人にとっても、役立つ本だと思う。

SAVE THE CATの法則 本当に売れる脚本術 | ブレイク・スナイダー, 菊池淳子

映画を書くためにあなたがしなくてはならないこと シド・フィールドの脚本術 | シド・フィールド, 安藤 紘平, 加藤 正人

素晴らしい映画を書くためにあなたに必要なワークブック シド・フィールドの脚本術2 | シド・フィールド, 安藤紘平, 加藤正人, 小林美也子, 菊池淳子

最高の映画を書くためにあなたが解決しなくてはならないこと シド・フィールドの脚本術3 | シド・フィールド, 安藤紘平, 小林美也子, 加藤正人

ストーリー ロバート・マッキーが教える物語の基本と原則 | ロバート・マッキー, 堺三保, 越前敏弥

【2】脚本術の本に興味を持っている理由は、アジャイル開発におけるストーリーによる要件定義手法を理解したいためだ。

ユーザーストーリー、ユーザーストーリーマッピング、ストーリーマッピングなど、似たような言葉が沢山出てくる。
また、カスタマージャーニーやデザイン思考の背後にも、ストーリーという概念が背後にあるように思える。

たぶん、欧米人が語る「ストーリー」という言葉は日本人が持つ言葉のイメージと違うと直感している。
単に物語という意味ではない。
起承転結という仕組みよりも、アリストテレスによる悲劇の分析で三幕構成が提唱されてからずっと、たぶん彼らは舞台劇や小説を理論化してきていると思う。

実際、「ハリウッドリライティングバイブル」「映画を書くためにあなたがしなくてはならないこと シド・フィールドの脚本術」「素晴らしい映画を書くためにあなたに必要なワークブック シド・フィールドの脚本術2」を読んでみると、映画のワンシーンという一つのプロットに小さなストーリーを埋め込み、全体の構成の配置、構造化に数多くの原則を彼らは見出している。
欧米人は、脚本術のおかげでプレゼン能力がすごく高いのではないか。

実際、単純な因果関係で説明されても人の心には響かない。
でも、感情を揺さぶる物語形式がバックボーンに埋め込まれていると、堅苦しいプレゼンを聞いているはずなのに、感情を揺さぶられて聞き入ってしまう、そういう感じがする。

アジャイル開発でも、システムの要件定義というIT技術の言葉が氾濫して難しい現場において、システムの詳細を知らないユーザが理解できるように、脚本術でストーリーを持ち込んで、一連のストーリーとして理解できるようにしたように思える。

今後の僕のテーマの一つは、欧米人が理論化した脚本術を、astahを使って、概念モデルやプロセスの構造に落とし込んで理解したいことだ。


| | コメント (0)

2022/01/14

【資料公開】チケット駆動開発の解説~タスク管理からプロセス改善へ #redmine

プロジェクト&プログラム・アナリシス研究部会で講演した資料「チケット駆動開発の解説~タスク管理からプロセス改善へ」を公開します。

【参考】
お知らせ2点:P&PA研究部会「チケット駆動開発」(1/11)、BOMに関する1日集中セミナー(1/27) : タイム・コンサルタントの日誌から

プロジェクト・マネジメント・システムは存在しうるか : タイム・コンサルタントの日誌から

【1】資料のテーマは、下記の通り。
基本的な前提として、Redmineの経験者を対象としている。

チケット駆動開発は、ソフトウェア開発で使われる障害管理ツールをタスク管理に利用する開発手法を指す。
チケット駆動開発はアジャイル開発と親和性が高いので、アジャイル開発のプラクティスを利用しやすく、チーム運営に役立つ。
チケット駆動開発を支えるチケット管理ツールは、汎用性が高く、とても有用な為、色々な業界の現場のプロセス改善に使われている。
チケット駆動開発の発端、仕組み、事例、プロセス改善に使われる理由を解説する。

チケット駆動開発、チケット管理ツール、Redmineというものを知らなければ、たぶん理解しにくかったかもしれない。

僕は、そういう内容を前提の上で、現時点で、チケット駆動開発とチケット管理ツールがどういう課題を乗り越えて、ここまで進化してきたのか、そして、今後はどんな未知の分野や課題があるのか、を整理して示したかった。
よって、70ページものボリュームになってしまった。

分かってくれる人に理解してもらえれば本望かなと思って公開してみる。

| | コメント (0)

2022/01/10

チケット管理の運用を支える体制とは何か #redmine

チケット管理の運用を支える体制についてツイートがあったのでメモ。

【発端】
ところてんさんはTwitterを使っています 「「なんでプログラマーはチケットシステムが上手く回って、それ以外の部門ではうまく回らないの?」 「プログラマーの世界はプログラマーの中で比較的閉じてるからじゃない?部門をまたいで同じシステムを使わせるというのが色々と大変なのかも」」 / Twitter

akipiiさんはTwitterを使っています 「チケットシステムがなぜプログラマ以外では回らないのか?と言う問題提起」 / Twitter

Dr.とまてぃ@セミコンエンジにゃあさんはTwitterを使っています 「@akipii 一応工場で導入に成功はしましたが最低限チケット管理システムの扱いをわかっている人(≒プログラマ)と、管理が腐らないよう見張ってくれる人が複数いないと機能しないですね」 / Twitter

akipiiさんはTwitterを使っています 「@tomati2020 Redmineコミュニティでは、チケット管理のルールが守られて運用されているか定期的に巡回する人を「お巡りさん(Redmine警察)」、現場の独自プロセスにFitさせる為、チケット管理ツールをカスタマイズする人をマイスター(Redmine職人)と呼んでます。まさに2つの役割に相当していますね!」 / Twitter

Dr.とまてぃ@セミコンエンジにゃあさんはTwitterを使っています 「@akipii ですです。 なのでなんとか自部署での運用は成功しているんですが、適用範囲を拡大しようとすると自助努力ではどうしようもないので会社ぐるみでの研修プログラムなどが必要になってくるかと思われます。」 / Twitter

【1】チケット駆動のタスク管理は、一度運用が回ればスムーズに回る。
チケット管理ツールを基盤としたチケット駆動開発は、アジャイル開発のタスク管理と相性が良いので、変更の多いタスク管理に適用しやすい。
また、アジャイル開発のプラクティスを自然に適用できるので、朝会やKPTによるふりかえり、ペア作業、メンバーの自発的行動を促す雰囲気作りを適用することで、メンバの貢献意欲を引き出しやすい。
結果的に、チームの一体感も高まり、チームの雰囲気もすごく良くなる。

【2】しかし、いつもチケット管理が上手くいくとは限らない事実は以前からRedmineコミュニティでも議論されていた。

その原因の一つは、チケット管理を刺させる体制が不十分なので、チケット管理の運用ルールが守られず、形骸化してしまうことだろう。

【3】経験上、チケット管理をスムーズに運用する為には、4種類の役割が必要になると考える。

①お巡りさん(Redmine警察)
チケット管理のルールが守られて運用されているか、定期的に巡回する。
また、メンバーが困ったときには手助けをする。
Scrumで言えば、スクラムマスターみたいな感じだろうか。
チケット管理の守護神のようなイメージかな。

②マイスター(Redmine職人)
現場の独自プロセスにFitさせる為、チケット管理ツールをカスタマイズする。
それぞれの現場では独自のプロセスがあり、そのプロセスに基づく組織文化や業務手順がある。
それらをチケット管理ツールに反映することで、利用者の操作感を良くして、取っ付きにくさを軽減する。

Redmineの普及促進にはRedmine警察やRedmineマイスターという役割の人達が必要: プログラマの思索

打ち捨てられていたRedmineが復活するまでの軌跡 - Qiita

③エバンジェリスト
チケット管理の伝道師としてメンバーを啓蒙する。
こういう熱い心を持った人が、チケット駆動開発を導入する時に旗印となって、メンバーを啓蒙して、心の熱量を注入していく。
もちろん、メンバーやプロジェクトマネージャへの教育も兼務するだろう。
最初は、エバンジェリストのような熱量のある人が、組織に息吹を吹き込む必要があるだろう。

④活動家
活動ログから現場の業務活動をモニタリングし、組織のあるべき姿(全体最適化)を目指す。
たとえば、標準化推進のPMOや、プロセス改善や品質管理を担当するSEPGが相当するだろう。
彼らは、Redmineの活動ログを元に、各PJの活動を見て、PJの進捗・品質・コストで異常がないかモニタリングし、何かあれば、プロジェクトマネージャにアドバイスする。

活動家はお巡りさんよりもさらにメタな観点で、チケット駆動開発をモニタリングする立場だろう。

【4】では、チケット管理を支える体制では、この4種類の人達だけで十分なのか?
その他のロールはないのか?
あるいは、2種類や3種類の役割に減らしても、チケット管理は上手く回るのだろうか?

こういう疑問を数多く集めて、この主張をさらに強化したいと思う。

| | コメント (0)

2022/01/01

ITの地殻変動はどこで起きているのか?~今後の課題はソフトウェア事業におけるエージェンシー問題を解決すること

ITの地殻変動はどこで起きているのかを2022年現在で考えてみる。
ラフなメモ書き。
特に後半は、ロジックが飛んでいるが、自分のアイデアを書き残すことに重点を置く。

【過去の記事】
ITの地殻変動はどこで起きているのか?~2006年: プログラマの思索

ITの地殻変動はどこで起きているのか?~SeasarとRuby、そしてPF: プログラマの思索

ITの地殻変動はどこで起きているのか?~チケット駆動開発はなぜ生まれたのか・2009年: プログラマの思索

ITの地殻変動はどこで起きているか?~Agile2.0をサポートするチケット駆動開発: プログラマの思索

ITの地殻変動はどこで起きているのか?~チケット駆動開発が進むべき道: プログラマの思索

ITの地殻変動はどこで起きているのか?~アジャイルへの流れと設計技法の違和感: プログラマの思索

ITの地殻変動はどこで起きているのか~アーキテクチャ設計技術にクラウドが必須になった時代: プログラマの思索

ITの地殻変動はどこに起きているのか~ソフトウェアの複雑さをどのようにして手なづけるか?: プログラマの思索

ITの地殻変動はどこで起きているのか~技術革新の流れはWebから機械学習やデータマイニングへ: プログラマの思索

【1】コロナ時代でのソフトウェア事業の問題点

ソフトウェア開発やソフトウェア事業を中核としたIT事業は、2000年頃から大幅に広がり、コロナ時代に入るまでに、GAFAに代表されるように全てのビジネスの中核となった。
ソフトウェアこそが今は、すべての事業の中核システムにある。
コロナ時代になって、対面での営業、対面での人間関係が厳しく制限されて、全ての人間関係がオンライン上で実行せざるを得ない環境に追い込まれて、ソフトウェアはビジネスだけでなく、人々の生活インフラの中核にまで覆い尽くした。

従来の製造業、小売業などの従来型のビジネスモデルは、ソフトウェアを基盤とした事業モデルに大きく変革を強いられた。
それは、業務を単にIT化するだけではない。
単なる業務のペーパーレス化、情報の一元管理が目的なら、コスト削減が目的であり、それはERPというパッケージ製品の導入と同じだ。

では、どんな変革を強いられたのか?
それは、ソフトウェアで作られたシステムを基盤として、企業が提供する価値とそれを購入して消費する顧客をつなげるバリューチェーン全てをシステムで一元管理することだ。
今風に言えば、それはプラットフォームビジネスであり、DXであり、SoEとも呼ばれるのだろう。

全てのバリューチェーンをシステムで一元管理できるとどんなメリットが出てくるのか?
それは、製造業の生産プロセス、小売業の販売プロセス、在庫プロセスという企業内部の情報を一元管理できるだけでなく、販売した顧客の購買履歴や活動履歴をも一元管理することで、顧客関係性を強化でき、顧客の声を生産プロセスや販売プロセスにフィードバックすることで、自社の業務プロセスを改善できるチャンスが増えることだろう。
しかも、アジャイル開発を適用できれば、1ヶ月間というスプリントよりももっと短いサイクルで業務を改善する仕組みさえ作れる。

このDXというソフトウェア基盤にはクラウドというスケールしやすいインフラがあり、MLやDLのようなAI基盤を使って、顧客が望むものを分析し提示することすらできる。
DXを構成する開発基盤や技術が一通り揃ってきたからこそ、すべての事業をソフトウェアで丸呑みして完全に実現できるようになってきた。

事業を一度ソフトウェアで実装してしまえば、アジャイル開発プロセスに従って、いつでも方針の変更が容易になるし、顧客の情報をより簡単に入手できて分析できるから、ビジネスのKPIに適用して、ビジネスそのものの診断ツールにも使える。

しかし、製造業も小売業もその他の業界の事業も全てソフトウェアで実装してしまえばいいだろうが、実際にはその転換は従来のビジネスモデルを構築した企業ほど難しい。
なぜ、ソフトウェア事業へのビジネスモデルの転換は難しいのか?

【2】DXとは「逆コンウェイ戦略を適用する」組織論である

ソフトウェア事業へのビジネスモデルの転換は難しい理由は、ソフトウェア事業に向いた組織を作るのが難しいからだろう。
チャンドラーは、組織構造は経営戦略に従う、と言った。
つまり、ソフトウェア事業に向いた組織構造を構築する必要がある。

一方、コンウェイは、ソフトウェアは組織構造に従う、と言った。
複雑な多重階層構造を持つ組織は、ソフトウェアをより複雑化させる。
人月の法則の通り、ソフトウェアの本質は複雑性にあり、ソフトウェアの複雑性を飼いならすのは非常に難しい。
つまり、ソフトウェア事業に向いた組織構造を作ろうとするが、従来の組織に単にソフトウェア開発を担当させるだけでは上手く行かない。

特に、ソフトウェア開発は、規模の経済が適用しづらく、少数精鋭の優秀な人材の開発チームで実行する方が成功しやすい。
だから、従来の製造業や小売業のように、大規模な設備、大量の人員を用意していても、ソフトウェア開発には向かない。
人月の法則の通り失敗しやすい。

そこで、コンウェイの法則の逆張りを考えて、逆コンウェイ戦略を取ってみてはどうか、という話になる。
つまり、ソフトウェア開発は少人数の開発チームの方が適しているなら、システムの構造に従って、開発チームを構成し直して、そこから組織を作ればいいのでは、となる。
たぶん、今、ScrumがIT企業だけでなく、製造業や小売業など他の業界にも適用されて浸透しようとしているのは、そういう理由があるのではないか。

たぶん、そういう動きは一部の企業に過ぎないだろうが、ソフトウェア事業が中核になれば、従来型の企業もそういう流れに傾いていくのだろうと思う。

DXとは組織論である: プログラマの思索

逆コンウェイ戦略のメモ~望ましいアーキテクチャを促進するためにチームと組織構造を進化させる: プログラマの思索

【3】今後の課題は、ソフトウェア事業におけるエージェンシー問題を解決すること

他方、会社という大きな集合体の中で、ソフトウェア事業を委託する人と、ソフトウェア事業を実行するの間には、利益が相反する緊張関係があると思う。

株主や経営者、生産プロセスや販売プロセスに従事する事業部門の人達は、プリンシパル(=委託者)になる。
彼らはソフトウェアやITに詳しくはないので、専門技術を持つエンジニアに、事業のソフトウェア化を実現するために、事業システムの構築を依頼する。

一方、エンジニアは、プリンシパルのために代理で活動する代理人をエージェント(=受託者)になる。
彼らは、ITの専門家として、プリンシパルの目標や要望を聞き出し、彼らの期待を実現する為に働く。
彼らは、事業のソフトウェア化を実装するために、業務システムだったり、Webシステムだったり、スマホアプリだったり、機械学習基盤だったり、クラウド基盤だったり、いろんなソフトウェア基盤を構築してリリースする。

しかし、経営学で習ったプリンシパル=エージェント理論では、エージェントがプリンシパルにとって望ましい行動を行わないというエージェンシー問題が必ず発生する。
一般に、エージェンシー問題が生じる要因として、「プリンシパルとエージェントの利害の不一致」と「情報の非対称性」の2点がある。

組織運営支援|マーサージャパン

ソフトウェア事業でも、委託する人達はシステムのことが分からないので、結局は、委託者であるSIの言いなりになってベンダロックインされやすい。
製造業や小売業などの発注者も、システムのことは分からない、システム開発をコントロールする難しさは体験済みなので、一括請負契約を結ぶことでシステム開発リスクをSIに全て押し付けようとするが、どうやってもベンダロックインされやすい。
その理由は以前書いた。

一括請負契約はソフトウェア開発にやっぱり向いていない: プログラマの思索

【4】ソフトウェア事業におけるエージェンシー問題を解決するための組織構造とは何か?

従来型の生産プロセスや販売プロセスを持った事業をおなっている会社が、ソフトウェア事業を中核に据えようとする場合、下記のようなイメージで、ホールディングスの持株会社を作り、親会社と事業子会社とシステム子会社がそれぞれ役割分担と制御構造を持つ必要があると考える。

親会社(ホールディングス会社)の役割は、企業グループの全体戦略を策定することだ。
その全体戦略に従って、個別の事業の戦略を策定し、その事業に必要なIT戦略、つまりシステム投資の計画を策定する。

事業子会社は、親会社が策定した事業戦略に従って、その事業に合った業務プロセスを構築し、その業務を実行する。
事業を支える業務には、業務システムが使われるため、自分達の事業に合った業務システムの要求や要件をシステム子会社に提出したり、一緒にIT計画を策定することになる。
事業子会社の成績は、事業のROIで測定されるので、事業のROIを親会社に毎年報告することになる。

システム子会社は、親会社が策定したIT戦略に従って、個別の事業を支援する業務システムを構築し、保守していく。
彼らは、事業子会社の事業戦略に従って、いつまでにリリースする必要があるのか、どれだけの開発予算が必要になるのか、をシステム計画としてまとめて、システム計画を事業子会社と親会社に承認してもらってから、実行に移すことになる。
つまり、システム子会社の主な仕事は、事業を支える業務システム構築とその保守になる。

ここで重要な点は、事業は外部環境や市場の変化によってどんどん変わるので、事業を支える業務システムは一定期間しか使われないという前提で、リプレースする機関と計画を事前に策定する必要がある点だ。
たぶん、減価償却が5年間という制約条件とか、外部環境の変化で事業の寿命は5年とか、そういう単位で、業務システムは定期的に破棄されて、新規に再構築されるように計画しておく。
そうすれば、事業小会社の事業では、たとえば5年おきに新しい業務システムに支えられるので、その時代の最新技術が使えたり、その時代の要件に合ったシステムを使えるようになる。

このように、定期的にシステムはリプレースすべきだ、と親会社も事業子会社もシステム子会社も事前にIT戦略に埋め込んでおけば、時代の変化にあった事業に対応できるはずだ。

さらに、上記のような三者の組織構造があれば、システム子会社は親会社や事業子会社に定期的に報告する義務が生じることで規制をかけられるし、システム構築の目的が親会社や事業子会社の要件に合うように考えさせられるので、システム子会社が暴走するリスクも小さくなるだろうと思う。

【5】事業を支えるシステムの企画は誰が責任を持つのか?

一般の日本企業では、メーカーであれ、ユーザ企業であれ、SI企業であれ、予算駆動だから、システムが必要になったら、その企画フェーズが必要で予算取りの根拠を作らねばならない。
では、その企画フェーズを担当する最終責任者はいったい誰なのか?

ソフトウェアPJの企画フェーズの責任者は誰なのか?: プログラマの思索

本来は、システムの企画フェーズでは、親会社や事業子会社が主導権を持って、事業に必要なシステムの要求や要件を企画すべきである。
なぜなら、彼らが使いたいシステムなのだから。

しかし、僕の経験でもそうだが、ITやシステム開発を経験していない人達がシステム企画を担当すると、割と揉める。
いろんな要求や要件は出てくるが、その時代に合ったIT技術を組み合わせて、品質・コスト・スケジュールのトレードオフに落とし込む作業が難しいのだ。
結局、システム子会社を持たない発注者は、SIやITコンサルに丸投げして、だめなシステムを計画してしまいがちになる。

システム子会社を持っていても、彼らがソフトウェア開発部隊を持っていなかったり、クラウドやAIなどの新技術に関するソフトウェア開発の経験がなければ、SIベンダに丸投げするリスクがある。
結局、企業グループの中核にシステム子会社を持ち、彼らが一通りの技術力を常に研鑽しておかなければならないのだ。

だから、システム子会社の開発者が企画プロセスに入り込んで、彼らが主導権を握る場合が多い。
そして、親会社・事業子会社のユーザと、システム子会社の開発者の間で、対立関係が発生する時もある。
AsIsはユーザが詳しいが、ToBeはユーザでは作りにくい。
開発者がToBeを作ることが多いが、ユーザが果たして納得してくれるのか?

こういう問題にどう対処するか?
たとえば、匠メソッドの匠モデルではこたつモデルを持ち出す。
ユーザ・開発者・営業担当者がいきなりToBeモデルを作る。
事業側も開発側も同じゴールを目指すべきという思想で対応するからだ。

たとえば、Scrumでは、プロダクトオーナー1人が企画プロセスを担当するだろう。
プロダクトオーナーがいるおかげで、開発チームは彼を頼りにしてシステム開発に専念できるはず。

Scrumではどのプロセスを誰が担当するのかが明確ではないかと思う。
企画:ProductOwener
開発:Team
プロセス全体の守護神:ScrumMaster
という仮説も成り立つ。

それから、システムはリリースしておしまいではない。
システム投資の予算を立てて投資するのだから、投資対効果もIT計画に盛り込んで、リリース後に半年後、1年後に実際にROIが予定通りなのか検証したい。
そうしなければ、次のリプレースに活かせないからだ。
また、システム投資のROIを測定する作業をシステム子会社に課すことで、彼らにROIの意識付けもできるようになる。

システムの投資対効果(ROI)を検証するプロセスはどんな構造になるのか?

GoalやToBeでは、システム構築の目的にROI向上(工数削減、経費削減、売上向上)があるはず。
たとえば、システム化することで、手作業から自動化されて工数が削減される。
ペーパーレス化されて、経費が大幅に削減される。
システム化されて、新規顧客に利用してもらって、売上拡大を図る。
そんな内容がROIになるだろう。

稼働後に検証しなければ、一連のPDCAが回らない。
投資対効果=ToBe-AsIs で測定することになる。

企画プロセスでToBeを定めているので、リリース後に実際に、工数や経費、顧客数と売上を測定して、その差分を見ればいい。
もちろん、リリースが遅れると、その分、投資対効果が得られる期間が先延ばしになるので、メリットが薄くなる。
システム構築のコストが増えれば、もちろん投資対効果は薄れるし、使いづらいUIだったり、処理が遅かったり、まともに動かないシステムだったら、投資対効果はゼロかマイナスになってしまうだろう。

【6】こういうホールディングス会社、3社の企業構造をもたせれば、ソフトウェア事業におけるエージェンシー問題をかなり和らげて、エージェントであるシステム子会社が暴走したり、システム構築の目的を忘れてしまうリスクを減らせるのではないだろうか?

逆に言えば、IT計画策定やROI測定などの仕組みを課さないと、事業を支える業務システムを構築できないのではないだろうか。

| | コメント (0)

チケット駆動開発のプロセスと開発基盤を再考する #Redmine

チケット駆動開発のプロセスと開発基盤を書き直してみた。

チケット駆動開発のプロセスとチケット管理システムの全体像 #Redmine: プログラマの思索の図を改良している。

チケット駆動開発は基本的に、ScrumやXPに似たアジャイル開発のプロセスと同一視される。
なぜなら、ロードマップをScrumのスプリント計画、XPのイテレーション計画とみなして、リリースサイクルに従って定期的にリリースされる仕組みとみなせるからだ。
つまり、チケット駆動開発は小規模リリースを実現するプロセス基盤でもある。

他方、チケット駆動開発というプロセスから発生する情報は、チケット管理ツールに全て集約される。
チケット駆動開発プロセスは、チケット管理システムに支えられて実装される。
チケット管理システムの構造は、Input,Process,Outputという単純なプロセスから成り立つ。
中核となるPMISは、フロー管理とストック管理という2つの機能を持つ。

フロー管理の機能は、チケット管理、チケット集計、ロードマップ、ワークフロー管理などがある。
つまり、チケットは流通媒体であり、ステータスに応じてサクサク流れる。
チケット集計には、ガントチャート、カレンダー、かんばんなどがある。
ロードマップとチケット集計を区別したのは、ロードマップがScrumのプロダクトバックログに似た機能であり、スプリント計画あるいはイテレーション計画で使われる重要な機能だからだ。

ストック管理の機能は、チケット管理、SCM連携、Wiki、トレーサビリティなどがある。
つまり、チケットは記録媒体であり、作業履歴や課題の内容、障害管理票などの帳票として記録される。
ただし、記録される媒体はチケットだけでなく、Wikiもあるし、GitやSVNなどの構成管理ツールにもある。
これらの情報と相互リンクすることで、チケット管理ツールにすべての情報が集約されて、ナレッジ基盤になる。

チケット駆動開発はプロセスであるから、処理が主人公になる。
一方、チケット管理システムは機能から構成されるので、機能を通じて記録されるデータが重要になる。
そのデータの特徴はフローでもありストックでもある。

チケット管理システムは、チケットにフローとストックの両方の意味を故意に持たせることで、幅広い運用が可能になる。
ある側面では、タスクかんばん上でステータス管理できるし、ある側面では、そのタスクや課題のチケットには、数多くの情報が記録されているし、その変更履歴も記録されているので、経緯や意図を把握できる。

このチケットの二重性という特質がチケット管理ツールに豊かな機能や利用シーンを生み出してくれるのだ。

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

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

| | コメント (0)

2021/12/31

昭和の管理者の承認処理は判子押印、令和の管理者の承認処理はいいねボタンを押すこと

「昭和の管理者の承認処理は判子押印、令和の管理者の承認処理はいいねボタンを押すこと」という文言をどこからか拾って、なるほど、その通りだと思った。

【1】昭和の管理者は、部下が提案書を作成して、申請した書類に判子を押印して承認する。
判子押印にはいくつかの儀式があった。
上司にお辞儀をするようにわざと左30度傾けるとか。
今ではあまりにも考えられないが。

【2】一方、令和の管理者は、部下がチャットで意見を提案した時に、いいねボタンを押して、承認したことを認める。
以前の平成の管理者は、部下の申請メールに対し、わざわざ文章を書いて、承認したことを返信する手間がかかっていた。
だから、いいねボタンを押すだけなら、わずか0.1秒で承認処理が済ませられる。

なぜなら、令和の管理者は意思決定の回数が多すぎるのだ。
たぶん、普通の企業の管理職や役員は、毎日100通以上のメールを処理しているのではないだろうか。
そのメールを処理することは、意思決定しているのと同じ。
メールのやりとりだけで数時間、半日を使ってしまうのではないか。

令和の時代は、TeamsやSlackなどのチャットで部下とやり取りするから、承認するなら、いいねボタンでいい。
いちいち文章を書いて返信する必要もない。

【3】LIFE SHIFT(ライフ・シフト)の一節に、1990年の仕事のやり方と2015年の仕事のやり方の違いが書かれている。

1990年の仕事は、全てが紙ベースだった。
顧客とのやり取りは、近ければ電話や会社訪問、遠ければ郵送による手紙のやり取り。
だから、海外出張する時は2週間や1ヶ月ぐらいかけるのが普通だった。
タイプライターを打つ女性に、提案書の書類のイメージを伝え、添削して返す。
この頃は、手紙や申請書を判子で押印する承認処理が多かった。
意思決定する時は慎重に行える時間や余裕があった。

2015年の仕事は、全てがオンラインになる。
顧客とのやり取りは、メールやチャット。
海外出張したとしても、1週間以内で慌ただしい。
毎日、100通以上のメールを読んで、処理して、日々の意思決定を下す。

この四半世紀で、承認処理も意思決定も大きく変わった。
意思決定の手法が変われば、意思決定の中身も変わってくると思っている。

| | コメント (0)

2021/12/28

チケット駆動開発のプロセスとチケット管理システムの全体像 #Redmine

チケット駆動開発のプロセスとチケット管理システムの全体像はこんなイメージではないだろうか?

【1】チケット駆動開発とは、チケットを起点として、業務の活動をすべてチケットで追跡する仕組みでありプロセスだ。

具体的には、リリース計画を作成して、チケットを一括登録したり、チケットを随時登録する。
登録されたチケットは担当者によって日々更新されたり完了されて、その進捗状況は、ガントチャートやロードマップなどのチケット集計機能によってリアルタイムにモニタリングできる。
管理者はこの情報を使って日々の意思決定やリスク管理に適用する。

リリースバージョンでグルーピングされたチケットが全て完了になったら、そのバージョンはCloseされて、成果物がリリースされる。
ソフトウェア開発ならば、バージョンつまりスプリントやイテレーションがCloseされると同時に、そのバージョンのモジュールがビルドされてデプロイされてリリースされる。

リリースされたモジュールや成果物は開発者が検証したり、ユーザが実際に使ってみて、開発者が見つけた障害修正やユーザの改善要望が管理者へフィードバックされる。
管理者はそのフィードバック情報を元に、次のリリース計画をブラッシュアップして、次のスプリントを開始する。

すなわち、チケット駆動開発とはアジャイル開発を実装したプロセスの一つとみなせる。

【2】一方、チケット駆動開発はチケット管理ツールという具体的なソフトウェア製品よって支えられている。
このソフトウェア製品という特性と実際の運用をまとめたものをチケット管理システムと呼ぶことにしよう。

【2-1】チケット管理システムの具体的な中身は何か?
基本はPMBOKが言うPMIS、つまりプロジェクト管理情報システムだ。
すなわち、チケットというインプット情報をPMISへ食わせた後、PMISがいろんな観点で加工して、PJ管理に必要な各種レポートをアウトプットして吐き出す仕組みだ。

第三者の観点から見れば、チケット管理システムはすごく単純だ。
なぜなら、インプット+プロセス+アウトプットという逐次実行の仕組みに過ぎないからだ。

【3】しかし、チケット管理システムというPMISの機能を解剖すると、単純な機械でありながら強力な機能を持っていることが分かる。
PMISの主な機能は、フロー管理とストック機能の2つだ。

【3-1】まず、フロー管理は、チケットを流通媒体とみなし、タスクをサクサク流すことに力点を置く。
MS Plannerのタスクカード、Agile開発やカンバン駆動開発のストーリーカードやタスクカード、申請承認ワークフローの申請書に相当する。
フロー管理では、作業のリズムを重視する。

【3-2】次に、ストック機能は、チケットを記憶媒体とみなし、日々の作業結果を記録していくことに力点を置く。
障害管理票や課題管理票、WBSなどの記録媒体。
過去の作業履歴、得られた経験や知識はチケットに記録されているので、チケットが蓄積されるほどナレッジ資産になる。
ストック管理では、ナレッジ基盤を目指す。

【3-3】実際は、チケットがフローとストックの2つの意味を二重に持っていることから、PMISはフロー管理とストック管理の機能を自然に持つようになる。
この特徴により、数多くのチケットを集計した結果から有用なメトリクスが得られる。
例えば、ガントチャート、EVM、リソース管理、タスクボードなど。
また、この特徴により、蓄積されたチケットの履歴やチケット間の関係、成果物とチケットの相互関係から、トレーサビリティの機能が生まれる。

【3-4】チケット駆動開発では、ビルドしたモジュールはバージョンというタグがあり、バージョンでグルーピングされたチケットがあり、そのチケットには作業履歴が残っていて、チケットには構成管理ツールの配下に置かれたソースコードや設計書などの変更履歴が紐づくように、運用される。
このトレーサビリティという機能があるからこそ、開発者は自信を持って開発できるし、管理者もリリースしたモジュールの品質を自分でコントロールできるようになる。

【4】チケット管理システムには、その運用を支える数多くのロールがある。
チケット管理をスムーズに運用するために必要なアクターがあることは、Redmineコミュニティで数多く研究されてきた。

【4-1】チケットを起票する現場の人は、PMISを業務のナレッジ基盤とみなす。
自分が入力した作業結果だけでなく、他人の作業結果も参考にして、ナレッジを利用することで自分の作業手順を効率化することに役立つ。

【4-2】管理者は、PMISをメトリクス集計のプロセス黄ばんと看做す。
彼らは、ガントチャート、EVM、リソース管理、タスクボード、信頼度成長曲線など各種の有用なメトリクスを用いて、業務活動の進捗管理、品質管理、要員管理をモニタリングし、日々の意思決定に活かす。

【4-3】お巡りさん(Redmine警察)は、チケット管理の守護神だ。
彼は、現場の人や管理者がチケット管理に困っていたら支援して、チケット管理をスムーズに運用させる。
チケットは生鮮食料品みたいなもので、日々更新されなければ、ただのゴミに過ぎない。
だから、お巡りさんは定期的にチケット管理システムを通じてチケット管理が運用されているか見て、チケット駆動開発を守る人になる。

【4-4】エバンジェリストはチケット管理の伝道師だ。
チケット管理がいかに素晴らしいか、チケット管理を通じて組織をどのように発展させていくべきか、現場の人や管理者を啓蒙する人だ。
エバンジェリストは熱い気持ちを持ち、チケット管理に関わる人の心に息吹や熱気を注入する人だ。

【4-5】PMISは、現場の人達や現場のプロセスに合うようにカスタマイズしたくなるので、マイスターという開発者がPMISをその現場特有のPMISへカスタマイズし、現場のプロセスに局所最適化する。
マイスターはまさにPMISの職人だ。
マイスターから見れば、PMISはPJ管理の開発基盤という側面も持つ。
つまり、チケット管理システムというPMISはプロジェクト管理を実現するソフトウェアフレームワークという開発基盤とみなせる。
すなわち、チケット管理システムはカスタマイズしやすい特徴を持つので、いろんな現場に適用できるように局所最適化しやすい。
だからこそ、改善が大好きな日本人にはチケット管理システムが合うのだろう。

【4-6】活動家は、PMISのログ(Redmineの活動タブ)を見て、現場の人達の活動、さらには組織の活動をモニタリングし、PMISを組織のプロセス改善の基盤として使う。
活動家は、1個のPJや1個の部署だけでなく、複数のPJや部署を横断して、人間の血液診断や健康診断のように、PMISを通じて組織の活動診断を行う人になる。

【5】こういうポンチ絵を描いてみると、チケットで作業も課題も障害も管理する、という単純なアイデアから生まれたチケット駆動開発は、いろんな側面に支えられて、豊富な応用結果を持つことが分かる。
こういうことを考えるのが楽しい。

脱Excel! Redmineでアジャイル開発を楽々管理:エンジニアがお薦めする 現場で使えるツール10選(3)(1/5 ページ) - @IT

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

Redmine警察・マイスター・活動家は導入の立役者 | マドびっ! Madosan's View

Redmineの普及促進にはRedmine警察やRedmineマイスターという役割の人達が必要: プログラマの思索

打ち捨てられていたRedmineが復活するまでの軌跡 - Qiita

| | コメント (0)

2021/12/04

「林業におけるRedmine活用」は林業におけるDXの良い事例だ

第21回勉強会 - redmine.tokyoで、「林業におけるRedmine活用」の講演は林業におけるDXの良い事例として、はてぶでバズっていたらしい。
ラフなメモ。

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

第21回東京Redmine勉強会の感想 #redmineT ~Redmineは業務も組織も包み込む柔軟性がある: プログラマの思索

林業のタスク管理をRedmineでやる話|株式会社百森|note

[B! Redmine] 林業のタスク管理をRedmineでやる話|株式会社百森|note

深津 貴之 / THE GUILD / noteさんはTwitterを使っています 「DXです。これが本当の意味のDXです。すごい。Redmineとイシュー管理で、森を整備する話。 https://t.co/PTBB6RFfnM」 / Twitter

【他ツイート】
akipiiさんはTwitterを使っています 「この発想はありうる。RT @murasakimitsuru: リン業…林業にもredmine導入で農業・酪農にもredmine導入ありそう。(モバイルredmine化を妄想)」 / Twitter

yuutaさんはTwitterを使っています 「林業におけるRedmine活用 https://t.co/x6duLhY4ty」 / Twitter

akipiiさんはTwitterを使っています 「興味深い講演でした。まさにDX。配信内容は見れますよ。RT @fladdict: DXです。これが本当の意味のDXです。すごい。Redmineとイシュー管理で、森を整備する話。 https://t.co/tm7QNJwDhH」 / Twitter

金森悠介|才流さんはTwitterを使っています 「業務の見える化と、文字情報に落とす意義がよくわかる事例 林業におけるRedmine活用 https://t.co/TI33f0hhI4」 / Twitter

れぐなむさんはTwitterを使っています 「現場の地図が付いてるだけでわかりやすさ段違いって印象受けるな。これ手作業なら絶対貼らないけどITなら一瞬だもんな。こういう地味な改善ってドローン飛ばしてあれこれするより効果でかそう / “林業のタスク管理をRedmineでやる話|株式会社百森|note” https://t.co/IQpDaQF6fO」 / Twitter

宇埜隆士さんはTwitterを使っています 「DXへの第一歩。チケット文化を根付かせることができたのは凄い(小並感)。 / 他74件のコメント https://t.co/zxrf1ZiT4n “林業におけるRedmine活用” (545 users) https://t.co/QHobwimNdt」 / Twitter

株式会社グローバルネットコア【サーバー・クラウド・Webシステム&ホームページ制作・セキュリティ】さんはTwitterを使っています 「wikiやredmineを林業で活用・・・これは素敵ですね!!当社のようなIT系企業でよく使っているようなデジタルツールを、第一次産業の現場で導入している成功事例です。これぞまさにDX!! #DX #DX推進 #デジタル化 https://t.co/3ZkqysJTFe」 / Twitter

中野ヤスオ|ARIさんはTwitterを使っています 「勇気をもらえます。常識にとらわれず、もっとより良い働き方を追求していきたいです。 / 他70件のコメント https://t.co/xmmZzE8qzc “林業におけるRedmine活用” https://t.co/qkV5jAhww5」 / Twitter

ぽっとさんはTwitterを使っています 「プロジェクト管理システムとしてはかなり好きRedmine。あとはガントチャートの棒がドラッグ操作で動かせたら完璧のぺきなのよ(販売されているプラグインでできることは知っています) https://t.co/nGgFfQE8Uq」 / Twitter

(call me #'knjname)さんはTwitterを使っています 「Redmineの汎用性は異常なので、何かシステム組むぐらいならまずRedmineに落としてみてほしい現場はたくさんある / “林業におけるRedmine活用” https://t.co/ke9qHiRhgT」 / Twitter

きのくにさとしさんはTwitterを使っています 「IT木こりとして、興味深く拝見した。 https://t.co/8PcZGv8ezF ちゃんとみんなを巻き込めているのがすごい。そこに一番苦労しそう。」 / Twitter

Katsue NagakuraさんはTwitterを使っています 「林野庁出身のすごいDX人材が農水省にいらっしゃるのもあって、個人的には勝手に農業林業とDXが熱いです、最近 林業におけるRedmine活用 - Speaker Deck https://t.co/FjZQgdUhnJ」 / Twitter

テキスト×音声で記録するAI電話ピクポン代表の小幡さんはTwitterを使っています 「林業におけるRedmine活用 の第21回勉強会で発表した内容です! ひとことにITと言っても様々な業態があるように、林業にも様々な業態があります。今回説明させていただいたのも、あくまでも林業という多様な業界の一例である、というこ… https://t.co/Si920QOsQz https://t.co/YcLwuD2FJL」 / Twitter

t_takataさんはTwitterを使っています 「とても良い事例だった。作業をチケットに分割できてチケットテンプレート化できればかなり楽になるのは実感がある。 / 林業におけるRedmine活用 https://t.co/sqxWarxw0z」 / Twitter

【1】林業にRedmineを入れた背景となる問題意識としては、労働者の高齢化が進んでおり、口頭伝承の作業代わりと多いことだろう。
結局、若い人にノウハウが伝わらないし、単純な肉体労働みたいなイメージに思われてしまう。

そこで、Redmineを導入したことにより、チケットで全ての作業を手順化して作業の平準化と臨機応変な担当のアサインを図ったこと、作業チケットから生まれたノウハウや経験談はWiki(Note記事を読むとDocBaseのサービスらしい)にナレッジとして蓄積していくようにした。
すると、作業者の意識も主体的になる効果もあったらしい。
ツールを入れることでプロセスを改善するだけでなく、従業員を含めた組織文化も変化させた点が素晴らしいと思う。

【2】「木こりのジレンマからの脱却」という問題意識はよくある。
作業を手順化して標準化し、IT化しやすいようにしたいが、そんな作業に時間を書けるくらいなら、実際の作業をすることでビジネスでお金を稼ぐべきだ、みたなジレンマがよくある。

こういう苦労は普通はJカーブを描くのだろう。
つまり、作業のチケット化、作業の手順化や標準化をすることで、一時的に生産性は下がるが、その効果が出ると一気に効率が上がる。
こういう木こりのジレンマは、林業に限らず、事務処理でもIT業界のシステム開発でもよくあるだろうと思う。

【3】今回の林業の事例では、Redmineの導入により一連の作業をIT化したのは、思い切った改革なのだろうなと思う。
そもそもITに慣れていない従業員も多かったはずだろうだから、苦労も多かっただろうと推測する。

一方で、どこかの勉強会で、日本の省庁の中で最もデジタル化が進んでいる省庁は、実は農林水産省です、という話を聞いた時がある。
農林水産業は実はITと相性がいいのではないか、という仮説も持てる。
なぜならば、元々IT化されていない作業が多いだけでなく、IT化することで生産性が大きく増える点があるからだ。
今回はRedmine導入による作業の標準化、ナレッジ蓄積という問題解決だった。
他にも、ドローン導入やGPSを使って広大な農地を管理したり、AIを使って農産物の品質判断したり、という事例とか、素人でも色々実現可能なアイデアは割とたくさん出てくる。

つまり、農林水産業はDXと相性が良いのではないか、という仮説を持つこともできるだろう。
この辺りのアイデアも膨らませてみたい。

| | コメント (0)

2021/12/01

物語を構成する要素はプロットである

最近のアジャイル開発では、企画フェーズや要件定義フェーズでユーザーストーリーを使った手法が多い。
この風潮に僕はまだ腑に落ちていない。
たぶんその理由は、ストーリーや物語の構造を欧米人の文脈で理解できていないからでは、と思っている。
たまたま、良いツイートのまとめを見つけたのでリンクしておく。

その中で、ストーリーとプロットは相異なることも理解した。
理解したことをラフなメモ。
特に結論なし。

【参考1】
ストーリー第1回目 三幕構成とはなにかな? - Togetter

ストーリー第2回目 第一幕 状況設定ってなんだ、キャラクター設定どうしたらできんの? - Togetter

ストーリー第3回目 第一幕 “欲しいもの”は二段階で考える?“欲しいもの”と“欲しいもの”の衝突が葛藤を生む。 - Togetter

ストーリー第4回目 セントラル・クエスチョンを意識してみよう - Togetter

ストーリー第5回目 群像劇でも主人公を立てよう その時に注意しなければならないことは? - Togetter

ストーリー第6回目 ダイヤモンドの各塁はどのような役割を果たしているのか ターニングポイントについて - Togetter

ストーリー第7回目 メインプロットとサブプロットの構造を理解しよう - Togetter

ストーリー第8回目  共感か驚異か - Togetter

ストーリー第9回目 シナリオライティングの参考書は何を読むべきか? - Togetter

ストーリー第10回目 2幕目をぐいぐい動かすための小技を紹介するよ! - Togetter

プロットの書き方 前編 - Togetter

プロットの書き方 後編 - Togetter

【参考2】
なぜユーザーストーリーによる要件定義にピンとこなかったのか: プログラマの思索

小説分析ツールyWriterの機能を元にストーリーの構造や考え方を解説するpart1: プログラマの思索

小説分析ツールyWriterの機能を元にストーリーの構造や考え方を解説するpart2: プログラマの思索

「ストーリーマッピングをはじめよう」本の感想~ストーリーによる企画や要件定義はSaaSと相性がいい: プログラマの思索

【1】「SAVE THE CATの法則 本当に売れる脚本術」「アウトラインから書く小説再入門 なぜ、自由に書いたら行き詰まるのか?」「ストラクチャーから書く小説再入門 個性は「型」にはめればより生きる」を読むと、「ストーリー」という言葉はあまり使われず、「プロット」と言う言葉をよく使う。
ストーリーは出来事を単に時系列で並べたもの。
プロットは出来事の原因と結果を抜き出したもの。
プロットは因果関係である。

プロット (物語) - Wikipedia

【2】プロットには、数多くの種類がある。
メインプロットは“事件”である。
メインプロットは主人公が辿るべき話の流れであり、ストーリーラインである。
メインプロットは大抵の場合、主人公の葛藤、それを乗り越えた成長や旅を表す。

【3】サブプロットは、メインの物語とは違うもう一つのテーマを語るパート。
サブプロットは、“心”についてのプロットだと考えればいい。
つまり、サブプロットは主人公の心理描写。
実際は、ラブストーリーがサブプロットによく当てはまる。

メインプロットがA面なら、サブプロットはB面、裏面のストーリーとなり、物語をより複雑に奥深く見せてくれる。
インプロットとサブプロットが互いに影響し合うことで、ストーリーは非常に多くのバリエーションを持つことになり、その展開は観客の予想を超えたものとなるわけだ。

【4】プロットポイントは、三幕構成内の幕と幕を繋ぐイベント。
具体的には、1幕と2幕の切れ目、2幕と3幕の切れ目にあたるイベント。
プロットポイントは、ターニングポイントとも呼ばれる。
つまり、ターニングポイントは主人公に行動を起こさせ、物語の方向を転換させる出来事になる。

第一幕の終わりには、第一ターニングポイントがあり、ここでガラっと舞台が変わる。
第二幕の終わりには、第二ターニングポイントがあり、ミッドポイント(第二幕の真ん中)で結末に向かう方向性を見出した主人公が、さらに結末へと向かうことになる出来事になる。

【5】こういう脚本術の本を読んでいると、映画や小説を欧米人は徹底的に構造化して組み立てているんだな、と思う。
臭いストーリーだなと思いながらも、なぜかハマってしまう。
たぶんその理由は、人間の原始的動機を揺り起こすように上手く構造化して緻密に作られているのに、その原始的動機を上手く隠し通しているのではないか、と思ったりする。

| | コメント (0)

プリコラージュの対となる概念はエンジニアリングになる

【1】図書館で借りた本でふと見つけた言葉。
「レヴィ・ストロースが提唱したプリコラージュの対となる概念は、エンジニアリングなのだ」と言う言葉にものすごくしびれた。
こういう発想があるとは思わなかった。
Redmineによるチケット駆動開発は、たぶんプリコラージュに近い概念と思う。
一方、ソフトウェア工学のようなエンジニアリングはその対極にある。

【2】「勝つための論文の書き方」では、プリコラージュをこんなふうに説明している。
構造人類学を創始したレヴィ・ストロースは、どんなに原始的に見える未開人の行動や思考にも、それなりの論理と構造があるのだという事実を、フロイトの無意識理論やソシュールの言語論を構造把握の手法として借りて、証明した。
こういうやり方、つまり、他の分野から方法を借用して把握する方法をプリコラージュ、すなわち、素人大工仕事と呼んだらしい。

【3】Redmineでチケット駆動開発を実践するというアイデアは、元々は、多機能化した障害管理ツールをソフトウェア開発のプロジェクト管理全般に適用しようというものだ。
つまり、手元にある道具が割と高機能だったから、これを目の前の問題に当てはめてみよう、みたいな感じから始まったと思う。

RedMineでチケット駆動開発!: プログラマの思索

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

そのアイデアは、タスクの発生から担当者のアサイン、プログラムによる実装、テスト、ビルドしてデプロイまでの一連の作業履歴をチケットに全て集約することで実現される。
つまり、チケットは、ソフトウェア開発で発生する全ての作業のライフサイクルを全て包み込む。

チケット駆動開発の適用範囲part4~ウォーターフォール型開発への部分適用の注意点: プログラマの思索

【4】さらに、BTSには集計機能、分析機能が使えることから、データ集計基盤、さらにはソフトウェア工学のデータ基盤として使えないか、という発想に発展させることができる。
元々、障害管理ツールなのだから、バグの傾向分析や信頼度成長曲線は簡単に出力できるからだ。

ソフトウェア・リポジトリ・マイニング~Web2.0をソフトウェア工学に応用する: プログラマの思索

【5】そんなことを考えると、本来はチケット駆動開発は、高機能化した障害管理ツールをプリコラージュした手法に過ぎなかったのに、いつの間にか、ソフトウェア工学を支援できるプロセスに発展できるのではないか、という妄想につながる。

2008年に僕が初めて講演したRedmineでチケット駆動開発を実践する~チケットに分割して統治せよでは、「チケット駆動開発は、中身は古いが新しい衣をかぶったアジャイル開発」と呼んだ内容は、プリコラージュの意味で使っていたのだと今になって気づいた。

2021年の今となってはもう当たり前の概念だし、普通にみんな使っているけれど、こういう考え方で新しく構造化できるのは面白いと思う。

| | コメント (0)

より以前の記事一覧