桜、抹茶、白、日記

名古屋市在住のC++使いのcoderの日記だったもの。

Agile Charity Event in Osaka に参加

Event Programming

d:id:youandi:20101030#p1
軽く興味があった程度でしたがお誘いを受けたので、参加してきました。

ThoughtWorks主催 Agile Charity Event in Osaka
http://www.tech-arts.co.jp/news-and-topics/events/2011/Charity2011.html

会場で[twitter:@nakaji]さんと合流したら、会うなりいきなり「丁度良かった。お金貸して！」とか言われました。

オープニング

参加者は50名ちょっとだった模様。

今回のイベントの目玉と思われていたケント・ベックさん関係については、ケント・ベックさんからの１分ちょっとの日本での大震災お悔やみ申し上げます的なビデオレターだけだった。日本語参考訳の紹介のあと、大事なことなので二回言いました的にもう一度ビデオレターが流されました。

「あいさつの魔法。」を参考にしたちょっとしたアイスブレイクがあった。二人一組でペアを作ってと言うのがかなりハードル高い気がしたが、[twitter:@nakaji]さんが居てくれて良かった。
あと右手の人差し指と左手の親指、右手の親指と左手の人差し指をくっつけて、上方向に向かって交互にくっつけるのはやりやすいが、下方向に向かって交互にくっつけるのは難しいってのもありました。

「アジャイルプロセス導入のポイント」 by テクノロジックアート 長瀬さん

    • 今まで
      • 直ぐに新しいものを取り入れている企業が導入
        • もともと組織として柔軟性があるので、どのようなやり方でも失敗しない
    • これから
      • 従来的なやり方をしていた企業が導入
        • 失敗事例が色々出てきそう
    • アジャイル開発導入にあたり、まず文化を見極める
    • 導入にあたって
      • まずアジャイル開発のプロセス手順書を作成する
        • テクノロジックアート社がコンサルする場合では、約２ヶ月間の時間を掛けて作成する
          • 導入先の状況に合ったものを作成する必要がある為、それ位の時間が掛かる
        • ロール(役割)の明確化をする
      • アジャイル開発手法について熟知した人が必ず１人はいる事
      • ドキュメント作成については、従来での基本設計書レベルものは作成するが、詳細設計書レベルのものは作成しない
      • 反省会(レトロスペクティブ)の実施
        • 以下のようにならないように注意する
          • 発言がない
          • 問題点のみが報告される
        • 上記のような事がある場合は、ファシリテーターが必要
    • 設計
      • どのように進めるかが重要
      • テストシナリオ
        • 顧客要求に合致したテストシナリオが書けているか？
          • 欧米では顧客側の技術力が高い
          • 日本では顧客の担当者は業務知識重視で技術力は高くない
            • 開発側が顧客要求を引き出したり、実現性の検討を行う必要がある
      • ストーリー
        • ストーリーの大きさ・正確性
          • どうするのか決める
          • 従来の分類方法を利用して大きさ(粒度)を揃える
          • 従来のやり方を整理する
    • ツールの選定
      • VCS
      • CI
      • テストの管理
      • 海外では既に分散開発の流れになっている
        • インド・中国等とのオフショア開発流れ
        • 日本においてもこの流れになってくるとツールが重要になってくる

アジャイルコーチ的な視点での、従来的な開発プロセスを進めているチームにおいて、どういった事に気を付ければアジャイル開発手法の導入をスムースに行えるか。といった内容のお話でした。あ、これらの話についてはセッション資料なしでセッションは進んでいました。

  • 感想等

上記のメモは自分が参考になった所しか取ってないかも。長瀬さんの話は節々でちょっと納得いかない所があった希ガス。

お昼(於：【閉店】昇龍軒 - 横堤/ラーメン [食べログ])

[twitter:@nakaji]さんとお昼。
塩チャーシュー麺を頼んだら予想外にチャーシューたっぷりだった。

「Are you target driven or customer driven」 by ThoughtWorks David Joyceさん([twitter:@dpjoyce])

agile.swtestの永田さんによる逐次翻訳セッション。

    • 自己紹介
      • Thoughtworksのエンジニア
        • リーン・カンバンの等のコンサルをしている
      • IT関連の仕事に従事して20年
        • 上記の内、12年はマネジメントに関わっていた
    • SystemThinking
      • リーンの話
        • エドワーズ・デミング博士*2
          • カイゼンの可能性は95%。残りの5%は働いている人自身にある。
          • 組織を変える為にはシステムを変える必要がある。
        • TPS 大野耐一(wikipedia:大野耐一)*3
          • 品質第一・正確性第一
          • コストは作業の流れにあり、何をしているかではない
        • ジョン・セルデン
          • Failure(失敗)は悪いやり方から来る
          • Failure(失敗)から知識を得る
      • 今日では
        • Scrum、XP、カンバン
          • これらは良い(better)やり方ではあるが、最適(best)ではない。
          • No Single Solution
        • Copy Methodするな
          • 他人の真似事をしてうまくいくだろうという神話は忘れろ
        • Agile Safaris
          • 現場に合わせて変化させていく
        • アジャイル開発することがゴールではない
          • 顧客にものを作って届けるのが仕事
        • 価値の提供 : Quality Code
        • 技術的なものを求めるのではなく全体を見る
      • 事例から
        • 現場の担当者が一番顧客の要求に近い所にいる。その上にいる管理者や更に上に行くと顧客要求からは遠いものになる。

内容としては、リーンを主体としてPDCAサイクルを回すととか、本当に顧客の必要とするものを作っているのか？といった内容。

  • 感想等

