無料ブログはココログ

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

TwitterとSNSの違い

Facebookな人からTwitterの説明を求められたままだったので、個人的な理解と感想をまとめてみました。

SNSとは

SNSとは、mixi、OpenPNE、Facebookのように相互に友達関係を認める事によって、お互いの日記やつぶやき、写真などを共有できるシステムです。SNSは閉じた関係が基本になっていて、友達以外には見せないという設定がある事はもちろん、友達の更新情報を見ないという設定があります。

更新情報がわからなければ、更新されたことがわからないので不便なのですが、いつも連絡を取るほどではないけど、気になった時に見るという友達の距離感が設定できる様になっています。情報を公開する場合には、その範囲をすべての友達だけでなく、友達の種類などその人との関係で制限できる様になっています。

また、コミュニティグループの運営も可能でも誰でも入れるものと管理者の承認が必要なものがあるなど、人と人の結びつきによって、情報の公開範囲を制限できる様になっています。

このようにSNS(Social Network Service)はその名の通り、社会における友達や仲間の関係をネットワーク上で実現しようとする者です。

Twitter

Twitterはミニブログと呼ばれるように公開が基本です。ブログはWeblogの略で、日記のような日々の出来事を書いて公開するシステムです。Twitterは1回の書き込みがSMSと呼ばれる携帯電話の通信に合わせて140文字に制限されていますので「ミニ」がついています。

一般のブログには書いた内容にコメントする事ができますが、Twitterは140文字しかありませんので、Retweetという転送と自分のつぶやきという形でコメントします。最近のTwitterクライアント(Twitterを使うためのプログラム)では、他の人のつぶやきを引用してコメントする機能もありますが、両方を合わせて140文字までにする必要があります。

