Pages

2016年11月18日金曜日

お知らせ:ブログの移転

当ブログをご覧いただき、誠にありがとうございます。

 この度、当ブログを以下のURL(ユニリタホームページ)に移転しました!

 移転先でも引き続きご覧いただければ幸いです。

 ↓↓
http://www.unirita.co.jp/blog/cloud-computing/becloud/

2016年10月5日水曜日

ワークスタイルの変革は自分たちの会社で必要か?

Be.Cloud通信戌亥です。最近ワークスタイルの変革(働き方改革)の話をよく聞きます。どこの会社でもテーマになっていますし政府も一生懸命になっています。さて、なぜこんなことになっているのでしょうか?

ホワイトカラーの生産性問題

日本経済新聞の9/16日の朝刊一面に、「国内主要企業の社長100人へのアンケート」が掲載されていました。そのアンケートでは、経営トップは「裁量労働制の拡大(51%)」「在宅勤務(43.5%)」「脱時間給(42.2%)」に興味があることがわかりました。それは日本のホワイトカラーの生産性が欧米に比べて低いというところから、ワークスタイルを変えなければ解決できないと言う危機感があるからです。

先日あるセミナーで国際的なIT会社のインターナショナルチームの方がプレゼンしていましたが、米国の生産性が100に対して日本は62だそうです。これは日本人が欧米人に比べて能力が劣っているということでないとしたら、働き方が悪いとしか言いようがないですよね。日本の競争力を取り戻すために、働き方改革が必要であるということを示している一例だと思います。 

少子高齢化にともなう労働力問題

そのほかに、女性活躍社会や外国人労働者受け入れの促進、また、高齢者雇用の促進などがあります。これは日本の少子高齢化にともなう、労働人口の減少を回避するために、多様な人材の受け入れが必要であり、それに応じた働き方ができるようにしたいということです。特に、子育て世代の人たちにとっては、男女ともに在宅勤務というのはある意味助かります。一度育児休暇に入ってしまうと、復帰するのにはいろんな意味で時間がかかります。在宅勤務で働きながらであれば、保育園への送り向かいの時間を取ることができますし、時間短縮の勤務体系で、子育ての時間を作ることができます。どちらにしても多様な働き方を受け入れるところから問題の解決が生まれます。

IT活用による働き方改革

さて、勤務制度だけを変更したからといって、生産性が良くなるわけでもなく、また在宅勤務者とのコミュニケーション問題が解決するわけではありません。そこには、ITという生産性を高めるためのツールが必要となります。

経済産業省が「攻めのIT銘柄」を発表して、「ITを売上拡大に利用しましょう」と推進しているのも、これまでのコストダウン型のIT活用だけでは無く、売上拡大にITを活用することで、ホワイトカラーの生産性を上げることが日本の課題となっています。

現在では当たり前になってきましたが、場所の離れた人とミーティングをする場合はテレホンカンファレンスを利用します。会社の会議室同士をつなぐ、本格的なテレカンシステムや個人のパソコンをつないで小さなミーティングをするSkype、Hangouts、Lyncなどのツールが簡単に利用できるようになりました。

何かを伝達する為のミーティングであれば、ネットでつないでリアルタイムに会話をするだけで伝わるでしょう。しかし、ディスカッションしたい項目をあげて、ディスカッションするとなるといかがでしょうか?例えば、会議室で話をしている時は、参加者の顔を見ながら、ここが自分の発言時であると思えば、そこで発言することが出来ます。しかし、ネットでつないで声だけを聞きながらだと、発言が難しくなります。

そこで活躍をするのがチャットだったり、共同編集型のOfficeツールだったりします。ホワイトボードに絵を描きながら討議をするのと同じ感覚で、Officeツールやチャットで情報を共有しながら会話をすれば距離を感じ無いミーティングをリモートで行うことが出来ます。

今風に表現すると「ホワイトカラーの生産性をアップしたい」からの「ワークスタイル変革をしたい」からの「在宅勤務を推進したい」からの「攻めのIT」が必要となるわけです。



2016年9月13日火曜日

リモートワークでコミュニケーションに悩んでいませんか?

Be.Cloud通信戌亥です。iPhone 7の発表会のプレゼンテーションをご覧になりましたか?日本人には大変嬉しいアップデードがありましたね。マリオだとかSuicaのサポートとか。しかし、個人的にはもう1つ嬉しいアップデードが発表されたと思っています。それはiWorkのリアルタイムコラボレーションです。

