this episode means a lot to me

自分のためのブログです。日々のやったこと・ふりかえりを主に書いています

MENU

【DevSumi2020】質とスピード

概要

event.shoeisha.jp

プロジェクトマネジメントにおいて、QCD(Quality, Cost, Delivery)という概念があります。 何かを重視すると、別の項目が犠牲になるという考え方ですが、ソフトウェア開発の文脈において、質(Quality)とスピード(Delivery)には本概念は当てはまりません。 質と開発スピードがトレードオフの関係であるというのは典型的な誤解です。 本講演では、どのように質とスピードを考えればよいかについて述べます。

スライドはこちら

プログラム内容

仮説

  • 品質を犠牲ににして開発スピードをあげると、どのような結果を招くのか?
    • 短期的には得られる、スピード
    • 中期的には逆効果
    • 長期的には致命傷になる

と、仮定される。

そもそも品質とは?

様々な切り口はあるが、本セッションでは 内部品質の保守性(テスト容易性、理解容易性、変更容易性の3つ)と定義する

※内部品質に着目するのは、製品側の品質特性を考えるため自然。

この保守性が失われることで、実際の現場では、

  • 変更容易性が失われると、動くコードに触るなとなる
  • コピーを始めると、可読性が落ちる
  • 致命的なバグがあると似た箇所を修正するが、コピーした箇所の漏れがある可能性もでる

現場で保守性を犠牲にした結果起こること

保守性を後回しにするような組織では往々にして市場リリースへの納期のプレッシャーに常にさらされていて、コードがクリーンな状態になることはないされることはない

では、保守性とスピードはトレードオフか?

保守性をあげるために時間を設けても、技術力のない人にとってその人の技術力以上のコードは書けない ※ただ、教育の時間は取れるため改善の流れはできる

一方で、技術力のある人は急いで作っても一定以上の品質のコードを書いてくる コードを書く際に意図的に品質を落としたとしても速度をあがらない

むしろ、最速のプログラマはコードを扱いやすいことに最新の注意を払っていたという事例が観測される。 このことから、実は保守性とスピードは逆相関ではなく相関があるのでは?

保守性とスピードの相関である要因を言及

保守性 → スピードの影響はどうか?
  • 可読性があがることで予防コストを低減できる
    • 不良対応コスト・本番障害になるとより対応のコストは跳ねあがる(200倍)
  • スピードを維持するということは、学びのFBが早まるということ f:id:ruzxas:20200219115420j:plain
スピード → 品質への影響はどうか?
  • スピードを上げるとバグによる手戻りが発生する。
    • 手戻り中は学びを生まない期間である
    • 開発のリードタイムへの影響もある。この間は仮説検証プロセスが回らない(遅れる)

つまり、保守性とスピードの相関の相互作用は

  • 内部品質がスピードを海
  • スピードが学びのループを生み
  • 学びのループが外部品質を生み
  • 外部品質が競争力を生み
  • 競争力が売上を生み
  • 売上が内部品質をはぐくむ

構造になっている。

 結論

内部品質を削るのではなく、スコープを削る or リリース日の延期が正解となる。

所感

開発者で内部品質と外部品質を意識して開発されているのは凄い。

本題から逸れるが、アジャイル開発の製品の仮説検証の速度が重要視されるケースにおいては、社内での動くモノのレビューもしたいため、多少のコードの汚い状態でもいいので機能の妥当性確認として動くものをレビューするというフェーズもあっていいのかなと思った。
その点は、TDDで動くものからリファクタリングするという流れになると思うが、開発者視点で理解できるよう手を動かしていきたい。

【DevSumi2020】常識を破壊するティール組織とエンジニアリング組織論(片岡 俊行[ゆめみ])

event.shoeisha.jp

ティール組織の代表的な企業であるゆめみにおいて、実際にどのようなエンジニアリング組織設計が行なわれたのか。 全員CEO制度、給与自己決定、承認プロセスは無し、性悪説経営など、常識外れとも思える組織設計の背景にある本質的な原理原則を解説いたします。 既存の常識から解放される事によって見えてくる新しい視点と共に、具体的な実装事例を公開いたします。

