hiroktsのブログ

IT開発系の勉強会の感想とか雑記とか

Accountableの解釈の誤りと自分事化、そして意思決定の明確なルールについて

Accountableの誤訳 

アジャイル系の本やスライド資料などを見たときに、一部でAccountableを「説明責任」と訳していると思いますが、Accountableは説明責任ではないはずです。
 
Accountableの英語の語感については以下の３つの記事が詳しいです。
 
 
これらの記事を合わせて読むと、Accountableの意味は
  •  「誰が責任を取るのか?」という時に使われる
  • 端的に言いかえると「落とし前をつける責任」である
    • 落とし前をつける = 引責辞任する、賠償金を支払う、　減俸、　懲戒処分とかをうける
新聞で、～の責任を取って辞任した、みたいな内容のときにはaccountableが使われるということみたいです。
なので、アジャイルとかの日本語の書籍や資料(スライドなんかも)で『説明』『説明する』ではなく、「説明責任」という言葉が出てきた場合は要注意。
本当はもっと、「落とし前をつける責任を持つ」「何かあったときに後始末を必ず請け負う」ということについて書かれていることが多いとおもいます。
エクストリームプログラミング第２版でも、「経営幹部は、XPチームに勇気、自信、『説明責任』を提供する」と書かれていますが、ここは『落とし前を付ける責任』と読み替えるほうが自然だと思います。
トヨタ生産方式に言及して、作業者を含めた全員が品質に責任を持つという話も書かれていますし、原文にもaccountableやaccountabilityについての記述があることは確かなのです。
(でも該当の記述の原文をちゃんと見たわけではないので間違っていたら申し訳ありません)
 

コーチングで使われるAccountableと自分事化について 

ビジネスコーチングを過去に受けたことがありますが、コーチはAccountableとVictimの対比でAccountableのことを説明されていました。

Accountableはほぼ「自分事化」「自己責任化」という態度で、Victimはその逆で「犠牲的」「主体的でない」「誰々のせいで私は～することができない」という態度という説明だったと思います。

当然ですが、Accountableになるほうが良いとアドバイスを受けました。

気を付けなければいけないと思っているのが、物事に対し自分が「誰々のせいで私は～することができない」という犠牲的な態度になっていないかということです。

本当にそうなのか？ということを考えてみることが自分事化だと思います。

Accountableと意思決定の明確なルールについて

 適切な意思決定プロセスとメンバとの良好な関係が築くことが一番大事、よく言われてることです。
特に意思決定のうまいやり方についてはすごく気になっていて、いろんなひとにチームや組織の意思決定をどうしているか、ということを質問したりしています。
 
上の真ん中の記事を結構前に見たのですが、久々に読み返していて、以下の内容が目に留まりました。

 

“Mike is responsible for holding Sally accountable. Tom is responsible for holding Mike accountable. I am responsible for holding Tom accountable.”
「マイクはサリーをアカウンタブルにしておく責任がある。トムはマイクをアカウンタブルにしておく責任がある。俺はトムをアカウンタブルにしておく責任がある。」

 
つまり、
「マイクはサリーに落とし前をつける責任を持たせる義務がある。トムはマイクに落とし前をつける責任を持たせる義務がある。俺はトムに落とし前をつける責任を持たせる義務がある。」
 
と、言い換えてもよいと思います。
 そこで、「これは意思決定の明確なルール作りにつながるのでは？」と思い至りました。
 『プロジェクトの進捗』や『プロダクトの品質』や『いきいきした仕事』についてaccountabillityを明確にさせておく、ということができていれば意思決定のルールをどう決めればよいかわかりやすいんじゃないかなと考えています。
自分の仕事の、「進捗やプロセス」「品質」「いきいきした仕事」に対してAccountableになりきれるように努力していきます。

アジャイルコーチというロールについて

エンジニアの学ぶべきことの深度は日々増加していて専門性も高くなり、そのために協調して働くスキルが必要になってきていると思います。

付け加えて言うなら、深くなってるんだから潜るのには勇気がいります。
誰もが教科書やコードを読んで、教えてもらうことなく技術を使いこなせるとは限りません。
たとえ技術力や意思力でヘタレだったとしても、そういった未知の領域に潜っていく勇気を与えてくれるのがスクラムやらXPであると思います。
スクラムやXPが生産性にすぐに直接影響を与えることが大きいとは自分は思っていません。継続的にやってこそ効果が出ると思います。

スクラムやXPの具体的な内容についてはここでは言及しませんのであしからず。

 

ただわかっているのは、やみくもにそういったプロセス改善のフレームワークを用い、プロジェクトがうまくいかないこともあると思います。
根本的な原因は、そのフレームワークそのものにあるのではなく、プロダクトの品質をキーにしたマネジメントをしていないということだったりします。
あるいは人同士の相互作用でプロダクトができるのを無視して、信頼関係の醸成やコミュニケーション(特に意思決定のルール)を軽視していたりすることだったりもします。
原因はともかく、うまくいっていないという現実の課題に踏み込まないまま、プロセス改善のフレームワーク(の上辺だけ)を適用しようとすることだけに注力しようとするのは自分は非常に危険だと思っています。

(そんな状態が続くとエンジニアのフレームワークに対する嫌悪感がたまり、悪のオーラ力がたまってハイパー化します。あるいは、エンジニアのソウルジェムが濁っていき、魔女化します。)

上手くいかないときはアジャイルコーチに頼ってみよう

そこで出てくるのがアジャイルのコーチです。
僕の知っているアジャイルコーチの最初に言った一言は「スクラムの教科書的な答えが知りたいですか？開発をうまく回したいんですか？」という内容です。
スクラムを単純に教えてくれる先生ではありません。

現場の課題に踏み込み、信頼して任せるということ

よく言われることだと思いますが、(良くないOJTのように)放任するというのと、信頼して任せるのは違います。

最初の段階では、アジャイルコーチはチームに問題があるかどうかを観察し、その課題に対してチームがちゃんと踏み込めるようにお膳立て(ファシリテーション)します。
具体的には、振り返り(retrospective)の効率的なやり方としてタイムボックスを提案してみたり、ときには簡単なワークショップもその場でやったりもします。
僕たちのチームの最初の課題として、KPTのproblemが浅く、tryの理由づけとして機能が弱かったというのがありました。
それを解決するのになぜなぜ形式でチームに問題の掘り下げをさせ、ボトルネックになっていることは何かということを追求させました。
やってるのはあくまでもお膳立てですが、ちゃんと現場の課題に踏み込みます。

