無料ブログはココログ

« 2012年11月 | トップページ | 2013年1月 »

[#TiDD] チケット駆動開発でちょうどいいプロセスをめざす - 「本当に使える開発プロセス」を読んで -

チケット駆動開発にふれた本が増えてきています(あきぴーさんの記事)。このうち「本当に使える開発プロセス 」ではテストの章でATDD(gihyo.jp BDDとATDD)やCI(Wikipedia)を含むALM(Wikipedia)の文脈で紹介されています。

アジャイル関連用語が多く出ていますが、帯には「ウォーターフォールでもない!アジャイルでもない!」と書かれていて、本文中にも以下の様に書かれています。

ウォーターフォールやアジャイルなど、特定のプロセスや方法論、お作法に捉われず、「ちょうどいい」と思えるシステム開発の進め方をデザイン(改善)することを目指します。(p.6)

第1章もシステム企画、要件定義、基本設計、詳細設計・プログラミング、テストという切に分かれていて、テストの節でチケット駆動開発に触れられています。
これは上流を強化したアダプタブルウォーターフォールの具体例とも言えるでしょう。構成としてはウォーターフォールなのですが、チケット駆動開発のところ(p.70)では

  • チケットをプロジェクトの情報の中心とする
  • チケットによる作業の割り振りと進捗管理を行う
  • チケットなしのコミットは禁止とする

と言う原則のほか、

チケット駆動開発では、バグやテストの情報だけでなく、要件や課題、変更要求といった情報に関するすべてのタスクをチケットで表現します。(p.71)

とあり、テストに限らないチケットの利用にも言及されています。

このあたり、書籍「チケット駆動開発 」の構成で悩んだところです。より具体的な内容を整理して書くと「本当に使える開発プロセス 」のようになりますし、チケット駆動開発を中心にするとプロセス全体を具体的に書きにくくなってしまいます。

閑話休題。このほかにもリズミカルな開発やCIとの連携によるALMの話。さらには、ツールはプロセス改善の「足がかり」と題して、「ツールはシステム開発の業務システムである」として、ツールの導入可否を判定するチェックリストと判定基準も載っています。このあたり、著者の知見がまとめられています。

最後に「本当に使える開発プロセス 」で目指すちょうどいいプロセスを目指す際のチケット駆動開発のメリットを挙げておきます。

スモールスタート(ハードルを下げる)

障害管理から始められ、プロジェクトの問題にあわせて順次拡張できます。まずは、プロジェクトの最も大きな問題を解決できる様に導入すると良いでしょう。

インクリメンタルな改善(継続的な価値の提供)

プラクティス間の依存関係が少なく、段階的に導入できます。チームがイメージできる範囲で導入を進めていくと良いでしょう。

最適化可能なバリエーション(ちょうどいいプロセス)

チケット駆動開発のゴールは一つではありません。様々なバリエーションがあります。チームにちょうどいいプロセスを実現できます。

今回は業務システムの開発に向けての本でしたが、それ以外の分野にもチケット駆動開発は有効です(赤羽根さんのIT全般統制の事例などは秀逸ですね)。

今後もより多くのチケット駆動開発の事例が公開される事を期待しています。


謙虚になりなはれ!

恩師にいただいた大切な言葉です。先日見つけたこの記事で思い出しました。

僕は自分が思っていたほどは頭がよくなかった - しのごの録

中高生の頃

そういえば、私が中高生の頃は自分勝手な生活を送り、我流の勉強しかしていませんでした。中学では目指す高校にギリギリだったのに、高校でも改めないで大学受験が迫って焦りましたが、時既に遅く、夢は叶いませんでした。

生意気だったのですね。困難な状況に陥って苦労したのに、ある方法で難を逃れるとそれで良いと思い込むのですね。そうなると手段が目的になり、それを守る事が自分のアイデンティティだと思ってしまったのです。

留学した時の話

時は過ぎ、30歳を過ぎて奈良先端大に留学した頃のことです。長年開発現場で働いた人間に取って、ソフトウェア工学は示唆に富む物ではある物の実際に使うには難しいものと言う印象でした。ついつい研究の議論でも生意気な事を言っていたのでした。そんな私に恩師は

「 謙虚になりなはれ!」

とたしなめられたのです。物事を教わろうとする者は謙虚に聞かないといけない。その事がわかっていませんでした。どうも他のOBの方で言われた方もおられるようで、ひとつのポリシーとしてもたれていた様です。

その後、仕方なしにおとなしくしていると、多くの事が学べました。私は現場のプロでしたが、先生方は研究のプロでした。どのように情報を集め、集めた情報で研究テーマを考えだし、実験をどのように行い、どのようにデータを分析し、どのように論文にまとめるか、知らなかった事をたくさん教えていただきました。

尊敬する先生

たくさん教わった先生は、私をたしなめてくださった先生の教え子で、尊敬すべき謙虚な方でした。大学院では、専門知識を得るだけでなく新しい人のつながりを得るなど、多くの事を学びましたが、「我々に教えられるのは、論文の書き方とプレゼンぐらいしかない」と言われていました。

そんな事はないだろうと思われるかもしれませんが、考えてみると書いた論文が採録されると言う事は、その研究に関しては誰にも負けない最先端の状態になるということです。たとえ指導教官であってもその研究は(たとえ一瞬でも)勝たないといけないのです。その状態になれば、もはや「読み書きプレゼン」しか教える事はなくなるのです。

「若い頃に教えてやっただろ!」と先輩ぶる人も世の中にはいます。しかし、大学の先生は追い越されるために学生を教えられ、その限界を認識されていたのです。そのような先生に対して、生意気な態度はありえないですね。

こだわりを捨てないと実現できない事もある

人はついつい「〇〇は××でないといけない」と決めつけてしまいますが、そう思った瞬間に成長が止まり、こなし仕事となって根性論が出てきます。

だれしも収入は多い方が良いし、名誉があり、地位が高いとうれしいでしょう。そして、服や装飾品、車や家、色々なこだわりがあるでしょう。そして色々なことで、許せない事もあるでしょう。それは、あなたにとって本当に大切な事なのでしょうか?

自分の人生で大切な物は何でしょう?きっと人によって異なるでしょうね。でも、その大切な物を守るためには、何かを捨てないといけない事もあるでしょう。守るのは大切な物なのですから、その時は捨てざるを得ません。その一つがこだわりなのかもしれません。

ビジネスと作る人との距離 - 第20回関西IT勉強宴会 その2 -

その言葉を聞いたのはXP祭り関西2009の平鍋さんの講演でした。日本と海外の違いについての質問に「ビジネスと作る人との距離が近く、同じリスクをとる」と言われていました。

ライブモデリング

先日の関西IT勉強宴会のライブモデリングで思い浮かべたのは、この言葉でした。ライブモデリングをされていた 渡辺幸三さんはモデリング支援ツール XEAD Modelerを開発されている方で、その方法論である三要素分析法のモデリングセッションでは、

ユーザーの発言にもとづき、それぞれのサブジェクトエリア毎にデータモデル、業務モデル、機能モデルの順にその場で手書きでまとめる

と言う事が行われます。このようなユーザーとの直接の対話は他の方法論でも見られます。要求開発のコタツモデルではトップ、業務担当、IT担当が膝を突き合わせる場を持ちますし、平鍋さんと共に要求開発宣言に署名されている神崎さんの書籍「顧客の要求を確実に仕様にできる要件定義マニュアル」に載っているRDRAでもモデルを用いた分析による全体像の共有や打ち合わせに触れられています。

良いソフトウェア開発は同じ方向を向く?

最近、ふと気になって@ryuzeeさんの

[Agile]あなたのプロジェクトはどのくらい「アジャイル」か?

を確認してみました。アジャイル開発でないと(少なくともお客様は)思っているのですが、微妙な項目がいくつかあったものの、完全に満たしていないのは以下の1つだけでした。

×チームは自己組織化されているか(他人の仕事のやり方を指示するような人は誰もいないか)

チームには、新人もいて指導する人が必要なので、仕方ないと思っています。もちろん、このチェックは[Agile]Agileってなんだっけ?(資料公開) に書かれている事を満たしているチームのチェック用だと思いますので、私のプロジェクトはアジャイルだと主張する気はありませんし、多くの項目は、お客様に恵まれているからだと思います。しかし、私が大切に思っている事は、アジャイルと共通しているのだと再認識しました。

また、以前、SEA関西XPJUG関西の協力を得て行った「CMM vs XP」のパネルディスカッションでも、それぞれを実践されている方の目的を反し合った結果、「なんだ、同じじゃん」という意見が出るなど、より良いソフトウェア開発を目指す開発者の思いは、どのような開発法であっても同じ物だと思いました。

結論

そこで、良いソフトウェア開発は、同じ方向を向くのではないかと思った次第です。特に、ソフトウェアは現実の世界の一部に組み込まれる物ですので、

良いソフトウェアを開発するには ビジネスと作る人との距離を近くする必要がある。

と言う事を再認識した次第です。



BPMSと業務システムの連携 - 第20回関西IT勉強宴会 その1 -

2回目の参加となった第20回関西IT勉強宴会のテーマは「BPM(ワークフロー)とデータモデリング」と題して開催されました。

上記のリンクにある通り、BPMとはビジネス・プロセス・マネージメント(業務プロセス管理)の略語で、業務の手順をワークフローとして整理して可視化することで業務を改善しようという手法です。

今回は、このBPMを支援するBPMS(ビジネスプロセスマネジメント・システム、あるいはスイート)の一つであるQuestetraを久保敦啓(MakeGood作成者)さんが紹介されました。BPMSについては@ITの5分で絶対に分かるBPMSをご覧ください。

その説明を受けて、渡辺幸三(ディービーコンセプト)さんがイメージされた棚卸しのライブモデリングをされ、さらにそれを受けた Questetraのアプリケーション久保さんが作られて全体で議論されました。

多くのBPMSがSOAなどを用いたトップダウンなシステム化を目指しているのに対し、Questetraは、ボトムアップに人間系を意識したシステムです。業務プロセスをモデル化し、それを元にアプリケーションを開発して実行、分析できます。また、DBMSやWeb APIを介して外部と連携できます。ライブモデリングではこの連携を利用して、棚卸しのステータスの変化を Questetraで管理する想定でアプリケーションが考えられました。

アプリケーションは、DBMSのレコード(今回はテーブルが一つでしたが、複数をテーブルとして利用する事も可能らしい)をダウンロードし、プロセスモデルに沿って実行し、DBMSにアップロードする想定のシステムでした。

BPMは単に実行するだけでなく改善を目的に行われます。Questetraでは各プロセスの実行時間を集計できますので、その分析結果を元に改善する様です。

ソフトウェアプロセスモデリングをかじっていた人間としては、プロセスモデルと考えるとCSCWのような協調作業の支援があるのかどうか気になるところですが、Questetraは案件データを参照できる社内SNS機能が用意されている様です。

今回はシンプルなステータスを管理する物でしたが、複雑なワークフローを管理する事もできる様ですので、様々な活用が期待できると思います。

渡辺さんのライブモデリングでは、モデリング時には既に画面がイメージされていました。これに関しては色々と考えた事がありますので、別途、まとめました

[#TiDD] 最近のソフトウェアを考えるとアジャイルに向かう

技術発表の改良パターンの一つに「口で説明した通りに修正する」と言うのがあります。文献を色々と引用するうちにわかりにくくなってしまい、指導教官から結局どういう意味かを問われて説明すると、「じゃあ、その通りに書きなさい!」と言われるパターンです。

それにならって、先日のCCPMのお話の後の懇親会で「なぜ大手ベンダーがアジャイルをするか?」という議論の犀の説明をまとめておきたいと思います。堅めの説明としては、ソフトウェア工学の視点ビジネスの視点ハンフリーさんの要求の不安定性の視点で既に書いていますので、そちらをご覧ください。

さて、最近のソフトウェアは、機能が年々増大しています。また、それに反比例する様に予算が削減され、開発期間が短縮、投入される工数も少なくなっています。この流れの中で開発の始めに一括請け負いするリスクはドンドン増大し、従来の開発方法は限界になっています。

不確実コーンで考えると、より広く、より短くなっています。

Photo

このような状況で開発するには、少しずつ、確実に、開発を前進させていく事が必要です。具体的には、以下のような対策が必要です。

少しずつ確認する

段階的に開発して、確実に動作する部分を増やします。アジャイル開発の様な繰り返し開発やプロトタイピングが有効です。

経験やアイデアを蓄積する

コミュニケーションを向上し、チケットやWikiに記録する事で、開発者の能力を向上します。

開発の効率化

様々な自動化、より高機能なフレームワークや言語の導入などによって開発を効率化して生産性を高めます。

信頼性の向上

自動テストや静的解析によって信頼性を向上し、手戻りを減らします。

このように考えると、アジャイルの「ライトウィング」と「レフトウィング」が見えてきます。必ずしも厳密なアジャイル開発でなくとも、アジャイル開発を知らなければプロジェクトの成功は見込めなくなっているのです。

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

情報を得るには Give & Give - 発表のモチベーション -

なぜ、私は色々なところで発表したいのか?ふと、気になって考えてみました。

人によって色々な人がいるでしょう。有名になりたい、人脈を作りたい、実績が欲しい、理想とする有名人に近づきたい、、。どれも、私にはピンときませんでした。そこで、昔を振り返ると、少しヒントが見つかりましたので、まとめてみます。

わかった事を伝えたい。まとめたい。

会社に入りたての頃はjusやSEAでviのTipsや入門的な内容、UNIXのことなどを発表をさせていいただく機会がありました。当時は勉強する事が面白くて、わかった事を他の人にも伝えたくて仕方がなかったと思います。

会社の人の発表を見る機会も多かったので、見様見まねで発表していました。実際に発表するとなるとわかっていないと発表できませんから、発表準備が結構勉強にもなりました。

人の役に立ちたい。

FM-TOWNSというマイナーなパソコンを使っている時は、フリーウェアなども公開しました。ちょっとしたツールとか、プリントユーティリティとか、会社の人がfjで流したTeXのドキュメントを変換したものとか、色々です。

マイナーなパソコンの世界では、自分の欲しい物は他の人も欲しい物で、きっと誰も作っていないのですから、人の役に立ててとても楽しかったです。日頃の仕事では自分の作ったソフトウェアやシステムがどのように役立っているか知る機会が少なかったので、ダウンロード数の増加やコメントがいただけるととても幸せでした。

もっと知りたい。

私が発表する理由で最も大きいのは、「もっと知りたい」という理由からです。上に書いたように発表すると勉強になるだけでなく、情報発信する事で情報が集まってくるからです。そう思う様になったのは、AMIGAという当時としては珍しいマルチタスクで動くパソコンを買った時でした。

プログラミングが目的でなく、レミングスなどの最新のゲームで遊んでいれば英語の勉強になるだろうと、軽い気持ちで買いました。AMIGAはとても奥の深いパソコンで、情報を得ることで色々な世界が広がりました。

私の情報源はAMIGAのユーザー会に入っていた会社の先輩でした。その先輩が言われるには「情報を得るには Give & Give」、情報発信を続ける事で新しい情報が自然と入ってくるとのこと。

確かに私の過去を振り返っても、それは事実でした。発表した後の懇親会では、発表に関する話題で盛り上がりますし、ソフトを公開すればコミュニティの掲示板で関連の話題が出ました。また、その後の研究発表でも、研究へのヒントを得たり関連研究を教えていただけるという経験をしています。

情報を得るには Give & Give

ふつうなら「Give & Take」と考えるのでしょうけど、そうは簡単に行きません。見返りを期待せず、とにかく自分から情報を提供するので情報が集まってきます。どこに行っても最初は初心者ですから、教えるのではなく、発表させていただくつもりで情報提供します。

ある先生が学生さんに「3回行けば、その分野の人と認識してもらえる」と言われていました。どんなに口べたな人でも、3回も発表させていただく機会があれば、そのうちに仲間であると認識してもらえます。

発表する機会を得るには、他の人にない何かが必要です。発見や発明かもしれませんし、新しい観点かも知れません。もちろん、経験して得た事は他の人にない情報です。聞く人が活用できる形で発表できたなら、多くの質問によって理解が深まり、関連情報も集まるでしょう。

情報発信は楽しい

いつもそんな事ばかり考えて発表している訳ではありませんが、これまでを振り返ると、心のどこかで考えていました。

「情報を得るには Give & Give」

だって、知らない事がわかったら楽しいじゃないですか。私が発表を続けているのは、ただそれだけでした。

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

CCPMのグッときた話 - TOC/TOCfE関西分科会 -

TOC/TOCfE関西分科会~CCPMでもっと工期短縮!!~」に参加しました。

CCPMは以前から記事などで知っていたのですが、大きく誤解していました。工期短縮が目的なので、乾いた雑巾を絞るような方法ではないかと勝手に思っていました。

そんな誤解があったものの、今回はアジャイル開発に興味を持つ人も多く参加されていて、なによりアジャイルラジオの東さんがされていて、なかなか楽しそうなので参加してみました。

CCPMCCPM(クリティカルチェーン・プロジェクトマネジメント)は質的なスコープ変化がなく、外部的な不確実性が少なく、期間とリソースのボリュウムがある程度あり、タスクに依存関係があるプロジェクトに向いている方法です。

CCPMの概要については「情報マネジメント用語事典」、「知っておきたいIT経営用語」、BeingManagementのマンガなどを見ていただくとして、今回の勉強会に参加してグッときた話を私なりの解釈でまとめます。

見える化である

見える化というのは単ある可視化ではなく、問題点が見える様にする事です。CCPMではスコープ(仕様)とリソース(人の割当?)を固定しておいて、納期(期間)を調整します。開発の効率化を実践すべく、目標とすべき計画とバッファを見える化し、時間軸の管理によって問題を明確にします。

従来の見積もりでは、理想的な開発期間と何らかの問題が生じた際のリスクをあわせたおおよその工数を見積もりとしています。CCPMでは理想的な開発期間を目標として線を引き、リスク分はプロジェクト全体の余裕バッファとして管理します。目標とリスクを分離して見える化することで、スケジュールに合わせてだらだら開発する事や、よかれと思って不要な作業をしてしまう事を防ぎます。

また、プロジェクト開始が遅れた際も、プロジェクトバッファはいじらないそうです。これはグラフを用いた管理を容易にするほか、プロジェクトの状況を見える化することが重視されているからでしょう。

計画時に工期短縮がきまる

特定の作業間のボトルネックであるクリティカルパスではなく、プロジェクト全体の期間を決めるクリティカルチェーンを管理します。また、クリティカルチェーンを守るために、チームで協力します。

柴山さんらのインタビュー記事にもありますが、プランニングポーカーを活用されるようです。フィボナッチ数列になったトランプ状のカードを見積もりに応じて示す事で、仕様の認識ずれをなくすだけでなく、より良い方法を発掘します。

計画時に作業の依存関係を認識し、作業の平準化をしながら計画します。それは私がイメージした乾いた雑巾を絞るのではなく、小豆と大豆が入った升をトントントンとつめていくようなイメージを感じました。そこでできたバッファは可視化され、管理されますので、浪費される事なく、結果的に工期が短縮されるのでしょう。

メンバーを活かす

講師が市谷さんと柴山さんだった事もあるかもしれませんが、アジャイル開発の話を聞いているような気がしました。リーンもスクラムもCCPMを包含するTOCもTPS(トヨタ生産方式)から生まれたと言われていますので、当然かもしれません。

マルチタスクになるのであれば、分割してシリアル化します(スクラムでも良く言われる事ですね)。また、理想の開発時間とバッファを分離する事で、リスクを個人の責任からプロジェクト全体の責任へ移します。スクラムを組む様にチームが一丸となり開発に立ち向かいます。

そして、柴山さんの説明の中にあったボスが責任を持つというスタンスは、サーバントリーダーシップそのものだと思いました。

全体を通して

アジャイル開発が納期とリソースを固定し、スコープを調整して機能を積み上げるボトムアップな開発方法であるのに対して、CCPMはスコープとリソースを固定し、納期の調整可能な計画を立てて効率化するトップダウンな管理法です。

ボトムアップな方法は共通化が容易な反面、全体をきれいに構成する事が難しいと言われています。たしかに、アジャイル開発でアーキテクチャが重要だと言われています。

一方、トップダウンな方法は全体がきれいに構成できるものの、冗長なモジュールができ易いと言われています。そこから類推すると、プランイングポーカーを利用してより効率的な方法の発見を目指すことは、トップダウンでは全体を効率化し難い中で、非常に重要な方法なのかもしれませんね。

さて、これまでの思い込みだった「乾いた雑巾をしぼる」イメージですが、すくなくとも柴山さんの発表からは感じられず、どちらかというとより良いチームを構築されている様でした。

そういえばCMMブームの際にも私はCMMにあまり良いイメージを持ちませんでした。しかし、実際にはそれをより良い方向に活かされた方も多くおられました。プロジェクト管理の方法はプロセスプログラミングのツールにすぎず、その方法をどのように実践するかにかかっているのでしょう。

おまけ

最後に、懇親会での話題を書いておきます。CCPMによって工数がかからなくなった場合、その利益はどこに行くのか?という話題がありました。請負なら受けた側の利益になって良いはずですが、お客様が期間短縮のメリットだけで納得していただけるか難しいところがあるかもしれません。

そもそも契約上の見積もりは最長をとるのか、最短か、あるいは平均か、どれがよいのでしょう。また、準委任(期間)契約の場合、売り上げが減る事になりますし、効率化へのモチベーションが低くなる可能性もあります。このように考えると、単純な人月だけではない契約が必要なのかもしれませんね。

そのあたりも含め、今後も実践されている方からもっと色々と聞いてみたいと思いました。

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

技術者は考える仕事 - プレゼンテーションのペースと間 -

技術者の仕事は考えるのが仕事です。既にある物をそのままどこかに当てはめるのではなく、その構造や考え方を抽象化して理解して新しいモノを想像する仕事です。

技術者を相手にプレゼンテーションする場合、ついつい頑張って色々詰め込もうとしてしまいますが、それは考える事が仕事の技術者に本当に良い事なのでしょうか?

ニュースバラエティ

かつてニュースバラエティがはやりだした頃、コメンテーターの「xxではないでしょうか?」という言葉が、視聴者の思考停止を誘っていると批判されていました。

ニュースを報道するだけでなく、わかり易い様に様々な工夫がされた解説があり、そしてキャスターの結論まであると、見ている人は情報を受け入れるだけでいっぱいいっぱいになって、考える事ができなくなるのでしょう。

ある大学の先生の授業

ほとんどの大学の授業がパワーポイントやMagicPointで行われる様になった頃、板書にこだわる先生がおられました。その先生曰く、「パソコンでやるといっぱい詰め込めますが、人間が理解するスピードを考えると板書しながらがちょうど良い」と言われていました。

多くの先生が詰め込みだったのに対して、その先生の授業はポイントをしぼられていましたので、とてもわかり易かったのを覚えています。他の先生の授業の後は、何も話さないか、内容がわからなくて確認し合う事が多かったですが、その先生の授業の後は、「あれは違うと思う」とか「あれ知ってた?」など、意見交換をしていました。

OHPシートに手書きの時代

こんな時代を知る人も少なくなりつつあるかもしれません。昔はOHPシートという透明なシートにマジックで書き、専用のプロジェクターで投影していました。手書きなので枚数がかけないですし、OHPシートは高い物だと1枚100円ぐらいしていましたので、当時は1枚あたり3分ぐらいかけてゆっくり話していました。

レーザーポインターもありませんでしたので、シートの上でペンをずらしながら1行ずつじっくり離していました。イラストを描く事もありましたが、きれいな写真などはありませんでした。暗い部屋で読みにくい字をみんなで眺めながら、じっくりと話を聞いていました。話を聞きながら、行間を考えながら聞いていたので、ディスカッションも盛り上がりました。

パワーポイントを使う研究発表

パワーポイントを使う研究発表は1枚1分ぐらいが多いようです。このくらいのスピードになると、きれいな構造に整理されていても内容を咀嚼するだけで必死になります。

すると出てくる質問は、前半の問題設定に関する疑問か、説明の追加を求めるコメント、将来の展開など、質問もパターン化されてしまいます。そこで20分の発表に20分の質問が割り当てるという研究会もありました。ゆっくりと質問や議論をしましたので、内容を深く理解できました。

技術者向けのプレゼンテーション

「魚を与えるのではなく、魚の取り方を教える」と言われますが、技術者へのプレゼンテーションはどうあるべきなのでしょう。上に述べたような事を考えて、これまで1枚1分以下だったのですが、最近はなるべくゆっくり話す様にしています。しかし、話したい事も多いので、これが難しいのですよね。

そこで、今日見つけた方法が、以下のページです。

「分かりやすく解説」する前に「困って」もらいましょう、という話
http://blogs.bizmakoto.jp/kaimai_mizuhiro/entry/5856.html

これまでペースだけを気にしていましたが、考えるためのいわば間を与えると良いのかもしれません。著者の開米さんは、こんな方法の記事も書かれています。

相手が思わずとポカーンとするような絵を見せる
http://bizmakoto.jp/bizid/articles/1208/08/news012_2.html

技術者向けのプレゼンテーションへのヒントをいただきました。もし、デブサミで発表できたら、やってみようと思います。

[#TiDD] オープンになったデブサミに@akipiiさんと応募しました #公募セッション

デブサミことデベロッパーズサミットに「チケット駆動開発の本質」という講演セッションで応募しました。ここでは、デブサミへの思いを書いておきたいと思います。

デブサミとはなにか

「エンジニアの知的交流を促進することで、世の中がもっと豊かになることを目指して年1回開催される、ITエンジニアのお祭り」だそうです。詳しくは、はてなキーワードを見てください。

デブサミを知ったとき

私がデブサミを知ったのは、アジャイル1次ブームを通じて知り合ったXPJUG関西の方からだったと思います。「デブサミに行かなかったのですか?」と聞かれ、詳しく聞くと東京で開催されたイベントで、自費で東京まで往復したとのこと。

地元のイベントの参加費ならまだしも、なぜ東京まで私費で行くのだろうと思いました。そこで、調べてみると、そこにはそうそうたる講演者が並んでいて、非常に魅力的なイベントでした。

当時はどちらかというとアカデミアに近かったことや東京での開催だけだったので、その後も参加された色々な方のお話を興味深く聞いていました。

デブサミに注目する理由

1) 「アカデミアと産業界をつなぐ」から「現場とマネージメントをつなぐ」へ

私の尊敬するかつての上司は、ソフトウェア工学の世界でアカデミアと産業界をつなごうとされていました。ひょうんなことから論文を書く様になった私も、元上司の後ろを、とぼとぼと歩んできました。

元上司が関わったソフトウェア技術者協会(SEA)やjus、SPIN、その他海外の研究者を着込んだコミュニティ活動は、アカデミックの世界と産業界をつなぐことに大きく貢献し、社会的に大きな成果を上げたと思います。

特に、私が委員長をさせていただいた事もあるSEA主催のソフトウェアシンポジウムなどでは、研究者と産業界が集まり、多くの意見交換が行われていました。産業界からは現場の方も来られましたが、管理職や教育・管理部門の方も多くこられていました。

もちろん、組織的に新しい技術を導入していく事は必要です。しかし、現場をどうするかという視点だけでなく、現場がどうするかの視点も同時に必要ではないかと思っていました。

その後、私が現場に異動したとき、自分がすべき事を考えました。もちろん、大した事はできないかもしれませんが、自分ならではの目標を考えたのです。それは

「現場とマネージメントをつなぐ」

ということです。現場とマネージメントが上下関係ではなく、お互いに交流し、技術論を通じて、より良い関係になる必要が必要だと思いました。

デブサミに期待しているのは、色のついていない現場の人の集まりだと言う事です。1000人を超えるようなイベントと言えば、特定分野のコミュニティのシンポジウムか、企業中心の展示会、あるいは学会がほとんどです。

これに対してデブサミは、出版社の主催ながらも賛同するライバル社も本を売ってたり、複数のコミュニティがブースを持つなど、比較的色のない集まりで、現場の人たちに向けたイベントが開催されています。

2) コミュニティをてこにしているデブサミ!

かつてソフトウェアシンポジウムのプログラム委員などをしていた時は、ソフトウェアに関する全般を扱っていましたが、論文を査読するなど若干アカデミックよりな集まりでした。また、発表者を集める方法は、基調講演を除いてオープンに論文・報告を公募していました。論文を集める際にはプログラム委員の人脈を利用してお願いもしましたが、様々な分野からの論文投稿がありました。

プログラム委員は論文・事例を集めるほか、査読基準に合わせて点数をつけていました。複数の査読を受けた論文・報告はプログラム委員長が集計し、合否判定と発表の組み合わせをプログラム委員会で検討しました。

2年前に講演させていただいた時に垣間見た、デブサミのシステムは興味深い方法でした。デブサミはトラックごとに担当の委員がおられて、その方を中心にプログラムが組み立てられていました。全体のコーディネートがされているものの委員の方が担当トラックの講演者を決めて依頼されている様でした。

この方法は委員の所属するコミュニティの人脈を活かす方法で、その分野の目利きが、ホットな情報を提供できる人を探す方法です。この方法だからこそ、そうそうたる講演者を集める事ができるたでしょうね。開発に関係する多くのコミュニティがつながって大きなイベントが実現されていたのです。

3) そしてオープンに

