hiroktsのブログ

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

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人でも多いのではないかと。

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

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

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

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

 

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

プレゼンの技術 #DevKan

2015年8月15日にあったDevlove関西の表題の勉強会に参加してきました。(書いてるの１月以上後になります。)

devlove-kansai.doorkeeper.jp

プレゼンの技術 考え方編

谷本 心さん
Achroquest Technology
JavaOne /Java Day Tokyoスピーカー
@cero_t

スライド資料リンク
プレゼンの技術 1 考え方


引用部分は主にスライドにそのまま書いてあることで、ほかの文はその場で発表者の方が言っていたことや、自分の感想を含みます。

プレゼンで大切なことは何か？

相手にメッセージを伝えること

相手の行動に影響

具体的には、「そのプロダクトを使ってもらう」「勉強のきっかけにしてもらう」など。
伝わって行動を変えるということがゴールですね。

自己紹介は大切
自分のポジションを明確にする。
自己紹介で示すポジション　＝　メディア力　
「この人が入ったから説得力がある」

同じことをいうにしてもその人がどのポジションでいうことかということを明確にする　→　説得力が生まれる。

プレゼンに大切な4つのこと

  1. 共感
  2. 価値の提供
  3. ストーリー
  4. メッセージ

1. 共感
問題意識の共有

共感または共感の裏返し

相手が共感しそうなエピソードや問題を選択すること。

× Java楽勝すぎフイタ
○ Javaのここが難しい

相手に伝わることを考えるとこの辺大事そうですね。
ひとりよがりな感じにならないようにしたい。

2.価値の提供
知識の共有　→　ふーん
経験の共有　→　みんな知りたい。それつかったらどうなるの？
思想の共有　→　理解できない

必ず先に「経験の共有」をしてから「思想の共有」へ

経験の共有一番大事。
あとで出てきますが、背景知識や共通認識が異なることによって生じる理解力の差がないようにしなければならないですね。

3. ストーリー
プレゼンは映画のようなもの
聴衆の心理を的確に誘導
序破急　３部構成ぐらいがちょうどいい

全く質の異なる２つの話を１つのセッションに詰め込んだ　→　聴衆も混乱する

１番伝えたいメッセージを中核に据えて周りを肉付けするとストーリーを作りやすい

4. メッセージ

一番大事　相手に伝えたいことは何か？


せいぜい１つか２つしかおぼえてかえられない

「プレゼンターの思想」　が　メッセージ

最初からメッセージありきにする必要はない
メッセージはプレゼンを作っている間に気づいたりする

一度メッセージが明確になればそれを目立たせるように演出すれば良い

何を伝えて相手の行動を変えるか？
せいぜい１つか２つしか覚えていられない、って関係ないけどジョジョ6部思い出しますね。
1つか２つしか覚えられないから、聴衆は必死にメモを取るわけです。

まとめ

  • 序　共感
  • 破　経験
  • 急　思想

さらにプレゼンの価値を上げるために大切な3つのこと

  • 笑い

大事。
プレゼンで学ぶのではなく、プレゼンできっかけを得てそれから自分で学ぶ
刺激を受けて楽しむために、プレゼンはエンターテインメントにする必要がある。

  • 裏切り

共感からの裏切りや共感からの意外性
聴衆にとっての「新発見」が重要
共感できない考えが時には新発見になる

  • 感動

感動こそ、人を動かすもっとも大きな感情

その他、、
夜中に書いたものは思考の視野が狭くなっている
面白いと思ったものが朝見るとあれってなることも。

感想としては『「経験から得た」プレゼンターの思想を伝えること』ができて、その結果として聞いた人が何か行動してくれれば勝ちという感じに思いました。
「ふーん」にならないようにするために、大事にすべきことはまずその１点かなと。

伝えるための試行錯誤、と言うか道草

@irofさん(Java界隈のプログラマ)

自分が一番初めに出たDevlove関西のテスト自動化についての勉強会でもGebとかを使ったテストを紹介されていた記憶があります。

スライド資料
伝えるための試行錯誤というか道草。

開発者コミュニティでのプレゼンでの話をします。

一般的なプレゼンでなく、背景知識が似やすい場であるということでしょうか？

やってきたこと

練習、練習、練習

やっぱり練習大事。。

