Getting Real 輪読会

# Getting Real 輪読会 ###### tags: `Getting Real` ## 各種リンク - [Getting Real](https://basecamp.com/gettingreal) - [日本語訳](https://bootcamp.fjord.jp/pages/35) - [単語帳](https://hackmd.io/2mnWn3MHQ4SSbuKMk_OrCQ) - [第60回まで](https://hackmd.io/9ebP1r19THyPTPGbAsg8Jg) * * * ## 【第105回】 ### 開催日 4月10日（月） ### 今回 CHAPTER 91: Start Your Engines You need people who are passionate about what they do. から https://bootcamp.fjord.jp/pages/35#-259 ### 次回 ### 今日の要約 - 情熱があり、自分の作品にこだわる人が必要です。 - Getting Realの考え方はソフトウェア開発の領域にとどまりません。 - 以下、制約を設けることによってかえって価値を生み出した様々な例を列挙 ### 各自メモ - hikaru - 読了〜！お疲れ様でした:tada: - 人が大事 - 制約を設けたり無駄を省いたりして、とにかくGetting Realすることでうまくいく例がたくさんある - 早く世に出して早く失敗することでより良くしていく考え方が大事だな〜 - もっと英語読めるようになりたいですねー - @niikz - かんそう！！！ - Web App をつくることに熱中する人が必要 - Getting Real のコンセプトはソフトウェア意外にも有効 - 具体例がむずかしすぎた😂 - 英語を読む抵抗感がなくなってよかった - @kasai441 - アメリカ人の常識が何一つわからないことがわかった - シェイクスピアの詩のくだりは575で読む俳句みたいなものかなあ... - 英語勉強会たのしかったです！ * * * ## 【第104回】 ### 開催日 4月6日（木） ### 今回 CHAPTER 90: Go With The Flow から https://bootcamp.fjord.jp/pages/35#-254 ### 次回 CHAPTER 91: Start Your Engines You need people who are passionate about what they do. から ### 今日の要約 - 流れに乗ろう。ウェブアプリは運用しながら常に調整や変更をしていくものである。最初のアイディアがベストなものとは限らない。 - 成功のカギはうまく実行できるかにかかっている。デザイン、コーディング、プロモーションなどをバランスよく実行しよう。 ### 各自メモ - hikaru - やりながら試せるというのがソフトウェアの良いところ、この精神を忘れずにいきたい - 実行しないと意味ない - ブログは誰でも書けるらしい... - 技術ブログ書かないとなー - @niikz - 最初つくっていたものと違うものがうまくいきそうだったらシフトチェンジしてビッグウェーブに乗る - 成功は素晴らしい実行にかかっている - デザインやプロモーションなどのバランスも大切 - 個人開発でサービス運営している人は本当にすごい - 成功するWebアプリで重要なのはやっぱり人 - @kasai441 - Flickrがあやしげなゲームのサイトだったというのは非常に好感が持てる - 3Mが最初は鉱山の会社だったのに今はポストイットを作っていたり、IBMがPCの製造をやめてソフトウェアに特化するようになったり、こういう話はとても好き。長い目で見ればWEBサービスに限らないとは思う。 - FBCの自作サービスは最初のアイディアを強固に固めていくので、ちょっとベクトルが逆かも。 * * * ## 【第103回】 ### 開催日 4月3日（月） ### 今回 CHAPTER 89: Beware the Bloat Monster から https://bootcamp.fjord.jp/pages/35#-252 ### 次回 CHAPTER 90: Go With The Flow から ### 今日の要約 - より成熟したサービスがより複雑になる必要はない - 同じものを売るわけにいかないという理由だけで新しい機能が追加されてしまう、それが膨張の原因となる ### 各自メモ - hikaru - 機能を盛り沢山にすればいいってわけじゃない - 買い切りサービスだと新たに買ってもらうために新機能の追加が必要で、それがプロダクトの巨大化につながっている - サブスクサービスは使用料を払ってもらうために価値の高いサービスを提供し続ける必要がある - サブスクってこの頃からあったんですね...！ - @niikz - 成長することと複雑になることは異なる - 毎年新しいバージョンを購入するものよりもサブスクリプションスタイルのほうが開発者としてもユーザーとしてもよさそう - @kasai441 - とくに需要とか機能の必要性がなくても、目新しい話題とか商業上の売り文句のために機能が追加される、ということはありそう。 * * * ## 【第102回】 ### 開催日 3月30日（木） ### 今回 CHAPTER 86: All Bugs Are Not Created Equal And remember what we said earlier about the importance of honesty. から https://bootcamp.fjord.jp/pages/35#-247 ### 次回 CHAPTER 89: Beware the Bloat Monster から ### 今日の要約 - サービスのアップデートに対する最初の反応はしばしばネガティブで感情的なものである。即座に反応するのではなく、十分な時間をおいて理由付けのされた応答をすべき。 - 最新の情報を追いつづけよう。自分のサービスに関してだけでなくライバルのサービスについてのニュースもチェックしよう。 ### 各自メモ - hikaru - 正直でいることが大事...確かに隠されたものを察せちゃうよりは正直に説明してくれた方がいい - おちつけ - 否定的な意見にのみ耳を傾けているだけかも？と思うのが大事。賛否両論でも必要な決定であれば覆さない - 競合の情報収集は欠かさずに - 最近FBC生のブログを追うためにRSSが欲しい - @niikz - すぐに対処できなくてもバグについて正直に説明することが大事 - 条件反射的に反応するのはよくない。24〜48時間たてば落ち着く。 - インターネットの情報はあとからでもよく燃えてる気がする… - 否定的な意見は大きくきこえる - トラブルが起きたらお問い合わせフォームに連絡するけどポジティブなフィードバックをする場所もほしい - @kasai441 - 感情的な判断は理由が後々分からなくなるので、きちんと客観的に言語化できるまでは外部への発表は控えるべきとは思います。 - 相手からの意見についてもそれが感情的かどうかで対応を変えた方がよさそう。 * * * ## 【第101回】 ### 開催日 3月27日（月） ### 今回 CHAPTER 84: Keep the Posts Coming It’s Alive から https://bootcamp.fjord.jp/pages/35#-241 ### 次回 CHAPTER 86: All Bugs Are Not Created Equal And remember what we said earlier about the importance of honesty. から ### 今日の要約 - 開発ブログを頻繁に更新することで生きているサービスであることの証になる - ベータサービスを言い訳にせず、自信のあるサービスを「正式リリース」しよう - バグに優先順位をつけて、重要なものから取り掛かろう ### 各自メモ - hikaru - 更新されなくなったブログってなんか寂しいですよね - アルファ版なんてのもありますよね - あれはそもそもフィードバック前提のPrivateなものに近いかも？ - ベータ版を置かずにリリース版と銘打ってなんかあったら責任を取れ - 厳しい... - バグに優先順位をつけよう。破壊的なバグでなければ一旦置いておける。文化を感じる - @niikz - たしかに開発ブログが放置されていたらサービスがもう動いていないように感じる…… - 「リリースしました！」ってちゃんと言うこと - ベータ版は限定公開とかだったら問題ないのかな🤔 - バグに優先順位をつけましょう。致命的なものでなければとりあえず置いておく - @kasai441 - ベータサービスを公開してやらないようにした方がよいのは、バグを放置する言い訳になるから？ちょっとアジャイル開発の章と矛盾してしまうところがあるような... - ゲームのベータ版は抽選で有志のユーザーに限定してテストしたりしている * * * ## 【第100回】 ### 開催日 3月23日（木） ### 今回 CHAPTER 84: Keep the Posts Coming から https://bootcamp.fjord.jp/pages/35#-239 ### 次回 CHAPTER 84: Keep the Posts Coming It’s Alive から ### 今日の要約 - リリース後も記事を書き続けてプロダクトが動いていることを示しましょう。 - 自分を大きくみせないで顧客と親しい距離で接し続けましょう。 ### 各自メモ - hikaru - リリース後もフレンドリーにブログ書きましょう！ - @niikz - リリースの1回だけでなくその後のアップデートについてもブログを書こう - フレンドリーなトーンで - 自分を大きくすごいプロフェッショナルのように見せる必要はない * * * ## 【第99回】 ### 開催日 3月20日（月） ### 今回 CHAPTER 82: Publicize Your Screwups から https://bootcamp.fjord.jp/pages/35#-235 ### 次回 CHAPTER 84: Keep the Posts Coming から ### 今日の要約 - 悪いニュースは即時公開し、良いニュースは小出しにしよう。 - 30日以内にメジャーアップデートをしよう。アップデートを前提としてリリースを行えば、よりコアな機能を完璧に作り上げることに注力できる。 ### 各自メモ - hikaru - 失敗はあえて公開した方が良い、それも一度に全て、勇気がいるなあ - コア機能だけまずリリースしてその後のフィードバックをもとにすぐにアップデートを追加する - アジャイルっぽい話だな - @niikz - 悪いニュースは一度にすべて、良いニュースはゆっくり少しずつ出す - リリース初期のアップデートを機能追加ではなくコア機能の完成度を高めるのは効果ありそう - @kasai441 - SNS以前の文なのに今でも通じそう。 - 一次ソースに触れる人と2次三次に触れる人とちがうので - うれしくてもいいニュースは小出しにした方がよいのは、あるかも。プロモーションのとこでもハリウッド式というのが同じやり方だった。 - 悪いニュース発表するの勇気いるなあ - https://japan.cnet.com/article/20125847/ * * * ## 【第98回】 ### 開催日 3月13日（月） ### 今回 CHAPTER 79: Answer Quick This does not mean that your product から https://bootcamp.fjord.jp/pages/35#-230 ### 次回 CHAPTER 82: Publicize Your Screwups から ### 今日の要約 - いろいろな要求があったとしてもサービスをシンプルにするということが唯一のの要求であるコミュニティがお互いに助け合う状態を大事にしよう ### 各自メモ - hikaru > As a software development company, you have to act as a filter. - すごい！尊敬！ - ユーザーからのフィードバックがあるとそれを（なんでも）製品に反映させるのが仕事だと思ってるPOもいたりするのでシンプルに保つっていうのは難しい。これはもうPOのセンス次第なんじゃないかな - 顧客同士で助け合ってもらうっていいですね。製品にファンがいるってことですね - @niikz - マーケットの7％見捨ててもIEを切った - 顧客の要望全てを聞き入れない。ノーと言う。 - 開発者が間に入らずにオープンなコミュニケーションの場をつくってフォーラムやチャットでお互いに助け合う - とてもいいコミュニティ - Supportセクション全体的に開発者は顧客に助けてもらい顧客もお互いに助け合おうみたいな話だった - @kasai441 - Ruby会議出席しようかなぁ... - そろそろ次に読む文献は何がいいか考えている... * * * ## 【第97回】 ### 開催日 3月9日（木） ### 今回 CHAPTER 79: Answer Quick から https://bootcamp.fjord.jp/pages/35#-228 ### 次回 CHAPTER 79: Answer Quick This does not mean that your product から ### 今日の要約 - 素早く返事をすること。誠実にすばやく返事をすると顧客は喜びます。 - An army of many. 顧客の力を借りれば少人数でも大きな企業に挑むことができます。 ### 各自メモ - hikaru - 素早くて率直な回答がユーザーを味方につけるためには大事 - イーロンマスクに聞かせたい - コミュニティの力を借りて少人数のチームで巨人と渡り合う - @niikz - すぐに何かしらの返事をするのは最も優先される - 小さいチームでも顧客の力を借りてバグ報告を受けたりサービスの拡散ができる - 開発者との距離が近くなることでより協力的になる人はいそう - @kasai441 - たしかにすぐに回答すると喜ばれるとは思うけど、サポートでバグとか不具合とか操作ミスとかの原因や解決をすぐにすることがとても難しそう。 - 90分以内に90％のメール問合せにこたえる - とても優秀... - 最近はチャットでのサポートがある場合はチャットでやると一番簡単だなあと思っています。 * * * ## 【第96回】 ### 開催日 3月6日（月） ### 今回 CHAPTER 77: Feel The Pain At Basecamp, all of our support emails から https://bootcamp.fjord.jp/pages/35#-225 ### 次回 CHAPTER 79: Answer Quick から ### 今日の要約 - サポートを開発者にさせることで、ユーザーと開発者の間に入る人をつくらないようにしよう - インラインヘルプやFAQを効果的に使って、ユーザーの疑問に先んじてこたえよう。それによって問合せ件数も減らすことができる。 ### 各自メモ - hikaru - エンジニア目線で言うと、良いプロダクトを作ることが仕事のはずなので利用者のフィードバックを遠ざけてしまうのはあんまり良くないと思う、W/Fは知らんけど - どういうつまづきポイントがあるのかは作っているうちにわからなくなるな〜と思いました - https://www.1101.com/iwata/2007-09-03.html - @kasai441 - 自作サービスではヘルプは結構作るのが大変だった。自分ではわかりきっている機能についてユーザーがどのあたりで詰まるのかを的確に知るのはなかなか難しい。たぶん、アジャイル開発によってもっとも恩恵を受けそうな部分かも。 - FAQ - Frequently Asked Questions - @niikz - 開発と顧客の間の仲介者をなくそう。サポートと開発を分けずに顧客の不満や提案を聞くことは本当に可能なのかな〜🤔 - サービスやユーザー層によってどのくらいヘルプを充実させるかバランスが難しそう * * * ## 【第95回】 ### 開催日 2月16日（木） ### 今回 CHAPTER 77: Feel The Pain It’s important for both sides から https://bootcamp.fjord.jp/pages/35#-225 ### 次回 CHAPTER 77: Feel The Pain At Basecamp, all of our support emails から ### 今日の要約 - レストランでは厨房とホールの間に認識の壁ができやすいため、シェフがウェイターとして顧客対応することで客の声を知る機会を設けることがよくあります。 - 同じようにソフトウェア開発においては、開発・デザインチームとサポートチームの間に分断が起きます。解決策としては、サポートをコールセンターなどに外注せず、顧客の声は開発チームが直接知って理解することが大切です。 ### 各自メモ - hikaru - 縦割り行政の弊害はユーザーに押し付けられているんですよ！！ - システムを納品して終わりっていう従来のSIer的ビジネスモデルから脱却しているのがWeb業界の良いところだと思います - もっと事業会社にエンジニアがいる必要がありますよね。DevOpsがもっと広まってほしいです。 - @niikz - **Don’t outsource customer support to a call center or third party.** - Do it yourself. - 個人開発だと直接顧客の声を聞く機会はありそうだけど大きな組織はどうやってるんだろう🤔 - お問い合わせフォームとかをおくとネガティブな意見ばっかり届きそう… - @kasai441 - 医療システムの保守をしていた時は、開発チームとの交流はほとんどなかったかも。要件として機能のバグや改善要求は伝えていたけど、人間的な感情は極力排除していたような気がする...。 * * * ## 【第94回】 ### 開催日 2月13日（月） ### 今回 CHAPTER 76: Name Hook And don’t sweat it if you can’t get から https://bootcamp.fjord.jp/pages/35#-222 ### 次回 CHAPTER 77: Feel The Pain It’s important for both sides から ### 今日の要約 - ハイテク産業になじみのないお客さんを怖がらせないキャッチ―でわかりやすいサービス名を付けましょう - サポートと開発の壁を取り払おう ### 各自メモ - @niikz - 覚えやすいネーミングにしたほうが売り上げがあがる。名前ひとつでとっつきやすくなる。 - ドメイン名もインパクトあると覚えやすい気がする - @kasai441 - ドメインが取れないという心配をしたことがないけど、たしかにxxx.comのような短いドメインだとかっこいい - 狭いサークルの中で受けそうな名前ではなく、なじみ深い名前を付けるのはセンスが必要かも。 * * * ## 【第93回】 ### 開催日 2月9日（木） ### 今回 CHAPTER 75: Inline Upsell から https://bootcamp.fjord.jp/pages/35#-219 ### 次回 CHAPTER 76: Name Hook And don’t sweat it if you can’t get から ### 今日の要約 - アプリ内でアップグレードしたりさらに高機能なプランがあることをユーザーに常に告知しましょう - 既存の顧客にさらに売り込むのは「うまい」方法です - 名前でひきつけよう - 一般的な名前は覚えにくい - 人を引き付けるようなサービス名にしましょう ### 各自メモ - hikaru - 無料版→有料版、有料版→さらなるグレードアップ版にアップセルしよう - 覚えやすい名前をつけよう - 昔の会社名に比べたら今の会社名ってすごく覚えやすくなっているのと似ているかも？ - IBM(International Business Machine) vs Meta(Facebook) - 委員会方式でクリエイティブはうまくいかないんだよな〜と思います - @niikz - アップグレードするようにおすすめしましょう - サービスを運営する上で大事なのは分かるけどあまりやりすぎるとユーザーが離れていく気がする - 名前重要 - ありきたりな名前は忘れられやすい - ネーミングセンスがほしい… - @kasai441 - GoogleDriveでやたらアップグレードを進められたのを思い出した - Youtube広告を有料版で見なくていいようにするサービスがもやもやする * * * ## 【第92回】 ### 開催日 2月6日（月） ### 今回 CHAPTER 73: Feature Food Another example: Bloggers took notice of Basecamp’s RSS support から https://bootcamp.fjord.jp/pages/35#-216 ### 次回 CHAPTER 75: Inline Upsell から ### 今日の要約 - 小さいチームは話題性のある技術をすばやく採用できる。凄い技術の威光を借りてバズることができる - あなたのバズがどこから来ているのかを調べよう - 良い意見には反応したり感謝の意を表明しよう。バズったことを報告するページを作ろう。 - 批判的な意見にもまた反応しよう。前向きなコメントを残して、あわよくば批判者を友好的に変えることも可能。 ### 各自メモ - @niikz - 小さい組織は新しいアイディアや技術を取り入れやすい - 大きい組織だと新しい技術を取り入れるのも難しそうだけど既存の技術をやめるのも難しそう - `Study your logs to track buzz` メンタルの健康にはあまりよくなさそう - 批判にも thoughtful comment をするのは大変そう… - @kasai441 - 新しい技術を取り入れて記事を書いたりしたらページビュー稼げそう - 絵の話ですが、はやりのゲームの二次創作とかは閲覧数が増えます - 感情的にならず批判的な意見に笑顔で対応するの難しそう... * * * ## 【第91回】 ### 開催日 2月2日（木） ### 今回 CHAPTER 73: Feature Food For example, by using Ruby on Rails, から https://bootcamp.fjord.jp/pages/35#-216 ### 次回 CHAPTER 73: Feature Food Another example: Bloggers took notice of Basecamp’s RSS support から ### 今日の要約 - Ruby on Railsは開発者のコミュニティによって大きな注目を集めることができた ### 各自メモ - @niikz - Railsを使ったことでBasecampはデベロッパーコミュニティから注目された - GYMAと並んで`key player in Ajax`と呼ばれるようになった - 新しい技術をいち早く導入すると有名？になるのはいまも同じ気がする - @kasai441 - Ajaxが初めから注目されているのは少し驚いた。JavaScriptフレームワークがWebの主流になる予感はすでにあったのかも。Railsはサーバーサイドの印象があったがフロントが評価されていたのかなあと。 - Railsの話をもう少し詳しく読みたいけど、そういう文献ってあるのかな？？ * * * ## 【第90回】 ### 開催日 1月30日（月） ### 今回 CHAPTER 72: Promote Through Education Teaching is all about good karma. から https://bootcamp.fjord.jp/pages/35#-213 ### 次回 CHAPTER 73: Feature Food For example, by using Ruby on Rails, から ### 今日の要約 - 先に支払えば見返りが返ってくる - 無料で情報を提供すると、それを宣伝してくれる人が出てくる - 新しいものや面白いものに飢えている人々に、それを提供すると彼らは自分たちのコミュニティにそれを宣伝してくれる。 ### 各自メモ - @niikz - `Pay It Forward` 恩送りてきなのはRubyコミュニティでよくされているように感じる - 知識をオープンにすることや周りに共有することが推奨されている世界 - 安定してから試したい派なので、`feature food` はあまり求めたことがない… - @kasai441 - 最先端の情報を手に入れるのはかっこいいと思って憧れるけど、自分はバズった後のものしか見てないなあと思いました。 * * * ## 【第89回】 ### 開催日 1月26日（木） ### 今回 CHAPTER 70: Ride the Blog Wave Ta-da List is another great example of the power of blog-based marketing. から https://bootcamp.fjord.jp/pages/35#-209 ### 次回 CHAPTER 72: Promote Through Education Teaching is all about good karma. から ### 今日の要約 - ブログによるたくさんの閲覧数を稼いだことによって、SvN, Tada, Backpack という一連のサービスの宣伝に貢献した - 直接的に「買ってください」とアプローチするより、教育すなわち何か役に立つものや情報を提供することによって、評判を広めたりフィードバックを得たりすることができるようになる。 ### 各自メモ - hikaru - 人に教えるのが却って自分のためになるんだな〜 - （雑談）寒すぎて調子悪いですね - @niikz - できるだけ早く登録してもらってリリースのお知らせを送れる人たちを獲得しましょう - β版の書籍ページにメールアドレスを登録してつぎの情報をゲットしよう！ってのをみた - Educationは先生が生徒に授業するみたいなイメージだったけど、ブログを書く、発表する、カンファレンス後に挨拶する、直接ワークショップを開くなど思ってたより広範囲の内容だった。😉 - @kasai441 - Ruby on Railsがでてきた！ - サービスが本当に誰かの役に立つものなのであれば、どんどん宣伝すればよいのかもしれない。（ただし、役に立つサービスを作るのは難しい） - 今日は珍しくたくさん勉強しました。 - ;) - :wink: * * * ## 【第88回】 ### 開催日 1月23日（月） ### 今回 CHAPTER 70: Ride the Blog Wave Start off by creating a blog から https://bootcamp.fjord.jp/pages/35#-209 ### 次回 CHAPTER 70: Ride the Blog Wave Ta-da List is another great example of the power of blog-based marketing. から ### 今日の要約 - 開発に際しての小ネタでブログの購読者を増やすことができ、Basecampのリリースのプロモーションに際して、有名なブロガーがサービスの知名度をあげる手助けをしてくれた。 ### 各自メモ - @niikz - ブログは勧誘・宣伝だけでなく役立つTipsなどを提供する - `helpful, informative, and interesting bits and anecdotes` な話題を毎日投稿して週に数千人の読者を得た - 話題を見つけるのが大変そう…… - @kasai441 - SNSがない時代のブログ全盛期のお話。 - 今でも、こつこつ情報発信をしてフォロワーを増やすのが大事そう。 - ChromeをいじっていたらWindowが落ちた... * * * ## 【第87回】 ### 開催日 1月19日（木） ### 今回 CHAPTER 68: Hollywood Launch When launch day arrived から https://bootcamp.fjord.jp/pages/35#-205 ### 次回 CHAPTER 70: Ride the Blog Wave Start off by creating a blog から ### 今日の要約 - プロモーションサイトをつくってサービスの趣旨や実際にどう使えるのかを説明するとよい - ブログを使うと効果的かつ安上がりである ### 各自メモ - hikaru - プロモーションサイトを作ってアピールすることが大事 - 自作サービスでいうとリリースブログがその立ち位置かな？ - 海外のサイトとか本ってめっちゃtestimonialがありますよね - basecampのサイトにもwhat our customers say. - https://basecamp.com/ - ブログをめちゃめちゃ推してくる - 今だったらSNSか？ - @niikz - Teaser→Preview→Launchは王道なんだな〜 - 広告自体よりも広告を評価することのほうが高価になるらしい。代わりにブログでプロモーションするときは評価しないから安く済むのかな🤔 - @kasai441 - 自作サービスでは、サイトのホームやヘルプページなどでサービスの機能を端的に伝えるためのテキストや素材を作るのが結構時間がかかりました * * * ## 【第86回】 ### 開催日 1月16日（月） ### 今回 CHAPTER 68: Hollywood Launch The Road to Launch Day から ### 次回 CHAPTER 68: Hollywood Launch When launch day arrived から ### 今日の要約 - Blinksaleをローンチしたときは、最初12人ほどの知り合いに教えて、次に何千ものメーリングリスト登録者をふやし、最終的に少人数の人にベータテストをやってもらうようにした。 ### 各自メモ - @hikaru - 箴言：贈り物をすると偽って誇る人は、雨のない雲と風のようだ。`like clouds without rain` - ティーザーを公開したけど、結局ローンチしないみたいなことをやっちゃうとこうなるということかな？ * * * ## 【第85回】 ### 開催日 1月12日（木） ### 今回 CHAPTER 68: Hollywood Launch Preview から https://bootcamp.fjord.jp/pages/35#-203 ### 次回 CHAPTER 68: Hollywood Launch The Road to Launch Day から ### 今日の要約 - 人々にサービスの宣伝をしてもらうように、情報を発信し続けましょう ### 各自メモ - @niikz - Teaser→Preview→Launchの順にやっていくとより効果がありそう - 更新/修正などのリリース情報があるとより気になる・応援したくなりそうだな〜と思った - @kasai441 - Launchのいい日本語訳がわからない - サービス開始？ - ユーザー100万人突破とか、よくスマホのゲームとかである。ユーザーも半分サービスを応援するみたいな感じで喜びを共有しているような感じ？ * * * ## 【第84回】 ### 開催日 1月5日（木） ### 今回 CHAPTER 68: Hollywood Launch から https://bootcamp.fjord.jp/pages/35#-200 ### 次回 CHAPTER 68: Hollywood Launch Preview から ### 今日の要約 - ハリウッド式のローンチ - 告知 - プレビュー - 発表 - まずはその道に詳しい人たちに宣伝して評判が立つようにしましょう ### 各自メモ - hikaru - この章はアメリカンな例えばっかだな〜 - ゲーム業界とかも同じことやってそう - 鋭意製作中！みたいな話だけ出て、数年音沙汰ないとかあるある - `If an app launches in a forest`の話はif a tree in a forestのもじりっぽい。他の本でもよく見る気がする。 - https://en.wikipedia.org/wiki/If_a_tree_falls_in_a_forest - @niikz - 自作サービスのプラクティスにも、ちゃんとリリースしたと書きましょう、ブログが読まれやすいタイミングでSNSに告知しましょうとか書かれていたのでなるほどでした - Teaserとか全く情報がないところからのサプライズみたいなのはよろしくないのだろうか🤔 - @kasai441 - ぜんぜんわからないサイトの名前がいっぱい出てきた... - グーグルの検索にかかるようにする、というのは、個人開発者だとどうやるんだろう * * * ## 【第83回】 ### 開催日 12月26日（月） ### 今回 CHAPTER 66: Silly Rabbit, Tricks are for Kids から https://bootcamp.fjord.jp/pages/35#-196 ### 次回 CHAPTER 68: Hollywood Launch から ### 今日の要約 - 初期費用や長期契約は嫌われるので避けよう - Grandfather clausesを検討しよう。（規約を変えた場合、前の条件で入ったユーザーに猶予期間を与える？） ### 各自メモ - @niikz - 長期契約、中途解約料金、初回手数料のようなものは嫌がられるので避けよう - 儲けるためにトリッキーな方法を探すのはやめよう - 悪いニュースは事前告知をしてできるだけ痛みを少なくする - 既存のユーザーには猶予期間を検討しよう - @kasai441 - grandfather clausesについて調べていました - https://en.wikipedia.org/wiki/Grandfather_clause - 中途解約手数料は嫌いかも携帯の2年契約とか - サッカーの移籍金は面白い制度 * * * ## 【第82回】 ### 開催日 12月22日（木） ### 今回 CHAPTER 65: Easy On, Easy Off There should always be a free option so customers can demo the app から https://bootcamp.fjord.jp/pages/35#-194 ### 次回 CHAPTER 66: Silly Rabbit, Tricks are for Kids から ### 今日の要約 - 登録フォームは簡単に入力できるようにしよう。 - それと同じように登録解除も簡単にできるようにしよう。 - ユーザーが登録解除したいとき、簡単にデータをエクスポートできるようにしよう ### 各自メモ - hikaru - toBだと無料で使えるけどコールバックしてきたりする会社が結構多い印象 - データエクスポートできるのはポイント高い - 仕方なくではなくて戻りたいと思ったから戻ってきてもらえるようにするのが大事 - @kasai441 - 登録解除が簡単なのは、そこそこ実現可能かもしれないけど、データを簡単にサービス外に出せるようにするのは技術的に難しそう - 最近だとCloudでのバックアップが普通になってるけど、サービスを辞めたらさすがにデータは外に出せなそう - デバイスを変えるとLINEのログがよく消えてしまう - @niikz - クレジットカードの情報を入力せずにアプリのお試しができるようにするべき。いつでも自由に試してもらえるように。 - 登録解除のリンクもはっきりと載せる。メールを送ったり特別なフォームや質問に答えさせたりしない。 - データはユーザーのものなので簡単にエクスポートできるようにする - やめたいときにやめれて戻ってきたいときに戻ってこれるのが重要 * * * ## 【第81回】 ### 開催日 12月19日（月） ### 今回 CHAPTER 64: Free Samples から https://bootcamp.fjord.jp/pages/35#-189 ### 次回 CHAPTER 65: Easy On, Easy Off There should always be a free option so customers can demo the app から ### 今日の要約 - 騒がしい世界の中でユーザーがあなたを見つけられるように、フリーサンプルを配りましょう。 - 登録と登録解除を簡単にできるようにしよう ### 各自メモ - hikaru - Getting Realって少し前の文章のイメージだけど、無料で配るビジネスモデルがもうこんなに書かれていたんですね〜。国内のサービスは出遅れ感あったような... - 本当に良いものを作っている自信があるなら、それを無料で全世界に公開した方が逆に儲かるということ - 退会も簡単なのは確かにイメージが良い - @ogaworks - 最初に無料枠、無料サービスを提供してというこの話、今となってはどこもがふつうにやるモデルになってる。 - （信用度の低い）個人が法人相手に何かを売る際にも、最初＆当面は無料で使ってもらって、評価と信用が得られたら有償に切り替えるとかもあると思う。 - （アプリのインストールって気軽？） - 有力な人って事前にある程度わかってるんじゃない？ - WEBサービスのほうが手軽 - 拡散しやすさ - 動画とか - @niikz - 最初は無料で後々有料プランに切り替わったら結構なユーザーが離れていくイメージでした - お金を払ってでも使いたいユーザーが残るのでいい、ということでしょうかね？ - ヒットシングルをあげましょう。人々が聴いて、コピーして、シェアしたら曲にお金を払う人が増えるらしい。 - 日本は著作権関係結構厳しいイメージがあったけど海外だと確かによくみる気がする - JASRAC... - 各ページに登録のポップが出るのはキツイ……😭 - @kasai441 - ウェブサービスで登録解除しにくいやつ、結構ある気がする - たしか、New York Timesのサイトの登録解除が難しかった...電話しなきゃいけないみたいな。今は違うかも。 - 無料サンプルは、昔よりもせちがらくなっている気がする。 - 「Don't be evil」Googleの"元"社訓 * * * ## 【第80回】 ### 開催日 12月15日（木） ### 今回 CHAPTER 63: Personify Your Product から https://bootcamp.fjord.jp/pages/35#-187 ### 次回 CHAPTER 64: Free Samples から ### 今日の要約 - サービスを人として考えよう - その人の性格はどうあってほしいか？厳格なのか楽しげなのか...etc - サービスの性格を決めたら、常に開発中その性格を心にとどめよう - あなたのユーザーはあなたの決めた性格のサービスの話声を24時間聞くことになるだろう ### 各自メモ - hikaru - プロダクトが性格を持っているという考え方は斬新だな〜、確かにSlackとかDiscordはお知らせが~~タメ口~~口語で親しみやすいかも - 複数人で開発をしてたら統一が大変そう。UXを担当する人がちゃんと統括しないといけない - @niikz - プロダクトの性格を考えてみましょう - ユーザーにどういう印象を与えたいかを考えるときに参考になりそう - コピーライトやインターフェース設計のガイドにするのはかなり役に立ちそう - 開発者の性格も結構反映されそうだな〜と思った🤔 - @kasai441 - ページによってテーマや文章の流儀にばらつきがあったら確かにいやそう。 - 開発者の性格ではなくサービスの性格を決めて反映させる、というプロセスは参考になりそう。 * * * ## 【第79回】 ### 開催日 12月12日（月） ### 今回 CHAPTER 62: Use Real Words Sure, it’s easier to just run down the forms から https://bootcamp.fjord.jp/pages/35#-185 ### 次回 CHAPTER 63: Personify Your Product から ### 今日の要約 - ユーザーが実際に入力するのと同じようにデータ入力をしてみないと、そのフォームの使い勝手を本当に理解できない。 ### 各自メモ - hikaru - 実際の文言を入れるのは大事ですよね〜、文言に限らず実データ入れたら吹っ飛ぶとかよくある - 鼻声で困る... - @ogaworks - そういえば、自作サービスの報告会の時にも、「ダミーデータは（見た人がサービスや機能を理解しやすいので）リアルな方がよい」と駒形さんが言ってました。 - 週末、地図画面に実装した住所検索で、「あああああ」でも「町田市成瀬1丁目」だと正常に動く（のでリリースしてしまった）のに「町田市」だと動かないというケースに遭遇して、テストデータは大切だと痛感したところでした。 - @niikz - デタラメな文字列を入力するのは簡単だが顧客が実際にするであろうことではないため、そのショートカットは本当に賢いことだろうか？ - 今回の引用はむずかしかった - @kasai441 - サービス開発中は、実際のデータを入れる手間が惜しいので「あああああああ」「ううううう」みたいなデータを入れがち。 - あらためて考えると、開発中に文章を考えるのが面倒なフォームというのは、ユーザーも書きにくいかもしれない。例文やサンプルデータを用意しとくとよかったかなと、思いました。 - ユーザビリティは開発の手間から本当に犠牲にしたくなりがち。 * * * ## 【第78回】 ### 開催日 12月8日（木） ### 今回 CHAPTER 62: Use Real Words から https://bootcamp.fjord.jp/pages/35#-184 ### 次回 CHAPTER 62: Use Real Words Sure, it’s easier to just run down the forms から ### 今日の要約 - ダミーデータを使うと、現実にある避けがたいデータのバリエーションを無視することになる。 - できるだけ、現実と同じようなデータを使いましょう。 ### 各自メモ - @niikz - ダミーテキストではなく実際のテキストを入力しましょう - その項目に沿った値を入れることでバリデーションのエラーやミスとかも見つかりやすそう - フォームには適当な値を入れて崩れないか、どういうエラーメッセージが表示されるのかのチェックをよくやっちゃいます😂 - @kasai441 - フォントの読みやすさとか、画像の見やすさとかは、ピクセルや幅などに大きく左右されるので、実際にありそうなデータでデザインの値を決めるべき - とはいえ、フロントエンドの開発になるまではサンプルデータもありかなと思います。 * * * ## 【第77回】 ### 開催日 12月5日（月） ### 今回 CHAPTER 60: Don’t Do Dead Documents Webapps don’t move forward with copious documentation. から https://bootcamp.fjord.jp/pages/35#-181 ### 次回 CHAPTER 62: Use Real Words ### 今日の要約 - 長いドキュメントを書いても誰も読まないので、それに時間を無駄に費やさないように - 短いストーリーを書こう。詳細ではなくストーリーを書こう。 ### 各自メモ - @niikz - 詳細ではなくストーリーを書きなさい - 新しい機能やコンセプトの短いストーリーを（いつもの会話のように）書く - 技術やデザインの詳細は必要ない - `Do it in a human way` 仕様書などの書類は不要なので文書っぽい感じではなく人間的に書く - @ogaworks - （無駄になるので）長々とビジョンや作戦を書かずに、まずは短いストーリーから始めましょうということかな。 - アントニオ猪木の道をふと思い出しました。 - 外で突風が吹きはじめた（５０Lの植木鉢が倒れた）ので途中抜けて失礼しました。 - hikaru - 輪読会EXPO参加しちゃっていいですか〜？ - ogaworksさんはどうでしょう - 短いストーリーを会話（すり合わせ）のきっかけにしよう、みたいなことなのかな？ - 詳細（戦術）部分は開発を始めたらおのずと定まってくる、みたいな感じ？ - @kasai441 - ユーザーストーリーの書き方を少し調べてみると、結構難しい * * * ## 【第76回】 ### 開催日 12月1日（木） ### 今回 CHAPTER 60: Don’t Do Dead Documents Here’s an example: から https://bootcamp.fjord.jp/pages/35#-180 ### 次回 CHAPTER 60: Don’t Do Dead Documents Webapps don’t move forward with copious documentation. から ### 今日の要約 - ワイヤーフレームなどのドキュメントも、それが実物のプロダクトにつながらないならば無駄である - 引用：「開発を進めていくうえで非常に多くの読まれない文書が発生するのを目の当たりにしてきた」 ### 各自メモ - hikaru - 実際のプロダクトにそのまま繋がらないものは全部省いていくスタイル - ドキュメントは読まれないので時間をかける意味はない - ドキュメントをカッチリ作るとなんかすごく仕事した気になっちゃうので本当にやっかいだと思う - @niikz - ワイヤーフレームが直接実際のデザインにならないならばわざわざ書く必要がない。書類が現実にならなければ "it’s dead." - 必要があるから書いたはずの文章を誰にも読まれなかったらツラい。読まれないコーディング規約🥲 - @kasai441 - 読まれないドキュメントは作らない。 - 読まれそうにもないドキュメントを作る仕事が多かった - 有価証券報告書 - 基本設計（建築） - 基本設計（SE） - 法的なドキュメント（ユーザー規約とか） - 全然使われないコーディング規約に出会ったことがある。 - ファイル名の法則を指定しているが、実際の製品ではまったく違う方法で命名されているのでいちいち権限のある人に電話で聞いていた - ローマ字何文字数時何文字みたいな規定 * * * ## 【第75回】 ### 開催日 11月28日（月） ### 今回 CHAPTER 59: There’s Nothing Functional about a Functional Spec Confusion disappears when everyone starts using the same screens. から https://bootcamp.fjord.jp/pages/35#-176 ### 次回 CHAPTER 60: Don’t Do Dead Documents Here’s an example: から ### 今日の要約 - 仕様書ではなくプロトタイプしましょう。 - 仕様書だけでなく紙の書類はなるべくプロセスから排除しましょう。 ### 各自メモ - hikaru - ここでいうインターフェースはどれくらいの出来のものを指しているのだろう？ワイヤーフレームレベルでいいのかな？ usingとかclickingとか言っているからもっとちゃんとしたやつ？ - 仕様書は定義からして机上の空論・仕様書にこだわるやつは邪魔者にすぎない、過激派だ - プロトタイプは製品への道の途中にあるが書類はゴミ箱への道しかない、に笑った - @kasai441 - 基本設計とかそういうのをやめましょうということっぽい - 組織が大きくなれば無駄な書類が増えるという話かなあと - いろんな権限が分散しているので、いろんな人に許可をとったり - @niikz - みんなが同じ画面を使えば混乱しない。できる限り顧客の体験を考えよう。 - みんな＝ピザを分けられる人数？ - 不必要な書類仕事を排除する。紙切れはごみにしかならないが、実際のインターフェースやプロトタイプは現実のプロダクトになりうる。 - @ogaworks - Railsでいうと、modelやcontrollerはほぼ空でViewで遷移する程度のものを作ろう（でそれを a real productに仕上げていく）というイメージなのかな？ * * * ## 【第74回】 ### 開催日 11月24日（木） ### 今回 CHAPTER 59: There’s Nothing Functional about a Functional Spec Functional specs lead to feature overload から https://bootcamp.fjord.jp/pages/35#-175 ### 次回 CHAPTER 59: There’s Nothing Functional about a Functional Spec Confusion disappears when everyone starts using the same screens. から ### 今日の要約 - 仕様書の時点であらゆる要望を採用すると機能が多すぎるサービスになってしまう - 仕様書の代替となるのは、インターフェースを作ってしまうことである。解釈の余地のある文章と違って、HTMLでかかれたものはより共通の地盤を持っている ### 各自メモ - hikaru - ストーリーってなんですかね？ユーザーストーリーのことですかね？ - なるべく早くインターフェースを作るべき！ - CHAPTER 46: Interface First も - 今日は具体的な内容でよくわかった - @kasai441 - だいぶ前の章でもすぐにHTMLを書いたほうが良い、ということが言われていて、そのときには今と開発手法がだいぶ違うからこうなるのかな、という話をした記憶があります。 - @niikz - 機能仕様は現実的ではないことについての具体的な話しがたくさんでてきてよかった - 機能を追加していくと皆を喜ばすことはできるけど人のためにはならない - テキストだと他にも解釈の余地があるけどインターフェースデザインだと共通理解になる * * * ## 【第73回】 ### 開催日 11月21日（月） ### 今回 CHAPTER 59: There’s Nothing Functional about a Functional Spec から https://bootcamp.fjord.jp/pages/35#-169 ### 次回 CHAPTER 59: There’s Nothing Functional about a Functional Spec Functional specs lead to feature overload から ### 今日の要約 - 仕様書によって仕事をしてる感を得ることはできるが、それはそんなに実用性がない - 計画の時点というのはそのサービスについてもっとも情報が少ない。その段階は決断をするのにふさわしくない。 ### 各自メモ - @niikz - 機能仕様のドキュメントは書かない - 機能仕様はファンタジー。文章上での同意は本当の同意ではない。同じ文章を読んでいても考えはそれぞれ違う。 - ”機能仕様によって情報が最も少ないときに重要な決断をさせれらる”ところの話しがよく分からなかった - @kasai441 - 計画の段階で予算が出るというのが常識すぎるので、開発が始まってから予算が決まるみたいなのはどうやってやるのかな？？って思いました - 「顧客が本当に必要だったもの」 - @ogaworks - 最初に機能仕様を書いて合意するのは無駄だ的な話かな。 - アジャイルじゃない受託開発の話の話みたい。 - そう言えば、ふだんWEBサービス作る時は画面とDBの設計ぐらいかな。 - hikaru - 決断はなるべく遅らせろ、みたいな話？なのかな - ウォーターフォール開発と真逆のことを言ってる感じ - making tough choices and exposing costsがすごいアプリを作る際に必要なこと * * * ## 【第72回】 ### 開催日 11月17日（木） ### 今回 CHAPTER 58: Open Doors APIs let developers build add-on products for your app that can turn out to be invaluable. から https://bootcamp.fjord.jp/pages/35#rss-api ### 次回 CHAPTER 59: There’s Nothing Functional about a Functional Spec から ### 今日の要約 - APIを利用すればそのサービスに役立つ拡張的なサービスが作られることを促すことができる - Google Maps APIやFlickrなど... ### 各自メモ - @niikz - APIを公開するとそれを使った拡張機能などが話題になって、その影響で大元のサービスも広がっていった。 - ブーメラン効果を得るためにAPIを公開するのは普及活動の一環ってこと？🤔 - @kasai441 - サービス間をまたがって複数のサービスで大きな機能を補完しあうみたいな理想の話。 - 今ではTwitterやGoogleなどのログインはAPIが使われている - LineなんかもAPIがたくさん使われている - →大きなサービスがAPIを提供しているイメージ * * * ## 【第71回】 ### 開催日 11月14日（月） ### 今回 CHAPTER 57: Manage Debt It’s ok to do this from time to time. から https://bootcamp.fjord.jp/pages/35#-166 ### 次回 CHAPTER 58: Open Doors APIs let developers build add-on products for your app that can turn out to be invaluable. から ### 今日の要約 - 収入があると税金を払わなければならないのと一緒で、コードを書いたりデザインをすることによって、将来的に払わなければならない負債ができる - RSSやAPIによってユーザーから得たデータをオープンに活用できるようにしたほうがよい ### 各自メモ - hikaru - 負債になってしまう方法もasapで実現するには必要だけど、ちゃんと後で修正することを頭に入れておくことが大事 - 情報は囲い込むより、一般に解放すべき！もっといろんな相互作用が働くようになってほしいですね〜 - APIのまとめらしいです - https://www.apibank.jp/ApiBank/api?category_no=0 - RSSが下火になったのは、SNSでフォローしておけば情報が追えるようになってしまったとか？ - @ogaworks - 受託作業の際の見積もりの「＋α」成分は負債の消化の意味合いもあったのかなと感じた。 - RSSリーダーの仕組み、改めて便利だなーと感じた。 - 今は、LINEの友達登録→LINEでお知らせとかが、情報の更新を知らせる手段のひとつにもなってるのかな。 - Googleやfbがコンテンツを自分に寄せて表示してくれるようになったのもフィードを取りに行かなくなった理由のひとつかも。 - @niikz - コードやデザインの負債を定期的に清算しましょう。小さいリファクタリングも時間がたつと大変になりそう。 - RSSの仕組みを初めて知った。便利らしい！いまでいうSNSの通知の役割なのかな🤔 - @kasai441 - RSSが失速した原因はなぜ？ - そもそも情報を積極的にあつめようとするユーザー層がインターネットの主勢力だった - YoutubeやタブレットPCやスマホによってインターネットが大衆化して、よりSNSよりのコンテンツが主流になった * * * ## 【第70回】 ### 開催日 11月10日（木） ### 今回 CHAPTER 56: Code Speaks Your code can guide you to fixes that are cheap and light. https://bootcamp.fjord.jp/pages/35#-162 ### 次回 CHAPTER 57: Manage Debt It’s ok to do this from time to time. ### 今日の要約 - より簡単で楽なコードが、最初に考えたものと違うとしても、それは問題ない。 - デザインについて心配することはない。技術者の言うことに耳を傾けよう。 - 負債というとお金のことを考えがちだが、そうでない負債もある。 ### 各自メモ - hikaru - 変更がしづらい、という声が聞こえたら修正するタイミング - コードがより簡単な方法を示してくれるらしいけど、これは熟練者ならではだよなあ - 負債のところはまだあまりピンとこないなあ - @kasai441 - コードの声はあまり聞いたことがないので、聞けるようになりたい。。。 - 負債というのは、将来的に積みあがる仕事、みたいなニュアンスかな？ * * * ## 【第69回】 ### 開催日 11月7日（月） ### 今回 CHAPTER 54: Less Software There is No CODE That is More Flexible Than NO Code! から https://bootcamp.fjord.jp/pages/35#-156 ### 次回 CHAPTER 56: Code Speaks Your code can guide you to fixes that are cheap and light. から ### 今日の要約 - コードが少ないに越したことはない - ツールは開発者が幸せになるものを選ぶべきだ。RubyやRailsは機能を充足させるだけでなく興奮やモチベーションを与える言語である。 - コードの声を聴こう。よりシンプルな効果的な方法を教えてくれる。 ### 各自メモ - hikaru - 良いツールをつかっているプログラマーは正しいことをします！なのでハピネスを最大化しましょう！いい言葉だなあ笑 - 今日のところはまさにRubyistって感じでした。 - コードは語る...注意深くコードにあたれ、ということかな？ - @ogaworks - Ruby on Railsに限らず、書く言語によって似たようなエンジニアが集まるというのはわかる気がする。 - 言語だけでなく、道具（PCとかキーボードとか椅子とか）にもこだわりがあり、そこにも似た人が集まってそう。 - programming bliss. - コードの声が聞こえるようになってみたい。rubocopもそのひとつなのかな。 - @niikz - コードをより少なくする - 何を入れるかではなく、何を入れないか - どんなツールやプログラミング言語を選ぶのかも重要 - Railsを使うとエレガントで生産的な美しい設計ができる！めっちゃRuby推し😊 - 幸せなプログラマーはシンプルで読みやすいコードを書く - @kasai441 - コードの声を聞いたことがないので続きが気になる。 - RubyやRailsが他の言語と比べて特別な感じはしないので、説明がちょっとほしいかも * * * ## 【第68回】 ### 開催日 10月31日（月） ### 今回 CHAPTER 54: Less Software Whenever possible, we chop up hard problems into easy ones. から https://bootcamp.fjord.jp/pages/35#-155 ### 次回 CHAPTER 54: Less Software There is No CODE That is More Flexible Than NO Code! から ### 今日の要約 - 小さなソフトウェアでも機能の取捨選択は気を付けてする必要がある。落ち着いて考え、本当に必要な機能を選ぶようにすること。 - プログラマーに逆提案をさせるように勇気づけましょう。12時間を要する機能追加を提案されたとき、1時間で済む代替案を提案できるなら、そうするようにプログラマーに言いましょう。 ### 各自メモ - @niikz - 困難な機能追加の要求にはノーと言う。時間・労力・混乱をセーブするようにしましょう。 - アイディアを漬けておく - ソフトウェアを変更せずに必要なコードだけを書くように提案する - @ogaworks - コードの量は抑えようという話。は、今までも何度となく出てきているが、前回休んだおかげでこの章の言いたいことがあまりバシッと理解できていない。 - 自作サービスの実装を再開したので、少ないコード（でついつい余計な機能を増やさないよう）を意識しつつがんばります！ - @hikaru - コードは書かずに済めばそれに越したことはないらしい - 1週間待ってみてまだいいアイデアだと思えたらアクションをとる、なかなか難しそうな話だなあ - @kasai441 - 表現が難しくて意訳するところが多かった！ * * * ## 【第67回】 ### 開催日 10月27日（木） ### 今回 CHAPTER 54: Less Software The way you fight this complexity is with less software. から https://bootcamp.fjord.jp/pages/35#-155 ### 次回 CHAPTER 54: Less Software Whenever possible, we chop up hard problems into easy ones. ### 今日の要約 - 複雑な問題に立ち向かうための解決策は、より少ないソフトウェアである - より少ないソフトウェアは、より少ない機能、より少ないコード、より少ない無駄のことである - 現在の問題をさしおいて先の心配をするのは無駄である ### 各自メモ - hikaru - 問題の80%を20%の努力で解決できれば御の字らしい - 将来の起こりそうな問題を今がんばって解決しないようにしろ、ということ？YAGNI的な話？ - https://ja.wikipedia.org/wiki/YAGNI - @niikz - `Don’t bog yourself down trying to solve these phantom issues.` 起こるかもしれない（まだ起きていない）問題に不安になりがちなので気を付けたい - `put away the crystal ball` 水晶を片付ける - `bog down` 沼にはまるという表現が日本語でもぴったり😂 - @kasai441 - いつもの通り、少ない機能にしようという話。 - GETTING REALの文脈上、リリースしてから問題が出てきたときに解決すればよいので、事前にいろいろ想定して機能を重くしないようにしようという話。 - たとえば、大規模なアクセスを心配して設計してもユーザーが少ないうちは意味がないみたいなことかなと * * * ## 【第66回】 ### 開催日 10月24日（月） ### 今回 CHAPTER 53: One Interface から https://bootcamp.fjord.jp/pages/35#-151 ### 次回 CHAPTER 54: Less Software The way you fight this complexity is with less software. から ### 今日の要約 - 管理画面のインターフェースと公開画面のインターフェースを分けてデザインすると2度手間になるので、同じ画面に収めるようにしよう - 2倍の機能を作ろうとすると2倍以上の労力がかかる ### 各自メモ - @ogaworks - 管理画面を公開画面と分けないというのはなんとなく理解できたが、実際管理機能をどう配置すべきなのかもう少し知りたい感じでした。 - 今リニューアルをしているサイトがRails3.2で、まさに`Big Ball of Mud`と格闘してる感がしてます。 - @niikz - 通常の画面と管理画面を分けるとコストが2倍かかり杜撰になる - 画面を別にするのではなくユーザーによって機能の表示/非表示を切り替えるのかな🤔 - コードの量が増えるとソフトウェアは指数関数的に複雑になっていく。できるだけシンプルなコードを書く。 - @hikaru - 管理画面を別で作らないのが大事らしい。一つのインターフェースでどう実現するかが大変そう。 - ログインユーザーが一般だったらボタンをグレーアウトさせておくとかそういうことかな？ - コードの量に伴って、アプリケーションの複雑さは指数関数的に増えていくらしい - @kasai441 - 管理画面の説明のところ難しかった。ただ、Railsではこの辺の機能は定型的にクリアできそうなので今はあまり気を配らなくてよいかも。 - 大きな泥団子は、読むのが大変そう。 * * * ## 【第65回】 ### 開催日 10月20日（木） ### 今回 CHAPTER 52: Copywriting is Interface Design から https://bootcamp.fjord.jp/pages/35#-149 ### 次回 CHAPTER 53: One Interface から ### 今日の要約 - コピーライトはインターフェースデザインである。 - ボタンの命名や説明書きなど、ひとことひとことが重要である。 - 専門用語などをつかってユーザーがわからない言葉づかいをしないこと。 ### 各自メモ - @niikz - コピーライティングはインターフェースデザイン。よい文章はよいデザインである。 - ボタンのラベル名や入力例は分かりやすいよう意識していたけど、ポリシーや説明書きも気にかけようと思いました - @kasai441 - 自作サービスでは、最初は雑にCreateボタンとかNewボタンとかで開発を進めるけど、CSSを入れる辺りで文字の長さとかが重要になってきて、最終的にはユーザーがわかりやすくなるように再度修正する感じでした。 * * * ## 【第64回】 ### 開催日 10月17日（月） ### 今回 CHAPTER 51: Context Over Consistency から https://bootcamp.fjord.jp/pages/35#-146 ### 次回 CHAPTER 52: Copywriting is Interface Design から ### 今日の要約 - 一貫性より、コンテキストが重要 - ユーザーが必要としているときに必要としているものを配置すること、それ以外のものは必要ない - 一貫性を持たせるためにナビゲーションバーやフッターを追加する必要はない。 ### 各自メモ - @niikz - すべてのページに余分なグローバルナビを追加するのはばかげている。一貫性よりも状況による。 - 一貫性をもたせることはインターフェースデザインの基本であると教えられるが、ウェブでは適していない。ソフトウェアには適している。ソフトウェアとウェブの違いがあんまり分かっていない。 - @kasai441 - 普通にサイトを作ろうとすると、とりあえずどのページにもロゴが出てフッターが必ずあるようにするデザインをなんとなくやってしまいそうなので、ちょっと知見を得た感じがした。 - ユーザーとしてサービスを使う時はフッターなんかほとんど見ないイメージ（だいたい利用規約などが書いてある） * * * ## 【第63回】 ### 開催日 10月13日（木） ### 今回 CHAPTER 50: Get Defensive から https://bootcamp.fjord.jp/pages/35#-144 ### 次回 CHAPTER 51: Context Over Consistency から ### 今日の要約 - ディフェンシブデザイン - 車の運転と同じように、いろいろな危険性を考慮して安全にデザインしましょう。 ### 各自メモ - @niikz - "Defensive Design"はエラー画面とか操作に失敗したときの対応のこと？ - Railsはエラーメッセージをよしなに表示してくれてありがたい - ここらへんをチェックして質を担保するのがQAエンジニアなんですかね🤔 - @ogaworks - 防御のための？デザイン、あまり今まで意識したことがないせいか、イメージが難しかった。 - "visitors confusion and frustration" するかどうかはなかなか自分で意識しにくい気もするので、部外者に触ってもらってその様子（スムーズか否か）を見るとわかりそうな気もする。 - @kasai441 - いろいろな不具合を想定してデザインしましょう、とのこと。 - どのタイミングのデザインか分かりにくいけど、一度リリースしてから直していくという理解でいいのかな？？ - Defensive Design for the webの本の紹介文がGettingRealの本文と同じ。 * * * ## 【第62回】 ### 開催日 10月3日（月） ### 今回 CHAPTER 49: The Blank Slate Yet most designers and developers still take this stage for granted. から https://bootcamp.fjord.jp/pages/35#-143 ### 次回 CHAPTER 50: Get Defensive から ### 今日の要約 - ページの初めの印象がユーザーの期待を決定するので、データがないページのデザインは重要 - データがない時はヘルプ画面に促したり、データを入力した後のイメージを見せたりするとよい。 - 最初のセットアップ画面は端末の機能の1/1000に過ぎないかもしれないが、最も重要な1/1000である ### 各自メモ - @ogaworks - データがないページのデザインはあまり考えたことがなく、データが有るように見せるためにデータを用意してきたな。 - 一度離れたユーザーが再び帰ってくることはほぼ無いので、「2度目のチャンスはない」は意識したい。 - `You Never Get A Second Chance…`　の引用文が複雑だけど、読み方がわかるとなるほど感が高くて楽しい。 - @niikz - 確かにMacのWelcome画面は分かりやすいしわくわく感があってしっかり設計されている。置いてけぼりにされない。 - 開発側が使い勝手に慣れれば問題ないと思っていても、ユーザーは最初の印象で使うかどうかをシビアに判断しているからブランク画面やチュートリアルも力を入れないといけない - @kasai441 - なるべく待たせない、選択肢を少なくする、というのも一つ大事な気がする。 * * * ## 【第61回】 ### 開催日 9月29日（木） ### 今回 CHAPTER 49: The Blank Slate から https://bootcamp.fjord.jp/pages/35#-142 ### 次回 CHAPTER 49: The Blank Slate Yet most designers and developers still take this stage for granted. から ### 今日の要約 - よく考えられた最初の印象によって、期待をさせること。 - データがない画面こそがユーザーの第一印象なので、データがない画面をデザインしないのは大きな失敗です。 ### 各自メモ - @niikz - 最初の画面には最低限の情報やデザイン、コンテンツしかないが、顧客はそこでアプリの価値・使いやすさを判断する - デザイナーはテンプレートをデータでいっぱいにしてデザインするけど、何もない画面のデザインもちゃんと考えましょうということかな🤔 - 次に何をしたらいいかヒントやアドバイスがある画面は親切だな〜と感じる - @kasai441 - たしかに最初に画面のデザインを考えるときはデータが入っている見た目でレイアウトを考えるので、空データのデザインというのは抜けている。 - データがない時は一覧の位置に「○○を作成する」のようなボタンを配置した方がよいと、デザインレビューで指摘されました。 * * *