毎日がもふもふ

新規事業に特化した渋谷の開発会社mofmof inc.を経営するエンジニア兼代表・原田敦のブログ

SHIROBAKOに学ぶ「なぜステークホルダーを巻き込むべきなのか?」

f:id:redhornet96:20151206155404j:plain

SHIROBAKO公式サイトより引用 http://shirobako-anime.com/

変な話、はやいものでもう2015年ももう最後の月となりましたね。12月といえばアレですよねアレ。みんな大好きAdvent Calendar。

今年は2つほど乗っかってしまいましたが、今回はこにふぁーさん率いるSHIROBAKO Advent Calendar12/8担当ということで、書かせていただきます。

http://www.adventar.org/calendars/729

SHIROBAKOとは

知らない人もいるかも知れないので、SHIROBAKOについてちょっと説明した方がいいのかな?

簡単に言っちゃうと、アニメ制作会社で制作進行をしている新人女性を主人公としたアニメなんですが、いきなり新人PMがプロジェクトマネジメントやってるみたいな話で、みなさんのようなIT戦士あるある的つらみが表現されてる作品です。その辺が他人事と思えず感情移入してしまうところが人気の理由なんでしょうかね。

SHIROBAKO公式サイト shirobako-anime.com

こにふぁーさんのスライド sssslide.com

ちなみにぼくは圧倒的に矢野さんオシです。背の小さいツインテールのニーハイキャラですよ。あとツンデレ成分が少しあれば完璧でしたね。

f:id:redhornet96:20151206155244p:plain SHIROBAKO公式サイトより引用 http://shirobako-anime.com/

23話 続・ちゃぶだい返しのあらすじ

さて今回は、「#23 続・ちゃぶだい返し」の回について語ります。

http://shirobako-anime.com/story/23.html

簡単なあらすじですが、「第三飛行少女隊」というアニメ制作も最終話を制作も出来上がり、担当編集部にもOKもらっていつになく順調。なんとか問題なく行けそうだと一安心した矢先、編集部から一本の電話が。「野亀先生(原作者)怒ってる!?最終話、絵コンテ全ボツ!?」

えー!そんなこと言われてももう間に合わないよ!先に進めてOKって確認にしたじゃん!どうするのどうするの!っていうところから23話が展開していくっていう話です。

ステークホルダーを巻き込むことで生産性を上げる

f:id:redhornet96:20151206155736j:plain

その後は、アニメ制作監督が直接原作者にコンタクトを取り、原作者の意図や想いを汲み取り、原作者も導けなかった最終話のストーリーが沸き起こり、両者がわかりあい納得の行くストーリーが出来上がるという風に展開していきます。

ぼくたちmofmof inc.という会社では、「開発チームレンタル」という形で月額制の受託開発をやっているのですが、プロジェクトに参画する上で各々の役割というものが存在します。

簡単に言ってしまうと、プロダクトオーナーはプロダクトのビジネス価値の実現とその手段の表現に責任を負い、デベロッパーはプロダクトオーナーが表現した「ビジネス価値と手段」を優先順に技術レイヤーに分解し、開発・リリースしエンドユーザーに届けることです。

ところが、プロジェクトは大きくなればなるほど、これらの役割以外のステークホルダー(利害関係者)が増えます。例えば、プロダクトオーナーがとある事業担当者だとすると、その事業部の事業部長という人物が存在していたりします。SHIROBAKOで言えば、野亀先生(原作者)が超絶大なステークホルダーになります。彼がNGといえば、誰がなんと言おうとNGになってしまうという。

SHIROBAKO#23の回では、野亀先生と直接話を出来るコミュニケーション設計がなされていなかったのですが、制作監督が直接原作者にコンタクトを取り、対話の場を確保したことで大きくプロジェクトが快方に向かうことになりました。

このことから、ステークホルダーを巻き込んだコミュニケーション設計は、生産性を大きく向上させることがわかります。「生産性」というは何も個人の作業効率だけの話じゃなくて、チーム単位でのアウトプット最大化のことにも言えるはず。がむしゃらに高速に大量に生産するよりも、コミュニケーション設計を適切なものに変えることで、無駄な生産活動を減らして、ビジネス価値の高いものの実現を優先出来るはず。それこそが本来の生産性の向上なんじゃないかと思ってます。