本番は次の練習
練習場を確保する

自分主催なら何してもいいじゃん
知り合いだけの場なら話しやすいじゃん

継続は力
スタイルの模索 プレゼンツール

どれも一長一短
使ってると楽しい　
とりあえずKeynoteに落ち着いている

zen いいものだ。。。　準備に画像探しで時間が超かかるのでやめ。
高橋メソッド 自分のキャラに合わない

ふりかえり

楽しいことはいいことだ
いろいろツール使ってJSやpythonの知識はつく
テキストでかけることが重要

いまんとこKeynote


プログラマ
時間あんまりない
開発者コミュニティにはなす

普段してることをはなす

プレゼンに時間かけるよりコードの１行でも書くかドキュメントの１つでも読むほうがよいものが出来る。

思っていること

ハイコンテキスト　場に合わせた話

コミュニティのプレゼンと現場のプレゼンとかは全然違う
テクいプレゼントエモいプレゼンもぜんぜん違う

解釈までコントロールしようとしない　→　軍隊を作るわけではない

「普段」の確認に良い
スライドにまとめるのは知識の再確認ができるし、

メッセージに目が向けられるとも限らない
メッセージは話者にとっては重要だけど、聴衆にとっては当たり前と思ってることのほうが重要な場合もある

おまけ：コミュニティで話したことない人へ
話すハードルを下げてみる

感想として、ツールやスタイルにこだわりすぎるのは自分も合わない気がします。
ですが、やっぱり発表の場を増やすことや練習を繰り返すことが着実に力になるとわかりました。
自分も「１行でもコードを書くべき」という意見には賛成です。（自分はそこまで実践できてないけど...。)


プレゼンの技術 実践編

再び谷本さん

スライド資料
プレゼンの技術 2 実践編

じゃあ具体的にどうすればいいの？

歴史と思想の話

ピラミッド
理　世の道理を明らかにし社会を作る額の時代
心　心を支配し、価値を作る芸の時代
知　知恵と情報の商の時代
物　工の時代
体 農の時代

1.体を鍛えて勝つ
2.用具や技術で勝つ
3.戦術・戦略で勝つ
4.心理戦で勝つ
5.知らんがな

1.操作に慣れて勝つ
2.連続技で勝つ
3.返し技を覚えて勝つ
4.心理戦で勝つ
読み合いでやる人とルールでやる人
ルールでやる人のほうが強い　読み負けた人はダメージを受ける
5.ゲームの真理で勝つ
コミュニティで勝つ

ウメハラ　このゲームとはどういうゲームなのかというのを考えている　真理を追究

最近、↓の本買いました。
格闘ゲームの場面展開はものすごく速いけど、このゲームとはどういう(どうすれば勝てる)ゲームなのかという「視点」を大事にして戦う、自分をビルドアップすることの大切さが書いてあります。
谷本さんも読んでるかもしれないけどどうなんだろう。www.amazon.co.jp

プレゼンも同じ
さっきまでのはほとんど知のフェーズ
笑い、裏切りは心のフェーズ

体と物は？

1. 体のフェーズ

練習しろ
発表

大事なプレゼンのときは社内で３回くらいリハーサルしています

CA Tech Kids
むちゃくちゃプレゼンがうまい小学生

毎週、テンプレート通りの簡単な発表を繰り返す
３ヶ月に一度、親も読んで大きな発表をする

アドリブでなく台詞は全て暗記

プレゼンだけでもうまくなるにはこうした練習が必要。
考えてみれば当たり前のことだけど...。

TPOと自分に合ったスタイルで
Zenスタイル
印象がよく伝わる　xむっちゃ時間かかる

こんな風に話したいという目標を見つける
憧れではなく目標で

マインドマップ書いてますか？

プレゼンの構造とマインドマップは抜群に相性が良い
発散　整理　構造化

物事を発散させる思考プロセス　→　マインドマップ

マインドマップで薄いところをあとから広げるのは不可能
知らないことを無理やり調べながら書く必要はない
本当に自分が話せることを話そう

プレゼンの秘訣は「仕事を頑張ること」

すごくいい仕事をしたり、すごく悩んだりしたこと

「誰」に向けて話す = コンテキスト

ハイコンテキスト
１を聴いて１０を知る

