仕事のあれこれ
仕事
Googleの働き方ガイド
https://rework.withgoogle.com/jp/
仕事好きのタイプ
１：会社という空間、場が好きな人（仲間タイプ）
２：お仕事をしてお金を稼ぐ、または地位を築くことが好きな人（お金タイプ）
３：仕事の内容にやりがいを感じている人（やりがいタイプ）
http://el.jibun.atmarkit.co.jp/noriwo_t/2017/09/post_59.html?ref=rss
仕事タイプ
ミクロ - マクロ
直観意味 - 事実論理
WHAT - HOW
http://mag.executive.itmedia.co.jp/executive/articles/1803/22/news012_2.html
働き方を変えて生産性を高めるための８つの習慣
http://hamuhamu.hatenablog.jp/entry/2017/03/30/093533
継続的な仕事の改善
仕事は肥大化する
仕事は個別化する
仕事は陳腐化する
よりよい環境
話し合いでは両者の立場を尊重すること
すべてにおいてアウトサイド・インのアプローチを採用すること
ヒューマンエラー抑制のためビルド，テスト，リリースのプロセスを自動化すること
開発作業と運用環境を簡略化，標準化すること
開発と運用を超越したシステムエンジニアリング文化を浸透させること
フィードバックとフィードフォワードのループを実践すること
開発者をサポートの最前線に配置すること
指示でありがちなこと
工数を勝手に決められる
全部、別の・他の○○に
（ページや部位をいわずに）○○を変えて
指摘と指示は違う（指摘：○○が間違っている。直して 指示：○○が違うので、××にして）
「やっておいて！」だけではなく「こういう理由で◯◯にやって欲しいからお願い！」
仕事がなぜ進まないのか
こころのエネルギーの法則（エネルギーは早めに消費される） 24時間は均等に流れていきますが、私たちの集中力の源であるこころのエネルギーは、均等には消費されません。一般的に、朝エネルギーが高く、1日の終わりになるにつれてどんどん残量が減っていきます。大切なことはエネルギーが最も高い時間に行うことがポイントです。
パーキンソンの法則（予定した時間の分だけ時間がかかる） これは、英国の政治学者であるパーキンソンが提唱した法則です。この理論が語っているのは、ある仕事を行うにあたり、余分な時間が与えられると、人は与えられた全部の時間を無駄なく使うために、仕事のペースを無意識のうちに調整し、生産性の低い仕事になることが多いということです。
つまり、予定した期限があればそこまで時間がかかってしまう。裏を返すと期限を早めることで非効率を排除できるということが言えます。
欲張り見積の法則（見積時間は実際時間より短い）
多くの方のタイムログ（時間簿）調査すると、時間見積もりは実際にかかる時間よりも短く設定されていることが多いものです。それは理想的なスケジュールで進めたい、これぐらいで済ませたいという願望が入るからでしょう。
しかし、計画が欲張り見積もりされている限り、決めた時間に終えることはできません。人によりますが、実際かかる時間の60％ぐらいで見積もられているケースが多いものです。裏を返すと40％ぐらいバッファー（ゆとり時間）を含ませると丁度良いです。
完璧主義
心配性
いい人
場当たり対応
先延ばし
だらだら仕事
曖昧なゴール
浪費癖
自己完結主義
http://president.jp/articles/-/14537
仕事のやり方
クリエイティブなアイデアは、リスクを含むケースが多く、潰されかねない
->最低限の人の了解のみをとる
->怒られたらあとで精一杯謝る
http://www.nikkeibp.co.jp/article/column/20141209/427607/?ST=overview&rt=nocnt
http://liginc.co.jp/web/useful/135013
優秀な「壁打ち相手」を準備する
ポモドーロテクニック
集中して仕事をこなすために、25分毎に時間を区切って仕事をする時間管理術。Francesco Cirillo氏が1992年、自身の勉強効率を上げるために考案した。
GTD (Getting Things Done)
GTDでは「頭の中にある気になること」をすべて書き出す
目標設定
・Specific（具体的か？）
・Measurable（測定可能か？）
・Attainable（達成可能か？）
・Relevant（ツボを押さえているか？）
・Trackable（追跡可能か？）
意識高い系エンジニア
エディタにはこだわっておく
勉強会には行っておく
アプリをリリースしておく
ソーシャルコーディングしておく
自動化しておく
キーボードにこだわっておく
いろいろなスマホを持っておく
業界の新しい動向を把握しておく
意識は一日にして成らず
具体的な指摘
・ ステップごとに実際の行動に落とし込まれているかを確認する
・ 誰がやっても同じような結果になるように、あいまいな言葉は使わない
・丁寧に → １０秒かけて
・ちゃんと → 定規を使って
・普通に → 写真と同じように
・大きめに → 何センチ
・最後に「●に報告し合格をもらう」「●の数値が▲を担っていることを確認する」など完了のチェックが入るようにする
■報告をメールでする業務の例
【悪い例】
・AさんとBさんに詳細な業務報告をメールする
このような場合、なにをすればいいのか、「詳細」とはなにかが曖昧なため十分なマニュアルとは言えません。
【良い具体的な例】
（1）新規のメールを作成する
（2）ToにAさんを設定し、CCにBさんを設定する
（3）件名を「◯月◯日 業務報告」とする
（4）本文を作成する
・URL（XXX）から◯◯を転記する
・△△から◯◯の数字を書き込む
・「よかったこと」「問題」「次のアクション」を書く
（5）ToとCCが間違っていないかどうか確認する
（6）送信する
思考
プロフェッショナリズム
我々に相談せずに、ビジネスが顧客と約束することもある。そのような場合には、そのコミットメントを果たせるようにビジネスを助けなければいけない。ただし、コミットメントを受け入れるわけではない。
この違いが重要だ。プロであれば、ビジネスに手を貸して目標を達成できるように務めるが、それは必ずしもビジネスのコミットメントを受け入れたということではない。顧客との約束を果たす方法が見つからなかったら、約束をした本人が責任を果たさなければいけない。
https://employment.en-japan.com/engineerhub/entry/2017/08/04/110000
ゼークトの組織論
将校には四つのタイプがある。利口、愚鈍、勤勉、怠慢である。多くの将校はそのうち二つを併せ持つ。
一つは利口で勤勉なタイプで、これは参謀将校にするべきだ。
次は愚鈍で怠慢なタイプで、これは軍人の9割にあてはまり、ルーチンワークに向いている。
利口で怠慢なタイプは高級指揮官に向いている。なぜなら確信と決断の際の図太さを持ち合わせているからだ。
もっとも避けるべきは愚かで勤勉なタイプで、このような者にはいかなる責任ある立場も与えてはならない。
デザイン指向
必要性: システム全体が課題解決を望む強さ。システムレベルの場合は、人々が課題に気づいていないことが多いため、必要性を啓蒙するところから始める必要がある。（例：惑星移住）
実現性: 課題解決のためのプロダクト開発における技術的難所や必要条件。システムレベルの場合は、単一のプロダクトの実現性ではなく、プロダクトが生まれる土壌を作るうえでの必要条件となっているインフラの実現性。（例：宇宙ビジネス発展のための宇宙へのアクセス手段）
採算性: 事業を持続するための安定した収益性の確保。システムレベルの場合は、単一のプロダクトの収益性ではなく、各プロダクトが収益を上げやすくするためのインフラの採算性。（例：宇宙ビジネスが儲かりやすくなる環境作り）
ゼロイチ思考
スタートアップが失敗する原因
必要とされていないマーケット
お金が尽きる
よくないチーム
市場競争に負ける
コスト
プアープロダクト
ビジネスモデルの欠如
プアーマーケット
顧客無視
リリースのタイミングを逃す
目的を失う
チームの不協和音
方向性を間違える
情熱を失う
よくない作業場所
無策な財政
法律上
使われない
燃え尽きる
意思が弱い
http://thebridge.jp/2016/03/whystartupsfail-pickupnews
時代
事業計画は作ってはいけない
予算は立ててはいけない
仕様書は作ってはいけない
ルールは作ってはいけない
分業はしてはいけない
稟議・承認はもう必要ない
管理さえももう必要ない
「テスト」はもう必要ない
「学校」ももう必要ない
「教育」すらももう必要ない
「失敗する権利」を奪ってはいけない
論理的思考では課題は解けない
もう課題解決の時代じゃない
IT起業
その１. 完璧を求めない
その２. 考えすぎない
その３. 周りに相談しない
その４. 既存にあるからと諦めない
その５. 利益を出せるサービスを作る
その６. 知識の格差が利益になる
その７. 額に入れて飾る
その８. 仕事は辞めてしまう
その９. 小さい目で見る
その１０. 大手のやり方は真似ない
その１１. 人の話は素直に聞かない
その１２. 「戦争をしている」ということを意識する
その１３. 出と入を考える
その１４. 「この野郎根性」を持つ
その１５. 孤独に慣れる
その１６. ポジティブになる。いや、ならざる負えない。
その１７. 無駄なことをしない
その１８. もらえて当たり前を捨てる
その１９．会社員脳の上司が言うことは信じない
その２０．自分を安売りしない
その２１．人間関係や義理人情だけで行動を決めない
その２２．稼げるかどうかは努力だけでなく環境にもよる事を理解し、稼げる環境へ身を置くこと
その２３．中途半端でいいから行動すること
その２４．頭で考えて答えを出さない
その２５．目先の利益より将来の利益を考える
その２６．上から目線でいること
エンジニアのモチベーションを下げる方法
o 序の口: ディスプレイを小さくする
o 序二段: 毎日スーツを着させる
o 三段目: 椅子を固くして、机を狭くする
o 幕下: 簡単に作れるでしょ？って上から目線で言う
o 十両: 打ち合わせ一杯で連続した集中時間を与えない
o 前頭: 情報共有しづらい、風通しの悪い現場に
o 小結: 引き継ぎなしで人をどんどん入れ替える
o 関脇: 背景わきまえず、コード汚い、仕組みひどいと言う
o 大関: 仕事を突然終了させて無意味感を与える
o 横綱: 本質的でないことに時間を取らせる仕組み
http://d.hatena.ne.jp/jflute/20160221/downmoti
社員のやる気を出す？
・家族も参加できる大運動会（住友電装）
・部門別業績を全社員が予想（リンクアンドモチベーション）
・社内報に毎号、全社員が登場（アチーブメント）
・ランチ仲間を抽選でランダムに（マンションリサーチ）
・運動会、社長は転がす玉の中（スピードリンクジャパン）
・職場盛り上げ社内通貨獲得（アイ・パッション）
・賞金付き社員相互表彰制度（クラウディアン）
・新入社員が社員旅行を企画（龍名館）
・社内SNSでプライベート情報（VSN）
http://netgeek.biz/archives/64851
エンジニアがやめないためには
・高い給与
・残業がないこと
・自由な時間に出社可能（出勤しなくても可）
・昼寝ok
・教材やセミナー費用を全額会社負担
・在宅勤務
・機材を自由に選べる
・自由に技術研究出来る時間
・無料の社食
・エンジニア、デザイナーの社内地位が高いこと
・長期休暇が気持ち良く取れる文化
・個室
・私服勤務可
http://www.2dgod.com/entry/2016/07/31/184000
問題解決
そもそも私はそれを本当に解きたいか
それはどこからきたのか
問題は何か
誰の問題か
考えをやめない
マーケティング
ブランドイメージ
技術力
信頼できる
スピード感
先進性
専門的
先見性
誠実である
発想力
柔軟性のある
業界リード
変革を生む出す
一流である
国際的である
チャレンジ精神が旺盛である
独創性のある
活気がある
知的である
オープンな
親しみやすさ
協調性がある
情熱的である
勢いがある
伝統がある
泥臭い
顧客の購買要因
優れた企画力・提案力がある
課題解決力がある
コンサルティング力がある
ITとネットワーク技術の双方に精通
サポート体制がよい
価格がリーズナブル
製品・サービスの品質が高い
情報セキュリティについて安心できる
総合力がある
要望した性能・機能を満たしている
要望に柔軟に対応する力がある
情報システム構築にすぐれている
プロジェクトマネジメント力がる
最先端の技術を活用している
先端的な製品・機能・サービスを提供している
グローバルでの実績が豊富
複数ベンダーをとりまとめる力がある
短い納期で対応してくれる
環境に配慮した製品・サービスを提供
PDCA
PDCAくるくる病
https://headlines.yahoo.co.jp/article?a=20170428-00010000-nkbizgate-bus_all&p=2
成功
エクストラサクセス
フルサクセス
ミニマムサクセス
失敗
企業の失敗
企業が犯す失敗には二種類あると、CEOのマーク・ザッカーバーグがいつも言っています。一つ目は目標を達成できないこと、二つ目は野心的ではない目標を達成することです。彼は、二つ目の失敗だけはして欲しくないと考えています。なぜなら、野心的ではない目標を設定した時点で、すでに失敗したも同然だからです。私たちに必要なのは、本当に野心的な目標を設定すること、自分の失敗を報告して責任を認め、フィードバックを受けられるよう安全な環境を整えること、自らがすすんで学び修正することです
仕組み化しよう
ルール化の問題
手順、ルールが多すぎる
ルール項目の実施が難しく、時間がかかる
手順項目が退屈
ムダな項目が多い
手順、ルールの存在が知られていない
仕組み化
属人性をなくす
その失敗が発生できないようにする
仕組み化が難しい場合は問題の検知、計測を自動化する
例
事象
開発環境のURLが入ったhtmlを本番環境に乗せてしまった
だめな再発防止策
データを保存するときはダブルチェック
チェック項目に開発環境のURLが含まれていないことを確認する
本当の再発防止策
開発環境のURLが入ったhtmlを保存できないようにバリデーションを追加する
組織衰退
事業環境変化
↓
組織の衰退
事業環境変化への感度の低下
意思決定の経済合理性の阻害
事業構造改革の躊躇
Last updated