togetterはこちら
togetter.com

ティール組織とは

共通した特徴、MDAとは異なる 自律分散協調し、進化型の組織をティール組織。(家族・生命体を指す)

組織は以下の順に発達してきた。 ティール組織の特長は、前の土台の特長を踏まえつつ、メリットは活かしデメリットは補完される構造を持つ。

  • 群れ
    • 力・恐怖で支配、短期的な活動 ― 緊急で危機回避的な動き方ができる
    • 力が弱まると裏切りも。長期で安定しない
  • 軍隊…
    • 階級・序列とルールで支配。秩序・計画性が生まれる。
    • 群れに長期的な視点が加わった状態
    • 上の言うことは絶対なので不合理、組織の入れ替えはないので外部環境の変化に弱い
  • 機械
    • 合理性と能力的主義を追加
    • 機械の部品のように効率性・イノベーションを生み出していく
    • 格差が生まれる・コンポーネントのような働きをするため非人間的
  • 家族
    • 合意形成や価値観を重視
    • カルチャー・ヴァリューを打ち出す。でぃずにーなどcrewなどの呼び名も
    • 権限移譲・両行な人間関係
    • 意思決定の遅さ・弱者救済で自己犠牲、弱者救済で温情主義
  • 生命体
    • 自律分散協調
    • 素早い意思決定を行う、全員で主体的に役割分担、
    • 次々へと変化するため、変化への不安、自律組織的である。

ティール組織の具体例

  • 10年で1万人の組織
  • 1チーム12人の看護師が全プロセスに権限と責任
  • コーチは45チームに一名と少数
  • バックオフィスは40名と同様に少ない
  • ラクラシー
    • 役職主導ではなく役割手動
      • 役職は責任が明確だが、ロールを複数跨ぐ状況はおかしい
      • プロジェクト管理・売り上げ利益予算管理・業務標準化・ルール決め、人事考課・目標設定・面談
    • 役割分散できる
      • カウンセリング・コーティング・キャリアコン札は専門性がいるので分割。
      • 役割検討会議でロールを定義する(組織の自己設計できる仕組み)
      • ボトムアップで組織変更・人事異動
      • 小さく変わると外部環境に痛みなく買われる。が忙しい 役職と役割のマトリクス型組織、縦割りの圧力が強く横が弱くなりがち

給与設計の例

経営 ⇒ 制度・ルール⇒ マネージャ ⇒ エンジニアというフレームで考える。

既存の組織だと、金銭報酬による動機付けが行われ、エンジニアの想像性・成果につながらない

ティール組織とは被評価者が、制度自体を変えることができる権限(=自律的に動く)がある。
例えばエンジニアがルールを作れるルールブックがある状態。エンジニアは自分を評価するルールを自己設計しているような構造。

それに伴い、経営者の役割もゲームシステムデザイナー的な
ルールが守られることを観察すること・外部の制約(法律など)に遵守しているかの確認に変わる。

所感

ティール組織の定義は初めて聞いたが、Cybozuさんとか不思議な組織だと思っていたらティール組織だったことに今更気づいた

ただ、ティール組織が自律分散的な活動と、力・恐怖の共存する状態が混在するという状態が成立するのに違和感を感じた状態はまだ呑み込めていない。

【DevSumi2020】世界最高の靴売場をシューカウンセラーとともにデジタル変革してみた

世界最高の靴売場をシューカウンセラーとともにデジタル変革してみた

世界最高と言われる伊勢丹新宿店の靴売場では、パンプスやヒールで悩む女性向けにフィッティングサービスYourFIT 365を提供しています。デジタルな「足の3D計測によるマッチング」とアナログな「シューカウンセラーによるフィッティング」を組み合わせ、毎月1000人以上のお客様が利用しています。このサービス開発では売場経験者をPOに、売場メンバー参加でカスタマージャーを作成、業務視点でUIUX設計など様々な取り組みをしました。本講演では、それらを紹介しながら、デジタル変革で現場をブーストさせるために大事なことをお話しします。

event.shoeisha.jp