ローコンテキスト
１をきいて１を知る

もっと低いローコンテキスト

背景知識や共通認識が異なることによって生じる理解力の差

プレゼンを聞く相手に合わせて共感の内容と説明の厚さを変える

心のフェーズ

プレゼンターよ、芸人たれ

プレゼンは脚本でプレゼンターは役者です

自分が好きなストーリーを脚本に

笑点の前半を参考にしよう

プレゼンを聞く相手に合わせて共感の内容と説明の厚さを変えるというのは、逆のパターンで言うとirofさんのいっていた「自分主催なら何してもいいじゃん」というやつかなあと思います。
話すのを背景知識の共有が出来たハイコンテキストの場に限定してしまえば、敷居は低くなると思います。
何も博愛主義的に聞きに来る人みんなが大事、というよりも本当に伝えたい層限定に伝えるほうが楽かな、、とはおもいます。
プレゼンの秘訣は「仕事を頑張ること」、まさにその通りであってほしいところです。
プレゼンの資料を作るタイミングが逆に自分の仕事を振り返るタイミングにもなるそうです。
その振り返りで自分の仕事がきっちり出来ていなければプレゼンの質に影響しそうです。

谷本さん、irofさん、ありがとうございました。

『クラウド時代のエンジニアの役割〜AWSを使い続けて気づいたこと〜』#DevKan

2015.07.24にあった表題のDevLove関西の勉強会に参加してきました。

クラウドがアーキテクチャを変え、エンジニアの役割も変わる

佐々木拓郎さん　NRIネットコム株式会社

www.slideshare.net

概要

クラウドファーストからクラウドネイティブへ
オンプレミスの提案だけだと「なんでクラウドの提案もないのか？」というようなことを訊かれるクラウドファースト時代になってきている。
データとその処理をサーバで変換する必要があった3-Tierのクラウドアーキテクチャから、データやストレージまたは計算処理(Lambda)に対して直接操作ができる2-Tierアーキテクチャが実現されつつある。

サーバの構築がほぼ不要で、パーツの組み合わせだけでサービスの構築が可能

Lambdaで計算処理はサーバレスでできるようになったが、APIとして利用するためにはサーバが必要だった。。。

Amazon API Gateway
が、「Amazon API Gateway」がLambdaやAWSの各サービスをHTTP/sのProxyとして呼び出せるAPI作成支援サービスとしてつい先日登場した。
とんでもないインパクトで、フレームワークの登場とにている→コードを記述する量がとんでもなく減る

クラウド時代のエンジニアの役割について

インフラなども含めてコード化できることが必須かつ、コード化される範囲が広がるので、その上に何を付加できるのかといったアーキテクチャの知識も必要になってくる

赤魔道士的な立ち位置
黒も白もつかえる器用貧乏　→　クラウドという強力なアイテムがあると何倍も力が増幅される？

ガチガチではなく、変化を楽しんで対応出来る能力を身につけよう

アプリエンジニアからクラウド専用のインフラエンジニアになってみて

佐藤瞬さん　NRIネットコム株式会社

www.slideshare.net

概要

AWSを触り始めて感じたのは、ドキュメントや手厚いサポートなどの「情報量の多さ・取得のしやすさ」
つまったのは、ネットワーク周り
ほとんどがプログラマブルに構築できる　→　コードか必須になってきている

AWS構築のコード化

CloudFormation　便利。テンプレートのJSONつらい　（たしかにそう。。。）

kumogataでCloudFormationのテンプレートをrubyで記述

OSミドルウェアの構築

  • Chef　クライアントが必要
  • Ansible Yamlがつらい

そこでItamaeです。ChefとAnsibleのいいとこ取り

デプロイのコード化
fabricとのこと。なぜcapistranoではないんだろう？

運用のコード化
hubotとslackでChatops。セキュリティの観点からあまり深いことはやらせていない

こちらの発表でも「API Gateway」の衝撃について触れられてました。
「楽しそう。でもインフラエンジニア廃業かな。。。」

これからのサービスの構築

まずサーバレスで構築（フロントエンド/モバイル+API Gateway/Lambda)

サーバレスでは厳しい面について、EC2上にアプリケーションサーバ

  • ユーザ認証
  • RDSとの接続
  • クローズドなネットワーク

