Visual IoT 開発ツール Node-RED が盛り上がってきた - 新刊2冊 -

IoTって言うけれど、ハードウェアの情報を収集したり、サーバーを構築するのは結構面倒でした。そこに現れたのが  Visual IoT 開発ツール Node-RED です。

Node-RED は以下のような特徴を持ちます。

• Node.jsの非同期処理をVisualに、しかも簡単に扱える
• ハードウェア接続や通信など標準モジュール（ノード）が豊富
• 多くのソフトウェアがcontribute されている。中でもdashboardを利用すれば、テスト用のUIが簡単に作れる

そんな、Node-REDの書籍が2017年夏以降に2冊出版されました。しかも良く書けていてお勧めです。

【１】つないで つないで プログラミング Node-REDでつくる初めてのアプリ

基本的な操作だけで半分のページが使われ、ユーザーズマニュアルの様に丁寧に書かれていています。

このブログでもNode-REDを紹介してますが、ここまでは詳しく書けません。まわりにユーザがいない方には頼りになる存在でしょう。

【２】はじめてのNode‐RED

はじめてのと書かれていますが、バランス良く書けた入門書です。初めての方でも、Node-REDらしいプログラムを楽しみながら読めると思います。

Node-REDの日本語情報を提供しているNode-REDユーザグループジャパンhttps://nodered.jp/執筆とあって、興味を惹く内容が色々と乗っています。

一見、おもちゃの様に見えるNode-REDですが、実際に使ってみると、高機能なソフトウェアを簡単に書くことができて驚きます。良い本が2冊も発売されて、いよいよ本格普及が始まりそうです。

決定をできるだけ遅らせる -「現場で役立つシステム設計の原則」深読み -

増田さんの「現場で役立つシステム設計の原則」に関して様々な議論があり、私も立食とコース料理 -「現場で役立つシステム設計の原則」批判の一考察 -を書いたあと、様々な議論をさせていただきました。私なりの本の読み方が見えてきたのでまとめておきます。

この本はアジャイル開発（以下アジャイル）がベースになっていると思います。特にリーンソフトウェア開発のプラクティスである「 決定をできるだけ遅らせる」（リーンを考える - 無駄と必要なアソビ -） の考え方が透けて見えます。

この考え方は上流工程をもつ従来の開発方法（ウォーターフォールと呼ぶとリリースが１回とか工程間で判定会議がいるとされることもあるのでこう表現します、以下、従来法）とは大きく異なる考え方です。

従来法の考え方

従来法で上流が重視されます。これは、ベーム先生の後工程になると修正工数が指数的に増えると発表されたからです（「要求は変化する。Boehm は間違っていた、と DeMarco が暴いた。」というYourdon のブログ：An Agile Way：オルタナティブ・ブログ）。後工程になれば修正が大変だからと上流工程で頑張ることで、開発のリスクを減らそうとした訳です。

話はそれますが、ベーム先生はその後の繰り返し開発やアジャイル開発につながるスパイラルモデル（リンク先はWikipedia）を提唱されたり、後述の「アジャイルと規律」を執筆されるなどアジャイル開発に貢献もされています。IEEE Softwareの紙面でケント・ベックさんとXPについて議論されていたので、からかわれたのじゃないでしょうか。

決定をできるだけ遅らせる

