ねえぶ

猫好きエンジニアのブログ

「エンジニアの知的生産術」を読んだメモ

西尾 泰和著「エンジニアの知的生産術」を読んだメモです.

全体

  • 経験のあるKJ法や,好きな外山滋比古氏の理論がよく引き合いに出されていて,全体的に理解しやすかった
  • 第6章「アイデアを思い付くには」が自分にとっては一番理解が難しかったが,フレームワーク依存問題など陥りやすい罠や持つべきマインドが解説されていたのが良かった
  • 著者の理論モデルが多くの過去のモデルから成り立ってきたのが読んでいてよくわかり,出典が逐次提示されているので,理論のトレースがしやすい本だと感じた
  • 折に触れて読みたい本だった

第1章 新しいことを学ぶには

  • 学びのサイクルは情報収集,モデル化,検証
  • インプットしたもののまとめや他者への説明などのアウトプットは検証の有効手段
  • 自身のインプットのやり方に欠陥があることを思い知った
    • 他人が確立したモデルをそのまま自身に取り入れようとして,理解した気になってうまく活用できていなかった(p43 パターン本から学ぶ)
    • 読むのが遅く,遅すぎて全体像が掴めない悩みがあったが,全部を読もうとするのではなくつまみ食いをすることが大事
    • そのために目標を明確し,全体像を把握する
    • 時間は貴重なのだから,遅延評価的勉強法を考慮したインプットを心がけたい
  • やる気を維持するために「ゴールを明確にする・近くする」は普段よく考えていて共感できた
  • やる気に関する問題は,最近読み直した「モチベーション2.0」の自律性・卓越・目標の3点に共通していると感じた

第2章 やる気を出すには

  • 7つの習慣の「重要事項を優先する」における緊急・重要マトリクスおける「重要かつ緊急」を減らし,「緊急ではないが重要」を増やす(緊急性分解理論)
  • GTDでは,価値観はボトムアップ言語化する
  • 優先順位付けは比較軸や不確定性から比較が難しく,日々の具体的なタスクを観察(計測)しながら事後的にできるようになる
  • ポモドーロテクニックはタイムボックスで終わりを設定することでやる気を持続させるが,スクラム等の手法も同様に感じた
  • 通知や割り込みを緊急性の高さと勘違いしてしまうのは陥りやすい罠なので,マインドセットや仕組み化が大事に感じた
  • 7つの習慣の「終わりを描く事から始める」はとても共感しており,仕事において必ず意識するようにしているので,本書でも取り扱っていて良かった(終了条件や目的を置かずに仕事をする人のなんと多いことか!)

第3章 記憶を鍛えるには

  • 反復的にアウトプットするのが長期記憶化のコツ
  • 認知的に高度な作業をした方が記憶にとどまる
  • 不適切な難易度によるモチベーションの低下は経験が多々あり,Ankiの自動保留の仕組みはよいアプローチに感じた

第4章 効率的に読むには

  • 開いている本・閉じている本(筆者の結論の有無),登山型の本・ハイキング型の本(概念の積み上げの有無)という捉え方は初めてだったので新鮮だった
  • 準備の大事さ,段階的詳細化,繰り返し読むこと,のコンセプトは今後の読書で意識していきたい
  • 遅読家で,理解が悪いことと認識しながら読書法の改善を図っていなかった
    • おそらく1度通して読んでおわりと考えているから,読み漏らすのが怖くて時間をかけ過ぎて読んでしまっているのだと思う
  • そこで次回の読書からやりたいこと
    • アウトプットを前提として読むこと
    • 1ページ目から通して読まないこと
  • 具体的な方法(仮)
    • 目次と導入から読むところを絞りつまみ食いする
    • 章ごとに感じたことや意見や疑問をまとめる
    • 目次に戻り全体マップでの位置を把握する
    • 以下ループ