コーチはそうした観察とデウスエクスマキナのような(だとちょっと言い過ぎかもしれませんが)交通整理を繰り返して、ある程度になった時点でチームを信頼して任せてくれたと思います。
決して教科書読ませてワークショップやって良かったねして、あとは自分でやれという感じではないです。

(新入社員の初年度研修などはそういうふうにせざるを得ない事情もあると思いますが・・・)

アジャイルコーチ、何となく良さそう！

アジャイルコーチとして、ファシリテーションの技術だけでなく、アジャイルに限定しない問題解決のプラクティスの引き出しが重要になると思います。

あくまで個人として感じたことですが、いいコーチはチームの困ってることを助け、自信を着けさせてくれると思います。
皆さんがアジャイルコーチというロールについて知らなかったのでしたら、「何となく良さそう」と思ってもらえるとうれしいです。

windows10のマシンにvagrantを入れて、ubuntuを動かす

やりたかったことはタイトルの通り。

vagrantとvirtualboxをインストール

http://www.vagrantbox.es/ から、ubuntu 14.04のURLをコピーし、以下のコマンドを実行

$ vagrant box add ubuntubox https://cloud-images.ubuntu.com/vagrant/trusty/current/trusty-server-cloudimg-amd64-$ vagrant-disk1.box
$ vagrant init ubuntubox

vagrant upで「Waiting for machine to boot.」で止まって失敗

そのままvagrant upしたのですが、以下のところで止まりました。

==> default: Waiting for machine to boot. This may take a few minutes...
    default: SSH address: 127.0.0.1:2222
    default: SSH username: vagrant
    default: SSH auth method: private key

数分待っても変わらないので、原因を調べてみることに。

まずは以下の記事を参考にしました。

virtualboxのguiを有効にするのがどうやら原因の解明にいいらしいということで、以下のようにVagrantfileのコメントアウトを外しました。

  config.vm.provider "virtualbox" do |vb|
  #   # Display the VirtualBox GUI when booting the machine
    vb.gui = true
  #
  #   # Customize the amount of memory on the VM:
  #   vb.memory = "1024"
  end

再度vagrant upをやってみると以下の記事に出てくる、「ホストマシンの仮想化支援機能(VT-x/AMD-V)が使用できません。ゲストOSは64ビットCPUを検出できず、起動できません。」というダイアログがでました。

http://qiita.com/super-hot-engineer/items/21e4456b8318db877f5b

ググったらこんなことが 「ホストマシンのBIOS設定でVT-x/AMD-V を有効化してください」 とりあえずググったページの通りにやってみよう。 たぶん自分のPCの仮想化支援機構が無効になっているようだ。

motherboardのCPU設定でvirtulizationを有効にする必要があるっぽい。
わからない人はマザーボードのBIOSメニューでとにかくCPU関連をあさりまくるしかないです。
ボードによってはもしかするとなかったりすることもあるのかも。

BIOSを変更して再起動し、やっとubuntuの14が動きました。
ありがとう、ぼくのサンドロック
参照先の元記事を書いてくれた皆様に感謝いたします。

Devlove現場甲子園2015東日本大会に参加してきました

前日の夜まですごく行くかどうか悩んでいましたが、Devlove現場甲子園2015東日本大会にいってきました。

 

 

市谷さんの話に出てきた『エモい』について

エモというのは音楽のジャンル(ロック系？)からきているのかと思います。
詳しくはないのですが、ちょっと長くいうとエモーショナルハードコアという名前で、その派生としてスクリーモなどがあるそうです。
ちょっと聞いたりしたこともありました。
Wikipediaを引用すると

 

エモ - Wikipedia

 

疾走感溢れ、正確なリズムとラウドなギターをベースにしたバンドサウンド（ギター、ベース、ドラムによる一般にハードコアやパンクで使われる楽器での演奏）に副次的な演奏（ピアノ、 キーボード、 シンセサイザーなどの演奏）を用いて、哀愁のあるメロディと情緒的なボーカルを乗せる

という感じ。

音楽に対して、「この曲はエモい」などという流れがあったのではないかと認識しています。
エンジニアリングにも、似たような感情で表現する形容詞として「エモい」が使われるようになったのではないでしょうか？


『受託開発の会社が自社サービスを開発・運営する中で見つけた自分たちにあったスタンス』
ヴェルク　田向裕介さん

 

Devlove関西で聞いた　boardの田向さんの話と、次のDocBaseの天野さんの話がもう一度聞きたくて勢いで東京までいった感じです。
基本的には同じお話だったので、前に書いたブログ記事と内容がかぶってしまいます。
ですが、やっぱりすごく面白かった。忘れていることも多かったし。
意思決定に関しての明確な方針がある（コストのかかる合議制は取らない）のがやっぱりいいと思いました。
自分がメンバーだったとしてもそんなところに時間はかけてほしくない。
差分としてあったことですごく面白かったのが、実験的にユーザーの個別相談会をやってみたという話。
時間を１時間予約してもらって、個別に密に相談する。
お客様からも意外と好評で、田向さんとしてもイシューの吸い上げだけでなく営業にもなるのですごくよかったとのこと。
開発者とユーザーのつながりがワンストップであることがやっぱり非常に重要だなーと思いました。
営業の人のヒアリング結果を開発者に伝える、ということではないところが重要。
カスタマーサポートをエンジニアがやってみる経験って田向さんのように直接のコミュニケーションではないですが自分もやったことがあり、いろんなことがわかります。
１回目ではっきり行って良かった感が感じられました。


『試行錯誤と改善を繰り返し、チームの開発力を高めた方法』
KRAY　天野 充広さん

 

お話はDocBaseの開発に限らず、チームを育てるという話がメイン。

サービスの価値を理解していない
開発メンバーが指示待ち
言われたものだけを作っている
だめなものをだめと言えない

といったことをなくすことで、メンバー全員が主体的に動いていくチームを目指す。
やっぱり自己組織化というキーワードがしっくりくるお話です。

自分に身近に感じられないものでは価値が判断できないという話はなぜドッグフーディングで作るのかという話につながるし、スクラムなんかがなぜ必要かということにつながると思います。

個人的にも意思決定のプロセスは優しい独裁のほうがいいんだろうな、とは思いますが、協調して働くためには意思決定のプロセスだけでなくメンバー間の良好な関係が築けているかも重要だと思います。
この話のテーマの１つだと思うけど、「メンバーの成長」を実現するにもやっぱりメンバー同士の関係性重要だと思います。
そのためのチームビルディングだし、スクラムのようなフレームワークだとおもいます。
メンバーの一人が提案によって「週１回一人２０００円を会社が負担して、みんなでランチを行い、仕事の話はしない」ということをやっているそうです。
会社が負担というところがいいですね。
勉強にしても、好きに勉強していい時間が週４時間あるとのことで、いいなぁと思います。

