無料ブログはココログ

アジャイルジャパン大阪サテライト2017の感想

SS2017のポストイベントがなくなったので、 急遽スタッフとして参加しました。


(1)キーノート:シンアジャイル(Joshua Kerievsky)

モダンアジャイルについての説明。タイトルはAgileJapan2017のタイトルにあわせて変更されたようです(シン・ゴジラをまねた?)。

個人的にアジャイル開発のタイムボックス管理は、作業タイミングを固定化するので超短期開発にはフィットしないと思っていました。Kerievsky氏は早くからタイムボックスを守るよりも顧客のメリットを考えようと言われていたそうです(そのとおり!)。

提案する新しい4つの原則は従来のアジャイルマニュフェストに対応しながらも、顧客やソフトウェアの安全性に配慮したものでした。

講演概要
http://www.agilejapan.org/session.html#session01

Agile 2016の基調講演: モダンアジャイル
https://www.infoq.com/jp/news/2016/08/agile2016-modern-agile

チェンジビジョン/英和システム 平鍋さんの説明
https://anagileway.wordpress.com/2016/10/07/modern-agile-jp/


(2)ヴァル研究所 新井さんの講演

アジャイルを社内に広げる際の話。みんなが積極的になるように色々と工夫された中で、権限(部長)があるので、一部の活動が社内評価と連動するようにした。と言われていたので懇親会で質問させていただきました。

質問は、社内の仕組みと連動すると、義務感ややらされ感が出ると思うが、どのようにバランスをとられているか?

答えは、社員には積極的なできる人と、受身の人と両方いて受身の人も働いてもらわないといけない。ルールを決めても相手によって変えている。とのこと。

つまり、ルールはがちがちにせず、運用時に人を見て、たぶんチームによっても変えているのでしょう。エンジニアは、ついつい一貫性が気になりますが、個人個人を良く見ると言うことが重要だと思いました。

ちなみに、「上から見てなので、みんながどう思っているかはわからないですけどね。」と謙虚に言われていたのが印象的でした。


(3)コニカミノルタの久保さんによるエモイ話

人はなぜ生きているのか?それは人生を楽しむためである。

なぜ苦しみがあるのか?それは、いつかより人生を楽しめるからである。

いい人である必要は無い。人の顔色ばかり見る必要は無い。わかってあげるだけでいい。

そう、生きているだけで素晴らしい。

そう思いました。

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

Node-REDから見えた未来 - 変わるもの、変わらないもの - SS2017 WG13

ソフトウェアシンポジウム(SS2017)では、前回紹介した論文発表のほか、ワーキンググループにも参加しました。

ワーキンググループでは各グループのテーマに沿って、参加者がそれぞれのポジションを発表して議論します。私が参加したのはWG13「ソフトウェア開発の現状と今後の発展に向けたディスカッション」で「Node-REDから見えた未来 - 変わるもの、変わらないもの -」を発表しました。

Node-REDは高機能なノード(モジュール)がたくさんあり、それらを組み合わせて高機能なシステムを効率的に開発できます。また、簡単にデバッグできるほか、デプロイが一瞬で、開発から確認の繰り返しを素早く実行できます。

このような環境を使っていると、面倒臭いことがなくなり、ソフトウェア開発に重要な作業を中心に実施する様になります。この重要なことはみなさん合意できますよね。という発表でした。

しかし、Node-REDのデモのインパクトが大きかったのか、Node-REDに対する質問で持ち時間が終わってしまいました。Node-REDを知ってもらえたので、良かったことにしておきます。

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

Visual開発ツールNode-REDの導入によるプロセスの変化と考慮点 - SS2017 -

ソフトウェアシンポジウム2017(SS2017)で経験論文の発表をしてきました。経験論文とは研究論文の様に新規性はないものの、事例報告の様に経験を報告するものですが、問題設定や結果・考察を整理してより有効性や信憑性を高めて論文にまとめたものです。

今回はVisual IoTツールと呼ばれているNode-REDのアンケート結果を報告しました。ソフトウェア開発にツールは欠かせませんが、その導入報告はあまりありません。上流のツールであれば、コンサルタントに依頼することもできるかも知れませんが、下流のツールは小さい規模から始めることが多く、導入経験は他の人にも役に立つと思ったからです。

発表ではNode-REDの基本、長所・短所の説明と共にデモもしました。基本的な Hello World のノードを入れ替えてPathをセットするだけで、そのビジネスロジック(文字列の代入)をそのままWebサービスにできる様子をお見せしました。