第5章 考えをまとめるには

  • KJ法のA型図解化/B型文書化のステップは知らなかったので実践してみたい
  • 新しい構造を生むために,分類を先に決めてトップダウンする(KJ法をやる意味がなくなる)のではなく,ボトムアップで分類する
  • 手法のチューニングは確かに大事だが,いきなりチューニングするのではなく,まずは守破離の守のステップとして原則に倣うのが良さそうに感じた

第6章 アイデアを思い付くには

  • U理論の谷を下りるために,他人の視点を大事にすることや,SECIモデルを意識することや,フレームワークにしがみつかないことが肝要(自分の枠を壊す必要がある.KJ法において分類を先に付けないことと似ている)
  • 他人の視点を理解するために,クリーンな質問(Clean Language)や絵に描くことやNM法などで,抽象概念やメタファから身体的感覚の(具体的な)イメージに解凍する
  • なかなか理解が難しい章だった
  • イデアが生まれるのは管理できるものではないという考えは外山滋比古氏から学んでいて違和感がなかったが,アイデアを検証するという考えは自分にとって斬新だった(普段業務で触れているリーンスタートアップの考えなのに,個人のアイデア発想にそれを適用する考えを持っていなかった)

第7章 何を学ぶかを決めるには

  • 数学と科学では,正しいということの捉え方が異なり,個人の意思決定はそれらとも異なる
  • Steve JobsのConnecting Dotsは事後的にしかわからないので,戦略をベースに学ぶしかない
  • かけ合わせ(ふたこぶの知識)や連続スペシャリストによる差別化戦略はよく意識していて,意図的に学ぶものを選択することがあったのでとても共感できた
  • いままで社内でひとつの部署に留まらず色々な部署を転々としてきていて,そのことにデメリットを感じていたが,戦略として有効に考えるきっかけになった(人や組織,コミュニティを横断する知識・役割を基盤に成長する)

「これからのマーケティングに役立つサービス・デザイン入門」を読んだメモ

「これからのマーケティングに役立つサービス・デザイン入門」を読んだメモです.

これからのマーケティングに役立つ、サービス・デザイン入門 -商品開発・サービスに革新を巻き起こす、顧客目線のビジネス戦略

これからのマーケティングに役立つ、サービス・デザイン入門 -商品開発・サービスに革新を巻き起こす、顧客目線のビジネス戦略

  • 作者: J.Margus Klaar,長谷川敦士,郷司陽子
  • 出版社/メーカー: ビー・エヌ・エヌ新社
  • 発売日: 2015/10/22
  • メディア: 単行本(ソフトカバー)
  • この商品を含むブログを見る

読む前に設定した「知りたいこと」

  • サービスデザインとはなにか,を言語化できるようになる
  • カスタマージャーニーの概念と具体的手法を知る

全体

  • サービスデザインにおける思考や精神が身につく本で,手法やフレームワークの具体的手法の解説は少ない
  • 「解説:日本のサービスデザインの現場」の章で述べられていたが,カスタマージャーニー(に限らず,あらゆるフレームワークや方法論)を使えば問題が解決すると誤解されている例が多いが,なぜそれをするのか(Why)の理論と精神を身に着けないと効果はないと感じた
  • その意味でも,具体的手法を実践する前に読むと良い本だった

序章

なぜ(why)?

  • ほとんどのことが決めつけや仮説のままシステム化されてしまっている(お役所仕事)
  • 「なぜ」(それが必要なのか,その方法なのか,使いづらいのか)を考えることが必要

サービス・デザインとは何か

  • ビジネスを顧客目線で体系的に編成する取り組み
  • UX(顧客付加価値)を提供することを目的とする
  • 購入時点のみならず製品・サービスのライフサイクル全体をデザインする
  • 情報を常に正しく提示しないと満足度は下がる
  • Whatが衛生要因になったいま,Howが価値を生む
  • ここではHowを思考せよとあったが,もっというとStart With Whyが重要なのだろうと感じた