話を戻して「決定をできるだけ遅らせる」というのはYAGNI(You aren't gonna need it)に通じる考え方です。従来法とは逆に、変更の可能性を考慮して、どうしても決めないといけない時（最終責任時点）まで決定遅らせるというプラクティスです。

例えば車のドアのところのデザインがかわる可能性がある場合、ドア部分の金型を削ってしまわずに少し残しておくといった対処で、後から変更が生じた際に調整できるように決定を遅らせるというプラクティスです。すべての事を決定しておかずに余裕を持たす事で、選択肢を残せます。

従来法のソフトウェア開発に置いても、決めきれない内容はペンディング、TBD、TODOなどといって後回しにしたり、手軽な方式に仮決めしておきますよね。それを時間切れだからとあきらめてするのではなく、変更の可能性を意識して選択肢を残す目的で実施するようなイメージです。こうすることで多大な手戻りのリスクを減らします。

「現場で役立つシステム設計の原則」の深読み

このような視点で読むと、仮決めする際のデフォルトが示されているように思います。オブジェクト指向はこう理解して、こう言う風に考えるとうまくいく、短いイテレーションも乗り切れるよ。という風に読めてきます。

上記は私の勝手な忖度ですが、増田さんの講演資料にある批判に対する回答を読むと、増田さん自身も決定を遅らせる考え方をもたれていることがわかります（現場で役立つシステム設計の原則）。

この５ページの「すべてのカラムが Not Null は非現実的？」に対して「実際にやっている、特に困っていない、SQL のスキル＋ IDE サポート」という回答からも、決定を遅らせるスタンスが感じられます。

批判を考える

このように考えた上で、この本に対して書かれている批判を考えると、とても良い指摘ではあるものの、「決定をできるだけ遅らせる」こととと対極にある「はじめのうちからしっかり作る」ことを勧められている様に思います。

もちろんリスクを減らす目的で決定をできるだけ遅らせているのであり、「はじめのうちからしっかり作る/設計する」方がリスクが減るのであれば、実施すべきでしょう。

kent4989さんのブログ勘と経験と読経でその方法が紹介されていました（アジャイルとデータモデル、DB進化設計のこと）。アジャイルにこだわるならイテレーションゼロで吸収する。それ以外なら前段階で供給開発、あるいは、RUPなどの反復開発手法の併用を勧められています。最近ではたなかこういちさんが、アジャイルでスタートアップも、軌道に乗ったらUPへ移行すべきときが来る、というものかもしれないと言われています。

2017/9/8追記：
アジャイルにこだわる方法としてFDD(リンク先はWikipedia)もあります。
（[#Agile] FDDはアジャイル開発、ハイブリッドアジャイルは、、
[#TiDD] 手分けするより助け合い - FDDとチケット駆動開発 - ）

2017/9/14追記：
この本の特徴の一つは決定を遅らせる際のシンプルなデフォルトを示していることです。イテレーション（スプリント）をうまく回せるか不安だった方や、ベロシティ（開発速度）が上がらなくて困っていた方には、大いに参考になるでしょう。

その方法は独特です。批判の多くは一般的な方法を主張し、その良さを指摘したものです。批判の実践はこの本に書かれたシンプルさを損ないますので、どちらを優先すべきか良く判断すべきだと思います。

もし、批判を読んで今までの開発が不十分で問題だったと思われるなら、批判は一部だけを示したものですので、より広く検討して上述の実施方法などを検討する必要があるでしょう。

アジャイルにこだわるかの判断

批判を別にしてもアジャイルにこだわるべきかどうかは考えておく必要があります。平鍋さんのブログデータモデリングなきアジャイル開発は危ういか？では、プロジェクトや製品の文脈によって変わるとされていますし、上述のたなかこういちさんのブログでも「バックオフィス側の管理業務」など業務が大きな要素であることは間違いないと思います。

一方、ベーム先生の「アジャイルと規律」ではアジャイルの５つの重要要因として、規模、重要度、 変化の度合いといった業務に関わる要員のほか、人、文化が挙げられています。

人に依る違い

設計に関して渡辺さんが「システム設計と創造性」の中で“まずは「システムが扱う現実の全体をぼやーっと理解する」ことを目指せばよい”とされていて、私もそうしています。

しかし、ふと思い出すと小学生のことです。私は作文の時間の半分以上をあーでもない、こーでもないと書く内容を考えていました。成績は悪くはなかったのですが、私よりもできる人の中には、作文の時間にすぐに書き出す人もいました。設計でも同じ様に人によって作りながらの方がうまくいく人がいるかも知れません。

そう思うと、書籍アジャイルサムライに

誰もがこの働き方を気に入るわけじゃない

— アジャイルサムライbot (@agile_s_jp_bot) 2017年10月2日

と書かれていたことが設計にも言えるのではないかと思います。

おわりに

増田さんの本に関しては、上記のような視点でとても興味深く読ませていただきました。できれば、続編あるいは改訂版のような形で、アジャイルとリファクタリングによる進化のさせ方について、もっと書いていただければと思っています。

なお、個人的なアジャイル開発に関する考えは、[#Agile] アジャイル開発の課題と対策 その1に書いています。現場でスクラムやXPの様なタイムボックス型管理をしているアジャイル開発はしていませんが、いわゆるモダンアジャイルを実践しているつもりです。

2017/9/8追記：

決定を遅らせるってのは、ファウラーはアーキテクチャの中心的な役割としている。アジャイルだからというより、OOにおけるソフトウェア設計ってそういうものなのでは？という理解。https://t.co/uJnLvoJUwK

— 松下正嗣 (@masatsugumatsus) 2017年10月7日

アジャイルマニュフェストはオブジェクト指向の有名人が集まって決めたので、なるほどと思いました、サブタイトルからもオブジェクト指向からの説明の方がしっくりくるかも知れません（私には書けませんが）。

これに関連して「アジャイルプロセスでは、本質的なデザインやアーキテクチャに関する意思決定をできるだけ遅らせることができます。」というマーチン・ファウラー氏の言葉を見つけてニワトリとタマゴの関係だと思いました。

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

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

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

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

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

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

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

---

UAS5の寄稿

UAS5 アジャイル開発に学んだアダプタブルウォーターフォール開発 from Makoto SAKAI

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

---

UAS4の寄稿

うまくいくチケット駆動開発 - リーンとリファクタリング - from Makoto SAKAI

---

UAS3の寄稿

アジャイルの夢を実現する–チケット駆動開発で考慮すべき点 from Makoto SAKAI

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

---

UAS2の寄稿

アジャイル風の開発で集中を実現する from Makoto SAKAI

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

---

UAS1の寄稿

チケット駆動開発はアジャイル1次ブームの夢を見る from Makoto SAKAI

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の記事が載っています。主要な機能を紹介したほか、チケット駆動開発にも触れていますので、是非お読みください。

Redmineはキャズムを超える －日経SYSTEMS寄稿の思い－ from Makoto SAKAI

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

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

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

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

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

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

[#Redmine #TiDD] 日経SYSTEMSにRedmineの紹介記事を寄稿しました

現在発売中の日経SYSTEMS 2014年10月号と11月号に寄稿しました。

「現場でホントに役立つツール ＰＭ・運用編」のRedmineの回です。10月号は障害管理を中心にRedmineの基本的な使い方を、11月号はタスク管理とチケット駆動開発、プラグイン、REST APIとスマホクライアント、メール連携を説明しました。

紙面の都合で全体にかなり端折って説明しましたがページが足りなくなり、用意したまとめが入らなくなってしまいました。せっかく書いたものですし、謝辞もなくなってしまって申し訳ないので、11月号のまとめを一部修正して公開します。興味を持たれましたら、大手書店等でお買い求めください。

---

Redmineのより進んだ使い方として、タスク管理ではガントチャートでRedmineの構造を、チケット駆動開発ではプロジェクトの状況に合わせた４つの方法を説明しました。また、プラグインやAPIなどRedmineの機能拡張や外部連携についても説明しました。


Redmineを導入する場合、全体の効率化と組織文化を育てることのバランスがポイントになります。Redmineはプロジェクトの情報を一元管理するリポジトリです。障害情報やバージョン管理ツールの情報など、開発に関連する様々なデータをチケットやWikiに紐付けることで、情報共有が効率化されます。

しかし、それが旗ふり役の独りよがりであったり、Redmine導入の負担でモチベーションが下がって、開発効率が下がるようでは意味がありません。プロジェクトの関係者全員が、自分の問題として検討して、プロジェクトの状況を改善していく文化を醸成できれば、より多くの効果が得られるでしょう。


今回紹介したRedmineの使い方はごく一部です。ソフトウェア開発以外にも、メール対応やIT全般統制(赤羽根さんの論文、スライド)、受発注管理、創薬、結婚準備にいたるまで、様々な使い方があります。独立行政法人IPAが開発した定量的プロジェクト管理ツールEPM-Xのメトリクスの収集に利用されていて、ソフトウェア工学分野も期待できます。


Redmineはオープンソースソフトウェア(OSS)です。OSSを選択する場合に大切なことは継続性です。そのOSSが継続的にバージョンアップされていることはもちろんですが、中心的な開発者・支援者やユーザ、コミュニティ、周辺のソフトウェアやサービスが存在しているかも重要です。


Redmineは開発言語のRubyやフレームワークのRuby on Railsの大きなバージョンアップを乗り越えて、継続的に開発されています。また、SaaS、プラグイン、クライアントなど、有料のサービスやソフトウェアも増えています。

もちろん、ユーザも増え続けていてコミュニティも活発です。東京にはredmine.tokyo(旧品川Redmine、facebook、Twitter)、大阪にはRxTstudy(Redmineやタスク管理を考える勉強会@大阪、facebook、Twitter)というコミュニティがあります。


この記事でもこれらのコミュニティで教えていただいた内容も多く、 末筆ながら感謝の意を表します。

---

なお、今回の寄稿のねらいについて、2014年11月15日(土)開催のredmine.tokyo 第７回勉強会でLTさせていただきます。ご興味のある方はご参加ください。

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

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

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

ARCとの関係

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

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

ビジネスモデル

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

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

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

対象のマーケット

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

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

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

営業力

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

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

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

ソフトウェアの特性

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

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

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

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

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

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

最後に

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

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

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

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

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

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

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

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

おまけ

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

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

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

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

IMPACT MAPPING - 戦略を共有する言葉 -

ソフトウェアは多くの利害関係者間のコミュニケーションから生まれる。コミュニケーションには言葉が用いられるので、どのような言葉を用いるかでソフトウェア開発の成否が決まる。

従来の方法

実装優先で作れば良いと思われる方もおられるかもしれない。しかし、この本のまえがきにこうある。

「動くソフトウェア」はユーザーストーリを確認する事はできても、問題の発見と選択には大して役に立たない。

実装やその前段階のモデリングは戦略の合意が得られた後のイメージ共有には有効だが、戦略を決めるには重すぎる。必要以上の情報が含まれているからだ。

そこで、従来は用語の統一がおこなわれてきた。構造化分析/設計に始まるデータディクショナリや、DDDのユビキタス言語がそれにあたる。

用語を統一する中でターゲットとするビジネス戦略(WHY)と対象ユーザ(WHO)が共有され、モデルや実装を通じて何を(WHAT)どのように(HOW)作るかが明確になってくる。

指示型コントロールから適応型コントロールへ

一見、正しそうに見える従来のやり方だが、大きな問題がある。ビジネス戦略(WHY)と対象ユーザ(WHO)がすでに明らかでないとうまくいかないからだ。まえがきにはこのように書かれている。

私達は、考え方の大きな転換点に差し掛かっている。(中略)プッシュ型では、人々はやる事を指示される。プル型では、問題や機会を与えられて、部門を超えたチームがその理解と解決に取り組むのだ。 (中略)内発的動機は、自律性、成長、そして目的によってドライブされる。

つまり、ゴールの設定からチームで取り組み、WHY、WHO、HOW、WHATを整理するのである。

効率的な情報共有

では、コミュニケーションに用いられる言葉はどのような構造が良いか？できる人の知識は構造化されているのだから、何らかの構造に整理した方が良いだろう。

従来はスクラムのバックログのように優先順位付きのリストや、派生開発(XDDP)のWhat、Where、Howを示す変更要求仕様書、トレーサビリティ・マトリクス、変更設計書などの表がある。

IMPACT MAPPINGでは、より効率の良いマインドマップの木構造を応用し、中心からWHY、WHO、HOW、WHATを割り当てている(翻訳者のお一人である平鍋さんの記事に詳しく説明されている)。木構造なので構造の見直しが局所化され、アルファ・ベータ法（リンク先はwikipedia）のようにあまり重要でないツリーを対象外にする事も容易である。

本の内容

ここまで、引用部分を除いて私の理解を説明した。せっかくなので内容にも触れておこう。

この本では、上に述べたようなインパクトマップそのものの説明よりもどのように書くか、そして犯し易い間利害について多くのページが割かれている。

準備のステップとしては、本当のゴールを見つける、適切な測定値を定義する、最初のマイルストーンを計画する、チェック、が説明されている。マップを描くステップとしては、骨組みを描く、代替案を見つける、主な有線事項を特定する、「稼ぐ」か「学ぶ」、チェック、が説明されている。

そして、測定値をマップ内に表示する、何度もやっては繰り返す、定期的な計測とチェック、で一連のプロセスが説明されている。これらは、非常にシンプルに説明されており、方法論というよりも手法に対するノウハウ集となっている。

本のデザイン

私とあきぴーさんとの共著チケット駆動開発も手法に対するノウハウ集で、80年代の書籍のような難解さを覚悟して、多様な内容を詰め込んだ。

しかしこの本の場合は、まるで児童書の様にシンプルで明快なデザインでエッセンスだけに絞る方法を選んでいる。図とタイトルをスライドに貼付ければそのまま発表に用いることができるくらいに練られている。

著者や翻訳者らはこのデザインを非常に大切にしているのだろう。適切な訳注は本の後半にまとめられ、全体のデザインを壊さないように工夫されている。

この本にはスキャンタイプの電子版がある。デザインを大切にしているので、それ以外の方法はなかったのだろう。しかし、2段組みの構成中にぶち抜きの図があるので、7-8インチ程度のタブレットでは少しつらいかもしれない。(私には少し字が小さかったが)通常本か、大きめのタブレットの利用をお勧めする。

おわりに

書店で手に取ってシンプルなデザインに、購入をためらう方もおられるだろう。イントロダクションにこう書かれている。

私の狙いは、この手法と関連するアイデアへの関心を喚起し、コミュニティを刺激する事だ。そのため、この本は意図的に短くつくり、すばやく読めるクイックリファレンスとして身近に置けるようにした。

背景に思想を持つ方法論とちがってこの本のように、ある方法のノウハウを集めた本は読み手を選ぶ。人によって価値を感じるところが異なるからである。しかし、それは読み手の成長に応じて、新たな発見があるという事だと思う。

すでにできあがった組織の中では、本書の方法を導入する事は簡単ではないかもしれない。しかし、ビジネスとソフトウェアの関係を考える際に、本書は非常に刺激となるだろう。そのような読者には、この本の薄さが大きなメリットになる。

少なくとも私は、この本に大きな刺激を受けてこの記事を書いた。知識が整理され、また一つ抜けていたピースが埋まったように思った。

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

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

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

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

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

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

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

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

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

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

従来の技術書

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

入門書
本を初めから読むと理解できる様に、順序だてて説明されています。説明されてない用語が突然出てこない様に工夫されていますが、概要と詳細などで同じ用語がなんども説明される事があります。説明順序が工夫されているだけなので必ずしも内容が薄い訳ではなく、「〔改訂〕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からの学び

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

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

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

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

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

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

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

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

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

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