ものづくりを通して誰かをハッピーを実現することが、クリエイターの至上の幸せだと思ってます。そしてそれを最大化することがぼくたちmofmof inc.の役目。そのために出来ることは決して「作ること」だけではないはず。

SHIROBAKOみようね!

ちなみに実は23話は神回と言われるほどよい話なんですよ。ぼくの中では完全にクライマックス。各登場人物の想いが交錯し実を結ぶ話。この回だけ見ちゃうのは非常にもったいない。カニの身を食べずにカニ味噌だけ食べて捨てるくらいにもったいない。

変な話、最初から観るのを全力でオススメします。

2015/10/30 @クラウドワークスにて「アジャいらないひよこクラブ」イベントを開催しました。

アジャいらないひよこクラブ運営のレポート担当です(原田さんのアカウントで投稿)。 前回に引き続き、クラウドワークスさん、会場のご提供ありがとうございました。何度行ってもやっぱり素敵なオフィスです。

f:id:redhornet96:20151206165043j:plain

今回も、盛りだくさんの発表内容でした。 また、参加者の方もアジャイル歴0年の方から15年の方までいらっしゃったり、得意とする言語も様々。 それぞれのスキルや経歴は全く関係なく、「開発現場やチームをよくしたい」という思いが共通していることを除いては、本当に色んな方が来られているなぁという印象です。

では、早速中身に入りたいと思います。 今回のテーマは「ふりかえり」です。メインスピーカーは、 アジャイルサムライ横浜道場よりお越し頂きましたてらひでさんです。

f:id:redhornet96:20151206165111j:plain

てらひでさんについて

  • 某不動産屋で情シス70%、開発30%くらいの割合で働いてる
  • アジャイル歴7年
  • 得意な言語はjava
  • 深夜アニメのカバレッジ90%以上

ふりかえりについて

ふりかえりを行って、顕在化した問題に対して手を打っていくわけですが、 顕在化した問題がいっぱいあったらどうすればよいのか。 どれからやればよいのか?優先順位をつけようか・・・? どうしたらいいの!?(>_<)となっていしまいます。

確かに、ふりかえりをして問題が顕在化したのは良いが、ただ反省するだけで 改善のための身動きがとれない状態では意味がありませんね。 では、どうしたらいいのでしょうか?

そんな時、全ての問題の本質的な原因というのがあったら、 やることはこの原因をつぶすことと明確になります。 イスラエルの学者 エリヤフ・ゴールドラットの言葉に、 『本来、ものごとはシンプルである』という言葉があるそうです。

なるほど!素敵な言葉ですね。いや、しかしここでの登場は少しだけ唐突ではありませんか?と思ってしまいましたが、この原理・原則的な考え方は後々のふりかえり手法をご説明頂いた際にじわじわ効いてきます。

ワーク

では、みなさんここで一旦ふりかえりをやってみましょうということで・・・ お読み頂いている皆さんも是非やってみてください。

「背筋を伸ばして椅子に座ってください。  目を閉じて鼻から大きく呼吸してください。  いつもの2倍の速度でゆっくり呼吸を続けてください。  思い出してみてください。最近失敗しちゃったなぁと思う事柄は ないですか?   ーその時あなたは何をしましたか?   ーその行動の結果、どうなりましたか?  目を開けてください。」

これ、途中まで何かに似ていませんか?そう、ヨガのレッスンですね。 それはさておき、余計なことを考えずに頭の中を空っぽにして思い返せるので、いつもより落ち着いて考えられた気がします。

f:id:redhornet96:20151206165146j:plain

話を戻しますと・・・

このワークでは、実はロジックブランチの説明が既に始まっていたのです。

詳細はスライド p23〜27をご参照ください。

ロジックブランチ

 ロジックブランチとは、TOC理論の3つのツールのうちの1つで、  因果関係を表すためのツールです。