このようにNode-REDは確認しながら開発するので短期間に品質の高いソフトウェアを作ることができ、アンケートにもある様に非同期処理が簡単に扱えます。その反面、ある程度の規模になれば、データやアーキテクチャなどの設計をきちんとしておかないと複雑になってしまいます。

そういった知識を持ち、ふさわしいプロセスで開発しないとうまくいかないことがアンケートからわかりました。まとめると

  • ツールの知識やノウハウを共有 する
  • 特性を活かした設計を行う
  • 実装を繰り返して常に確認する
  • 主体的にプロセスを変更し、品質 を上流から作りこむ

となり、これは、モダンアジャイル

  • 人々を尊重する
  • 安全な状態を前提とする
  • 素早い実験と学習
  • 価値を継続的に届ける

の基本理念と対応していて、Node-REDの良い導入が開発のアジリティ(機敏さ)を高めると考えられます。詳しくは以下の論文を読んでください。
(実は最終原稿の段階でモダンアジャイルの基本理念と対応していることに気付いたので追加しました)

Node-REDから見えた未来 - 変わるもの、変わらないもの - SS2017 WG13 につづく

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

複合主キーの扱い方

緊急開催:複合主キーは必須なのか?<第55回IT勉強宴会Light> に参加しました(主催者まとめ)。

議論の発端は渡辺幸三さんの「単独主キー専用環境」と賢くつきあうためにという記事。

乱暴に説明すると「データベースではきちんと複合キーを使うべきだ。OOPだからといってカスケードキーでいい加減に作るから、あとでわからなくなって保守ができなくなるんだ。ばかやろう!」ということ。

ここにはいくつか議論をしないといけないことがあります。一部追記したスライドを元に説明しましょう(追記部分は灰色の小さい文字になっています)。


RDBだから複合キーを使わずにできてしまう

渡辺さんのブログを読んでいると、RDBなのになぜ複合キーを使わないのか、という気持ちが透けて見えます。でも、実は多機能なRDBだから複合キーを使わずにできてしまうのではないでしょうか?

複合主キーを持てないKVSや連想配列があります。これらを使うとき、シーケンスの管理が
難しいこともあり、「キー1_キー2」のようにして開発しています。

このことから考えると、RDBなのに複合主キーを使わないのではなく、RDBだからサロゲートキーを作りやすいので、複合キーを使わない開発が簡単にできてしまうのだと思います。

つまり、単独主キーで開発を安易に行うことが問題です。

本来、複合主キーで表現されるデータをどう扱うかは、モデリングの問題ではなく実装の問題です。

複合主キーを使わないのは実装の都合なので、そこにある危険性を周知することが重要だと思います。

(もちろん、、モデリングしているのはあたり前としてです)


オブジェクト指向だから単一主キーとは限らない

渡辺さんのブログでは「OOP好きからは『テーブルに別途ユニーク制約を置くなり、クラスの中に制約のためのロジックを盛り込むなりすればよいだけではないか』と反論されそうだが、」と書かれていますが、それは時代に流されている人ではないでしょうか?

オブジェクト指向システム分析―上流CASEのためのモデル化手法には「オブジェクトのそれぞれのインスタンスを唯一に識別する1以上の属性の集まりは,そのオブジェクトに対する識別子です。」と複合主キーを認めています。

ソフトウェアを開発する場合、様々な視点で特徴や制約をモデリングしないとシステムの詳細は表現できないと思います。複雑な要素を如何に矛盾なく、いかにわかり易く統合していくかが設計者の腕の見せ所では無いでしょうか。


保守性の考慮

もちろん、実装の都合でモデルと異なる方法をとったり、モデル自体を実装に最適化することもあるでしょう。しかし、その場合は注意深く開発する必要があるでしょう。

渡辺さんのブログには「複合主キーを扱えない」という環境自体の特性ゆえの問題が書かれています。

  • エンティティのまとまりやそれに適用される複雑な制約が、開発者自身によって見い出されない
  • 使いづらく保守しにくい業務システム開発が生まれる
  • 単独主キーだけを用いた設計スタイルに逃げ込んでも、問題が見えにくくなるだけで事態はさらに悪化する

つまり、きちんとモデリングされず、保守しにくいシステムが作られ、どんどん深みにはまってしまいます。

