2010年2月22日月曜日

「西日本アジャイルプロセス協議会 中間報告会」に参加

お疲れさまです。ZuQ9->Nnです。
2010年2月21日(日)に「西日本アジャイルプロセス協議会 中間報告会」が開催されていましたので参加しました。

場所は京都キャンパスプラザ、参加人数はきっちりとは、把握できていませんが40人ほどでした。
まず、お世話役(飲み会の幹事)前野さんより、西日本アジャイルプロセス研究会について説明がありました。

アジャイルプロセスに必要な人材とは?そして、そのような人材はどのように育成されるか?
「人と知識と技術」をテーマに小さな疑問を一つ一つ解決していこうと立ち上げられたそうです。

そして、最初のセッション、日野数司さんによる「アジャイル開発者のための行列のできる法律相談所」

なんだか、人気テレビ番組のもじりのようなタイトルですが、いたってまじめな内容だと始めに説明がありました。

たとえば、大事なアイディアを盗まれたり、勝手に使用されたりしないか?という疑問に
クリエイト・コモンズをしているから大丈夫だと答えがあるが、これは、本当か?というところから
この研究が開始されたそうです。クリエイト・コモンズはアメリカでは有効だが、
日本では著作権法があるので、いまいちうまく機能しないそうです。

その他に、知らないあいだに違法してたり、突然、
訴えられたりすることがあるかもといった感じですすんで来たようです。
そして、岡山でおこなったワークショップの経験をお話しされました。

ある企業が、前担当者が一つのスペースで業務、
共有スペースでの「タスクかんばん」張り出し、
派遣社員とのペアプログライングを行っていると仮定し問題点を聞いたところ

期待していた答えとは、まったくちがう「ペアプログラミングできるスキルが無い」などであったそうです。
個々の問題を整理しても意識しないと気づかないのでは?
意識させには、ワークショップのように具体的なシナリオベースに注意ポイントをあげる方が伝えやすい
との検討から、今後はシナリオづくりをされるらしいです。最後にメンバーを募集してセッション終了。

続いてのセッションは山根英次さんの「アジャイル開発のための技術体系」です

アジャイルプロセスでは、人が大切なんだと話が多いが、
技術の話はいいのか?バリバリ作れるのか?との疑問から
ソフトウェアは「技術」を有した「人」によって作られるものだと最初に説明がありました。

そして、企業と技術者の関係を説明され、企業は事業戦略、業務改善の技術的見地から立案が欲しい。
技術者は経験の基づいた技術、新技術に対するアンテナが必要

アジャイルプロセスを運用するための人が技術として必要とされる技術は何だろう?
その技術をどうやって身につければ、もしくは、身につけてもらえば良いにだろうか?
仮にそれらに技術を身につけた技術者に企業はどのように報いれば良いのだろうか?
などと言う事を話し合っていきたいとの思いを語られました。

また、平鍋さんが訳された、ソフトウェア職人宣言
・動くソフトウェアだけでなく、しっかり作られたソフトウェアを、
・変化に対応するだけでなく、着実に価値を付加していいく事を
・個人と相互作用だけでなく、プロフェッショナルたちのコミュニティを、
・顧客との協調だけでなく、生産的なパートナーシップを
を紹介されました。

その他、「技術」と価値のひも付けをおこなっているそうで、
ISO/IEC9126-1の品質特性に満たすために必要な技術。
アジャイルプロセスで必要なのは「技能性」「保守性」に注目し、成果物をまとめたそうです。

また、XPのロールごとに必要な技術をITSS ver3とマッピングしてみたり、
技術とロールをひもづけて見たり、技術も一足飛びに習得は出来ないので
段階を経て習得するものはレベル分けをされたりしたそうですが、
結論としてキャリアパスとスキルパス分離しよう。と主張されました。

最後にちょっとでもこの業界をよくしてみませんか?仲間内で愚痴いるより、前向きに愚痴ってみませんか?
と言う言葉はとても印象的でした。

この後、休憩があり、休憩終了後にライトニング・トークス。
最初は谷本誠さんの「目覚めよ!スキルアップ欲」

リーダーとしてメンバーにスキルアップに取り組んでもらえる方法を模索、
資格試験は業務につながりにくく、スキルマップなどは具体性に欠けるので、
現場目線で実力測定ツールを作成されたそうです。

その、測定ツールでは目標となる人を設定できる。その結果のグラフ化した結果、
目標とする人と自分の差を比較できる。 月次で集計すると、だんだんアップしてきているのが見える
といったメリットがあったそうです。今後はエンジニアマインドに火をつけるような
スキルアップができるようにしたいと語られて見事、5分以内で終了。

つづいては、松本真一さんの「心理状態を読み取るには?」

目線の動きで人の心理を読み取るコツを紹介されました。」
目線が上の時は何かを想像している。右ばかり見ているのは未来の考えている傾向。
左ばかりの場合は過去を考えている。左下は触覚を思い出す/自己対話の傾向。
などを説明されましたが、残念ながら時間オーバーでトーク終了