なぜこのプロセスをデザインと呼ぶのか?

  • デザインとは価値観やアイデアに形を与えること(無形→有形)
  • 理解しやすく,使いやすく,識別しやすく,美しくあることが良いデザイン
  • 問題定義のためにカスタマージャーニーマップ,仮説検証,タッチポイントを考える

カスタマー・ジャーニー

要求は決して「もの」ではない

  • 顧客の目線で世界を見る
  • リアルで意味のある世界にするために対象グループ,ペルソナを規定する
  • 購入のタイミングだけでなく,前後・背景を含めライフサイクル全体を考える
  • ペルソナから見る世界をモデル化するためにカスタマージャーニーマップ,共感マップを利用する
  • 顧客の大半は苦情を訴える行動を取らない(立ち去る方がコストが安い)ので,苦情の発生はその背後に潜在的な苦情が10倍程度あると認識する
  • 疑問:ペルソナは考えようと思えば無数に考えられる.必要なペルソナを設定・選定する指針は?
    • 同僚のデザイナの人に教えてもらった
    • 例えば
      • 対象のサービスの特性から考えられるユーザグループを,相反するユーザ特性を考慮して軸で分ける
      • 例えば,2軸でユーザグループを分け,各象限ごとに代表的なペルソナを作る
    • 単に設定したペルソナだけではなく,上記ユーザグループの全体像があると,ペルソナの妥当性(そのペルソナが対象ユーザに当てはまること,例外的でないこと)を他者へ説明する際も,論拠がしっかりする

仮説の検証

  • 量的データ・ビッグデータには過去の購入した情報だけしかなく,背景・カスタマージャーニー・Whyが含まれていないので,トレンドを把握するには役立つが,思考や感情を洞察するには役立たない
  • インタビュー,グループディスカッション,ワークショップを正しく行い洞察を得るためには,注意深い設計とファシリテーションが必要(対話法,観察法の習得が必要)

顧客接点(タッチポイント)

  • 事業体が提供する価値と顧客が受け取る価値が食い違っていないかに注意する(機能や性能がすでに衛生要因になっていないか,など)
  • テクノロジの進化と現実世界の課題・変化により,顧客は不満を表明し公にする強い力を得た
  • カスタマージャーニーの中で,顧客が受け取る価値が最も高い顧客接点を考察し,その場面のUXを高める

この種の課題への組織的な取り組み

  • 責任者の不在,組織のサイロ化は耳の痛い話で,サービスや製品の改革以前に組織改革が重要という主張は素直に同意できた

「IMPACT MAPPING」を読んだメモ

ゴイコ・アジッチ著「IMPACT MAPPING」を読んだメモです.

ここでは,デリバリ=成果物,デリバリチーム=開発チームと読み替えています.

IMPACT MAPPING インパクトのあるソフトウェアを作る

IMPACT MAPPING インパクトのあるソフトウェアを作る

インパクトマップとはなにか

  • ゴールを中心に,スコープと仮説を視覚化したツリーマップ
  • Why(ゴール)を中心に,Who(アクタ)/How(インパクト)/What(成果物・機能)を枝葉が広がるようにデザインする
  • 誰(Who)が何をもって(What),どんなインパクト(プラスもマイナスも)(How)をゴール(Why)に与えるかを表現する
  • GitHubで公開されているワークショップ用のチャートシートが良いリファレンス

impactmapping.orgより

インパクトマップの役割と効果

ゴールと仮設の明確化

  • ビジネスゴールと機能・スコープ・ロードマップを紐付ける
  • アジャイル開発が「予算がなくなるまで間違いを直し続ける」ことにならぬよう,仮説(成果物とインパクトの検証,インパクトとゴールの検証)の認識を共有できる
  • 開発チームには良いロードマップを,ビジネススポンサには全体像を与える
  • 検証する仮説の選択と優先度設定が的確にできる
  • 不完全なアジャイルが及ぼす悪影響を改善する
    • ビジネスと開発が分断された"ウォーター・スクラム・フォール"
    • これはBIG PICTUREの不在が原因

