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やゲームを含めて利益を出す様に、メディアミックス的な動きが当然の様です。

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

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

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

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

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

この本に示されている「納品のない受託開発」は単に技術をあわせただけでなく、
イノベーションの原型である シュムペーターの新結合遂行の例（イノベーションに背を向け続けた研究開発）だと思いました。読み進めるにつれて、アジャイルをはじめとする技術(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 は読み易くて内容が濃い本です。マンガによるストーリーを活用した従来の技術書にはない構成によって実現できたのだと思います。

従来の技術書

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

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

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

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

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

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

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

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

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

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

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

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

守破離の危険性

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

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

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

ワークショップの危険性

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

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

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

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

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

[#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」によって日本人にふさわしい形でスクラムが広がり、その文化がふたたび世界に広がる。そんな夢を抱きつつ、この本を読み進めたいと思います。