このように考えると、複合主キーを使ったモデルそのままに実装できるならDBを見ればわかるかも知れませんが、モデルと異なる実装ならモデルからどのように実装に持ち込んだかわかる様にしておかないといけないと思います(もちろん、モデリングしている前提です)。


おわりに

渡辺さんの主張をより単純化すると「バグを出すなバカやろう」だと思います。

なぜ、バグが出るか、それは「複合主キー環境でないから」ではないと思います。たぶん、複合主キーが使えても同じようなDB設計をするのではないでしょうか?

もし、きちんとモデリングができるなら、本来必要な制約を理解し、わかり易く制約を実装し、必要ならドキュメントも作成するでしょう。

「もともとDB設計というものは高度な専門職」とは思いません。もし、そうなら、ソフトウェア開発のインタフェース設計、システムチューニング、保守、運用、すべて高度な専門職です。

エンジニアリングは一定の努力で誰もが習得できる専門知識です。きちんと勉強して、危険性を理解すれば良いと思います。

問題はすでにできてしまったお客様のシステムをどうするかです。危険性を考慮せずに勝手な思い込みで作られたやっつけシステムは、問題が起きた際は大変だと思います。作り直したくても予算も期間も無いからです。

担当される方のために祈らずにおられません。

彼らをお赦しください。自分が何をしているのか知らないのです(ルカによる福音書/ 23章 34節、日本聖書協会)

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


考えろ、理解しろ、整理しろ

渡辺幸三さんのブログ:設計者の発言を読んでいて感じたこと。

日々の仕事をする中で口うるさいと思われても、年長者の務めなのできっかけを見つけては指導している。色々と言っているが、だいたい以下の3つに集約できるだろう。

考えろ

指示されたままに仕事をしたり、いつも通りで良いと思っていないだろうか。

渡辺さんの「論理削除」ではなく「無効化」をスタンプ属性や更新履歴テーブルの無駄っぽさを読んでいると、習慣ではなく考えて仕事をすることの重要性を感じる。

より良い方向を考えても、全体との調和の問題で実施できないかもしれない。しかし、きちんと考えてシステムを作り上げることはとても重要だ。次の仕事に活かせるからだ。

なぜかを理解しろ

学部の恩師の言葉で忘れられないのが「職人になるな勉強を続けなさい」という言葉(社内勉強会より社外の勉強会)。知っているだけではなく、きちんと理解していなければ技術者とは言えない。

人に聞いてわかったつもりで仕事に使い、うまくいったらそれでおしまい。それは技術者でも職人でもない。ただの人工(にんく)に過ぎない。

ものごとの原理は何なのか、その人はどうやって情報を知ったのか、広い目で深く理解していれば、自己流ではないより良い方法が選択できるだろう。

整理しろ

