AgileJapan仙台サテライト 参加レポート③
教育は遊びから
イトナブとは?
ペットボトルロケットにGoProつけてみた - YouTube
教育は遊びからということで町づくりをしている。
町づくりの団体は次の世代にうまく渡すことが使命。
若者が未来を考えられるようにしたい!
イトナブ=IT×イノベーション×営む×学ぶ×遊ぶ
遊びが最終的にはイノベーションにつながっていくはず。
イトナブの方針
2021年までに石巻に1000人のIT技術者を作る
一歩でも半歩でも自分が動くと、変わるということを感じて欲しい。
大人は「面白い大人」「かっこいい大人」でなくてはならない。
子供たちはそれに触発されていく。
イトナブの教育方針
イトナブの教え方は「勝手育」。
自分でやってみて、何かが分からなくなったら聞きに来る。それでいい。
全国のハッカソンに武者修行に行くこともやっている。
イトナブの活動
- 東北TECH道場
- 石巻ハッカソン(http://itnav.jp/archives/228)
質問
【質問】
やる気のない人はどうするの?
【回答】
そっちのアプローチはしていない。
今やりたいと思っている人に情熱を注ぐ。
【質問】
目標の1000人ですが、今はどれくらい?
【回答】
今は開発できるのが60人くらい。
その中でもイケてる人は15人くらい。
感想
古山さんはパッと見、ただのカッコいいお兄さんだけど、芯はものすごく熱い人だなーって思った。
やっぱり地元を活性化するっていうのはいいことだし、そこに向かって色々なことを自分たちが楽しみながらやっているっていうのを感じた。
しゅうたろうという子供が「アプリ作ってシリコンバレーに行く」っていうのがめちゃくちゃカッコいいと思ったし、それを言える環境を作ってるイトナブという組織は凄いなぁ~って思った。
「要件は定義するものではない。見つけるものだ。プロダクトディスカバリーのすすめ」
楽天 半谷さん
本日のメッセージ
量は質に転化する
なので、たくさん失敗しましょう
全ては仮説である。
だからこそ、早く小さくリリースすべきなんです。
プロダクトバックログ
プロダクトバックログと要件定義とは違うの?
AngryBirdは要件定義から生まれたのか??
参考)How Angry Birds started?
http://notes.fundersandfounders.com/post/82688778583/how-angry-birds-started
たまたま生き残っているものが、生き残っている。
定義するよりは発見しましょう。
ちょこっとワーク
20個の○に顔を書くワーク。 ブループの隣の人に渡して、好きなものを3つに☆印を付ける。 自分のところに戻ってきたら終了。 手を上げたらバラけていた。
全ては仮説と検証と実践
Product Discovery ステークホルダーを3人考えると色々な方面から見ることができて、良いプロダクトになる。
楽天さんの実例を交えて結構詳しく説明してくれた。 ここでは書けないのが残念(笑
質問
【質問】
使っているツールはなんですか?
【回答】
アトラシアンの製品が多い。
Stashとか。
【質問】
ペルソナの妥当性はどうやって確認していますか?
【回答】
最初はググって作って、その後に実際に会ってペルソナを変更した。
感想
要件を定義するのではなく、量を作って生き残るものを見つけよう!っていうのは面白いアイディア。 それをABテストとかでウケるのを探していくって感じかな。
楽天さんでリーンキャンバスをキチンと使ってるって凄いなぁ~って思う。自分の会社はそこまで色々なプロダクトがないけど、本当にスタートアップのときはこういうの考えて方向性を定めていかないとブレちゃうんだろうなぁ~って感じた。。。
ちょこっとワークは面白かったのでぜひ自分の友人とかでもやってみようと思う。
AgileJapan仙台サテライト 参加レポート②
実際に遠隔でアジャイルをやってみて分かったこと
メンバーズ 角銅浩平さん
アジャイル最大の敵は距離
もし遠隔でアジャイルができたなら・・・ ・オフショア ・リモート開発 ・人材の採用の幅が広がる
パターンランゲージとは?
ContextとProblemとSolutionがセットになって、それに名前が付けられている。
GoFのデザインパターンもその一つ。
[参考]パターン・ランゲージ: 創造的な未来をつくるための言語
http://www.amazon.co.jp/dp/4766419871
遠隔のアジャイルパターン
場の共有
"雑談"を含めてチームメンバー間の情報共有が行われ、チームの一体感が醸成される。
→拠点間で常時テレビ会議を行う。
全員チャット
複数チームがあるときに他のチームにも有益な情報、ノウハウは共有されると全体が改善されやすくなる
→プロジェクトに関わらないメンバーもチャットに入れる
15分の朝会
問題が起きたときに共有、対処を早くすることでロスを最小にする
→朝15分くらいの短時間で共有を行う
→全員で準備して、スタンドアップミーティングにする
→すぐに解決しない問題は2次会で!
NTT(No Talk Time)
情報量が多いとかえって集中できないことがある
→「話しかけるの厳禁」の時間を作っている
午後の2時から5時をNTTにしている
ポケット一つの法則
プロジェクトが進んでいく過程で共有すべき情報が増えて、複数の箇所に保存されている →Wikiに情報を集約し、探すコストを下げる。
[参考]「超」整理法
壁の活用
定期的に確認しないといけないもの(インセプションデッキなど)は常に見えるほうがいい
→両方の拠点に同じものを貼るようにしている
あえてアナログを選ぶことも必要
十分なドキュメント
過剰なドキュメントは作成しない。 →必要なドキュメントは作成する。(インセプションデッキ、ジャーニーマップ、ペルソナなど)
始めは同じ場所で
チームメンバーは近ければ近いほど良い →プロジェクトが始まるときは必ず顔を合わせて、チームビルディングを行う
定期的な訪問
チームメンバーの認識に自然とズレが発生することがある →イテレーション毎に顔を合わせて話す機会用いる
同じ釜の飯を食う
チームメンバーのひととなりを知ることは大事 →食べながら話すことはとても重要。 同じものを食べ、話すことは共通体験を生む
角銅さんからのメッセージ
一つだけでもぜひやってみて!! アジャイルでみんなHappyに!!
質問
【質問】
仲を良くするために一番効果があるのは?
【回答】
一緒にご飯を食べるのが効果がある
仕事と全然違う話をするのもかなり効果がある
【質問】
ネットワークを突き詰めていけば0までいけますか?
【回答】
無理だと思うので、最低プロジェクトの開始には集まりたいところです
【質問】
定期的な訪問でずれるのは何でしょうか?
【回答】
東京の方が顧客と顔を合わせる機会が多いので、その情報を取りたい
感想
自分のチームをよく分析していて、東京と仙台の距離を感じさせないような工夫が一杯あった。
結構淡々と話していたけど、ここまでたどり着くのは色々試行錯誤があったんだろうな。
SonicGardenさんとスタイルが似ていることもあり、興味深々だった。
高専生と取り組むScrum(仙台高専 力武克彰さん)
なぜScrumか
高専生は実装は得意だが、実装だけでは価値は生まれない。
なので、価値を生み出すところをキチンと抑えて欲しい。
取り組んだこと
ETロボコンへの参加(H23~H25)
スクラムの要素を取り入れながら実施した。
Webアプリ開発のプロジェクト 児童向け物語創作システム
実際にどうやっているのか?
力武さんがスクラムマスターとなり、高専生にプロダクトオーナーや開発者など様々な役割をふっている。
成果物
- プロダクトバックログ
- スプリントバックログ
- インクリメント
- スプリント計画ミーティング
- プランニングポーカーでの見積もり
- 昼会(デイリースクラム)
- デモ(スプリントレビュー)
- ふりかえり(レトロスペクティブ)
- ユーザービリティテスト
スクラムに取り組んでみた印象
一番使えると思っているのはふりかえりと計画ミーティング。これはチームの現在地を確認できる場として使える。 高専生は人間関係はできているが、逆にそれを壊すことを恐れるため一歩踏み出せないことがある。
開発対象の理解不足など、2週間で要求~受け入れまでを行うのは本質的に難しい
問題課題が見えると学生が自発的に動き出す。
スクラムマスターのお仕事はサーバーントリーダーシップ。
もっぱらお菓子の買出しを行っている。
困っていること
情報共有
環境・ツールについて
- コミュニケーションコストを下げる
- メンテナンスコストを下げる
- 学習コストを下げる
高専生が生き残るためには
- 「頼れる仲間」を「きちんと頼る」ことができればもう何も怖くない
- 組み込み系のPBLを実施している
- スーパーエンジニアとの出会い
質問
【質問】
モチベーションが低い人をどう持ち上げていくか?
【回答】
あの手この手で頑張っていますが悩んでいます。。。
【質問】
物書きは楽しくない
【回答】
本来は論文も含めて、プロダクトにするのがいいと思う
【質問】
2011年以前の学生とそれ以降の学生の違いは?
【回答】
昔は高専生ならではのガムシャラ力に頼っていた。
スプリント毎にやると効率的にできるようになってきた。
【質問】
出会いの場を作るためにはどうでしょうか?
【回答】
本当は仙台の近くにあればいいんだけど、なかなかそうも行かない。
平日の勉強会に行けるのはかなり意識が高い学生
感想
Scrumを忠実に実施している印象を受けた。
やっぱりグッと来たのは、以下の言葉。
高専生+方法論(PDCA)=価値を生み出せる創造的技術者
力武さんの、高専生をもっと高く売り込みたい!というのがとても素敵だと思った。
AgileJapan仙台サテライト 参加レポート①
今年もやります。AgileJapan2014。 早速基調講演のレポートを書いてみましたー
予習用の水野さんのYouTube
『時を超える技術』 水野和敏氏 ―あなたと部下を最高の結果に導く極意とは?― - YouTube
ソフトウェア開発者に問う ~日本人のモノづくりの本質とは~
元日産GTR責任者:水野和敏(みずのかずとし)
企画・開発・設計・生産・販売・品質保証も 全てが一体になるのが日本の素晴らしさ。 切ってしまうから言葉でつなげるだけ仕事になる。 言葉を代理してくれるのが、メカニックであり、セールスマンである。
最初からガチンと来る。。。この人は間違いなく面白いという予感!
文化の違うところに、違う経営手法を用いるとおかしくなる。 価値観を共有できるのは実はすごいアドバンテージ。 日本語は感情を伝えるのにはとてもよい言語である。
どうしても仕様などを日本語で書くと厳密ではないと感じるけど、コミュニケーションの言語としては表現が豊かなんだろうなぁ。
レーシングチームに入ったとき、まずレースとはなんぞやをやった。 How to じゃなくて、What isだ! データ解析者を3人雇って、全てのデータを分析した。 データを見ながら、相手の監督の考えもシミュレーションする。 プロのドライバーへもデータを使い毎日フィードバック。 プロのドライバーのの凄さは1時間で0.2秒の誤差。これは瞬きとほぼ同じ時間。 実はBigDataはみんなをやる気にさせるマネジメントツール 裁量権と目標を与えるとみんなやる気になる。 未来の目標を如何に共有化するかがチームの最高の仕事。
感覚ではなく、データを見ながら目標に近づいていくというのはとてもいいこと。 ただデータだけでは動かないのでパッションとデータに基づいた目標が与えられたとき、 素晴らしい力を発揮するのだと思った。
Try&Errorと言うと聞こえがいいが、言っちゃうと壊れた&直した。 無駄なTry&Errorはしない。車はエラーすると人が死んじゃう。 人・物・金・時間が従来の半分でいい。この半分はエラーがないからできる。
かなり早い段階で意識を共有して、無駄なTryをしないっていうのは凄いなぁ。。。
普通の人がお金を使うことではなく、お金持ちがお金を使わなくなることを 不景気という。ディスカウントバリュー戦略はダメだっ。
確かに安売り戦略は全てが疲弊しちゃうよね。 最後の質問にもあったけど、HighClassとMiddleClassを狙っていくのがいいんだと思う。
GT-Rはよく見るとセダン。スナップショットがそのままカタログになる。 でもそれがいいところ。トランクがあるスーパーカー作ったっていいじゃない! タイヤがバーストしても、そのままディーラーに行けてもいいじゃない! それが日本人が作るスーパーカー、おもてなしの心。
やっぱり日本人は色々なものを取り込んで混ぜることに関しては圧倒的な才能があるんだと感じた。
技術の進歩で値段は上がりますか? iphoneは?冷蔵庫は?車は? 実は値段を下げるものじゃないですか!!
それは確かにそうかもしれない。機能をつけたら付加価値になると思うのはまやかしなのかもしれない。少なくとも数年のスパンで考えると付加価値は下がっていくと思う。
低いレベルに合わせた設計と作りをしたとき、本当にその商品は 進化しているのだろうか?誰かがOKと言ったとかで作ってないですか? 会社という枠でモノを見てるから、ニュートラルにモノを見れなくなる。 会社は実現の手段であって、目的ではない。 職業の選択:What/Why 会社の選択:How
確かに会社の居心地がいいと、自分で考えることをやめて、誰かのせいにして進んでしまうなぁ。。。色々な人から話を聞いてもが多い気がする。
夏スーパーカー乗っている人が冬SUV乗るのは幸せか? 冬も乗れるスーパーカーを作ればいいじゃない! 事実を知ったら発想が出てくる。
なるほど、モノがないときはそのコンセプトは馬鹿にされたかもしれないけど、 実はそこに真の需要があるかもしれない。。。
日本車に比べ、ドイツ車はリコールが少ない。 テストコースくらいじゃ、本当の状況を再現することはできない。 ドイツはマイスター制度があるので、モノを作ることに希望がある。
技術者が国家資格で優遇されるというのはとても良い制度だと思うなぁ。 日本でももっと能力を持った人が優遇されればモノつくりが良い方向に向かうと思う。
一番上にいるのは、現場!! 現場が造れないものを設計しても無理・無駄が起こる。 現場と設計を平行で進めていく。 現場のレベルが上がらないと設計のレベルが上がらない。
設計が言ったから、設計が言ったから・・・はダメ 水野さんのマネした言い方が面白すぎる(笑
未来は言葉ではなく画像。過去は言葉。 言葉と数字でディスカッションしても未来は生まれない。 新しいこと、未来は言葉からでない。
未来はストーリや画像で語れ!!というメッセージが熱かった!!
ってか尋常じゃなく面白かったなぁ。。。
水野さんありがとうございました。
【質問】
現場と共有するためには?
【回答】
会社からの肩書きが自分の能力だと錯覚する。
会社にもらった権限を忘れる。失敗をする可能性があるが、その失敗をリカバーするために自分は一体どうすればいいのかを真摯に考える。
【質問】 リーダーやチームで共有するべきコツ 【回答】 みんな趣味で仕事している。それは仕事ではない。 仕事は人のためのもの。キーワードは"人の喜び"、それをもって共有できる。 人のためにと思うと、共有できる。 まず初めにどんな人をどのように喜ばすかを考えなければいけない。
【質問】 水野さんの夢 【回答】 日本を象徴する最高級のフラグシップを作らないといけない。 最高級(HighClass)と廉価版(LowClass)の間のMiddleClassをどうするかが分からない。 そこをどうにかしていきたいと思っている。
【質問】 ソフトウェア技術者に一言 【回答】 どうせ人生は一度きりなので、会社に囚われずに社会に対してどうしているかを考えて欲しい。趣味や欲は捨てました。ダメで元々だと思いなさい。失敗したら社長が悪い(笑 失敗しちゃいけないと思えば思うほど、何もできなくなる。
テストカテゴリの出し方(機能編)をみきおさんから教えてもらった
Twitterでワイノワイノやってたら、みきおさんからテストカテゴリの出し方を教えてもらった。
みきおさんのテストカテゴリの機能側導出の手順。 ソースはこちらを参照のこと。 http://togetter.com/li/684105
みきおさんがまとめたアーキテクチャー入りの方はこちら http://togetter.com/li/684589
機能を実現するプログラムを単純に入力、処理、出力とみなします。 入力に関するテストすべき観点は、「入力データチェック」「ボタン操作」 になるでしょう。処理に関する観点は「計算」、出力に関する観点は 「表示」になります。
この取り掛かりはマインドマップ本や、HAYST法のラルフチャートと同じだと思う。
まずは3つに分けてそこからブレイクダウンするということ。
シナリオを書いているときも同じ思考かもしれない。
これでだいぶテストカテゴリが洗い出されますが、これだけだと、 p.10のテストカテゴリには不十分です。何が足りないかというと、 「処理」のところです。単純に入力されたデータを演算して出力す るのではなく、蓄積された値を使うことがあります。
そこで、処理で蓄積された値を扱う場合のカテゴリである「登録、 更新、削除」が現れます。これまでの説明で、論理的機能構造の 入力、変換(処理)、出力、蓄積が現れています。ですから、 p.10のテストカテゴリは機能モデルから導いていることになります。
これはモデルによって変わるんだと思う。 例えば、コマンドラインでの計算プログラムだと蓄積された値は無いかもしれない。 でもメモリは必ずあるので、この機能モデルの蓄積がファイルまたはDBか、メモリを含むか道考えるかで違うんだろうな~
あるテスト対象の場合、入力、処理-蓄積、出力という機能モデルには 馴染まないものもあるかもしれません。この場合は、別のモデルを 設定すれば良いことになります。
あと、機能モデルはプログラム・スケルトンを用いた 構造化プログラミングっぽいので、クラス図に慣れていると 違和感を持つかもしれませんね。
なるほど。ちょっと納得です。
テスト対象によって、テストカテゴリ名称が変わることはあると思います。 「ボタン」が「リンク」に変わったりとか。さらに、組織の文化も 反映すると思います。エラー発生時のメッセージ確認を重点的にやる組織ならば、 「エラー処理」のようなカテゴリを追加するかも。
「エラー処理」ではなく、状態遷移に関するテストを重視するのであれば、 「状態遷移」というカテゴリを持ってくるかもしれません。 まぁ、公開されているゆもつよマトリクスを分析した結果なので、 非公開のものには当てはまらないものがあるかもしれません。
エラー処理はともかく状態遷移は機能モデルからは出ないと思う。 組織(または個人)の経験として持っておくべきなのか。。。
2014/06/25 追記
どうやらやはり状態遷移は機能モデルから導出するらしい。
また機能モデルは対象のソフトウェアに依らないが、
状態遷移だったり、エラー処理だったり意図を持ってテストカテゴリを導出するとのこと。
状態遷移や非同期処理、排他などは機能モデルのサポートから出るみたい。
http://jasst.jp/symposium/jasst12tokyo/pdf/A2-6.pdf のP7
テストカテゴリの出し方(機能編)を考えてみた
WACATEに参加して、ゆもつよメソッドについて以下の理解が足りないということが分かった。
少し考えてみないとダメだね。。。でもそれが分かったことも収穫だった!
- テストカテゴリの出し方(機能/非機能両方)
- テストタイプの網羅性とテストカテゴリの網羅性
- テストカテゴリの数と粒度
【そもそもテストカテゴリとは?】 既に選択したテストタイプに対して、どのようなテストケース条件で 変化を与えるべきかを考えたものがテストカテゴリになります。 (ソフトウェアテストPRESS Vol.10 P20)
JaSSTのサトミ塾の例。 http://jasst.jp/symposium/jasst12tokyo/pdf/A2-6.pdf P10のデジカメの例を考えてみる。
上記資料でもテストPressのVol.10でも機能モデルから出しているのですが、、、 自分の結論は機能モデルは"無理"です。 この機能モデルを常に上手く出せる気がしないっす。。。 (1) (2)
ってことで自分が考えた結果は、データ中心のシナリオから出すのがいいと思いました。
デジカメの例で考えてみると・・・
【写真を撮るときのシナリオ】 1. ユーザーがシャッターボタンを押して、 2. 写真のデータが、SDカード内部に保存される。 3. そのときにJpegに変換される。 4. 保存されたデータはSDカード内部から読み出されて、 5. 液晶ディスプレイに表示される。
ここから動詞を抜き出すと以下のような感じ
- ボタンを押す
- データの保存
- データの変換
- データの読み出し
- ディスプレイへの表示
【写真を見るときのシナリオ】 1. ユーザーが再生ボタンを押して、 2. 写真のデータがSDカードから読み出されて、 3. 液晶ディスプレイに表示される 4. ユーザーは進むボタン/戻るボタンを押し、 5. 写真のデータがSDカードから読み出されて、 6. 液晶ディスプレイに表示される
ここから動詞を抜き出すと以下のような感じ
- ボタンを押す
- データの読み出し
- ディスプレイへの表示
エラー系だとフォーマットが違いますって出て表示できないこともあるので、それを考えると実は読み出した後にフォーマットのチェックをしている模様。するともう1つカテゴリがでるかな。
シナリオを何個か書き出してあげると大体の機能のテストカテゴリは出すことができそう。
自分は結構スッキリしました(笑
機能モデルに近いクラス図からも出す方法も考えたんだけど、 クラスというより、もう1つ上の概念、レイヤーとかパッケージとかそれくらいになる気がする。 でもその場合は例えばチェックとかそういうのって、クラスだったり、メソッドだったりのレベルだと思うので、レイヤーとかとは粒度が違うので出にくい感じがしてるんだよなー
あとは感覚的にはマインドマップ本のテスト対象分析のやり方でも出せるような気がしている。 簡単なアプリから考えてみるともう少し分かる気がする。
※考え方とか間違っていたら指摘ください♪
(*1) どうやら機能モデルはシステムによってそんなに変わらないらしい。 http://jasst.jp/symposium/jasst12tokyo/pdf/A2-6.pdf のP7
(*2) みきおさんから以下のコメントを頂きました。 機能モデルはプログラム・スケルトンを用いた構造化プログラミングっぽいので、クラス図に慣れていると違和感を持つかもしれませんね。
DevLOVE仙台 泥臭い受託開発を語る
時間が取れたので、急遽参加!
そして、参加して良かった!!超楽しかった!!
今回は話聞きながら少しまとめれたので、ブログが楽チン♪
次回もこのスタイルで行きたいなぁ…
DevSen 炎上プロジェクトの経験を前向きに学ぶ(村上さん)
炎上あるある
- 要件がコロコロ変わる
- メビウスレビュー
- 赤字覚悟の案件受注
できる人に仕事が集中して人がおかしくなってしまう。 できない人はおかしくならないw
炎上の原因
- コスト度外視で納期だけ
対策は?
- プロジェクトマネージメントの強化
- PMP
- ISO
でもダメだった。。。
結局、工数が増える/品質が劣る/管理作業も増える
自分たちの問題点を直視しないで、借りてきた解決策を導入するとこうなるよね。。。
やっと気づいた思考パータン
- 積み重ねの概念がない > 昨日と今日に連続性がない
- 悪いのは自分以外の何か > だから謝らないし、自信満々
- 対策は他から持ってきたものばかり > 自分では考えてない
話せば分かると思ってたけど、分かり合えない。。。
ただし、ジャイアン(=自身満々の人)の数は少ない
真の対策は?
- 仲間を増やす
- コネクションを使って、情報を通していく
- 情報は聞かれたものだけ報告していく
- そしてジャイアンを無力化する
- 上手く行ったらチームみんなに感謝をする
以前、村上さんとお話したときの情報を少し… 「情報はプロジェクトの血と同じ。滞っていると死んでしまう。 そのために、キーマンを飲みに誘い情報を引き出す。 そして、小さくてもいいのでやってみる。 楽しそうにやっていると人が集まってくる。そうやって仲間を増やしていく。」
DevKan 受託だからと言って受け身である必要はない(大友さん)
スライド
下請けから見て誰がお客さんか?
- 元請けのA社が満足する必要がある
- 誰が何のために必要なのか
→これは本当にドメインを知ってる人じゃないと答えられない
受け身じゃないポイント① 本当の要求を持っているユーザーまで自ら辿り着く
「念のため」という言葉を上手く使い確認を行う
受け身じゃないポイント② ユーザーが予算獲得などで作成したコンセプト資料を必ず手に入れる
コンセプト資料を手に入れたら要求仕様書を作成する。
受け身じゃないポイント③ たとえ不要と言われても、要求には「なぜなら〜」を書く
なぜなら〜、〜だからだを書くことでチームの意識が揃ってくる。
これがないと、メンバー同士が憶測で喧嘩を始めることもある。
派生開発でいう理由に当たるところだと思う。 レビュー時も要求だけよりも「なぜ」という理由が書いてあった方が納得しやすい。
受け身じゃないポイント④ チームが形成される仕組みを積極的に組み入れる
いっぱい話せる仕組みを取り入れる。朝ミ、夕ミ、ランチミーティング、飲み会など。
受け身じゃないポイント⑤ 良いプロダクトを作る機会では社外もチームととらえ積極的に会話する
普段からどうでもいいことを話してないのに、大事なときだけ話せるわけがない。
お金と瑕疵以外で話して、チームとしての一体感を持つ。
要注意
会話の量は仕組みで増やすことができるが、 会話の質は個人に依存するので、要注意。
最後の会話の質は個人に依存するっていうのは本当に分かる。 お互いに尊敬の念がないとダメになることが多い。 ただどうやって尊敬の念を作っていくかは… まだ答えがない。 半谷さんの発表のように、激論をすることでお互いを強敵(とも)と 呼べるようになればいいのかな…
DevSen 「泥臭くない」受託開発なんてない。あるいはTDD/DDDのすすめ(井上さん)
泥臭い受託開発とは?
受託開発で顧客が求めているシステムは全て異なる!
Why / What / Howを常に探求し続ける必要がある。
レベルの違いはあるかも知れないけど、全ての現場が泥臭いことをしているはず。
SIer時代で楽しかったこと
かなり早い時代からのXP。 顧客にとっていいものを作れたことが楽しかった。
2001年からテストファーストをやっていたとは… 時代がやっと井上さんに追いつきましたね(笑
悩み
- ほとんど中間管理職
- システムのWhyとWhatに注意を払う人が居なかった
- 決定したことをそのままやることが重要
- 技術力が評価されない
- 周りを変えるのは難しい
- 誰のための仕事か分からない。
- ドキュメントとコードが一致しない。
- チーム全体に覇気がない
TDD/DDD
自分が良いと思っているTDDでプログラミングしたプロジェクトはバグ0。
1サイクル目は捨てる前提!!
1サイクル目は捨てるっていうのがグッと来た。 そもそもソフトウェアに試作とかという工程がないのがおかしい。 DDD勉強会in仙台参加しなきゃ!
DevKan 「私がモテないのはどう考えても受託開発が悪い!」なんてことはない(横田さん)
よこたまさた @mesodash
最近はSonicGardenやGildWorksのビジネスモデルのように情熱系受託開発が多い
受託開発あるあるチェック
- 要件定義が長引き開発の費用や時間が大幅に減った
- 作ったものが期待するレスポンスで動かない(作り直し)
- 外注したら絶望的な品質の何かが届いた(作り直し)
- そういえば今日はメールとExcelのみ
- お客さんからモーニングコールがかかってきた
終わらない開発
- なぜやそもそもを十分に把握せずに対処してしまった。
- チームのスキルを無視した技術の採用
- 個人の力技で解決
受託から自社製品へ
- 仕様を自分たちで決められる
- 自分たちが考えた機能をお客さんにイイネしてもらえる
でも売れなかった…
中途半端な状態で逃げられなどしない。
どうすればプロジェクトが上手くいくか
- プロジェクトは未知の領域
- 技術は前提
やるべきことはしっかりやらないといけない
- 見積もりはしっかり
- 真の要求をとる
チームが上手く機能すれば、プロジェクトは劇的に良くなると実感する。
上手く機能させるためには仕組み作りも必要である。
受託開発のいいところ
- 色んな技術を取得できるチャンスがある
- お客さんと直に接することが出来る
- お客さんの望んでいるものに対して、自分たちの最高を届ける
横田さんはどれくらいモテないのか、気になって仕方なかった…
まとめ
- 経営上の課題を解決する
- お客さんとしっかり向き合って、信頼関係を作る
- 現場が正しいと思うことを出来るような組織にする
開発者の良い面を引き出すのが、良いマネージメントなのかもしれない…
サービス企業も結構色々あるんですよ(半谷さん)
日々の仕事
Hadooop Cluster(2PB)使って、本社からの仕事を仙台、大阪で受けている。
今の問題
- ビジネス側と開発側に隔たりがある
- 東京と地方との隔たり
地方で成果を出すべく、ガシガシ頑張った結果、東京から見直された。
転機は東京チームと激論を交わしたこと。そして飲みにいくようになった。お互いに理解が深まって態度が軟化して来た。
心の友よ!状態になった!!(向こうが本当に思っているかどうかは分からないw)
楽しくやることが重要。あと酒。酒があれば大抵大丈夫。
楽しくやることって重要だよね。自分もそれを一番に心がけている。 同じことをやるにしても楽しくやってるかやっていないかで伸びに雲泥の差がある。
ダイアログ
自分が入ったのはチーム4:要求を引き出す工夫
要求を引き出す工夫
- 趣味を一緒にやって、時間を共有する
- 情報を独自に集めて提案する
- キワキワのところを質問する
- 実際に形のあるものを見せると意見が出てくる
- 要求よりも問題を明確にするように意識する
困った人対策
- なるべくその人をたてながら、最後は仲間に居れる
- 周りを巻き込んで動かざるを得ない状況にする
チーム形成のコミュニケーション
- アニメの話
- 朝会
- 飲み会
- お土産作戦
- 趣味の話 > 人を知る
- 自分のキャラを立てる(メンバー)
- 褒める(サスガっすw ← 大阪で大流行?)
受け身にならないようにやっていること
- 〜でいいですか?より〜でいいですよね?という話し方
- 興味がないことには興味を持っていくこと
- クオリティ感覚を持つ
- 定時になったら自分の時間として使う
- 自分が会社を動かしていく視点を持つ
- プロジェクトとビジネスの情報を公開する > 視野が狭いと受け身になる
自分のまとめ
やっぱり困っているところは結構同じだよな〜って再認識した。
Whyをキチンと取っていくのが重要であるということ。
そしてチームメンバーには感謝の念で接することですね。
ビアバッシュもここに書けない楽しい話が沢山あって良かったです♪
アジャイル開発と結婚式のビデオ
会社の後輩であり、アジャイル札幌代表であり、尊敬している友人の1人でもある鈴木こと、あつーしから結婚式のプロフィールビデオを頼まれた。
AtsushiAzusaWeddingVideo from Noriyuki Nemoto on Vimeo.
短い作成期間の中で、心配を掛けないように、いいものができるように作っていったところ、最後になってこれってアジャイルのスタイルと似ているかもと思ったので記しておく。
聞き取り
どういう感じがいいのか、食事をしながら聞き取る。このとき新婦のアズとは初対面。お互いに人見知りじゃないので沢山話すことが出来た感じ。
本題のプロフィールビデオに入ったけど、アツーシとアズに明確なイメージはない。この時、iPadに入っていた自分が以前作成した再現形式のビデオを見せたところ、気に入ってくれたので今回も再現形式のビデオを作ることになった。
後は彼らの出会いから結婚に至るまでを事細かに聞いていく(笑
昼間からビールを飲みながら、幸せな二人との話はとっても楽しかったなぁ。
◇学んだこと
相手の想像をかきたてるものがあった方が話が早い。
昼のビールはやっぱり旨いっ!!
撮影
実際の撮影のときは、二人のキューピットである上司の協力も得ながら撮影した。ここで活躍したのは一緒に撮影に付き合ってくれたいづいづ。この人はめっちゃ絵がうまくて、自分がイメージしたTシャツを何も見ずにその場で作ってくれた。ビデオの中に出てくる「勝つ!!」って書いてあるTシャツはいづいづの手書き。凄いよなぁ〜ほんとに。
◇学んだこと
最速でものを作る場合は圧倒的なスキルが重要である
編集に使ったアプリ
さて、素材が出来たのでここから編集作業に入った。
今回の編集ソフトはMacのFINAL CUT PROをチョイス!触るのが始めてだったので先ずは簡単な動画を作成してみる。
◇学んだこと
知らない道具は先に使えるようにしておくことで、不安を取り除く
Macの動画編集ソフトはWindowsに比べて圧倒的に安い!!
気をつけた事1
自分が一番気をつけたのは相手が不安にならないこと、最後にドンデン返しがないようにすること、そしてやっぱり二人が喜んでくれるものを作ることだった。
今回のビデオは5パートで作成した。
1 予告編
2 あつーしの生い立ち
3 あずの生い立ち
4 二人の出会い(再現)
5 二人の写真
2週間と短い期間だったので、基本は毎日メールとリリースをした。一つのパートが毎日出来ていくので、安心したんじゃないかと思う。その日にリリースできないときは予定をメールするようにして、無駄な不安を生じさせないようにした。
字幕などは最初につけずに、後でつけるからということにして全体をリリースしていった。
◇学んだこと
相手が不安にならないようにすることが重要と考えた。それには細かいリリースが一番。
気をつけた事2
ソフトウェアほどではないが、どうしても変更を行うと音と映像がずれたりと影響がでる。逆に言うと音や映像のズレなどに気をつけていれば、その他の不具合は気にしなくてもよいというのは楽だった。ただたまにFinalCutの特性か、ある特定の部分で変更がされないことがあったりしたが、それに関してはFinalCut自体を再起動することで直った。
毎日のリリースで気になった事
ここで気になったのは、要求元の二人からあまりリクエストが入らなかったこと。一応、会社の先輩後輩でもあるので、言いたいことが言えないんじゃないかと不安になる。最後の方にはリクエストあったので、このときに初めて満足してくれてたんだなと分かって一安心。
◇学んだこと
最初に良い関係を構築しておかないと、満足しているのか、遠慮しているのかわからないことがある。
最終リリースと当日の上映
1週間前になんとかリリースして、二人はとっても喜んでくれた。そして結婚式当日、自分は参加者としてみんなの声を直接聞く事ができた。ワイワイ賑やかだった会場が静まりかえり、みんながビデオを見てくれるのがとっても嬉しかったのを覚えている^^
評判も良くて3次会まで話題に困らなかった(笑
◇学んだこと
実際に見てくれた人の生の声聞けるってとっても嬉しいし、幸せだと思う。
感想
今回のビデオ作成はチーム開発という部分は少なかったものの、振り返ってみるとかなり自分のイメージしているアジャイル開発に近いと思った。
作りたいアイディアや想いも重要だけれども、作れる技術や道具というのはベースとして絶対に必要である、普段から意識してそのベース上げる努力が必要だと思う。
その上に相手を不安にさせない方法+相手とイメージの共有に力を注ぐことで、手戻りを最小限に留め、磨き上げの時間を多く取る事ができるんじゃないかな〜と思った。
アジャイルな方法で実施しようと思ったわけじゃないけど、アジャイルについて勉強したり考えたりする機会が多いので、そういうのが少し出てきたんじゃないかな〜って思っている。