朝会やKPTのやり方の話も良かったです。
KPTって、前のDevlove現場甲子園2015西日本大会で久保明さんが話されていた、行動科学と関連してくると思います。
「行動をほめる」習慣作りがすごくいい感じかも。

こうした様々な取り組みの結果、「他のプロジェクトで使えるようにプラグインで公開する」などの自律的な行動が増え、場のことは現場の人を信頼して任せることができるようになったとのこと。
プロダクトを小さく作って繰り返し検証するという話ももう一度聞きたかったけど、今回の話も面白かった。


『Developer Infrastructure』
Wantedly 坂部広大さん

 

企業などの採用ページの入力にwantedlyの情報を自動で入れるajaxのボタンを導入した話。
質問であったのですが、あらかじめ効果の高いであろうサイトと交渉して事前に一緒に作業してテストまでやっていてから公開したとのこと。

wantedlyの文化　

Code Wins arguments
議論よりもその場でコードを書いてみて検証するほうが確かである

User First
バズりやすいというか、ツッコミを受けやすい
単にユーザーの言うことをきくのではなく、ユーザーの本質的なニーズに気づくことが大事。

確かにと納得させられる話。
言われたことをやるだけではインフラチームは務まらないと言われることが多いと思いますが、インフラチームだけじゃないよなーと思います。

インフラチームのKPIをどうしたらいいの、といった話が続いて
上限KPIが10%も改善しないような施策はやらないとか仮説をどう立てるかということが重要になるとのこと。
MVP的なアプローチなのかなーと思いました。

インフラチームはコードを書かないけど、自動化やセルフサービス化によってインフラのコード化をすればいい。


サービスが拡大すると開発チームばかりが増大する問題。
タスクが溜まってインフラチームが帰れなくなり、インフラチームがボトルネックになる。
わかる。。。。
ここで、解決するためにメンバーを増やすということではなく、インフラチームの質を底上げする都いうアプローチを取ったそうです。

WHAT: 何を実現するか？

変化に強いインフラ、変化を避けるインフラではなく、むしろ変更を前提とするインフラを実現するとのこと。

インフラのコード化によって、依頼の形式がissueではなく、プルリクになった！

ここで疑問があったので、あとで質問してみました。

「１つ目の質問として、開発チームにインフラの知識が必要になるのではないですか？
２つ目の質問として、開発チームも依頼しやすくなる？　開発チームとインフラチームの対立をひき起こしにくくなるとか副次的な効果があったら嬉しいんですけどないですか？」

回答としては、インフラチームはインフラのことをアプリチームに教え、アプリチームはアプリのことをインフラチームに教えるという勉強会を隔週でやっているそう。
それは仲良くなれる上にプルリクで依頼というのもやりやすくなるなと思いました。素晴らしいなー

情熱プロジェクトと痛み分けタスクをどっちもやる。
普段アプリのエンジニアの話ばかりを聞くことが多いので、今回の話はすごく参考になりました。
前もヴァル研さんの話で聞いたけど、その時と違ってなぜこういう取り組みがいるのかというのが身にしみている感じです。

インフラエンジニアの人たちにももっと紹介したい話だと思ったので、Devlove関西でも、もう一度坂部さんの話が聞きたいと思いました。

why
インフラチームのモチベーション管理
インフラチームが依頼されたタスクをこなすだけでなく、自分たちのやりたいことを実現するには
インフラチームとアプリチームの歩み寄りを実現するには

 

 

『プロジェクト管理しないという提案』

株式会社ZIG CTO 森 英寿さん

 

はっきり言って知らないことが多すぎて頭の中がちょっとオーバーヒートしました。

技術をコアにしたスタートアップ特有であるかもしれないプロジェクト管理です。
自分の感じたこととして、コミュニケーションにコストをかけることで社内の雰囲気・文化・ビジョン・会社の軸を醸成することが大事なのかなと思いました。
それをやる前提条件としてお互いの信頼が絶対の前提条件。
スタートアップでぶち当たる「資金調達して、アプリを成功に導く、つまり前半で説明されていた通り、出してすぐはバーンレートが赤字を垂れ流し、プレッシャーになったりする壁」に、３人の組織として立ち向かう際に軸がぶれていては話になりません。
作りながら文化も醸成していく。
過去のissueを管理したり思い出して何かやるより、今上がっているissue(絶対の信頼がある仲間から上がっている課題です)を解決することが重要。
確かにそうなるだろうなと想像はできました。
本当に重要な課題は何回も出てくるし、逆に何回も出ることでその度に新しい改善方法を考える機会が得られるというのも確かにそうだ、と感じました。

面白かったのは、スタートアップとして、の段階を通り過ぎた後はエンジニアなどの採用をどうするのかというお話で、そこについては初めてだからわからないので逆にWantedlyの坂部さんに質問をされていました。

坂部さんの回答としては、エンジニアのスキルを持った人が「前職はこうだったから」というロジックで行動して会社のビジョンなどとマッチせずに離れていくのを防ぐには、やっぱりビジョンなどについても結論だけで話すのではなく、徹底的に話し合う必要が出てくるとのこと。
そういう段階においては、過去の経緯が多少わかるようにWhyとWhat(あるいはDone内容の記述かなと自分は思いました)を管理していく、マネジメントも必要になるのではないかという回答でした。
１個前の坂部さんの講演も聞いてて良かった感が非常にありました！


でもやっぱり１回じゃわかりきれなかったので『も゙っがい゙』的な気持ち強かったです。


『ゲーム開発2つの現場』
スクウェア・エニックス 岩本翔さん

 

（この辺もう完全に自分の電池キレ気味だったかもしれません。申し訳ないです）
１年ほど前よりサウンドプログラマとして、サウンドを制御するためのサウンドドライバやサウンドデータを作成するためのオーサリングツールを作っているそう

マルチプラットフォームで　マルチチャンネルで、いろんなサウンドのフォーマットで音を鳴らさないといけないので難しい。
音量を調整するだけでなく、負荷の問題も制御したり、開発環境がいろいろことなるが、いろいろ同時にサポートする必要が有るそう。


上から指示されたことを計画通りにやれということではない
「『やっていいですかね？』じゃねーよ、『できました』って言え」

すごすぎる。でもただしいというか。

スタンドプレーの結果から生じるチームワークが主体だけど、スクエニ全体がそうじゃなくて、サウンドチームは独立国家

朝会などなくて、本当の裁量労働
コードレビューなどはしないが、読めばわかるというレベルの高い人が集まっているため、全体は把握している

元は朝会やるとかいろんな試行を繰り返して、今の形になっているとのことだし、これからもずっと変わるのかもしれないと感じました。