先ほどのワークの質問は下記のとおりでした。  最近失敗しちゃったなぁと思う事柄はないですか?  その時あなたはどういう行動をとりましたか?  その行動の結果、どういうことが起こりましたか?

ex.  - その時あなたは何をしましたか?・・・こちらをAとします     体調不良で会社を休みました

  • その行動の結果どうなりましたか?・・・こちらをBとします     次の日の朝上司に説教される

「もしAならBになると言われたら、原因と結果の因果関係が 成り立つでしょうか?」 ん〜・・・これはちょっと、成り立ちませんね。

「では、なぜ成り立たないのでしょうか?他に要因はありませんか?」  というてらひでさんからの問いかけに対して、参加者からは以下のような  回答がありました。

  • 夜中までゲームしてたりアニメ見てたのでは?   →てらひでさんに対するイメージより
  • 引き継ぎをしなかったのでは?

  • 他に要因はあったのか?・・・こちらをCとします     実際には同僚が全く同じ日に休んでいました

上記のA・B・Cを組み合わせると、下記のようになります。  「もし体調不良で会社を休んだら、次の日に上司に説教された。   なぜならば、同僚が同じ日に休んだから。」

[ポイント]   「もしAならBになる」では成り立たない。    しかし、「もしAならBになる。なぜならばCだから」というように、    AとCの2つが揃えばBの結果は成り立つ。    原因となるAとCのいずれか1つでも崩れると、結果は壊れる。

視点を変える

つづきまして、こんなことたまにあるかもって話が具体例です。 ざっくりいうと、電車に乗ったけど寝過ごして、歩いて帰る羽目になったお話です。 スライドp28〜をご参照ください。

www.slideshare.net

歩いて帰るという結果を導き出した原因は、上記スライドのとおり 多数あります。それらのうち、どれか1つでも壊れれば、歩いて 帰らなくて済むのです。

「みなさんならどこを壊しますか?」 というてらひでさんの問いかけに対し、参加者の方からは 「電車で椅子に座らずに立っている」といったような回答がありました。

大事なのはここです。他者の視点を借りて、自分で気づかないものを見つけることです。 自分で気づかないものを自分で気付こうとするのは難しいです。 これを簡単にサポートしてくれるのが多様化したチーム。

いや、多様化したチームに所属してないです・・・と思ってしまった方も 大丈夫です。

てらひでさんは、多様化したチームは見たことがないそうです。 また、現在1人で開発されているため、そもそもチームではないそうです。 それでも、自分で気づかないものを見つける方法はあります。 「視点を変える」ことだそうです。

視点なんて、そんな簡単に変えられないよと思われるかもしれませんが、 (思いました) 簡単です。100本ノックしましょう!とのこと。 これは、努力しろという意味ではないというのがポイントです。 例えば、「よかったところを100個あげてください」と言われて やってみると、どこかで手が止まる。「むり!!」という瞬間がきます。 そこが自分の限界です。自分の限界が見つかると、視点を変えようと努力するのだそうです。

まとめ

  • 100本ノックで要因を探す
    • よかったところ、課題、etc.
  • ブランチを書く
    • 注目する要因を決める
    • 因果関係(原因と結果の関係)がないかを確認する -「なぜならば」を探す
    • 「なぜならば」見つけられないなら100本ノック
  • ブランチを補強する
    • 「論理の飛躍」を埋める
    • 過去を掘り下げるときは上(結果)から下(原因)へ
    • 未来を予測したり仮説を立てるときは下(原因)から上(結果)へ

変わり方について

「変わらなきゃを変わらなきゃ」

変わってと言われたとき下記のようなことが頭に浮かぶのでは ないでしょうか?

  • 変わり方がわからない
  • そもそも俺は変わりたくない
  • 変わる必要に納得できない・・・ 困ってない、今までのやり方を変えるのは大変
  • 自分がやってきたこと、自分自身を否定されている気分になる
  • 変わっても結果が出なかった時に辛い思いをするのはいやだ

そこで、「アクションプランを考えよう」 最初の一歩は、明瞭・簡単であることが大事。