デブサミの方法は全体のコーディネートやスタッフ間の協力があるにしても、委員のセンスや人脈に依存する方法なので、方向性や雰囲気にある程度偏りができることもあったたと思います。もちろん、それが良さでもあるのですが、たまに違う話も聞いてみようとすることで、新しい刺激を受ける事ができると思うのですが、それが難しくなってしまいます。

そこで(なのかどうかは、中の人でないので知りませんが)、登場したのが公募枠です。発表者を公募する事で、様々な分野の発表者が集める事になると思います。

また、「いいね!の数を参考にデブサミ2013コンテンツ委員会で最終判断を行います。」とされていますので、参加者の聞きたい内容を中心に選ばれるようです。より幅広い講演を通じた、より広い交流が期待できます。

「いいね!」もしくは応募をお願いします!

このように多くのコミュニティをてこにして開催され、現場の開発者が集まるデブサミが、オープンになりました。この機会を逃すことはできません。私も「現場とマネージメントをつなぐ」事を目指して、応募しました。

内容はチケット駆動開発で、本を共著した小川さんと二人で講演を希望しています。チケット駆動開発はチームの管理であるとともに、開発者自身の管理でもあります。

開発者の能力を最大限に生かして、開発を効率化するだけでなく、それをチーム全体の管理につなげることができます。現場とマネージメントが対立するのではなく、助け合い、いや、さらに進んで自分たちで管理して進めていけるようなチームが構築できるのです。

