イノベーション イノベーションを起こすためのスキルを習得し、業務に活かす方法を学びます。
Google re:Work - ガイド: OKRを設定する
イノベーション イノベーションを起こすためのスキルを習得し、業務に活かす方法を学びます。
スケールドメテオフォール開発 - hogepiyohoo’s blog
序節：はじめに 近年、日本型の開発プロセスとして メテオフォール型開発 - 実践ゲーム製作メモ帳2 が注目を集めている。 eiki.hatenablog.jp 上記のメテオフォール開発では、適用対象は開発チームである。 （本稿ではこれをオリジナルMF開発とよぶ） 一方最新の研究では、これをより大きな企業レベルで適用する事により、更なる災厄効果をもたらす事が明らかになってきた。 本稿では、企業レベルでメテオフォール開発を適用する為の手法「スケールドメテオフォール開発」について、概要を説明する。 (オリジナルの方に迷惑かかるとアレなので補足:オリジナルMFを書いた方とは全然関係ない人のポストです) 第一節：スケールドメテオフォール開発 オリジナルMF開発では、単一の開発チームを想定している。 そしてこうなる。 一方、スケールドメテオフォール開発では、複数の開発チームを含む、企業全体が対象となる
重大事故の時にどうするか？｜miyasaka
ヤフー時代の部下から突然メッセンジャーが。 「以前宮坂さんが緊急対応時に残して頂いた言葉を今度セミナーで使っていいですか？」 と。 リーダーの仕事はいっぱいあるけどなかでも大きな仕事の一つは重大事故の発生の時の陣頭指揮。平時は部下で回せるようにするのがマネジメントだけど、危機の時まで部下にまかせるわけにはいかない。 お恥ずかしながらヤフー在職中の22年で何度か重大事故を起こし関係者の人に多大な迷惑をかけてしまった。その度にその陣頭指揮をとった。 結果的にヤフーのなかでもっとも深刻な事故対策をやった人の一人じゃなかろうか。そのなかからノウハウ的なものがたまってきたものを部下にメモしておくってあげたものを彼は覚えていてくれたらしい。 彼いわく危機対応の時にすっごく役にたって指針になったといってくれて送ってくれた。 ひょっとしたら他の人にも参考になるかとおもって（若干訂正してますが）ここに残して
サービスに求められるものを、6段階に分類する｜深津 貴之 (fladdict)
「サービスの体験をよくする」というのが、漠然としてどうすればいいかわからないとき、まずユーザー体験を6段階に分類するのをオススメします。 この図をベースに、 ・あなたのプロダクトの現状 ・やろうとする施策やアップデートが、それぞれどのレイヤーに属するかを見て、基本は低レイヤー（機能より）のものから、充足させてゆきます。 下記は、家を例にしたのユーザー体験です。 Lv 0. 存在しない家がない。寒い。そして何も解決してない。 Lv 1. 機能がある屋根と壁と床がある。とりあえず雨風がしのげる。色々と我慢すれば、まぁ生きていける。 Lv 2. 安全と安心地震で壊れない。水漏れしない、火災報知器がついた、ドアに鍵がかかるようになった。最低限の信頼性が担保できる状態です。 Lv 3. 使いやすい、わかりやすいまっとうに使えるか。家のなかで迷わない。生活導線が機能するか。キッチンや冷暖房などがスムー
エンジニアと1on1をするときの事前面談シートテンプレート - $shibayu36->blog;
はてなのチーム横断のエンジニアメンター制度 - Hatena Developer Blog で紹介していますが、はてなにはチーム横断のエンジニアメンター制度があります。僕も最近までメンターとして5~6人ほどのメンティーを持っていました(今は事情があってメンターをやっていないのですが)。 メンターとして1on1をする時には1on1ミーティングに備えるアンケート - しるろぐを参考にし、事前にメンティーに面談シートを書いてきてもらうという工夫をしていました。その面談シートは改善を少しずつ加えながら運用していたのですが、一度知見共有も兼ねて最近使っていた面談シートテンプレートを公開してみようと思います。 面談シートテンプレート 以下のようなフォーマットで書いてもらっています。1on1の前にメンティーに1on1用Google Docsに追記していってもらっています。1on1用Google Docs
マーケティングに強くなる「スキルマップ」を作ってみた【一覧図で解説】
マーケターのムロヤ（@rmuroya）です。 マーケティング組織の構築・育成や、煮詰まった時の施策アイデアの発想促進のために、マーケティングのスキルマップをつくってみたので共有します。なお、デジタルマーケティング のノウハウが根幹となる事業をやっていたので、デジタル寄りの内容になってます。 なお、SNSマーケティングに絞ったスキルマップも作成しました。 SNSマーケティングのスキルマップ作ってみた ーーー このブログの著者・ムロヤのメルマガもどうぞ。10年後も使える「マーケティング」を学べる情報をお届け。物事の本質を掴み、仕事・副業でハイパフォーマンスを出せる骨太な思考法を身につけられます。 https://rmuroya.theletter.jp/ ーーー マーケティングのスキルマップ （クリックすると拡大表示できます） ＜更新履歴＞ ・マーケティングスキルマップVer.1.0 上下で分
プロダクトマネージャの必要性 | F's Garage
とある創業社長のお悩みとして、 「いつも社員が考えた企画案を最後にひっくり返す役割になってしまう」 ということについて、胸が痛いという話をしていた。 こういう経験がある人は特にベンチャーでは少なくないだろう。親会社などからこれを食らうのは辛い話であるが、小さな組織でも、それなりにダメージはある。場合によっては、ワンマン社長の元で、好きなことができないと絶望してしまう人もいるだろう。 しかし、これについて、そのように見方を変えられるかが生き残りのカギである。 「社長にエスカレーションされるまで企画案の問題点に気が付かなかった企画、チーム、組織の問題」 と。 創業社長は、その会社で一番、そのビジネスについて考えている立場である。ちょっとやそっとで創業社長を上回るアイディアを出せると思ってる方が考えが甘い。ある意味、ひっくり返されて当たり前だと思うほうが話し早く進む。 ここでミニCEOと呼ばれる
SREサイトリライアビリティエンジニアリングを読もう - yoshidashingo
セクションナイン の 吉田真吾（@yoshidashingo）です。 SRE本の原書が出てから早1年半が経ちました。原書はすでにオンラインで無料で読めるようになっています。 Google - Site Reliability Engineering 前回このブログでSREについて書いたのが、原書の出る1ヶ月くらい前ですね。 yoshidashingo.hatenablog.com 国内でもSRE部署の設置が急速に進んでますが、運用部門をSREと看板を掛け替えただけの劣化コピーが大量生産されていることも否めなかったりなかったり。 そもそもSREは、従来のシスアドではなくソフトウェアエンジニアです。そして、開発／運用の分断による必然的な対立関係をインセンティブ設計で統合し、サービスの成長と運用コストが比例しないように切り離すための組織設計であり、そのための技術ノウハウです。 今日は今週末発売さ
マネージャーと開発者が安心してアプリ開発を続けるための開発ルール - Qiita
@eaglesakura です。 皆さん、進捗どうですか？ お仕事の規模が大きくなれば、参加人数が増えていくでしょう。 参加人数が増えれば、様々な宗教観の人がプロジェクトに参加するでしょう。 お一人様プロジェクトを中心にやっていた人もいれば、大規模案件のソルジャーとしてキャリアを積み上げてきた人もいます。彼らのスキルレベルもまちまちです。 私が参加している（そしてプログラマーに対して強い権限のある立場である）プロジェクトでは、次のようなルールをベースに適用しています。 これはなるべくプログラマーの負担をかけずに管理側（プロジェクトマネージャー＝PM）が開発管理を行える（進捗がブラックボックス化しない）ことを目的とした開発ルールです。 前提ルール ソースコード管理はgit/githubを利用する 1コミット（1ブランチ）に対して、複数Issueを処理しない githubはリポジトリ管理（作成
なぜ優秀なエンジニアを低待遇で採用してはいけないか
この記事は技術そのものやエンジニア採用のことがよく分からない経営者へ向けて書いています。エンジニアが読めば当たり前のことが書いてあります。また優秀なエンジニアならこう考えるのではないかというところは、私見によるものなので本当にそうかどうかは分かりません。 募集要項を書く募集要項で最も重要なのは待遇に関するところだと私は思います。具体的に言えば、だいたいの年収です。もちろん業務内容や組織の雰囲気なども重要ですが、業務内容や組織の雰囲気が良ければ年収が低くても働こうと思ってくれるのではないかと考えるのは経営者の奢りであって、そんなエンジニアはほとんどいません。優秀なエンジニアにとってはそのどちらも満たす求人が他にたくさんあるために候補にすらなりません。 逆に業務内容に魅力がなくても年収さえ高ければ良いという優秀なエンジニアも一定数いるはずです。待遇を具体的に書くことはそういった層に響くのではな
日本人の低すぎる生産性と、IT打ち壊し百姓一揆
生産性の低すぎる日本社会デービッド・アトキンソン著『新・所得倍増論』を読んだ。日本社会は世界トップクラスの質の労働者を抱えながら、「一人当たりGDP」や「時間当たり生産性」 において極めて低い水準にあるという。その結果、先進国で最も貧しい国になっている。（いずれもデータに基づく議論なので、関心のある人は本を読んで確認してほしい。） そのような現状分析からの政策提言として、「政府がGPIF（公的年金ファンド）を通じて上場企業に『時価総額を上げろ』というプレッシャーをかけるべきだ」と書かれている。 曰く、日本の上場企業経営者は、国際水準ではまったくの無能であり、利益を出せていない（「3時に閉まる銀行」という例が何度も登場する）、無能な経営者を交代させることでしか生産性の向上はない、女性の活躍もないという論旨だ。 同様の提言は他の識者からもなされている。藤野英人著『ヤンキーの虎』では「5年平均で
【非エンジニア・QA向け】なんちゃってQAのススメ - Qiita
本記事はGoodpatch Advent Calendar 2016 の20日目の記事です！ Goodpatchで唯一QAの肩書をいただいているenpipiと申します。 普段は社内SEとして活動しておりますが、Prottの大幅な改修時などスポットでQAとして参加しています。 専任のQAがいれば良いのですが、ディレクターや手が空いている人がQA的なことをしているチームも多いのではないでしょうか。 本記事では、非エンジニア・QAに向けた簡単なQAのコツについて紹介します。 スタンスの話 QAは、平たく言えばサービスの品質に責任をもつ仕事です。 しかし、片手間でQAをやる場合や専任じゃない人に同じ責任を求めるのは酷です。 バグを絶対に出さないと意気込むよりも、エンジニアがやらなくても良い仕事を引き受けて、開発に集中してもらう環境を作るくらいで考えている方がモチベーションを保てると思います。 テス
IDCFクラウドの開発チームで使っているツールなど - Qiita
IDCFクラウド開発チームで使っているツールや開発者の作業環境を紹介してみたいと思います。 GitHub まずは定番のGithub。 約100リポジトリあり、3割がプロダクション利用、7割が社内利用の用途で使われています。またプロダクションで利用されているリポジトリの過去1年間のコミット数の合計は、5,090コミットでした（2016/12/14現在）。 Githubのコミットメッセージ コミットに絵文字を使うルールになっていて、.gitmessage に凡例を記載して使っています。 $ cat ~/.gitmessage # 例 # 📝 :memo: Update getting started documentation # 🔥 :fire: Remove deprecated methods # 🎨 :art: Refactor *** for readability # # 絵
【冒険のDNA】ホットペッパー創業期の社内公募の文章が神すぎる - LiB-log
僕が新卒で入社したリクルートにおいて 一番長い時間を過ごした部署が、 まさに成長期真っ只中のホットペッパーでした。 毎月のように新しいエリアに新版が創刊され、 日々、至る所で【ギネス更新】という言葉が溢れていて メキメキと音を立てるがごとく事業が成長していました。 そして、たった7年間で 売上500億、営業利益150億という数字を叩き出すまでに成長し おばけ事業となったホットペッパーの成功は リクルート全社においても徹底的に分析され 他事業部へと、そのノウハウが横展開されることになりました。 今振り返ると、 その当時のホットペッパーには まさに伝説とも言える奇跡的な時間が流れていたと思います。 そんなホットペッパーの創業期において 社内で挑戦者を募集する社内公募の文章があったのですが、 この文章が、今まで見たこと無いぐらい神がかっていて それを先輩がシェアしていたので ここでも紹介したいと
はてなインターンの振り返りをYWTを使ってやってみた - だいくしー(@daiksy)のはてなブログ
今年は、はてなインターンの実行委員長という仕事をしている。 hatenacorp.jp 8月15日から9月9日までのインターンを終え、今年の教科書も公開ができた。 developer.hatenastaff.com まだもう少し委員長としての仕事が残っているが、ここで一度今年の振り返りをしようということで、実施した。 振り返り手法としてのKPTとYWT ぼくは普段、Mackerel というプロダクトの開発にかかわっている。Mackerelでは開発手法にスクラムを採用していて、2週間のスプリントごとに毎回振り返りを行っている。ここで使っているのはKPTという手法だ。 KPTはKeep, Problem, Tryの略で、2週間を振り返って、その期間でKeepしておくべき良かったこと、Problemとして議論すべき問題となること、そしてそれらを受けて次のスプリントですべきTryを決める。 K,
Qiitaにおけるリモートワーク主体の開発プロセス - Qiita
2016/9/27 スタートアップRails勉強会発表資料 About @takashi Increments アプリケーションエンジニア 主にQiita:Team担当 最近入社した 最近 Incrementsの開発チームが大事にしていること HRTを大切にしたコミュニケーション 作業は意識的に自動化する 属人性を極限まで排除する 重要な価値に集中する Qiitaにおけるリモートワーク開発プロセス HRTを大切にしたコミュニケーション Humility(謙遜), Respect(尊敬), Trust(信頼) リモートワークにおいてHRTとは？ オンラインコミュニケーションは誤解を招きやすい (本当に)意図せず冷たく接しているように伝わる そこで なにげないレビューに を添えるだけで雰囲気が良くなる (けど普段喋れないこともあるので)月１回はオフラインで集まるようにしている 作業は意識的に自
親に知ってほしい受験勉強
小学校以降〜大学受験まで、学年に関係なく、受験を控えている or 受験をするかもしれない子どもの親に向けて、親にこそ知っておいて欲しい効率的な勉強方法を有給ニート中の有り余るヒマを注ぎ込んでまとめてみたスライド。Read less
夏休みの宿題進捗管理をIT化したら子供が凄くやる気出した話
長男(今年9歳)が通っている学校は、かなり宿題が多い学校のようで、低学年でもそれなりの量の宿題が出ます。当然、夏休みの宿題も結構な量です。 長男は、普段の勉強については特に苦労をしていないようですが、やはり小学生であって、計画的に宿題をするのは苦手です。 一年生の時の夏休みの宿題も、結局すべて片づけるのはかなりギリギリになっていたようで、8月下旬くらいに泣きべそをかきながら宿題をやっているのを観測しました。 小学校の宿題に親が口出しするのもどうかなと思いまして、一年の頃はあまり干渉しなかったんですが、ちょっとそれを見て反省というか、考えを改めました。 宿題の本来の意味は、「家庭での勉強の習慣を作ること」だと思います。それが機能しないばかりか、単に嫌な思い出ばかりになってしまい、机に向かうこと自体がイヤになってしまったら可哀想だなーと思ったからです。 そこで、2015年の夏休みは、多少干渉し
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
心理的安全性の構造 デブサミ2019夏 structure of psychological safety
技術的負債と向き合う