ex ダイエットする 「炭水化物を30%減らす」よりも、「夜ラーメンを食べない」の方が  わかりやすい。  でも、ラーメンが大好きなので夜ラーメンを食べないは難しい・・・  そこで、「平日の夜ラーメンは食べない」とする。  これならできそう!簡単!というわけです。

ex 自動テストを書く 「毎日自動テストを1件書く」よりも、「毎日まず5分テストを書く」  の方が簡単です。  しかし、実際には5分でテスト書けないから、書き終えるまで  やめたくないという心理が働いてテストを書ききれるのだとか・・・。

また、ブライトスポット(うまくいっているところ)を探し、 現状との違いを見つけます。

  • 自分のチームでうまくいっているところを探す
  • 他のうまくいっているチームと比較して自分のチームとの違いを見つける

課題の話をしていると暗くなっていくので、 うまくいっているところを探す方が前向きになりやすいのだとか。

すぐに始められることがたくさんありましたね。 仕事においても、私生活においても、早速始めてみたいと思います。

発表〜Influence Management

f:id:redhornet96:20151206165321j:plain

なんとシリコンバレーからお越し頂きました。スティーブ・マギーさんです。

スティーブさんは、マネジメントのお仕事をされています。 普段はなかなか聞けないような視点からのお話が聞けました。

リードタイムという言葉はよく耳にしますよね。 リードタイムとは、着手してから完了するまでにかかった時間のことです。 会社経営からすると、リードタイムはどれだけお金を使ったかというコストに ダイレクトにはねかえります。このリードタイムを、マネージャーに伝えるための2つのキーワードを教えて頂きました。「利益」・「コスト」です。

例えば、エンジニアをやっていると、よくアンプランドワーク (割り込みの仕事)を急にふられることがあります。 しかし、エンジニアはマネージャーに対し、それにどれだけリードタイムがかかるのかということを説明するのではなく、「リソースや時間が足りません・・・」と具体性がなく、ダイレクトにコストに跳ね返るといった印象が持てないような伝え方で、マネージャーに対して自身や自チームの状況を伝えがちなのではないでしょうか。

マネージャーに伝わるようにするためには、「利益」・「コスト」の2つを 使ってより具体的に伝える必要があります。

現場のエンジニアは、開発に一生懸命になっていてあまり全体にどれだけのコストがかかっているのかを意識していません。しかし一方で、どれだけのリードタイムがかかっているかは現場のエンジニアにしかわかりません。 マネージャーにリードタイムを伝えるためには、まずリードタイムを明らかに しなければなりません。方法は次のとおりです。 ワークアイテムをそれぞれ洗い出して、1番目、2番目とそれにどれだけリードタイムがかかっているかをチャートにしてみると一目瞭然です。

リードタイムを1つ1つ記録してマネージャーに見せることで、仕事を急にふられたことによって、どれだけコストに跳ね返っているのかということをマネージャーに伝えてみてはいかがでしょうか? 

LT1〜雲を掴むような話

f:id:redhornet96:20151206165336j:plain

http://www.dont-think-feel.com/archives/46659167.html

株式会社もくてき CTO 坂本さん 1年以上かけてクラウドソーシングを実験してきた経験より感じた クラウドソーシングのメリット、クラウドソーシングで仕事をする上で 重要なこと、気づきについてのお話。

LT2〜スクラム奮闘記

f:id:redhornet96:20151206165347j:plain

Yahoo株式会社 田地さん

チームメンバーの職種が多岐に渡っており、バラけていると感じていた チームをユーザーにものを届けるという1つの目標に向かって立ち向かう集団に変えたいと思い、スクラム開発をやってみてのTry&Errorのお話。

LT3〜良いふりかえりのために気をつけていること

f:id:redhornet96:20151206165401j:plain

 なぜふりかえりが大事なのか、気をつけていること、  よくある困った状態、それに対する対応についてのお話。

質問タイム

最近、以前に比べて質問タイムが短くなってしまっているという課題があり、 改善に向けて検討中ですが、今回もたくさんお悩み相談をして頂きました。 いくつか抜粋して記載しておきます。

