よもやま話β版

よもやま話を書きます。内容はぺらぺら。自由に書く。

s-dev talks #5「プロトタイピング」 参加メモ

一般参加しました!

s-dev-talks.connpass.com

資料もアップされています: 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さん

  • エンジニアファースト、エンジニア支援
  • スポンサー総額 900万円(!)
  • オープンポートフォリオ
  • ロボットがGitHubを分析して紹介してくれる、面白そう

次回予告

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恐い。

f:id:beta_chelsea:20181112100335j:plain 箱は黒だったが、中身の本体はAmazonのリンク先の通りに白かった。肝心の本体全景を撮り忘れた...。

f:id:beta_chelsea:20181112101318j:plain とくにスタートガイドにキャップを取れと書いて無かった*2ので、最初半透明キャップをつけたまま投影して、光っているけど映らないと思い込んでしまった。かなりあせった。単純に固くぴったりな蓋がハマっているだけだった。蓋を取ると無事投影できた。

f:id:beta_chelsea:20181112101431j:plain

f:id:beta_chelsea:20181112101853j:plain 最初のようこそ画面的な表示の上部が暗くて、明るさ不足かなと思ったが、いざPCと繋いだら問題なさそうだった。 テスト投影なので超適当に写しただけだが、スライドを映して全社員で見る、という使い方には耐えられそうだ。

それにしても最近のプロジェクターは家で個人的に使う用で特にこだわらなければ1万円以下のものもあるしさっと買えちゃう。 テレビよりwifi機能のついたプロジェクターとかでYoutubeを見倒すみたいな使い方もできる時代だよなぁ...。 安くてびっくりした話でした。おしまい。

*1:2018年11月上旬時点でAmazon売れ筋ランキング2位。1位は明るさが少し希望より足りなかった。

*2:もしかしたら書いてあったのかも?見落としただけで...

31日間記事を書いた感想

2018/10/08~11/06にかけて、31日間続けて記事をアップロードすることができた。 32日目以降、私用が重なったり持っていた記事ストックが尽きたこともあって、とうとう継続できなくなった。以下記念スクショ。

f:id:beta_chelsea:20181108000107p:plain

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とか既存のノウハウでサービスを保守開発運営することはできる。できることでとりあえず粛々と頑張っていこう。

朝ごはんの目玉焼きを見ながら、なんとなくそういうことをつらつら考えた。おしまい。

最高と最低限の開発グラデーション

とある機能を開発するにあたって、最高を目指す開発と、最低限の開発と言うものがあると思う。 ざっくり箇条書きしてみよう。
ただし、 どちらも要件は実現されていて、機能は正しく動いている ものとする。

最低限の開発

  • 設計がちょっとあやしい
  • テストコードがない
  • 命名がダサい
  • 野暮ったい実装
  • コピペコードを含む
  • 見落とされたtypoがある

最高を目指す開発

  • 将来のことも検討されているシンプルで美しい設計
  • メンテしやすいテストコードがある
  • よく検討された分かりやすい命名
  • スマートな実装
  • コードが適切に再利用されていて重複していない
  • typoなどの安易なミスは駆逐されている

開発のグラデーション

何事にもハイとローの2方面があって、そして選択肢はその両極端にあるのではなく、常にその中間のどこかにもたくさん存在する。 以前お世話になった方がよく言っていた「グラデーション」という単語を強く覚えていて、自分も参考にしている。 開発にもグラデーションがあって、時と場合に応じて一部取捨選択をする場合がある。

設計を綺麗にしきれずにある程度で妥協するとか、
テストコードが一部省略されたりとか、
安易なtypoミスを気づいたけど修正する余裕がないとか...。

その時々で納期とかチームの総合力とか、色々な周辺要素に応じて出来る限界は決まってくる。 もちろん最高の開発を目指すことがベストだが、要件の実現に対してかけるべきコストと天秤にかけてうまい具合に妥協点を探り、確実に要件を達成していくほかない。ベストな妥協点を探って実装に落とし込む力というのも重要なのだ。
そう自分に言い聞かせながら、今日も最高と最低の合間の出来の実装をmergeするのだった。

ちなみに

最低限の対義語、一応「最高限」というものがあるようだが、耳慣れない。 人間高みを見るとキリがない(から、限という漢字がつくと違和感がある)ということなのだろうか...。

kotobank.jp

Rubyのnext, return の違いを再履修

qiita.com

完璧にハマったところを、上記記事に救われました。感謝... :pray:
自分でも再履修してみる。

サンプル

次のような実行結果を期待してコードを書いたとします。

hey
hello
hello
# hello.rb
def hello
  3.times.map do |n|
    return 'hey' if n.zero?
    'hello'
  end
end

puts hello

しかし実際の実行結果は次のようになります。

hey

なぜそうなるのか

return の説明を改めて見直してみます。
https://docs.ruby-lang.org/ja/2.5.0/doc/spec=2fcontrol.html#return

式の値を戻り値としてメソッドの実行を終了します。

hello.rbreturn と書いているのはブロック内ですが、あくまでメソッドの終了を支持しているので、helloメソッドの戻り値として「hey」が返されました。ブロックの戻り値を指定したい場合は next を使います。

https://docs.ruby-lang.org/ja/2.5.0/doc/spec=2fcontrol.html#next

nextはもっとも内側のループの次の繰り返しにジャンプします。

# hello.rb
def hello
  3.times.map do |n|
    next 'hey' if n.zero?
    'hello'
  end
end

puts hello
hey
hello
hello

基本はメソッドが戻り値を返すコードを書くのですが、そのノリでブロック内でreturnを使うとまずいですね。

ちなみにバグは自動テスト(RSpec)によって気づくことができました。
やはりテストは重要。