「ユーザーの声」を上手に聞く方法｜けんすう
簡単にいうと、「ものごとに対して、5回、なぜ？を繰り返す」ということが思考を深めるのによいよ、という話です。 元ネタはトヨタとかなのかな？ これは、僕も昔から意識しており、絶対に実践した方がいいものだと思っています。 余談ですが nanapi の共同創業者である和田さんと最初に作ったサービスが「なんで」というサービスです。これは「解決したいことをいれると、5回、なんで？と繰り返し聴いてくれるサービス」です。 ご想像の通り、めちゃくちゃ大したことないサービスなんですけれども、まあ、そのくらいこの考え方は結構大事にしています、ということです。 で、アプリやWebサービスの開発において、この5回繰り返すというのはとても重要です。上記の深津さんの記事でもありますが、特にユーザーから「こうしてほしい」といわれたときには必ずやったほうがいいことです。 この記事では、なぜしたほうがいいか？などの話をした
スピードを捨てる： 成長期の個人開発アプリを頓挫させないための戦略
MarkdownノートアプリのInkdropを一人で作っています。去年の頑張りのお陰で幸いにも月間20万を超える収益化に成功しました。アイデア出しから収益化までの道のりはこちらに書いた通りです。 さて、今後このサービスを継続して成長させていくためには、立ち上げ期とは少し異なる戦略が必要です。それは、課金してくださっている顧客を守る事です。なぜなら、ノートアプリの本質は知見の管理だからです。長く使うほどその価値が発揮されます。なので、当初から事業の継続性は最重要視していますが、運用・保守面においてもより一層気を配らせていく必要があります。 本稿では、個人開発における事業立ち上げ後の成熟化に向けた心構えや戦略について考えたことを書きたいと思います。 勢いに任せるのは限界がある立ち上げ当初はとにかく勢いを大事にしました。頻繁に新バージョンをリリースして、ブログを書いて、盛り上がりを演出しました。
【今日からできる】コミットメッセージに 「プレフィックス」 をつけるだけで、開発効率が上がった話 - Qiita
はじめに 今まで commit message を「なんとなく」書いていたが、プレフィックスをつけることで、コミットメッセージに対する考え方が変わった。 そのおかげで開発効率が上がったので、その内容をシェア。 プレフィックスをつけるってどういうこと？ 以下のようにコミットメッセージの先頭に、なんらかの文字をつけること。 feat: xxx という機能を追加 fix: yyy で発生するバグを修正 refactor: zzz の機能をリファクタ のように feat, fix, refactor などがプレフィックスです。 最近 OSS の Contribution Guide などでよく見かけます。 導入したプレフィックスルール Angular.js/DEVELOPERS.md Angular.js の開発者ガイドに書いてあるメッセージを参考にしました。 以前のコミットメッセージ（例 ちなみ
コードがどうしても動かない時に「Interviews on Skype」Preview版 - Skype blog
短いコードが思うように動かない。迫り来る時間に止むを得ず知っている人に電話してみたが、思うように伝わらない。コードとエラー画面を添付したメールの往復を通じてようやく原因を突き止めるが単純なミスに想定外の時間を大きく割いてしまった。こんな経験はないだろうか。 このようなソースコードに関わる課題を解決する試みとしてSkype.comに「Interviews on Skype」がプレビュー版として登場したことを公式ブログSkype blogが伝えている。Microsoft EdgeとGoogle Chromeで動作する。 Interviews on Skypeは、教えを請いたいユーザーをオンラインのエディタ上に呼び出し、そのコードと実行の様子を共有するもの。向かって左側のペインのコードの実行結果を右側に出力できる。現在、C, C++, C#, Java, JavaScript, Python,
なぜ人は複雑なリモコンのようなWebサイトをつくってしまうのか - ビープラウド社長のブログ
「複雑！すべての機能をとても使いこなせない」 数多くボタンが並んだAV機器のリモコンを見て、過去に思ったことがある人も多いでしょう。 しかし、いざ自分がWebサイトを企画する側になると、複雑なリモコンと同じものをつくってしまいがちです。 誰もが、シンプルで使いやすいWebサイトをつくりたいと思っているはずなのに、なぜ、そのようなことになってしまうのでしょうか。 順に考えていきます。 小さな労力で大きな価値を Webサイトを開発するリソース（お金、時間、人）は、どのような企業でも有限です。 そのため、なんでもかんでも思いついたものを、つくるわけにはいきません。 小さな労力でWebサイトをつくり、大きな価値を生み出す努力が必要です。 そのためには、当然ながらWebサイトの開発スコープを絞ります。 顧客の対象を絞る スコープを絞るには、顧客の対象を絞るのが１番手っ取り早い方法です。 たとえば、顧
SIerの下請け開発者ってレベル低すぎない？ - UXエンジニアになりたい人のブログ
ネット上ではSIer批判＝技術のことをわかっておらずプログラムも書けずPMも出来ない非効率でダメダメな上流工程と、 人月単位での労働力提供という業界の慣習に縛られ、持ち前の優秀な技術力・知識を生かせず非効率な作業を強いられているかわいそうな下請け開発者、という構図が確立されているように思います。 自分が関わるまでは、まあそうなんだろうなと思っていましたが、しかし実際にそういう立場のひとと関わりをもつにつれて、どうもそうではないのではないかと思うようになりました。このあたりの実情を書いていこうと思います。 なお、先に言っておきますが本記事で書くことは、上流工程がどうのとか、業界の多重請け負い構造がどうのとか、給料が安くてとか労働条件が過酷でとか、そういう話とは全く関係がなく、純粋にプログラミングのスキルの話だけです。 対象はおもに詳細設計、実装UTだと思ってもらえれば。外部仕様が決まった状態
「バックログに入らないタスクを可視化する仕組み」という話を技術勉強会でしました - Hatena Developer Blog
こんにちは。アプリケーションエンジニアの id:daiksy です。 はてなでは毎週木曜日に技術勉強会を開催しています。 参考: 寿司と勉強会とエンジニア - Hatena Developer Blog 先週、当番が回ってきたので、「バックログに入らないタスクを可視化する仕組み」というトークをしました。 speakerdeck.com 詳細はスライドを見ていただくとして、この発表で定義された「税」などの用語が、さっそく社内でのコミュニケーションでも使われだして、エンジニア同士で、ある概念について共通の認識を持つためにもこういった場は効果があるな、と実感しました。 はてなでは、アプリケーションを構築する技術だけではなく、プロジェクトマネジメントやチームビルディングの知見などもこうして技術勉強会で共有されています。
コードの半減期とテセウスの船 | POSTD
プロジェクトが発展する際は、単純に新しいコードが古いコードの上に追加されているのでしょうか。もしくは、時間をかけて徐々に古いコードが新しいコードに置き換えられているのでしょうか。これを解明するために、手ごわい GitPython プロジェクトの助けを借りて、Gitプロジェクトを分析する 簡単なプログラム を構築してみました。履歴を年ごとに振り返り、 git blame を実行してみようと思ったのです（この処理を多少でも速くすることは簡単ではないと分かりました。しかし、ファイルのキャッシングを便宜的に含ませることや、変更された点を履歴から見つけること、 git diff を使って変更したファイルを無効にすることなどの詳細を、いつかお伝えします）。 頭がさえている時に、 テセウスの船 をダサくもじって、 “テセウスのGit” と名付けました。私は父親になって、ひどいダジャレを作れるようになった
エンジニア立ち居振舞い：重箱の隅をつつかない - 面白コンテンツ探求日記
お題「エンジニア立ち居振舞い」 自分は重箱の隅をつつかないというのを意識してる。 重箱の隅をつつく問題はコードレビューの現場でよく聞く。レビューの場で所詮「書き方レベル」の指摘が横行してしまうというやつ。 誰しも綺麗なコードを追求したい気持ちはあると思うし、自分もそうなんだけど、あまり良くないなと思ってやらない事にしてる。理由は3つ。 時間の無駄 指摘される側の精神衛生上よくない そもそも意味ない 細かい指摘でも修正してマージするまでには結構時間がかかる。コードを直し、手元でビルド・動作確認し、pushしてCIを回し、「修正しました」と報告し、LGTMが付いてやっとマージできる。このプロセスが日に何度も発生すると確実に時間を食ってしまうし、Nitsな内容を何度も何度も受けると精神的にも疲弊してしまう。それで生産性が下がってしまえばもっと大きな問題になる。 こうした指摘をしたくなる時、「コー
Slackで消えた日報 | ロードバランスすだちくん
シンジです。日報とは一体なんなのか。いや、日報を活用している組織には申し訳ないのですが、日報という単語にポジティブな感じを受ける人は少ない気がしています。そしてシンジチームには日報を送るという習慣はありません。なぜなら日報を書く時間が不毛だと思っているからです。ところがSlackを使うと、分報という形になって蘇ります。 分報（ふんほう）とは Slackで簡単に「日報」ならぬ「分報」をチームで実現する3ステップ 〜 Problemが10分で解決するチャットを作ろう http://c16e.com/1511101558/ このブログを書いた野澤さん曰く、 日報は情報共有のタイムサイクルが24時間→遅すぎる 日報を送る前に課題解決していたら、課題として記載されない→課題解決をチームで行っていたら迅速に解決出来る可能性 などなど、要するに日報など死んでしまえということです（ぇｗ ブログに共感したの
ユーザーに受け入れられ、問題を起こしづらい大規模リニューアルの進め方
iOSDC Japan 2016の発表資料です。 https://iosdc.jp/2016/c/node/84
アプリのアップデートに依存せずにアプリの画面を改善し続ける仕組み - クックパッド開発者ブログ
検索事業部の日高(@kaa)です。 検索事業部では作りたいレシピが見つかることをひとつの目標に、レシピを探す行動を助けることに挑戦しています。 その中で、レシピ検索した際の結果画面でのコンテンツを改善していくための仕組みについて紹介します。 作りたいレシピが見つかるためへの色々なアイデア レシピ検索結果画面でレシピを一覧で見せるだけでなく、作りたいレシピがより見つかるために考えられることはたくさんあります。 例えば もし、入力ミスと思われる検索ワードだったら 正しいと思われる検索ワードを提案、または正しいと思われるワードで検索し、元のワードも表示(Google検索のように) あいまいな検索ワードだったら より具体的に検索できるよう検索ワードを提案。「さっぱり」だったら「冷しゃぶ」「さっぱり 麺」など。 (具体的なワードで検索するとレシピが決まりやすい傾向があります) さらに小分類をもつワー
ポケモンGOを作った男、ジョン・ハンケ独占取材 「忙しすぎてレベル5」 | Forbes JAPAN 公式サイト（フォーブス ジャパン）
7月21日から米サンディエゴで開催された「コミコン2016」。世界最大級のオタクの祭典といわれるこのイベントを今年、大席巻したのがポケモンGOだ。会場ではポケモン関連のコスプレの来場者たちがスマホの画面を覗き込み、捕獲したモンスターを見せ合っていた。筆者はその会場で、ポケモンGOを開発したナイアンティック社のジョン・ハンケCEOに話を聞いた。 「彼らもプレイしてるよ」と49歳のハンケは、歩きスマホのカップルを見て笑った。「あのリュックを背負った男性や、向こうに座っている集団もそうだな」と彼はうれしそうに話した。 ポケモンGOは、記録的大ヒットになり米国人の10人に1人が毎日プレイしている。調査会社サーベイモンキーは米国内だけで1日600万ドル（約6.2億円）の売上と推測する。ヒラリー・クリントンは演説の中でポケモンGOについて触れ、ジャスティン・ビーバーはニューヨークのセントラル・パークで
新卒エンジニア向けに品質の話をした, Asakusa.rb 第368回 - HsbtDiary(2016-07-26)
■ 新卒エンジニア向けに品質の話をした slideshare だと keynote から書き出した日本語が消えてしまうので speakerdeck で。 https://speakerdeck.com/hsbt/yatutemiyou-tqc ペパボでは新卒エンジニアの研修の一環で座学という形で60min何かを講義するという取り組みをここ数年続けているので、自分も品質というキーワードにまつわるあれこれを講義してきた。こういう話、社内では自分くらいしかしないだろうから丁度いいだろうというレベルで若干ふわっとした話をしてきた。 資料だけだと、「ちょっとこれは雑すぎない?」というのがあるとは思うんで、この辺もう少し詳しくということがあったら、是非ディスカッションしましょう → https://pepabo.com/recruit/pepaluncheon/ ■ Asakusa.rb 第368回
『サービスを殺すKPI設定』
小越ブログ スマートニュース株式会社ではたらく小越のブログ。旧：今日のニッパウ ＊スパムが多いのでコメントは承認制になっております。 目標設定の季節になりましたねー。 CC:GotCredit ぼちぼちみなさん決まってきているかと思いますが、 設定の仕方によっては目標がサービスや仕事を殺す事もある、 という件はなかなか見過ごされているんではないかと思います。 私が例として引かせていただきたいのは、「労時売上」という概念です。 労時売上とは飲食の大手チェーン店などでは当たり前に追われているようで、 以下のような指標です。 従業員1人の1時間当たりの売上高のこと。 人時売上高は、次の計算式で求めることができる。 人時売上高＝売上高÷総労働時間数 例えば、売上高が10万円で総労働時間数が20時間の場合、人時売上高は5000円となる。なお、総労働時間数には、社員の他にアルバイトやパートの労働時間を
テストなんか書かなくて良い 僕の考えるサービス開発の肝 - mosa_siru’s blog
世の中は一周まわってエンジニアリングの手法に溢れている。 テストを書け、ドキュメントを書いて冗長化しろ、コミットはわかりやすく、コーディング規約が、安定性が─── でも、それって本質なんだろうか？ 新規サービスを作る際に肝だと思っていることをまとめてみた。 おことわり 以下は少人数で"普通"のアプリやWebサービスを自社で新規開発するときのことを想定しています。大人数で重厚なソシャゲを作るとか、ガチガチの金融系サービスを作るとか、コンシューマーゲーム開発とか、個人で好きなものを作るとか、受託とかは全く想定していません。 基本的に一通り現場をこなした中級以上のエンジニア向けに書いています。 アンチテーゼとして、ややキツめに断定する箇所が多いです、こういう意見もあるんだな程度に受け止めてください。 所属する団体の意見とかは一切関係ありません。 目次 おことわり 目次 ユーザーのことだけ考える
ダレずに開発を走り切る為の習慣
重要なのは、この「煩わしさ」は、「そのタスクを完了した際に、どれだけ体力と意欲を使い果たすか」 の指標であることです。 「技術的には難しくないから、経験の浅い人にまとめてやってもらおう」と、そうした「だるいタスク」を集中させてしまうと、あっという間に人員が疲弊して 最悪離職します 恥ずかしながらこういう経験があります。 「だるさ見積り」した => 予測工数の -5%〜+5% の前倒しor遅延 で済んだ 「だるさ見積り」しなかった => +20%〜40% も遅延した。 終わった後の生産性の低さも本当にもう酷かった。 ごめんなさい。。。。 やろう！『だるさ』見積り！本当に大事だよ！ [見積もり編] 3. OKR を意識したバックログ 具体的には Github の issue サマリを記載していく事柄で実践します Objectives : この PullRequest で何ができてほしいのか サ
水を求めて〜蜃気楼に負けないゲーム開発〜
カジュアルゲームとチュートリアル 〜実はチュートリアルが一番複雑になってませんか？ ちょっとの工夫で改善！〜KayoMiyata
【資料公開】強いチームの作り方 | Ryuzee.com
2015年11月10日に某社の社内勉強会で、「強いチームの作り方」というテーマで話をしたのでその際の資料を公開しておきます。 内容自体は、WEB+DB PRESS 83号に書いた内容なので興味があればそちらを参照ください。 最近DevOpsの文脈ですぐに「インフラ自動化しないといけない」とか「ツール使って効率化」みたいな話を頻繁に聞きます。 が、端的にいえば、「実際のところ、ソフトウェア開発上の問題の多くは、技術的というより社会学的なものである」というデマルコの一節の通りであり、 DevOpsの本質もツールではなく、CLAMS(Culture、Lean、Automation、Measurement、Sharing)であって、土台となるのはやはり組織やチームの文化になります。 一度自分たちのチームや組織について考えてみるとよいと思います。 アジャイルコーチングやトレーニングを提供しています株
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ゲーム開発素人集団がゲーム作り始めて いつのまにか40倍の組織になっていた話