部内ではマイルストーンはないが、別の部署から　使ってる側からの都合で予定が決まるそうです。
仕様書などなくて、実装された物が仕様で必要になればドキュメントも用意するとのこと。


自由に仕事できる　モチベーションは高いけど、何をやればいいか自分で考えないといけない、何をやったか自分でアピールしないといけないとのこと。

きついけどやりがいしかない感じがします。

「ゲームの発売日とかは理由書けば休める。」

 


Aiming 相良 拓哉さん

 

オンラインゲームのクライアント側の開発をやっているとのこと

朝会・夕会は基本なく、その理由の一つとしてプロジェクトでサーバサイドなど全部入れると30人を超える

ほぼ毎日研究のため他社ゲームで遊んでいる　→　ゲームの共通言語ができた


社内勉強会
結構いろんな人が多すぎて絶対に情報の共有が必要
技術だけでなく運営にか関わる法律の話、例えばコンプガチャ問題やマーケティングの話なども

 

勉強会は持ち回り？
運営を相楽さん　運営サポート５人
月１回　運営会議　「こういうのってしっておかないとまずくね？」みたいなことを決める
逆に、「やりたいんだけど」っていってくれるひとがいる　勉強会の枠を使ってもらう

勉強会の運営会議かー。これ全然ゲーム開発関係なくいいやり方だと思います。
ダイアログのなかでもでたけどお菓子配るとかの工夫もいいですね。
違う現場の社内勉強会のやり方、もっと知りたいかも。

毎週やろうとすると辛くなる。結構フィードバックない
開催したらくるけど何もない。続けるためには無理にやらない

なんだかんだオファーするとやってくれる
いつやってくれるかきいてこないと、日程をある程度決めておく
日時近くなったらできますか、と聞く　リスケ

アンケートやってみると、よいとか非常によいとかのフィードバックが多い
モチベーションになる

ちょっとずつ勉強会に関わる人を増やしていく

岩本さんから勉強会のフィードバックのもらい方についてのTIPSのアイディアが！
dwango勉強会　付箋を配っておく　その場で感想をもらう

こうやってその場で改善の提案が出るところが素晴らしいです。

魔導書買おう。


全体の感想

結局のところ、ほとんどの現場で無駄なリソースを使う余裕なんてないんだと感じました。
本当に必要なもののみに注力する、ボトルネックを改善する、全体の収益に一番影響を与えるものを徹底的にこだわって改善する
現場に今必要なことって、現場ごとにやっぱり違う。

肌感覚も大事だけど、その辺の見える化やメトリクスについてもエンジニアリングの文脈でいっぱい出てきているのかな、、、みたいなことも考えました。

 

発表者の皆様、スタッフの皆様、参加者の皆様、会場の運営者のYahoo株式会社様、ありがとうございました。

Devlove現場甲子園2015 西日本大会に参加してきました

Devlove現場甲子園2015 西日本大会

初めてスタッフとして参加
会場の司会担当になりました。
緊張しすぎて結構つまるところも多かったので会場の皆さんやスピーカーの皆様方にはご迷惑をおかけしました。
メモを取る余裕もほとんどなかったので、以下はほぼなんとなく覚えていることの感想がほとんどになります。

 

『ユーザーに向き合う最前線』
Yahoo株式会社 山本学さん

世の中に公開されているさまざまなサービス(API)と、ものをIoTで結びつけるHUBとなるサービスであるmyThings。
そのサービスを開発者としてだけでなく、エバンジェリストとして広めていくことになったエンジニアとしてのキャリアのあり方、みたいな話だったと記憶しています。
人の目に露出する、使ってもらう、ファンを作る、などの切り口で考えた時、メディア発表だったり、ハッカソンだったり、Devloveのような勉強会だったり、あるいはハンズオンだったりのチャネルの違いでできること、広まることが違うとのこと。
ヌーラボの染田さんとロール的な立ち位置の変わり方が対称的だなーと思いました。２人で対談とかしてみてログとってみても面白いんじゃないかなーと思ったりします。


『Misocaチームの自己組織化への取り組み』
株式会社ファントムタイプ 小久保 祐介さん

 

Misoca自体はクラウド上で請求書を作って送れるプロダクトの名前でもあり、会社の名前でもあるとのこと。小久保さんは協力会社。
昔はカウボーイスタイルで個々の裁量に任せっぱなしだったのを自己組織化したチームに少しずつ少しずつ改善していったという話。
agileの手法やツールを導入するにも、そのチームにあったやり方があってそれを模索する。
pivotalトラッカーが合わなかったら付箋を貼るホワイトボードのタスクボードでやってみるとか。

去年devlove甲子園西日本大会のaチームさんの「Agileごっこで始めてもいいじゃない。でもやめんな」という話を思い出します。
朝会だけ導入するとか、チームごとにKPTのやり方を変えてみるとかあったような。しかも名古屋だったような。

ポエム駆動開発とまではいかないまでも、日常のモヤモヤをポエムにすることで他人のやっていることや考えていることが伝わるみたいな話もあった。
しかも使っているツールはesa.io。ポエムを書くならesa.io?

そして逆襲のスクラムはちょっとかっこよかった。
スクラムとかアジャイルとか限らず継続的に改善する雰囲気って大事だなーと思いました。


『君が居て僕が居る　マネジメントと開発メンバのDiffトーク（そして現場からは、誰も居なくなりそう）』
NECソリューションイノベータ株式会社 アジャイル開発推進センター所属　石崎 浩太郎さん
経営管理センター所属　西 秀和さん

DevLove広島のメンバーのお二人。
会場が２つのモニタを別々の表示に使えるとのことで、急遽２人別々のプレゼン画面を表示しながらやることに決めたそうです。
(もちろん、前もって２画面版と１画面版は用意されていたようですよ)

指示棒がライトセーバー。しかも「ブン。。。。ブン。。。。」的な効果音が常になりっぱなしで面白かった。
大手ISPの案件を受託開発する会社でアジャイルなどをどのように導入していったか、どのように改善していったかといった話だったと思います。
２人は別々の会社で、リーダーとパートナー会社のメンバーだったとのこと。
はじめは全然意思疎通もできなかった。
だんだん改善して、それこそ自己組織化された結果・・・
このチームのリーダー？スクラムマスター？いらないよね、とメンバーから外されたというお話も。。。。
会社の半期くらいの事業リストをみんな繰り返しで見る話が面白かった。
やっぱり会社としてやりたいことがわかってるとみんな共感とか納得して、プロダクトを作るモチベーションになるとおもいます。


