無料ブログはココログ

Redmineが得意なプロジェクト

Redmineの機能を考えると、どのようなプロジェクトに向いているかがわかります。

プロダクトライン

Redmineのチケットは全てのプロジェクトで通番になっています。他のプロジェクトのチケットを容易に参照できますので、プロダクトラインの開発時の様に過去のプロジェクトの参照が必要な場合に有利です。
参考:『Redmine実践ガイド』に書き忘れた事 - 管理を容易にするチケット番号の一意性 -

System of Systems あるいは トップダウンに分解できる

Redmineのプロジェクトとチケットは、それぞれの親子関係を持つ事ができます。 System of Systems と呼ばれるような、複数のプロジェクトから構成されるシステムも小さな単位に分割して管理できます。
参考:[#TiDD] チケットによる情報の関連付け(チートシート)

多様なコミュニケーションが必要な大規模システム

Redmineには他のITSにもあるWikiのほか、フォーラムやニュースなどの情報共有の仕組みがあります。また、ガントチャートによる可視化やREST APIなどシステム連携機能もあります。大規模システムにも対応できる多様な機能が標準で用意されています。(大規模な開発が多いので参考にある様に「説明会を開くべし」と言う意見が多いのでしょうね)
参考:[#redmine] Remineを活かしたプロセス支援 - 失敗しないプロセス支援 - #rxtstudy

作者のJPL(Redmine.jpブログ)は、このような開発をしているのかも知れませんね。

ちなみに上記に当てはまらない、一度限りのプロジェクト、単独システムあるいは構成が変わり易いシステム、チケットで十分あるいは小規模な場合は、Redmineにこだわらなくて良いプロジェクトと言えるでしょう。

なお、Redmineの特徴を説明しましたが、ITSの導入には知見者あるいは導入意欲を持った人の存在が必要になります。また、過去の資産をどうするかということも、ITSを選択する際の重要なポイントの一つでしょう。

このエントリーをはてなブックマークに追加


[#UAS] Ultimate Agile Stories の寄稿5本を一挙公開!

Ultimate Agile Stories (UAS)は全5册からなるアジャイル同人誌です。

この本は、アジャイルのコミュニティの人達の熱い思いを綴った記事をまとめたものです。頒布による利益は、東北の震災の年から5年間寄付されてきました(まだ在庫があるので、寄付したぐらいの赤字だそうです)。

私もアジャイル関係のコミュニティに出入りしていましたし、日本XPユーザー会関西支部(XPJUG関西)でチケット駆動開発の分科会があったことなどから、全ての本に寄稿させていただきました。

これまで、次の本が出る度に1年前の寄稿を公開してきました。しかし昨年、とうとう最終号になってしまいましたので、これまでの寄稿をまとめて公開します。

UASには、アジャイル放談という飲みながらそれぞれの思いを熱く語り合った記事があります。そろそろ若い人に任せた方が良いのではないか、などと思いながら、なぜか全てに参加させていただきました。

この他にも有名な方々の記事がたくさん載っていますので、機会を見つけてぜひ購入してください(トップのリンク参照)。



UAS5の寄稿

<UAS5の紹介>
[#UAS] アジャイル開発とフィードバックそしてリスク - Ultimate Agile Stories Iteration 5 -



UAS4の寄稿



UAS3の寄稿

<UAS3の紹介>
[#Agile] 自己組織化あるいは自律的組織 #UAS3



UAS2の寄稿

<UAS2関連記事>
[#TiDD]ウォータースクラムフォールよりも五月雨WFの方が変化に強い!(かも)



UAS1の寄稿

このエントリーをはてなブックマークに追加


[#TiDD] パタンランゲージで経験を活かしたプロセスを構築する

プロセスが好きだと言うと若い人は怪訝そうに見られる。品質保証の人からは「SEPG(標準プロセスを制定するグループ)とかですか?」と聞かれる。アジャイルな人達は「プロセスやツールよりも個人と対話を」と言われる。

そんなことは無いはずです。一般に「プロセスはタスクの集合」と定義されるからです。つまり、ソフトウェア開発をしている人は皆、プロセスを実行しているからです。

モデリングの失敗

このようにプロセスが他人事の様に語られるのは、プロセスのモデリングに失敗しているからです。「ソフトウェアプロセスもソフトウェアである」と言われていますが、これまでのプロセスのモデルはプロセス特徴を表現できなかったからです。

そもそもプロセスモデリングは、プロセスの知識を伝達、理解、改善、管理、 支援、自動化するものです(参考:[#TiDD]失敗しないチケット駆動開発 - プロセスモデリングの視点から+告知 -)。しかし、ウォーターフォール(WF)の標準プロセスやスクラムは、メタなプロセスと汎用的なプラクティスを示したもので、過去の具体的な経験を伝え、そのノウハウをソフトウェア開発として活かす仕組みは、肥大化し易い標準プロセスによる管理や開発チームの習熟に依存しています。

例えばユーザデモ

たとえば「段取り8分」といわれるように段取りは重要ですが、例えばユーザデモをどのように調整するかといった基本的な事もうまく支援できません。

【標準プロセス】
仮に標準プロセスに実施方法を書いたなら、「うちはこのやり方です」と顧客に言ったり、何らかの事情でテーラリングしたくても制約を受けてしまう事があるでしょう。
逆に詳しく定義しなかった場合は、それぞれのプロジェクトでWBSなり線表に落としますが、どのような条件があってその計画にしたかがわかりません。このため、前回は顧客が用意してくれたので、デモ用のデータや会場の準備を忘れるかもしれません。
経験の少ないマネージャーなら、マイルストーンの設定だけで必要なタスクが漏れているかも知れません。

【スクラム】
スクラムではタスクの依存関係や期限をうまく管理しないいけませんが、タイムボックスからあふれて間に合わないなんてことが起きるかも知れません。
ベテラン揃いなら色々な工夫や調整を行うのでしょうが、それはプロセスで支援されるのではなく、開発に関わる人達の習熟に任されています。勉強会やコーチが必要な訳です。

どんなモデルなら支援できるか

これらのプロセスモデルをソフトウェアの概念に当てはめてみると、クラスや機能であって、段取りに必要な関連や状態概念が不足している様です。

【クラス指向】
WFの標準プロセスは抽象クラスの責務でモデル化されています。WBSに代表される様に細かな構造に分解してプロセスを定義します。インスタンスに相当する内容は自由だが責務だけは果たす様に求められています。CMMを提唱したハンフリー氏らはプロセスのスキップが最も大きな問題と考えていて、抜け漏れチェックが重視されています。ただし、このモデルに基づいてもインスタンス化する際に考慮が必要な内容は直接は支援されず、組織内で定義し、訓練によって実現しないといけません。

【機能指向】
スクラムのロールモデルは機能で分割され、ロール間やロール相互のコミュニケーションに必要なアーキテクチャ、具体的には外部との連絡、コンセンサスの共有、などの仕組みを持ちます。実現する順序はバックログで管理されますが、バックログの調整はオブジェクトである人に依存しています

このように プロマネ、リーダ、プロダクトオーナは苦労しています。それは具体的なプロセスで考えないといけない段取り、つまり状態があまり支援されていないからです。

【状態指向】
実際にプロジェクトを実施する際には、具体的な開発対象の状態が考慮されます。具体的には、いつまでに何を作るかを考えてそれに至る道筋を考えています。これがいわゆる段取りです。上記2つのモデルでは具体的な開発対象を直接扱いませんので支援が行えないのです。そこで開発対象の状態を考慮したプロセスが必要になります。

パタンランゲージ

そこでパタンランゲージです。開発の計画を立てる際は、ゴールや制約に合わせて、過去の経験した作業を当てはめ、必要に応じて作業を組み立て直します。まさにマネージャがしてる事です。

パタンランゲージを利用する際は、この工程をパタンランゲージとプロジェクトランゲージ2段階で行います。関係者からのインタビューで良いと思ったものをパタンランゲージとして整理し、制約を考慮して組み合わせてプロジェクトを段階的に構成していきます。

パタンランゲージはどのような問題(フォース)をどのように解決するかを集めた、いわゆるパターンの集合です。誤解を恐れずに言うと、そのドメインに特化したDDDのユビキタス言語に相当するものだと思います。

プロジェクトランゲージでは パタンランゲージを構造化・洗練したものを表の縦軸に、プロジェクト横軸に取った表を作成します。実施する交点につける印が多くなる様に、制約を考慮してプロジェクトの実施順序を決めます。ちょうどユーザーストーリーマッピングを左に回転させたようなイメージです。

(参考:本橋、中埜、羽生田、懸田、江渡、パタンランゲージからプロジェクトランゲージへ共創のプロセス(PDF),AsianPLoP 2011)

パタンランゲージで経験を活かしたプロセスを構築する

ここで先ほどのユーザデモを考えてみましょう。ユーザデモはパタンの一つですので、パタンランゲージに加えられるでしょう。

それだったら従来のプロセスでユーザデモを追加したのとあまり変わらないのではないかと思われるでしょう。実はこの時点で他のパタンと同列に並んでいる所が後で効いてきます。

プロジェクトランゲージを作成する際はセンターと呼ぶ概念や対象物を明確にします。ユーザデモがより重視されるならレビュー作業を中心的なものにするかも知れませんし、逆にユーザデモをキーマンに対してだけ実施するかも知れません。

従来だとユーザデモのような作業は足し算でしかなく、標準プロセスや元のフレームワークを変更する事はできません。パタンランゲージは関係者で協議して方向性を決める(センタリング)しますので、バランスの良いプロセスを再構築できるのです。

どこから始めるか

パタンランゲージのやり方は、小規模プロジェクトでよくやっている事です。示された制約と使えそうな経験を思い浮かべ、依存関係のあるまとまりでその実施順序を決めていきます。

ソフトウェア開発の規模が小さくなると実施できる事が限られます。関係者で議論する事でバランスの良いプロセスを構築して、顧客の要望に応えていたのです。

経験を集めてパタンランゲージを構築する方法は、チケット駆動開発で作成した過去の履歴を分類して活用できると考えています。

まずはチケットにどのような経験が蓄積されているかを調べ、その結果を次回のSEA関西&RxTstudyの勉強会で紹介するつもりです。

まとめ

具体的な計画をする際に現れる制約をモデル化せずにクラスを作ったり、枠組みを作っても上手くいきません。その状態で頑張れば頑張るほど、大事な事が個人に閉じてしまいます。

今回紹介したパタンランゲージのアイデアは、過去の経験を元にプロセスを構築する方法です。チケットをうまく利用する事で、プロジェクトに適したプロセスを構築できると思います。

【告知】
すでに募集している次回のRxTstudyの講演内容を変更し、上記のような考え方とチケットの関係を説明するつもりです。ぜひ、ご参加ください。

第65回 SEA関西プロセス分科会&RxTStudy #15 「チケット管理システムによるプロセス支援と今後の課題」 (07月30日) https://rxtstudy.doorkeeper.jp/events/44608

このエントリーをはてなブックマークに追加

WFかアジャイルではなく、将来のソフトウェア開発を考えてみた

未だにネットワークの世界では、アジャイル開発だとかウォーターフォール(WF)開発だとか騒がれていますが、プロセスはそんな単純なものではありません。

それぞれに得意分野があり、現在の多くのプロジェクトに効果的な選択ができるでしょう。 それぞれでどんな工夫をしているかはとても参考になりますが、どちらで成功しているから他方はだめだとか、どちらで自分が不幸なのかを語っても他の分野では役立ちません。

そこで、ソフトウェア開発の流れを考えて、未来の予想をしてみます。今の現場にとってふさわしいプロセスは、将来のソフトウェア開発にふさわしいとは限りません。でも、将来に向けて今から検討しておけば、いつか役に立つと思います。

厳格なウォーターフォール(WF)開発

そもそものWFは、大規模なソフトウェアを開発する方法として生まれました。大規模なソフトウェアでは全体が混乱したり、仕様変更により肥大化しがちで、予定の期日や予算で完成しなかったからです。

そこで、計画を重視して進捗を見える化しました。工程という考え方を導入して分割統治が図られ、各工程でのドキュメントを中心とした成果物や、信頼性を中心とした品質のメトリクスを管理する事で下流工程での混乱を防ごうとしました。

批判対象になっているWFはこのようなプロセスだと思いますが、巨大な一つのシステムを開発する際には一定の成果をあげてきました。

アジャイル開発の登場

20世紀末になるころには、計算機の性能向上、ネットワーク機能、オブジェクト指向を中心としたソフトウェア開発技術の向上によって、短期間、多機能、広い意味の分散処理、多様なシステムが実現可能になりました。

開発の環境や対象が変わるに伴い、従来の様に一度に大きなものを作る事が避けられる様になりました([#TiDD] 最近のソフトウェアを考えるとアジャイルに向かう)。

ボトムアップに実装を積み上げていくアジャイル開発は、リスクを低減する方法として、自社開発企業やユーザビリティを重視する一般ユーザ向けソフトウェア開発に利用されました。

現実的なWF開発

アジャイル開発が生まれる遥か前から、厳格なWF開発が実施不可能な現場では、最適化が行われました。具体的には、工程の完了の前に次工程を開始する、仕様変更の管理を柔軟にする、プロトタイピングによりリスクを低減する、段階リリースする、などです。

このように現実に最適化された開発は、スコープを可変にするアジャイル開発になかなか移行できません。特に決められた期限までに最低限必要な「一式」の機能を実現しないといけない業務システムではその傾向があると思います。

現実的なWF開発では仕様変更に柔軟に対応するほか、請負開発ですので請負側が瑕疵担保責任を持つ事で、発注側のリスクを減らすことができます。決められた期間に必要な「一式」の機能を実装するには有利な方法です。

その反面、納期が迫ってからの仕様変更には残業や増員による対応が必要で、開発者の負担は大きくなります。批判は当然ですが、このような開発が少なくなる事はあっても、発注側にメリットがある間は無くなりはしないでしょう。

近未来の小規模ソフトウェア開発

近未来の小規模ソフトウェア開発は、以下を想定しています。

  • 生産性が高く、高機能なソフトウェアを少ない工数で開発できる
  • 少人数でチームが構成され、開発期間も短い
  • 高度に自動化され、短時間でデプロイできる

生産性が極端に高くなると継続的にバージョンアップする環境に追随する事が難しくなり、アルゴリズムを「どのように実現するか」と考える時間よりも、最新の環境で「実現できるか」を確認する時間の方が長くなります。

リスクが高くなると請負では高価になりすぎるので、顧客にとって準委任契約の方が安価に望みのソフトウェアを得られる可能性が高くなります。準委任契約だと発注側と受注側で契約範囲の議論は少なくなり、要望を満たせる良いソフトウェアについて前向きな議論が容易になるでしょう。

その一方で準委任契約だったとしても、従来のプロセスと前提が異なるので見直しが必要になります。

近未来の大規模ソフトウェア開発

一方でこれまで規模や予算の関係で実現できなかった大規模開発も行われる様になります。クラウドで支援されたアーキテクチャを利用して、システムのスケーラビリティや分割統治が実現できる様になります。

しかし、それは管理的視点での分割ではなく、技術的視点、つまりアーキテクチャー中心の分割になります。アーキテクチャ設計が先行して行われますので、実装プロセスはともかく、プロセス全体では段階的(WF型)になります。

このような開発の特徴は「一式」の機能を一度に揃える事です。しかし、実装時のリスクはドンドン高まりますので、ある程度は実装を優先した開発になってくるでしょう。

近未来はスクラムが難しくなる

準委任開発が増えるならアジャイル開発、今ならスクラムの導入が増えそうなものですが、アジャイル開発の「考え方」と「やり方」は利用するもののアジャイル開発とは似て非なるものになると思います。

私もNode-REDの開発をして近未来感を感じていますが、新規性の高い開発ではアジャイル、特にスクラムはうまくいかないと感じています。具体的には以下のような理由です。

変更を早く反映したい:アジャイル開発では開発者が集中を維持するために、イテレーションやスプリントと呼ばれる繰り返し開発のタイムボックス中の仕様変更から守られています。しかし、技術的な問題は関連する作業の継続を難しくしますし、短期間・少人数の開発では問題は即座に解決する必要があります。

ロールモデルよりも関係者の協調が必要になる:少人数での開発では小さな問題が全体に影響します。ロールを分けて開発メンバーを守るよりも、お互いに協力して知恵をだしあうことが求められます。また、そもそもロールを兼務するようでは組織パターンを利用している意味はあまりありません。

増員も時には必要:チームビルディグは重要ですが、期限の限られた仕事では増員が必要な事や、フェーズによって減員が必要な事もあります。そこでチーム単独でなく、同じ分野のチーム間で人をプールしたり、情報共有する仕組みが必要になります。

近未来のソフトウェア開発の難しさ

近未来のソフトウェア開発を考えると、厳格なWFもアジャイル開発も厳しいものがあります。開発者に負担にはなりますが、現実的なWFが今あるなかでは柔軟にさえ思えます。

そもそもWFは肥大化しない様に外側から束縛し、アジャイルは骨組みを作って肉付けをチームビルディングに任せている事から、現実の問題にプロセスで対応することを直接支援していません。

小規模開発は工数増加による被害も小さいので、これまであまり注目されてきませんでした。しかし、近未来には実装の単位がドンドン小さくなり、品質を維持しながら現実の問題を解決できる実施方法が必要となるでしょう。
(参考:クリティカルチェーンの定義から小規模プロジェクトの難しさを考える

近未来のソフトウェアプロセス

建築の世界では大規模で無機質な開発の後に、無秩序な小規模開発が増えて、魅力的な街づくりが難しくなりました。そこでパターンランゲージが注目され、関係者が集まって現実の問題回避に必要な具体的な解決パターンを導き出し、それらと実際の制約を元に現実的なプロジェクトランゲージを構成し、魅力的な街づくりをする方法がとられています。

ソフトウェア開発もこれまでの様に良いプラクティスを全てやるのではなく、関係者で現実をふりかえり、品質を維持するための制約、チームビルディング、開発対象の実現方法、リーズナブルな運用の方法をパターン化し、より良いプロセスを構築することで、現実問題を解決できるプロセスが構築できると思います([#TiDD] パタンランゲージで経験を活かしたプロセスを構築する)。

そして、その具体的な情報の収集源としてチケットが有効だと思います。

【告知】
すでに募集している次回のRxTstudyの講演内容を変更し、上記のような考え方とチケットの関係を説明するつもりです。ぜひ、ご参加ください。

第65回 SEA関西プロセス分科会&RxTStudy #15
チケット管理システムによるプロセス支援と今後の課題」 (07月30日)

このエントリーをはてなブックマークに追加


[#TiDD] ビジョンとコミットメントがチケット駆動開発を成功させる

Redmineを導入すれば問題は解決するのでしょうか?それだけではうまくいきません。では、チケット駆動開発を導入すれば良いのでしょうか?それだけでもうまくいきません。ビジョンとコミットメントがチケット駆動開発を成功させるのです!

うまくいく場合もある

いやいや、Redmineを入れるだけ、チケット駆動開発を導入するだけでうまくいく場合もあるでしょう。それは現状の問題が共通認識になっていて、ツール以外の問題やタスク管理以外の問題がない場合です。

たとえば、すでにアジャイル開発をしていて、拠点が分かれたのでタスクボードの代わりにRedmineを導入する場合など。あるいは、障害管理がうまくまわっている組織が新しい分野にチャレンジする場合に、気付いたことを効率よく共有できる様に補完型チケット駆動開発を導入する。といった場合です。

このように問題点が明確な場合は、チーム全体がチケットを中心にまわり、チケットで情報共有が進み、作業が効率化されます。

うなくいかない場合

反対にうまくいかない場合は以下のような状況がある様です。

  • 協力してくれない。チケットを行進してくれない。遅い
  • チケットと現状に差がある、適当。ごまかす
  • 期待した成果が出ない。勉強不足で効率が悪い

その背景には以下の問題が考えられます。

(1) 問題が共有されていない
そもそも何のためにRedmineやチケット駆動開発を導入するのか、目的がわかっていないのではないでしょうか。それがなぜ必要かもわからず、作業の負担増え、ただただやらされ感を感じさせているのではないでしょうか?

(2) 重要性が理解されていない
トレーサビリティやコミュニケーションの向上、あるいはデータ収集の効率化といった目的が共有されていても、その効果をフィードバックしていないなら徐々にいい加減になるでしょう。重要性を理解してもらうには、その効果を示す必要があります。

(3) 導入の段取りが悪い
ツールを導入する場合は新しい作業が負担にならない様に、レクチャーや指導が必要です。理解のないままに、いきなり高度な実施方法は負担が大きくなります。まずは障害管理から初めて、開発の道具になってからタスクの管理をはじめると良いでしょう。

違いはビジョンとコミットメント

コマンドコントロールにしろ、支援型のリーダーシップにしろ、新しい環境を導入する際にやらないといけないことは変わりません。それは、どのような改善がもたらされるか、ビジョンを示すことです。

状況によって、始まりは指示なのかお願いなのかわかりません。しかし、長く継続させるには、そのビジョンは理想のままではなく、結果で示さないといけません。

開発者が効果を実感できるか、明確なフィードバックがなければ、それは余分な作業が増えただけです。

フィードバックは定量的でなくても構いません。「障害対応が早くなったような気がする」「管理作業が楽になった」という感想が聞ければ、それは無駄な作業ではなくなります。前向きな協力が得られるかも知れません。

そして、何よりもコミットメントを得る事が大切です。やらされ感だけの作業は、いい加減になりがちです。

無理な導入は行わず、必要な教育を実施した上で、開発者にメリットのあるところから段階的に実施します。そして、その後も支援や適切なフィードバックを行いましょう。

まとめ

Redmineやチケット駆動開発に限らず、これまでのプロセスを変更する際にはリーダーシップが求められます。それが如何に大切なことであるかビジョンを示し、理解を得ないといけません。

それはソフトウェアを作る場合と同じです。はじめに必要な勉強をした上で、必要に応じて修正やフィードバックを行いながら、より良いプロセスを作り上げていきます。

ゴールの達成にはリーダーは余計なプライドを捨て、チームに期待して、何でもしないといけません。チームを支援することが、リーダーの仕事をセクシーにするのです。

参考:

[#TiDD]ウォーターフォール開発をアダプタブルにする(チケット駆動開発) - SQiP2015チュートリアル -

ピグマリオン効果とリーダーシップとリーダーの心理 - マンガで分かる心療内科14 -

リーダーはショットガン・アクションでボトルネックをなくせ! - マンガで分かる心療内科14 その2 -

求められるリーダー像と羊飼い型リーダーシップ - 「リーダーシップ3.0」の咀嚼 -

支援者としてのリーダー - 「リーダーシップ3.0」を読んで -

チームを守り育てる - セクシーな中間管理職 -

このエントリーをはてなブックマークに追加


求められるリーダー像と羊飼い型リーダーシップ - 「リーダーシップ3.0」の咀嚼 -

なぜリーダーシップやプロセスのことに興味があるかを考えると、自分がうまくいったと思えるプロジェクトを説明したいからです。そんなモデルとして今回は、書籍「リーダーシップ3.0」にも載っていた羊飼い型リーダーシップを考えてみたいと思います。

とはいえ、昔からこのような仕事のやり方をしているかと言うと、必ずしもそうではありません。昔はどちらかと言うと外科医チーム的に隅々に目を行き渡らせてコマンドコントロールしていたように思います。しかし、様々な状況に合わせていくうちに羊飼い型リーダーシップにたどり着いたのです。

コマンドコントロールの限界:規模

実際のところ、うまくいく場合はコマンドコントロールの方が楽です。リーダが概ね予想できる時は、細かなところまで指示できますので、それを管理すれば良いからです。

しかし、規模が大きくなってくると一人では管理できません。そこで、サブチームに分けて、それぞれのサブリーダーに自分の代わりにコマンドコントロールを任せることになります。

こうなるとコマンドコントロールの良さは少なくなります。コマンドコントロールはリーダーの判断で直接コントロールできる機敏さがメリットだったのに、各チーム間で調整が必要になって、全体の動きが鈍くなるからです。

コマンドコントロールの限界:変化

また、あまりにも変化が激しい場合、コマンドコントロールには限界があります。リーダーによってコントロールされるので、リーダーの判断がチームの判断になるからです。

そこで、チャレンジングな仕事の場合は手分けをして調査をする必要がありますが、それをうまく集約できないとリーダーは判断できなくなります。

効率化するには権限を委譲して一定の判断をしてもらってから集約することになるのですが、ビジョンが明確でないとバラバラな結論になってしまいます。

コマンドコントロールの限界:カリスマ性

そこで、全体を調和させる目的でカリスマ性が求められます。その分野に長けた人がビジョンを示すことで、全体に一貫性を持たせるのです。

この方法はカリスマ的に活動できる間はうまくいくでしょう。成功のポイントは中長期の社会の変化に対して、適切に情報収集して対応できるかどうかということになります。

カリスマ性を発揮して豪腕を発揮すればするほど、下の人間は従順になりがちです。反対意見が通りにくいので意見が上がりにくくなり、世の中の変化に対応できなくなる可能性があります。

求められるリーダー像

ここまでの流れを考えると、リーダーがボトルネックになっていることがわかります。リーダーは負担を減らし、方向性を示すと共に、意見を集約しないといけません。

もちろん、規模や先進性、社会の動向などによって求められるリーダーシップ像は異なります。しかし、小規模で多機能なソフトウェアを技術の進歩が激しい基盤上で、社会の変化に対応させるには、従来のコマンドコントロールは難しくなっています。

そこで、求められるリーダーシップは以下のようなものです。

  • 権限を委譲して自律的な行動を促す
  • ビジョンを示してチームを導く
  • 意見を出し易くしてコミュニケーションをはかる

これは、経験的にうまくいくと思っています。ボトルネックになることなく、リーダーの能力を超えたプロジェクトを成功に導きます。そして、サーバントは革命の言葉。ビジョンを示せ! - サーバントリーダシップ私論 -に書いた様に、自分の思い通りのソフトウェアではありませんが、自分も含めてチームの持てる力を最大限に発揮して、大きな喜びが得られます。

これまで、このようなリーダーシップはサーバントリーダーシップだけだと思っていました。しかし、羊飼い型リーダーシップがより説明が容易だと思います。

羊飼い型リーダーシップ

羊飼いは羊を飼う仕事です。羊の群れをえさ場に連れて行ったり、柵の中に入れるには群れになる習性を利用して、先頭になる羊を後ろから行かせたい方向に導きます。

羊飼いは前面に立つことは少ないですが、その行動は積極的です。危険な状況では、杖で羊をつついたりもしますし(リーダーは背後から指揮をとり、 「集合天才」を活用せよ:要無料登録)、一人で導くことが難しい場合は、牧羊犬にあたるコンサルなども使います。

(羊飼い型リーダーシップの説明では書かれていませんが、実際の羊飼いは餌を持って先導することもある様です。なんでもするということでしょう。)

羊と羊飼い

羊というのは恐がりでまとまって行動しますが、山羊は行動的で木に登って樹皮を食べたりします。そのためか終末論では、神様が良い羊と悪い山羊に分けると言われています。

また善き羊飼いというたとえがあって、1匹の羊がはぐれたら、99匹の羊を置いて、命がけでその1匹を探し出すとされています。(参考:Wikipedia

つまり、羊飼い型リーダーシップには、性善説に基づいて、一人一人と向き合って導くイメージが暗黙のうちにあると思います。

おわりに

書籍「リーダーシップ3.0」(支援者としてのリーダー - 「リーダーシップ3.0」を読んで -)に示されている歴史を自分なりに書きました。この業界に入って以来、ソフトウェアはドンドン複雑に、かつ、小規模になり、技術や社会の変化も激しくなりました。そのような変化に対応できるのは、ビジョンを見据えつつも各人が成長し、それぞれの能力を最大限に発揮できる組織です。

羊飼い型リーダーシップは、チームにビジョンを示しつつ後方から導きます。チームが成長する様に支援するだけでなく、危険な状況では様々な手段を講じて羊を守ります。チームはビジョンと自律的な行動によって、ゴールを達成できるでしょう。

以前、サーバントの歴史を追いました(古くて新しいサーバントリーダシップ)が、羊飼いはなんと紀元前5000年からある様です。7000年間熟成されたリーダーシップが、きっと新しい時代を切り開いてくれると思います。

このエントリーをはてなブックマークに追加


[#TiDD] チケット駆動開発のパタンランゲージを作りたい

あけましておめでとうございます。年初にあたって夢を書きたいと思います。

モチベーション

2009年からチケット駆動開発のブログ記事を書いていますが、未だに具体的な実施方法を体系的にお話ができません。

もちろん [#TiDD] チケット駆動開発の「ライトウィング」と「レフトウィング」 の様な概念的なお話はできますし、書籍チケット駆動開発に書いたようなプロジェクトの状況にあわせたテーラリングの方法などは説明できます。

しかし、アジャイル開発ではタスクカードをチケットにするとか、ウォータフォール開発ではWBSをチケットにしたり、備忘録としてチケットを使う、というようにベースのプロセスが必要です。

このため、チケット駆動開発を実施するには、現状の問題点を明らかにした上で、その現場にふさわしい実施方法を決める必要がありました。

標準化の問題点

普通に考えれば、成功したプロジェクトを参考に標準プロセスを定める事になるでしょう。標準化すれば、そのプロセスを理解して、過去の問題を改善し、管理し、ツールによる実行や支援が可能になるでしょう。

その反面、教条主義に落ち入り易く、チームは考える事をやめて、ルールを守る事がゴールになってしまいます。底上げはできるものの、目指すべき自分たちで考えて改善する文化を育てにくくなってしまいます。

チケット駆動開発にはたくさんの利用方法があり、様々な問題が解決可能です。多くの人たちが、自分たちで考えて、工夫する事で、開発をよりよいものにしているのです。固定化を目的とした標準化はちょっと違う様に思いました。

プラクティスだけでもない

そこで、過去の経験に基づいてプラクティスを集めれば良いと考えました。“No ticket, No commit!”のようなプラクティスを揃えておけば、それらを組み合わせてソフトウェア開発が実践できるからです。

チケット駆動開発のプラクティスが示されることで、議論が容易になりました。「 “No ticket, No commit!”は実施してますが、 “No ticket, No work!”は実施していません。」といった感じです。

しかし、共通化してパターンを抜き出したものは参考になるものの、どのように自分たちのプロセスを構成すれば良いかは現場の工夫に任されたままでした。

パタンランゲージに期待するもの

そこで、パタンランゲージなら標準化と多様性のバランスが取れるのではないかと期待しています。

パターンというとあたり前の繰り返しの様に考えてしまいますが、心からの良い変革を示します(美しさは変化の中にある - パタンランゲージ - #agileto2015)。単調な建物が延々と並んでいると飽きてしまいますが、途中に講演があり、並木があり、木漏れ日があったなら、良い心地がするでしょう。そのような変革です。

それは単独で存在するのではなく、様々なレベルのパターンがあり、それらが組み合わさって、心地よい風景を表すものです。([#agileto2014] コーディネートは全体で - Agile Tour Osaka 2014「パタン特集」 -)。

このようにパタンランゲージがランゲージであるのは、心に響く様々な言葉を紡ぎ合わせて良い小説が構成される様に、様々な心地よいパタンを組み合わせて、全体が構成されるからです。

プロジェクトが始まろうとするとき、様々なイメージをするでしょう。ソフトウェアの事、お客様とのやり取り、チーム作り、メンバー間の情報共有、などなど、様々な視点と様々なレベルでプロジェクトを考えて、プロジェクトの準備を進めていきます。

単なるプラクティスとしてチケット駆動開発を利用するのではなく、心地よい変革としてチケット駆動開発を様々なレベルで取り入れ、それらをうまくつなぎ合わせる事でプロセスを構成していく。そんなことをはじめていきたいと思っています。

参考リンク

[#TiDD] プロセスプログラミング1 - ソフトウェアプロセスもソフトウェアである -
[#TiDD] プロセスプログラミング2 - ウォーターフォールとアジャイル -
[#TiDD] プロセスプログラミング3(改) - ファシリテーション -
[#TiDD] プロセスプログラミング4 - チケット駆動開発 -

標準化のトレードオフ その1 -  標準化のパターン -

標準化のトレードオフ その2 - 本当に狼男ですか? -
標準化のトレードオフ その3 - 応用のできない習熟 -
標準化のトレードオフ その4 - 慣性の法則 -
標準化のトレードオフ その5 - 従来法と改善 -
標準化のトレードオフ その6 - スクラムの形式知が大切な理由 -
標準化のトレードオフ その7 - リーンソフトウェア開発の考える仕組み -
[#TiDD] 標準化のトレードオフ その8 - チケット駆動開発はソリューションライブラリ -

[#TiDD] プロセスモデリングにおけるチケット駆動開発の可能性
[#TiDD] プロセスモデリングの課題からチケット駆動開発を考える - きょうわたしたちに救い主が生まれた -
[#TiDD]失敗しないチケット駆動開発 - プロセスモデリングの視点から+告知 -
[#TiDD] チケット駆動開発の3要素
[#TiDD] アダプタブルな開発を実現するチケット駆動の3要素

このエントリーをはてなブックマークに追加


[#redmineT] 裾野が広がるRedmine「チケット駆動開発導入のヒント - 自律と規律 -」

redmine.tokyo 第9回勉強会で発表させていただきました。

今回の勉強会は入門的な内容だったこともあり、80名を超える方に参加していただけました。そのうち初めての方の比率が高く、懇親会には約1/3の方が参加されました。

以前、Redmineはキャズムを超える - redmine.tokyoに参加して -と書きましたが、本当に裾野が広がってきた様に思います。

これまではRedmineの利用方法にはAsIsとToBeの2つのの進め方があると説明してきましたが、講演をしていると導入時点で失敗している相談を受ける事が多くありました。そこで、プロセス改善やPDCAサイクルと管理者・開発者の利益の視点から導入方法のヒントを説明しました。

うなずいてくださる方も多かったのですが、Tweetでの反応で予想外のものもありました。「ピンチはチャンス」というタイトルでプロジェクトが大変でどうしようもない時に導入すると良いと説明したのですが、「無理だ」という反応がありました。

プロセス改善は効果が見込めるから実施するもので、効果がないなら導入してはいけません。みんなが頑張る方が効率的に乗り切れるなら、そうすべきです。

ピンチのときにチケット駆動開発をして効果があるのは、何をすべきか見えていないので気付いた事を共有するとか、混乱の原因がコミュニケーションや情報共有にある場合です。そのような問題をチーム全体で共有して、負担よりもメリットが大きい場合のみ導入すべきです。

そのような注意書きがなかったので、嫌な経験をした方には納得できなかったのでしょう(もし、私の過去の発表がきっかけになっていたらごめんなさい)。

なお、スライド中で参照している乗松さんのスライドのPDFはここ(Jaspic)です。

追加でお話しした日本Redmineユーザグループ発起人会のスライドのPDFはここに置きました。

これまでも東京はredmine.tokyoと大阪にはRxTstudyというコミュニティがありましたが、日本全体のユーザの場をつくりたいと思っています。Facebookのグループや、地方での普及協力、開発者への支援など夢は広がりますが、先ずは有志で集まりませんか?というお話をしました。

ご興味のある方はPDFをご覧の上、Twitter (@sakaba37) などでご連絡ください。

このエントリーをはてなブックマークに追加


[#TiDD]ウォーターフォール開発をアダプタブルにする(チケット駆動開発) - SQiP2015チュートリアル -

ソフトウェア品質シンポジウム(SQiP)2015の併設チュートリアルであきぴーさんと講演をしてきました。

一人当たり2時間の講演でしたので、これまでの講演のベストチョイス3本を再構成したものに、アダプタブルウォーターフォールの講演を組み合わせました。

アダプタブルウォーターフォールの講演では、問題の多いウォータフォール型開発を変化に対応できる方法として、補完型チケット駆動開発を中心にウォーターフォール型開発をアダプタブルにする3+1Ultimate Agile Stories Iteration 5に寄稿した記事に書いた内容を説明しました。

質問を受けた内容を総合すると、比較的大規模なプロジェクトに完全型チケット駆動開発を導入してみたものの、チケットを更新してくれない、管理が大変、といった問題で皆さん困られている様です。

やはりチケット駆動開発の導入はプロセスを改善する作業なのですから、管理の都合でルールを導入するのではなく、障害管理、補完型チケット駆動開発と段階的に導入を進めていき、現場がメリットを感じる形で進めていくこと、小規模な単位に分割して管理をすることが大切だと思いました。

ウォーターフォール型開発における完全型チケット駆動開発に関しては、いずれまとめたいと思います。

このエントリーをはてなブックマークに追加


続きを読む "[#TiDD]ウォーターフォール開発をアダプタブルにする(チケット駆動開発) - SQiP2015チュートリアル -" »

[#redmine] Remineを活かしたプロセス支援 - 失敗しないプロセス支援 - #rxtstudy

RxTStudy #13で「Redmine再入門 〜達人に学ぶRedmineの徹底指南〜」と題して、お話をしてきました。

今回は Redmine再入門ということでしたので、チケット駆動開発でどのような点に注意すれば良いかをお話ししました。

説明会は開くべきか

パネルディスカッションでは、モデレータのあきぴーさんの質問に対する議論の形で進められました。中でも気になったのは、Redmineの導入時に説明会が必要かどうかです。

説明会が必要だとする方が多かったのですが、何のためにRedmineを導入するかによると思います。たぶん、大きなプロジェクトや組織の中にRedmineを導入するような想定なのでしょう。

この場合、Redmineに期待するのは、障害管理などの管理作業をRedmineに移行して効率化をはかると言う目的なのでしょうね。情報共有がリアルタイムになり、プロジェクトがうまくいく算段なのでしょう。

説明会の功罪

説明会を開くと知識の底上げと共通化ができます。Redmineの使い方やルールを知る事で、一定の知識を持つ事ができるほか、運用ルールを徹底する事ができます。

説明会を開くと、「こういう時はどうすれば良いですか?」と積極的な質問が出るでしょう。良い事です。

このような大人数の説明会では、質問は出ても改善案はなかなか出ないでしょう。もし出ても「こうして下さい」と共通ルールに従う事をお願いすることになるでしょう。仕方ありません。管理のための導入なのですから、、

Redmineをチーム作りに使う

Redmineには、もう一つの使い方があります。「チーム作り」です。チームで気付きを共有し、作業を共有し、同じゴールを共有して行動します。いわゆる自律的組織です。

多くの人は教えられると考えるのをやめます。その方が楽だからです。ならば、基本的なルールをWikiに書いておいて、問題のある時だけ指導してはどうでしょう。

Wikiに書かれている事を理解して、考えないと行動できませんん。なぜそのようにしているかを考えて、より良い提案が出てくるかも知れません。

管理のあり方

Redmineを管理に使うととても便利ですが、自律的なチームの可能性を押さえてしまいますし、工事進行基準では様々な問題があります([#TiDD] チケットのエクセル連携は工事進行基準と相性が悪い)。

より外乱に強いプロジェクトを実現するには、管理者は組織パターンの「門番」として外界とのインタフェースをとると良いと思います。コミュニケーションの視点でチケット駆動開発を考える事が自律的なチーム作りには重要だと思います([#TiDD] チケット駆動開発による「ソフトウェア開発の現場力向上」を終えて)。

このエントリーをはてなブックマークに追加


より以前の記事一覧