コンテンツ内容

  • 婦人靴向けのパーソナルフィッティングサービス
  • 3Dスキャンするとパンプスをレコメンド
  • 実績
    • 7ブランドからスタートし、現在25ブランド250足対応
  • phase 0:2年間にわたる模索
    • 文化:足に合う靴を提供したい
    • 新人とベテランのスキル差を埋めるための3D計測できないか考えた
    • ベンダの要件は計測制度の高さと、情熱の高さを決めて
    • アジャイルの採用を役員が即断(従来の開発手法だと失敗する、特に採用の理由には触れない)
      • POは現場メンバーでなければならない
      • やり取りは現場メンバーと開発メンバーが直接すること.
    • yourFIT専任、PO支援のためのメンバーを追加
  • phase 1:駆け抜けた立ち上げ
    • リリース日は確定していた。(期間5か月)
    • まず関係者全体で話し合った。(POはシステム開発のわからない状態からスタート)
      • ベテランと新人の話す機会があって良かった
      • ビジョンと優先度の共有
      • リーンキャンバス・カスタマージャーニーを作成
    • データを入手する
      • レコメンドには木型が必要するが、普通は門外不出(デザインを盗まれる)である。
      • 過去のバイヤーとシューズブランドの信頼関係でクリア
    • 自分たちのサービスに
      • お買場のメンバがサービス名・ロゴデザインなど剪定
      • 頻繁にdemoしにいく
    • サービスブループリントを利用
      • 業務のシーケンス図を定義する(アクター・データ・業務)
      • 足を計測してからの時差(スタッフが顧客への引き延ばし時間)を確認
    • 3か月で初期リリース
      • 最初の1~2か月はアジャイルのトレーニングなので、実質開発期間は3か月程度
      • 機関APIチームと連携(会員情報・商品情報・在庫…
    • リリース日
      • 毎日数十件+接客(1接客に1-2hほど)
      • 最小機能でリリースしたため、日々のFBへの対応をしていた。
  • Phase 2:次に向けて
    • 11月から安定期にして、予約件数を絞った
    • 何をすれば満足度を下げずに効率化できるか
    • どうすれば価値が上がるかの時間を設ける
      • スタッフの接客時間が長い、前の顧客を待たせるなど課題はある
    • ユーザビリティ調査顧客がどう利用しているか、何があれば便利か。
      • 接客しながらアプリを使ってもらう。機能の理解性などをみた
      • 再来店を促す
        • 以前買った顧客は、夏と冬用の靴でも同じ木型は安心して買える
        • 同じ木型であることを訴求するとCVRはあがる
      • データを活用する
        • 足形から靴を作る
          • 昔よりも人の足は細くなりつつリサーチがあると思いきや、実際に計測してみると足先が幅広な顧客が増えてきた
        • 新たな顧客を見つける
          • パンプスを美しく履きたい+歩き方講座・トレンド講座など抱き合わせの提案など、百貨店ならではの藏合提案力
  • 半年間で学んだこと(ともにつくるとは)
    • 当事者意識を持って行動する。逆に当事者意識のない人はいらなかったな
      • デジタル変革を求めるプロジェクト・リアリティが求められるケースのため
      • 顧客と、共に学んで改善する。サービスを育てる。システムの成長につながる
      • そもそも誰も知らない商品を仕入れて提案する文化だったり、スタイリスト個人技中心だったので、顧客に聴いたりや汎用化せざるおえないデジタルツールになれるのは難しかった
    • アナログと共に作る ― アナログの力をデジタルでブーストする
    • DX導入パターン
      • 既存組織とともにつくる
        • 適度な自治権を現場にあたえる。(出島型
        • 新しいことをするので開発プロセスは分離するし、セキュリティや運用ルールは遵守する必要がある
        • 距離感
          • 島型:既存に影響されてしまい、スピードがでない
          • 島型:既存のシステムから...
  • そして広げる
    • DX推進向けの機能子会社を作成
      • 目的は既存の枠組みではやりにくいことをやるための枠組み
      • メンバーを流動的にすることで違うことに取り組んでもらう
    • 社外から取締役を照合
    • 道をつくる。組織の力にしていく必要がある
      • DXへの理解や、ITのアジリティが不足している。
      • 苦労した要素を整備する
    • 共に作るIT部門にしたい
      • 今回のお買場が試行錯誤して【学ぶ場】を提供する
    • お買場のワークショップの開催
      • 関係者全体で顧客サービスを考える。
      • イデアが固まればトライアルをして、サービス提供につなげていく
      • PO/PO支援教育
    • プラットフォーム再設計
      • サービスを作る場合の土台
        • 平日日中の無停止リリース
        • どこからでも本番作業
      • 機関データのリアルタイム連携
      • トライアルがしやすい顧客管理ツール

感想

アジャイルの成功要因について多岐にわたって、事例が挙げられていて参考になる。 自社の提案力(百貨店ならではの歩き方講座など)と、技術を掛け合わせて顧客体験を挙げていく話はよかった。

【DevSumi2020】アジャイル開発の原則を守りつつ、マルチサイト開発を行なう! ~ベトナムのメンバーとともにつくる~

プログラム内容

  • クラスメソッドさんは社員もオフショアもスケールしている
  • アウトソーシングというよりは、共同開発をしているようなもの.モダンオフショアと本セッションでは定義する
  • ヤフーの事例 倉貫さん
  • レガシーオフショア
    • 経済格差によるコストメリット
    • 現地使用人の技術力不足(やコミュニケーションの問題が生じやすい)
    • いずれも事実に反する
  • アジャイル×オフショア支援に奔走していますという話
    • 資料見てね
    • Scrum Kanban、KPT
  • アジャイル×オフショアについて話していく
    • モダンオフショア:優秀なエンジニア確保・共同開発・フラット・境界は代理PO・無し、仲間、アジャイル
    • オフショア:安い,上下,顔見えない,顔の見えないリソース,計画的
  • モダンオフショアを成功させる7原則
    • 大切なのは人と人とのコミュニケーション
    • 1,相互利益
      • あらゆる拠点のプログラマーが(相対的・その土地の中では)給料のいい仕事をする。
      • 安かろう脱却しないと離職や品質低下につながる
      • お互い設けようの精神
      • 日本。ベトナム共にQCSは同じ
    • 2.信頼
      • 意欲に満ちた人を集める
      • マイクロマネジメントしない。情報・権限を制限しない、
      • 透明性の確保
        • kannban、単一のコードベース、デモ
    • 3.リスペクト
      • 人として重要な存在である感
        • メンバー全員の名前を覚えるところから始める
      • 繋がりを大切にする・礼節を重んじる
    • 4.組織は拠点配置に従う
      • 一緒に作業する人は同じ場所にいられるようにする
      • ベトナムで閉じたscrum開発を目指す
        • ベトナムから日本に来てもらう、その逆、拠点を跨いだ開発もやった - 日本側のPMTLがWCDを担保
        • 頻繁な出張ベトナムが必要
      • ブリッジSEを置かない、代理POをおくことはある
        • 後ろの人の顔が見えないと..
    • 5.離れて作業する前の顔合わせ
      • 信頼とリスペクトにつながる
      • 自分が一緒に働く相手を知る機会を与えて、プロジェクトの統一感が必要
      • 飲み会するよ。新規プロジェクトの時は実施
      • お客さんにも出張に参加してもらうと効果的
    • 6.個人との対話
      • 出張時は直接、個人と対話
      • リモートでも日越エンジニア同時は直接slackチャット
      • zoomやmeetでは窓口(コミュニケータ、代理PO)を立ててつたない英語はカバーする
    • 7.出張に備える ― 出張のための予算が組み込まれていないとプロジェクトはやっちゃだめ
      • 毎月の見積もりを含める
      • フェイス to フェイスで一揆に課題が解決することが多い
  • レガシーオフショアから変わらぬベトナムの魅力
    • 動員力
      • 2桁の増員依頼にも対応
    • 不確実性のある開発の時は、決定を遅らせる。一本に絞らない。そこにオフショアという選択肢もあり。
    • 熱気がすごい。GDP7%前後.ALWAYS 3丁目の世界観
    • 親日・教育水準の高さ
  • レガシーオフショアから変わらぬベトナム課題
    • 分業体制
      • 分析・設計・テスト・プログラミング・結合。PG⇒QC
      • 現場は騒がしい
    • 英語は日本もベトナム人も苦手
      • face to faceの会話が通訳を介すので、非言語コミュニケーションがロスする
        • 雰囲気からプロジェクトの状態を理解する
      • 一方、仕様・プランニングはコミュニケータを介する
      • コミュニケータも雰囲気を伝えてくれる人がいい
      • mot hai ba zho?だけ覚えておけば一体感が作れる

感想

・日本のエンジニアはスキルが足りない!
・日本には何でもあるけれど、希望だけがない。
ベトナムPGはQAと仲良くしたいがゆえに、わざとバグを仕込んでいる
というジョークを交えつつ楽しく聞かせてもらえる会だった。

【DevSumi2020】A retro on agile ー アジャイルをふりかえる

event.shoeisha.jp

世界のソフトウェア開発を変えるムーブメントとなったアジャイルについて「ふりかえり」を行いましょう!

このセッションでは、SaaSの構築に携わって15年以上のJasonが、アジャイルにまつわる迷信や課題、機会などについて議論し、Jira Software のリード・プロダクト・マネージャーとして経験した事例や学びを交えながら、アジャイルはどう使うのが良いのかを共有します。

 プログラム内容

  • 話すこと
    • アジャイルの意味がゆがんできた - 外部の人との協調?
    • 継続的な向上のためどうすればいいのか
    • チームの健康状態を大事にしてほしい
  • アジャイルの原則に照らし合わせて
    • 計画がないことがアジャイルだとはき違えてはいけない
    • 未完成でもリリースすることで、FBから立て直せる
    • アジャイルはするのではなく、アジャイルの精神になることが大事
      • スクラムプロセスは形成・混乱・統一・機能期をたどる
      • cynefin(問題の複雑さをカテゴライズする)FWと開発プロセスを併せる
        • 単純 - waterfall
        • ややこしい - agile/water fall
        • 複雑 見たことない・経験がない 反応を見てから - agile
        • カオス 最適な方法をとる時間がない Kanban
        • 混乱 - カテゴライズを誤った場合に崖から落ちる
    • ヘルスモニター(アトラシアンモニター)
      • それぞれの質問に対してメンバーで集まってじゃんけんっぽくカードを一気に出す
      • trelloでバラバラの意見に対しては意見を交わす
    • 顧客との協調性をハッカソンを通じて形成?
    • SPARRING 気軽に試せる環境
  • 製品かサービスか?
    • stay lean, stay loveable, be agile
      • リーン:アジャイルの原理に従って反復開発、スクラムからカスタム
      • 筋トレ:問題なく動くソフトを継続的にリリースする
      • 愛される:価値があがるように反復する
    • 結果よりも成果に価値を置く。結果はやったことで、成果は顧客に与えた価値?

所感

  • 仕事だけでなく、私生活でもagileになることを意識しているけれど未完成の状態でも終わらせるだとか複雑さ・分からない情報に対してどうアプローチしていくかというところは難しい。本セッションを通してアジャイルについて再度振り返りたい

【DevSumi2020】新しいHTML<portal>を利用した画面遷移設計 〜PayPayモールとYahoo!ニュースの事例を添えて〜

新しいHTMLを利用した画面遷移設計 〜PayPayモールとYahoo!ニュースの事例を添えて〜 https://event.shoeisha.jp/devsumi/20200213/session/2384/

新しいHTML要素のは、Webの画面遷移体験をよりシームレスにすることが可能です。 ヤフー株式会社が運営するYahoo!ニュースとPayPayモールではPortalsを導入し、先日「新しいHTMLタグportal、Portals機能で変わるWebの遷移体験!CDS2019で紹介されたヤフーの実装例 #UIUX」というブログを公開しました。 ブログでは紹介しきれなかった、Portalsを利用するにあたってのデザイン方法や、Portalsの詳細な技術仕様と実装方法について、ヤフー株式会社のデザイナーとエンジニアからお話させていただきます。

プログラム内容

  • Portalsの概要
    • ページ体験速度早い方がいい
    • a・iframe要素の両方の性質をもっている。指定のページへの遷移と要素の取得
  • portalのコツ
    • ページの繋がりをシームレスに使えるということを意識して利用する
    • facebookの動画再生のように、再生中の動画を維持したまま関連ページの遷移を実現できる
  • リッチなUXに引きずられず、非対応環境でもちゃんと使えているか確認すること
  • 状態としては、以下のようになっていてテストは大変そう。(他にもあったので後で資料を確認する
    • page A(商品一覧)とB(商品詳細)を作成
    • 利用可能なブラウザならportalを埋め込む
    • pageBを開いて、animationで拡大させて、簡易ページBを表示させる
    • activateでpageBのURLに変更する
    • ×ボタンを押すと、アニメーションが小さくなる
    • activateでページAに戻る
  • インプレッションの計測に注意。portalを読み込んだ時点でカウントされる場合がある
  • CVRにもつながってきそうな感覚がある

所感

  • 画面遷移が発生しているけれど、portalを利用することで簡易ページを間に挟んでシームレスな体験を作っている。portalを利用していない場合と比べてみると気持ちよさの違いが良くわかる
  • 要件定義時は、非対応のブラウザに注意を払う
  • テストをする際に実装について理解しておくことは有用

【DevSumi2020】「ともにつくる」を実践するドメイン駆動設計

event.shoeisha.jp

ドメイン駆動設計はソフトウェアの利用者を含む関係者すべてが一丸となって開発するためのプラクティスで、まさに「ともにつくる」を実践する手法です。 このセッションでは、今再びソフトウェア開発の現場で盛り上がりを見せているドメイン駆動設計をキャッチアップできるようお話します。

セッションの内容は次を予定しています。

さぁ、ドメイン駆動設計を手に取って、「ともにつくる」を実践しましょう!

参考 : ボトムアップドメイン駆動設計

プログラム内容

  • ドメイン駆動設計とは
    • 対象のユーザの世界をに注目する
    • ドメインモデル ⇔ コードがむずびついている状態
    • モデルとパターンの二つの要素がある
  • 手法
    • モデリング:ソフトウェアの目的によって切り出すfeatureは異なる
    • パターンモデル:コードに落とし込む時のやり方をまとめたもの
  • ドメインを知るためには、その業界で従事するdomainexpertに聴く
    • 要件定義の会話で、ドメインの言葉の不足を補っていく
    • ドメインモデルを作る際は、実業務の言葉(実装ではない)でやり取りする
  • ユビキタス言語:開発者とclientが主体となって纏める言葉
    • 単語帳ではない.ドメイン固有な言葉を使うわけではない
    • ※エキスパートもドメインモデルの用語・単語の定義が曖昧な場合もある
    • 知識の捉え方を変えたもの
  • 境界付けられたコンテキスト
    • アクター(発注者・受注者)によって分割する例があげられた
      • 分けない場合注文にまつわるゴットクラス(ごちゃまぜ・責務まとまりすぎ)になる
    • ドメインマップとして纏めており、注文時に発注・受注両方にあることを気づける
  • パターン
    • ※書籍見てくださいとのこと
  • ドメインをはじめから把握することは難しい
    • そのドメイン固有のノウハウがあるため
    • ドメイン固有の言葉について理解を深めることで、domainexpertと距離が近づき、より深いドメインモデルに到達できる
  • ドメイン駆動設計をするには、ステークホルダーやdomainexpertに教え共想する必要がある
  • ドメイン駆動あるある
    • 実装時にドメインの曖昧なことに気づける。 ⇒ 実ドメインドメインモデル・オブジェクトを反復(開発)する
    • スタートするならパターンからにするとやりやすい

所感

そのドメインのノウハウなども含めてコードに落とし込む場合には、反復開発的に理解を深めていくやり方が適していそう。

モデリングした際に切り出すフィーチャ―何にするかというのはテスト観点の親を何にするか問題に通じている気がしていて、この辺りはまだふわふわしている手の動かしたい領域だなあ

ぼんやりと把握していたドメイン駆動開発について、開発プロセスの構造の言語化や、ドメイン駆動開発をする際にclientやチームメンバーに対してどう働きかけるかといった点について理解が深まるいいきっかけになった。