リモートワークでのコミュニケーション

先日、当社のワークスタイル変革のセミナーでリモートワークの件がテーマになっていました。リモートワークについては検討をされている方はたくさんいると思いますが、コミュニケーションはどうするの?という悩みを持たれている方多いのではないでしょうか?

リモートワークは単に従業員が自宅で勤務をするだけではなく、違う場所にいる人たちが、チームでワーク(仕事)しなければなりません。つまり、チームの人たちがお互いに様々な情報を共有しなければならないのです。

当社でもリモートワークをやり始めています。我々はソフトウェアの開発をリモートで行っていますが、開発をする項目、その進捗状況、プロジェクト内で発生する様々な課題などは、プロジェクトを統括する人と複数人のプロジェクト員たちの間で共有しなければなりません。これまでは、同じオフィスで働いていたので簡単に共有することが出来ましたが、それがリモートになるので、ITを駆使しなければ出来ません。

特に昨今のソフトウェア開発は、2週間毎にリリースを行う、いわゆるアジャイル開発が多くなってきております。開発を2週間で行うと言うことは、10営業日の間に、詳細設計、プログラム開発、単体テスト、結合テストを完成させなければならないため、1日の遅れが、プロジェクトに大きな影響を及ぼします。

協働の為のツール

そんな時に、共同でドキュメントが編集ができる仕組みである、Google Docsやマイクロソフトオフィスのオンライン版であるOffice365、今回、アップルから発表された、iWorkのリアルタイムコラボレーションは生産性向上に大きく寄与します。

その他にも、wikiやアジャイル開発でよく利用されるJIRA、Backlogと言った仕組みを様々な方法で使いこなすことが必要です。

ちょっと同僚にものを聞きたいなぁ?と思った時に、いちいち電話をすると、同僚の仕事をインターラプトしてしまいます。これでは本業に集中できなくなりますので、その場合は、Slackなどのチャットツールを使って聞きだすといいでしょう。

「ちょっと聞きたいんだけど今いいかなぁ」

という感覚でチャットを使います。同僚はダメな場合は、応答をしないでしょう。大丈夫な場合は、それに応答してきてくれます。

ツールは用途によって使いわける

メールがいい場合もありますが、メールは基本P2Pです。ある人が、ある人に直接メッセージを書きます。受け取った人は、その時に時間があれば返信しますが、時間がないと、時間が経ってしまい他のメールに埋もれてしまいます。

また、それ以外の人が返信可能だったとしても、Toに入ってない人は、基本返信をしません。その点、SNSやチャットを使えば、プロジェクトに参加している人や、部内の有識者が、困っていると気がついた時に返信してくれます。メールとチャットやSNSは利用の仕方を分ける必要があります。
この様に、様々なITを使いこなすことで、リモートワークに必要なコミュニケーションがより良くなります。

因みに、iWorkが嬉しいのは、Apple製品には無料でバンドルされてきているからです。私は以前からMacを使っていますが、OpenOfficeを使ったり、iWorkを使ったり、なんとか、MS Officeに頼らない使い方を考えてきました。

しかし、お客様やパートナー様から、MSのパワポ形式で送って欲しいというニーズが多かったので、最初はiWorkのKeynoteをパワポ形式に変換して送っていたのですが、これをやると、同じプレゼンテーションがいろんなフォーマットに複製されて保存されてしまうので、モノホン(原本)がどこにあるかわからなくなってしまうのです。 その為、ついにMac版のMS Officeを導入してしまいました。

iWorkの協働編集機能を皆さんが使う様になれば、パワポでなくてもいいという人が出てくると期待しております。その時には、iWorkにもう一度戻したい考えています。

2016年8月26日金曜日

動画って業務に活用できるんですか?

 Be.Cloud通信戌亥です。もっとブログを書きたいと思っているんですが、こう暑いと「箸」がじゃなくて、筆が進みませんね。まあ、夏の暑さももう少しでしょう。

ユニクロがバイトを動画で面接

先日、日経新聞をみていたら、「ユニクロ、動画でバイト面接」という記事がでていました。前回のブログで報告しましたように、当社も動画を活用してアルバイトの基本トレーニングを行なっておりますので、ちょっと気になりました。応募者が自分で動画を撮影してサイトにアップするようです。店長らがそれをみて合否判断をするとか。「ん〜、あんまり新しくないね。リアルの面接が、動画になっただけなんじゃないの?」と思う方がいるかもしれませんが、私はこれをみて、ただの面接ではなく、もっとこれを活用できるんじゃないの?と思いました。

