最速で価値を提供する

最速で価値を提供する 藤澤正通 株式会社ネクスト HOMEʻ‘S事業本部 2017/03/18

⾃自⼰己紹介 名前:  藤澤 正通(@masamichi) 所属:  株式会社ネクスト 不不動産情報ポータルサイトHOMEʻ‘Sを運営

⾃自⼰己紹介 やってきたこと • テスト • テスト⾃自動化 • ⾃自動テスト基盤環境構築 • テストコード作成 • プロセス改善やツール導⼊入 • セキュリテイ、CSIRT⽴立立上げ⽀支援 • 新規事業⽴立立ち上げ⽀支援 社外活動: • ソフトウェアテストシンポジウム JaSST東京 実⾏行行委員

今⽇日お話したいこと • 品質について • 品質を考える時の観点 • Webサービスに求める品質 • 品質改善のカタ • 品質の仕様化 • 実装 • モニタリングと改善 • 最速で価値を提供する • Value  Stream  Map

品質について

品質を考える時の観点 • 狩野モデル • ビジネスフェーズ • サービスとしての品質

狩野モデル Satisfied Excitement 魅⼒力力的品質 無くても不不満には思 Performance わないが、充⾜足され れば満⾜足 Fullfilled Not fullfilled Basic 性能品質 不不充⾜足だと不不満、充 ⾜足されると満⾜足 当たり前品質 充⾜足されないと不不満、 充⾜足されて当たり前 Dissatisfied

ビジネスフェーズ毎に必要な品質 サービスの成⻑⾧長段階によって求められる品質は 異異なる Early Majority Late Majority Laggards Users Early Innovators Adopters 魅⼒力力的品質 性能品質 当たり前品質 魅⼒力力的品質 性能品質 当たり前品質 魅⼒力力的品質 Service Life Cycle 性能品質 当たり前品質

サービスの特性 • 無形性 • ⾮非分離離性 • 変動性 • 消滅性

サービスの特性 無形性 サービスは購⼊入する前に⾒見見たり、触れたり、 味わったりすることができない無形のものである ⾮非分離離性 ⽣生産と消費が同時に発⽣生し、提供者と不不可分のもの である(サーバーが稼働し続ける必要がある)

サービスの特性 変動性 提供者や時間、場所によってサービスの質が変化する 消滅性 在庫することができない (作り貯められない / ユーザーは所有しない) • つまりプロダクトリリースは完成ではなく、 ユーザー満⾜足度度を考えたサービス運⽤用や 継続的な改善が必要になる

サービスの品質 4つの評価軸 • 有⽤用性 • 可⽤用性(信頼性) • ユーザビリティ • セキュリティ

サービスの品質 有⽤用性 ユーザーまたは顧客の「成果を挙げられるか」また は「制約を取り除くことができるか」 可⽤用性(信頼性) 使いたいときに、ストレスなく利利⽤用できるかどうか

サービスの品質 ユーザビリティ 簡単に使えて、楽しい、嬉しい驚きがあるか セキュリティ 安全は守られているか

Webサービスの品質 • Webサービスは品質の考えかたが他の業種と 異異なる • 例例えば組み込み製品だと • ユーザーはプロダクトを買う • 所有することに価値が⾒見見出される • 問題が起こると⼤大きな問題になる • 発熱、誤動作、事故＞リコール • ⼀一度度出荷してしまえば、後から⽋欠陥を修正することが ほとんど不不可能 • 出荷前の品質保証活動がとても重要

Webサービスの品質 Webサービス • ユーザーはサービスを利利⽤用することに価値を⾒見見出す • リリース後に⽋欠陥を修正することが可能 • とはいえ有⽤用性が毀損されることが許容されるわけではない (ここ⼤大事) • まずリリースしてみて、 ユーザーの反応を⾒見見ながら改善することが重視される つまりプロダクトリリースは完成ではなく、 ユーザー満⾜足度度を考えたサービス運⽤用や 継続的な改善が必要になる(⼤大事なことなので2回⽬目)

品質改善のカタ

品質改善のカタ 1. 品質の仕様化 2. 実装 3. モニタリングと改善

品質の仕様化 • ざっくりいうとプロダクトに どんな品質を求めるのかを⾔言語化したもの • 例例えばISO/IEC25010  

ISO/IEC25010

