スポンサーサイト

  • 2016.05.30 Monday

一定期間更新がないため広告を表示しています

  • 0
    • -
    • -
    • -

    セルフレジでポイントカードの出すタイミングが変わった

    • 2016.04.02 Saturday
    • 00:06
    小さな事でもカイゼンするんだと驚いたこと。
    先日ライフのスーパーで買い物したときに、セルフレジで会計しようとすると、
    ライフのポイントカード提出するタイミングが変わっていました。

    ■今まで
    1. 財布だす。
    2. ポイントカードをレジに通す
    3. ポイントカードを財布にしまう
    4. 財布をしまう(または近くに置く)
    5. 商品をレジに通す
    6. 財布をだす
    7. お金を払う
    8. 財布をしまう
    このような流れでセルフレジを使っていました。
    一番面倒だったのが(3)の工程。
    商品をレジに通すには片手では難しく、ポイントカードを通した後、財布にしまい、その財布もしまわないといけなく、小さな煩わしさを感じていました。

    ところが、先日セルフレジを使用してみたところ、

    ■現在
    1. 商品をレジに通す
    2. 財布をだす
    3. ポイントカードをレジに通す
    4. ポイントカードを財布にしまう
    5. お金を払う
    6. 財布をしまう
    このようにポイントカードのレジ通しが、商品をレジに通したあとになったことで、
    財布を出すタイミングが一回に済み、大変らくになりました。

    このような小さなカイゼン。なかなか気づく事難しいと思いますが、流石だなと思いました。
    以上、街中で見つけた小さなカイゼンでした。
     

    アジャイル開発プロジェクトにおける古典的な失敗パターンのメモ

    • 2013.10.31 Thursday
    • 01:40

    日経コンピュータで連載されている天野勝さんの「アジャイル開発、実践の勘所」に書かれていた、
    アジャイル開発における古典的な失敗パターンが凄く勉強になったので、自分メモ。
    (雑誌内容そのまま掲載はさすがにアレなので、要点のみに編集)

    ■失敗パターンその1
    間に合わせ仕事
    • イテレーションないで、無理やり完成させようとして品質悪化。
    • 次のイテレーションにも影響し、修正に時間がかかり新規機能追加が遅れる。
    • どんどん、技術的負債が膨らんでしまう。
    対処方法の例
    • ふりかえりで、問題点を把握。
    • 作業の省力化や、スコープ見直し。
    • そもそも、朝会などで早期に問題点発見を心掛ける。


    ■失敗パターンその2
    イテレーションの延長
    • 期間内で完了しなかった為、イテレーション期間を延ばしてしまう。
    • その結果、フィードバック回数が減ってしまう。
    対処方法の例
    • 慣れないうちは、イテレーションの期間を延ばさない。
    • スクラムでは、イテレーション途中でのゴール変更を禁じている。
    • イテレーション期間を3日間など短くするのも一案。
    • (慣れないとタスク作りにも時間が取られてしまうので、計画を建て易い期間とする)
    • 慣れてきたらイテレーション期間を1週間より延ばすなど行っても良い。


    ■失敗パターンその3
    巻き込み不足
    • 品質チェック担当のメンバーがアジャイル開発に対して知識不足。
    • 品質チェック担当が、既存審査基準からの変化に対応できず、リリースできない。
    対処方法の例
    • プロジェクト初期から、品質チェック担当にも参加を促す。


    ■失敗パターンその4
    情報の揮発(きはつ)
    • 情報が更新されず、新機能追加時に見当がつかない。
    • 分析に余計な時間がかかってしまう。
    対処方法の例
    • プロジェクト区切り毎に、保守用ドキュメントを用意する
    • (アジャイルはドキュメントを作らないという勘違いがまだ多い)
    • 自動化テスト環境を用意し、システムを振る舞い的に理解しやすいようにする。
    • システム担当メンバーをある程度固定化し、そのまま運用保守まで担当することで、引継ぎによるコストを減らす。


    あとパターンに含まれていませんでしたが、失敗しやすいものとして、
    • メンバーがアジャイル経験が未熟のうちにメンバーを分裂させて、アジャイルチームを増やしてしまう。
    • アジャイル経験者をリーダのポジションに就けると、メンバーが指示待ち態度となってしまい、互いに助け合うというチームにならない。

    失敗の根本にあるのは、互いに助け合うという気持ちが足りない時に発生しやすい。
    チームメンバーが役割に拘らず、互いに補完しあう、自律的に動くチームを作る事が大切であると締められています。

     

    Agile Tour Osaka 2013に参加してきました!

    • 2013.10.08 Tuesday
    • 02:09
     
    2013/10/05に開催されましたアジャイルツワー大阪2013に参加してまいりました!
     
    AgileTourOsaka2013
     
    中身が濃いセッションで、大変勉強になる内容でした。
    当日のTwitterは、@kamatamadai さんがまとめて頂きました♪
    いつも重宝させて頂いております。有難うございます!
     
    「AgileTourOsaka2013 #agileto2013 のまとめ」
     
     

    ■アジャイルマーケティングがより良い製品を届ける

     
    agileMarket
     
    keynoteは、Chris Kruppa氏のアジャイルマーケティングの話です。
    氏の経歴等は告知サイトの紹介を参照して頂くとして、
    マーケティングだけでなく、技術の話もできるとても凄い方でした。

    (10/10 追記。スライド資料が公開されましたので追加します。
    著作権的に不味いものが削られており、会場で拝見したものと若干異なっています)



     
    以下は、原田さんの同時通訳+オレオレ英語解釈で理解した内容です。
     

    ■そもそもマーケティングって何だろう?

     
    マーケティングという言葉は、人によって、全く意味合いが異なってしまい議論がかみ合わない事が多いそうです。
    ベトナムでこの話をすると多くの人は、「マーケティングとは、マスコット作ったり、宣伝したり多くの人に告知をすること」と思われる方が多いとの事。
    私もマーケティングとはそういうものだと思ってました(汗
     
    会場から挙がった意見としては、
    ・市場調査
    ・予測と分析
    ・ニーズ調査
    ・自らのアイデンティティを明らかにする
    ・製品の市場テスト
    などなど。
     
    Chris氏が言うには、マーケティングとは、
    大きい視点で見る必要性との事だそうです。
     

    ■マーケティングにおける4つのP、4つのC

     
    4つのPとは、
    • Price(価格)
    • Place(流通)
    • Product(製品)
    • Promotion(プロモーション)
    売り手からの目線で考えた4つのマーケティングツールの事。
     
    4つのCとは、
    • Customer(顧客)
    • Communication(コミュニケーション)
    • Cost(コスト)
    • Convenience(利便性)
    4つのPを顧客(買い手)視点に置き換えた概念となります。
    現在はこの4つのCがマーケティングの主流になってきているそうです。
     
     

    ■企業文化としてのマーケティング

     
    マーケティングに大切なことの1つがブランディング。
    企業文化や、企業魂のようなものと言われてました。
    それには4つの要素があり、
    • Identification(共感)
    • Enthusiasm(熱意)
    • Transparency(透明性)
    • Communication(コミュニケーション)
    との事。
    事例紹介として、イギリスのロックバンド「Radiohead」は、インターネット上でアルバム「In Rainbows」を販売しました。
    しかし、値段は敢えて定めず、好きな金額を払って下さいという形をとりました。
    つまり、払わなければタダでアルバムが聞けることになります。
    お金を払わなかった人は全体の33%で、多くの人は幾ばくかの金額を払ったそうです。
     
    そしてこの話は続きがあり、このマーケティング手法で有名になった彼らが、アルバムを現物のCDで売り出したところ、多くの人に買ってもらう事が出来ました。
    購入者の中には、インターネットでアルバムを既に買っていた人も多かったそうです。
    同様に、ライブチケット販売も大盛況だったそうです。
     
    昨今、ステマという言葉が流行っていますが、ここら辺を狙ったマーケティングなのでしょうね。
    反発されているのは、透明性が無いからでしょうか。
     
     

    ■アジャイル・マーケティング

     
    マーケティングの世界も、不確定に対応するためのアジャイル・マーケティング・マニフェストが出来たとの事。
     
    What is Agile Marketing?
     
    Chris氏が用意して頂きました日本語訳を下記に記載致します。
     
    Responding to change over following a plan
    計画の遂行よりも、変化への対応を
     
    Rapid iterations over Big-Bang campaigns
    ビッグバンキャンペーンよりも、すばやい繰り返しを
     
    Testing and data over opinions and conventions
    意見と会話よりも、テストとデータを
     
    Numerous small experiments over a few large bets
    大きな少数の賭けよりも、小さな多数の実験を
    (※少数の大きい賭けよりも、小さな多数の実績を・・・のほうが判り易いかな)
     
    Individuals and interactions over target markets
    市場目標よりも、個人と対話を
     
    Collaboration over silos and hierarchy
    縦割りや階層構造よりも、協調を
     
     
    アジャイル・マニフェストと概念は同じですね。
    このマニフェストをふまえると、
    運用とマーケティングは、
    • 組織コミュニケーション
    • アジャイル組織
    • 機能横断チーム
    • 交渉よりも協調を
    の形になるそうです。
     
     

    ■質疑応答

     
    質問:
    「新しいプロダクトを作り出すのに、強いリーダ。カリスマな人は必要ですか?」
     
    回答:
    「必ずしもリーダが必要とは思わないです。
    アイデアは1人ではなく、チームからも出る事はあります。
    社内肩書きに関係なく、フランクに話せる協調できる組織が大切だと思います」
     
     
     
    質問:
    「昔の海外企業は、パーテーションや個人の部屋など比較的プライベートな場所や空間で、仕事するのが多かったのですが、何故今のようなチームによる開かれた空間での仕事と変わったのですか?」
     
    回答:
    「誰かが困っていたら、気づいた人が助けてあげる。チームの協調性が高まったら、自然と個室や区切りがなくなって、お互いの顔が判るような形と変化していきました。」
     
     
     

    ■すぐそこにあるDevOps

     
    日本MSのエバンジェリストである、長沢智治さん(@tomoh)によるDevOpsの話です。
    長沢さんのお話しは特定ツールや環境に依存しないお話しなので、大変勉強になります。
    余りの宣伝の無さが逆に心配になるぐらいww
     
    長沢さんのセッション資料としては、AgileTourの1週間前に行われたJAWSの資料なのですが、ほぼ同じなので掲載させて頂きます。
     
    (もし、AgileTourのセッション資料がUPされましたら、差し替えます)
     
    以下はセッションで気になった個所です。
    • 現在はITは不可欠!
    • 市場の動向が大切になってきている
    • 現在は開発途中でも、ビジネスは変化していく
    • 長い開発期間では変化に対応出来ない
    • 決定権が、CEOからCTOへ
    • 決定権が、CIOからCMOへ (@fuku518さんご指摘有難うございます)
    • 10年前のAgileがやっと活躍できるのが、今のITビジネスなのでは
    • EnterpriceもDevOpsの時代へ
    • BML(Business Build、Market Measure、Lean)の循環が大切 @fuku518さんご指摘有難うございます)

    DevOpsというと、運用保守と一体化した開発というイメージを持っていたのですが、
    時代は攻めの運用ということなんですね。
    ABテストを常に仕掛けたり、MVP(Minimum Viable Product)作ったりなど。
     
    こうなってくると、お客の儲けの何%を頂く代わりに開発費は低くするなど、
    新しい受注スタイルが産まれるのは当然ですね。
    そうして、また開発部門を自社内に内包していくのでしょうかね。
    歴史は繰り返すみたいで、面白そうです。
     
     
    ■折り紙を使ったワークショップ
     
    セッション途中に、折り紙を使ったワークショップがありました。
    ネタバレになるので、詳しくは書きませんが、頭のいい人は凄いなと思いました。
    どんな思考しているのか、脳を覗いてみたいです。
     
     

    ■プロジェクトを導くしなやかな背骨

     
    山本雄一郎さん(@u1r_red)が現場で実践された、アジャイル実施結果と考察の紹介です。
     
     
    とても面白い内容でした。
    個人的に気になった個所は、
    『何故アジャイルをするのか?』という疑問に対して、
    • 疑問を晴らす、不足を埋める
    • 評価しなければ、結論が出ない
    • 判明したから、変化が出来る
    だから、アジャイルを使うという箇所でした。
    なるほど、すごく納得が出来ました。
     
    あとは、表現が独特で面白かったです。
    目的が無い戦略で右往左往する様を、「ミジンコが暴れている」という表現は初めて聞きました(笑
     
     
     

    ■凄い人達によるディスカッション

     
    セッション最後は、スピーカ達によるディスカッションです。
    文字で多少なりとも伝われば良いのですが、海外エンジニアの隆盛と対比して、日本エンジニアの将来を憂う辺りなど・・・
    会場が一瞬凍りつくさまは、文章では表現できないですね。(;^_^A 
     
     
    ■質問1
    今後、DevOpsが進むと個人に必要となる知識はますます増加するのですか?
     
    回答
    全部を学ぶのはやはり無理。今後も特定分野の専門家は存在することになる。
    しかし、専門家に全部任せるのではなく、ツッコミを入れれるぐらいの知識は必要になるかと思う。
    現場で考えるというのが一番大切で、その為の知識は必要という事。
     
     
    ■質問2
    日本のエンジニアが置かれている今の状況で、若い人たちにはどのような警鐘を鳴らされますか?
     
    回答
    若いエンジニアには、ベトナム・中国などに行って、現地エンジニア達の熱意や給料を見てこいと言っています。
     
     
    ■質問3
    海外のエンジニアの熱意やレベルが高いという事ですが、どのような状況ですか?
     
    回答
    オブショア下請けから、自社サービスを始めるというのが主流になってきています。
    大学間のレベル差というものは存在していますが、みんなやる気が高く、ベトナム全土で約5万人のエンジニアが活躍しています。
     また、日本からの仕事は、実装とテストしかやらせて貰えなく、javaを知らない日本人が書いた間違っているかもしれない設計を実装するのは嫌と言う人もいます。
    お金よりもやりがいがあるかで、仕事を選んでいる人が多いです。
     
     
    ■質問4
    ミニマムに作って、顧客からフィードバックを得たいと思っていても、
    なかなかミニマムに作れません。なにかアドバイス頂けますでしょうか?
     
    回答
    ミニマム作っていて、時間がかかるのなら、それはミニマムでない可能性が高いです。
    見せたいものが多いと、複数をパラレルで用意したくなりますが、スプリント内で3つしか用意できないのなら、その3つだけを見せて、早めにフィードバックを頂けるようにしましょう。
    ミニマム例として、ログイン画面だけ用意して中身はComming Soonのまま、GoogleAdなどで宣伝して、人が集まってきてから、ページ内部を実装し始めました。
    1行もコード書いていませんが、これもミニマムの一例です
     
     
    時間が足りず、回答されなかった質問も多くありました。
    メモした中で気になったものを挙げると
     
    • 客が気づいていない潜在ニーズの掴み方
    • Cross Functional Team(機能横断チーム)をするための良いツールってありますか?
    • 戦略を理解しようとしないメンバーはどうすればいい?
    • DevとOpsが別会社の場合の良いコミュニケーションとフィードバックを得る方法は?
    • 仮見積もりが独り歩きする
     
    どれも気になる質問です。
    機会があれば、聞いてみたいと思います。
     

    ■まとめ・感想

     
     今回で2回目の参加となったAgileTour大阪ですが、今回はマーケティング、DevOps、アジャイル実践ガイドなど、昨年とは違った形で大変勉強になる内容でした。
    マーケティングの世界にもAgileが取り入れられているというのは、かなり衝撃でした。
     
    顧客とも、同じチームとして動こうとするのなら、壁がどんどん取り外されていくことになりますから、これからのIT業界どうなるんでしょうかね。
    なんにせよ、技術スキルが無いと、エンジニアとして生き残りに苦労しそうですね。
    もっと、頑張らなくは!
     

    DevLOVE関西 「わかりやすいアジャイル開発の教科書」ワークショップ#1を開催しました!

    • 2013.06.13 Thursday
    • 12:50
     
    2013/06/10(月)に、DevLOVE関西 「わかりやすいアジャイル開発の教科書」ワークショップ#1(レゴスプリント)を開催いたしました。



    今回初めて、参加者ではなく主催者側として 募集サイト準備やら、会場準備など裏方作業をさせて頂いたのですが、その御蔭か、普段とは違った視点でワークショップを見る事が出来ました。

    そして、なりよりも、講師として「わかりやすいアジャイル開発の教科書」著者である前川さん自ら、ワークショップを指導して頂けたのは、大変良かったと思います。
    前川さん、本当にご参加有難うございました!

    また、レゴスプリントは現在立ち読み用として、
    PDFで見る事ができます。
    (立ち読み用PDF「レゴスプリント」→ http://goo.gl/6pww8



    ■そもそも、ワークショップを開催したいと思った訳


     アジャイルを学ぶには、本や資料などで知識を得るのも大切だと思いますが、勉強会など、アジャイル系ワークショップに参加して、実践することが、理解への近道かなと漠然と考えておりました。
    何より楽しいですし♪

     そんな折、出版された「わかりやすいアジャイル開発の教科書」では、知識の大切さとともに、実践する事の大切さが書かれておりました。
    本の内容もワークショップが多数掲載されていましたので、それならばと、本を使ってワークショップを中心とした読書会を開催したいと思ったのが、きっかけでした。



    ■まずはアイスブレイク


    チーム内へ普通に自己紹介するのではなく、WhoWhoクエスチョンというのを行いました。
    ・二人ペアになる
    ・一人がもう一人に、1分間ひたすら『Who』と問いかける
    ・問われた方は、その度自身に関わる事をなんでも話す。(名前やら出身やら趣味やら)
    ・終わったら、『Who』と聞いた人がチームメンバーに向かって、1分間紹介をしてあげる

    これが中々難しく、『Who』で答えてくれた回答をメモする暇もないので、
    頭の中に覚えるしかなく、チームメンバーへの紹介時はしどろもどろになってしまいました。


    ■座学:アジャイルって何?



    ワークショップを始める前に、前川さんから簡単にアジャイルについての説明がありました。
    以下は、自分が気になった個所のピックアップです。

    1. 物の価値、ソフトウェアの価値の予見は、なかなか当たらない
    2. 顧客の求めているものとの誤解・ズレは多々として発生する
    3. 顧客自体が求めている、欲しいものも必ず変化が生じる
    4. アジャイル開発は増えてはいるが、顧客から『アジャイルで開発をして欲しい』と依頼があったときは、アジャイルを行う事自体が目的となっている可能性があるので、気を付ける事
    5. プロとして、顧客に提案することは良いことだが、業界構造の問題として、2次・3次受けとなると難しい時もある
    6. イテレーション期間は最初に決めた日数から変更しない。2週間と決めたら2週間周期でスプリントを回すこと
    7. プロダクトの価値も大切だし、プロジェクトのゴールも大切。どこに向かって進んでいるのかは、常に意識すること


    ■ いよいよワークショップ「レゴスプリント」



    いよいよレゴを使った、ワークショップのスタートです。
    お題は『レゴで最高の飛行機を作る』ただこれだけです。

    何をもって”最高”なのかは、各チームが考えます。
    (色、形、大きさ、スピード・・・)

    ルールは下記になります。
    1. 最初に、各チームでどんな飛行機を作るか考えます
    2. 飛行機を作るうえでの作業タスクを考えます
    3. タスクは「かんばん」に貼り付けます
    4. そして、タスクは「ToDo」「Doing」「Done」作業ステータスに併せて移動させます
    5. ここからは、1セット10分の作業を2回繰り返します
    6. 1セット内に「朝会」「作業」「振り返り」を行う
    7. 1セット終了したら、他チームの状況を見学
    8. 2セット目スタートする前に、”レゴ飛行をバラバラにする!”
    9. 1セットと同じ流れで2セット目をスタート
    当時の風景はこんな感じです。


    ※飛行機の材料となるレゴブロック





    ※部品となるレゴを漁る各チーム




    ※レゴの組み立て





    ※あるチームの1セット目の結果
    (前川さん曰く、1セット目で飛行機が完成しなかった初の事例とのこと)



    ※同じチームの2セット目の結果
    (レゴ外しも部品として使ってしまうなど、全チーム内で一番ユニークな飛行機になりました。なぜに滑り台!)



    各チームとも、1セット目よりも2セット目の飛行機が、
    独創的で面白いものが出来上がっていました。




    ■ レゴスプリントを通して気づいたこと



    1セット目は各チームとも要領が判らず、苦戦していました。
    特に時間配分で苦労しているようでした。
    つまり、チームを仕切る役割分担があいまいな感じでした。

    しかし、2回目は各々が自身の役割を認識して、自主的に作業を進めておりました。
    あるチームでは、タスク管理専用に行うメンバーも出てまいりました。

    その為か、1セット目と2セット目を比べて、如実に変化が感じられたのは、
    各チームの「かんばん」でした。


    ※1セット終了時でのかんばんの状況
    (ToDoが多く、Doneに至ったタスクが少ない)
    (もしかしたら、本当はDoneしているのに、タスクを移動していない物もありそう)



    ※2セット目終了時のかんばん状況(同じチーム)
    (タスクの内容もほぼ1セット目と同じ内容ながら、多くのタスクがDoneに移動)
    (このチームはタスクを管理するメンバーがおられました)




    ■まとめ



    自分的には、ふりかえり重要性を再確認したワークショップでした。
    ふりかえりで問題点を認識しあい、朝会で各タスクを認識、そして実作業に入る。
    必要な時は適宜ディスカッション。
    10分以内に完了する各タスク。
    2セット目のスムーズさは、見ていて気持ちの良いものでした。

    レゴスプリントでは「最高の飛行機を作る」というアバウトな要求仕様。
    10分しかない作業時間など、厳しい制約だと思っておりましたが、
    現実世界もあまり変わらないなと思うと、
    自分たちが普段やってる仕事ぶりは、1セット目みたいな感じなんでしょうね。

    ( ゚∀゚)アハハ八八ノヽノヽノヽ

    前川さんみたいにうまくは回せないでしょうが、
    一度会社でもやってみたい、ワークショップでした。

    最後に、前川さん有難うございました!




    ■ 最後といいつつ追加


    FaceBook上ですが、前川さんから興味深い投稿がありました。
    (公開モードなので、皆様ご覧いただけます)



    なるほど、こういう隠れた意図もあったのですね。
    勉強になります。


    DevLOVE関西「関西人の自分戦略」に参加してきました!

    • 2013.04.05 Friday
    • 05:32
     
    2013/04/04(木)に開催されましたDevLOVE関西「関西人の自分戦略」に参加してきました!

    関西で著名な御三方、@shin1x1さん、@jyukutyoさん、@nao_maruさんそれぞれの、
    自分戦略のお話をお伺いすること出来ました。
    皆様、当然ながら目的意識をもって日々お仕事をされており、何も考えずにノホホンと
    日々過ごしていた自分には、大変刺激になる内容でした。
    それでは、各セッションで気になった個所をカキカキ〆(゚▽゚*)


    ■自分戦略ってなんや?




    • DevLove関西 主催の@yohhatuさんによるセッション
    • 人生において、未来への見通しは不明瞭
    • しかしコンパスがあれば、進むべき方向は判る
    • 人生における自分戦略とは、コンパスであり、未来への地図でもある
    • つまり、自分戦略とは「過去を振り返り、未来を定め、することを決める」事である



    ■合わせ技で生きていく


    • 新原雅司(@shin1x1 )さんによるセッション
    • やりたい事+食べていける事=エンジニア
    • 食べていける事≒家族を養えるという事は大切
    • 対価とは、価値を提供してもらうもの
    • では、自分の価値とは何になるのか?
    • 特別に突き抜けた技術力がそれだけで価値があるが、なかなか難しい
    • 一つ一つの技術力は平凡でも、組み合わせる事で効果を発揮する
    • プラグラム+インフラ、PHP+多言語など
    • 稼ぐ方法も合わせ技で対応できる!
    • つまり、目的指向で合わせ技!



    ■もし草サッカーの補欠選手が「こんな環境じゃ活躍できない」と言ったら。


    • 阪田 浩一(@jyukutyo)さんによるセッション
    • 色々と知識を深めたくて仕事をしている
    • 役に立たなそうな知識や資格も取得した
    • 勉強方法は色々ある
    • コミュニティ主催、本を執筆など、とても勉強になるが、とても大変
    • ITの勉強は安価でできる
    • ITは専用分野が多く、専門家は多数いる
    • 頑張れば誰でも、何かしらの専門家になれる
    • エンジニアは生き方だ
    • いつか、世界で何かしらの分野で一番になりたい



    ■本を書くという自分戦略に行き着いた途中経過


    • 前川直也(@nao_maru )さんのセッション
    • アンパンマンの歌詞一説がキーワード
    • 「何が君の幸せ何をして喜ぶ 判らないまま終わるそんなのは嫌だ」
    • 論語もためになる。40超えると内容がジワジワくるw
    • 「三十にして立つ、四十にして惑わず」・・・未だ惑わってるw
    • 人生はアジャイルだ。変化ヲ抱擁セヨ。
    • 価値を駆動しよう
    • コミュニティで人に出会って、色々と刺激を受ける事が出来た
    • 本を出版したのは、人に「感謝」を、「価値」を届けたかったから



    ■LT大会


    LTでは、席でピザやビールを飲みながら、
    3名「@ryerさん」「@jaVuBaxさん」「@takepuさん」の方々による
    自分戦略を紹介して頂きました。




    ■まとめ

    • 発表者みなさん全員が、シンプルなゴール(目指す方向)を持っていられたのが印象的でした

    • 今ぱっと思いつく目標としては、@jyukutyoさんの目標が、自分と近いかも。
    • 色々なものを知りたいという欲求は大きいです。

    • 衝撃を受けたのは、人生はアジャイルで対応するというお話し。
    • 言われてみたらその通りだと思いました。日々の生活でも使用できますし。
    • 言われるまで全く思いつきませんでしたw

    • もしかして、子育てもアジャイルが使えるかもと思って調べてみると、
    • 733.000件のヒット。
    • もう既に「アジャイル子育て」は実践されているのですね(汗



    ■おまけ


    今回スピーカーでもあり、「わかりやすいアジャイル開発の教科書」の
    著者のおひとりである前川直也(@nao_maru )さんからサイン頂きました!


    栄えあるサイン番号2(≒サイン回数が2回目)をgetです。
    お忙しい中サイン頂き、有難うございました!




    わんくま同盟 大阪勉強会 #54にてスピーチしてきました

    • 2013.03.05 Tuesday
    • 02:16

     3/2(土)わんくま勉強会にて、Team Foundation Serviceを使ってみた際の感想等をスピーチしてきました。
    人生初スピーチで緊張しまくり、正直何を話したのか覚えておりません。
    他スピーチさんの度胸や、知識量が半端ないことを知る良い機会となりました。
    また機械があれば、スピーカとして何かに参加して見たいと思います。




    AgileTourOsaka2012 in Minoh 箕面の滝からこんにち に参加してきました!

    • 2012.11.04 Sunday
    • 05:58

    2012/11/03に「AgileTourOsaka2012 in Minoh 箕面の滝からこんにちは」に参加してきました。
    参加者の疑問を講演者の牛尾 剛さん、長瀬 嘉秀さん、藤原 大さんが回答していくというのがとても興味深いものでした。
    それでは速記をφ(゚ー゚*)メモメモ。


    ■PO(プロダクトオーナー)の育て方、次のステップへ移る課題は?
    • ストーリなどを要約する力
    • 全体の整理力が身に付く
    • ロジカルシンキング


    ■顧客へのアジャイル開発であるという説明はどうするのですか?
    • 開始前が重要
    • 顧客と話して、スプリントを1週間でなく、2週間単位にしました
    • 顧客の不安要素を顧客と話し合う

    ■メンバーの最大人数は?
    • 経験では10人
    • 理想は一緒に食事に行って、すぐに座れるぐらいの人数(5~6人ぐらい)

    ■アジャイル嫌!って人への対応
    • そういう人にはチームから出て行ってもらっている
    • 日本はエンジニアが多すぎる。半分は不要!

    ■チーム活性化の良い方法
    • 積極的に話しかける
    • それ以外は開発!
    • 一週間に一時間はフリートーク

    ■新しいプラクティスが効率が無い時の止め時は?
    • 振り返りで「やる/やらない」を決める
    • そのため、止め時はスプリント単位
    • 止めても再度やってみる事はある

    ■PO(プロダクトオーナー)はいる/いらない?
    • みんなの意見がぶつかった時
    • 今は多数決
    • 手を挙げない人は、その不安を聞いて、皆が納得するまで話し合う

    ■平常化は人の流動性を高めるため?
    • 1つのチームで上手くいった事象を他のチーム、他のプロダクトで試してみるため
    • 上手くいった場合、その標準化を差分を判定するため
    • 人の引継ぎはペアプロでOK

    ■アメリカはウォーターフォールから、アジャイルへの転換でエンジニアはどうなったの?
    • アメリカはゆっくり変わっていった
    • アメリカのエンジニアは自分のお金で勉強会に行っている

    ■振り返りで「なぜx5」をやると中が悪くなる
    • やはり「なぜx5」で人を泣かしてしまいました
    • 社員と派遣を分け隔てなく行うことが重要



    第6回RxTstudy に参加してきました!

    • 2012.10.21 Sunday
    • 04:07

    2012/10/20に第6回RxTstudy に参加してきました。

    ■Redmine 過去、2.1、未来


    • 前田剛(@g_maeda)さんのスピーチ
    • 今迄の振り返り
    •   2006年6月にversion 0.1をリリース
    •   0.5ぐらいから日本で紹介されはじめた。
    •   0.8が今の形の原型
    •   PHPのCandyCaneは0.8を原型に独自進化
    •   0.9に大幅な機能強化

    • 1.4→2.1における近代化の痛み
    •   1.4→2.0→2.1でどんどん動かなくプラグイン多し

    • 追加された便利機能
    •   PDFの文字化け解消
    •   SVNなどでコミット時に「@2.5h」とつけると、作業時間を自動反映
    •   チケットとリビジョン関係を後付で編集可能
    •   チケットのグループへの割り当て
    •   wikiのPDF出力
    •   プライベートチケット作成機能
    •   チケット、wikiでのCSS使用可能(使えるCSSはまだ限定的)
    •   チケットのReadOnly設定

    • Q&A
    • Q.英語の勉強方法はどのようにしているのですか?
    • A.単語やフレームでGoogle検索。出てきたページをチケットに書き込み。

    • Q.Redmineの使いかっては?
    • A.イナズマ線やタスクを開始順序にしてほしいなど思う。イナズマ線は海外ではメジャーではない。クリティカルパスを採用しようとする動きはある。


    ■チケット駆動開発への思い


    • 阪井誠(@sakaba37)さんのスピーチ
    • 書籍の種類


    • プロローグ
    •   アジャイルが判った
    •   チケット中心のコミュニティ
    •   マイルストーンにむけてゴールがが明確
    •   イテレーションの日々とリズム
    •   割り込みを減らす

    • TiDDの基本的課題
    •  TiDDの原則や価値とは?
    •   →暗黙知を明確にしたい!
    •  TiDDでのノウハウがパターン化できるのでは?
    •   →チケットの粒度
    •   →チケットの完了条件
    •   →チケットの優先度

    • TiDD原則と価値
    •  →原則とは、基本ルール
    •   →最初にチケット
    •  →成果物は構成管理に従う

    • チケットとは?
    •  →管理すべき対象プロセス
    •  →チケットはワークフローで制御される
    •  →ワークフローは構成管理へ

    • 構成管理
    •  →ソフトウェアの資産を管理する
    •  →変更を記録
    •  →リリース可能なソフトウェアビルド番号

    • チケットの消化率でベロシティを測る


    ■まとめ(感想)


    今回は、書籍 「チケット駆動開発」 の発売記念として、坂井さんのお話しを聞くことができました。
    チケット駆動らしきものはしているのですが、アジャイルらしさは微塵もありません(涙
    本を読んで勉強したいと思います。




    アジャイルサムライ読書会でプランニングポーカーやってきました

    • 2012.09.29 Saturday
    • 07:29
     9/28(土)に「アジャイルサムライ読書会@大阪道場#5」に参加してきました。

    今回のテーマはプランニングポーカー。

    読書会の流れとしては、
    1. 見積もりたい対象を考える
    2. タスクを検討する
    3. タスクごとに見積りを行う
    4. 振り返り
    このような流れで進んでいきました。


    1.見積もりたい対象を考える

    いろいろな案がでました。
    ・アジャイルサムライを執筆してみる
    ・ATNDサイトを立ち上げる
    ・ショッピングサイトを作る
    ・肉じゃがを作る
    ・居酒屋を作る

    今回はこの中から、「居酒屋を作る」というのを行うことになりました。


    2.タスクを検討する

    見積もり対象を大まかな形で、タスク分けを行いました。
    主なものとして
    ・店の場所を決める
    ・内装を決める
    ・メニューを決める
    ・食器をそろえる
    ・アルバイトを募集
    ・レアな焼酎を仕入れる

    思いつく限りタスクを挙げて、似たタスクはまとめ、その中からおもしそうなものを見積もることにしました。



    3.タスクごとに見積りを行う

    今回の読書会のメインテーマ「プランニングポーカー」です。
    ルールとして、
    • 今回は1〜13+無限・コーヒーブレイクのカードを使う
    • 最初に基本となりそうな(タスクイメージしやすそうな)タスクをみんなで見積もる(1や3となるようなタスクが良い)
    • 基本としたタスクを元に他タスクを”相対”見積もりを行う
    • みんな一斉にカードを提出
    • 一番数値が大きい人と、一番小さい人が意見を発表
    • カード提出後のディスカッションはほどほどに。
    • 数値が”全員”一致するまで3回繰り返す
    • 一致しないまま3回終わった場合は、タスクにより多数決か、一番大きい数値を採用する
    プランニングポーカーを行って教えて頂いたことは、

    ●疑問:
    何故一番数値が大きい人と、一番小さい人が意見を発表するのか?

    回答:
    プランニングポーカーの問題点として、声が大きい人(影響力がある人)が意見する機会が多いと、その人の見積もり値に合わせてしまうことがあるから。
    また普段発言が少ない人も、一番大きい・小さい数値を出した場合、強制的に発言することになるので、コミュニケーションが図れるというメリットがある。


    ●疑問:
    一致しないまま3回終わった場合、数値を多数決ではなく、一番大きい数値を採用する場合があるのは何故?

    回答:
    他の人より大きい数値を出したという事は、その人が考えている見積もり対象のタスクが人より大きいということ、つまりその人だけが見えているリスク・作業が存在している可能性があるということ。
    (新人による作業とか、過去の経験とか色々)
    そのため、リスクが発生しそうなタスクや、重要なタスクでは、多数決ではなく一番大きい数値を採用したほうが良い場合がある。



    4.振り返り

    KPTで振り返りました。

    一番感じたことは、プランニングポーカーで重要なことは

    ●ディスカッション(コミュニケーション)
    ●見積もり対象のイメージを共有化する

    だと思いました。



    最後に・・・・

    参加者数名で、恒例のペアプロならぬ、
    ペア”ダンスエボリューション”を行ってきました。


    最新のゲーム機ってすごいですね。
    ビバ!技術革新!!

    PR

    calendar

    S M T W T F S
      12345
    6789101112
    13141516171819
    20212223242526
    2728293031  
    << August 2017 >>

    selected entries

    categories

    archives

    recommend

    recommend

    recommend

    recommend

    profile

    search this site.

    others

    mobile

    qrcode

    powered

    無料ブログ作成サービス JUGEM