みんなの意見は案外正しい

ユニクロの記事をみて思い出したのが、「みんなの意見は案外正しい」という本です。この本をご存じでしょうか?かなり前に流行った本です。英語のタイトルは「The Wisdom of Crowds」でその名の通り「集団の知恵」です。集団の知恵がいかに正しいのか?というのをいろんな事例をもとに説明をしています。例えば「雄牛の体重予想」では、800人の予想の平均値が、どの専門家の予想よりも近かったというものです。もちろん、これにはいくつかの条件があります。多様性、独立性、分散性を守ることです。同じタイプの人たちが予測したり、だれかと相談して、いくらにしょうか?というのはなしですね。それをやると、だれかの意見に流されたりするので、集団の知恵にはならないわけです。この本面白いので、是非読んでみてください。
この本の日本語タイトルには「みんなの意見は案外正しい」と「案外」が入っていますよね。英語のタイトルには入っていません。前から気にはなっています。日本ではどうしても、多くの人たちが集まると、正しい意見になるよりは、間違った意見に流されるというイメージの方が強いですね。何か、洗脳されるみたいな話です。そう言う意味でも、独立性や多様性を重視した意見が意思決定には必要なんだと思います。

デジタルであればこをできること

しかし、ユニクロの件とこの本何が関係あるの?と考える方がおおいでしょう。私も普段新卒の面談をしていますが、面接官はせいぜい2人です。800人で面談をしてしまうと、学生が萎縮して面談になりませんよね(笑)。しかし、デジタルデータとして投稿された動画は、多様性、独立性、分散性を守った上で評価することができます。これこそ集団の知恵ではないでしょうか?いくら頑張って、面接をしてもたった30分で面接官2名で正しい評価ができる保証はありません。それよりも、いろんな人に評価してもらい、その平均をアウトプットとして採用することができます。このように、動画を活用することで、これまでにないやり方で評価をすることが必要だと思います。まさに、デジタル変革ですよね。単に、どんなツールを使うかだけではなく、それをどう使って行けば、今までに無い高いアウトプットが出せるのかが重要です。

デジタル化はメリットを考えながら

様々な業務をデジタルで保存することは、それを2次利用、3次利用できることに意味があります。例えば社内で共有すること、あるいは社外の人と共有すること。早く共有すること。と言うのもメリットになるかもしれません。履歴書を書いて、面接をして、結果を伝える。と言うこれまでのやり方とは違い、履歴書も何もなしに、いきなり自己紹介動画を自撮りでとって送ってもらうことで、応募から採用までを短縮する事が出来るかもしれません。
情報をオープンすることにより、イノベーションが起きる、いわゆるオープンイノベーションができるのはデジタル化の一つのメリットです。様々なノウハウをクローズドにしたいという意見もあるでしょうが、多様性をもった集団の知恵を活用し、意思決定をすることも一つの考え方ではないでしょうか?

2016年8月8日月曜日

