【勉強会メモ】DevLOVE関西2017 commitment 〜"何"にコミットするのか？〜
日時：2017-11-25（土）10:30 - 18:00
場所：大阪産業創造館
DevLOVEの秋のビッグイベントに行ってきました。今回のテーマは「コミットメント」です。これまで何にコミットしてきて、これから何にコミットしていくかについてスピーカの方々が発表されました。セッションは2つの部屋で同時進行で行われたためメモしたのは半分だけです。
どのセッションにも共通していると感じたのは、コミットメントを実行するうえで個人や組織の枠にとらわれずに向き合って取り組んでいることです。コミットメントを達成するためには必ず何らかの壁に直面するため、その壁を自分の問題として乗り越えられるかが問われるのだと思います。
DevLOVEの恒例行事として最後に参加者のグループディスカッションがありました。私も僭越ながら自分のコミットメントを考えてグループ内でディスカッションしました。コミットするのはいいけど何から着手するのか難しいところですが、同じグループの方からいろんなアドバイスを頂いて勇気をもらって帰宅しました。
（字が汚くてすみません。。。）
時を超えた越境への道
やっていること：仮説検証型のアジャイル開発
目的からはじめる（Start with Why.）
- チームのレビューが顧客・関係者とのスプリントデモよりも遥かに厳しい。
- 当事者より当事者らしい目的を持つ（Share with Why.）
- クライアントワーク、自社開発が言い訳に使える気がするのは幻想
- 2つに違いはない
- 忠誠を誓う対象は 目的
- No Why, No Dev.
目的のための越境
- 役割を選ばない
- あらゆる人を巻き込む
- あらゆる手段を取る
- 目的を問い続ける
「越境する」こと、そのものが仕事
越境に至る道
2006年：組織内の境界を超える
当時の状態：塹壕・組織の限界
デブサミ2007への参加
血があつい鉄道ならば／走りぬけてゆく汽車はいつかは心臓を通るだろう
⇒正しいものを正しくつくりたい
どこからか現れる救世主を待ち続けるほど人生は長くない
2007年夏に社内デブサミを実施
- 80人参加
- いまだに続いてる
2008年⇒組織間の境界を超える
当時の状態：生死の境界
RubyKaigi2008への参加
2008.6.21⇒コミュニティ DevLOVEを2人から始める
- 2人の安心感
- 2人いれば1人ぼっちにはならない
- 行き詰まったらまた2人に戻ればいい
⇒2人最強論
- ソフトウェア開発は一生かけても、たかだか300人月
- HangarFlight の実践
- 空がまだ未知で危険だった時代に飛行機乗りがお互いの体験を話し合った
⇒4,000人のコミュニティに成長
2013年⇒当事者意識の境界を超える
当時の状態：無謀な開発を止められないビジネスモデルの限界
（お客さんにとって意味がない開発であっても受託開発会社にとってはビジネス）
正しいものを正しくつくりたい
- 自分がいる塹壕の中だけでは正しいものを探せる芽はない
- プロダクトオーナーの向こう側に正しいものを探す可能性がある
- 自分たちで背負う
⇒ギルドワークスの立ち上げ
越境＝引力
- 全体をありたい方向へ引張る力
- 越境の方向は安定と混沌の両方に引っ張られる
越境のための視点と技術
視点⇒どの高さから、どの範囲を見るか
- 視座（高さ＝目的）…同じ範囲をみていても視座が変われば見えるものが変わる
- 視野（広さ＝人）
視座が高い、視野が広いではなく高低と広狭を可能な限り早く行き来できることが良い
技術⇒実験とフィードバックによる調整
- 仮説検証とアジャイルな開発
リーン原則とアジャイル原則
指し示す指ではなく、指の先にあるものを見つめる
- プラクティスにとらわれるのではなく目的を見つめる
- 原則に依り、目的に向かうための術を自ら見つめようとする
越境すると
- 自分の振る舞いが常に問い直される
- いかなる判断も越境した人自身のもの
越境は孤独⇒越境をenergizeしたい
- energize…活気づける
- プロフェッショナルは励まされ、動機づけられた時に最高に実りのある仕事をします
- http://shop.ohmsha.co.jp/shopdetail/000000004303/
2017年の越境
- energize+agileでエナジャイルを設立
- 2018年に事業が立ち上げられるように検証中
2018年の越境
- DevLOVEから生まれてDevLOVEに帰る
- 安定と混沌2つで1人の自分
- カイゼン・ジャーニーの出版
- たった1人からはじめて、「越境」するチームをつくるまで
- 2018年2月発刊予定
- DevLOVEのコンセプトに「3. 自分から越境しよう」を追加
開発プロジェクトの価値をあげるだけのアジャイルでいいの？～ 企業価値、製品価値向上のためのアジャイル ～
www.slideshare.net
日本のソフトウェアエンジニアを笑顔にしたい
- ソフトウェアがビジネスになって約60年
- アジャイルが動き始めて16年
未来戦略室の立ち上げ
アクションプラン：現場へのアジャイル導入
- 組織改善
- 人財開発
- 価値創造
未来戦略活動のコアにあるもの
アジャイルとは？⇒ お客様のビジネス価値を最大化するための「考え方」と「姿勢」
コラボレーションしてエコシステムを作る
- スキル
- マインド
- ノウハウ
組織力を上げる
- 一人ひとりが自分自身の「ビジョン」を持ち行動に変える
- 自ら考え発信できる場と風土を作る
- ビジネス観点で考え価値を提案できる社員を増やす
会社の成長の鍵は「人」
アジャイルマインドの3つの鍵
- ゴール⇒プロダクトオーナー
- リズム⇒スクラムマスター
- 愛⇒開発チーム
（矢印の右はスクラムにおける担当）
ゴール
- 落としても腑に落ちないとゴールにならない
- 納得と共感が必須
- もの・こと・ひと
- 「ものづくり」を活かしながら「ことづくり」するには「ひと」が重要
- レゴスプリント
- グループワーク⇒最高の飛行機を作る
- なぜインセプションデッキを書くとプロジェクトがうまくいくか？
- これを考えないとうまいくいかない
- Whyを考えてみる
- ビジネスでの成功と自己成長
- 組織のWhyと個人のWhy
- ODSCでの個人のWhyを描く
- 目的、成果物、成功基準
リズム
- 拍子ということ（宮本武蔵の五輪書）
- 短いタイムボックスで回しながらフィードバックを得る
- KPTやる
- チームが成長することが組織の価値アップにつながる
- 底上げだけではなく、イノベーターが走っていけばついてくる
- 守破離が大事
- 課題はゴールと現実のギャップでしかない
- 自分のこととして解決していけるか
愛
- リスペクトすることが全てのパワーにつながる
- 五輪書…兵法の道を大工に喩える
- スクラムチーム⇒誰しもポテンシャルは高い
- ダグラス・マクレガー「 X理論Y理論 」
- 自分自身の成功体験が邪魔していないか
- クラッシャー上司
- 自分の成功体験が他人の成功につながるとは限らない
- アジャイルの価値を語っている時点で負けかも
- 自分たちの価値を考える
まとめ
ソフトウェアエンジニアを笑顔に
⇒日本のものづくりを「ことづくり」に変えたい
ソフトウェアの価値向上が重要
アジャイルで⇒デザイン思考、リーンスタートアップ、エコシステムなどを交える
- 作り方のデザイン（リズム）
- チームのデザイン（リスペクト）
- 価値のデザイン（ストーリー）
- 品質のデザイン（価値の保証）
コードをどまんなかに
スピーカー：@irof さん
- どのポジションにいても全力で「いいコード」を書いてきた
- コードに手を抜かない
- みんなでコードを書いたらコードが真ん中に来る
ドキュメントとコード
ドキュメント
- 理解しやすい
- 整合性をとりにくい
- 人が書き、人が読む
コード
- 理解しにくい
- 整合性を取りやすい
- 人が書き、人が読んで、コンピューターが実行
ドキュメントはコードのサブセット
説明できるコード＝コードレビューのポイント
- 全行説明できること
- 説明できればいいコード
説明できるか？
- ファイルやフォルダ
- 構造、深さ、名前について
- 関連（ファイルやモジュールなど）
- 関係の有無、方向
- 関連はドキュメントに書く時は書きやすいがコードに書くと複雑になる
- 何かしらの宣言
- 名前、修飾子（アノテーション）、順序、（位置、引数の順序）
- メソッドの並び順など慣習的なものはその慣習の背景が説明できなければ慣習を破ることもできない
- なにかしらの処理
- 順序、一時変数の使用、行間、対称性（粒度）、コメント
- コメント
- 書いた理由
コードの説明
- コードは読まれるほうが多い
- 説明できたとしても説明する機会がなかったりする
- 読み物としてのコードにとって説明できるのは前提条件
コメントは何のため？
- コードに表現されていない情報を追加する
- 読み取りにくいコードを読むのを支援する
- 「コードを読まずに済むようにする」ではない
コメントの大前提
- すべての情報が変わらないなら無い方が良い
- 情報量が変わらない
- 読む時間が変わらない
ループ図 を書いてみると良いかも
呪い
- 前にこうしたから
- 他がこうなってるから
- 動作に影響ない
呪いの解き方
- 無くしたらどうなる？をひたすら繰り返す
- 知識と実践の両面から攻める
「ほうがいい」から気づく
- コメント：無いほうがいい
- 名前：短いほうがいい
- 行数：少ないほうがいい
- 引数：少ないほうがいい
早くコードを書くために
- だいたい遅いのは書かなくて良いことを書いている
- 新しく作るよりは書いたものを選ぶ
- 選ぶで済むものを書いているから遅い
- タイプ量も増えて間違える
- 選ぶ訓練おすすめ
思考の速度を上げるには余計なことを考えないこと
コードを説明する
- 自分相手でいい
- 全行漏らさず
コードをはやく書く
- 書いて観察する
- もっと早く書けないかを問い続ける
コードをどまんなかに
- いつでもどんなときでもコードを書く
- そのための速度、そのための可読性、そのための意図
コードを書いてるから要件定義が進まないはダメ
コードを中心に説明できるようになるとコンピューターで動くものとの整合性が取れる
- 説明できるコードを書く
- あたりまえのことをする
- あたりまえのことにする
UX ≠ ユーザー体験を考えるということ
スピーカー：山下 一樹 さん （ @yamashitakazuki ）
- UXという言葉は難しい⇒UXではなくユーザー体験をテーマにする
- ユーザー体験を考えるということ
UXデザインの今
時間の流れ：期待・予感⇒使う⇒使った結果⇒記憶・思い出
- 時間の流れで設計していく
- UI/UX…「使う⇒使った結果」の部分
モノと情報が溢れている今はスペックやブランドでは売れない
- オンデマンド、マルチデバイス、ユーザー参加型
- 価値はモノから「体験」へ
例）
マーケティング？UXデザイン？
- マーケティングは特定のセグメントに分けてものを売る⇒ビジネスがゴール
- UXデザインはペルソナを中心にモノを広げる⇒ユーザー理解が起点
UXデザインにはあらゆる手法がある
- 発見⇒理解⇒改善
- フェーズに合ったUXデザインの手法があり 成果物は共通認識が目的
サービスデザイン
- 従来：調査/企画⇒設計/製造
- UXデザイン：ユーザー理解⇒問題の定義⇒プロトタイピング⇒実現性の評価
- すべての関係者が参加し、反復的なフローを繰り返す
現場でのUXデザイン
- クライアント
- ディレクター
- デザイナー
- エンジニア
それぞれの役割で課題があって連携が難しい
デザイン中心の設計
- プロトタイピング⇒目に見えるものをまず作る
- 構造化されたデザインシステム⇒作っている過程を共有する
- 余った時間でプロトタイピングなどに注力
- ツールによって作る時間が短くなってきている
エンジニアが1歩踏み出してもいいかも
- 言語化された共通認識が重要
- 誰でも始められるUXデザイン
- あくまでユーザーの存在を意識する
実装は末端でモノを生み出す
「その機能誰が使うんですか？」と勇気を出して言っても良い
UXデザイン、つまり○○
考えること
- 当たり前の「期待」を考える
- 期待される振る舞いを考える
例）ボタンの形状
- 世の中のリモコンなどのボタンは角丸がほとんど
- 記憶の中にあるもので考える
期待を良い意味で裏切ること
例）dev.toの表示速度
どんな状況か考える
- モバイルユーザーの状況：コンテキスト
- 対PCセッションタイムは減少…18%
- モバイルトラフィックは増加…20%
どういう状況で使われているかが見えにくい
例）乗換案内
- 自分で出発時間や到着時間を入れる
- 駅までのことは自分で考える
例）GoogleMap
- 現在地からのルートも示す
- どこからでも検索可能
期待値コントロール
⇒使った結果が価値判断として残り続ける
- 期待から「体験価値」を発見する
- 体験価値をいかに見出すか
ユーザー体験 ↓ 体験知識 ↓ 体験価値⇒我々が最後にやらなければならない部分
UXデザインの今後
- エンジニアが感情曲線を書いてくるようになってほしい
- 想像することが大事
- 変化は緩やかだが大きい
システムには人の心を惹きつけるものが求められる
- 職業人である前に私達は「人」である⇒共通認識、期待値
- ユーザー体験を考えるということ⇒共感
ボトムアップな組織改革-会社にアジャイルな風を吹かせる-
スピーカー：増田 謙太郎 さん（ @scrummasudar ）
コミットする対象：組織改革
- 地位も権限もないが組織をより良くしたい
今日話すこと
- 社内にアジャイルを広めた活動
- 活動を通して会社が変化していく様子
スクラムマスター誕生編
プロジェクト発足
- 実現したい理念やコンセプトは明確
- 実現は困難
新しい技術に挑戦⇒スクラムの要素を取り入れてスタート
アジャイルの知識
ステークホルダーとのレビューでアジャイルを知ってもらうきっかけに
きっかけはふりかえり
-2週間ごとにふりかえりを実施 - 急遽ファシリテーターに⇒ふりかえりを良くしたい
- 仕様チームと開発チームに分かれている
- スクラムマスターがいない
- リファインメントの位置づけが曖昧
スクラムマスダー誕生
⇒社外に向けた活動のきっかけになった
3つの誓い
- プロジェクトの成功と生産性を上げるための取り組み
- 会社全体として短いサイクルでユーザーに価値を提供するプロセスづくり
- 社外へのアピールと人材獲得
研修に参加
- すぐにフィードバック：社内向けの勉強会実施
ビジネスコンテスト編
ビジネスコンテスト＝若手のスキル向上・改善風土醸成
情報をかき集める
- 過去の色々な数値（開発工数、投資金額）
- 他社事例（協業企業、ヴァル研などの先行事例）
⇒優秀賞には選ばれず
新卒採用編
- インターンシップに参加
- 内定率が高いので大手企業に人財を奪われがちな背景
- ユーザーストーリーマッピングで新規プロダクトを考える
- アジャイルプラクティスで採用活動
- 解決したい課題を提示
- アジャイルを知らない社員を巻き込む
⇒インターンは大成功
内定者は次の社員なのでそこに向けてアジャイルの良さを伝える
組織活動編
- アジャイルを広める組織
- 変化に素早く対応できる組織づくり
- 3チームに1人しかいないスクラムマスター
- 外部からエキスパートを招聘
- 自分でNDA書いて稟議を通した
- 外部からエキスパートを招聘
- まずはチームから…チームの状態を見える化する
- お披露目会実施
- 2週間ごとにステークホルダー向けデモを開催
- プロジェクトではなくプロダクトを見せる
- （追加要件ばかり出てきたのでその後やめた）
- お披露目会実施
組織の拡大⇒1人から2人の組織に
インターンシップを一緒に実施した社員が参画
他の組織への伝播
- アジリティーを意識した取り組み
- ヴァル研究所への見学会に総務部門と一緒に参加
⇒アジャイル開発で製品リリース！
まとめ
- 組織は変えられる
もちろん簡単ではない
- 時間がかかる
- 予算がない
- 他部署との接点がない
機会は多くある
- 普段の打ち合わせ
- 企画提案イベント
- 採用活動
- 評価に関わる目標
会社のイベントを活かす
- 会社に所属しているからこそできることがある
論理と情熱のミックス
- 課題を解決したいという熱い気持ち
- 課題を解決するための技術的な裏付け
たまたまアジャイルだったが他にも当てはまる