ぜひ皆さんの「いいね!」をお願いします。facebookのDevelopers Summit 2013 公募セッション応募ページで、

Devsumisubmit

をさがして「いいね!」を押してください。

あるいは、あなたも応募してください。12月10日までいいね!・応募ができる様です。

[#TiDD] 年末放談会「ソフトウェアビジネスのパラダイムシフト」SEA関西プロセス分科会

第50回を迎えたSEA関西プロセス分科会。今回は50回記念という事で第1部が世話人の阪井と小川さんの講演。第2部がSEA名物の年末放談会でした。

第1部「チケット駆動開発」

阪井「挑戦の道具としてのチケット駆動開発

私の発表は放談会につながる様に、1990年代から続いているパラダイムシフトを踏まえて、チケット駆動開発を新しい環境、実装方法、業務に挑戦するために、チケット駆動開発をどのようにテーラリングすれば良いかをお話ししました。

小川さん「チケット駆動開発のフレームワーク~現場の経験知からパターン言語へ
http://www.slideshare.net/akipii.oga/4redmine

ここのところ、小川さんはチケット駆動開発を価値やプラクティスで整理しようとされています。私は3回聞きましたが、どんどんこなれてきている様に感じました。これからに期待しています。

第2部 年末放談会「ソフトウェアビジネスのパラダイムシフト」

放談会はプロセス分科会が始まる前、たぶん1990年ごろからやっています。日頃のSEAは講師を中心に発表と少なくとも30分以上の質疑応答で、そういう真面目な感じの分科会をしています。とはいえ、忘年会や新年会の前は少し羽目を外して自由な議論がしたいと、話したい人が順に前に出て言いたい放題、聞く方も自由に議論をする、といった形の時間を取っています。

今回、前に出たのは、司会をされた小林さん、講師の小川さん、そして阪井です。

小林さん「ソフトウェアビジネスのパラダイムシフト

スライドが公開されました。最近のソフトウェア開発にまつわる色々な流れについて語られました。その中でRubyのまつもとさんの書籍にも書いている話としてCAP定理のお話をされました。

小川さん「最近感じる事」(ブログ

このお話で特徴的なのはDOAですね。小林さんのお話と共に後で語ります。

阪井「[#TiDD] アジャイル開発が注目される理由

予定していなかったのですが、昔のブログのお話をしました。開発のリスクをどのように分散するか、その際に企業の利益を確保するかという事を考えると、ユーザ系企業とベンダーの提携や合併が進むと思っていましたが、やはりそうなってきてますね。とお話ししました。

未来を考える

放談会で大きな刺激を受けました。色々考えると、パラダイムシフトには方向性のある物と揺らぎのある物があると思っています。

小林さんと小川さんのお話を聞いて思い出したのが、RISC CPUです。かつてはCPUが効率的に使えないのは、CISC CPUの命令セットが複雑なためであるとして、シンプルな命令セットにしたCPUが作られました。当時は革新的でそれ以外は考えられないとブームになりました。しかし、短期的には大きなシェアをとったものの、CISC CPU特にインテル社がその技術を取り込んで高速化を図った事から、結果的にインテル社の寡占が進みました。

同じ様に、RDBに与えられた制約を外す事で、NoSQLは高速に大量のデータを扱える様になりましたが、それをベースに複雑なクエリができる様にする事や、RDBとの組み合わせで高速化を図る事もある程度増えるのではないかと思っています。

この揺らぎというのを考えると私の発表に挙げたリスクの各分野で未来が予測できます。

環境

ホスト、PCでの分散、サーバ+X端末、ワークステーションによる分散、クラウド、というように集中と分散はこれまでも繰り返されてきました。これからが分散だとすると、HTML+Javascriptのように端末側のリソースを使う技術が増えるのでしょう。

実装方法

実装では機能中心とデータ中心の揺らぎがあります。また、ボトムアップとトップダウンという揺らぎもあります。アジャイル開発を見ていると、ストーリーという機能的な分割中心のボトムアップですので、ブームのさらにその先には上にあげた新しい形でのデータ中心アプローチや、複数の組織を統合するためのトップダウンアプローチなどが出てくるかもしれません。

また、プロセスとプロダクトという揺らぎもあります。アジャイルはプロセスでもありますがプロダクト重視なので、ツールを中心にプロセスを重視したアプローチが出てくるかもしれません。

業務ドメイン

これまで、RDBやNoSQLのように、新しい実現方法で新しい業務が実現されてきました。そこでは、電子化、効率化、自動化、決定支援が行われてきた。これは揺らぎでなく方向性です。今は単にたくさんのデータを扱う事が中心ですが、協調フィルタリング(Wikipedia)などで予測する事や、ユーザの動作の予測などが行われる様になると思っています。

最近知ったのですが、iOSでは押されたキーを推測するのに、辞書データの頻度情報を利用しているそうです。計算機は大陸弾道弾の軌道計算が始まりと言われていますが、また、先祖帰りをするのではないでしょうか。シミュレーションによって実際に動かさずに判断したり、時間を超えて予測する様になるでしょう。これも一種の揺らぎかもしれません。

さて、このような中で、技術者はどのように生きるべきか?信念を持つ生き方も良いですが、世の中は冷静に見ないと行けません。楽しいからだけが理由であったり、みんながそういうからマネをすれば仕事にありつける、という発想は危険でしょう。たとえば、アジャイル開発では多能工だとやり易い様ですが、自分の得意分野を常に持つ事もこれからは求められると思います。

そのためには、常に新しい技術に挑戦しなければ行けません。そこで、チケット駆動開発がきっと大きな力になるでしょう。と、今回の発表に戻ってきたところで今日の放談は終わります。

« 2012年11月 | トップページ | 2013年1月 »