LIVE UNIVERSEセミナー報告

 少し遅くなりましたが7月26日に行われましたLIVE UNIVERSEのセミナーの報告をしておきます。今回は、外食業界にターゲットを絞りまして、LIVE UNIVERSEというサービスのご案内をさせていただきました。

 ゴールデンマジック様がこの春から採用をしており、店舗の運営やレシピのマニュアルを全て電子化をしてオンラインで見れるようにしました。「電子化」といっても単にマニュアルをPDFにして公開しただけではありません。最近は多くの人が、スマホを持ってますね。そしてそのスマホで動画を見て様々なニュースや情報を取得することが当たり前になりました。それを、なんと業務にも応用しようというものです。



 紙のマニュアルとは違い、動画はエンターテイメント的な要素が多くなります。直感的に情報が入ってきます。動画を使い慣れた、若い人や、日本語の少し不慣れな外国人の従業員には大変好評とのこと。セミナーではLIVE UNIVERSEの導入により、退職するパートナー(ゴールデンマジック様では非正規の従業員をパートナーと呼んでいます)が少なくなりました。ゴールデンマジック様によると、パートナーが退職する一番の理由は、「仕事内容がわからない」や「教えてもらえない」だそうです。


 最近のアクティブな若者は、「教えてもらえなく」ても、自らが動画を利用して、自己学習をするんですね。それゆえ、LIVE UNIVERSEを導入してから、退職するパートナーが少なくなりました。これは、店長やエリアマネジャーには朗報です。店長やエリアマネジャーは様々な仕事を抱えています。パートナーの採用や、店舗運営にまつわる様々な仕事を会社から任されて、いわゆる出来る社員や出来るパートナーがエリアマネジャーや店長になります。そこに、ITという武器を持ったユニリタが、店舗の運営にまつわる様々な業務をサポートすべく、LIVE UNIVERSEというサービスを開始しました。





 今後は動画だけではなく、店舗とのコミュニケーションを良くするための様々な仕組みをLIVE UNIVERSEに実装していく予定です。例えば、Google AppsやOffice365と連携をして、メールでの情報共有やファイルの共有、LINEやFacebookを通じてパートナーとのコミュニケーション、そしてエリアマネジャーのためには、売上情報や原価管理など、店舗運営には様々な情報が必要となります。これらはLIVE UNIVERSEがinfoScoop SmartxPortalを基盤しているために可能となります。

 先ずは、ゴールデンマジック様のように、店舗運営に必要なマニュアル一式を動画として店舗スタッフに提供をし、その効果を感じて見てはどうでしょうか?


お問い合わせは、ユニリタホームページにて。
(コメント欄で「LUに関するお問い合わせ」とご記入ください)

2016年6月9日木曜日

アジャイルサムライはスプリント、ユーザストーリー、ベロシティを駆使する


Be.Cloud通信戌亥です。
最近は、Be.Cloud通信と言いながら、アジャイル開発のことばかりを書いていますが、クラウドサービスの開発には最も重要であると考えいますので、もうしばらくお付き合いのほどを。

開発の単位はスプリント単位で

 スクラム開発は1週間とか2週間の単位で開発を進めます。これをスプリントと呼んでいます。アジャイル開発では一般にはイテレーション(反復)と呼ぶこともあります。我々は2週間を1つのスプリントとしていますが、 アウトプットはこの単位で作られます。つまり、2週間単位で、計画、設計、プログラミング、テスト、レビューを行います。

 レビューでは、実際に動くデモをレビューする事が重要です。この事があるため、アジャイル開発では「機能」とは言わず、「フィーチャー」と呼んでいます。つまり、計画ではどのフィーチャーを実装するかを決定して、レビューではそのフィーチャーが実装できたかどうかを確認します。結果、本番へのデプロイメントをしない場合もあるかもしれませんが、基本、2週間単位で計画を立てているし、またクラウドサービスですので、デプロイメントは出来ます。

お客様と開発者の共通言語はユーザストーリーで

 さて、この2週間単位で作るプログラムの粒度ですが、これが結構悩みます。スクラム開発では、フィーチャーをユーザストーリーとして定義し、その単位で開発を行います。もちろん2週間での開発ですので、できる限り粒度は細いほうがいいのですが、あまり細かくするとレビュー(動くデモの確認)が出来なくなります。フィーチャーという言葉を使っているのは見えるデモとして定義した方が良いので、その粒度にユーザストーリーを作りましょうという事だと思います。

 もう1つの悩みの種は、プロジェクトの計画時に定義したユーザストーリー(マスターストーリー)が必ず実装されるか?という問題です。いや、実はこの問題が、アジャイル開発とウォーターフォール開発の確執を生んでいる最大の問題です。

 ウォーターフォール開発では、「最初にお客様と約束をしたことは絶対だ!」が基本です。例えばお客様が、途中で「この機能は必要なくなったので、代わりにこの機能を実装してほしい」と言ったとすると、要件変更のプロセスが走ります。時には、全体スケジュールの変更も行われるでしょう。

 しかし、アジャイル開発の場合は、「最初から要件を全て洗い出したとしても、時間とともに変化をするのだから、要求の変更には柔軟に対応すべきである」が基本です。開発者の中には、「そんな事をしたら、お客様は永久に要求をしてきて、プロジェクトは終わらないじゃ無いか」という反応があると思います。いわゆるデスマーチと呼ばれるものです。

つまり、アジャイル開発の場合はお客様との信頼関係が必要です。

1. 開発者は要求を柔軟に受け入れる
2. お客様は新しいストーリーを追加する時には、必ず既存のものを削る