『自動化とは何か？ゲーム開発において実践した自動化とは？』
プラチナゲームズ株式会社 森田　和則さん

 

個人的に衝撃的だった「ベヨネッタ２のゲーム開発のデバッグにおいてコントローラの操作を自動化する」というブログ記事の執筆者です。
はてブで見て「まじか」となりました。
今回はその話ではないですが、ゲーム開発における自動化の意義についてやそのやり方など。
意義はクリエイティブに集中するために自動化する。
エンジニアだけじゃなく、グラフィックのデザイナーさんなども含めて、簡単に更新する処理ができるようにxmlのファイルベースで日々のビルドによる、ゲームの負荷などのパフォーマンスをJenkinsとか色々使って可視化しているとのこと。
誰でもできるためにDBなんか使わずにファイルベース。

やっぱり本当にクリエイティブのみに集中したいという考え方に共感します。
前もAsiyan automation allienceでもゲーム開発者の方が話されていたように、どこの開発現場でも本当に必要ならばそこで作ってしまう文化がゲーム開発現場にはあるんじゃないかと思いました。
セキュリティなどの考え方についてもゲーム開発の現場では、Webなんかと比べても非常にシビアだとか。
普段自分と関わることのない現場の話が聞けて面白かった。


『サービスx現場』
株式会社モノタロウ　牛島真一さん

チームをうまくまわすだけでなく、そのマネージャークラスでもアジャイルにコミュニケーションをやりましょうという、言わばスクラムオブスクラム的なお話なのかなと思います。
チームが違うとお互いのリリースに関心を持っていなかったり、急に別チームに依頼をしても、「もう今回のスプリントに入らない」みたいな問題を解消しようと。
チームの関心をわかるためにマネージャの朝会をやったり、朝会時に使うタスクボードで他のチームのリリース予定などに自分のチームが、（たとえばDBを見てるグループとWebのアプリのグループが）「このリリース、うちのグループも関係してるなー」と思ったらシール貼って意思表示するみたいなことをやっている。

マネージャー陣の時間は潤沢にはないので、効率的にまわさないと「この時間本当にいるの？」的なことが飛び交っているんじゃないかとか色々思われますが、諸事情があって感想書きにくいです。
でもどんなことでもやってみて継続的な改善のサイクル回すって大事だと思います。繰り返しになるけど。
最後の質問は「そっとしておこう・・・」でいてほしかった的な感じだったです。


『エンジニアが幸せな人生を過ごすための学び方、関わり方、あり方。』
コニカミノルタ株式会社 久保明さん

MVPの再演です。

TEDみたい、という感想もあったようですがまさしくその通りかと。
練りに練られたプレゼンでした。
覚えていることベースで書きます。

 

他人の幸せを考えるためにはまず自分が幸せになること
エンジニアにとって幸せとは？

リーダーの自分がガントチャート書くのが苦手なら、得意な人にやってもらってもいいじゃん。
成長するのは良いことだ、から、成長しないことは悪いことだ　にしないように

そのためには行動科学がいいですよーと

 

ダイアログで久保さんと話させてもらいましたが、自己組織化とか自律的なメンバーの行動をうながすために、チームからリーダー的な立ち位置の人が手を引くのも手だけど、やるなら段階的にとか。
そして、本をオススメされました。


「マンガでよくわかる　行動科学で成果が上がる組織を作る 教える技術」1, 2巻


次の日に買いました。
久保さんものすごく面白い人だと感じました。


いろんな現場知れて本当に楽しい。

 

発表者の皆様、他のスタッフの皆様、参加者の皆様、会場の運営者のエムオーテックス様、ありがとうございました。

 

esaとDocBaseのサービス開発のDiffの話 #DevKan

WIP

2015年11月28日に実施された表題の勉強会に参加してきました！

devlove-kansai.doorkeeper.jp

speakerdeck.com

KRAY 天野 充広(@amachin)さん

そう言えば、ホッテントリからKRAYさんの記事ブックマークしてた！

git pull と git pull –rebase の違いって？図を交えて説明します！ | KRAY Inc

esaさんとは実は仲がいい

以下、メモ的な内容になりますが、DocBaseさんのお話になります。
少し開始時刻に間に合わなかったので、途中からになります。

なぜ作ったのか？

  • 社外秘の情報がいっぱい
  • ユーザー数による課金

その結果

  • 外部の開発パートナーと共有しづらい
  • クライアントと共有しづらい
  • アルバイトやインターンを招待しづらい

問題点「有用な情報が関係者全員で共有できない」

一部の人だけが使えないツールの問題はうちの会社でもあります。
結局のところプロパー社員以外も含めて全員に共有するにはメールしかなかったり。
一番共有したい手順やヘルプトピックなどが共有できなかったり。

ドキュメントを作るのは大変(というイメージ)

  • ちゃんとしたドキュメントを書かなきゃ。
  • 間違った情報を書いてはだめだ

その結果

  • ずっと下書きのまま。
  • 小さな情報は共有しづらい
  • きちんとしたドキュメントを作るのは大変。

この辺でesaさんにはWIP機能があるんですよね、という話が入った。
DocBaseのスライドなのに「esaの命題」というタイトルになっています。
人数少なかったのもあって、参加者と発表者そして、esaの深谷さん、赤塚さんも質問や発表内容の捕捉に加わってもらいながら、いい感じに質問のキャッチボールができてました。
WIPって何て説明すればいいんだろう？仕掛中？　　 うちの会社では、プルリクエストにWIPというプレフィックスをつけて出す場合がかなりあります。 esaさんはWIP機能で「未完成でもいいんだよ」とハードルを下げて、「ドキュメントを書く」ということを促しているそうです。 DocBaseさんでもWIP機能は検討したそう。

DocBaseの命題：チームの情報共有を活発にさせたい

情報共有が活発になると

  • 新しい知識が共有され、チームメンバーが成長できる
  • 暗黙知を形式知にしたい
  • チームが力を最大限に発揮出来る

DocBaseの特長

  • URL一つだけの小さな情報も気軽に投稿できる
  • Slackなどにながれる有用な情報をためておける

このコードおかしいから直したい、だとか流れて消えてしまうにはもったいない情報なのかなと思います。
本当によくあることだと思います。

小さく始める

  • 小さな情報をまとめて有用な情報にできる
  • まとめ機能は手順書を作るときに役立つ

関係者全員で情報共有できる

  • 柔軟な権限設定：組織全員だったりプロジェクトごとだったり
  • シンプルなUIでエンジニア以外も使いやすい

  • ユーザー数無制限

  • いろんなアプリごとにデザインのスクリーンショットをとったりしている

  • スクリーンショット貼り付けの機能は、メンバーがいつの間にか入れていた

  • ヘルプセンターに機能の使い方がかれている ** テーブルを超簡単に作成する方法など

  • esaはマークダウンでスライドにできる ** かなり使われている！

  • メモを開いたときに可変にならない 画像の問題があった 広げる機能を作る予定

  • esaは画像についてはオリジナルを出している

