サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
Wikipedia
shinsemiya.hatenadiary.jp
タスクをReadyにしないとなにがまずいか? たまに聞かれる質問です。 簡単に言うと ・見積精度の向上 ・タスク失敗率(炎上ないし未完成での撤退)の大幅な削減 ・プロジェクトのリスクの削減 の3つです。 タスクが予想より大幅に時間がかかるケースにおいて調査したことがあります。 実態としてはReadyになってからDoneになるまでのリードタイムは予想通りだったのですが、Readyになるまでの時間が大幅にかかっていました。 またReadyになった段階で作業量がほぼ確定します。 ですのでReadyになっていない=作業量が確定していません。 この段階で「3日で終わります」というのは非常にあやふやな見積りです。見積りというより勘による占いです。 そしてこの勘がはずれて、炎上し、最悪撤退する。 それらが積み重なってプロジェクトのリスクになる、というわけです。 以上の理由から私のチームにおいてはRead
代々木にあるピクシブ株式会社を退職していました。 なぜか12月にかけて会社の会議室をイベントの会場として使用したいという旨の相談が急増していたので私はもう代々木の会社にはいないよ、ということをここに明言しておきます。 社員の方、連絡がある場合は2つだか3つだかあるという元社員グループのどれかからご連絡ください。 在職中はBOOTHというクリエイター向けECサービスや、自社配信の広告管理システムなどを作っておりました。 またpixivのUIリニューアルにも関わっていました。 今はB2B系のサービスに関わっています。 トレンドの移り変わりで、億単位の月間PVや100万単位のユーザーを確保できないと収益的に辛い2Cサービスよりも、2Bサービスの方が今後は伸びると思っています。 もうアガってしまったサービスを作るより、これから伸びるサービスを作る方が楽しかろうということで成長期の会社に入りました。
30歳当時は某pクシブ社に雇用されていました。 今は雇用関係にありません。 もう2年以上経っているので、今は評価制度なども違うそうなので、時効だと考えています。 会社も給与体系もなんか昔と変わっているそうなので、今あの会社に入りたい人には参考にならないと思います。 雇用当初の説明では27万円 * 12ヶ月 + 夏冬賞与が1ヶ月分 + 住宅補助5万円 * 12ヶ月分、残業代なし裁量労働制438万円という説明でした。 なのでその額をもらっていたことになります。 そこから昇給が一切なく、時々賞与が少なかったり出なかったり、あと電車遅延とか関係なく月3回、朝10時に遅刻したら減給(精勤手当とかいうのがあってそれがなくなる。他社でもそういう制度があると聞いたのでよくあるのでしょう。社会は厳しい)で、その年は電車遅延が多く、上記の減給があり満額は出なかったですね。 裁量労働制だったので残業代はありませ
最近の日常 最近、データ解析にはまった。 実践してみたところ「男女比は50%である」「身長が高い人ほど体重が大きい傾向にある」というレベルの大変有益()な解析結果が得られ、真剣に反省する必要に駆られた。 前書き コミケのユーザー層をサービスに取り込めないかという話が会社で出た。 ちょっと調べてみたが、なかなか面白かったので分析した結果をここにまとめる。 調査結果から読み取れる内容からは、興味深い結果がわかるとともにデータ解析でよくある「誤った解析結果」を出す条件が揃っていてとてもおもしろい。 会社でこの話をしようとしたがエンジニアがコードがでない話するのも肩身がせまいのでここで書く 種本 コミックマーケット35周年調査報告 注意:これは6年前の調査報告書 昨年の調査報告書も持っているが、裏取りの都合から一般公開されている方が良いと考えこちらを選んだ。 読み解くと? アンケート以外で公表され
前提条件として ターゲットとなるユーザー層に知り合いがいることが前提です。 え、いない? 作りましょう。いないと話になりません。 え、つくりたくない? 興味を持つつもりもないユーザー相手に商売してもうまくいきませんよ。 システムしているの? 検証でやることはほぼ地道なアナログ作業です。 このあたりの作業を最後までやりきってルーチン化できれば自動化できます。 ようするに最初はほぼアナログです。この作業に限って言えば、ディープラーニングや機械学習は「機械に任せられるフェーズが早められる」「分析する変数が増やせる」くらいの効能しかありません。 これを1サイクル回すのにどれくらいかかる? 約2週間〜4週間 1~2イテレーションくらいです。 施策を検証せずに打つより時間はかかります。しかし有効度が高いためこの方法を採用しました。 「連射性」より「命中性」を重視した施策の打ち方です。 大事なのは「有効
Advent Calendar この記事はProduct Owner Advent Calendarの3日目です。 Product Owner Advent Calendar 2015 - Qiita 挨拶 こんにちは、瀬宮です。 プロダクトオーナーの役割の1つとして、チームをまとめ、市場的成功のために努力するというものがあります。 今回はチームメンバーの意識をまとめ市場的成功のほうを向かせる努力をした話をします。 やったこと 他社のチャットで定期的にプロダクトのサマリーデータを通知するbotがいて、便利そうだったので自分のプロジェクトでも実際に作ってみました。 このbotはチーム向けチャットに自動でつぶやきます。 チャットに載せる情報はチームメンバー向けです。 注意 この記事ではbotの実装には触れません。 hubotで作った系列と直接Slack APIを叩く系列があります。 botにデ
会社でカスタマージャーニーの話が出ていたのでちょっとここに書く。 カスタマージャーニーについて悩んでいた彼がここを見るかもしれないし見ないかもしれない。 もし見たのなら助けになればいいと思う。 あくまで私の一見解であるので特に勧めたりはしない。 また一見解であるので、真に受けて痛い目みても責任は取れない。 本題 さて、私はカスタマージャーニーとはUX設計の一手法だと思っている。 ここにAirBnbのカスタマージャーニーの図があるんだが、これはわかりやすい。 ただしわかっている人間にとっては。 わかっていない人間にとっては非常に誤解しやすい図だと思っている。 ドツボにはまるケース わかっていない人間は手続き的にユーザーの動作を列挙しようとしてドツボにハマる。 つまり行動を列挙し、それにともなう感情を付け加え、最後に書き連ねた内容を総括して「結局ユーザーは何をしたい?」を書く。 順番として 行
この記事は アジャイルCasual Advent Calendar 2014 - Qiita の23日目です ネタが足りないのでこの前聞いた話をまとめて埋め草にしようという魂胆です 情報を集めない ビジネス判断を行う際には、判断材料として情報が必要です。 不足があるとその部分を「勘と経験」で埋めます また、情報をむやみに集めすぎると重要な情報がそうでない情報に埋もれて有効に活用できなくなります。 ローマ初代皇帝が元老院の定数を倍に増やしたことでに(彼の目論見通り)元老院の力が弱まったことに似ています。 重要な情報と、そうでない情報とはなにか、を定義しないこともこの傾向を加速させます。 ドメインを理解しない ドメインとはどういった構造をしているか? ビッグプレイヤーが存在しないとしたらなぜ存在しないのか? ユーザーやニーズの所在や構造をモデル化しているか? …これらを行うためにはドメインへの
この記事はRuby Advent Calendar 2014の15日目の記事です。 Windowsで動くexeファイルをRubyで作りたい! 序論 何をどうとち狂ったか、「ゲームを作ろう」「Windowsで動くexeファイルをRubyで作りたい!」そう思い立った俺たちは一路南米にとんだ。 南米では特に何も見つからなかったが、かわりに目的の技術であるJRubyFXとrawrという技術をインターネットで発見した RubyでGUIアプリを作るならJRuby+JavaFX+Rawrで決まり! - かなりすごいブログ なお作者はRuby AC 17日目担当の @supermomonga ももんが (@supermomonga) | Twitter さんであります。ありがとうございます! JRubyFX とは JavaFXをjrubyから使えるようにするライブラリである。 ControllerとMod
この記事は Ruby on Rails Advent Calendar 2014 - Qiita の17日目です。 前回は @gogotanaka さんの Railsを作った男たち - Qiita でした。 複雑な処理 is つらい Railsで複雑な処理を書くと死ぬ。 即死はしないけどあとで何度も苦労される 運用しつづけるとリソースをけっこう食っている事に気づく。 いわばエナジードリンク。開発の活力の前借り 複雑な処理を避けるには? 処理の複雑さ=仕様の複雑さ 複雑な仕様を簡単な仕様にすれば、処理も簡単になる 最初の段階でドメイン設計やモデリング、デザインを頑張れば簡単にすることは可能 最初にリソース投下して設計する事、また途中で定期的に再設計、リファクタを繰り返し整理された設計を維持し続ければ複雑なドメインは避けられる。つまり複雑な処理も避けられる、はず。 ところがぎっちょん すべての
この記事はアジャイルカジュアル Advent Calendarの1日目です。 インセプションデッキを作るときに、「このプロジェクトをこのまま進めたらヤバい」という危険信号がある。 それが出ている状態で進めると、だいたい炎上することになる。 炎上とは最後に燎原の火のごとく燃え広がるが、その火種は初期の段階から存在する事が多い。 もし火種を見つけたら、消してほしい。それが無理なら止めるか、せめて上司にエスカレーションした方がいい。 火種は恥ずかしがり屋なので、開発のカオスに隠れていないと自分の力を強める事は出来ないからだ。 今回はその実例を書く パターン1.エレベーターピッチを作る が すごいゆるふわ エレベーターピッチというかこのプロダクトを一言で言うと?でもいいと思う 例えば、飲食店を作ろう!というテーマで 良い例としては「最高の洋酒とそれに合うツマミを出すBAR」みたいな感じ。 聞いただ
このページを最初にブックマークしてみませんか?
『shinsemiya.hatenadiary.jp』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く