多くのチームはすばやい変更を優先するあまりBIG PICTUREを犠牲にして、プロジェクトを導いている。これはまるで暗いトンネルの中で、どこに向かっているかはわからないまま、落ちないように一歩一歩小さく進んでいるようだ。

無駄を排除し価値を速く生む

  • ストーリカード地獄(プロジェクトの開始時点で,成果物に必要な膨大な数のユーザストーリを作成してしまうこと)防ぎ,現状に適切な量・表現のユーザストーリを導出できる
  • インパクトマップのWho/How/Whatがそのままユーザストーリになるので,ユーザストーリの必要性がインパクトマップから判断できる
  • リーンのWIPを最小化する原則を実現する

導入しやすい

  • 記法が単純で,ステークホルダ全員が理解しやすく書きやすい

副次的効果(インパクトマップを書くだけではなくて,マインドセットも必要だと思う)

  • 効果的な会議
    • ビジュアル化による理解力・思考力・創造力の向上
    • インセプションデッキのような,立ち位置や目指す先の共有による議論の軸の確立
  • コストから投資への議論
    • 成果物のコストではなく,それがもたらす成果や利益への焦点の移動

インパクトマップのつくりかたのコツ

  • 「顧客に満足感を与える」ことだけを測るメトリクスは無価値なので,「行動につながる」メトリクスに焦点を当てること
  • 打ち合わせは2部制がよい
    • ビジネスゴールとメトリクスを設定する会
    • インパクトマップを作成する会
  • ビジネスマネージャは機能ではなくビジネスゴールを語るべし
    • 機能要求から始まった場合は,なぜなぜを繰り返しゴールを問う
  • ビジネスゴールは計測可能にする
    • SMARTを満たすこと
    • Measure
      • scale: 測定するものはなにか
      • meter: どう計測するか
      • benchmark: 現状はどうか
      • constraint: 許容値,損益分岐点
      • target: 求められる価値
  • メトリクスは追跡しやすさではなく価値あるものを選ぶ
  • メトリクスを測定し,継続やピボットの判断を行うタイミングを定期的に作る
  • 複数の測定値を持つものはマイルストーンを分けて考えてみる

所感

  • かなりコンパクトにまとまっていて(100ページ未満)で短時間で読めるため,本の全体感を認識しながら読み切れた
  • それぞれの項目ごとにポイントが記述されているので,実際にインパクマッピングをする際にリファレンスとして活用しやすい
  • 考え方はゴール志向要求分析や匠Methodに通じる部分が多いなと感じた
    • ビジネスと開発の分断を防ぐ方法論
    • What/Howだけだと失敗する
    • Start from Why
      • サイモン・シネックのゴールデンサークルに則っている考え方
    • システム開発だけアジャイルでも,ゴールやステークホルダと結びつかないので,ビジネスを含めアジャイルであるようにするための方法論
  • アジャイルであっても,知識体系のどの領域をカバーする議論なのかを意識することが有用に感じたのでPMBOKとかちゃんと勉強しようと思った
    • たとえばインパクトマップのWhy/WhoはPMBOKの計画プロセスにおけるプロジェクト憲章・ステークホルダ管理の概念
  • 「成果物の目的は,アクターの行動変化だということへの合意」という部分が,先日のYahoo! JAPAN Tech Conference 2019でCTO藤門さんが言っていた「ユーザの行動を変える」に通じるものを感じた
  • 本の最後の方にある「典型的な会議づくりに関する誤り」「典型的なファシリテーションの誤り」はインパクトマップ関係なく,仕事をする上でとても重要で参考になった

DevLOVE 価値観ババ抜き大体験会 に参加しました

ちょっと前ですが,1/21(月)にDevLOVE主催の価値観ババ抜き大体験会に参加してきました. イベントのページはこちら

価値観ババ抜きとは