アクティブユーザー２倍

  • 共有されたドキュメント数 ２ヶ月で１万増

esaとの出会い

  • DocBaseのプロトタイプを作っている時期
  • 別の仕事で飲んでいたときに、同じタイミングでお互いに内々に作っていたのがわかった (うわ、やりづらくなったなぁ、というのはあった。) (出してから、お互い情報共有して)

設計と開発

新サービスを作りたい

  • 受託も楽しいけど

小さく始めるしかない

　サービス検討を小さく

Amazonを真似して、プレスリリースを作る

  • サービスの概要、問題アピールポイントなどをプレスリリースの形式でまとめます。
  • ワーキングバックワード法

モック画面を作る

  • 一番価値があると考えている画面を作って検討

  • 10ぐらいのアイデアから１つに絞り込んだ。

  • 企画会議

  • お菓子を置いてお菓子を食べながら

作るもの決まったぞ！

社内の意見など

  • リソース割くけど、利益出る？

小さく始める

小さなチーム作り

  • 最初のチームはエンジニア３人と私の4人。
  • 受託開発と並行

価値検証したい部分だけ作る

  • モック画面を開発合宿で作って、社内で検証
  • 日光にあるペンション　ついたらすごい大雪になって、次の日の朝すぐに帰った　帰りの電車の中でも作った

ドッグフーディング

  • 社内でリリース

社内インタビュー

  • 小さく早く回す

プチ合宿

  • 金曜15時から１８時までカフェに集まって開発

社内の意見

  • EvernoteやQiita:teamあるけど使ってくれるの？

小さく始める

  • 社内のみで公開

  • アイディアもすぐやめれる　サービス自体も。。。

  • ログインの機能などいろんないらないものはつくらなかった。

  • 社内でリリースした機能を公開 Evernote

  • 仮説検証のサイクルをまわしやすい

感想ですが、ドッグフーディングであると同時に完全に仮説検証可能な最小限のプロダクトで何回も仮説検証を回すという、MVPのアプローチになっていると思います。

社外10社くらいに限定公開

  • 自分たち以外にも役立つか判断しやすい
  • 実験的な機能を盛り込みやすい
  • 完璧をめざさなくていい

  • 価値がないとつかってくれないのでわかりやすい

  • 中途半端な機能実装もまだ実験的なので、ということがいえた

クローズドβで少しずつ公開

  • 事前登録してもらって１週間に10社ずつ招待
  • サポートにたくさん意見をもらえた
  • アップデート後のはんのうがわかりやすい
  • まだ辞められるという安心感
  • そろそろ後戻りができなくなるという不安感

質問： ペルソナを作ったり、アーリーアダプターにユーザーインタビューとかした？

  • 自分たちが使ってみたいユーザ　ドッグフーディング
  • こんなプロトタイプがあるんですが、つかってみたいですか？
  • 3社くらいは興味なし、２社くらいは使ってみたい

質問： バージョンの切り方　どこまで作ったらリリースみたいなこと

  • あいまい
  • ２週間のイテレーションのサイクルで出せる方が良い
  • esaの場合はできた段階で出す。

社内のこういうことがしたい、という思いに共感して

課題

  • 検索改善 ElasticSearch
  • 複合で検索できるように
  • elastic searchをAWS側に
  • サービス側からはindexのみにしてセキュリティのリスクを下げる
  • デザイン改善
  • より伝わりやすくするための生理機能
  • 規模が大きい組織向けの大規模対応
  • 画像以外のファイルも対応、ファイル添付
  • もっとスマホから使いやすくするスマホ対応改善

質問： 企画会議などで社内の冷静な意見が出ていた頃、開発メンバーは企画者の思いに共感していたの？(この質問は自分がぶつけてみました)
* 最初は半信半疑だった * なぜなぜ分析などで「なぜ情報共有するのか」などを繰り返した * ドッグフーディングで、社内の意見もクライアントの意見も集まるようになって「これはいけるぞ」という雰囲気になってきた。

なんか本当に素晴らしいと思います。

そしてesaのお話

speakerdeck.com

esa LLC 深谷 篤生(@fukayatsu)さん 赤塚 妙子(@ken_c_lo)

情報を育てたい

  • 最初から完璧を目指さず

WIP

  • 途中でもとりあえず共有
  • みんなにも共有するけど、積極的に通知はしない

WIPをつけるときのきもち

  • こんな感じで考えているんだけど、細かいツッコミはやめてね
  • WIPはエクスキューズ　ゆるい感じにする
  • できなかったことができる　書けなかったことが書ける

自分のために書く「ドキュメント」

ユーザー属性

  • チーム規模: 1〜126ユーザー
  • 有料ユーザーの３０パーセントが個人ユーザー

一人ユーザーが多い

  • メモ整理アイデアまとめ原稿執筆など
  • alt Evernote
  • 家庭内esa 夫婦カップル
  • 育児や夕食の連絡
  • ゲームのコミュニティ

プログラマ好みの機能・設計

  • 高いカスタマイズ性
  • API
  • シンプルでフラットな設計
  • UIは基本英語

プログラマ好みにした理由

非プログラマでもわかりやすい

質問： 見た目テーマ変えないの？

楽しいから、毎日作り続けてる

  • ユーザーのフィードバックがイシューになる
  • 982フィードバック　１０００を取った人には何かaword

土日が活発・次点で木曜日

リリースノート９月から１００

  • 週１、２回

標準的なリリースのサイクル

  • ユーザからのフィードバック　自分で思いついた機能をGitHubのissueに
  • GitHub Flowにしたがってブランチを作るい、適宜pushしながら実装
  • 導線だけつぶして、公開していることも

毎日がドッグフィーティング

  • 周囲の仲間達とesaで日報を共有
  • 業務委託先の会社でもesa
  • esa社のesa
  • 実家への連絡もesa
  • IT強くなくてもギリギリつかってもらえる
  • DocBase 子供の教育方針　交通事故にあったときの種々の連絡先

スケジュール・ノルマはなし

  • 締め切りによる心理的負担を減らして、より良い選択をしたい
  • 締め切りによるその後の開発も窮屈になってしまう。

Staging環境

  • まだない
  • 本物のデータで確認

Heroku

障害監視

  • Pingdom + PagerDuty
  • サービスダウンしたときに携帯に電話