f:id:redhornet96:20151206165412j:plain

質問: 「ふりかえりKPTをやっている方に質問です。ふりかえりをどういう頻度で何時間やっているか、 1回のふりかえりで何チケットでるか」

回答1:「2週間のスプリントで1時間ふりかえり、チケットは2、3枚」

回答2:「スクラムだと、2週間のスクラムだと2時間と定義されている。それを超えるのはよくない。決まった時間でどれくらいのふりかえりができるかが大事。」

回答3:「10名チームでKPTそれぞれ2、3枚チケット出る。(サマリして2、3枚ではなく、1人あたり2、3枚書いてる)」

質問: 「ふりかえりの手段としてKPTがでてるけど、他の手段はある?」

回答1:「KPTに飽きてきたとき、出てこなかったらイベントタイムラインを使う(アジャイルレトロスペクティブがオススメ)」

質問: 「チーム開発をしていると、スクラムマスターがいたりメンバーがいたりして、温度差が生まれる。メンバーの自主性を高めるような面白いワクワクしたものがある人いたら教えて!」

回答1:「《Fearless Change アジャイルに効く アイデアを組織に広めるための48パターン》に紹介されている。 ※ちなみにこの本は、LT3でお話し頂いた中込さんが翻訳者のお1人。      例えば       - 小さな成功(いきなり大きいことをするのではなく、小さいみんながよかったねと思えることをしてのってくるようにすること)      - アーリーアダプター (自分が新しいことやりたいと思った時に、自分だけではやりきれないので、誰か一緒にやってくれる人を探す。周りで共感してくれる人を探す。)」

以上

ご登壇頂いた皆様、ありがとうございました。

サービスやプロダクトを作るのは開発者じゃない

f:id:redhornet96:20151117111400j:plain

mofmof inc.エンジニア兼代表取締役の原田です。

最近とある語学留学にいって帰ってきた方とちょっとした雑談をしたんですが、受託開発の話で「あくまでも作るのは我々ではなくてあなた(クライアント)なんですよ」っていうようなことを話をした。

あーいい話だなーと思ったのでちょっと書き留めておきたく。

サービスやプロダクトを作るのは誰か?

mofmof inc.では月額制の受託開発をやっているのですが、ご相談いただいた際に、ご一緒に仕事して本当にうまくやれるかどうかを非常に気にします。

昔からソフトウェア受託開発の世界では、いわゆる「丸投げ」っていう発注の仕方をするケースがあって、極端な言い方をすると、ざっくり要件を伝えるから、あとは開発会社の方で行間読んで良きに計らってねっていう形です。

で、ぼくの経験上このケースは本当にうまくいかない。よくあるのが、設計段階で確認したときには「オッケーオッケーそんな感じでやっておいてー」みたいだったのが、開発終盤になって動くものが見えて来た段階になるに連れて「え、ここはこう動いてもらわないと困るよ」とか「思ってたの違う」みたいにごにょごにょしちゃって、結局あんまり使い勝手がよくないものが出来上がっちゃう。

そして、こうなるかならないかは「クライアントがどれだけ主体になって作ったかどうか」というポイントが分かれ道になってる。色んな方々と仕事させてもらってきたけど、ホントこれ。もちろん開発者サイドにも改善出来ることはたくさんあるんですけど、それは主旨がブレるので一旦棚上げで。

なぜクライアント自身が主体的であるほうがうまくいくのか?

ソフトウェアでビジネス価値を実現しようとしている場合、なんらかの課題があって、そのソリューションを作ろうとしていることが多いわけなんですが、良いソフトウェアを作るには、その課題をより近く感じていて、それを適切な言葉で表現出来る人がどうしても必要だと思ってます。

課題を浮き彫りにするのってそんなに簡単じゃないんですよ。コスト削減のために「経費申請システム」を作りたいって言われたとします。じゃあ作りましょうって、ただ単に作ったってコスト削減にはつながらないんです。

