タグ

関連タグで絞り込む (1)

タグの絞り込みを解除

managementに関するtoenobuのブックマーク (29)

  • Quora: 新しい社員の迎え方について - ワザノバ | wazanova.jp

    http://www.quora.com/Quora-company/What-is-the-on-boarding-process-for-new-engineers-at-Quora スタートアップだと新しい社員を採用したときに、面接までで手一杯で、受け入れ態勢を当日までに用意するのが大変だったりします。「xxさんは今週から入社じゃない?」と気づき、大慌てでPCやソフトの準備をすることもままありました。そして間に合わないという失態もしました。。 数年前の話しですが、Quoraはまだ創業間もないのに、新しい社員を迎え入れる体制がしっかりしていて、エンジニアは、ロゴ入りグッズもらって、hardware/softwareは当然揃っていて、ウェルカムランチをへて、必ず初日に番アップまで経験できるような仕組みになってたと記憶してます。事業の成功を担保するためのせっかくの新戦力なので、優先順位は

  • 【失敗】怖話2年間の総括【無念】 - Fjord, Inc(株式会社フィヨルド)

    @komagataです。 怖話(http://kowabana.jp)の9月のアクセス数と収益のまとめです。 怖話とはスマホで怖い話がサウンドノベル風に見れる・投稿できるWebサイトです。 アクセス数 約156万PVでした。先月が207万PVなので激減です。特に障害は起きていないので先月までで夏効果が切れたといったところでしょうか。 収益 約14万円でした。先月は約21万円だったので激減です。PVなりの減り方です。20万行くか行かないかは大きく感じます。 総括 下記のエントリを投稿して以来、2年間毎月アクセス数と収益を公開しながらやってまいりました。 スマホでサウンドノベル風怖い話投稿サイト « 合同会社フィヨルド 「2013年9月に単月で70万円の収益を上げなければプロジェクトは失敗」とブログでも定義・公言してやってきましたが今月は14万円なので達成率20%で失敗ということになりました。

    【失敗】怖話2年間の総括【無念】 - Fjord, Inc(株式会社フィヨルド)
  • どうすれば小さなチームでも大きな成果を出せるのか 〜 少人数のチーム、低コストで開発を続けていくためのプロセスを学ぶ | Social Change!

    先日3月21日に、スクー( http://schoo.jp/ )という、ウェブ上で様々な授業が受けられるサービスにて、ひとつ講義を受け持って授業をしてきました。 「どうすれば小さなチームでも大きな成果を出せるのか 〜 少人数のチーム、低コストで開発を続けていくためのプロセスを学ぶ」というテーマで授業をしてきました。 オンラインで生放送の授業をするという初めての経験で緊張しましたが、質疑応答で沢山質問も頂けたので、とても良かったです。オンラインの方が、質疑応答で質問が出やすいような気がしますね。 この記事では、その授業での内容や、スライドと質疑応答について書きました。 授業内容の紹介 大きな組織で沢山の量をこなすのは当たり前のことで、あまりクールではありません。少ない人数でも大きな成果を出すには、スピードをあげることと、そのためにも無駄をなくすことがポイントになってきます。 ウェブサービスを

    どうすれば小さなチームでも大きな成果を出せるのか 〜 少人数のチーム、低コストで開発を続けていくためのプロセスを学ぶ | Social Change!
  • Web業界 受注契約の教科書という本を執筆させていただきました。

    こんにちは。株式会社8bitです。 まったく個人的な記事になってしまうのですが、この度レクシスネクシス・ジャパンさんより発売される「Web業界 受注契約の教科書」というの執筆に携わらせていただきました。 2013年11月1日に書店の店頭に並ぶ予定です。 現場レベルでよくありがちなトラブル事例と、IT専門の弁護士である藤井先生が法的な立場からトラブル事例に対しての解釈やアドバイスを書いてくださっています。 Web制作業界の方、特にディレクターや経営者の方々には共感していただけるのではないか、という内容になっており、同業の方であればかなり勉強になるだと思います。 リーガル書という位置付けですが、実際に想定される事例と合わせて法的な解釈やアドバイスが載っているので制作現場の方にも読みやすく、理解しやすい内容になっています。 ということで、今回は書の内容を紹介させていただこうかと思いま

    Web業界 受注契約の教科書という本を執筆させていただきました。
  • Square創業者 ジャック・ドーシーが語った、仕事上で意識している4つの「Do」と4つの「Don't」|U-NOTE [ユーノート]

    U-NOTEトップ ビジネス Square創業者 ジャック・ドーシーが語った、仕事上で意識している4つの「Do」と4つの「Don't」

    Square創業者 ジャック・ドーシーが語った、仕事上で意識している4つの「Do」と4つの「Don't」|U-NOTE [ユーノート]
  • Github Issues を利用したリリースマネージャのお仕事 - hakobera's blog

    最近、Quipper という会社で「リリースマネージャ」という名前のお仕事をしています。開発以外の仕事は久しぶりだったので大変でしたが、最終的にそれなり上手く行った方法を振り返りとしてブログに書いておくことにします。 経緯 自分のチームとは別のチームが開発しているサービスのリリースが迫っている中、それまで開発者の1人がリリース管理っぽいことをやっていたのですが、さすがに開発と管理の二足のわらじが辛くなってきたとのことで、急遽サポート的に自分が「リリースマネージャ」という役割りで参加することになりました。 コンセプト コンセプトは「使用するツールを増やさない」です。 管理のために新しいツールを増やすと、その使い方を教えるなど新たなタスクが発生してしまいます。タスクを減らすためにタスクが増えるなんてナンセンスです。 ということでQuipper では普段の開発に Github を利用しているので

    Github Issues を利用したリリースマネージャのお仕事 - hakobera's blog
  • サービス立ち上げ時のユーザー獲得戦略とその手法

    最近は、サービス立ち上げフェーズの集客戦略や、理想的なスタートを切るための方法についてあれこれ考えることが多いです。 「僕がスピードよりも品質を重視する理由」の続編というイメージもありますが、今回はこのテーマに関して自分の中で大切だと思っていることをまとめてみたいと思います。 理想的な初期ユーザー像を定義する特にCGM型のサービスの場合、リリース後にむやみにユーザーを増やそうとするのはかなり危険だと思っています。 初期ユーザーはサービスの雰囲気を作り、その後の広がりを方向付けます。例えば、彼らが投稿した内容を見て、後から来たユーザーはどんなものを投稿すれば良いかを学びます。ここでうまく軌道に乗ればその後のサービス展開が楽になりますが、逆に失敗してしまうと、その流れを変えるのは容易ではありません。 ドワンゴ会長の川上さんの新書「ルールを変える思考法」を読みましたが、その中で川上さんは、サービ

  • 非開発者もGitHub Flowに巻き込んでみんなハッピーになった話 - Masatomo Nakano Blog

    前提: GitHub flow を使っていてCIサーバーはJenkins 最近ちょっと開発フローの改善をして、とてもよく機能してて満足しているので紹介してみる。 この改善をやる前の悩み: pull-requestでコードレビューはできるのだけど、cssとかjavascriptなどの見た目や動作の変更ってコードだけだとわかりにくい。レビューする人が各自ローカル環境で実行するのもだるい。 コードを読まないデザイナーとかプロダクトオーナーとかの人が、pull-requestのレビュープロセスに簡単に参加できない(非開発者全員のところでローカル環境設定するのはだるすぎる)。 コード的にokに見えてmasterにmerge後、何か問題(特に仕様的な問題や、デザイン的な問題)が発生した場合、「修正branchを作ってpull-request」というフローを再度回さないといけない。最初のpull-req

  • これからWeb系のベンチャーで起業しようと思っている人へ考慮しなければいけないリストを作成した ~技術編~ - nigoblog

    Web系に限らずですがとにかくいろんなことを考えなければいけません。 業界で3年以上やっていたエンジニアならいざしれず、非エンジニアフロントエンドしか触ったことのないエンジニア。 そして学生等々、Web系ベンチャーをやるには案外考えることが多いんだぜってことを伝えたいと思います。 開発編 運用編 まとめ という流れで説明します。 開発編 主にサービスローンチまでのプロセス。 最近でいうとMVP (Minimum Viable Product)だったりアジャイルだったりが流行っていますが、 とりあえずMVPを構築するまでに考えなければいけないことをリストを書いていきます。 1. 言語は何を使うか 一番ベーシックな概念にして、一番重要かもしれません。 とりあえずフロントエンドはさておき、バックエンドをどうするか。 ここで選択肢を上げておきます。 PHP Perl Ruby Python Sc

    これからWeb系のベンチャーで起業しようと思っている人へ考慮しなければいけないリストを作成した ~技術編~ - nigoblog
  • Loading...

  • Webデザイン エンジニアリング---目次:ITpro

    この数年間で,(インターネットの総称としての)Webは私たちの生活に深く関係する身近なツールになりました。様々な情報を,この環境の上で閲覧や操作できることは,特別なものから,徐々に当たり前で,なくてはならないモノに変わろうとしていると言えるでしょう。 特別なものから日常のものへとシフトしていく中で,Web自体も大きく変わるべきところが見えてきています。様々なことが挙げられますが,利用者という立場からすれば,やはり「ユーザー・インタフェース(UI)」が一番の関心事です。 特定のITリテラシの高い人たちだけが使うものではない世界に突入する以上,作り手の側の意識も変化しなければ,ニーズに対応できません。そして,こうしたWebアプリケーションの大量生産の時代にも入っています。今あるWebアプリケーションは,私たちの生活を便利にしてくれていますが,これで十分ではないのです。もっと多くの分野で,もっと

    Webデザイン エンジニアリング---目次:ITpro
  • ネットで見られる提案書のまとめ | Webデザインのタネ

    ディレクターの提案資料を読んでから案件に取りかかることが多いと思います。おかげでさまでデザインの方向性が決まりやすいのですが、他社のディレクターやお客様サイドに立ってる人の提案資料ってどんな感じなんだろうと思って調べてみました。 特定のお客さま向けのものや、どんなお客さまに向けても使えるものまのまで色々見ましたが、自分で「ここならお仕事頼んでみたい!」と思うものを基準にピックアップしてみました。 企画書・提案書 西野有香さんのポートフォリオサイト 広告の企画書や、ロゴ、タイポグラフィ、パッケージとたくさんの種類があります。最終的な形にした経緯が素敵。ロゴを作るにあたって競合もしっかり調査されているのがよくわかります。 サイト:西野有香さんのポートフォリオサイト 村上由未子さんのポートフォリオ コンペ時の提案書のようです。要望を整理し、それらの要望に対してどのようにアプローチをしていくかが、

    ネットで見られる提案書のまとめ | Webデザインのタネ
  • システムの「価値」をどう考えるのか?〜なんで人月換算基準がなくならないか、について - 急がば回れ、選ぶなら近道

    「なんで人月換算基準がなくならないか」については、これは作る側での議論が非常に多いのですが、逆側から見た議論があまりにも少ないので、自分の考えを記録しておきます。そもそも、発注した側ではシステムの価値をどう見るのか?という議論があまりにもなさ過ぎの印象があります。いくら作る側が頑張っても、発注サイドで「いやだから、結局いくらかかったか内訳見せろ」という話になった途端に、残念ながら人月単価が登場するわけで、話は振り出しに戻ります。 まず一義的にはユーザーから見たシステム開発は投資になります。確かに、毎年作っているでしょう、という話もありますが、普通は数年に一回作っては動かして、メンテナンスにモードに移行させる、という形になります。投資として、通常はキャッシュ・アウトに相当するコストで資産を認識します。リースにすれば、定常的でしょうという話もありますが、オン・ブックになった途端に普通に取得原価

    システムの「価値」をどう考えるのか?〜なんで人月換算基準がなくならないか、について - 急がば回れ、選ぶなら近道
  • ディレクターがプログラマーとうまくやる方法を全部教えます : LINE Corporation ディレクターブログ

    こんにちは、櫛井です。 プロジェクトマネージャーやディレクターの仕事というのは多岐に渡りますが、特にプログラマーと上手にコミュニケーションを取り一定の目的を果たすというのはわりと大変なことだったりするらしいです。私は比較的プログラマーとうまくやれているタイプのようなのであまり苦労した覚えが無いのですが、過去10数年で培ったプログラマーと上手くやる方法を紹介していきたいと思います。おまけで「プログラマーに嫌われる6つのこと」も紹介します。 ※うまくやれてるイメージ図 プログラマーと上手くやる方法をざっくり言うと 役割分担として求められていることをやる お互いのTODOを把握し区切りをつける スケジュール管理をしっかりする といったカンジです。ではそれぞれ説明していきます。 役割分担として求められていることをやる そもそもディレクターが求められる役割とはなんでしょうか。Web開発案件におけるデ

    ディレクターがプログラマーとうまくやる方法を全部教えます : LINE Corporation ディレクターブログ
  • プロジェクトマネジメントなう\(^O^)/ | ぽんぽんぺいんなう\(^O^)/

    20代後半から15年ほどSIプロジェクトのリーダー/マネージャーをやってきた経験から。 『 監督とは、 他人が打ったホームランで金を稼ぐことだ。 』 ケーシー・ステンゲル(MLB監督) ●ポリシー 1)全てのメンバーが目的・段取りのわからない仕事をしない/させない。 2)プロジェクトの成功には、短期的な成功と中長期的な成功がある。両方を意識すること。 3)プロジェクトの短期的な成功は、お客さんを満足させることと利益をあげること。 4)プロジェクトの中長期的な成功は、リーダーとメンバーが成長し、また一緒に仕事をしたいなと思い合うこと。 5)リーダーとメンバーがフラットでオープンな関係を築けなかったプロジェクトは、中長期的には失敗する。 6)みんなで得意なことを持ち寄って知恵を出し合ってやってみてダメだったらそれは僕らにはムリな仕事だったということ。 7)人は一人一人別人であり仕事に対するスタ

  • Web制作のリアルな工数と見積もりの話~フリーランス編~

    http://coziest.net/?p=572 のパクリです。 WP-Dの元記事や上記ブログの記事を見ても納得しない人は多いでしょう。なぜか。 「制作会社の視点であって、フリーランスの視点で考えていない」からだと思います。はてなにはフリーランスの人が多いのです。 そこで、細々と10年フリーランスをしている自分が、「フリーランス編」として工数と見積もりの話をしたいと思います。 ■依頼内容 個人なので、100ページ以上必要なサイトを依頼される事は稀です。顧客も、中小・零細企業がほとんどでしょう。 ここでは前提条件として、「30ページ前後のホームページをWordpressで管理できるようにする」というリニューアル案件を想定したいと思います。 そしてこのぐらいの規模の場合、納期は概ね1ヶ月前後とだと考えられます。1ヶ月は待ってくれるけど、それ以上かかるようなら破談になる可能性が大です。 ■見積

    Web制作のリアルな工数と見積もりの話~フリーランス編~
  • はてブで爆釣れする見積書の作り方

    1週間ぶりに登場のWP-D Blueです。いやー、思ったよりバズりましたね。ウェブ制作の見積書です。 このエントリーでは、あの見積書に様々に仕掛けたトラップについて解説したいと思います。まだ前記事を読まれていない方は、短い記事ですので、先に目を通しておいていただければと思います。 まず、WP-D読者の方に謝っておきましょう。クリアさんが「リアルな工数と見積もりの話」を書きました。私は「見積もりを金額付きで晒してやろうじゃないか」と言いました。「リアルな見積書を金額付きで晒してやろうじゃないか」とは言っていません。あ、石が飛んできそうな予感がしてきました。 リアルな見積もりとは言ってないもんね! 実際のところ、クリアさんの記事「WordPressのリアルな工数と見積もりの話をしようじゃないか!」ではかなり細かく作業内容と工数が記載されていましたね。デザインがトップ及び下層ページで丸まってる点

    はてブで爆釣れする見積書の作り方
  • ウェブ制作の見積もりを金額付きで晒してやろうじゃないか!

    はい高いですか?こんなもんですか?以下見積もりの説明です。 リニューアルと言っても、既存サイトはCMS化されておらず、たいして情報もアップされていなかったため、ほぼほぼ新規案件に近い、というイメージです。そのため、旧システムからのデータ移行費用が入っていません。その代わり、商品データベースは既存のものがあり、定期的にそこからデータを吸い出してCMS側の商品ページに反映するというカスタマイズが入っています。色々調査した結果、1週間でできそうという見込みのもとに見積もりしていますが、この要望はなかなか軽く収まらないことが多いですね。 コンサルティング費用にどのくらいかけるかというのはサイトの規模感によってまちまちだと思いますが、誰に向けたサイトで、何の目的で、対象となる閲覧環境は、用意するサーバーは、考えられるリスクは、など細かく資料に起こしていき、事前に複数回クライアント往訪のうえ打ち合わせ

    ウェブ制作の見積もりを金額付きで晒してやろうじゃないか!
  • 昨今のwebディレクターは「データ分析」「A/Bテスト」病にかかってしまい、考え方のスケールが小さくなっているのではないか。 - webディレクターのネタ帳

    追記: 捕捉となるエントリーを書いてみました! blog.egachan.net A/Bテストについて 最近のwebサービス事情として、大手資の会社などもガンガン参入しているため、 「サイト立ち上げ」→「適切なプロモーション」→「継続したサイト改善・運用」 という風な3つの流れはマストな時代になってきたと思います。少し前までは、「素晴らしいサイトを作れることだけで人が集まる」「素晴らしいサイトと上手なプロモーションだけでサービスは活性化する」という時代だったのですが、最近は、そこまでは当然として、さらに「継続したサイト改善・運用」がマストな時代になってきたと感じています。(この三位一体を適切に行っても、流行るか分わからないのが、webサービスの世界で、そこが難しいのですが。) ただし、サイト運営を継続的に行なっており、一定の機能が回りだし「改善・運用」フェーズに入ったサイトの施策を考え、

    昨今のwebディレクターは「データ分析」「A/Bテスト」病にかかってしまい、考え方のスケールが小さくなっているのではないか。 - webディレクターのネタ帳
  • 事業会社側、発注側のディレクションスキルも底上げを――「0からのウェブディレクション講座:設計編」に参加してみた | yfujimura Weblog

    ストリートアカデミーが主催する『0からのウェブディレクション講座:設計編』に参加した。自分は事業会社側でWebを作るWeb担当者という位置づけだが、Webディレクションを体系的に学んだことはなく、独学で、ほかの人のやり方を見よう見まねで習得しながら、ディレクションをやった。「そのやり方が正しいのか」という確信がないままに。 この講座では、Webディレクションの「設計」の部分を特に重点的に学ぶことができた。その学びと自分のWebディレクションのやり方を振り返りながら、感じたことを残しておく。ポイントは記事タイトルの通り、「事業会社側のWeb担当者のディレクションスキルの底上げが必要じゃないかな」という点に尽きる。 Webディレクションの根幹をなす「情報設計」に力を入れていますか? Webディレクションの仕事を進めるにあたり、自分が最初のころにやっていたのは、頭の中にWebサイトのイメージを描