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

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

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

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

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

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

Selenium WebDriverでTextarea要素のテキストデータ取得する際の改行コードについて

  • 2014.09.17 Wednesday
  • 11:02
Seleniumu WebDriverでTextarea要素のテキストデータを取得するときに、取得方法によって、改行コードがついて来たり、亡くなったりします。
良く忘れるので、自分メモ。

 

ぐるぐるDDD・Scrumに参加してきました!

  • 2014.03.23 Sunday
  • 13:46
2014/03/15にDevLove関西で開催された『ぐるぐるDDD/Scrum - ドメイン駆動設計。モデリングと実装のうずまきをまわしてみよう』に参加してきました。
http://devlove-kansai.doorkeeper.jp/events/8246

DDD本(鈍器)を読んで、悶々としていたところに、DDDのワークショップを開催するということで、これ幸いとスタッフとして働くことを条件に参加してまいりました。


今回は、講師をして頂きました原田様、会場提供頂きましたエムオーテックスの井上様には多大なるご尽力頂きまして、誠に有難うございました。
改めて御礼申し上げさせて頂きます。
 

いろふ式暗号を作ってみよう♪

  • 2013.12.17 Tuesday
  • 00:24

この記事は、いろふ Advent Calendar 2013の16日目の記事です。
もう17日になっていますが、気にしたら負けです。

昨日は、@Posauneさんの「いろふさんの一意性を証明する #irof_history」でした。
いろふさんはやっぱり、謎なんだなと思いました。


さて唐突ですが、本日は、いろふさんを使って、
オレオレ暗号ならぬ、
いろふ・いろふ暗号を作ってみたいと思います。

なぜそんな事をするのか?
何となく、いろふさんは謎なので、鍵にするのなら、
丁度いいと思ったからです。




さて、暗号式の作戦ですが、
鍵にはある程度の複雑さと、ゆらぎが必要ですので、
ここはirofさんのtweetを利用したいと思います。

作戦はこうです。
(1)いろふさんのtweetの中から、ランダムに2件取得
(2)2件のtweetをハッシュ化、XORで1つの秘密KEYを作成
(3)暗号化したい平文メッセージを秘密KEYで暗号化
(4)暗号化したメッセージを今度は復号化してみる

醍醐味は、取得した2件のTweetからは、暗号キーはサクッと作れますが、
暗号キーからは、どのtweetを使用したのか判らないような暗号を作ってみたいと思います。
では、さっそく作ってみましょう♪
 

■まずはTweetからランダムに2件取得


Tweetを取得するにはTwitterのAPIを利用するしかないのですが、
C#には「linq2twitter」という便利なライブラリがあります。


ライブラリを使うと、たったこれだけで、
指定したユーザの最新200件のTweetを取得することができます。
(200件はTwitter1.1の一度に取得できるMAX件数)

あとはこのTweetリストの中から、2件のTweetを選びます。
ランダム取得もLinqを使って1件取得するとなると、

こうなります。

ビバLinq!便利。
早速、プログラムで2件ランダムにTweetを取得します。



つぎは、取得したTweetを使って暗号キーを作成してみます。


 

■2件のTweetから暗号キーを作ってみよう



どのTweetから、作成されたのか判らないようにしたいので、
まずはTweetのメッセージ文章をハッシュ化させてみたいと思います。

ハッシュ化は、MD5を使うと簡単に行えます。

あとは2件のTweetをそれぞれ、ハッシュ化を行ったら、
XORで1つにまとめてみます。
これを秘密キーとします。

早速、プログラムで実装してみます。

 

■秘密キーで暗号化してみよう



作成した秘密キーを使って、平文を暗号化してみたいと思います。
暗号アルゴリズムには現在最強のAESで行ってみたいと思います。
C#では標準でAESアルゴリズムが用意されていますので、
簡単に暗号化する事が出来ます。

それでは、プログラムに実装してみましょう。


 

■暗号化した文章を復号してみよう



復号は先ほどの暗号化とほぼ同じプログラムとなります。


プログラムに実装してみましょう。


無事、復号する事ができました。

 

■いろふ式暗号の特徴



作ってみて判ったのですが、

■特徴その1
圧倒的に、強度が低い(汗
なぜなら、Tweet件数を200件としてしまっているので、
その中から、ランダムに2件選んでいるということは、
200*199回、総当たりされたら、突破されることになります。
瞬殺ですね♪


■特徴その2
時限式暗号で、賞味期限がある!
200件のTweetは古くなると見れ無くなります。
つまり、いろふさんが沢山つぶやくと、そのぶん暗号の賞味期限は短くなります。


あとは、Tweetのコメントを秘密キーにしているので、
似たような内容のコメントが続くと、暗号強度が下がるのですが、
そもそも200*199回の総当たりで突破されるので、どうでもいいです。


一応今回のプログラム(C#4.5)はコチラになります。
https://github.com/kawakawa/IrofCryptographic.git
誰得?ですが置いておきます(汗


明日は、@kazuhito_m さんの「「いろふさん絵描き歌」じゃないヤツ、歌ってみた #irof_history」です。
 

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



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


PR

calendar

S M T W T F S
     12
3456789
10111213141516
17181920212223
24252627282930
31      
<< December 2017 >>

selected entries

categories

archives

recommend

カンバン仕事術
カンバン仕事術 (JUGEMレビュー »)
Marcus Hammarberg,Joakim Sundén

recommend

recommend

profile

search this site.

others

mobile

qrcode

powered

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