品質仕様の例例 たとえば「⼀一眼レフカメラ」なら • 画素数 • 重さ • ⼤大きさ • ボディのデザイン

品質仕様の例例 Webサービスなら？ • レスポンスタイム○ms • 平均故障間隔○○⽇日 • セキュリティ脆弱性ゼロ • 使いやすさユーザー評価No.1 これらは組織・プロダクトのビジョンや 顧客の要求にもとづいて決める

品質の仕様化 Q.  なぜ品質を仕様化する必要があるのか？

品質の仕様化 Q.  なぜ品質を仕様化する必要があるのか？ A.  ⾔言語化されない品質は作られないから

実装 品質を⾼高める技術を活⽤用して品質を作り込む ⽋欠 陥 数 ⽋欠陥検出型 予防型 要件定義 設計 実装 テスト 開発フェーズ

実装 品質を⾼高める技術の例例 • 各種設計技法 • テスト • プロジェクト管理理 • ⾃自動化 • ナレッジ管理理 • 可視化・モニタリング • 構成管理理 • レビュー • TDD • コード解析 • インシデントレスポンス • 障害分析 • ふりかえり • チェックリスト

モニタリングと改善 求められる品質の充⾜足状況を定量量化・可視化して 改善する

モニタリングと改善 Webサービスなら？ • レスポンスタイム、安定性 ・・・ダッシュボード • セキュリティ ・・・脆弱性診断 • ユーザー評価No.1 ・・・ NPS(Net  Promoter  Score) 品質を指標に変換し、モニタリングする

ここまでのまとめ 1. ⾔言語化されない品質は作られない 2. 開発技術で品質を作り込む 3. 品質仕様を指標に変換し、モニタリグする

最速で価値を提供する

最速で価値を提供する • 実は弊社の⾏行行動指針の１つ • 価値とは例例えば、 • 魅⼒力力的品質(デザインが良良い、⾰革新的) • 性能品質(電池がへらない) • あるいは • 有⽤用性(めっちゃべんり） • 使⽤用性(使いやすい、速い) • 安全性(⼤大事な情報あずけて⼤大丈夫かな) • 「品質とは誰かにとっての価値である」(Weinberg,1994)

最速で価値を提供する ⾼高い価値を届けるためには時間がかかっても 仕⽅方ない？ • そうではない • トレードオフではなく「ANDの発想」を持ちたい • ⼤大事なことを⼀一つだけ選ぶのではなく、 どうやったら両⽴立立できるのかを考える

価値を素早く届けるために アイ ディア 学習 構築 データ コード 計測

価値を素早く届けるために ループにかかる リードタイムを短くする • ムダな⼯工程は無くす • 必要な⼯工程は減らさない アイ ディア 学習 構築 データ コード • できるだけ⾃自動化する 計測

価値を素早く届けるために バリューストリームマップ 原材料料が加⼯工されて顧客の⼿手に渡るまでの全⼯工 程の経路路と、各⼯工程がどこからの指⽰示で実施さ れるのかを⽰示したもの

価値を素早く届けるために [引⽤用]https://en.wikipedia.org/wiki/Value_stream_mapping

バリューストリームマップ • リードタイムは処理理時間と待ち時間で構成される • 処理理時間：実際に作業される時間➔やり⽅方を変えて短縮でき ないか • 待ち時間：作業の開始待ち時間➔ムダなのでなくせないか • 常に繰り返される⼯工程があれば、定型化、⾃自動化、可視化す る

各⼯工程や流流れ無理理・ムダを取り除く ⼯工程 (例例) 無理理・ムダ 対策 プロジェクト 計画 • 次に何をすれば良良いか分から ず情報を探す • Wikiに書く • 開発の流流れと問合せ 窓⼝口をまとめる 外部調達 • コミュニケーションもれる • 提案書の内容がばらつく • 期待している成果物が作られ ない • RFP • 要件定義フェーズと 実装フェーズの分割 テスト • 単体レベルのバグをE2Eで探す • テスト⾃自動化 • 回帰的なテストを⼿手動で実⾏行行 • CI構築 する デプロイ • リリースを⼿手作業で⾏行行なう • 作業待ちがある • CD構築

本⽇日のまとめ 1. 品質を分類してプロダクトやビジネスフェー ズにあった品質を作りましょう 2. 品質の⾔言語化⼤大事 3. 品質とスピードの両⽴立立を⽬目指したい

エンジニア募集中！