無料ブログはココログ

« 2014年7月 | トップページ | 2014年9月 »

[#TiDD] Redmineはドラえもん! - 成長を促すソフトの時代 -

ロボットというと、昔は単純作業を人間の代わりにしてくれるものでした。その後、高度なセンサーが付くようになって、高度な作業も代行してくれるようになりました。

SFの世界では人間を超えるロボットもありますが、いわゆる匠の世界はまだまだ人間のものです。しかし、調理ロボットなどはほどほどに高度な作業を自動化してくれるものの、材料をセットや箱詰めなど機械に難しい単純作業も人間の仕事として残っています。

そのような2極化について「中間層の仕事がなくなる」と表現した記事がありました。

職場のオートメーション化で中間層向けの仕事がなくなる
http://gendai.ismedia.jp/articles/-/1478

この記事はショックでした。IT技術は人を楽にするもの、単純な作業はコンピュータに任せて、人間はより高度な仕事をすれば良い。そんな風に考えていましたが、IT技術は人間らしい仕事を減らす存在になっていたのです。

では、どのようなソフトウェアを作れば良いか?頭に浮かんだのはドラえもんでした。ロボットのように単純な作業や高度な作業をするわけでなく、未来のロボットなのに世界を征服しないのに、社会貢献もしてくれない。

でも、必要とする人間(のび太)に「もっとこうしないとダメだ」と諭してくれます。中間層になれない落ちこぼれののび太の成長を促してくれます。

今後はこのように利用することに教育効果があるようなソフトウェアが必要だと思います。使い続けるうちにユーザを少しずつ成長させて、高度な技術を身につけさせてくれるソフトウェアです。

そこで、自分にとってのドラえもんを考えてみました。一つ目はUNIXとC言語です。大学でアセンブリ言語で苦労していた私に、構造化することや組み合わせること、OSの仕組みを教えてくれました。

2つ目はチケット駆動開発です。アジャイル開発もどきをして失敗していた私でしたが、Tracのチケットで情報共有することでアジャイル開発が解決しようとしていたものが少しわかったと思います。

ちなみに、私がチケット駆動開発の存在を知ったのは、あきぴーさんがRedmineの経験から「チケット駆動開発がわかった!」といわれたからです(書籍「チケット駆動開発」に書いています)。

最後はそのRedmineです。「Tracに影響を受けている」といわれるRedmineですが、ワークフローやプロジェクトやチケットの階層構造など、高度な機能が簡単に扱えるので色々なことを学ばせてくれます。

もちろん問題がなければ、必要な機能だけを使っていれば問題ありません。しかし、どうもうまくいかないときや、もっと効率化したいとき、「ドラえも〜ん!XXXなんだ、なんとかして〜」とRedmineの機能を調べると色々な解決策が見つかります。

ここで大切なのは、「 XXXなんだ」と問題点を明確にすることです。自信満々のジャイアンや出来杉には進んで教えてくれないからです。

もし、大変な状況なのは間違いなくても問題点がわからない、そんなときはドラえもんはこんなことを言うでしょう。

「のび太君。どうして君は人を頼るんだ!少しは自分で考えてみたらどうだい」

問題がわからないなら、Redmineの機能を調べながら「なぜ、そのような機能があるか」を考えてみると良いでしょう。きっと、ドラえもんが助けてくれるはずです。

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


[#TiDD] アジャイルの夢を実現する – チケット駆動開発で考慮すべき点

Ultimate AgileStories Iteration 4(UAS4) が刊行されました。今回も巻頭のアジャイル放談への参加と寄稿をさせていただきました。アジャイル放談では、9月27日(土)にSEA関西で講演していただく倉貫さんの「納品」をなくせばうまくいく の話題のほか、アジャイルの考え方についてワイワイと放談しています。

ご参考までにUAS3に寄稿した原稿を公開します。関西でのUAS4の頒布は 9月27日(土)のSEA関西でも頒布予定ですので、ぜひ手に入れてお読みください。

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


[#TiDD] As isから始めよう - チケット駆動開発の3事例 -

台風接近のため DevLove関西でLTできませんでしたので、ブログで公開します。

この発表は、以前発表した「AsIsとToBeの視点によるチケット駆動開発の事例の考察 - 坂本記念WorkShop -」「チケット駆動開発によるプロセス改善 - 現場重視、管理重視、それとも情報共有重視 -」と同じ事例の再構成です。これら発表では、管理重視は良くない時があるので現場の問題を解決しよう、といった内容ですが、どうもモヤモヤするものがありました。

そこで、チケット駆動開発の「ライトウィング」と「レフトウィング」 と組み合わせました。しかし、どうも納得いきませんでした。

色々と考えて気付いたのは、チケット駆動開発はプロセス改善でなので、単純な成長をしないと言うことです。この時に思い出したのは、ソフトウェアプロセス改善カンファレンス2004(SEPG Japan 2004)の乗松さんの発表(PDF)でした(特に23ページの図)。

As is にも To be にも長所短所があり、状況に応じて必要なアプローチをとることが必要です。そして、様々な改善の経験を通してチームや組織に常に改善する文化が根付くのだと思います。

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


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

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

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

ARCとの関係

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

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

ビジネスモデル

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

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

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

対象のマーケット

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

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

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

営業力

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

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

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

ソフトウェアの特性

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

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

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

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

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

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

最後に

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

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

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

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

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

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

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

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

おまけ

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

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

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

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

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


« 2014年7月 | トップページ | 2014年9月 »