リリースノート

  • esa上で運営してドッグフーディング
  • webhookで受け取ることができる
  • メール slack

質問： やりたいことをきめるのはどうする？
* 二人同時並行 お互い手伝う * mockまではつくってる これはなしだよ　みたいな話はする。 * どうしても収束しない場合は放置　ABなどはしない

カスタマーサポート

フィードバックに５分で返信する

質問に対して、「はい/いいえ」よりも良い返事がある

  • 「xxの機能はありますか？」
  • ユーザの問題はなんだろうか
  • それを現状の機能で解決できるだろうか
  • 他にも応急的な策はあるか？

バグ修正や簡単で効果的な機能追加はその場で実装してすぐにリリース数r

  • サポート中はモチベーションが一番高い

いろいろなチャンネルを使う

  • Web/e-mail/Twitter/直接

  • エゴサーチ

  • 既存の機能の改修ならすぐできる

  • フィードバックが同僚の意見の代わり
  • 井戸端というチャットツールでもフィードバックをもらっている

イベントでプレゼンする

  • 特に技術系のイベントでの登壇

技術系のイベント・コミュニティにツール提供のスポンサーをする

  • 運営チーム向けにesaの1チームを無償提供する
  • 東京Node学園祭2015
  • RubyKaigi2015
  • Wikiガチ勢からのフィードバック

Twitterであそぶ

  • esaアカウント

モチベーション　とても大切

  • for motivaated teams
  • 使う人　作る人　両方大切

フィードバックをもらう

  • クレームは宝
  • どんな厳しい意見

リリースノート書きたい

  • 書くのが楽、楽しい
  • リリースノート駆動開発

esaらしさ

「esaらしい」こと

  • 上から何かを強要しない
  • 気づいたらそこにあった

「無名の質」

esa LLCについて

２人でいろいろやる

開発者、経営者、ユーザ

２人だと開発スピードは遅い?

  • 現段階ではそうでもない感じ
  • 意思決定のスピードの速さ
  • 多少苦手だった営業などもesaのためだったらやれる　視野が広がる
  • 稼ぐべきお金が少なくて済む
  • 決定権は50・50
  • 得意な領域が違うのでケースバイケース

もともと趣味から始めた

  • Qiita:teamのクローンを2013年の１１月につくって満足して放置していた
  • 開発合宿でブラッシュアップした
  • pplog
  • 知り合いのエンジニアさんにiphoneアプリを作ってもらった直後に、深谷さんが勝手にandroidアプリを作っていた　知り合う
  • Qiita:teamフロー

会社よりもプロダクトが先

  • esaのサービスコンセプトが会社のコンセプト

We are not startup.

  • 出資を受けていない
  • 急激に拡大することを目指していない

経済状況

  • 受託とesaの秀英きトントンくらい
  • 週に数日スタートアップのお手伝い
  • フルコミットの受託は受けられない
  • esaの収益だけで食べていくことが当面の目

これから

  • ネイティブアプリ
  • 決済連結機能
  • 検索改善
  • スピードアップ
  • alt Wiki的な可能性
  • GitHubPageのesa版

使われても楽しい 自分たちで使っても楽しい

趣味から始めた「楽しさ」をどこまでも維持したい

質問： 大企業　外に繋げないなど　オンプレミスはできないの？　GitHubEnterpriseのように
* クラウドに依存している S3とかあるので難しいが検討したい。

質問： オフラインモード * 深谷さんがその場でイシュー作ってました！！

感想

esaの新コンセプトであるmotivated teamsですが、この会は参加者が少なかったのもありますが、本当に発表者、そして発表してないほうの発表者、参加者のあいだで活発に質問や意見交換が行われていて、すばらしい会でした。
主催の中村さんも、いつもこんなセッションができたらいいのにというお話をされていました。

この会のあと、電車で帰るときに中村さんに「(この２チームのように)Productに共感して開発したい」という気持ちを伝えたのですが、「共感は出来なくても理解、納得して作らないといけない」との言葉をいただきました。 esaやdocbaseのようにプロダクトに寄り添う仕事がしたいし、 受託案件だったとしてもやることに納得できる案件をとってきてくれるんじゃないかと信頼をして仕事がしたいです。

繰り返し、DocBaseの開発チームの話ですが、

  • 最初は開発メンバーも納得していなかった
  • そこからMVP的なアプローチ、ドッグフーディングで小さく小さく検証しながらプロダクトを育ててきた
  • 社内の冷静な意見もそうやって説得してきた。

というエピソードを聞いて、最もMotivated teamsにふさわしいチームなのではないかと感じました。 最もesaにふさわしいチームがdocbaseを作っていた。つまり、貴族主義は最初から間違っていたんだよ、ザビーネ！

esaとdocbaseこんなになかいいことも知れたし、2つのプロダクトの今後についてフワフワした期待感とともに非常に気になります。

発表者の３名様、DevLove主催の中村さん、参加者の皆さま、そして会場を提供してくれたTAMさん、本当にありがとうございました。

『board』のサービス開発の現場 #DevKan

『board』のサービス開発の現場 #DevKan

ヴェルク株式会社代表取締役　田向 祐介さん

2015年9月18日にあった表題のDevlove関西の勉強会に参加してきました。

 

devlove-kansai.doorkeeper.jp

 

boardとは

the-board.jp

 ドッグフーディングとは、自分たちの作ったものを自分たちの業務でも実際に使うという開発スタイルだそうです。(※指摘により修正しました)

会社としては受託の事業がメインで受託が好き　が、波がある

なぜ受託が好きなのか、ということを質問してみましたが、自分の知らないいろんなビジネスに携われるからとのこと。

 

私も前職はSIerでしたので、新しいビジネスプロセスにかかわれるときは面白かったです。つらいときはつらかったけど。

そういうつらい状態をなくすために、いい案件を受託するといった努力もしているそうです。

 

自社サービスの運用を開始した。

本業の受託とのバランスが難しい。

 

受託の会社なので、要件の検討などはお客様がやったものが降ってくる

つまり、要件の検討などの経験がない。

 

最初に作ったのはiphoneアプリ

ブレストのやり方を習得

  • アイデア１００個を１時間に出す
  • 整理する

繰り返し

 

想像以上にうまくいかない！

 次にやったのがスマホアプリCMS「Patto」

初めての自社サービス事業化

営業はいないのでインバウンドマーケティング

ソリューション型なのでお客様の要望を聞く受託に近い

自分たちに近い領域からはじめることが大事

 これは本当に思います。

自分の知らないことをいきなり始めようとしてもうまくいかないだろうなぁ・・・

とはいえやらないといけないときもあるのですが

要件どおりに作ることではなく顧客の満足を目指すならば

 