インフラエンジニアとしては、EC2上にアプリケーションを構築する上で、何がサーバレスで問題だったのか、どうやったら解決するか、アプリケーションにはどのような要件が必要かという現状を把握できることが必要。

感想

クラウドファーストだけでなく、クラウドを徹底的に活用すること前提の時代もすぐそこまで来ているのだなーと感じました。
自分はアプリエンジニア寄りなので、APIgateway及びLambdaは早く触らないといけないと思います。
Dockerの勉強会でも言われていましたが、技術に依存してしまうのではなく変化を楽しんで適応する能力が一番重要だとのことでした。
そのためにはどの方向から攻撃が来ても受け流せる猫足立ちを身につけないとですね。
インフラエンジニアでもフロントエンドを勉強し始めているとのこと。
ほんとに隣接した領域の知識も必要になってきている感じです。
お二人ともありがとうございました。
とりあえず紹介されていた本買ってみよう。

『自分戦略〜エバンジェリスト編〜』#DevKanに参加してきました。

2015.04.18に行われた標題のDevLove関西の勉強会に参加してきました。

スライドは公開されていない発表もあったため、今回は感想だけです。

長沢智治はなぜエバンジェリストになってしまったのか？なぜやり続けるのか？

長沢智治さん

感想

ベルトを巻いておられます。　ディケイドの模様
エバンジェリストは製品中心と思い込んでいましたが、顧客・企業・製品のバランスをとっていくということが大事ということになるほどと思いました。
エバンジェリストである以前に、「現場自身が変わる能力をもたせたい」という目的のために行動しているという感じを強く受けました。
そのためにもっているエバンジェリストとしての武器として、「その気にさせる」影響力、「コミュニティ・市場に通りすがって助ける」行動力が大事なのかなと感じました。 キャリアとしてエバンジェリストを考えた時に、その元となる熱意・モチベーションと自分の行動・成果を管理するためのマネジメーントの能力を兼ね備えていないと続けていくのは難しそうだと感じました。

「#てらだよしおがんばれ」　の誕生秘話について

寺田 佳央さん

感想

プライドと意地、大事だと感じました。
謝罪会見になってしまったというお話については、渦中に飛び込んでみて正直に伝えるということをやってみることで成長に繋がっていくというストーリーが伝わってきました。
悲惨な状況から、JavaOneTokyoを必死に成功に導いたときの男泣きの写真がかっこよかったです。

エバンジェリストに必要なのは
「覚悟と情熱」
『「**」にたいしては誰よりも一番愛していると思えること』

そういう覚悟や情熱を得られるのは、長沢さんもおっしゃられてたように正直に技術やコミュニティに向き合っているからだと思います。

「モノづくりのとマーケティングのはざまからエンジニアの役割を考える」

染田 貴志さん

感想

「染田、エバンジェリストやめるってよ」という出落ち！

起業してCTOになったときの「対価を得ることの難しさ・大切さ・売り上げが０になっていることは辛い・悔しいという原体験」からくる覚悟・熱意というのが非常にインパクトが大きいと感じます。
自分もそういう覚悟・熱意というものを何とかして得たいです。 ヌーラボに参画してからはモノづくりの目的が「少しでも世界をよりよくする、だけではだめでその結果、自分たちも幸せになる」という風に変わり、エンジニアリングとマーケティングのアンバランスの解消を手伝うためにグレーゾーンに踏み込んでいく、そのためのエバンジェリストというお話でした。
エバンジェリストというロールをやめたとしても、エンジニアとマーケティングの橋渡しをしていくことを続けるそうです。
うちの会社でも「ビジネスを考える人と開発をする人が日々一緒に働く」ということの大事さが骨身にしみています。 エンジニアリングのこともわかってくれているPOの案件では非常に仕事がやりやすいです。
そういう架け橋をかけてくれるのはとても大事だと思います。

『コミュニケーションツールと“持ち寄り型”プロジェクトマネジメント』#DevKanに参加してきました

2015.04.11にあった表題のDevLove関西の勉強会に参加してきました。

ポエム駆動開発エンタープライズ

こしば　としあきさん　ピクシブ株式会社

Poem Driven Development Enterprise // Speaker Deck

今回のテーマ：再現性を作りたい

元になった考え
ポエム駆動開発によるWebサービスの作り方pplog

