「ジョナサン・アイブ」を読んだ
会社から課題図書として「ジョナサン・アイブ」が与えられたので読んだ。 http://amzn.asia/d/a6VRRNIamzn.asia
自分は本を読むまでさっぱり知らなかった*1のだが、彼はAppleのChief Design Officerだ。本にはその半生 + Apple でどのようにプロダクト作成に関わってきたかがたっぷり書かれている。表題は「ジョナサン・アイブ」と書かれているが、本文中では基本「ジョニー」と表記されていた。海外の名前に関する呼び方のニュアンス、難しい。あだ名的扱いなのだろうか。
自分がAppleという会社の製品に触れたのは親に連れ立って行った電気屋に電源が入った状態で展示されていたiMacだった。 自宅にあったのはクリーム色っぽい外装で変哲のない四角のWindows95据え置きパソコンだったので、鮮やかなカラーリングが物珍しく、触って見たものの真円に近い形のマウスが扱いきれなかった。結局操作方法がよく分からないまま、起動しっぱなしのバグズ・ライフのゲーム画面を飽きるまで眺めていたのを覚えている。
これがボンダイブルーと呼ばれるカラーリングであったこと、また当時iMacがジョブズ復帰直後の衝撃的なプロダクトであったこと、そしてジョナサン・アイブ氏も大きく関わっていたことを、約20年越しに読書から知った。
自分はハードウェア方面はからっきしなので、形成技術がどれほどすごいとかはいまいちピンと来ていない。しかし、使っているMacbookの表面がすべすべしていて閉じた状態が綺麗だなぁと感じられるので、ジョナサン氏および彼が率いるIndustrial Design Groupのシンプルさを追求する哲学が一般市民に届いている証拠と言えるのだろうなぁと思う。
また、iOSは昔はもっとアイコンやUIに「木の本棚」や「押せるように見えるボタン」といったリアリティさを求めていた。それはスマートフォン黎明期に人々がデバイスの使い方を理解するために必要なものだったが、ある日を境にフラットデザイン方面に舵を切った。それまでハードウェア面で腕を振るっていたジョナサン氏がiOSの改革も行ったためということのようだ。現実模倣デザイン*2とフラットデザイン、どちらもメリットデメリットがあると思うが、現実模倣→フラットデザインという変更は順当な進化であるように感じた。
特にApple内部がどうしたこうしたという話は特に把握しておらず、ただの1ユーザに過ぎない自分もなんとなくプロダクトから改善の差分の匂いを感じていたが、それはすごいデザイナーさんの活躍が滲み出ていたんだなぁということに驚いた。
iPhone8以降の端末サイズがでか過ぎて手に余り、次の何らかの端末買う機会は携帯のAndroidへの買い替えかなと考えていたが、店頭でうっかり手に取ったiPad Pro(2018)があんまりにも軽くて感動したのでゲットしてしまった。つい先ほどそれが家に届いた*3が、まだダンボールを開けていない。Apple IDgのこだわっている箱を開けるときのわくわくをもうちょっと味わっておこうと思う。
「ジョナサン・アイブ 偉大な製品を生み出すアップルの天才デザイナー」、Appleのデザインへのこだわりがどう形成されていったかが追えていってよかった。一応会社の課題図書なので何を学んだかというのを考えると、神は細部に宿る、とか、ユーザのためにこだわるのが大事、ということかな。
銀座Rails#3 参加メモ
一般参加するたびにメモ記事が増えるぞ! それ以外にも色々と発信の方法はあるしやっていかないとなぁという強い気持ちをもらえた会でした。
- 最近乾杯! から始める勉強会多い気がする(直近2回目)
- Forkwellさんのスポンサード戦略に脱帽、またでたな!
- リンクアンドモチベーションさんの会場おしゃれ...銀座だ...ひぇ...(商業施設で迷った)
Ruby,Rails書籍の分類と一考察 2018年秋版
- ゼロからわかるRuby超入門! 発売おめでとうございます!
- Rails5 の万葉本買いました
- たくさん本がある、2018年Ruby本分類表すごい
- 表を見ながらのいがいがさんの口頭解説そのままyoutubeとかにしたほうがいいのでは説
- オライリーのRuby本はキリンだったのか、調べたらツバメもいた。
- BOOTHでみんな同人誌出している、すごい
- いがいがさんが読みたいけどまだなさそうな本
- 次回技術書店は2019年4月予定
- まだ行ったことないので行ってみよかな
現場で使えるゆるいペアプロ
- ペアプロ: ふたりでやる
- モブプロ: 複数人でやる
- ベアプロ: くまに話しかけながらやる
- ゆるいペアプロ: 開発を効率よく進めるために、チームを有効活用すること
- わからないとこあったら相談しよう作成は機能しなかった。相談するために調べてる間にわけわからなくなる...。
- 忙しそうな人に質問しづらい。忙しいひと「質問できなかった?」「そんなことないです〜(そんなことある」
- 考えていることを口にしながら、一緒に作業を流す
- 情報を集める: 誰に聞くかとか
- コードを読む: どんなキーワードで検索する? URL?
- 戦略を立てる: 複数たてる、あとはやるだけにする
- タスク: ひたすらやる、迷わずやる、ハマったら時間区切る
- ふりかえる: 詰まったら戦略まで戻る
- 困ったらペアプロはうまくいかなかったので、基本ペアプロ ということにした。
- 実際にやった感想
- コミュニケーションハードルが低くなった: いつでも話せる。ちょっといいすか、とかいらない
- PR、コミットに見えない家庭: 一緒に考えることができた
- 複雑 -> シンプルにどうしたらできるか方法がわかった。書く子撃破すると倒しやすくなる
- Gitコミットやリファクタリングをするリズムをわかっている相手から感じることができた
- リアルタイムで相談レビューでコードを改善しやすい
- わかんない状態だと不安が強いが、ちょっとできる人と一緒にやると勇気がもてる
- (自分はいまのところベアプロオンリーだけどたしかに疲れたら会社のくまを抱きしめるのでベアプロと言える)
- サイクル: 課題確認 > 戦略立て > 作業の流れを相談 > どちらかのPCで作業 > 休憩
- ちゃんと振り返る。実はふたりともつらかったとかはつらい。
- 時間区切って、バラバラのほうが効率いいね、となったらソロに戻る。
- TODOを書くと客観的に見れる
- もう一回とにかく聞くことも技
- slack有料だとリモートペアプロできる
- ペアプロをメインにして慣れた、すぐ声かけることができるようになった。
- ただし、ペアの数だけペアがある。やりやすいやりかたはそれぞれ。
- 現場Railsいいぞ
- ペアプロ = ボルダリング
- ペアプロ = 料理
"Railsで開発できる" への道
- Railsで学んでいくときのアプローチ
- 書籍での体系的な知識 (学ぶ/技術を広げる) & 実践と実務(考える/技術を深める)、両方大事。
- 学びて思わざれば則ち罔し、思いて学ばざれば則ち殆し
- 学ぶだけだと身につかない、考えるだけだと独特の癖がつく、視野が狭くなる
- 学ぶと考えるを行ったり来たりするのが良い
- Rails5速習実践ガイド(買いました!!
- 執筆に2年...!
- 読まなきゃ、そして本の力を借りてRailsバージョンをあげるぞ
- 入門編
- 本気エリア
- Chapter4: ログイン、管理機能曲者。買いてても大変だった。ハード。
- Chapter5: RSpecにした。minitestと悩んだ。
- Chapter6: ここまで物を作ってきたけど全体をフォローする。
- Chapter7: レシピ盛りこんで論理削除の要素を落とした。よくばった。
- レベルアップ編:
- Chapter8: JSについてチームで相談するための土台を作る。章ごと落ちかけたが入った。
- Chapter9: GitHubでチーム開発、段取りの紹介。ひとりでからチームへ行った時にびっくりしないように。
- Chapter10: 万葉のみなさんの複雑さへの向き合う気持ちが詰まっている
- 学ぶ: 早めに全体像を示す > 表や図などで網羅 > 色々な話題を取り入れる
- 考える: 具体的なコード、網羅の後に具体例を示す、本文が深いと筋が見えなくなるので脚注やコラムをいれる
- おおおお https://github.com/everyleaf/el-training
- 辞書編纂みたいになった。大変だった。
- 複数著者のメリット: パワーがある、土壇場パワーすごい。デメリット: 安心しちゃってやばい、やりとりで時間がかかる。
- 複数著者の教訓: あなたはこの章ね、よーいどん、でなく、最初にガイダンスで意思統一が必要だった。あらすじが必要だった。
- 横割り分担もいいかも。コード、文章、技術検証などの区分で。
- Railsで開発できるへのハマりポイント
s-dev talks #5「プロトタイピング」 参加メモ
一般参加しました!
資料もアップされています: s-dev talks 〜サービス開発勉強会〜 #5 「プロトタイピング」 - 資料一覧 - connpass
実装より実践すべし、ということが詰まったお話をたくさん伺うことができました。 勢いで年末LTの申し込みをしてしまったのでネタを探したいと思います。
以下伺ったお話や会の感想メモです。
sdevtalks#5
- おしゃれオフィスだ 会場: 株式会社クラウドワークスさん
- エンジニアがいっぱいいる、みんなどこから湧いてきたんだ(普段ぼっちなので毎回びっくりする)
- 最初からお酒やピザを提供していてカジュアルな雰囲気、硬くない、「乾杯から始まる勉強会」
- 参加確認はconnpassの紙を印刷してあって来た人が丸をつける。わかりやすい。
- ホワイトボードと付箋が準備してあって、参加者が会についての意見、感想、次回テーマのリクエストをできる。ものすごく良い。
sdevtalksとは?
- 職種単位でなく「サービス開発者」単位のコミュニティ。なのでデザイナーさんやPMさんとかもたくさん参加している。めっちゃよいなぁ。
- 今回のテーマは「プロトタイピング」
目的別プロト検証のススメ
- https://tockpop.moneyforward.com/ のクーポン画面のデザインプロトタイプについて
- ユーザへ良いものをできるだけ早く届ける、プロトタイプは無駄な議論や思い込みを回避できる
- ふせん+ペン、Sketch + Invision
- 要素の選定: どの要素が入っていると良いか
- 順番をつけてください
- 理由はなんですか
- デザイン: どんな印象を与えたいか?
- チェックしてほしい項目、違う項目を準備しておく
- クーポンアプリにスマートさは求めてないとかの率直な意見が得られる
- ユーザビリティ
- 操作を完了できるか、感想を口に出しながらためしてもらう
- 登録できるか、クーポンをつかえるのか、退会できるか
- 画面遷移ができる状態になっている ->ロゴが押せないとかの意見が得られた
- 自分のテンション上がるダミー画像を使ったりする
- 長方形の付箋がスマホサイズにぴったり
- Q: デザインの検証項目はどういった基準で決めたのでしょうか?
- 感じてほしいキーワードをチームで出して決定している スマートよりはポップ、親しみやすい など -「女らしい/男らしい」 -> どっちでもないからわかんないです という答えが狙い通りだったりする
- Q: プロトタイプの調査の対象となるユーザは誰?
- 本当はユーザになる人が直接つれてくればいいけど、社内で条件に当てはまるひとを何回か決めていた。
- 実家に住んでいたので家族に聞いたりとか。
- Q: SketchとInvision 、Invisionの検証でできなかったこととかは?
- 基本的にはカバーできた。タブのスワイプは厳しかった。
- 連続でアップロードすることでスワイプっぽさを再現できた
- Q: アンケートばらつきすぎたらどうする?
- だいたいは意見まとまってくる。その中で共通項を見つけて検証をすすめる。
~ エンジニアがユーザーテストをやってみた ~ 高齢者UIプロトタイプ検証の学び
- 最初のプロトタイプは何故ダメだったのか? -> 合意のためのプロトタイプだったから
- ちゃんとターゲット層に当たって実際に観察 -> 問題点の発見
- 高齢者の知り合いの確保: 公園にいる人
- 都会の高齢者、ITリテラシーが高い
- インタビューする人と観察する人を分ける
- 標準UI(select)でなく数字直接入力 -> ATMからヒントを得た
- あいうえお表配列にした -> カラオケのデンモク
- フラットデザイン的トレンドよりも見やすい色・文字を重視。ぐっと押し込む人がおおい。
- ちゃんと使ってもらえるようになったとのこと、すごい...。
- 課題発見のためのプロトタイプ 。「こういう動きをしてください」と言って観察する
- Q: どうすればいいの?って言われたときにどう切り返したんですか?
- 受付ですという設定をちゃんとしておく。僕は教えれませんと断ると、自走してくれる。
- それでも聞いてくる人はいるけど、教えないのを徹底する。
- Q: 高齢者以外は考慮されていたのですか?
- 検討していない。若い人は勝手に自走してくれていたので、そこは無視した。
- 受付の人の業務負荷を減らすことを重要視した
- Q: 最初の時点で高齢者の方に聞いてみるという選択肢はなかったのか?
- 設立前の話。ビジネスモデルを探っているフェーズ、かつ、メンバーにデザイナーもいなかった、知り合いに高齢者もいなかったので、決裁者のニーズを優先した。
スマートスピーカー(R&D)のプロトタイピングについて
- R&Dチーム: ZOZOさんの研究開発部門、ちょっと未来の生活者が使うプロダクトを発明する
- 新技術の検証: 爆発的に普及したときにどうなるのか?ユースケース
- ユーザ価値の検証: 仮説>似たユーザにインタビュー>ペルソナ化
- 緑のパンツにあう服は?
- 最初はコードは書かずに仮のロールプレイ環境を準備して触ってもらう感じ
- 検証ができたら作ってみる
- 検証結果をプール: 社内に公開して定量、定性 的データを貯める
- 社内会でリリース告知
- データをストックするチームが社内にあるのすごい、ZOZOさん強い...
- Q: 服以外の領域にも広げられると思うが検証領域のやるやらないはどう決めるのか?
- ファッションという軸に絞っている。あとはミッションに沿うと絞られていく。
- Q: スマートスピーカーってどこにあるという想定でやったのか?どこでもある?
- リビングのテレビ台の横か、洗面台か、キッチンか、くらいの想定をした。
- 後はスマホとか証明とかどこにインプットがあるか分からないので色々想定している。
- Q: チームで未来はこうなるはずだというディスカッションをしたのか?チーム内でどうやってコンテキストを揃えたのか、その工夫は?
- スマートスピーカーのチームは2人ですぐ隣にいるので、議論がしやすい。
- 社内ドキュメントを常に何の議論が起こったのかを記録に残している。
- プレゼンのタイミングで資料を作りながら振り返り、地盤をかためて進める。
- Q: プロトタイプ、シーンを絞っているがどんなフィードバックを得られたか?
- 夕方みんなつかっている。みんな朝余裕なくて使えない。
- 土日の前に事前に考えておくタイプ。前から悩んでたことを相談するタイプ。
- 服選びの課題にいろんなアイテムを聞かれると思ったが、同じアイテムについてばかり聞かれる。
- Q: R&Dは周りを巻き込む意識のたかい組織。こういうやり方ならみんな参加してくれているのはどうやっている?
- 新しいことやってるって楽しそうだよね、いいよねというところで巻き込みやすい
クックパッドマート立ち上げにおけるプロトタイピング
- クックパッドマート: https://cookpad-mart.com/ 食材を注文して近所で受け取れる、エリア限定でサービス開始中
- 現実世界を巻き込むプラットフォーム: とにかくキャストが多くて複雑,各関係者の気持ちにたって考える
- オペレーションミスが起きづらい仕組みづくり、生鮮食品の扱いが難しい、現場の制限
- サービスにたどり着くまでの紆余曲折
- 買物代行で料理は楽しくなるのか? の検証: to 社内スタッフ
- アンケートではふわっとした答えしか得られない
- 制約: スタッフであってもお金を払うこと、それによって真剣度が変わる
- 注文をスタッフから受付、自分たちて買い物、届けるというフローをやってみて検証から。
- 既存のありものでフローを再現する。SpreadsheetをRDBっぽくして運用。メールとslackで注文通知、決裁はSquare。
- 普段買わないものが喜ばれる、社内から自発的な料理投稿がされるなど、フロー再現から学びが多く、そこから価値がありそうというところに早くたどり着ける。
- 接点のあまりないユーザ... 販売者/生産者のテストは?-> デザインスプリント(3日バージョン)、生産者に価値を感じてもらえるのか?
- プロトタイプ... アプリでなくてよい。内容を理解した上でどう思うか?が大事
- サービス説明しちゃう。注文からのオペレーションイメージやロールプレイを実際にやってイメージしてもらう。その後インタビュー。
- スタッフが実際に配送員になりきってやってくるなどで実際のイメージを生産者に強く持ってもらう。
- ネガティブ,ポジティブ意見別で付箋の色を変える。
- ユーザの調理例が生産者にすごく喜ばれるのがわかった。
- 保冷剤の量の話が引き出せる。課題がインタビュー者から提示してもらえる。
- アプリ化しなくていい。
- Q: ビジネスモデル的な試算はどのタイミングで?
- デザインスプリントとは別にやっている。
- Q: 仮説検証の3人は普段なにやっているひと?検証前につくりたい気持ちをこらえた?
- 3人は立ち上げ時のみ、いまは3人ではない。
- エンジニア、エンジニア兼デザイナー、事業部長(PM)の3人
- 前者2名はすぐ作りたがる派ではなかったので、すぐ作りたいという気持ちはなかった。
LT: プロトタイピングとユーザーインタビューについて
- figmaでプレゼン資料作った
- ユーザの求めているものでない必須案件が降ってきた、とにかく大変
- Prott or Figma で 1on1、3週*3人、自由に触ってもらう
- ユーザのセグメントを切る。初心者/ときどき/ヘビー
- カスタマーサポートのメンバーをサービスユーザから確保している。なので、ユーザインタビュー対象もカスタマーサポートのメンバーでいい。ユーザの意見を一番知っていて、リアルなユーザーとしての意見を聞ける
- 意見: クリティカル/want に分けて対応していく
- flamingoさん法人プランできたよ! フラミンゴ ふらっとみんなで語学
LT: デザインスプリントで機能がすっきりした話
- 本の管理アプリを作ろうと思った。
- もりもりの機能を入れようとおもったらエンジニアにこんなに機能いるの?といわれてしまった
- デザインスプリントを省略パターンで実施。
- プロトタイプから方向性などが見えてきた。デザインスプリントの before / after でかなりUIが違ったものとなった。
LT: 進捗ノート
- ずっと右上にTwitterアカウントを出しておくスタイル!うまい
- 頑張っていることを進捗報告したらコメントやメンションをもらえる
- 進捗ノートを使うと共有なのでモチベが維持でき、共有範囲も選択できる
- 個人開発はみんなこれを使ってくれるのか...?という不安が開発中止につながる
- いいねを1投稿にたいして1日1回つけられるようにすることで、継続的に応援してくれる人がいると嬉しくなる
- まだ開発中でも進捗を共有すればフィードバックをさっともらえる
- 進捗ノートへの投稿をTwitterに投げるかどうか使い分けて発信頻度をコントロールできる
- 自分で作っているサービス自体で自分のモチベを保つの強い...!
LT: Supernova Studio 使い始めてみたら割と良さそう
- プロトタイピング後の実装に繋がる話
- プロトタイプを見せうると「できてるやん!」という人がいる 。できてない!
- プロトタイプ -> 実装を早くしたい。SupernovaStudioというのがあるらしい
- Sketchファイルからネイティブを出力できる。すごい。
- viewの開発工数が削減、デザインミス指摘が減る
- 実戦投入開始。結果は将来
- コードがおかしいところもあるけどクセをおさえれば大丈夫
- Sketchの元の画像ファイルの加工とかで出力後の調整工数が変わったりする様子?
スポンサーLT: forkwellさん
次回予告
12月大忘年LT大会: s-dev talks 〜サービス開発勉強会〜 大忘年LT大会 - connpass いきたいです!!(ぽちー
会社のプロジェクターを選んだ
プロジェクターが壊れた
弊社が一軒家にあった頃から活用されていて、その後社長宅で死蔵されてきたプロジェクターがある。オフィス引っ越しに伴い2年ぶりに日の目を見たプロジェクターだったが、いざ使おうとしたところ故障してしまっていた。電源も点くし画面も表示されるが、画面表示後1分ほど経つと、画面中央にぼやっとピンクのもやのようなものが発生する症状が出る。また、それは写真や図の輪郭にもピンク色が表示され、プレゼンなどで画面を切り替えるとピンクのもやが画面に30秒ほど残留する。見辛いことこの上ないし、しかも人間の笑顔の写真とかが映っていると、じわじわと顔の皮膚がピンク色に変色してくる。もはやホラーである。 社内全体での話し合いとかのときにプロジェクターは大変活躍するので、とりあえずなんとかしなければと思った。
修理の余地を考える
Google先生に聞いてみたところ、レンズかランプがダメになるとそういう症状が出ることがあるらしい。もし格安でランプ交換して延命できるなら良いかもと思い、古いプロジェクタの型番 CP-X2521WN
を調べた。ランプは23,812円で売っていた。アンティークか、アンティーク価格なのか。修理の案は即時棄却した。
プロジェクターを選ぶぞ
新しいプロジェクターを買う提案を社長にする決意が出来たところで、参考サイトを元に改めて考えた。
重要な指標はいくつかあるが、オフィスで使うなら最低限これだけのスペックが欲しいなというところを調べ、注目点を2つに絞った。
- 解像度: XGA(1024x768)以上
- 明るさ: 最低2500lm以上 できれば3000lm以上
- (サイズや重さ: 持ち歩く予定がないので考慮しない)
- (焦点距離: 置く位置でどうにでもなると思ったので考慮しない)
- (コントラスト比: とりあえず旧プロジェクターを参考値としたが強く考慮しない)
さっと有名どころの日本製のプロジェクターを調べると、要件を満たすものは5-10万円する印象を受けた。 次にAmazonでの売れ筋とレビューを調べる。すると、2万前後のプロジェクターがずらりと並んでいた。いずれも海外製の様子。 安い方がより助かる、長いものには巻かれろの2視点から、ランキングの上から順に検討して要件を満たすものにした。
Amazon.co.jp 売れ筋ランキング: ホームプロジェクター の中で最も人気のある商品です
そして第2位だった ELEPHAS YG600W
キミに決めた!*1
http://amzn.asia/d/eiC7QHQ
価格はなんと19800円。 あらやだ〜ランプより安いじゃないですか〜。
念のため前のプロジェクタのスペックと、希望スペックと、頼んだ物を比較してみる。 安いけど前使っていたものより確実にスペックは高い品物と考えて良さそうだと思った。
チェック項目 | CP-X2521WN | 希望 | YG600W |
---|---|---|---|
解像度 | XGA (1024x768) | XGA (1024x768)以上 | WXGA相当(1280x800) |
明るさ | 2700lm | 2500lm以上 | 3500lm |
コントラスト比 | 2000:1 | 旧を参考 | 3000:1 |
重さ | 2.3 kg | 考慮しない | 2.2 Kg |
届いたぞ
11/8の夜に注文してもらったら、翌日9日には届いた。むちゃ速い。Amazon恐い。
箱は黒だったが、中身の本体はAmazonのリンク先の通りに白かった。肝心の本体全景を撮り忘れた...。
とくにスタートガイドにキャップを取れと書いて無かった*2ので、最初半透明キャップをつけたまま投影して、光っているけど映らないと思い込んでしまった。かなりあせった。単純に固くぴったりな蓋がハマっているだけだった。蓋を取ると無事投影できた。
最初のようこそ画面的な表示の上部が暗くて、明るさ不足かなと思ったが、いざPCと繋いだら問題なさそうだった。 テスト投影なので超適当に写しただけだが、スライドを映して全社員で見る、という使い方には耐えられそうだ。
それにしても最近のプロジェクターは家で個人的に使う用で特にこだわらなければ1万円以下のものもあるしさっと買えちゃう。 テレビよりwifi機能のついたプロジェクターとかでYoutubeを見倒すみたいな使い方もできる時代だよなぁ...。 安くてびっくりした話でした。おしまい。
31日間記事を書いた感想
2018/10/08~11/06にかけて、31日間続けて記事をアップロードすることができた。 32日目以降、私用が重なったり持っていた記事ストックが尽きたこともあって、とうとう継続できなくなった。以下記念スクショ。
31日間続いたとはいえ、感動的にゴールを達成したとは少々言い難い。やっていく上で、いろんな問題点を感じた。 書いた記事の種類と数を見てみたうえで反省会をしてみよう。
- ただの雑談: 9 (29%)
- 働くときの工夫/考え方: 9 (29%)
- コーディング/ツールの使い方: 7 (23%)
- スタートアップオフィスの話: 3 (10%)
- 勉強会: 1 (3%)
- 読書: 2 (6%)
反省点
体調不良はほんとダメ絶対
ひとつ言い訳をすると、10月中旬の勉強会参加直後に風邪をひき、症状を変質しつつ、かれこれ3週間ほど調子が悪い。咳喘息というやつらしく、なかなか治らない。寝込んでしまって2日ほどダメにした日もあったし、気持ちも下がる。風邪はほんとダメ。 いまも元気なんだけどふとした瞬間にゴホゴホするのでしんどい。インフルエンザ予防接種しようと思ったら医者先生から「咳止まってからね^^」と釘を刺された。咳よ止まれゴホゴホ。
技術系目的だったのに雑談に逃げがち
続けるための策だったとはいえ、雑談の数が多すぎた。 あと引き出しの少なさをほとほと痛感した。
よかったこと
ストックを作ることで継続させた
最初にストックを作っておいたことによって、どうしても時間が取れない日でもストックを消費することで継続扱いにできた。仕事と家事をこなすだけでいっぱいいっぱいになる日がどうしてもある。 特に心が簡単に折れがちな自分には、ストックがあるから明日頑張れば問題ないということにするのは良い作戦だった。
勉強会で発表することの価値の体感
期間中、1回だけ勉強会にLT発表で参加できた。参加にあたって資料作りのために調べたり考えたりした経験の方が、記事を書き続けるよりずっと価値があったと感じた。発表1回のために3本のブログ記事ストックが消滅したので、多分3倍くらいの価値と考えていいだろう。今後は記事の本数を考えるよりも、発表する機会を積極的に探していくほうに変えていきたい。
色々と足りないものが見えた
反省点にもあるように、引き出しが少ないということを強烈に実感した。いざ書こうとして深掘りが出来てないことに気づいてボツにした話題がいくつかある。ボツにしたのもすぐに出せないから(連続更新に間に合わないから)という理由なので、ちゃんと調べて書くという癖をつければ力にしていくことができるはずだ。足りないことを足りないと自覚できたことが良かったことと言えると思っている。
今後どうするか
ブログは続けてみる
前のブログを畳んでからは発信したい技術系ネタはQiitaに書いていたけれど、「Qiitaは、プログラミングに関する知識を記録・共有するためのサービスです。」と 公式の「Qiitaとは」のページにもあるので、イベントに参加した感想とか、個人的などうでもいい話とか、いま働いているスタートアップでのスモールチームならではの特徴的な面白話は発信できなかった。 せっかく個人ブログという形式になったので、そういうよもやま話をコツコツ備忘録していける場として活用したいと思っている。 発信サービスとしてnoteが頭によぎらないこともなくはなかったけど、noteはクリエイターとかお金になるコンテンツを作るための人たちのもので、自分の日記を垂れ流す場じゃないなと思ってやめた。どろどろ気楽に出していきたい。 Qiitaとの使い分けはまだちょっと悩んでいる...。
量より質を目指す
毎日発信を自分に強制したことによって本当にどうでもいい話が30%発生してしまったので、それよりも頻度を落としてもうちょっとためになる話とか、コンテンツとしての面白さを重視したい。いや〜目玉焼きの話とかほんとマジでどうでも良かったです。反省。
本をちゃんと読む
読みたかった本があって、昼休みとかもちまちま読んでいたのだが、毎日発信の開始後は昼休みと帰宅後のちょっとした余剰時間がすべてブログ記事作成に注ぎ込まれ、本を読むというタスクが完全に消失した。記事として読んだ本の感想とかも書こうと思っていたものの、その読む時間を捻出する余裕が無くなるという状況はまずいなと感じた。今回の31日間の挑戦中に書いた2冊分の感想はどちらも挑戦開始前に読み終えていたものだった。今読んでるのは挑戦前から読んでるけどまだ終わっていない...ということは31日間かけても終わっていないということで...。また、記事を出すぞという意識でもっと読む量自体は増やせそう。
勉強会に参加する、あわよくばLT発表する
良かったことにも挙げたように、勉強会で発表するという目標は思った以上に自分を強くしてくれると体感できた。隙間があればシュッとLT発表できるように意識していきたい。そのためにもまずはこの咳喘息をどうにかしないと...。
まとめ
上記に挙げたように、やってみることで色々見えてきた。やはり行動することは大切なんだなぁ。
ちなみにこのブログの開始目的は、最初の記事に一行で書いてある。
長期的目標は弊社にエンジニアという肩書きをもつメンバーを増やすことである。
まだ自分のぼっちエンジニアという状況は変わっていないので、引き続きマッチしそうな人を探していきたい。 そろそろぼっちは飽きてきた!
ファンベース を読んだ感想
以前読破したファンベース の本について感想を書いてみる。
ファンベース ──支持され、愛され、長く売れ続けるために (ちくま新書) http://amzn.asia/d/iAeDvdp
ひと昔前は購買層への主なリーチ手段の「メディア」といえばテレビCM一強だったが、今はスマートフォン経由のWebブラウジングやニュースサイト、YouTubeなど「メディア」という語句が定義する内容は一段と広くなった。情報過多と言える時代において、企業が大事にすべきは実際に商品を購入してくれる人のうち、コアなファンである...ということをじっくり語ってくれる一冊だった。
実際の有名な企業の取り組みも紹介されていて、自分も実際にそれらの消費者のひとりだったので驚いた。
特にじゃがりこは好きなおやつのひとつなのだけれど、じゃがり校というファンサイトの取り組みは知らなかった。
https://www.calbee.co.jp/jagarico-school/
会員限定、かつ、入学試験に合格しないとじゃがり校にはログインできない仕組みになっている。そしてじゃがり校に参加したファンは商品企画プロジェクトに発言を通して参加できる! ごく一部のファンに向けてこんなに濃いwebコミュニティを運営するのは並々ならぬ労力が必要そうだが、ファンベースとして考えればすごく効果的で、それだけの手間暇をかける価値がある。 なんとなく、自分としても、コンビニでじゃがりこを見かけると「わぁ、じゃがりこ好きな人たちがみんなで考えたフレーバーなんだ」と思ってつい手に取るようになってしまった。ファンベース施策の効果が出ている瞬間を体現してしまったといえる。
自分はweb系のエンジニアなので企画方面とかはからっきしだが、メンテしているコンテンツのどういうところをユーザは喜んでくれているのか、とかそういう柔らかいところを気にかけていくことはできる。実装方針で迷った時、エンジニアとして楽な方向に流れそうになったら、ファンユーザはどう感じるのかを立ち返って考えるための指標として受け止めていきたい。
目玉焼きの焼き方の名前(雑学
初めて習った目玉焼きの作り方は、焼き始めたあとに水を足して蒸し焼きにするやり方だった。 自分はこれを唯一無二の目玉焼きと信じて20年ほど生きたあと、一人暮らし中に、蒸し焼きせずにフライパンに落として待つだけで白身が固まるという発見をした。しかもこの方法だと黄身の半熟加減を決めるのが蒸し焼きよりもやりやすかった。
すごい発明だぞと喜んでいたが、これは世界の新発見ではなかった。すでに名前が付いていたのだ。
- sunny-side up: 片面のみ焼く方法
- turn over: 両面焼く方法
- basted egg: 蒸し焼き
世界の物事には大抵新発明というのは残念ながらなくて、大概既存の便利なものや概念が存在している。しかしそれらの既存のものを少しずつ付け足したり、組み合わせたりしてより便利なものを作るということも立派な仕事と言えるはずだ。 自分は多分新発明する力はないけど、gemとか既存のノウハウでサービスを保守開発運営することはできる。できることでとりあえず粛々と頑張っていこう。
朝ごはんの目玉焼きを見ながら、なんとなくそういうことをつらつら考えた。おしまい。