そして４年目にboardのサービスを始めた

受託が炎上していたら自社サービスの開発は出来ない。

（会社の）自分への依存度を下げる

どういうことかというと、代表である自分がほとんど営業して案件をとってきて案件の実現や管理部分も自分がこなしてしまうことが多かった。

そういうことからの脱却を目指すために、やったのはリスク感覚の一致

トライアンドエラーを繰り返すことで、「アラートあげすぎ」などの違和感をなくしていった。

 これはあるあるですね。

能力のあるなし、にかかわらず心配しすぎのせいで前に進めない、リスクを取れないということを自分もしてしまいがちです。

そういった部分が一致しているチームでないと仕事はすごくやりにくい。。。

boardは会社を経営するうえでほしいから作った

(受託IT会社の)経営者視点で開発

売り上げの予想なども出来るようにしたい

開発している自分たちがユーザ

ドッグフーディングできるか？

→自分たちが検証

本質的なニーズを探り出す

機能としては満たすが業務としてはあっていない、というようなことをなくす。

自分事なので調査がいらない。

 これがわかるのは本当に大きい。

要件の通りに作ったのに、結果として顧客の業務を円滑に進めることが出来ないということは多々ある。

顧客と常に対話できる状態ならいいのですが(そういう状態を作り出すところがアジャイルの真髄だとは思います。)

 

ドッグフーディングのデメリット

自分に最適化されすぎて、一般のユーザにとって正しくない可能性

初めて見たときの感覚を失い、新規ユーザへの配慮がなくなる

 

 

この問題の解決のために、テストやる人には詳細な実装内容を伝えず始めて使う状態でやっている。

本当はユーザビリティテストなどをやったほうがいいんだろうけど、受託をやりながら、しかも週に１度のリリースサイクルを実現しているためやっている時間がない。

サービスインして自分たちだけで本番環境を試す仕組み

 

本番環境がいちばん正確ですね

無駄なものを作らない

いついつまでというリリースポイントを決める

リリースは一週間に一回

少し足りないくらいでリリースする

最初は怖い

ユーザに言われなかったら実はいらない機能だったことがわかる。

言われたら対応することで、顧客の要望にこたえることにもなる。

 なるほど。したたかな感じ。

中途半端なかかわりのメンバーはなくす

案件の波やタスクの内容とタイミングを調整する

 

ユーザはIT業界が圧倒的に多い

会社半分くらいが2~10人

 

受け入れ中で暇だった9月のシルバーウィークに寝ずにプロトタイプを作った

欲しい機能　使い勝手　の6割くらいは9月末までに実装

10月に社内テストを実施し、2月にClose, 5月にPublic Beta

5月は受託で忙しく、製品化した8月までほとんど機能は追加していない

 何か作ったりするときにはやっぱり寝ずにやるくらいの勢いが要りますね。

 
優先度の決め方について

自分が欲しいもの

やってないことのうち　納得できるもの

声の大きい人の意見を優先しない。

全部やったらシンプルさがなくなる

boardを好きになってくれるユーザが増えてきた

そういうユーザの求める優先度もだんだん同じに

 不思議な感じがします。

 

コストかけすぎない

受託もやりながら

広報とSEOは協力を仰ぐ

汎用性はない　→　差別化

 

大事なこととして、受託もboardの開発も大きな山を作らないこと

リリースは週に1度

山があるとほかのことがとまってしまう。

開発だけやっても何にもならない。

 確かに、大きな案件に集中しすぎてしまうとほかの案件にまったく手をつけられない状態になることがよくあります。

マルチタスクにしないことも大事だと思いますが。。。

小さいタスク1週に1個

中タスク　月1個

大タスク　年1個　（大規模なリファクタリングとか）

技術的な負債の返済

 

ペースの維持

 チェンジオブペースなんて使う必要はないですね。(言ってみたかっただけ)

ロードマップは公開していて、一貫している

合議制はとらない！

 作ってるのが2人とのことですが、ダイアログのときにも出たけれどやさしい独裁者みたいな感じに思えます。

経営者視点だけで気づかないこと

  • 捺印申請の機能

期限のみ入れれるようにした

捺印申請出す側としては「上司に日付だけの申請は失礼」という意見があり、コメントを入れられるようにした。

独自の習慣などの要望はお断りする勇気を持つ

カスタマーサポートは自分でやっていて、何でやらないかをとうとうと論理づけて伝える。

 これは単純にすごいです。

 

開発ロードマップを公開することで、ロードマップがあるから使うことにしましたといったユーザも出てきた。

公開ロードマップがあることで自分へのいいプレッシャーになる

時間がない　ので　メルマガやユーザビリティテストはできない

UI, UXをがんばっていても業務にフィットしていないと意味はない。

まさにその通り、だとおもいます。広義のUXには業務にフィットすることも入ると思うけれど 

売込みをする側からこの機能がUIこれだけ使いやすくすればユーザにとってメリットがあり、使ってくれる人が増える、売り上げが増えるといったことを考えていたとしても、結局業務にあっていないと意味がないんですよね。

この辺、小さく作って検証のサイクルを速く回すといったMVP的な最適化がなされている気もします。

(ユニット)テストは後回し

最初書かないとずっと書かなくなるといわれるが、がんばって書く

リリースの規模が小さいと

  • テストが楽
  • ストレスが小さい

でも主な目的はRailsがバージョンアップしたときのテストのため。

 そのため、カバレッジはがんばってあげる。

リリース時のテストは項目は出さない

テスト項目を出すと自分の見えている範囲しかテストしない

 うっ。

私もリリース前のテストは自分が変更した部分の確認といった感じになりがちですね。

このやり方のほうがいいのかも

ここで最初のほうに出たリスク感覚の共有といったことも生きてくるのでは。

ＣＳは月100件

平均応答時間8分　即時対応

使えるだろう、と思った機能が使いにくいといったことがあるとき、反応がすぐ感じられる

サポートの実績を公開している

CS応対にはintercomというサービスを利用

固定費を最小にしている　継続のため

逆にintercomのようにこのくらいのコストは許容できるといった外部サービスはどんどん利用する

自分にあったスタンスで開発を続ける

 

 

 ダイアログも面白かったです。

チームの人数が重要ではないかという意見があり、ベンチャーなどのチームはメンバーが4人でも多いのではないかと。

意思決定はやさしい独裁者が理想。

「こういったドッグフーディングのサービス開発の導入をするにはどうしたらいいか？」

という話題には新しい技術を学ぶタイミングと、やりたいことを結びつければよいのではないかということでした。

そのために自分の欲しいものリスト(ネタ張)を作っておくことは大事です。

 

田向さん、ありがとうございました。