また一般のブログにはRSSという更新情報を知る仕組みがありますが、携帯電話には向かないデータ量の多い方式です。そこでTwitterにはフォローという仕組みがあります。フォローをするとそのアカウントのつぶやきをリアルタイムに見る事ができます。つぶやきはフォローしている人と自分の者が時間順に表示されますので、TL(タイムライン)と呼ばれます(8/29追記:TwitterにもRSS配信があるようです。 ツイッター(Twitter)のつぶやきをRSSで読む方法 http://webdirector.livedoor.biz/archives/52463773.html)。

タイムラインは情報をリアルタイムに見る仕組みです。Facebookのニュースフィード似ていますが、Facebookが友達と購読しているフィードと自分の書き込みが表示されるの対して、Twitterは友達という概念がありませんので、購読フィードと自分の書き込みに相当する情報が表示されます。

コミュニティグループの概念もありません。できるのは関連する話題にハッシュタグと呼ばれる#から始まる文字列をつぶやきに入れる事と、コミュニティの名前を持つアカウントを作る事です。ハッシュタグは勝手につける事の可能な印ですので、クローズドな関係を表しません。たとえば、肝臓に良いと言われるウコンとキリシタン大名の高山右近が同じハッシュタグでつぶやかれる事もあります。

Twitterにも少しだけ関係性を示す方法があります。一つ目はタイムラインへの表示を制限するブロックと返信です。フォローは基本的に自由にできますが、ブロックされるとフォローできません。リアルタイムに知れれたくない関係がブロックです。返信は送信元のアカウントと返信先であるアカウントの両方をフォローしていないとタイムラインに表示されない連絡方法です。これらはタイムラインへの表示を制限しますが、各アカウントのページに行くと見られてしまいます。

連絡内容を公開したくない場合は、ダイレクトメッセージで連絡を取ります。ダイレクトメッセージはフォローされている人がフォローしている人に送る事ができます。新聞を取っているとチラシが挟まっている事があるようなイメージですね。

こんほかにもプロテクトをする事で公開を制限できます。プロテクトすれば、フォローを許可された人以外はつぶやきを見れなくなりますが、あまりTwitter的ではない使い方でしょう。

気をつけたい事

すべて公開されている

基本的にすべての情報は公開されています。あなたのつぶやきはフォロワー以外にも見られています。自分のブランド作りに利用するぐらいの気持ちでないと、変な誤解を受けてしまう可能性があります。

かつて、フォローしていない方から私のつぶやきについて声をかけられた事があって驚きました。フォローをせずにリストから時々チェックする、それがその人との距離感で、都合の良い読み方なのでしょう。

基本は1方向のつぶやき

基本はブログですから、勝手につぶやいたものを他の人が見るだけです。見るも見ないも読み手の自由です。お返しフォローなどをされる方もありますが、フォローした人のRetweetは非表示にできますが、つぶやきは非表示にできません。必要な場合のみフォローをした方が良いでしょう。

友達の関係になりたいならSNS、友達に限らない相手の普段の考えを知るならTwitterです。

・レッテルを貼らない

リストの仕組みを使えば、アカウントをグループ分けして管理できます。リストは公開できるのですが、その際にリストの名前も公開してしまいますので注意が必要です。出身校や趣味など、リストに載せられる人が公開していない情報をリスト名に使う事はあまりお勧めできません。

また、自分のフォローしている人やフォロワーに対して論評すると、たとえ正しい情報や良い情報であっても気持ちのよいものではないでしょう。増してや勝手な思い込みで論評するという事は論外です。フォロワーがそこで何も言わないと、それを認めた事になってしまうからです。

フォローを外されても動揺しない

フォローと言うのは、公表資料をリアルタイムで読む事です。ダイレクトメッセージが遅れなくてもメンションといって、つぶやきに相手のアカウントの前に@をつければ連絡を取る事ができます。増してや他の連絡方法があるなら全然問題ないでしょう。上述のようにリストで管理する方法や、別のアカウントで読む方法、直接見る方法もあるからです。

最近はTwitterを他のSNSに転送される方もたくさんおられます。Twitterで見たのに、またFacebookでもチェックしないといけないのでどちらかで読めば情報収集は十分です。私も何度か外しました。しかし、Twitterで複数人で議論をしだすと、すべての人をフォローしていないと不便でした。そのような可能性がある場合は、我慢するしかないでしょう。

まとめ

Twitterはミニブログです。SNSとは異なる情報発信や情報収集のための緩い関係を築きます。うまく使えば情報収集やブランド作りに役立ちます。また、オープンなコミュニティにも役立つでしょう。その反面、程よい距離感の友達関係を示しませんし、クローズドな関係を扱うのには向いていません。

Twitterは基本的に公開情報ですので、便利な反面、公開情報で恥ずかしい思いをしたり、容易に人を傷つける事もできてしまいます。その特性をきちんと理解して、うまく活用してください。

[#TiDD] 書籍「チケット駆動開発」では広い議論を狙っています

かつてXPがブームになったとき、7つのプラクティスがありました。その7つのプラクティスには関連があり、すべて守らないとうまくいかないと思われました。しかし、実際のプロジェクトのお話を聞いてみると、顧客同席でなかったり、ペアプロをしていなかったり、色々なプロジェクトがありました。

プロジェクトにはいろいろな制約があり、プロジェクトの成功のためには犠牲にしなければいけないプラクティスがあったからです。しかし、そのようなプロジェクトであってもXPの効果は(一部であったかもしれませんが)得られていました。
参考:川端さんらとの論文PDF(日本語英語)、スライド(日本語英語

チケット駆動開発は、“No Ticket, No Commit!”を基本ルールとした「プラクティス」として、現場で生まれました。このルールを適用する事で構成管理との関連付けができますので、プログラムの更新理由がチケットの内容である事を示せますし、チケットに議論があればその修正に至った経緯も示す事ができます。また、チケットのワークフロー機能を使えば、チケットの完了時の確認を確実に行う事ができます。

しかし、実際にチケット駆動開発を実践されている方のお話を聞いている方のお話を聞いていると、様々なバリエーションが存在していました。そこで書籍「チケット駆動開発」では、基本的な考え方を示しながら、バリエーションについても触れる事にしました。

Twitterを見ていると、このような内容はどうも誤解を与えるようですので、すこし整理しておきます。

1. チケットがないとコミットしてはいけない

チケット駆動開発の基本ルールです。守る事で上述のようなメリットがあるので、プロジェクト内でチケットが活用されるでしょう。しかし、従来法の事例では上流(例えば単体テストまで)では厳しく言わないようにされている場合も多いようです。また、最近の事例として“Pivotal tracker”を利用されている方もおられ、構成管理との連携はないものの、チケット駆動開発の部分的な効果を得られています。

2. コミットするなら細かな作業であっても、チケットを作成しないといけない

コミットとチケットは1対1でないといけないか、なるべくその方が良いでしょう。しかし、実際にはチケットの起票が煩雑になり、必要名項目であっても記入されなくなってしまうかもしれません。それよりは、汎用的なチケットを用意しておいて、同じチケットで何度もコミットする方が現実的でしょう。

3. チケット駆動開発はアジャイル開発である

アジャイル開発がマニュフェストをすべて遵守するという定義なら、上述のXPの様に多くのプロジェクトがアジャイルでないかもしれません。チケット駆動開発はアジャイル開発と親和性が良く、アジャイル開発を意識しながら運用したなら、アジャイル開発のメリットを感じる事ができるでしょう。しかし、チケット駆動開発はアジャイル宣言のすべての要素を含みませんし、従来法を補う形でも実施できますので、チケット駆動開発が常にアジャイル開発と言う訳ではありません(従来法を補う形のチケット駆動開発を本の中ではアダプタブル・ウォーターフォール開発と読んでいます)。

4. 組織のプロセスである

チケット駆動開発は組織プロセスとしても利用可能です。しかし、チケット駆動開発は現場から生まれました。いわばプロジェクト改善です。組織のプロセスと考えるよりもプロジェクト向けに最適化するツールボックスと考えた方が、チームの能力を最大限に引き出せるでしょう。

5. まとめ

チケット駆動開発は厳密な定義がなく、まるでバズワードの様に語られてきました。しかし、チケット駆動開発には多くの利点があり、事例を整理する事でよりプロジェクトにふさわしい方法で実践する事が可能だと思っています。書籍「チケット駆動開発」では、より多くの知見をあつめ、多くの議論ができる様に、従来考えられている要理も柔軟な幅広く議論できるように定義しました。

その言葉について多くの議論が集約できるようなものを、アンブレラワードと呼ぶそうです。よくわからないバズワードでなく、より現実的なアンブレラワードとして議論できること。それがより広いチケット駆動開発の定義を採用してテーラリングガイドを載せた理由です。

チケット駆動開発は現場から生まれました。現場のプロジェクトを成功させることが、チケット駆動開発の目的だと思います。より広い定義を採用して、少しでも多くのプロジェクトを成功に導きたいと思います。


自動化による信頼性向上 - オブジェクト指向とアジャイル開発 -

XPやスクラムはオブジェクト指向の著名人がまとめたそうです。そのことから、アジャイル開発の繰り返し開発、テストファースト、常時結合、リファクタリング、などを考えると、オブジェクト指向開発の信頼性向上にはアジャイル開発が必然である事が見えてきました。もちろん、これらのプラクティスは変化を受け入れたり、信頼性を向上させる、作業を効率化する、などの目的がありますが、オブジェクト指向開発を適用するとそれらの効果があったという事なのかもしれないと思っています。

オブジェクト指向

Smalltalkの大家である青木淳先生らの「Smalltalkで学ぶオブジェクト指向プログラミングの本質」によると、オブジェクトのアナロジー(類推)は細胞だそうです。大きなシステムを構築できるように細胞の構造を参考にしたのでしょう。外界との間に細胞膜があり外界の信号(メっセージ)を受け取り、内部には私的データ領域(インスタンス変数)があります。このような細胞の複製とメッセージによる差異によって、大きな生命体が構成されるのです。

このアナロジーが示す事をざっくり言うと

・小さな単位のオブジェクトの組み合わせによって大きなシステムを構築する

のですね。今や当たり前に受け入れられる考え方ですね。

しかし、かつてSmalltalk-80がパソコンで動くようになったころ、オブジェクト指向には以下のような課題があると言われていました。

・動的な部分を持つ言語なので実行しないと正しく動作するかわからない
・処理系が複雑で豊富なリソース(メモリー、CPU)が必要

そこで、Smalltalkには逐次実行する環境があったのですね。インタプリタを用いて逐次実行して確認すれば、実行時に解決される動的な処理も確認する事ができます。そういう信頼性の高い小さな開発の繰り返しによって、大きなシステムが開発されていました。

そのように順次拡張されていったSmalltalkのライブラリは一つの世界を表現していて、既にあるライブラリをうまく拡張することで新しいシステムが開発されていました。その様な環境を維持するには、プログラムが単体でも組み合わせでも正しく動く事はもちろんの事、再利用が容易なようにきちんとリファクタリングされているる事が必須でした。

リソースの問題は、いまや計算機の性能向上が解決してくれましたので、オブジェクト指向開発に求められるのは、ソフトウェアの再利用性の維持と信頼性の向上になりました。

アジャイル開発

アジャイル開発ではソフトウェアを常に実行・テスト可能にしておき、段階的に開発していきます。これはオブジェクト指向を実現するための動的な要素を含む言語であっても、安心な構造であると言えるでしょう。また、リファクタリングによって再利用が容易な構造になりますので、再利用性が維持できます。

アジャイル開発は自律的な組織を前提にするなど、オブジェクト指向的な要素を含んでいます。コンウェイ(リンク先はWikipedia)は、組織構造に似たアーキテクチャが作られると言いましたが、開発方法論によって似たプロセスが生まれることもあるのですね。

自動化による信頼性向上

テスト自動化や継続的統合・デリバリーは、常に実行可能なソフトウェアを実現するだけでなく、オブジェクト指向で必要とされる信頼性向上と維持を容易にします。

・常にきれいにして問題の発生を見える化する
・問題を局所化して発見を容易にする

トヨタ式改善の基本は工場の掃除だそうです。ネジや部品が落ちていたらすぐにわかるからです。ソフトウェアをいきなり結合すると、ちらかった工場でネジを探すようなもので、見つけるのに時間がかかってしまいます。

テスト以降の工程を自動化すると、常にテストされた状態にソフトウェアを保つ事ができます。問題が生じれば前回との差分、新たに追加されたか変更された部分であると予想できます。規模が増大しても、自動化テストの範囲の不具合は比較的短時間で不具合を摘出できるでしょう(この効果によってケントベックさんが言われているように規模が大きくなっても工数があまり増加しなくなりますが、想定外のバグはうまくいかないと思っています)。

このように、アジャイル開発はオブジェクト指向開発での信頼性を向上させる仕組みを実現していると思います。

アジャイル開発のプロセス

アジャイル開発のプロセスをオブジェクト指向になぞらえると、実行しないとわからないという問題は、人間の仕様に対する理解や外界の変化、リソースの問題はアジャイル開発に必要な作業に相当するでしょう。

動的な言語と同じように、人間の要求も実際に動くモノがないと仕様は明確になりません。また、外界の変化に対応するにはなるべく早くソフトウェアをリリースする事でしょう。段階的な開発によって、その問題は軽減されるでしょう。

リソースの問題は多くのツールが支援してくれます。統合開発環境、バージョン管理ツール、障害管理ツール、xUnit、CIツールなどが作業負荷を減らしてくれるでしょう。

プロセスの自動化

プロセスは人間が実行するものです。このため、完全な自動化のほか、警告や指示、支援などは、すべてプロセスの自動化に含まれます。

開発作業の自動化と同じように、プロセスもバージョン管理や障害管理などプロセスの一部はツールによって自動化されています。しかし、ビルドツールだけでは不十分なように、プロセスもまだまだ自動化の余地が残っています。

その一つはチケット駆動開発で用いるBTSのワークフロー、ツールの関連付け、通知方法など様々な特徴だと思っています。アジャイル開発はオブジェクト指向の問題を解決する中で生まれましたが、チケット駆動開発は現場の問題を解決する中で生まれました。

様々な問題が発生する開発現場において、アジャイル開発だけでは負担の大きい問題もあるでしょう。その解決にはプロセスの自動化が効果を発揮する場面があると思っています。

まとめ

XPが話題になった頃、前述の青木先生に「XPをどう思いますか?」と質問したとき、「同じような事は、前からしてるよ」とあまり気にしていないそぶりで言われました。当時は、研究開発をされているからだと思っていましたが、オブジェクト指向開発にとってXPのような開発スタイルは必然だったのかもしれません。

それにも拘わらず、日本ではなかなかアジャイル開発が普及しません。それは現場において単体テストまでの工程で問題点を吸収するなど工夫しているのか、それともまともなオブジェクト指向開発が行われていないのか、あるいはそろそろ限界で破綻に向かって進んでいるのか、私にはわかりません。

しかし、信頼性を向上させる観点では、実装と同時にテスト以降の作業の自動化は必須だと思います。アジャイル開発が考慮しているオブジェクト指向での信頼性をどのように担保するか、どのように効率化するか、よく検討しなければいけないと思います。


[#TiDD] カードかチケットか、タスクボードかBTSか

アナログが良いかデジタルが良いか、そんな答えはありません。それぞれに長所も短所もあります。プロセスは各プロジェクトで異なるので、必要な方法を実施すれば良いのです。

大切なのは、今のプロジェクトの問題が何で、その解決法は何かという事です。以下にタスクカードなどのアナログのカードと、チケット駆動開発(TiDD)で用いられるBTSのチケットの特性をまとめました(BTSではなく他のタスク管理ツールでもおおまかな傾向は同様でしょう)。

カード チケット
コミュニケーション 自然と目に入る リモート、リアルタイム
情報量 壁は大きなタスクボード 膨大な情報の検索と表示
起票の容易さ 簡単 工夫が必要
履歴の利用 困難 容易
情報交換の方法 話し合い中心 文字中心
作業配分 分担的 やや分業的


コミュニケーション

カードの特徴はタスクボードなどに貼られる事で、自然と目に入って情報共有できる事です。アナログ情報は大まかな情報認識に有利で、今どのような状況にあるか大まかに知る事ができます。

チケットは意識的に見る必要がありますが、更新の通知を常に利用するツール、例えば、メール、webブラウザなどのrssリーダー、プラグインによるEclipseへの通知などによって、日常的に確認する事ができます。また、物理的なボードは使いませんので分散開発であっても利用する事ができます。

情報量

タスクボードにホワイトボードを使うと物理的な制限があります。しかし、壁を利用する事ができたなら物理的な制限があまり気にならないでしょう。タスクボードは情報を提供するだけでなく、コミュニケーションの場を提供します。昔の喫煙室のように何気ない「うまく行ってるようだね」「大変そうだね」から始まる状況の確認、苦労話、ノウハウなど情報交換が行えます。以前紹介したXP祭り関西2012の田口さんの発表(Spring of Wisdom − XP祭り関西2012(3))では、複数チーム間でそれを実現されています。タスクボード物理的制約に縛られますが、その制約を除ければ大きな可能性があるのです。

一方のチケットには物理的な制限がなく、様々な検索や表示が可能です。緊急度の高い作業や個人の作業の検索やキーワードの検索、マイルストーン単位の一覧やガントチャートでの表示も可能です。

起票の容易さ

多くの方が、カードの起票が容易であると言われます。手書きで主な情報だけを書く事ができるからです。すべてのタスクのカードを作るなら、明らかに有利でしょう。

チケットの記入は時間がかかるというほどではありませんが、後々参照される者ですからきちんと書いておく必要があります。しかし、あまりにも同じようなチケットばかりだとやる気がなくなってしまいます。そこで、上流においては共通で利用するチケットを用意したり、あまり厳密に構成管理と関連付けない様にします。

履歴の利用

カードにおいても写真を撮る事である程度は履歴を管理できます。カードのデータを電子化してから印刷するようにすれば電子データを残す事ができますが、文字や書き方でパッとわかるというアナログの良さが半減してしまいます。

チケットであれば議論も残せますし、構成管理とも連携して記録できますので、非常に効果的です。先日ご紹介した赤羽根さんのIT統制のお話は、とても良い応用例だと思います。

情報交換の方法

カードを作成する際には多くの情報交換が行われ、ゴールが共有されます。カードでは多数決のような決定も行われますが、まず情報交換が行われて多くの決定が進められます。しかし、意見を主張する事が苦手な人もいます。

チケットには電子化によるコーチング的な効果があるので、ある程度緩和される可能性があります。

作業配分

カードの起票や管理は基本的にチームで行われ、各人のコミットメントに従って作業が分担されていきます。アジャイル開発の目指しているサーバント・リーダーシップの発揮しやすい環境です。

チケットを用いる理由の一つとして、ワークフローがあります。作業者の役割ごとに権限を分けて、チケットの状態を遷移させる人を限定するのです。この方法は作業の一部を分業する事になります。管理的ならないように気をつけるべきでしょう。

おわりに

コミュニティで経験談を聞いていると、チケット駆動開発から始めてアナログなアジャイル開発に進んだ例を聞く事があります。

アジャイル開発に比べると物理的な制約が少なくて導入が容易なチケット駆動開発から初めて、アジャイル開発の成果を上げた上で、アナログのメリットを把握した上で、アナログなアジャイル開発に移行されるでしょう。もし、分散拠点での開発や管理上の理由、メンバーの適正など、チケット駆動開発の必然性のあるプロジェクトであったなら、ずっとチケット開発を続けられたでしょう。

最近、アナログなアジャイル開発が実現する「自律的で攻撃的な開発」で成功されている組織の、ある特徴に気づいきました。このような組織は、積極的な経営を実施し、元気な人を集めているイノベーティブな企業が多いのではないでしょうか?それがすべての企業に当てはまるかどうかは、十分に検討する必要があるでしょう。

もちろん、どのような会社も自律的で攻撃的な開発を目指すことで、新しいマーケットが生まれるかもしれません。しかし、アジャイルサムライに書かれているように、アナログなアジャイル開発をすべての人が気に入るとは限りません。組織に既に居る人に合わせた、よりふさわしいプロセスを用意する方が効果的ではないでしょうか。

今回書いたチケット駆動開発の本には、チケット駆動開発のバリエーションを踏まえてテーラリングについて書きました。アジャイル開発を導入する場合にも、組織やマーケットに会わせたテーラリングが必要だと思っています。

リーンを考える - 無駄と必要なアソビ -

leanとは贅肉がなく引き締まった様子を表す言葉で、リーン生産方式などでは「無駄を排除する」ことから名付けられています。「無駄を排除する」という事だけをとらえると、スターバックスの改善のように作業をストップウォッチで計測して、配置と作業の最適化によって無駄を排除するような事をイメージするのですが、ビジネスを考えると、アソビが必要だと思っています。

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

私がリーンを初めて知ったのは「リーンソフトウェア開発」という本でした。この本には、海兵隊を例に自律的な組織が説明されていたほか、「決定をできるだけ遅らせる」というプラクティスが衝撃的でした。

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

アソビ

先日、koboを買いました。iPhoneのような箱という評価もあるようですが、こんなに開けにくい箱は初めてでした。茶筒じゃないのだから、それなりに隙間を持たせてほしいと思いました。設計では、このような隙間を「アソビ」と呼びますが、きちんと考えて隙間を作るのに「アソビ」というのは面白い表現ですね。

理論の世界と現実の世界の違いは、このアソビだと思います。計算上はうまく行くはずなのに、現実世界になるとうまく行かないことがあります。たとえば、1人月の仕事だから1ヶ月だけ誰かをつれてきてなどと考えても、前の仕事からの切り替えには、新しい仕事の準備だけでなく、前の仕事をきちんと切り上げて、打ち上げなどがないと気持ちの切り替えもうまく行かないでしょう。また、常日頃から与えられた仕事の勉強だけでなく関連知識も習得する努力をしておかないと、前の仕事のスキルを次の仕事に活かす事も難しいでしょう。

ラーニングオンデマンド

ラーニングオンデマンドは、以前も書きましたが簡単に言うと、情報が増えてくるとあらかじめ勉強しておくのは困難なので、必要になったときに勉強するという事です。いわば、ポーリングをやめてイベントドリブンにするのですから、この方法も無駄の排除には効果的です。

しかし、実際にやってみると、デマンドをどのように捉えるかによって、学習範囲と効果がかわります。もし、仕事だけをきっかけにしたのなら、自分がどんどん使い物にならなくなっていく事を実感されるでしょう。逆に、目にしたものすべてをきっかけにしたのなら、膨大な情報に振り回される事になります。前回のアジャイルの壁で書いたように、興味を持ったときは学習効果が高いので、仕事+興味を持ったものをきっかけにするのが良いと思います。

リーンスタートアップ

同じ「リーン」の名前のついたものに「リーンスタートアップ」があります。後から名付けられたようですが、これも同じく無駄のないスタートアップ(起業)の方法です。無駄のない仕組みとしては、MVPと呼ばれるスモールスタートの考え方と、ピボットと呼ばれる方針転換がポイントでしょう。音楽業界を見ていると、このピボットの方法が見えてくるのではないかと思っています。

かつて倉貫さんが大阪に来られたことがありました。このとき、本を読んでくる事が宿題だったのですが、力つきたのでその代わりに当時話題になりつつあったももいろクローバZ(ももクロZ)の特番を見ました。私は高音の女性の声が苦手なのですが、この時は我慢して見ました。

そこでわかったのは、ももクロZは最初から今の方向性ではなく、徐々に方向転換した上で、メンバーの脱退を機に方針変換したという事でした。元々は少し元気なアイドルだったのが、各人に色がつき、ミュージカルっぽいものからコント仕立てのもの、そして今のようなハチャメチャに元気いっぱいでアニメっぽいイメージのものとなっていったようです。

後で調べると、その背景にはAKBの会いにいけるアイドルとは反対に、会いにきてくれるアイドルという軸足があったようです。その中でピボットを繰り返し、最終的に最も大人っぽかったメンバー脱退でよりアニメっぽい方向に舵を切ったようです。このようにピボットができたのは、毎回必要最低限のぎりぎりで曲を作ったのではなく、アルバムの中にアソビがあって、顧客の反応を見ていたからだと思います。

必要なアソビ

さて、どこまでが無駄でどこからが必要なアソビなのでしょう。ソフトウェアを作るのが人間である限り、それは幅があると思います。組織的に考えるのであれば、ある程度の長期的な視点で進めると共に、ある程度はエンジニアの自由を認める必要があるでしょう。

エンジニア個人を見ると、勉強会に出るなどで刺激を受けることが効果的です。実は勉強会は多くの刺激が受けられるほか、経験者からのサマリーを聞く機会でもあります。ややもすると、仕事には無駄と思われがちな勉強会ですが、会社に閉じこもって調べるよりも結果を聞いた方が早い事も多く、特に懇親会でお話ができたなら、仕事に直接関係する相談ができる事もあります。

知識というのは単独に存在しません。外部との関連があり、周辺の知識とともに存在します。ピンポイントで業務上の知識を持っているだけでは応用が利きませんし、経験だけでも役に立ちません。経験をきちんと整理できて応用が利く、そういう時間が取れる適度なアソビが「必要なアソビ」だと思います。

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


アジャイル開発への壁は価値観の壁

海外ではウォーターフォール開発に失敗してアジャイル開発が普通なのに、日本では問題を抱えながらもウォーターフォール開発がそれなりに成功してアジャイル開発が普及しないのはなぜか?その理由を欧米の価値観から説明し、その対策を考えてみたいと思います。

1.サーバント・リーダーシップ

上記の問いの答えは価値観にあると思っています。かわぐちやすのぶ(@kawaguti)さんの最終回 5分で分かる、「スクラム」の基本まとめの最後に、“「サーバント・リーダーシップ」へのマインドシフトが必要”と書かれていますが、これこそがアジャイル開発の壁だと思っています。

実は「サーバント・リーダーシップ」はアジャイル開発に限らず、欧米の価値観では当たり前の事なのです。以前、紹介したいわゆるデブサミ本「100人のプロが選んだソフトウェア開発の名著 君のために選んだ1冊」に、CMMで有名なハンフリー氏の「TSPガイドブック:リーダー編」にある関連部分を引用していますので、その部分を転載します。

この本にあるように、メンバーの能力が発揮できる「自律的なチーム」を構築すべく、「リーダーシップ」を発揮して「その最大限の能力を最大限発揮できるようメンバーを動機付け、コーチし、後押しする」ことが重要だったのです。そのためには「フィードバックとコミュニケーション」の提供や「動的な負荷調整」も必要です。また「管理することとリードすることは違います」し、「人はリードされたいけれども管理されたくはない」ので、「リーダーは部下を動機付け」るなど「下からリード」して「ゴールを達成」するべきだったのです。

この本はアジャイル開発についてCMMIに記述される前のチームのプロセスについて書かれた本です。そこでは厳密ではないですが、ウォーターフォール的な開発が基本です。にも拘らず、自律的なチームを下からリードすることが勧められているのです。これには私も驚きました。チームのあり方がこのように語られるのは、メンバーやリーダーの価値観が日本と違うからだと思っています。

2.欧米の価値観

欧米というと、昔からの私のイメージは「個人主義」「合理主義」でした。しかし、これは表面的な捉え方だと思います。確かに、民主主義の流れで確立された個人の権利は個人主義につながりますし、自由主義経済の基本にあるのは合理主義的な考え方でしょう。しかし、そういう割り切った価値観以外に、キリスト教的な価値観があると思います。それは以下のようなものです。

自分の能力を活かす
聖書にはタラントンの教え(リンク先は日本聖書協会)というのがあって、預けられた1タラントンのお金をなくさないように埋めておいた人が、怠け者として怒られるお話です。タラントンとは昔のお金の単位ですが、タレントの語源だそうです。キリスト教圏の人は「神様に与えられた能力を活かしなさい。」と教えられて育つのです。これでは、コマンドコントロールに向いたウォーターフォールがうまく行くはずがありません。

人に仕える
また、最後の晩餐のときには、使徒たちのうち誰が偉いかを話していると、キリストに「上に立つ人は、仕える者のようになりなさい。」(ルカ22・26、日本聖書協会 新共同訳)と言われるお話があり、200年前から「サーバント・リーダーシップ」が語り継がれているのです。

日本人はどちらかというと個人の能力を活かすというよりは、「一人前」と言う言葉に表されるように人並みになる事が第一目標。そして、人の上に立って、地位と名誉を得る。という一般的な成功パターンをイメージしがちです。そこには、自制的で調和のとれた立派な人によって構成されたピラミッド型の組織のイメージがあります。

しかし、上のような欧米の価値観からは、個性的で人の役に立ち、人の能力を最大限に生かすリーダー像がイメージされます。そこで、欧米の有名人を思い浮かべると、そのそばには必ずと言ってよいほど名補佐役やエキスパートがいました。互いに能力を認め合い活かし合って偉大な結果を生むことが、多いのでしょうね。

3.壁を越えるには

さて、このように説明すると宗教に頼らないといけないのかと思われるかもしれませんが、すでに大人の私たちが改宗しても、子供の頃から欧米の価値観の中で育った人になれる訳ではありません。何らかの戦略を理論として持たなければなりません。私の考えた2つの戦略を紹介します。

勝てる土俵で勝つ
主にカトリック系の幼稚園におおい教育法で「モンテッソーリ教育」(リンクs会はWikipedia)があります。子供が何かに集中して獲得しようとしているときを「敏感期」と呼んで、そのときを利用して教育します。私はこれが、大人でもあると信じています。

誰でも興味を持った瞬間を活かして勉強すればすごく上達しないでしょうか。仕事をする上でも、「おっ!」と思ったときはすかさず確認して、ある程度納得するまで調べます。そうして得意な分野を増やしていくのです。また、同じ工数で従来のやり方と工夫したやり方があるなら、後から楽になりそうな工夫をしてノウハウとその後の効率を手に入れます。

このように自分の能力を育て、活かし、そして得意なところや勝てるところで勝負します。そうすればさらに能力を高める事ができるでしょう。

背中を押してくれるお父さんになる
「人に仕える」と言われてもよくわかりません。そこで、血の気が多く、技術指向だった頃に私が求めていたリーダーをイメージすると以下のようになります。

・より良い方法を提案すると、それを受け入れてくる
・受け入れられない場合は、説明してくれる
・権限を委譲して色々やらせてくれるが、調整したり責任を取ってくれる

つまり、「俺が見てるからやってみろ」と背中を押してくれるお父さんになるのです。若いときは「謝るのも仕事なのに」と愚痴っていても、上司になると何もせず謝る事を避ける人がいます。この戦略はその逆で、積極的に謝る覚悟をしつつ、メンバーの能力を活かして、それをさけるのです。

4.おわりに

価値観を変えるというのは難しい事で、同じ価値観をチームで共有するというのは難しい事です。アジャイル侍にあるように、みんながその方法を気に入るわけじゃないのかも知れません。しかし、価値観に対する議論をせずに、やることだけを共通化してもアジャイル開発の効果を得る事はできないと思います。

どのようなチームにするか、その合意形成が重要なのだと思います。

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


メトリクスの特性からアジャイル開発を考える

アジャイル開発に関する議論が色々ありますが、メトリクスの特性を考えるとアジャイル開発が何を目指しているかがわかってくると思います。

メトリクスは目的にあわせて定められるものです。GQM(リンク先はWikipedia)のように、測定する目的(ゴール)があり、評価すべき問いがあり、メトリクスが存在します。アジャイルで開発においても、従来からのメトリクスを収集されているところや、StatSVN(リンク先はRyuzee.com)や Sonar(リンク先は@IT)を用いてメトリクスの自動収集をされているところもあるでしょう。しかし、ここではアジャイル開発で特有のメトリクスを考えることで、アジャイル開発を考えてみたいと思います。

メトリクスには、数値、尺度、属性の意味があります(楠本 真二,“ソフトウェアメトリクスの研究動向(PDF),” 第4回エンピリカルソフトウェア工学研究会,December 2004.)。従来から利用されているメトリクスの多くは「数値」として用いられ、アジャイル開発特有のメトリクス(とは意識されない場合も多いかもしれませんが)には「尺度」として用いられています。この「尺度」には以下の種類があります。

比例尺度 ratio scale 数値の差と共に数値の比にも意味がある
間隔尺度 interval scale 数値の差のみに意味がある
順序尺度 ordinal scale 順序のみに意味がある
名義尺度 nominal scale 観察される変数と数値を対応させる(分類として記号の意味を持つだけ)

たとえば、開発対象を表すストーリーポイントや、その開発速度であるベロシティを考えると、これらはプロジェクト間で有効な数値ではなく、チームで決めた比例尺度です。複数のチーム間を比較して善し悪しを決めるものでなく、チームがより良く開発できるように用いるものです。

ストーリーポイントの見積もりにはプランニングポーカーが用いられることが多いようです。プランニングポーカーは、1、2、3、5のように直前の2つの数の合計が次に続く数列であるフィボナッチ数列を基本とするものです。1、2、3、4と続く線形の値で詳細な見積もりをするのではなく、ざっくりとした見積もりをします。

プランニングポーカー(リンク先はEnterpriseZine)は見積もりという意味では比例尺度を示すものですが、ストーリーに対して属性をつけることで、大まかな分類をしている側面があります。分類をすることで、以下の効果が得られます。

- ストーリに対する認識のずれを明らかにする。
- 詳細化が不十分なあまりにも大規模なものを見つけ出す
- ゴールを共有すると共にベロシティを意識する

これらをみていると、メトリクスの向こうにある目的が透け見えます。メトリクスは組織の視点で管理するものでなく、プロジェクトをうまく動かすための道具でり、コミュニケーションや見える化、そしてプロジェクトを前に進めるためのエンジンなのです。

このほかの尺度の例としては、スクラムのバックログがあげられます。バックログは優先順位を持ちますので、順序尺度です。バックログを属性尺度ではなく順序尺度として用いるのは、イテレーション(スプリント)のゴールを明確にするだけでなく、顧客にとっての価値を明確にすることで顧客とのコミュニケーションを向上させているのでしょう。

このように、メトリクスの観点でアジャイル開発を眺めると、従来の開発との違いが見えてきます。数値によってプロジェクトが過去の標準的な開発からずれていないかを管理するというのではなく、これからのプロジェクトに対し、理解を深め、問題点をなくし、ゴールを共有する道具であり、顧客とのコミュニケーションをとる仕組みになっているのです。

アジャイル開発は組織の視点よりも、今のプロジェクトを重視しているのです。

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


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