この様にすれば、お客様は、何でもかんでも要求リストに加えることをしないでしょう。また、技術者にとっては、大きな要求リストはデスマーチ、つまり死のロードを意味する為、要求リストが大きくなってくると、何でもかんでも否定をし始めます。つまり、どうでもいいフィチャーをユーザストーリーとして持ち込まない代わりに、持ち込まれたユーザストーリーは真摯に対応することが重要なんです。


開発の生産性はベロシティポイント

 前回のブログ「スクラム開発でバッファを最小限に」では、私は「人日」で説明しましたが、スクラム開発では、「ベロシティポイント」を使います。アジャイルサムライと言う著書では、絶対的なメジャーメントよりも、相対的なメジャーメントがいいとされています。ベロシティポイントにすると、ユーザストーリーの難易度を示すことが出来ます。人日や人月に慣れている開発者にはわかりにくいでしょう。結局は、人日や人月に変換するのでは?というご指摘はごもっともですが、「このユーザストーリーは何人日で出来ますか?」「はい、2人日です。」「それでは、今週の金曜日にできるのですね。」「いいえ、次のスプリントの終了は2週間後の水曜日なので、再来週の水曜日までお待ちください」と話しがややこしくなります。人日はある意味絶対メージャーと解釈することもできるため、この様なことが起きます。開発者が言ってる「人日」を正しく翻訳すると、「1日7.5時間を全てプロジェクトに使えるとして、開発終了には1日かかります」ということですが、お客様の「人日」は「スタートして次の日には終わってる」ということになります。解釈が異なります。開発者の「2人日」は、「2フル・スタンダード・ワーキングデイ・ポイント(フル=時間を100%プロジェクトに使える/スタンダード=残業時間は予定には入れない/ワーキング デイ=もちろん土日祝は予定には入れない)」と解釈しましょう。

 「人日」で答える代わりに、「このユーザストーリーは2ポイントです。」「そうですか、このスプリントはあと何ポイントこなすことが出来ますか?」「はい、あと2ポイントこなせます。」そうすれば、「他に優先順位の高いストーリーがない限り、再来週の水曜日には終了できますね」「はい、問題ありません」となります。「こんなにうまくいくのかよ」と疑問を持たれている方は、是非スクラム開発を経験してみてください。

 さて、前々回のブログで、「スクラム開発でペースを作れ!」を紹介しました。そうそう、5キロを何分で走れるかですね。5キロを20分でしか走れない人に、監督が「15分で走れ!」と言ったらどうなるでしょうか?まさに、デスマーチが始まります。同じ様に、1スプリントを15ポイントしかこなせないチームに20ポイントのユーザストーリーを課すとどうなりますか?デスマーチが始まります。じゃ、1スプリントをどれだけで走れるか?が課題となります。幾つかのスプリントをこなしていくと、15ポイントしかこなせないと思ってたチームが、18ポイントこなせると気づくかもしれません。こんな時は、チームのペースが上がったと喜びましょう。スクラム開発チームの生産性が何かの効果でよくなったと考えられます。技術者が新しいテクノロジーに慣れてきたのかもしれません。または、お客様の業務を理解し始めて、ユーザストーリーを詳細の仕様に落とし込むことがうまくいき、手戻りがなくなってきたとも考えられます。
 但し、間違っても、残業をし無理してベロシティポイントを上げようとしないでください。もちろんバッファを使い切った時にやむなく残業をする場合はあるかと思いますが、無理してベロシティをあげようとすると、チームのペースが崩れます。ベロシティポイントをあげるのは仕組みを変えたり、知恵絞ったり、経験を積んだりしながらあげていってください。