「なんで既存のサービスじゃダメなのか?」「Excel+Dropboxで十分なんじゃないのか?」「運用を改善すれば解決する課題なんじゃないのか?」というところは当然明らかにすべきだし、実際に既存の経費申請フローをくまなくチェックして、何がどう非効率で不満なのか、それを使う人の体験を十分に分析しなきゃならんのです。そんな泥臭いことをやらなきゃわからんのです。「最適なソリューションを提案します」とか軽々しく口に出来たもんじゃない。

ソフトウェアを作るなんて簡単なことですが、本当に価値あるソフトウェアを作るのはそれほど簡単じゃないです。だから本当はソフトウェアを作るより前と、作ったあとの継続的改善が勝負どころなんです。

で、それを最もやれる立場にいるのがクライアント自身ですよと。

クライアント自身がソフトウェアに責任を持つ作り方

上で言及している通り、ソフトウェアで価値を実現するには、多くの試行錯誤が必要になります。ただ作っただけのソフトウェアがたまたまうまく行くなんてことはめったにないです。にも関わらず、ソフトウェア開発には「完成」を求められる。

果たして「完成」とはなんだろうか? 仕様書通り作れば一応「完成」させることは出来ますが、それは「ビジネス価値の実現」とは全然別ものなんじゃないですかね。思うに「ビジネス価値の実現」にフォーカスした場合「完成」という明確な状態が存在しないんじゃないかと。

従来のように開発者サイドが成果物責任を負うということになると、クライアントが「ビジネス価値の実現」を求めているのに対して、開発者サイドは「仕様書が定義する完成」を目指さざるを得ないのです。それも「ビジネス価値の実現」をほっぽり出してまで。

だからmofmof inc.の受託開発では月額制で「準委任契約」という契約形態で、ソフトウェアの完成責任を負わないが、エンジニアリングという役務に責任を負うという形態を選択しているわけです。

誰だって作ったものを成功させたい思いは同じはずなのに、契約形態や責任という理由で、チームの向いている方がバラバラになんてしまうのは本当に残念な話じゃないですか。

マインドを変えたり、やり方を変えたりすることで、チームを強く出来る可能性があるし、もっとエンジニアは価値を出せるはずだと信じてる。ぼくたちはそんなことに挑戦していきたいなと思ってます。

一度完成したら終わりではなく、継続的に改善していく作り方が出来る - 株式会社ネクストレボ水野様クライアントインタビュー

f:id:redhornet96:20151112012758j:plain

今回ネクストレボ様のサービスの開発を担当した原田です。弊社の月額制の受託開発で一緒に開発をしてきた体験をインタビューを通してお伝えします。

※まだ非公開サービスのため、開発したサービスの内容については掲載していません。

弊社の月額制の受託開発を選択した一番の理由はなんでしょうか?

比較的コストがリーズナブルで開発しながら設計を柔軟に変更出来るという点が決め手でした。また、あらかじめRubyで作りたいと決めていたので、Rubyに特化した開発会社という点も非常にプラスでした。

仕様や目的を詳細に事前にお伝えしたおけば、その中の情報から最善の実装を汲みとってくれるため、ある程度お任せしても安心して進めることが出来た点が、私達のニーズに合っていました。

弊社の月額制受託開発を利用してみて良かった点はどんなところでしょうか?

一番大きいのは、一度完成して終わりではなく、頻繁に仕様変更や修正ができるので、外部情勢の転換や、ビジネスの方針を変えたときにも、ビジネスに合わせてプロダクトの形を変えていける点でした。

またコード品質の向上にも余念がなく、常にコードのリファクタリングとセットでしかもスピードを落とすことなく開発していただけるので、膨大で複雑な負債コードが残りにくい作り方をしている点も良かったです。

改善できると良い点はどんなところでしょうか?

まだサービスインしていないので、いまのところは大きな問題はありませんが、随時開発をし続ける形のため、きっちりと実装範囲と納期で区切ることが難しいところはあります。

ただこの点については、完成品を納品してもらうスタイルと、随時開発を続けるスタイルのトレードオフの関係にあると思っているので、どちらがいいのかという問題だと思っています。

最後に

水野様ありがとうございました!