札幌 Java Conference 2012 - 午後

札幌 Java Conference 2012 の午後の分の忘備録です。
午後はちょっと体力キレ気味でした。。。

• 顧客と PM と PG の話は何故噛み合わないのか（鈴木さん）
• コロケーションアジャイルの実践（松館さん）
• Android やってはいけない UI/UX（高橋さん）

鈴木雄介さん - 顧客と PM と PG の話はなぜ噛み合わないのか

プロダクトマネジメントとアーキテクト設計について本来はどういったものなのか説明するよ、っていうお話でした。ほむほむ

自己紹介

• 日本Javaユーザーグループ会長
• @yusuke_arclamp

どの立場？

• 立場によって考えることは違うよね
• PM
• 技術リーダー
• 保守リーダー
• 顧客
• 例えば
• PM だったら赤字は絶対出せない

"何を考えどう判断すべきか"

ソフトウェア開発とは

• ソフトウェア品質モデル
• プロセス品質 - プロジェクトのプロセスが良いかどうか、後に残らない
• 内部品質
• 外部品質 - テストの対象、設計の対象になる
• 利用時の品質
• それぞれの品質は依存し、影響を与える
• バランスを撮ることが大事
• 組み合わせが良くない、というのが起こりがち
• 失敗の原因は品質間の依存関係が壊れていること

どうやったらよい依存関係、影響関係をつくれるか

• プロジェクト・マネジメント
• プロジェクト・マネジメントとは
• PMBOK
• 失敗してから読み直すとよく分かるらしい
• 9つのナレッジエリアで定義されている
• 縦の列として、計画、実行、調整がある
• プロジェクトの自己原因は2つ
• 計画の問題
• 実行の問題
• PMBOKは「計画と実行の差を把握する」ための知識群
• 予測して調整を行うことがプロジェクト・マネジメントの本質
• アーキテクチャ
• アーキテクチャとは
• 制約のあるなかでミッションを達成するシステム
• システムには利害関係者が含まれる
• 利害関係者には関心事（ビューポイントがある）
• 全員のビューポイントを集まる点をモデル
• モデルを達成するものをアーキテクチャと呼ぶ
• （・・・で合ってたかな？ちょっと自信ない・・・）
• ライフサイクルあで意識した
• システムの分け方と組み合わせ方のこと
• アーキテクチャとマネジメント
• プロジェクト・マネジメントはプロセス品質？
• NO
• スケジュール管理=プロジェクト・マネジメントではない！
• アーキテクチャとは内部品質？
• NO
• 構造/構成=アーキテクチャではない
• 両者にも必要なのはプロセス間の影響を正しくする、ことが大切
• 答えありきのようなプロダクト選定も問題
• 状況を見て決定を行うことが必要
• 「問題の予測と対応」「問題対応能力の確保」
• プロジェクトマネージャーは事後的な活動がメイン
• アーキテクトは事前的な活動がメイン
• WBSはアーキテクトが作った方がいいと思うんだ
• スコープ管理部分ってアーキテクチャ設計だよね？
• よく知らない人がやると悲劇
• 純粋なプロジェクトマネージャーのしごとではない
• マネジメントは必ずしもPMだけのものではない
• アーキテクチャ設計は必ずしもアーキテクトだけのものではない
• 不満はPMに還元しないと好転しない
• マネジメントとリーダーシップ
• それぞれ違うもの、組織論から
• 役割、特徴がそれぞれ違う
• Do things right と Do the right thing
• 自分の得意と不得意を認識する
• 完璧な人などいない
• 帽子をかぶり直すことが大事
• 内圧と外圧のバランスを取り、張りを維持する
• こちらがわの理想と制約、要求とのバランスをとる

選択することは簡単ではない
理由を説明する「責任」と、結果を受け入れる「覚悟」が必要

@matsudate 松館さん - コロケーションアジャイルの実践

横浜と札幌というロケーションが離れている環境でのアジャイル開発を実践されている松館さんによる実践例の紹介と、Martin Fowlerの事例との比較でした！

コロケーションってなんだろうと思ったのですが、co-locationだったんですねー。

（アジャイルジャパン札幌サテライト以来ですね！）

• 海外の事例とオーバーラップしての事例の紹介
• 北海道は海外とのオフショア開発と似たとこあるよね？

企業のニーズ

• 大きな2つのニーズ
• リスク分散、安価 - オフショア開発
• 品質・顧客満足 - アジャイル開発
• この2つの方向には大きな隔たりがあるのではないか
• 管理・責任：独立vs連帯
• 作業分担：分割vs共有
• コミュニケーション：疎vs密
• 価格が安いからオフショアってのはどーよ？

オフショアアジャイル

• 松館さんの信念
• 開発はロケーションを選ばない
• よいものはよい環境とよい人材で作られる
• よい人材はよい待遇でしかるべき
• 信頼、安心を前提としてチーム構成
• オフショアアジャイルの先駆者
• Matt Simons(2002): The Challenge of Offshore Development
• コミュニケーションの低下
• プロジェクト状態が見えづらい
• Configuration management
• 見積りの差
• Margin Fowler(2003 - 2006, 2011):the article did not need a frther significant revision

Martin Fowler との事例との比較