チームワークを大切にしよう

 ウォータフォール型の開発では、WBSのそれぞれのタスクに担当者が書き込まれます。つまり、ある担当者はそのタスクが終わると、次のタスクを実行するわけですが、次のタスクのまでスケジュールに余裕がある場合はどうするでしょうか?自分のタスクは早めに終わって、次のタスクまで時間がある人は、別の仕事をするか、他のタスクの準備をするか、つまり開発者の自由に使うかもしれません。これが前回のブログ「スクラム開発でバッファを最小限に」で話しました「バッファ」の使い方になります。ウォータフォール開発では、自分で作ってあったバッファは自分で勝手に消化されてしまう可能性があります。 

 アジャイルな開発ではチームでストーリーをこなしていくため、1つのタスクが終わると、バックログから優先順位の高い新たなタスクを取り出して実装を始めます。この場合、バッファを活用してどんどんと開発を進めることができ、バッファはどんどん貯まっていくことになります。チームのためにバッファを貯めた人は評価してあげましょう。

 むむむ、この話を聞いて、察しのいい方はこう思ったのではないでしょうか?「優秀な技術者であるほど、損する仕組みが、スクラム開発なのですか?」どんどん、ストーリーをこなしていく技術者はどんどんバッファを貯めていくが、ストーリーが全く進まずに、停滞して、他の人に迷惑をかけ続ける技術者はバッファをどんどん食いつぶしていく。スクラム開発では、スプリント毎にアウトプットを出すために、チームワークが必要です。ベロシティポイントもチームでどれくらいのベロシティとなるのか?が重要となります。つまり、チームで少し経験が浅い開発者を教育して、ベロシティが上がれば、チームのベロシティは確実に上がります。

 このように考えれば、ベロシティは絶対的なメジャーメントよりも、相対的なメジャーメントとし、スプリント毎にポイントをトレースして、チームのベロシティがどのように変化しているのかを見ることも必要です。絶対に、チーム毎にベロシティを競わせることをしないでください。そのようにすると、残業時間が増えて、新たなデスマーチが始まるかもしれません。

2016年5月24日火曜日

スクラム開発でバッファを最小限に

Be.Cloud通信戌亥です。

 前回のブログは、「スクラム開発によりペースを作れ!」でした。スクラム開発には、従来のウォーターフォールにはない大きなメリットがあります。今回は「バッファ」の話をしたいと思います。

 因みに当社では、スクラム開発を基本としているため、スクラム開発と記載していますが、アジャイル開発と読み替えてもらってもあまり大差はないと思います。

 私が普段から大変悩んでいるのは、スクラム開発のメリットを話し出すと、やはり、従来型のウォーターフォールを得意としている人たちからはネガティヴな反応が出てくることです。その多くは「スケジュールが作れない」です。確かに、ウォーターフォール開発は、1番最初に工程表を作り、それに沿って開発をします。いわゆるWBS(Work Breakdown Structure)を作ります。しかし、これも結構厄介です。何故なら、全ての項目をBreakdownできればいいのですが、大きなプロジェクトになると、完璧なBreakdownが出来ません。また、プロジェクトを進めていく上で、障害となることもありますが、それを考慮したWBSを作るのは至難の技です。例えば、個別のエンジニアのスキルや予期しない問題の発生などは最初から予測することは難しく、遅延する可能性もある為、プロジェクトの全行程を完全にスケジュールすることは難しいのです。

バッファ

 そこで、多くのマネージャ達は知恵を絞ってバッファを設けます。「制約理論」を提唱したゴールドラットさんは、その著者「クリティカル・チェーン」の中でこのバッファを上手に説明してくれています。

 我々もよくやりますが、エンジニアに「このプログラムはどれくらいで作れる?」と聞くと、エンジニアは「(うーん、多分、5人日ぐらいと思うんだけど、少し見えない部分もあるので2人日余分に乗せて) 7人日です!」と応えます。このプログラムをAとしましょう。次に違うエンジニアに、別のプログラムBを同じように聞いてみると、「(10人日だと思うが、このPMは怖いんだよな、計画通りにつくらないと怒られるし、よし!) 13人日です!」そして、3番目のプログラマに、別のプログラムCを同じように聞くと、「はい、6人日です。(2人日ほど余裕を見てるけどね)」と多めに宣言をします。つまり、それぞれバッファを設けます。ここではこれを、「プログラミングバッファ」と呼ぶことにします。

 そしてプロジェクトマネージャは、総合テストの10人日(2人日のテストバッファを設けてある)を加えて、最終的に合計してみると7人日+13人日+6人日+10人日=36人日な訳ですが、もちろんプロジェクト全体のバッファ(ここでは「プロジェクトバッファ」と呼びましょう)を設けるので、「(5人日ほど上乗せして) 41人日でお客さんには出そう」となるわけです。もちろん値切り交渉の上手なお客さんにはここからさらに営業がのせる「営業バッファ」を設けたり、技術者のスキルによっては、さらにバッファを設けたりする(「スキルバッファ」)為、バッファはどんどん増えてきますが、今回はややこしいので、それは省きます。

 とすると、実際にこれだけのコストで済むかもと思われる、プログラムA 5人日+プログラム B10人日+プログラムC 4人日 + 総合テスト 8人日の合計 27人日に対して、41人日が提示されてしまいます。プログラミングバッファとプロジェクトバッファを合わせると14人日となり、大凡1.6倍の見積もりが提示されることになります。

 因みに、バッファはすべて悪ではありません。バッファと言うのは、製造業で言う在庫に当たるので(「クリティカル・チェーン」を参考)、不測の事態が発生した時に使えます。例えば、エンジニアがインフルエンザにかかってしまった場合は、そのバッファを使って、スケジュールを取り戻すことが可能です。