ポエムとは： サービスを開発する上での思い サービスを開発する前にポエムを書くこと。 開発で迷ったらポエムに立ち帰る。 設計内容のドキュメントというような堅苦しい話ではなく、開発のコンテキストを共有したい。

『ピクシブ株式会社のビジョン・ミッション』
創作活動がもっと楽しくなる場所を作ること

ポエム駆動開発「エンタープライズ」
エンタープライズであることによる違い

  • 情熱を大事にはするが、経営資源の投入を行うので「ほかをやらない理由」を書かなければならない。
  • 「人をよこせ　サーバーを使うぞ」といった要求が飛び交う。
ポエムから起ち上がるプロジェクトの実例

pixivチャット：
メンテされない。塩漬け状態。やめようという話になっていた
数人がpixivチャットにかける思いをポエムに書き始めた

『pixivチャットをやめるのは良くないと思います』というポエム
→ 肉付け: 何人がどれくらいでどういうものを作ります

結果としてポエムをきっかけとしてサービス改善として開発することになり、開発計画もポエムからできた。

pixivでの開発について

開発スタイル：アジャイル
エンジニア勉強会を行っている

ある日、開発の天啓を得る

  • 計測結果
  • お問い合わせ
  • 世の中の趙声

天啓は揮発性が高い: 飲み会　含む　普段の会話

なぜポエムか？
  • 日報　その日のことしか書けない
  • ビジネス文書　エモいことを書けない
  • チャット　流れてしまう

オフシャルな形でポエムプラットフォームを導入
ドキュメント共有ツール＞esa

結果：

  • 議事録などもポエムで書かれるように
  • 参加していないメンバーでもわかりやすくなった
  • ポエムを通じていろんなプロジェクトが持ち寄られる状態になった
  • 社内のサービスはリリース後も開発者以外も触ってみて感想を書かれるようになった

導入のためにやったこと

  • オフィシャルなプロジェクトとしてesaとポエムの導入をきちんとプロジェクトとしてたちあげ
    コミュニケーションツールの炎上　導入には慎重になっていた
  • ツールの意図の説明
  • 理想の利用者を演じる
  • 意図と違う使い方を黙認

してないこと

  • カテゴリー分け
  • 細かいルール策定

社会活動を起こす方法を参考にする。→ハブみたいな人が乗ってくれた

感想
プロダクトやサービスにかける思いなどは確かに共有することは難しいです。
自分の会社では週報の所感として、そういう思いを書くことはありますが、それが他の開発をしている人などには伝わっていないのでもったいないなとおもいました。
ポエムという形で、設計というような堅苦しい話ではなくほかのチームやメンバーの開発がどういう思いでプロダクトを作っているか共有するのは素晴らしいと思います。
そこから実際のプロジェクトの起動までつながるのがちょっと想像の範囲外でした。
ちゃんとしたプロジェクトとしてポエムやesaの導入をやっているのでトップダウンな面もあり、ポエム自体の布教というボトムアップな面もあり、といったことがコミュニケーションツールとして幅広く受け入られた理由だと思います。
参考にしていきたいです。

ストック型＋フロー型ツールで周りを巻き込んで導入した話

株式会社TAM 白石 尚也さん

コミュニケーションツール

ストック型 Qiita Team, DocBase, esa
フロー型 Slack

今回はDocBaseを導入した話

導入前に困っていたこと

やっている仕事はパートナー型デジタルプロダクション 。 お客様とタッグを組んでPDCAを回す。

  • Web連携CRMSalesforce連携開発の受託開発業務

社内では誰もやっていないことをチャレンジする案件がほとんど。
必ずはまるポイントがある。

お客様満足度　品質を追求
昼夜を問わず働くことも。

疲弊しない受託開発をするためにチーム力向上を図る

自分がはまったことは必ず他の人もはまる。
どうやって解決したかを共有し、他の人が同じことではまらないようにしたい。

ストック型のコミュニケーションツールを使ってみよう

導入のコツ

  • １個目の壁 どのツールを使ったらいいのか

  • ２個目 リーダーを説得するために、どうしたらいいのか　決裁

  • ３個目 どのツールがいいのか？

Qiita Team : Qiitaが有名
esa : デザインがかわいい
DocBase : シンプル