世の中のできる人を見ていると、常に考えて仕事をし、より深く理解しているだけでなく、情報を整理してコンパクトに理解している(できる人を観察して勝負する

得た知識はそのままにしておけば忘れてしまうし、量が増えれば大変になる。知識を活かしてステップアップするには、これまでの知識との関連を整理しておく必要がある。

体系化できていればすべてを覚えておく必要はない。どの資料に書いてあるかを知っていれば、いつでも確認できるからだ。経験のインデックスを作るのだ。

おわりに

世の中には新しい情報があふれているが、実は似たような議論を繰り返していることも多い。

渡辺さんの議論も、コードクローン(リンク先は阪大井上研)は全て悪か、より良いバランスはあるのか、と言う議論に見えなくもない(普及しているオープンソースには一定のコードクローンが存在するらしい)。このようにマッピングできるのは、ものごとを考え、理解し、整理しているからである。

ここに挙げた内容は技術者にとって基本的なことであるが、実践は難しい。自分のことはともかく、若者の可能性を信じて意見するのが年長者の務めだと思っている。

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


在庫推移監視方式にみるDOAのアプローチ #benkyoenkai

生産管理再入門-MRPを超えて <第43回IT勉強宴会> に参加しました。

メインの話題は在庫推移監視方式(Stock Projection Monitoring)で、その基本と事例の紹介でした。在庫推移監視方式はMRP(所要量計算)方式がバッチで処理するところを、手作業を前提とする事でリアルタイム処理する方式です。

在庫推移監視方式について

在庫推移監視方式は(1)新たな発注などの入出庫予定の変動があった際に、MRPは、(2)所要量の計算、(3)受払予定の再編成、(4)在庫推移の再計算、(5)推移以上の対応までバッチ行います。

しかし、実際は在庫を見たいだけなのに、(1)の入出庫予定の変動があるたびにバッチを実行しているユーザが多いそうです。そこで在庫推移監視方式は(2)と(3)だけをリアルタイムで行うことで、在庫の状況を確認できる様にしています。

在庫推移監視方式の事例

事例では、受注と発注の担当者を同じ組織にすることで、MRPがルールで行うことを人間によって調整できる様にしています。これによって、ムダに生産や在庫することが無い様に稼働を調整しているそうです。

在庫管理のポイントは、DB設計、方式設計、組織設計、工程負荷だそうですが、 在庫推移監視方式にあわせて組織設計までされたようです。

お話で興味深かったのは、在庫推移監視方式を知って実践したのではなく、実践してからそれが在庫推移監視方式であることに気付いたそうです。GoF本が出た時に「前からやっていた」という人がおられましたが、良いパターンは誰もがたどり着くものなのでしょうね。

そしてそのパターンを見いだして命名された渡辺幸三さんは、生産管理というドメインを極めたスパーエンジニアなのでしょうね。

在庫推移監視方式は方式設計?

在庫推移監視方式は方式設計ではないかということです。ドメイン分析の様に見えながら、実はリアルタイム処理かバッチかという方式まで決めています。

同じような感じは、ライブモデリングの時にもしました。データモデリングのようなのですが、理由を問われると「こんな有力画面を考えているんですよ」と答えられていました。

データモデリングと言いながら、画面設計もある程度できていたのです。DOAは常に実装と繋がっているのだと思います。

DOAのアプローチ

渡辺幸三さんは、ドメイン知識はDDDがいうような汎用的な方法では獲得が難しく、ドメイン専門家にならないといけない、といった主旨のお話をされていました。今回の在庫推移監視方式は専門的な経験があるからこそ、できる事なのでしょう。

DOAのアプローチはどちらかというと業務分析に始まるトップダウンアプローチです。でも、実装がどうなるかを意識していないと動くシステムは作れません。

たぶん、DOAはその溝を業務固有のデザインパターンでつないでいるのだと思います。今回は在庫推移監視方式というパターンでしたが、それ以外にも多くのパターンがあり、その獲得がドメイン専門家になるという事であると思いました。

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


クリティカルチェーンの定義から小規模プロジェクトの難しさを考える

小規模開発の難しさは独特です。これまでも問題点の指摘と解決法が提案されてきました。

改善に書けられる工数が少ない

プロセス改善ブームの前、多くのヨレプロジェクトが予算の2倍を消費していた頃は、会社の存続を左右する大規模開発に比べて被害が少ないので、小規模プロジェクトはあまり関心を持たれませんでした。やがて、大規模プロジェクトが統計的な手法でうまくいくようになると、小規模プロジェクトの被害が無視できなくなりました。

しかし、小規模プロジェクトでは改善の工数を大きく割く事が困難で、標準プロセスを管理する独立したSEPG(Software Engineering Process Group)を作る事も困難です。そこで行われたのは、大規模システムで行われている管理手法の簡素化です。標準プロセスをシンプルにすることと、自律的な改善活動でした(VSEセンター:資料ダウンロード)。

外乱による変動が大きい

しかし、小規模プロジェクトの難しさは、改善の工数が少ないだけではありません。規模が小さいので外乱による影響を受け易いのです。

環境、実現方法、業務ドメインの未知の問題が発覚すると、プロジェクトはその対応に追われます。脆弱性対応など、外乱による問題は規模に関係なく同じように理解と対応が求められますので、知識と経験の蓄積が必要とされます。

増員が難しい

このような問題を認識しても、まだ小規模プロジェクトの難しさの本質を表現できずにいました。先日、CCPM(リンク先はWikipedia)におけるクリティカル・チェーンの定義を見ていて、増員できない事が問題を難しくする事に気付きました。

大規模プロジェクトでは、クリティカルパス法やPERT法のように「作業員を雇用することが容易」という前提を置く事が可能です。しかし、小規模プロジェクトでは

  • 増員によるコスト増加の比率が高い
  • 教育コストの比率が高い
  • 一人分の初心者向け作業を切り出すことが困難

といった理由から、増員が困難です。このことで、「作業工程上の従属関係」だけでなく、クリティカルチェーンの様に「必要リソースが限られているために発生する従属関係」の考慮が必要になります。

リソース制限による難しさ

例えば並行して実行可能な2、3、4人日の作業A、B、C、があった場合、3人で実行すれば最短の4日で完了できますが、メンバーが2人なら最短で5日かかります。これを4.5日でとりあえず動かして欲しいと言われたなら、どのような対応ができるか考えてみましょう。

増員:トレーニングに1日かかるなら、指導1日もかかるので、3、4、4日となって4日で終わらせる事ができる反面、2人日の追加工数が必要です。このようにうまく配員できるかどうかという問題もあります。

手伝い:半日分の作業をもう一人に手伝ってもらえるなら、何とかなりそうです。しかし作業に専門性があるなら、その理解に必要な時間分は、はみ出てしまいます。

共通化:まだまだ上流なら、作業や構造の共通化で何とかなるかもしれません。でも、すでにきちんと設計されていたなら、難しいでしょう。

作業をショートカット:テストを端折ってでもリリースして欲しい。というお話を聞く事もありますが、障害対応に必要な作業で他の作業ができなくなりますので、一番危険な方法です。

後回し:保守用ドキュメントはリリース後に回すなど、作業内容を精査してリリースに必要な作業だけを実施します。リリースの目的が他のモジュールとの結合テストなら、有効な方法かも知れません。

以上の方法を考えると後回しが有効だと思われますが、開発標準に抵触する可能性がありますし、全体の作業内容を良く理解していないと混乱を生じる可能性があります。

残業というバッファ

クリティカルチェーンの正攻法はCCPMのように、あらかじめバッファを確保する事、他の作業からリソースを回す事です。本当に使える開発プロセスで書かれているように、大規模プロジェクトでは理想見積もりの1.5〜2倍の予算を確保してスケジュールがきめられるので、バッファをとれるかもしれません。

しかし、小規模プロジェクトの場合は、発注側が詳細な作業内容を把握しています。このため、理想見積もりを基準に予算が確保され、スケジュールを決められる傾向があります。

そこで小規模プロジェクトでは、残業時間がバッファになりがちです。スケジュールが厳しいからと、あらかじめ残業が見込まれてしまうと、さらに打つ手が限られてしまいます。

小規模プロジェクトの難しさ

そこで、いざとなれば開発標準をよく理解して、顧客との合意が可能な範囲で作業の最適化を行い、優先度の低い作業や手戻りの可能性のある作業を後に回すといった柔軟さが求められる事になります(Win-Winプロセス(ウォータフォール編)追記)。

このような方策は作業のショートカットと紙一重です。作業間の関係を理解した上で、独自のプロセスを構築する。そのようなアクロバティックな難しさが小規模プロジェクトには存在します。

クリティカルチェーンの定義から小規模プロジェクトの難しさを考えてみました。小規模開発では、改善工数の制約や外乱の影響を受け易いほか増員が困難で、クリティカルチェーンの特性であるリソースの制約があります。そこに予算とスケジュールの制約が加わるので、独特の難しさが生じているのだと思います。

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

[#agileto2014] コーディネートは全体で - Agile Tour Osaka 2014「パタン特集」 -

Agile Tour Osaka 2014「パタン特集」に参加しました。

パタン探し

午前中は「@haradakiroと行くパタン探し」というオプション企画で、伊丹の町を歩きながらクリストファー・アレグザンダーのパタンを探しました。

クリストファー・アレグザンダーは建築家で、心地よいと感じるパタンを、町、建物、施行の3レベルにまとめました。たとえば、小さな広場、南向きの屋外、いっぱいに開く窓、というパタンの組み合わせを聞くと、素人の私でもなんとなく良いイメージがわきます。

このようにパタンを体系化したものをパタン・ランゲージと呼びます。クリストファー・アレグザンダーの書籍名についている冠詞は「a」で、本に書かれたものはアレグザンダーが見つけたものであり、他にもパタン・ランゲージは存在するという意味だそうです。

ワークショップ&ディスカッション

懸田さんのワークショップでは、謎のAさんが健康的な生活が取り戻せるように、

  • 力の衝突(フォース)を 明らかにする
  • 解決策とパタンの名前を考える
  • スケールで分類する
  • スケールの異なるパターンを組み合わせて素敵な未来を 描く

といった作業をしました。ここでスケールという概念が出てきて、アレグザンダーが3つのレベルにまとめていた事が思い出されました。

Posauneさんの講演は「テスト自動化のパタンランゲージ」でした。以前聞いた内容でしたが、ワークショップのあとで聞くと、パタンを間連付ける事の重要性を感じると共に、「スケール」のない事が気になりました。

ディスカッションでは小林サンからの午前中の報告のあと、原田サンが登場。

  • パタンとは対立のフォースをそらすもの
  • 良いパタンはあたり前のもの
  • パタンはソリューションカタログではない

というお話がありました。

おわりに

対立するフォースをそらせるパタンを関係付け体系化したものがパタンランゲージです。パタンにはレベルがあり、それらを組み合わせて、何を、なぜ、どのように、作るかを考えます(このように物事の対立を前提に解決する点は、TOCfEに似ていると思いました)。

ソフトウェアでパタンというと、最初に思い出すのはデザインパターンです。でもこれは、実現したいものの一部に過ぎません。実現する際に立ちはだかるフォースを避けてより良いものを実現するには、アーキテクチャや組織のパタンなども組み合わせる必要があります。

ソフトウェアを開発する技術者は「プログラマ」と呼ばれる事が多いですが、ソフトウェアを実現する行為は、プログラミングのレベルを超えたコーディネートだと思います。開発に関わる体制、プロセス、アーキテクチャ、もちろんプログラム、に存在するフォースを利害関係者と調整し、進行し、実践するからです。

それは、対立する課題からよりよい解決策を求める作業です。 パタン・ランゲージの視点で見ると、我々の仕事のゴールは色々なレベルのパタンを組み合わせて、より良いシステムを作り上げる事だと思います。

そこで技術者に求められるのは、より良いソフトウェアを実現できるように、会社間、組織、モチベーション、技術、など複数のレベルのパタンを常に洗練し、パタン・ランゲージとして用意することです。複数のレベルのパタンをコーディネートして、より良いシステムを実現することが必要だからです。

Agile Tour Osaka 2014に参加して、特定のレベルを最適化するだけでは不十分だと考えるようになりました。全体をうまく構成できるように、広い視点を持って、パタン・ランゲージを用意できるように心がけたいと思います。

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


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

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

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

ARCとの関係

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

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

ビジネスモデル

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

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

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

対象のマーケット

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

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

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

営業力

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

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

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

ソフトウェアの特性

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

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

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

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

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

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

最後に

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

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

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

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

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

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

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

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

おまけ

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

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

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

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

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


レビューを考える - SEA関西プロセス分科会 - #seakansai

森崎先生のレビューの講演に参加しました。
個人的には@ITの記事のようなことを期待していたのですが、そのような記事ではわからない議論をすることができてとても有用な講演でした。

議論を通じて感じたことは以下の点です。

(a) 開発者は項目の抜けに敏感

 実践していなくても頭の中がWモデルになっているのかもしれません。テスト項目の源泉を仕様書に求めるので、どうしても項目の抜けが気になるのでしょう。

(b) レビューに優先順位をつける

 優先順位というとリスクベーステストを思い浮かべてしまい、全てをしないでどうするのかと思われるかもしえません。しかし、極限までレビューすることは困難で、時間の制約や体力の限界で終わってしまうので、優先順にレビューのフォーカスを変えていくことが有効だと思いました。

(c) レビュー道の極意は、レビューをせずにバグをとる

 私が勝手にN先生のフロントローディングの話をまねました。すべてをレビューできなければ、その対象を減らすために、ドキュメントのひな型を用意する、ワープロの文章チェック機能を使う、エディタの自動整形機能を使う、静的解析ツールを利用するなど、効率化や自動化は有効でしょう。

(d) レビュー技術の研鑽には経験を積むことも重要

 ドメイン知識がソースコードになっていることから、コードを良く知っているというのも、抽象化できる人なら高度な技術者なのだろうと思います。理由もなく、これまでそうしていたからというのは統一性には役立ちますが、将来役に立たなくなるでしょう。

(e) レビューの特性を生かせ

 テストで見つかると工数がかかるからということがレビューのモチベーションになっていますが、それだとどれだけ時間をかけても良いことになってしまいます。しかし、欠陥の種類によってはテストの方が早く見つかるものも少なくないでしょう。懇親会ではテストは積み上げという議論があり、それからするとレビューの特徴はトップダウンです。レビューに向いているトップダウンでしかわからない所を攻めるべきでしょう。ボトムの細かなところは、なるべくほかの手段で済ませたいですね(それには(c)が有効でしょう)。

つらつらと書きましたが、このようなことを考える良いきっかけになりました。

より以前の記事一覧