無料ブログはココログ

[#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の寄稿

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


Jenkins、Chef、Redmine、Dockerで業務効率アップ 10倍速の開発・運用ツール(日経BPムック)

「プロセスやツールよりも…」と言いますが、ツールが無いとやってられなかったり、そもそも実現できない事もあります。日経SYSTEMSは、そんなツールに関しての記事が多い雑誌だと思います。

2012年12月月号から2015年3月号までの日経SYSTEMSに掲載されたJenkins、Chef、Redmine、Dockerの記事をムックにまとめたのが、この「Jenkins、Chef、Redmine、Dockerで業務効率アップ 10倍速の開発・運用ツール (日経BPムック) 」です。

なぜ10倍速なのかは気になるところですが、これらのツールを使えば、今までよりも高速に、簡単に、間違いなく、実行できることは間違いないでしょう。個人的にはDockerの勉強をしたいと思っています。

このムックには去年の10・11月号に寄稿したRedmineの記事が載っています。主要な機能を紹介したほか、チケット駆動開発にも触れていますので、是非お読みください。

しかし、最近の出版業界は変わりましたね。雑誌だけで利益を上げるのではなく、

  • 記事をまとめてムックにする
  • 電子書籍にする
  • イベントを開催する

という感じで、アニメがDVDやゲームを含めて利益を出す様に、メディアミックス的な動きが当然の様です。

すでに電子書籍なら誰でも出版できる時代になってしまいました。出版社は編集の質が高いというものの、それ以外の+αをあわせた総合力がないと厳しいのでしょうね。

ソフトウェア産業も、ソフトウェア、システム、運用、トレーニングなど、様々なサービスができないと厳しい時代になりました。

この本を読んで、少しでも早めにツールを活用して競争力を高めたいと思います。

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


ソフトウェアと制約と自由 - 「納品」をなくせばうまくいくを読んで -

倉貫さんの「納品」をなくせばうまくいく を読み終えました。

この本に示されている「納品のない受託開発」は単に技術をあわせただけでなく、
イノベーションの原型である シュムペーターの新結合遂行の例(イノベーションに背を向け続けた研究開発)だと思いました。読み進めるにつれて、アジャイルをはじめとする技術(ARC)との関係、ビジネスモデル、対象マーケット、営業力、ソフトウェアの特性、について、色々と考えさせられました。

ARCとの関係

本を読む前に少し書きましたが、倉貫さんの考えは、リーンスタートアップ、アジャイル開発、DevOpsといった考え方と繋がっています。かつて倉貫さんはARC(Agile, Ruby, Cloud)という技術的な視点で語られていましたが、これが、「納品のない受託開発」の技術、組織、ビジネスと繋がっていると思います。

技術
組織
ビジネス
Agile
段階的に開発することで無駄なく開発できる
顧客と協調した自己組織化を実現する
リーンスタートアップにより新しいマーケットを創造する
Ruby
少ない工数で多機能なソフトウェアが構築でき、フィードバックが得易い 技術指向の人を集めることができ、相互学習の場を作ることが容易
早い段階から顧客に価値を提供し、スモールスタートできる
Cloud
やり直し容易で、小さく失敗できる
ネットワークの利用が前提の組織を構築できる
スモールスタートが可能で、必要な分だけ払えば良い

ビジネスモデル

「納品のない受託開発」はARCがベースになっていますが、それだけなら納品と関係なく実現できます。特に五月雨ウォーターフォールなら結構良い感じで無駄をなくすことができますし、準委任契約なら顧客と対立することも少ないでしょう。

また、月額定額というモデルは書籍中に出てくるSaaSに限らず、昔からある保守契約や永和システムマネジメントさんの「価値創造契約」(終了時の利用条件と休止が異なる?)もあります。

「納品のない受託開発」の特徴は、月額定額という表面的なビジネスモデルではなく、ターゲットとするマーケットが新しい点だと思います。

対象のマーケット

「納品のない受託開発」ターゲットは新規ビジネスです。しかも、大規模投資が必要なビジネスではなく、リーンスタートアップが向いている小さく始められるビジネスです。

ソフトウェア開発は昔からの大規模化の流れのほか、1990年代から小規模化が始まっています。規模がドンドン小さくなり、最後に行き着くところの一つが「納品のない受託開発」で実現するオールラウンドなエンジニアによる小規模開発かもしれません。

単に小規模であるなら景気の影響を受けてしまいますが、新規ビジネスですので不景気なときほど重視されるソフトウェア開発です。規模の大きさを狙わず、社会を替えていく小規模に狙いを定めたスーパーニッチのマーケットです。

営業力

「納品のない受託開発」は、マーケティングはしても営業しないとされています。情報発信が人を集め(情報を得るには Give & Give)、効果的なマーケティングになる。まるで、コミュニティのような営業戦略です。

この方法は新しいマーケットには効果的だと思います。いずれにしろ情報を伝える必要があるので、情報発信をインターネットで行い、興味を持つ人を集め、営業することなく、問い合わせのみに対応する。飛び入りに比べて非常に効果的です。

これができるのは、倉貫さんが率いられているからでしょう。その情報発信力は大きな営業力になっていると思います。会社を大きくする必要はなくとも、次の倉貫さんが生まれるかどうかがマーケット継続の課題で、問題が顕在化する前に後継者を得るか、社会的な認知を受ける必要があると思いました。

ソフトウェアの特性

「ソフトウェア」はハードウェアの対比から生まれた言葉です。ハードウェアでもプログラミングは可能ですが、ソフトウェアで実現することでシステムが柔軟になります。

しかし、ソフトウェアはその柔軟性が故に、一定の制約がないと混乱してしまいます。スパゲティプログラムに対する構造化プログラミングのほか、ドキュメントやプロセスの標準化も混乱を避けるための制約の一つでしょう。

しかし、単純で教条的なウォーターフォールによる固定的な制約の与え方は、 ソフトウェアの特性を奪い、柔軟な開発を難しくする、あるいはより混乱させる、と言う事態を招きます。

そこで、アジャイル開発では、繰り返し単にであるイテレーション中は原則的に仕様を凍結する代わりに、イテレーション毎に仕様の見直しを許して、ソフトウェアの特性を生かすような制約を与えました。

このような開発法で、Ruby on Railsのような強力なフレームワークを用いると、イテレーション毎に価値をユーザに提供できるようになるので、適切なフィードバックを得易くなります。

ここで、Ruby on Railsはソフトウェアに対する制約で、まつもとさんの言われる
ある種の制約は自由を増やす」 状態になっていると思いました。

最後に

私もエンジニアですので、ぼんやりと独立を考えたこともあります。その際のネックが、営業力、技術力、資本力、でした。

倉貫さんの「納品のない受託開発」は、これらをコミュニティ的な方法、Ruby、クラウドとリーンスタートアップ、によって解決されました。さらに、新しいマーケットを開拓することで、新結合を遂行し、社会の変革を始められたと思います。

あえて限界を考えるなら、上に挙げた倉貫さん個人に依存する限界のほか、Railsの限界、規模の限界だと思います。

Rubyコミュニティも活発で、新しい技術が継続的に出てくると考えられることから、その限界は遠いのかもしれません。もし、「納品のない受託開発」に関わる中から、色々な支援が行われたなら、限界はさらに遠のき未来が広がるかもしれません。

規模の限界は、一定の体制が必要になる場合(「納品」をなくさなくてもうまくいく)です。しかし、初めから大きな体制が必要な場合は、それを支援するフレームワークが支援してくれないなら手を出さないのだと思います。

問題となるのは、初めは小さく始めたのに、ユーザの増加によって体制が大きくなる場合だと思います。たぶん、この場合は小さなコンポーネントの組合せで実現することで分割統治するか、不可能な場合は他の業者への引き継ぎをして顧客の卒業を支援されるのでしょう。

いずれにしろ、新しいマーケットを開発し、社会の構造変革の一端を担われることになると思います。そこには多くの可能性と、いくつかの課題があると思います。

それは「どのような制約を与えればソフトウェアの特性を生かすことができるか」という大きな社会実験でもあると思います。「納品のない受託開発」がどのように発展していくか、とても楽しみにしています。

おまけ

かつて倉貫さんが大阪に来られて、リーンスタートアップの勉強会が行われました(ちょっとだけ関係する記事:リーンを考える - 無駄と必要なアソビ - )。

その時に、「ビジネスになることは考えることができるが、それを事業にすべきかどうかわからない」と質問しました。それに対して「そのビジネスを通して何を実現しようとしているか、ビジョンが大切です」といった主旨の回答をいただきました。

ビジネスでも仕事でも、そのこと自身ではなく、それを通して何を実現するかが大切だと思います。この本に書かれたビジョンはとても良心的で技術者の理想の姿です。

「納品のない受託開発」があたり前のビジネスの一つになることを期待すると共に、「納品のない受託開発」でなくてもその理想の実現を目指したいと思いました。

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


日本でスクラムを実践するなら読んでおきたい本(SCRUM BOOT CAMP THE BOOK)

アジャイル開発が話題になって10年以上が経ちました。しかし、この本が登場するまではどこかしっくりこないところがあって、日本ではあまり普及してきませんでした。

ア ジャイル開発では開発者が中心で、自ら進んでタスクを選んでコミットします。それぞれのメンバーがプロジェクト全体を見渡して、ワイワイと見積もり、助け 合いながら実践し、定時になったら帰宅する。そんな理想的なソフトウェア開発の姿を見聞きして、多くの人が夢を見たと思います。しかし、いざ社内を見渡す とシャイな人も居たりして、いきなりアジャイルをやれと言われても困ってしまうというのが現実ではないでしょうか?

この本は日本の現場でどのように実践するかが書かれた本です。スクラムマスターを任された主人公のボク君を中心にお話が進んでいきます。社内で初めてのスクラムプロジェクトなので、プロダクトオーナーやメンバーも初心者です。そして、その中にはシャイなバッチ君もいます。

こ のバッチ君は自信なげに「僕なんかでいいですか?」と言います。いかにもありそうな、日本の現場です。イベントや勉強会で見聞きする、アジャイルの有名人 による理想的なプレゼンからはイメージしにくい現実です。このバッチ君がストーリーに存在することで、この本で説明されているスクラム開発が、理論でなく 現実のものとしてイメージできるものになってます。

この本はマンガのストーリーを中心に関連する多くのノウハウを説明する構成になってい ます。示されているノウハウは大量でメインのストーリーよりも多いですが、マンガで流れが読み取れるのでとても読み易くなっています。もし、ストーリーも 文章ならもっと読みづらい本になっていたと思われますが、マンガと文章のコントラストによって知識の少ない人でもストーリーを見失う事なく読み勧められる ようになってます。

ソフトウェア開発を実践するには多くのノウハウが必要で、プロジェクトをリアルにイメージできないとうまくいきません。この本は、これからスクラムを始めようとする人には、ぜひとも読んでいただきたい本だと思います。

(アマゾンのレビューからの転載)


工夫が凝らされたSCRUM BOOT CAMP THE BOOKの構成

SCRUM BOOT CAMP THE BOOK は読み易くて内容が濃い本です。マンガによるストーリーを活用した従来の技術書にはない構成によって実現できたのだと思います。

従来の技術書

技術書にも色々ありますが、記事や論文を束ねた書籍を除くと、用語の説明方法で大きく3種類に分けられると思います。

入門書
本を初めから読むと理解できる様に、順序だてて説明されています。説明されてない用語が突然出てこない様に工夫されていますが、概要と詳細などで同じ用語がなんども説明される事があります。説明順序が工夫されているだけなので必ずしも内容が薄い訳ではなく、「〔改訂〕Trac入門 」のように案外濃い内容が載っているものもあります。

中級書
ある程度詳しい説明をする場合、あらかじめ用語を説明しておく方が説明が容易になります。そこで、導入部でなるべく多くの用語を説明しておきます。それでも不十分な場合は脚注で別のページへのリンクを示したり、説明を補うなどします。「Redmineによるタスクマネジメント実践技法 」は「プロになるためのWeb技術入門」を参考に中級書を意識して書いています。

上級書
さらに色々な事を説明したい場合は、同じ脚注を何度も書けないので、用語集としてまとめます。このようにしておくと、用語の説明に左右されず全体を構成できるほか、特定の場所だけを読み直した際にもあちこち読まなくても、読みたいところと必要に応じて用語集を見れば良いようになります。

チケット駆動開発 」は前作でかけなかった内容をより多く書く目的で、20世紀に多かったこのような専門書を意識して書いています(なので図が少ない、読みにくい、色々書きすぎ、などと言われても困っていたりします)。

このほかいずれの場合でも、全体の流れを乱してしまうような内容を書きたい場合は、コラム(囲み記事)として分離する、逆引きができる様に索引を付ける、といった工夫をします。

「SCRUM BOOT CAMP THE BOOK」はマンガに気を取られて入門書だと思ってしまいがちですが、初めに吉羽さんの解説がある事から、中級書の構成になっていますし、読み応えのあるコラムや一覧し易い索引があり、なかなか良くできています。

マンガによるストーリー

「SCRUM BOOT CAMP THE BOOK」は全体のストーリーをマンガで構成し、関連する説明を比較的多めの文章で補っています。一見、文章がメインでマンガを挿絵の代わりだと思ってしまいがちですが、中級書の脚注が複数ページになったと考える事もできます。そう考えるとやはり中級書と言えるでしょう。

ストーリーで技術を説明するとイメージがわかり易くなる事から、これまでも多くの本で採用されています。たとえば「アジャイルと規律 」では TSPとXPの比較に利用されていますが、部分的なものです。また「バグがないプログラムのつくり方」は全体をストーリーで構成していますが、文章のみで構成している入門書です。

「SCRUM BOOT CAMP THE BOOK」はマンガでストーリーを示しているので、解説の文章との対比が明確になっています。この効果で、ストーリーに引っ張られずに、実践的な情報をふんだんに取り入れても違和感を感じない構成になっています。

まとめ

技術書以外の既存の本で考えると、「クッキングパパ」や「酒のほそ道」のコミックなど料理マンガのレシピを増やしたイメージとも考えられますし、かつての「科学と学習」や小学館の学習雑誌の付録似ついてきたマンガをベースにした解説本のようにも感じます。

これらの本は内容が濃いものの、楽しく読めるという特徴があります。クッキングパパではレシピの最後に「おいしいぞ!」と語りかけられると、ついつい作ってみようかという気持ちになります。マンガは雰囲気が伝え易く、親しみ易いので、より多くの情報を伝える事ができるのでしょうね。

アジャイル開発もいよいよ本格的な普及期に入ったと思います。これからは原則に則った方法だけでなく、より現実的で実践的な情報が必要とされるでしょう。

この本の様に様々な工夫が凝らされた本が増え、ソフトウェア業界が健全に発展する事を期待しています。


SCRUM BOOT CAMP THE BOOKからの学び

Bootcamp

ようやく読み終えたので、内容の感想を書きます。この本は、とても読み応えがありました。特にシーン20以降は実践的で、経験の少ない方にはぜひ読んでいただきたい内容でした。

マンガが載っているので入門書だと思って読むと、実践的なノウハウがたくさん詰まっていてきっと驚かれるでしょう(これには構成による効果が大きいのですが、それは別に書く事にします)。

この本はスクラムと書名に入っていますが、スクラムの内容はスクラムを始める際に必要なものに限定しています。その反面、必要な内容はスクラムでないことも載っていることは、以前書いた通りです。

この本には3つの大切な事にたくさんのページを割いています。

準備
インセプションデッキや見積もりなど、開発を始める前にする事が多く書かれています。アジャイル開発は実装優先のはずですがなかなか開発が始まらず、1/3が準備に割かれています。

確認
インセプションデッキから、スプリント計画ミーティング、スプリントレビュー、そのほか全てが常に確認・改善されながらお話が進んでいきます。透明化によって問題を見える化し、確認する事が大切なのだと思いました。

タイムボックス
この本の中で、「プロジェクトの先を見通すために、タイムボックスは必要なんだ」と力説されているのがタイムボックスです。ベロシティをきちんと測定するには、タイムボックスを守らないと行けません。

これは、スプリント計画ミーティング、スプリントレビュー、スプリントレトロスペクティブ(ふりかえり)の比率を一手に保つためにも必要な事でしょう。また、本には書かれていませんが、チームのリズムを守り、効率的な開発を維持すると言う側面もあると思います。

スクラムは「アジャイル開発とスクラム 」にあるように、オブジェクト指向から考えられたプロセスです。カプセル化のモチーフになったとも言われる小さな細胞の組み合によって実現される大きな生命体の様に、確実なプロセスを積み上げないといけません。

そのようなスクラム開発だからこそ、きちんと準備され、確認され、タイムボックスできちんと管理されたプロセスが必要なのでしょう。そしてそのような開発を通じた実践的な「学び」を続ける事が、本当の意味の「守破離」の道なのだと思いました。


使えるアジャイル開発の本 - SCRUM BOOT CAMP THE BOOK とプロセス -

ソフトウェア開発プロセスの定義は色々ありますが、モデルとして考えるなら

  「選択的なタスクの集合」

だと思っています。特定のやり方を強制するのではなく、状況に応じて対応できないといけないと思っているからです。

これまでのアジャイル開発の本は仕組みや考え方のの解説が多く、多様性があまり無い物が多かったと思います。 SCRUM BOOT CAMP THE BOOKはスクラムで不足している内容を補っているだけではなく、多様性を与える事で使えるアジャイル開発の本であると思います。

守破離の危険性

CMMブームの際に議論になったのはレベル3(定義されたれレベル)の壁です。CMMで考える良いプロセスは、定量的で管理され(レベル4)、常に最適化される(レベル5)プロセスです。

しかし実際は、段階モデルに従ってレベルを達成していくと、レベル3でとどまる事が多いと議論されていました。これはレベルの達成に時間がかかって疲弊してしまうだけではなく、「ルールだから守れ」というトップダウン的な強制が思考停止を招くからだと思います。

アジャイル開発に置いても同じ事が起こりうると思います。それぞれのチームがルールだからと何も考えずに実践していれば、改善の考え方や仕組みが組み込まれていても、いずれおざなりになるからです。

ワークショップの危険性

ワークショップは特定の技術を体感して身につけるには効果的です。しかし、体験した印象があまりにも強く、講師が複数の選択肢を示していても記憶に残るのは唯一の経験でしょう。

これは開発の現場でも良く起きる事です。一度、プロジェクトで成功すると前提条件が変わっても同じ方法をとり続けて失敗するというパターンがあります。このような状況を避けるには、書籍や他の開発者との交流などで、より多くの判断可能な知識を得ておく事が重要です。

どのように考えてリリーススプリントの実施を決めるかなど、この本の様に示されていれば、現在のチームの状況を見定めた上で実施方法を判断する事ができるでしょう。

業務の開発では失敗できない

UltimateAgileStories iteration2のアジャイル放談で細谷さんが語られた様に、トラブルが発生した場合、ウォーターフォールは対策方法がわかっていてそれなりに鎮火できますが、アジャイル開発はその解決方法がこなれておらず、とんでもない事になると思います。

[#TiDD] チケット駆動開発で気付いたアジャイル開発の仕組みで書いた様に、私も過去にアジャイル開発で失敗していてうまくリカバリーできませんでした。この時は研究開発だったので失敗も経験のうちと考えられましたが、お客様の業務をになうシステムなら、大きな失敗はゆるされません。

プロジェクトを成功させるには、プロジェクトのゴールを明確にするだけでなく、リスクを明確にして対策を講じておかなければいけません。そのためには、プロジェクトがイメージでき、いざという時のために複数の手駒を用意しておかなければいけません。

設計時に複数のアーキテクチャを健闘した上で判断した方がより良いソフトウェアが実現できる様に、プロセスプログラミングにおいても、複数の方法を健闘した上で実践する方がうまくいくのです。

お客様の業務開発を考えたとき、ようやく使えるアジャイル開発の本が登場したと思いました。


日本文化に仕立て直した実践書 - SCRUM BOOT CAMP THE BOOK の意義 -

「 SCRUM BOOT CAMP THE BOOK」をじっくりと読んでいます。まだ1/3ほどしか読めていませんが、読み終わると今の思いだけでなく、別の事が書きたくなって収拾がつかないと思うので、一旦、感想を書いておきます。

結論から書くと、この本は欧米文化をベースに作られたスクラムを、日本人に合わせて見事に仕立て直しています。どのように実践すべきか、スクラムに不足しているところを補いながら、日本人が実践できる様に説明している良い本だと思います。

欧米の文化を考える

以前「スクラムを味方につけろ! - SEA関西プロセス分科会 -」と言う記事で「スクラムは敵か味方か」という不安を書いていましたが、「アジャイル開発とスクラム」とこの本を読んでいて、その背景にあるのはキリスト教的な欧米文化にあると思いました。もちろん、単純に述べられるものではないと思いますが、聖書から透けて見えるのは以下のような内容です。

契約文化

「新約聖書」と言いますが、新約の「約」は契約の「約」で、翻訳の「訳」ではありません。天国に行くには契約を守れば十分です。海外では仕事を頼んでも「その仕事は私の仕事ではありません」と断られてしまうことがあるそうですが、契約がすべての基本であるという文化的背景があると思います。

聖書の「善いサマリア人」(ルカ10・25-37)では博愛が説かれているのですが、それは「人にしてもらいたいと思うことは何でも、あなたがたも人にしなさい」(ルカ6・31、日本聖書協会 新共同訳)と考えるからで、気を利かせたり会社のためという感覚ではないと思われます。

このような契約文化があるので、価値観や考え方だけでなく「仕組み」としてプロセスを作り上げる必要があると思います。

能力の発揮が義務

タレントの語源になったと言われる「『タラントン』のたとえ 」(マタイ25・14-30)というものがあり、自分の能力を発揮しないといけません。

日本では指示されるとか、そういう雰囲気でなないと、自ら進んでコミットしない人が少なからずいます。しかし、欧米では信仰上、能力を発揮しないと天国に行けないので、進んでコミットメントするのが当然と考えられます(もちろん、例外もおられるでしょう)。

サーバントリーダーシップ

以前、アジャイル開発への壁は価値観の壁という記事に書いた様に上に立つ人は、仕える者のようになりなさい。」(ルカ22・26、日本聖書協会 新共同訳)という聖書の言葉があり、上の人間がメンバーが能力を発揮できる様に考える事が当然とされています。

日本では偉くなると人を使うものだと考えて、上司が細々と指示を出して、下の人がそれに従うイメージがあります。欧米でウォーターフォールがうまくいかず、日本ではある程度うまくいったのは、このような背景があるのかもしれません。

CMMをふりかえって

CMMも日本を含めて世界的に行われていた管理が先にあり、クロスビーの研究をベースに形式化されたと考えられます。CMMを導入した企業によっては、日本的な管理をベースに、改善がうまくいっていたのに破壊されたと言う意見を聞いた事があります。

標準になるとその方が優れている様に考えてしまいがちです。しかし、それが自分たちにとって必要なものであるか、そのまま受け入れて良いものか、良く見極める必要があると思います。

アジャイル開発とスクラム」では、オリジナルスクラムでの考え方がアジャイルスクラムでどのような仕組みにマッピングされているかを解説されていました。しかし、それはあくまでも仕組みです。そのような仕組みで前提にしている価値観についてはあまり書かれていませんでした。

スクラムを日本人向けに仕立て直す

「SCRUM BOOT CAMP THE BOOK」はアジャイルスクラムの前提である欧米文化を解説するのではなく、日本人がスクラムを実践するならどうすれば良いかと言う事が書かれています。

そこで、見え隠れするのは日本的なチームの一体感です。和辻哲郎氏の「自他不二」と言う言葉に示される様に、日本人は「場」において一体の仲間だと感じます。単なる互恵関係ではなく、互いを気遣い、助け合える関係です。

この本は、スクラムの仕組みを利用しつつ、このような日本文化を活かして、チームにどのように文化を構築するかが書かれていると思います。

それは、遠藤周作が当時のキリスト教に居心地の悪さを感じ、著作を通して日本人向けのキリスト教観を構築した様子に似ています。その著作は日本だけでなく、世界でも読まれています。特に「沈黙」はセンセーショナルで、日本だけでなく様々な国の言葉に翻訳されました。

「SCRUM BOOT CAMP THE BOOK」によって日本人にふさわしい形でスクラムが広がり、その文化がふたたび世界に広がる。そんな夢を抱きつつ、この本を読み進めたいと思います。


壁を打ち破れ! - アジャイル開発とスクラムを読んで -

良書と呼ばれるものには、メッセージ性の強いもの、入門でありながら深いところまでかたるもの、網羅性の高いもの、色々な読み方ができるもの、など色々なパターンがあると思います。

この本は、「おわりに」にある様に「実践知リーダーシップ」というメッセージを中心に書かれていますが、基本から実践までが語られていて、色々な読み方ができます。著者らの思いとは少しずれているかもしれませんが、感じたままに感想を書かせていただきたいと思います。

私が感じたのは「実践知リーダーシップ」に必要な共同化を実現する「壁を打ち破る」ことが大切だと言う事です。この本を読み出したとき、「そもそもアジャイルとは何か」「スクラムでないとできない事は何か」など、ついつい曖昧になりがちな言葉の定義ではなく、そこで大切にされているものを知りたいと思いました。

オリジナルスクラムと壁

この本はアジャイルスクラム開発の本と言うよりは、事例やオリジナルのスクラムを通してアジャイルスクラムを見直している本だと思います。野中さんがオリジナルのスクラムの解説とそのアジャイルスクラムのマッピングをされていますが、所々、気になるところが出ています。

もちろん、アジャイルスクラムを応援されていますが、それよりも大切なものがオリジナルのスクラムにある様に思いました。それが、壁を打ち破り、知識を共同化し、 実践知リーダーシップ を発揮する事だと思います。

最初に「壁」が出てきたのはセールスフォース・ドット・コムの事例です。アジャイル開発の説明でありながら、この事例は組織の壁(p.24)を取り除いたのでうまくいったと思います。また、リクルートの事例でも組織の壁について語られています。

この壁と言うものは、ソフトウェア開発の最大の敵です。タスクカードを貼って情報を共有する場合には、壁はとても魅力的です。しかし、ステークホルダーの間に立ちはだかった場合には、プロジェクトの透明性が失われ、コミュニケーションが阻害され、対立構造が生まれてしまいます。

壁の経験

この本を読んで、壁の経験を思い出しました。

私は若い頃から複数のメーカーさんの仕事を何度かさせていただいています。そこでは、ハードとソフト、最近ではインテリジェントな周辺機器とメインの機器など複数のソフトウェアが並行に開発されています。

そのような場合、スクラム・オブ・スクラムというか、軽量化された五月雨ウォーターフォール開発・オブ・スクラム、とでも言うようなリーダーミーティングが行われています。これは、リーダーが実践知を持って互いにコミュニケーションをはかり、各チームに深く入り込んでいればうまくいきます。

特にある程度こなれた環境の場合は、スタブやシミュレータがあって、インターフェースのトラブルも限定されたものになります。しかし、新規にインタフェースを作る時には、よほど注意深く開発を進めないとうまくいきません。

以前、どうもあやしいと感じるプロジェクトがありました。その時はあるチームの責任を持つ立場でしたが、リーダーミーティング的な集まりはお客様の担当者が出られていました。出てくる資料や話からは詰めの甘いところが感じられました。

そこで、担当者の方に「このままでは無理です」と宣言しました(後から聞くと同僚は強気な発言に驚いた様です)。通常なら、Q&Aなどを通じて詳細を詰めていくのでしょうが、期間や内容を考えるとリスクが高過ぎました。そこで、お客様とお話しして他のチームとの合同のミーティングをしていただきました。壁を打ち破った瞬間でした。

オブジェクト指向だけでは堅すぎる

この本を読んでいると、アジャイルスクラムはオブジェクト指向開発をする上で、従来のやり方では難しいのでオブジェクト指向的な組織構造を作った(P.221)というジェフ・サザーランドさんのお話が載っています。

チームをカプセル化し、スクラムマスターがプロダクトオーナーとのメッセージを受け取る仕組みです。大規模化する際にはスクラムマスター同士が集まるチームを構成し、スクラム・オブ・スクラムを実現します。

しかし、オブジェクト指向がやりにくい場合に、アスペクトやミックスインをしたくなる様に、チームがうまく守られれば守られるほど、やりにくくなる可能性があります。

富士通の事例(P.173)では、朝会と夕会のそれぞれをチーム毎と全体の2回ずつ行っていますし、野中さんも「チームの外部への知識の伝達については未だ多くが語られていない」(P.217)とされています。

要求開発のコタツモデルのようにチームを越えて知識を共同化するには、「壁を打ち破る」事が必要なのだと思いました。

チケット駆動開発の壁

著者の平鍋さんはアナログ大好きな方の様です。この本の中でも遠隔地とは最初は同じ場所で始める、skypeを常につないでおく、といったお話が出てきます。とても参考になります。

チケット駆動開発は作業の中心にITSなどのチケットシステムを置いて、それに依存して常に見る様にする事で、アナログのタスクボードのような効果が得られます。

この時に注意しないと行けないのは、それだけではうまくいかない事を認識する事です。本に書かれた方法や、必要に応じて通信方法を選択する事も大切です。

RxTstudyなどの勉強会で議論していて良く出るのは

  • 議論が長引いて面倒な時は電話などで直接話をしてまとめをチケットに残す

と言う方法です。ありがちな説明では「手段が目的化」しないようにという説明になりますが、これもチケット駆動開発という方法の壁を打ち破ってコミュニケーションをすることと言えると思います。

この本で壁を打ち破ろう

アジャイルスクラムはオリジナルスクラムに比べで、ソフトウェアに最適化した非常に良くできたパッケージだと思います。しかし、チームの壁を超えた組織的な活動はこれからです。

これがあれば万全と言う銀の弾丸は未だにありません。ソフトウェア開発を担う私たちは、現実の問題に合わせてどのようにプロデュースし、どのようにパッケージングするか、常に求められています。この本はその時のヒントになる良書だと思います。


リーダーに求められる大切な事 - 100人のプロが選んだソフトウェア開発の名著 -

今回、公開するのは「100人のプロが選んだソフトウェア開発の名著 君のために選んだ1冊」という本に寄稿させていただいたハンフリーさんの「TSPガイドブック:リーダー編 (IT Architects'Archive)」という本の紹介文の全文です。

これまで、[#devsumibook] 誰もが本を読んで学んできた「100人のプロが選んだソフトウェア開発の名著 君のために選んだ1冊」と言う記事で本を紹介し、アジャイル開発への壁は価値観の壁という記事で一部を抜粋して思うところを書いてきました。

最近、アジャイル開発やチケット駆動開発について考えています。その中で、私の考えのベースはやはりこの本だと思いましたので、全文を公開します(構成前の原文を元に体裁を整えました)。

みなさまのご参考になれば幸いです。

ちなみに「100人のプロが選んだソフトウェア開発の名著 君のために選んだ1冊」に関してしては、shimashimaさんのslashdotの書評(その1その2)が興味深いです。取り上げていただいてありがとうございました。


より以前の記事一覧