エンジニアじゃない人が大半のメンバーである中で１週間ずつ試用してみた。

Qiita Team

機能は一番豊富だが、プロジェクト・タグ・メンバーから記事が探しにくい。
エンジニアじゃない人が多いため、マークダウンなどに馴染みがない。
投稿ボタンの場所がわからず投稿できなかった（解像度の問題）

esa

女性に好評　かわいい。
なぜ英語？直感的に使いづらい。
カテゴリやタグ付けがわからない。
WIPの意味がわからない　インターネットカフェ？

DocBase

シンプルでわかりやすい。 エディタ機能でMarkdown出なくても描きやすい。 投稿ボタンも見える。 メニューから記事が探しやすい。 自分の活動、ほかの人の活動が見えやすい。

リーダーの説得を行い、DocBaseの導入を少人数(3人)でスタート

振り返りでわかったこと

  • 何をかいてよいかわからない
    →　暗黙知をつくるな、すべてを形式知にかえよ
    全部をドキュメントに変えよう。
    誰か一人が知っているではなくて、全員が知っている状態にしよう

  • 投稿を通知して読んでもらう仕組み

  • 読んだということを知らせるために　いいね　や　コメント
  • あのコメントを書いた人ならもしかして知っているかもということからコミュニケーションが取りやすくなった。

課題：

  • 記事の精度
  • タグ煩雑になりそう　タグの運用はどうすれば

やってよかったこと

  • やりたいことがある人は少人数で試してみる
  • どんなことでも残っている安心感が得られる

感想
うちの会社ではAtlassianのConfluenceをドキュメントベースの情報共有に使っていますが、使っているのはまだエンジニアがほとんどだと思います。
エンジニアじゃないひとに情報共有の仕組みを広めていくためには、Qiita Teamやesaを試用してみたときの課題が大変参考になると思いました。
投稿を通知して読んでもらう仕組みに関してはまだまだできていないのでこれから考えていかなければと思います。
「あのコメントを書いた人ならもしかして知っているかもということからコミュニケーションが取りやすくなった。」というのを実現していきたいです。

SlackをTAMに導入した話

株式会社TAM CTO 松尾 浩志さん

Slackとは
  • Flickrが作ったチーム向けチャットツール
  • 同じドメインを持ってる人だけがチームに入れる　他は招待制
  • UIがいい　
  • 少人数以外は有料制

既存のコミュニケーションツール：メール・チャット(Skype)
Skypeプライベート　クローズドなツール
グループチャットをすると他のメンバーには存在すらわからない。

Slack導入に向かった経緯
  • ふわっとした情報の共有がしたい。
  • 便利なショートカットがあった
  • Wordpressのプラグインがある
  • あれはバックログに書いた　あれはチャットに書いた　という状態をなくしたい
  • GitHubなどの通知がタイムラインに流れてくる
  • さわってみて　これいけてるという感じがあった
チャンネルのタイプ
  • 全員が参加するオープンなチャンネル
  • 誰でも入れるオーブンなチャンネル
  • クローズドなプロジェクト単位でのチャンネル
  • 一対一のチャンネル
導入してみて
  • デフォルトで通知の設定が簡単にできる。
  • heroku jenkins githubとの連携が簡単。IFTTTも活用
  • Slackの画面をみていると情報が集まるようになってきた
Hubotの活用　ChatOps

Javascript (Node.js) + Herokuで手軽にOK

コミュニケーション上の工夫

どうやって使ってもらうか？

導入時のみなさんの反応タイプ

  • 新しいもの好き、積極的　少数派
  • ツールは特になんでもいい　多数派
  • めんどくさい・・・　多数派
  • 絶対イヤ　　　　　　少数派

導入の障壁を壊すために
和む雰囲気をつくる。
お堅い雰囲気だとなかなか浸透しない。 業務外のチャンネルを作って、好きそうな人を招待。
例：今日飲みたい人のチャンネル

TAMくんbotがなごませ要員

  • 定期的に投稿
  • 人の話に反応
    お昼　〜が食べたい　ビールが飲みたい
  • 画像を検索：　Tamくんimage 「明日も勝つ」

「質問たらい回し作戦」 誰かが全体に質問する。
誰も答えない・・・
→　このままだと質問してくれなくなる