• Martin の事例とは大きく次が違うよ
• 時差がない
• 人数が少ない
• 宗教の違いがない
• Topic1. continuous integration
• Topic2. have each site send ambassadors to the other sites
• マネージャ、リーダーの派遣、常駐でコミュニケーション・ギャップを埋めるのが大切
• 横浜時代から周到な準備を行なってきた
• 月１回以上のリーダーの出張打ち合わせなど
• Topic3. use contact visits to build trust
• ２つのタイプの訪問
• プロジェクトの初期の関係、環境構築
• タスクの実行、ふりかえり、計画変更時
• 試行錯誤
• 両環境をカメラでつないだり
• 遠隔地でペアプロしたり
• Topic4. don't underestimate the culture change
• Topic5. use wikis to contain common information
• wiki とか便利つツールをフル活用
• Topic6. use test scripts to help understand the requirements
• 要求仕様を明確化する上で非常に有効
• ペアによって作業することでシェアしていた
• Topic7. use regular builds to get feedback on functionality
• Feedbackの早期発見
• ユーザー教育
• Topic8. use regular short staatus meetings
• Skype朝会
• 持ち回りで一言
• Topic9. use short iterationn
• Topic10. use an iteration planning meeting that's tailored for remote sites
• 遠隔地に適した計画ゲームへの準備
• Topic11. when moving a code base, bug fixing makes a good start
• ソースコードの保守如何はbug fixから始めるのがよい
• Topic12. Separate teams by functionality not activity
• 工程ではなく機能によるチーム分担
• Topic13. expect to need more documents
• 文書やそのかわりに便利なツールを利用しましょう
• 開発チームが必要なドキュメントのこと
• ドキュメントには間違いがあってあたりまえ、気づいたら作りなおす
• Topic14. get multiple communicationn modes working early
• Topic15. costs and benefits of offshore development
• Topiic16. the future of offshore and agiile

高橋さん - Androidアプリやってはいけない UI/UX

AndroidのUIって難しいよね、こういう特徴があるよーっていうのがメインの話でした！難しいですよねー

• 松館さんの会社の方

Android Playストアの現状

• 登録本数は70万本を突破（多分非公開のもの含む）
• 2012年9月 250億DL達成
• 日本は Android 後進国
• 国別のトップ10は入れ替わりが激しいらしい
• 人気カテゴリはやはり"ゲーム"

2012年はAndroid元年だったんじゃ

• 日本のアプリ市場はこれから？
• でもカオス
• Playストアは玉石混交
• 競合が存在する中で"何に価値を見出すか"
• UI/UXを考えていこうぜ

UI/UXは誰の仕事

• UI/UXはデザイナーさんだけの仕事？
• NO
• UI/UXは"技術"
• UXとは
• 多くの概念を包括した用語として使われている
• 今回は「システムと出会うことで得られる経験」
• ユーザーがやりたいことを、楽しく心地よく達成できるかを重視する
• UXで大事と言われる7つの要素（超有名なハニカム図）
• 「UX ハニカム図」あたりで検索するといいらしい
• こまけぇことはググれ
• デザイン難易度が高いのはAndroid? iOS?
• 圧倒的に Android の方が難しい
• 端末の種類が多様すぎる
• 特にスマホとタブレットの両立は難しい
• スマートフォンとタブレットは持ち方が違う！
• バージョンによるUIの差が大きすぎる
• ２，３，４で全然違う
• 物理ボタンの有無とか
• OS標準のナビゲーションボタンの数が多い
• IOSは１つだけ、アプリで制御しなくて良い
• Androidは3つ、アプリで制御出来る
• アプリごとに異なる動作になってしまう
• ユーザーに使いにくいという印象を与えてしまう

やってはいけない

• 【すべての端末に対応しようとしてはいけない】
• 端末が多すぎるので限界がある
• マツウチさん「10機種くらいでいい」
• 今だと4.x系に絞ってもいいかもね
• 【ターゲットを忘れては行けない】

• 特化したUIを検討するのが良い
• 誰が使うのか
• いつ使うのか
• スマートフォン？タブレット？
• どの指で操作する？
• 【よく使う項目を画面の上部に設置してはいけない】

• 押しづらい
• かといって最下部ピッタリもダメ
• ホームボタンや戻るボタンとの誤りタップ
• 【やたらと縦スクロールさせてはいけない】

• 画面を切り替える操作なしデモ必要な情報うが揃っている状態が理想
• 【IOSを意識し過ぎてはいけない】
• 【セオリーを無視してはいけない】
• 無視しては行けない
• 革新的なUIのみが許される
• 【情報が多すぎてはいけない】
• 【すべての操作を一律に考えてはいけない】
• 操作を平等に扱う必要はない
• よく使うもの
• ないと困るけど、たまにしか使わないもの
• 使用頻度に応じて考える

その他の話

• ユーザーは残酷
• Playストアからダウンロードされたアプリのうち約37％がアンインストールされる
• 別の統計ではインストールからアンインストールまで約7分？という調査も
• 直感的にわかるUIが求められている
• ユーザーは使い方を覚えてくれない
• 説明を読んでくれない
• 使い方を
• 原則
• セオリーに従うこと
• 文言はシンプルに
• 文字より画像
• メニューには必要項目のみを
• 同じに見えるものは同じ動きを
• Design Androiid Developpers（公式）
• 役立つサイト
• ANDROID PATTERNS
• 安藤日記
• Mobile Patterns
• Mobile Design Pattern Gallery
• おすすめ書籍
• Android Layout Cookbook - あんざいゆきさん @yanzm
• ＋4.2ベースの新しいのが出ている Android UI Cookbook?
• 使って欲しいサービス
• Google Developpers Live