バッファを食い尽く理由(クリティカル・チェーンより)

プロジェクトを推進するにあたりバッファを作る事がよくある。それぞれの工程にバッファを作り、さらに全体でもバッファを作るために、全体の工程は2倍に膨れ上がる。しかし、それでもプロジェクトは遅れる。バッファを食い尽くしているからである。バッファを食い尽くす理由は、

1. 学生症候群
2. プロジェクトの掛け持ち
3. 作業の遅れは蓄積されるが、バッファは蓄積されない

が主な理由である 

バッファが多くなるのは計画曖昧である

 しかし、バッファが多すぎるとこれは無駄となります。どこかで聞いたことありますのね。そうそうジャストインタイムでは、在庫は「悪」とされていますが、バッファが多いと様々な問題を起こします。ここではその説明はしませんが、問題はバッファが多くなりすぎることと、そのバッファの使い方です。

 バッファを多く設けると言うのはどういうことでしょうか?つまり、計画が明確になっていないということです。計画が明確になっている場合にはバッファをそんなに多く設ける必要がありません。つまり、計画が曖昧である為にバッファを設けるのだと思います。よくリスクという言葉を使いますが、リスクと一言で片付けるのは、曖昧性を増やすことだと思います。リスクは何が起こるかわからないことを言いますが、バッファの中には起きることを想定しているバッファもあると思います。

スクラムでのバッファ

 我々がスクラムを始めた時に、私はなんとも言えない違和感を覚えました。その違和感は悪い意味での違和感ではなく、いい意味での違和感です。おそらく、実際に開発する人には悪い意味での違和感であり、開発を依頼する人にとってはいい意味での違和感になるのだと思います。

 その違和感は決まった日数でアウトプットを作り続けるということでした。我々の場合は2週間でした。2週間経つと、アウトプットが見れますが、次の2週間の新たな開発の計画もできあがります。今から考えるとその違和感というのは、「この2週間が一度守れなくなったらどうなるのだろう」ということだったんだと思います。つまり、たった2週間のことですが、その2週間が守れなくなると、後続の開発全てが遅れてしまうことを意味します。つまり、今この2週間に集中しないと、プロジェクト全体がどうしようもなくなるという違和感です。逆にみれば、後のことは考えずに、とにかく今の2週間をうまくやることを続けていけば、プロジェクトは遅延することなく、終わることができるといういい意味での違和感です。アジャイル開発を始めて経験する私には、このことが違和感としてこころに中に残っていました。これはまさに、バッファが小さくなっているということだと思います。バッファが小さくなっているからこそ、何か不足の事態が起きた時に、「どうするんだろう」と心配になっていたということです。もちろん、スクラムでも、ユーザストーリーに対してどれだけの開発が必要になるかをポイントで示しますので、実装が予測できないユーザストーリーにはバッファを設けます。しかし、ユーザストーリーは数日の開発に分割する為、バッファ自体が小さくなり、またバッファはあくまでスプリント単位であり、1回のスプリントで精算されますので、このバッファを次のスプリントに持ち越すことはできません。つまり、バッファは最小限にし、かつそのスプリント内で使い切ることになります。

 今回はプロジェクトの中で見込むバッファを中心に話をしてきました。もちろん製造業の中でも在庫は「悪」であるという考え方と、「必要不可欠なもの」という考え方があるように、ソフトウェア開発のバッファも必要という考え方があるかと思いますが、バッファが多すぎるということは、それだけ計画が曖昧であるということだと思います。最終的にソフトウェアを仕上げることが目的であれば、バッファを極力すくなくして開発をすることが、スケジュールを守る一番良い方法でると思います。