逐次翻訳が直訳過ぎて居眠りしてしまった・・・。あと本セッションは予定より15分オーバーだった。

パネルディスカッション「アジャイルは失敗するって本当ですか！？」

[twitter:@nao_maru]さんがモデレーターとして、主題の他に会場からのアジャイル開発についての質問を聞いてそれについてもディスカッションする形に。

会場からの質問としては・・・

    1. Q：？？？忘れた・・・
    2. Q：アジャイル開発って儲かるのか？
      • A：WFだと３倍の金額で見積もるので儲かる。アジャイルは嘘がつけないので儲からない。
  • 感想等

自分がした質問

    1. Q：アジャイル開発導入の動機について従来のやり方に問題意識を持つからやるのでは？
      • A：
    2. Q：開発者向けのツールはVCS, CI, ITSとか色々あるけど、(アジャイル開発を導入する上で抵抗がありそうな管理者層をサポートする為の)管理者向けのツールってありますか？
      • A：そもそもツールを導入するのは、やってみてうまくいかない時に導入するものであって、まずツールありきではない。
      • A：Redmine使え

Agile Tour Osaka 2010にも参加している*4ので、Redmineによるタスクマネジメント実践技法のあきぴーさんのセッションも聞いていますが、それを踏まえた上で管理者向けのツールは？という質問をしたのですが、質問仕方が悪くて意図が伝わっていませんでした。
個人的にはRedmine/Trac等のITSってエンジニアの管理・情報共有ツールだと思っていて、ストーリー管理とか、テスト管理とかプロジェクト全体を見渡すの事までは出来ない気がします。プラグイン追加したら出来るよと言う意見もあるでしょうけど。そのプラグインで出来るよ！というのが気に入らないので、先日RTCについてのセッション*5をしている訳で。

気になった内容

    • 長瀬さんの海外での開発の話
      • 常時3,000ビルドが走っているようなCIサーバーがあり、CIサーバー専門に監視する人がいる。
      • ３日でシステム開発が完了するような事例もある
    • QCD(Quality, Cost, Delivery)重要
    • Agile Inspection Process
    • Agile Requirementsなイベント
    • 開発計画には、メンバーの成長についても計画に含める
      • そこまでリーダーがイメージできるかが、成功のポイント

成功と失敗の話については、根本的に計画づくりが大事だという話になって、ちょっと主題とはズレた方向になったのではないか？と思った。計画が大事ってそりゃそうですけど、それは従来手法でも同じかと。
あと、「アジャイルは失敗する」の「アジャイル」の定義が壇上の皆さんと自分とでは捉え方が違ったようで、壇上の皆さんの認識では、開発プロセスとしての「アジャイル」で話をしている気がした。自分が考える「アジャイル」って開発プロセスよりももっと広義だと思うんですけどね。
アジャイルだけではなくテストとかの話でもそうですが、議論する上ではまず言葉の定義を明確にしないといけないな、と最近思いますね。

閉会

特に何も無く撤収。

懇親会

１次会(於：大阪市鶴見区のカフェダイニングは"SunnyClouds"サニークラウズ)

[twitter:@yasuohosotani]さんと色々先日のAgile Japanでのテスト開発プロセスの話を伺ったり。ファシリテーションスキルの高い人の会話には割り込みかけるのは難しいですね・・・。
技術評論社からチーム開発プラットフォーム Team Foundation Server 入門が５冊提供されていた。

２次会(於：【閉店】ネルフ 大阪支部 （NERV） - 近鉄日本橋/バー [食べログ])

[twitter:@nakaji]さんと２人で２次会。4squareでチェックインしたつもりが出来ていなかった・・・。
名古屋支店とスタンプカードは共通で使える模様。

あと可愛らしい女性店員さんの応対がとても良かった。

参加しての感想等

パネルディスカッションで壇上に上がっていた、[twitter:@nao_maru]さんや[twitter:@yasuohosotani]さんは実務でもScrumを導入・実践しているようで、凄いなと思う反面Twitter上でもアジャイルについて広めている人達は皆Scrumを導入しているような・・・。
個人的にはScrumをちゃんとやれば確かにアジャイル開発になるんだけど、Scrumでやらないアジャイル開発ってのもあるんじゃないか？と思うんですよね。従来方法にアジャイル手法を取り入れて少しずつカイゼンしていくってのは、アジャイル開発になるのかならないのか、パネルディスカッションでの違和感はその辺から来ていますが。

今回、名古屋アジャイル勉強会でいつものメンバーと話している内容とはまた違った側面でのお話を聞く事が出来て、色々を知見を広める事が出来た事は参加して良かったなと思います。


余談ですが、アジャイル開発ってチーム内や顧客との対話(コミュニケーション)で成り立つものであり、個人的にはアジャイルの勉強も対話やアジャイル手法を体験する事により進めるべきものかと思っています。今回のようにセッションを聞いて帰るだけっていうのは、ちょっともったいない気がします。
名古屋アジャイル勉強会では、イベント毎にワークショップやディスカッションやKPT等で振り返りを必ず入れて、それを参加者全員でやる事により、全員が何か発言・体験をし、何らかのものを持ち帰る事ができるのではないかと思います。そこが自分がスタッフをやろうと思った動機だし、継続して参加し続けたいと思った所ですね。

*1:http://www.tech-arts.co.jp

*2:デミング博士の新経営システム論―産業・行政・教育のために

*3:トヨタ生産方式――脱規模の経営をめざして

*4:d:id:youandi:20101030#p1

*5:d:id:youandi:20110409#p4