答えがわからないときは、中継して他の人に聞いてみる　メンション

Slack導入してみて

「持ち寄れる下地」がやっとできた。
全社メールしかなかったら質問ができなかった。
「良い仕組み」を持つツールがフィットすると仕事の流れが予想以上に良い方向に変わるケースもある。
遊び要素、和み要素が重要
仕組みを作った　はい終わりではなくコミュニケーションを活発にしていく努力を継続的にしていく必要が有る

感想：
「Slack羨ましい。使ってみたい」という気になりました。
興味を持ってくれそうな人、積極的に使ってくれる人をハブにするのと、継続的に使ってくれるように努力していくことがコミュニケーションツールの導入には大事だなと感じました。
とくに、チャットルームに仕事に直接関係すること以外の「部活」「今日飲みに行きたい人」などを用意することや、botに面白いリアクションを返させるなどの和み要素を設けることはうちでは全然できていないので参考にしていきたいです。

『農業の「現場」から生まれた業務改善サービス「houren.so」の話を聞いてみる』#DevKanに参加してきました

2015.04.10にDevLove関西の表題の勉強会に参加してきました。

www.slideshare.net

株式会社日本情報化農業研究所 農業技術部部長　齋藤 毅さん

houren.soとは

体を動かして作業する人がいる現場のツール・グループウェア 何かの作業をした後、画像を投稿することで、誰がいつどんな作業をやったか報告できる

植物学「低コストの栽培技術をまとめる」 というところから　プログラミングの道へ

なぜこのアプリが開発されたのか？

研究のための農作業の日報

  • 報告する側
    農業で１日作業すると疲れきっている。 会社への報告を業務アプリで書いていたが、疲れすぎた状態で日報を書くのはツライ。 しかし、報告しないとサボり扱い。。。

  • 報告される側
    面倒なので読まないが提出だけはチェックしている

夜、無理をして作業日報を書く　→　睡眠不足　→　翌日の作業が危ない！
怪我や命にかかわることも多い

作業ブログ　→　事細かく書くように要求されているため「メモ」が必要
だが、メモを残しづらい

  • 雨が多過ぎる気候　→　メモ帳はすぐ使い物にならなく
  • 寒いときは手袋を外したくない
  • 農薬散布はフル防護服　（散布する人は超危険）

なんとか簡単に情報を伝えることができないかと、試しに作業時に写真を撮って熟練者に見せてみた。

  • 作業前、作業後、使った機械
    写真を見たら作業した面積がわかる

仮説：大事なことは写真だけで大半が伝わるのではないか？
→　Exifの情報を並べるだけで十分な日報に

検証：写真による報告の効用

  • Webで販促を行っている　とにかく写真が欲しい
    例：トマトが熟している写真が欲しい　→　報告で使っていた写真を検索で使う
  • 報告以外でも、農業の作業場の風景などをなんとなく写真に
    →そのまま栽培の教科書に
  • 報告はテキストより写真のほうがわかりやすいことがわかった
  • 農業では写真を活用する文化がまだなかったが、活用方法は多岐にありそう
  • Exif（撮影日、GPS）があるので、後日投稿でも質が落ちない
    →　雨の時にまとめて送信など
  • 相談も写真があればわかりやすい
    熟練者が見れば、畑の画像などから『「この色のおかしい箇所」はなんだ？』というところから、実際にはカビがあるということの発見につながる。
    →　画像でノウハウなどの弱い共有ができる

設計：
* 写真と日付　を　グループ単位で　クローズドに投稿する * シンプルで便利にする * 狙いは、写真の投稿者の負担をかけず、投稿のハードルを下げるため * 時系列のまとめ機能 * 投稿者はほとんど情報を持たず、グループがもつ情報がほとんどにする

投稿するだけで報告になるというUX主眼の機能設計

検索の仕方

  • タグで検索
  • 月で検索　：　７月　→　トマト
感想

開発の話について、以下のことがすばらしいとおもいました。

  • 開発までいたるプロセスとして、きっかけがあって仮説をたて、それを最小限の単位で検証している
    MVP的なアプローチ
  • 完全にUX主眼の設計になっており、デザイン主導になっていない

houren.so自体は、目視確認を行う作業がある現場は農業以外でも様々な場面で活用ができそうです。