スポンサーサイト

  • 2016.05.30 Monday

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

  • 0
    • -
    • -
    • -

    VisualStudio2013からGithubへPushする方法

    • 2013.12.12 Thursday
    • 06:45

    VisualStudio2013から、標準機能だけで、Githubと連携する事が可能になりました。
    その方法に簡単にまとめてみました。

    irofさんとAR(拡張現実)で遊んでみよう♪

    • 2013.12.02 Monday
    • 02:17

    この記事は、いろふ Advent Calendar 2013の2日目の記事です。

    1日目は、@Posaune さんの「irofさんってどういう人なのか客観的に分析してみる」でした。
    irofさんをJVMとして解析するというのは納得なのですが、
    Twitter4JをC#で呼び出したりと相も変わらず素敵です。
    そして、衝撃(?)のラストは必見ですwww。

    カレンダー2日目の内容としては、
    みんなのアイドルirofさんをAR(拡張現実)にご招待してみたいと思います。

    (※ARイメージ)
    AR_image

    あ、先に言っておきますが、絵心はないですよー。

    ARを実現する方法はいくつかあるのですが、
    今回はお手軽にARが試せるUnity+Vuforiaで試してみたいと思います。


     

    ■Vuforiaでターゲットを設定してみよう


    Vuforiaとは、QUALCOMM社が提供しているARライブラリです。
    https://developer.vuforia.com/
    その中にUnity用SDKもあるので、今回はそれを使用します。

    SDKを使用するにはユーザ登録が必要となりますので、
    まずは画面右上にある「Register」からユーザ登録を行います。




    次にARライブラリのSDKをダウンロードします。
    SDKはAndroid、iOS、Unityの3種類ありますので、
    Unity用SDKをダウンロードしておきます。

    Unity Extension - Vuforia v2.6
    https://developer.vuforia.com/resources/sdk/unity



    ダウンロードしてきた、「vuforia-sdk-android-2-6-10.zip」を展開して、
    「vuforia-unity-android-ios-2-6-7.unitypackage」ファイルを取り出します。


    次に、ARで拡張現実を呼び出すための目印、マーカーを設定します。
    Target Manager
    https://developer.vuforia.com/target-manager

    このページにある「Create Database」をクリックします。
    (Cloude DatabaseにもCreate Databaseボタンはありますが、そちらではありません)


    クリックすると、マーカーを保存するデータベース名称を聞かれるので、
    入力します。(今回はデータベース名:irof にしています)


    Createボタンをクリックすると、新しいマーカー用データベースが作成されます。


    データベースが出来たら、マーカーとなる画材を登録していきます。
    データベース名称(今回はirof)をクリックして、次ページで「Add Target」ボタンをクリック。




    マーカー設定画面が表示されます。
    ここで別途用意していた、マーカー画材をターゲットとして登録します。

    (用意していたターゲット画材)


    ターゲットは紙1枚なので、Single Imageを選択して入力し、最後に「Add」をクリックします。


    暫く経つと、データベースに登録した画材が反映されます。
    (2~3分ぐらいかかりました)


    次に、このターゲットをUnity用ライブラリとしてダウンロードします。
    上にあるデータベース名:irofをクリックします。
    そうすると、先ほど登録したマーカー画材が表示されますので、
    チェックを付けて、「Download Selected Targets」ボタンをクリック。


    そうすると、マーカーSDKの種類を問われますので、
    今回はUnityを選択します。


    以上で、事前準備は完了です。
    次からは、Unityでの作業となります。


     

    ■ UnityでARライブラリを実装してみよう



    Unityについては、色々な紹介ページが多数ございますので、
    そちらを参照して頂くとして、早速ダウンロード&Unity起動を行います。



    新規プロジェクト画面はシンプルで何もないですね。
    ちなみに、Unityの色が黒みかかっているUnity Pro状態となっていますが、
    これは色々試してみたくて、30日体験版状態となっているためで、
    ARライブラリで遊ぶだけでしたら、無料Unityでも大丈夫です。

    早速、デフォルトに存在しているMain Cameraを削除します。


    次に、「Assets」-> 「Import Package」 -> 「Custom Package…」を選択。


    Vuforia作業時にダウンロードしていた「vuforia-unity-android-ios-2-6-7.unitypackage」を選択します。
    そうすると、インポート選択画面が表示されますので、そのままインポートを行います。


    つぎに、自分で設定したマーカーライブラリ(irof.unitypackage)も同じように、
    「Assets」-> 「Import Package」 -> 「Custom Package…」から登録します。


    これも、そのままimportボタンをクリックします。

    次にARライブラリのカメラとマーカーをHierackyに登録していきます。
    最初に「Project」 -> 「Assets」 -> 「Qualcomm Augmented Reality」->「Prefabs」を選択します。 



    右画面に現れる「ARCamera」「ImageTarget」をHierackyまでドラッグします。


    次にARCameraの設定を行います。
    ARCameraを選択した状態で、右側に表示されるInspectorから「Data SetLoad Behaviour」にある、
    「Load Data Set irof」にチェックをつけ、「Active」にもチェックを付けます。



    次にImage targetの設定を行います。
    Image Targetを選択状態とし、Inspectorの「Image Target Behaviour」から、
    「Data Set」と「Image Target」を設定します。


    Unityの下準備は以上です。
     

    ■拡張現実部分を準備しよう♪


    いよいよ、マーカーを見つけた時に、表示する拡張現実のオブジェクトを作成していきます。
    しかし、ここで重大な問題にぶち当たります。

    スネ夫の前髪問題と同様に、
    irofさんを3D作成した場合、正面からみた絵が判りません(汗

    それにこれは顔なのか?
    胴体があるのか?など、ここに来て根本問題にぶち当たりました。
    ・・・パンドラの箱が開きかねないので、ここは単純な球体と想定して先に進めます。      

    「Game Object」から「Create Other」->「Sphere」を選択し、
    球体を作成します。


    作成したShpereを「ImageTarget」の配下になるように、ドラッグで移動させます。


    デフォルトだと、Sphereのサイズが小さいので、大きくして、ついでに位置調整を行います。

    ここら辺は、微調整の世界です。

    つぎにSphereに顔の画材を貼り付けます。
    用意した画材はこちら


    ・・・絵心?ねーよ。


    用意した画材をMaterialsに、マウスでドラッグして登録します。


    次にMaterialsに登録した画材をマウスでShpereにドラッグすると、
    画材がShpereに張り付きます。


    これで作業は終了です。
    早速Androideで見てみましょう。

    デバック用のAndroid端末をPCとUSB接続しておきます。
    つぎに「File」->「Build Settings…」から、Androidを選択し、
    「Build And Run」を選択します。




    それでは、irofさんアイコンを
    Androidのカメラで写してみます。

    無事に3D irofさんが写りました♪


    それでは、次に動画で動きをみてみましょう。

    以上です。
    C#がやりたくて、Unity選択したのに、一切ソース書いてないですね。
    こんな簡単にARができるなんてビックリしました。

    3日目は、@daiksyさんの
    いろふインスタンスの最大数を探る。
    http://daiksy.blogspot.jp/2013/12/blog-post.html
    です。

     

    C#にて、別スレッドから新規Formを表示させる際のお作法について メモメモ

    • 2013.10.31 Thursday
    • 11:54

    メインのThread以外から、新規にFormの描画やUI制御などを行うと、例外エラーが発生します。
    その為のお作法があるのですが、良く忘れて都度ググってしまうので、自分メモとして記載しておきます。

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

    • 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上ですが、前川さんから興味深い投稿がありました。
    (公開モードなので、皆様ご覧いただけます)



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


    わんくま大阪勉強会#55でLTしてきました

    • 2013.06.02 Sunday
    • 08:41
    先週末にありました、
    わんくま同盟 大阪勉強会#55にて、LTしてまいりました。



    見ての通り、ネタLTです。

    もともとはアジャイルラジオの山根さんが言われていた、
    ダメなプログラムとして、「マネージャClassだらけじゃねぇか!」
    というセリフに共感して、作成したものです。

    資料作成するにあたり、オブジェクト指向のアンチパターンを調べていたのですが、
    あるわあるわ色々なパターンが…。
    結構、みんな自由に名前を付けているという印象でした。

    勉強もかねて、これらアンチパターンをまとめて体言化してみようかな。
    出来たら、どこかで発表したいです。


    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です。
    お忙しい中サイン頂き、有難うございました!




    SharePoint2010のSPQueryで「0x80070057」エラーが発生する件について

    • 2013.03.28 Thursday
    • 09:30
     
    SharePoint2010でSPQueryを使って、データ取得をする際、
    下記例外エラーが発生するようになりました。



    <nativehr>0x80070057</nativehr><nativestack></nativestack>



    検索してもなかなか解決しなかったのですが、
    原因はクエリーで使用していた下記文字列にありました。


    ■間違いの記述

    <Eq><FiledRef Name="LinkFilename" /><Value Type="Computed">hoge</Value></Eq>


    ■正しい記述

    <Eq><FieldRef Name="LinkFilename" /><Value Type="Computed">hoge</Value></Eq>



    判りますでしょうか。
    原因はタイプミスで、
    X 「FiledRef
    ○ 「FieldRef 


    単純なのに全然気づきませんでした。
    半日費やしてしましましたorz

    原因はとても恥ずかしいものでしたが、
    自戒の意味も込めて記載しておきます。


    【大阪】継続的デリバリー読書会(12回目)に参加してきました!

    • 2013.03.26 Tuesday
    • 04:50
      
    それでは、読書会での速記メモ .〆(・ω・` )カキカキ

    ■10.5「緊急修正」
    ・ロールバックも緊急修正の一つの手段
    ・応急処置でパッチを充てるだけが緊急修正ではない

    ■10.6「継続的デプロイメント」
    ・数をこなすしかない!

    ■10.7.1「実際にデブロイメントを行う人たちを、デブロイメントプロセスの策定に参加せよ」
    ・理由:誰でもデブロイ出来るため。
    ・誰でも理解しているということが重要。

    ■10.7.2「デプロイメント作業を記録せよ」
    ・デバック用・緊急用の2つの意味がある?

    ■10.7.3「古いファイルは削除せず、移動せよ」
    ・成果物管理だけでは予測できない不測の事態に備えるため
    ・2世代ぐらいとる?
    ・diffのdiffを取るのも有効

    ■10.7.6「最初のデプロイメントにはウォームアップ期間を持たせよ」
    ・単に温めの意味?

    ■10.7.7「失敗は早めに」
    ・失敗していたら、動作させないため

    ■12.1「導入」
    ・DBの成長は2種類ある
     →顧客操作による成長
     →システム変更による成長

    ・DBのライフサイクルは長い

    ■12.4.1「データを失わずにロールバックする」
    ・1世代のみ?
    ・リストア&ロールフィードバックという方法もある →でも大変


    ■まとめ
    今回で読書会として「継続的デリバリー」読み合わせは終了となりました。
    自分でも再度読み直して、まとめてみたいと思います。


    PR

    calendar

    S M T W T F S
        123
    45678910
    11121314151617
    18192021222324
    252627282930 
    << June 2017 >>

    selected entries

    categories

    archives

    recommend

    recommend

    recommend

    recommend

    profile

    search this site.

    others

    mobile

    qrcode

    powered

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