つづいては、前野公孝さんの「最近想うアジャイルのこと」

アジャイルしない会社からアジャイルしかしない会社に転職して想われた事として、

変化を前提、当たり前のことを当たり前に、ペアでやることの意味、
リモート開発の可能性。 説明責任もあるし安心感も高い。

アジャイルで実現できた事としてジャイルで実現できること。
・大切なものを大切に ・恊働。
・購入/償却から投資/進化へ ・業界の変革。

最後にアジャイルに対しての思いとして
・実践し続けることの難しさ ・技術者の成長 ・アジャイルをどう体現するか。
・アジャイルだから何の苦労もなく何かがうまく行く訳ではない ・問い続けることと学び続けることが重要
とまとめられて、見事5分以内でトーク終了。

最後に東京から来られた、本橋正成さんの「東の和ー日本の和に向けて」

神輿と寄合のパターンラングエッジを紹介されました。
西日本のパタン。一見さんお断りパタン。よしもとパタン。つかみのパタン
など、ちょっとお話がはやくて、うまく、書き取る事ができませんでした。

最後に、みんなの拍手で最優秀者を決めて、ライトニング・トークス終了。

セッションにもどって猪原信彦さんの「アジャイルプロセスの必要知識体系」

まず、知識体系とはなにか?をXPやScrumなど知識を複数の視点で分類、
構造化し知識のモデルと説明され全体の把握と漏れの防止を目的としてまとていられるそうです。

まず、アジャイルプロセスをシステムに対する要件の変化や追加を積極的に受け入れ、
真の要求に見合った価値のある開発を実施するプロセスであると定義づけられていました。

アジャイルプロセスの価値、原則、プラクティスの説明をされました、

・価値あるソフトウェアを提供する事により顧客を満足させる事が重要
・顧客の競争優位を実現するために変化を受け入れる。
・短い期間の単位で、頻繁に動作するソフトウェアを提供する
・インターバールの中に、より効果的なる方法が現れ、チームはそれに強調し、調整する。
・メンバーが仕事をやり遂げるために、働き易い環境とサポート、信頼を与える

目的や価値に プラクティスを体系にあわせて分類してみたそうですが、
うまく分類できない開発もあったそうです。実装/プラクティスに関するものと、原則に分類し
今後も完成に向けてやっていくとの事でした。

続いてのセッションは新保康夫さんの「孫子と孔子で説くアジャイルプロセス講」

最初にアジャイルプロセスへの障壁として導入への障壁、上司や利害関係者への得度、
メンバーへの布教などをあげられ、

その障壁を乗り越えるために先人達の知恵をつかおうと
そして、先人達の知恵でアジャイルプロセスに生かすには
戦略、戦術だけではなく、道がいるとも語られました。

実際には、まず、孫氏や孔子の説法を使い、プロジェクトの視点で毒舌をつかう。
例として「孫子曰く、兵とは国の大事なり」 これは、
・ 会社として、開発プロセス、相手の環境で影響を受けること。
・プロジェクトリーダーの経験はあるのか。
・制約条件はきちんとしているか。

「将わが計を聞くときは、これを用うれば必ず勝つ」
・アジャイル開発を導入するときは「空気を読め」。
・ 情勢をしっかり見て論理的な解が当初の目的と整合性があるように臨機応変に進めなくてはならない。
といった例を紹介されました。結構、あたっているというか、的を得ていておもしろいと感じました。
今後は、このような説法集を作っていき布教をしていきたいと語られて終了。

最後は特別講演で京都光華女子大学 人間科学部メディア情報専攻の阿部一晴准教授による
「ソフトウェア「要求」を取り巻くあれこれ」

最初にウォーターフォールモデルなどの情報システム開発手法の説明があり、
その中でもソフトウェア要求が非常に重要だとの語られました。

そして、「ソフトウェア要求」とは、顧客がソフトウェアに当然
備わっているべきてあると考える機能や性能の事と説明がありました。

ソフトウェア工学から独立した要求工学では、要求の獲得、要求の分析、
要求の検証、要求の管理の4つの領域がある、アレグザンダー「オレゴン大学の実験」などの
お話をされて要求開発について述べられました。

Openthologyの5つのプリンシプル、Openthologの7つのプラクティスを足早に紹介され
ソフトウェア工学の人間的側面をおっしゃられて、最後に、まとめとして
なぜ、良いシステム開発が出来ないのか?それは、正しいシステム要求が出せないからだ。
なので、要求は「開発」するものだ、正しい要求の獲得と合意のための活動を行おう。

この業界の若者に魅力あるものに。ソフトウェア技術者を幸せにしたい。との発言がありセッション終了。

かなり、長時間でしたので、やはり、集中力を保つのが大変でした
もっと、しんどくなったり、途中で眠くならないかと心配になりましたが、
いい感じで、集中できたと想います。

やはり、改めての気づきもあり、また、普段の自分の至らなさの反省部分にも目を当てられたと想います。
今後も機会があれば、積極的に参加していきたいと想います。

0 件のコメント:

コメントを投稿