こちらの公式ページの説明が詳しいです. 価値を表す単語が書かれたカードをババ抜き風に回したり捨てたり(+新たに取ったり)し,自分や他人の価値観を認識できるワークです. カードには「楽しさ」「コントロール」「成長」「チームワーク」などが書かれています. 一通りカードのやり取りが終わったあとで,手元に残ったカードを体系化したり,そこから考えられる価値観についての記述を行います.

進め方

当日のイベントは次のような感じで進められました.

  • 新井さん(@araratakeshi)からDevLOVEの説明
  • 山田さんから価値観についての話
    • 強み=得意なこと=他人に聞けばわかる
    • 興味・関心=好きなこと=自分に問いかければわかる
    • 価値観=大切なこと=こういったワークで認識する
    • マザーテレサの戒めでいう「思考」は価値観が左右する
  • 加藤さん(@acnaman_devファシリテーションで価値観ババ抜きの実施
  • 蜂須賀さん(@PassionateHachi)によるふりかえり
  • 新井さんによるクロージング

価値観ババ抜きワークの様子

  • カードを切るのにすごい迷ってしまって,我々のテーブルが一番最後まで時間がかかった
  • カードを切る時に「私は○○を手放します」と宣言するのだけど,「宇宙」というカードがパワーワード過ぎて,「私は宇宙を手放します」になっちゃうから爆笑だった
  • でも途中から「宇宙」という言葉に感じた感覚が,意外に自分の中でフィットしてきて,結局最後まで残った
  • ババ抜きが終わったあとの体系化と言語化の時間がちょっと少なかったので,もう少し時間を取ってしっかりまとめたかった
  • 最後に一緒にやったテーブルのメンバに,どのような人と感じたか,仕事でどのように一緒になりたいか,などをちょっとした手紙としてまとめるのだけど,これが実に恥ずかしい(^^;

↑2枚目の右下が自分の最後まで残ったカード

感じたこと

  • 価値観ババ抜き前に行った山田さんのアイスブレークが効果的で,ワークを一緒にやった人たちは全員はじめましてだったけど,スムーズにワークが実施できたのが良かった
    • お題に対して超高速で回答を回していったり
    • 全員立ち上がって部屋中に散らばって感覚の共有をしたり
  • きっとこのワークは,一緒にやる人によって結果が全く変わるなと感じた
    • 初めましての人とだと自己の内面との対峙という面が強いけど,すでに利害関係がある人たちとやると,嫌でも外から見た自分を意識すると思うので
  • チームビルディングなどを行う際に,キックオフミーティングや飲み会だけではなく,こういった互いの価値観を認識できるワークをするのがとても有用そうに感じた
  • まとめると,価値観ババ抜きワークとても良かった!

先月読んだ本と今月の読書予定(2019年2月)

f:id:ottijp:20190131230241p:plain

先月の読書実績

漫画,雑誌は除いています.

実績 Fav
数学ガール
新装版 リファクタリング―既存のコードを安全に改善する
エンジニアの知的生産術
Newton別冊『飛行機のテクノロジー』
IMPACT MAPPING インパクトのあるソフトウェアを作る

今月の読書予定

新規・継続
数学ガール
エンジニアの知的生産術
🆕 思考・論理・分析―「正しく考え、正しく分かること」の理論と実践

Yahoo! JAPAN Tech Conference 2019に参加しました

1/26(土)に開催されたYahoo! JAPAN Tech Conference 2019に参加してきたので,聞いたセッションについて簡単にメモします.

イベント概要

全体

  • 今回始めてYahoo! JAPAN Tech Conferenceに参加したが,普段聞けないYahooの取り組みや中の人の話が聞けてとても良いイベントだった
  • やはり大企業だけあって,社内の体制やプロセスが合理的でしっかりしていて,スタートアップ系企業の発表では味わえない"強さ"のようなものを感じた
  • 会場の場所がちょっとわかりにくかったけど,六本木駅から来くるとスタバの横の階段を降りて地下1Fに行き,しばらく真っ直ぐ歩くとミッドタウンホールの入り口があった
  • 予定があったので17時以降のセッションは聞けなかった😢

セッション

13:00-13:45 Keynote

藤門 千明さん(執行役員、CTO)

  • Yahooのねらいはインターネットでユーザがよりアクションすること
    • スライドの表現から,Search/Know/Buy/Payに特に主眼をおいているように感じた
    • キーノートの最後に流された動画でも,購入や支払いのイメージが強かった
  • Data/AIに関する取り組みはそれこそ10年前からやっているが,コンピューティングリソースが足りない点が弱点だったので,kukaiというスーパコンピュータを構築した
    • kukaiは水冷で,環境への配慮やエネルギー効率を考慮している
    • エネルギー効率(GFlops/watts)を上昇させるためのパフォーマンスチューニング自体をMLで行っている
  • kukaiの適用例
    • ヤフオクの不正出品の検出
    • 知恵袋のネガティブポストのレーティング
    • いづれも,モデルの作成が以前に比べ数百分の一くらいの時間でできるようになった
  • Yahooともなるとそのデータ量は膨大になる中,自社でAIへのアプローチを工夫しているのが印象的だった

仲原 英之さん(執行役員、CISO)

  • セキュリティへの取り組みの話
  • 2018の全サービスTLS1.2移行
    • 事前調査で非TLS1.2の通信は3%だった(母数多いから数は多い)が,売上より安全を優先して全サービスTLS1.2に踏み切った
    • 事前の告知や移行サポートにより9月には1.3%までに減った
  • 今年はOpenSSL1.0.2がEOLになるので,OpenSSL1.1移行が大きな動きになる
  • OSSの安全な活用とCI/CDの重要性が学びだった
    • ビルドパイルプラインに脆弱性検出を入れてる
    • DevOpsからDevSecOpsへ
  • YahooのTLS1.2完全移行は話題になったけど,他の企業からすると,「Yahooがやってるんだからうちもいいよね」と言いやすく,すごい助かった印象(実際IEを切る口実に使ったりした)
  • ユーザ数が多い中,決断は難しかっただろうけど,英断だったと思う

14:00-14:45 B-1

パスワードレス普及への取り組み by 三原 一樹さん

  • Yahoo IDの数は2018年9月時点で4,587万
  • これまではパスワードの安全性を高めるためにログイン履歴・ログインアラート・MFA・スマートログイン(ソフバンユーザ向け)などを対応してきた
  • 自アンケートによるとパスワード忘れ(96%),使い回し(73%)などパスワードがあること自体による問題が浮き彫りになった
  • そこでSMSを使った解決策を提供してきたが,これも十分とは言えなかった
  • そこでFIDOを使って,生体認証によるセキュリティとユーザビリティの両立を図っている
    • サーバは認証情報を保持しない
    • FIDO2でブラウザでも使えるようになる
    • FIDO認証採用はYahoo! JAPANが世界初
    • 現在はAndroidのみ
  • SMSはWhat you haveに近い認証だと思うので,パスワードよりユーザビリティは上がるが安全性は下がりそうな印象があったので,FIDOを使うのは良いなと感じた
  • TLS1.2の例と同様に,「Yahooがやってるから」と説得しやすい例を先行して確立してくれるのは,すごいありがたいと感じた

ヤフーのデータ戦略を支えるID連携 by 本間 洋光さん

  • Yahoo IDをベースにデータの提供,蓄積,活用するために同じIDでサービス利用してもらう工夫
    • ユーザにカスタマイズされたコンテンツ
    • ログインの簡便化(セッションの引き継ぎ)
    • ブラウザでのログイン情報をアプリに引き継ぐ
  • YahooID連携
    • OpenID Connectに準拠している
    • クロネコメンバーズの例
      • 再配達率15%を低減するためにYahooアプリで配送状況を確認しやすくするなどのシナジーを創出
      • プッシュ通知やY!カレンダーへの配送予定など
      • Yahoo IDをキーにクロネコメンバーズサービスからWebAPIへ配送状況を送信し,PulsarでYahoo各サービスへ配信している
  • 単に認証基盤を提供するだけではなく,他のサービスとシナジーを創出する取り組みをしている点が印象的だった

15:00-15:45 A-2

ライブクイズ「ワイキュー」を生み出した"内因的モチベーションドリブン" by 善積 正伍さん

  • 会社にとってのサービスの目的や理由が,チームメンバのモチベーションの理由になるかというとそうでもないので,内因的動機づけの必要性にアプローチした話
  • 課題解決型のサービスは課題と解決策が紐ついて明文化しやすいし共感は得やすいが,新価値想像型のサービスは課題に相当するものは無い
    • リーンキャバスが描けないので,MLP(Minimum Lovable Product)で仮説検証した
  • 1st MLPはSlack Botのアンケート機能でMLPを作って,賞金をかけたイベントが盛り上がるのかどうかの検証をやった(開発ほぼゼロ)
    • 小さな成功体験が発生し,メンバの内因的モチベーションをドライブさせた
    • 「みんなでワイワイする」というUVPが生まれた
  • 2nd MLP
    • 1st MLPのモーメントが実際のUIでできるか検証した→成功
    • 技術的なパフォーマンス実現に難しさ(25億PVレベル)があり,リリース見直しがあり,ライフチャートは低減した
  • 成功体験の因数分解によるモチベーションの維持もPMの仕事
    • やらなくてもわかること,やらないとわからないことは事前に分解してMLPを組み立てる
  • MLPは仮説検証でありチーム育成でもある
    • どうメンバのモチベーションが上がるかを含めて設計する
    • 大企業は多くの人が関わるからこそ,誰のモチベーションをくすぐるかまで設計する
    • 仮説検証 x MLP x チーム育成
  • リーンキャンバス描けない問題や検証のスパンが長かったり成功体験が無かったりすることによるモチベーションの低下は自分の組織でも経験があるので,非常に参考になったし同意できた

ワイキューが目指した"楽しい時間を作るデザイン" by 染矢 沙織さん

  • 「惰性的な日常にドキドキする瞬間を」→パーティをコンセプトに据えた
  • パーティ会場の擬似的な再現
  • UIは単純にYahooのガイドラインに単に従うのではなく,サービスの特性やコンセプトに準じて決めていった
  • スライドのデザインもちゃんとワイキューのデザインを適用しているっぽいくて流石感あった

16:00-16:20 B-3 ライブ動画配信サービス「ワイキュー」の作り方 〜優れた社内技術で実現する、少人数のサービス開発〜 by 石井 直矢さん

  • Yahooのトップページは昔はYUI(米Yahooのライブラリ)だったが,Reactに変更された
  • Yahoo社内に動画,コンピューティング,DB,NGワード等の各プラットフォームチームがあるので,サービスのコアバリューに集中でき,すばやく開発ができる(ワイキューのメンバは3人で,開発からリリースまで6ヶ月ほどだった)
  • 配信動画はHLS(HTTP Live Streaming)というフォーマットで,動画にメタ情報が付加でき,フロントエンドでメタデータを取り出して処理している
  • Yahoo全社として役割分担とフォーカスするべきものが確立されているので,それぞれが無駄なことをせずにモチベーションを保ちながらサービス開発できている感覚が垣間見れて良いなあと感じた

16:25-16:45 A-4 LEAN XPを活用したユーザーの声を聞くものづくり 〜Yahoo! JAPAN タブレットアプリのリニューアル〜 by 馬場 敬寛さん

  • リソース不足と技術のレガシー化の問題を抱えながら,LEAN XPを活用してゴールを達成していった話
  • LEAL XP
    • Pivotal Labsで学んだ
    • LEAN+UCD+XP
    • チームとしてはPM+Designer+Developer
  • 以下の3つのステップからなるデザインプロセスを実施した
    • STEP1: ターゲットユーザの理解(Generative Research)
    • STEP2: 課題の解決策の探索(Evaluative Research)
    • STEP3: 解決策をより使いやすくする方法の探索(Usability Research)
  • 自分の組織でもペルソナやシナリオをデザインすることはあるけど,それを検証してアップデートするというサイクルがうまく回っていないことがあるので,具体的なプロセスの説明をしてもらって参考になった

1人月は何ヶ月としてスケジュールすべきか?

システム開発の作業工数見積りにおいて,人月を単位として算出することがよくあると思います. それ自体の是非は別として,1人月の作業は期間としては何ヶ月でスケジュールすべきでしょうか?

前提

人月の神話によると,システムプログラム開発においては人と月は等価には交換不可能とあり,この基本的な考え方には私も同意しており,複数要員の場合にはまた違った話になるので,ここでは要員数は1人として考えます.

分担はできるが、サブタスク間でのコミュニケーションが必要な仕事においては、コミュニケーションにを図る労力を、こなすべき仕事量に追加しなければならない。

(人月の神話[新装版] フレデリック・P・ブルックス, Jr. p13)

また,ここでは1人月が20人日・160人時だった場合の1ヶ月を20日・160時間とします.

私の考え

私が過去に見てきたプロジェクトにおいては、当然のように1人月=1ヶ月としてスケジュールされることが多かったです. しかし,私はそれは間違っていると考えていて,基本的には(条件がなければ)1人月=1.25ヶ月としてスケジュールするようにしています.事実,1人月=1ヶ月としてスケジュールしているプロジェクトは,炎上するか遅延する例が多かったように思います(もちろんスケジュール計画以外の問題もあったろうと思いますが.)

この1.25ヶ月という数字は,組織やプロジェクトの諸条件や要員の雇用契約形態などによって妥当な値が異なると思います.

1人月=1ヶ月でない理由

1人月(1人が1ヶ月かかる工数)がなぜ1ヶ月というスケジュールに収まらないのかというと,そのプロジェクトに専属の要員であっても,間接作業や非可動時間が発生するからです.例えば,次のようなものが考えられます.

  • 所属組織内の業務(進捗会議,報告,目標管理など)
  • 教育と情報収集(研修,展示会など)
  • 法令関連業務(避難訓練など)
  • 雑務(整理整頓,掃除など)
  • 休暇
  • 祝日

考えみれば当たり前ですが,スケジュールを計画する際にこの考慮をせず,プロジェクトに専属なのだから100%の時間を当てられるだろうという間違いを犯してしまう例をよく目にします.

この点を無視すると,期間に当てられる作業量が,計画時点ですでに残業を織り込んだものになるため,進捗が遅延し,作業者の能率が悪くなり,品質に影響を与えることに繋がりやすくなります.

計算

先に述べたとおり,組織やプロジェクトの諸条件や要員の雇用契約形態などによって妥当な値は異なると思いますが,例としてこの間接作業と非稼働時間を考慮した計算をしてみます.

  • 進捗会議: 1時間/週(4時間/月)
  • 業務作業報告: 1時間/週(4時間/月)
  • 研修・e-learning: 2時間/月
  • 展示会参加: 4時間/月
  • 雑務: 30分/週(2時間/月)
  • 休暇: 1日/月(8時間/月)
  • 祝日: 1日/月(8時間/月)

上記のような場合,32時間/月(20%)が非稼働時間になります. つまりプロジェクトに当てられるのは1ヶ月=0.8人月であり,かかる期間は1人月=1.25ヶ月です.

一般的には間接作業は分けて工数実績を付けていると思うので,自身の組織でどれくらい間接作業に時間が使われているか調べてみると,実情がわかり妥当な計画が立てられるかもしれませんね.