権限委譲でよくある失敗として、「権限委譲しきれていない」というのがある。気になってちょいちょい細かく口を出してしまうのだ。自分の経験だと、もともと優秀なプレイヤーだった人に多い気がする。 権限委譲する側でもされる側でも改善はできるが、どちらかといえば権限委譲する側の方がコントロールしやすいので意識するべきことを雑にまとめておきたい。 自分の集中するべきことを明確にする 口を出してしまうのは、口を出す余裕があるから 委譲した分何か別の集中するべきことがあるはずだが、それが明確じゃないか忘れてしまっている 自分が為すべきことを明確にして、優先順位を考えるべき 期待の認識を合わせる 口を出してしまうのは、期待を下回っているように感じてしまうから そもそもどこまでを期待していて何を任せているのか認識を合わせた方がいい デリゲーションポーカーなどで委譲の分野やレベルなどを確認するべき 情報が渡ってい

コンサルタント業界に知見がある人ならご存じな話だけど、今はコンサル大量採用時代だ。 Big4と呼ばれる総合コンサルだったり、アクセンチュア、ベイカレント、さらにはMBBとして括られる外資系戦略コンサルまで 以前では考えられないくらいにどこの会社もたくさんの新卒、中途を採用している。 そんななか、その波に乗って日系企業から大手コンサル会社に転職したのが私。 転職から半年が経過しようとしているけど、今はかなり苦しい。 ◾️苦しんでいる理由 1.周りのレベルが高すぎる 前職までは中小企業にいたから、スピード感や求められる質の高さについていくのに必死になってる。 2.業務コンサルで入ったけど、システム導入案件に一人アサイン。 前職までは、ITなんて関わりのない事業部門で働いていた。 部下や後輩の指導をしたり、とある業務の責任者もやってたけど、ここでは役に立たない。 上司は近くにいないから客先に一人

「誰のためのデザイン?」の旧版と改訂・増補版を読みました。 以前に旧版を読んだのですが、その記憶もあやふやなくらい前だったので、あらためて読み直し、その面白さゆえに改訂・増補版も購入してこれも読み終えました。 Web システム開発を生業としているので、日々ユーザとのインタラクションが発生するプロダクト開発に関わっているわけで、ユーザがどのように製品を認知し、使うかという内容は参考になりました。 それとは別にソフトウェア開発という観点で、ソースコードを読む時に人がどのように認知するのかという点でも興味深いものでした。このエントリでは、自分なりに整理したソースコードと概念モデルについて残しておきます。 ソースコードとメンタルモデル ソースコードの概念モデル 実行モデル プログラマモデル ユーザモデル 誰のためのソースコード? さいごに メモ ソースコードとメンタルモデル ある程度、経験のあるプ

概要 チームによる継続的開発を前提としたコーディングのガイドライン。 特定の言語を対象としたものではないが、主に静的型付けのオブジェクト指向言語を想定している。 サンプルコードは別段の定めがなければSwiftで記載。 ガイドラインの目的 生産性を高め、メンテナンスコストを下げる バグが生まれづらくする 開発メンバー（特に新規参加者）がコードを理解しやすくする 初心者プログラマーの教育 内容の説明 タイトルの頭についた【数字】は重要度。 高いほどシステムに与える影響が大きいが、低いものの方が影響が小さく改修しやすいものが多い。 【5】変数のスコープを小さくする 変わり得る値は複雑さを生み誤解やバグに繋がるため、プログラムは変数が少ないほど問題が生まれづらい。 プログラミングの大原則として、変数は必要最低限を心がけ、むやみに増やさないようにする。 また、変数はスコープや寿命が大きいほど悪影響が

技術書典によって同人技術書界隈が盛り上がってきている。 その流れに乗って私も技術書典に行き、毎回10冊弱程度買うようになった。 しかし買っても読めない。 2017年に買ってまだ1ページも読んでいないのもある。 私が技術書を読むスピードが遅いというのもあると思う。 (漫画はスラスラ読めるのに技術書はスラスラ読めない。) そして読まないといけないというプレッシャーみたいなものもあって苦しい。 去年の秋くらいからなんとなく読まないといけないというプレッシャーに押しつぶされそうになっている自分が居て正直ツラかった。 また、本を読む時間に押されてアウトプットする時間 (ブログを書く時間、コードを書く時間) が無くなっている事に気がついた。 アウトプットするために技術書を読んでインプットしているのに、これじゃ本末転倒だと絶望した。 この悩みを去年末の親しい友人と集まった忘年会で打ち明けてみると、 「わ

皆さんは「学術論文」を読んだことがあるでしょうか。 大学生や大学院生なら、自分の分野の論文は読んでいることでしょう。 情報が広く共有される現代でも、 「学術論文は専門家や研究者が読むもの」 「普通の市民は論文など読めない」 というイメージは今でもかなり強いように感じます。 私はこれを非常に「もったいない」と思っています。 実際には、「素人が専門の論文にアクセスする」ためのハードルは年々下がっているからです。 今や、素人でも「専門家が読んでいるのと同じ文献」をその気になれば読める時代になりました。 にもかかわらず「科学論文を読む素人」や「分野外の論文を読む学徒」が増えないのは、「論文の読み方」を大学以外でなかなか習えない、というのが一つの障壁になっているのかもしれません。 「論文の調べ方」「論文の読み方」に王道などありませんが、今回はあくまで私の例として、論文を探して読むためのハウツーを簡単

補足書きました思った以上の反応を頂いて驚いてます。 コメントへの返信など、追記しようかと思ったのですが、長くなったので別記事にしました。 興味あったら見てください。 https://anond.hatelabo.jp/20200102201209 はしがき釣りっぽく書いたけどほんと。 結構色んな意味で読書や知識というものに関する意識が変わったので、なんかアウトプットしたくなった なお、名著そのものを知ったことに関する感銘とかは今更私が言うまでもないので省きます。 書きたいのは100分de名著シリーズを対象にした読書を集中して実施したことに関するメタ効果に関して。 ちなみに、読破したと言っても読破したのはあくまで解説本。 スペシャル版とか、ブックス版はもう少し厚いけど。どれも約120ページで、読書慣れしてる人なら2-3時間で読める量だと思う。 いやそれじゃ読んだことにならないだろ原典あたれよ

この記事は 技術同人誌 Advent Calendar 2019 の11日目に公開されるはずだった16日目に公開された記事です。正直すまんかった。 これまでに8冊の技術同人誌を作ってきた間で、技術同人誌というジャンルがめちゃめちゃな勢いで普及し、本を書く手段もいろいろな選択肢が用意されるようになりました。その中でも、一貫してCSS組版 + Vivliostyleというニッチな方法で作り続けた体験談は意外と参考になることもあるのでは、ということで、今までにどのような方法で執筆してきたかを振り返ります。 C90 はじめる React Native Source: GitHub - pentapod/C90-builder 記念すべき1冊目。この段階で、原稿をPug + Markdown、レイアウトをStylusで書き、Gulpでビルド、だいたいできてきたらVivliostyle viewerで

この記事は 「技術同人誌 Advent Calendar 2019」 の15日めの記事です。 昨年・今年と、技術書典に3回参加しました。いずれの回も、技術同人誌の執筆・売り子としての参加でした。 色々と感じることがあり、書いてみます。 参加した理由とモチベーション 自分が技術書典に参加したのは 技術書典6、7 (いずれも共著本の執筆、売り子) 技術書典8 (委託販売と売り子手伝い) です。 「最近 (2018-19) 盛り上がりを見せている、技術同人誌イベントに参加したみたい。」 というのが、参加した理由です。 このようなイベントの熱量は、実際に現場に行ってみないと分からない。ネット経由の情報では、技術書典の面白さといったものがわからないと思い、参加を決めました。 どうせ参加するなら、自分でも何か同人誌を書いて参加したほうが楽しいのではないか、と思い、知人の同人誌執筆プロジェクトに参加。共

はじめに この記事は「技術同人誌 Advent Calendar 2019」の16日目の記事です。 自分が技術同人誌を書き始めてちょうど1年経ったので、 Fun Done Learnでふりかえりをしてみようと思います。 目次 はじめに 目次 これまで関わった技術同人誌 単著 合同誌 Fun・Done・Learnでのふりかえり Fun Fun・Done Done Done・Learn Learn Learn・Fun Fun・Done・Learn 個々の内容について少し深堀り Fun 自分の本が売れた! Fun 本だ…マジで本になってる…! Fun 一番大好きなゲームに関わっている人と知り合いになれた Done Podcastでサークル読み上げを何度かやった Learn 宣伝の重要さ Learn・Fun 初めて会う人の委託を受けた Fun・Done・Learn 商業誌版のリリース! ふりかえり

メディア関係者向けお問い合わせ先 メールでのお問い合わせ: pr-jp@google.com メディア関係者以外からのお問い合わせにはお答えいたしかねます。 その他すべてのお問い合わせにつきましては、ヘルプセンターをご覧ください。

この記事は「技術同人誌 Advent Calendar 2019」の13日目の記事です。 adventar.org 1年は早いもので、もう12月になりました。 12月といえば買ってよかったものとか色々書いちゃう時期ですが、その前に今年1年の執筆活動を色々振り返りたいと思います。 昨年(2018年)と比べると、より活動の幅が広がったりするなど変化の大きい1年でした。 2月～4月：Lambda本執筆・技術書典6参加 blog.taiko19xx.net blog.taiko19xx.net 2月に技術書典6に参加できることになったため、そこから書き始めました。*1 本文はもちろん表紙も予定通りに進めて無事に頒布できるようになりました。 この時、まとめ記事にも書きましたが、売れた数＜刷った数というのは考えさせられました。 売上が第一ではないというのはもちろん分かっていますが、需要を見誤ったのか、

38歳のオッサンになって、生きることが楽になった。禿げてきても「まあボチボチ40だしね、仕方ないか」とそれほど悲しくなかった。息切れも性欲の減退も揚げ物があまり食べられなくなったことも全く同じように、年相応の衰えだと納得できた。これはとても楽でいいなと思う。 今までは「もう20過ぎたのにアレも出来ないコレも出来ない」みたいな苦しみ方をしたり「まだ30なのに衰えが始まった気がする」と怯えたり、そんなことが多かった。でもこう、40が迫ってくると自分が何に関しても大した才能を持たず平均的な労働力でしかないことや肉体的な衰えを、自然な変化として受け入れることが出来るようになった。 僕は何者にもなれなかった。もっと言えば何者かになろうと必死で足掻くことをダサいことだと勘違いして避け続けた結果、凡庸な中年男性になった。でもまあ生きていける程度に給料はもらえて、健診でも特に問題はなくて、たまには連休を取

技術同人誌 Advent Calendar 2019の12日目の記事です。 この記事のゴール 本稿ではTechBooster/ReVIEW-Templateリポジトリをベースに 著者はマークダウンで原稿を書く。 GitHubのプルリクで差分をチェックする。 マージしたら自動でPDF生成→Slack配信。 上記を実現するための取り組み（突貫工事）をご紹介します。 この記事の対象読者 技術同人誌の快適な執筆環境を整備しようとしている方。 自己紹介 販売数1,000部を超えた技術同人誌『個人開発がやりたくなる本』の発起人・編集代表です。 詳しくは以下の記事・スライドを参照ください。 yuzutas0.hatenablog.com 既存のツール TechBooster/ReVIEW-Templateという有名なGitHubリポジトリがあります。 Re:VIEWという書籍執筆支援システムを手軽に利用

やった順。 大神(30h、懐古的に80点)PS2時代にクリア済み。懐古的にやるのがいいのでは。 初めてプレイする人は、最近のゲームほど操作性がよくないので、おススメはしない。 既プレイ民は久々にやると、終盤の熱い展開で燃える。 いけにえと雪のセツナ(15h、60点。2時間ドラマを見るくらいのつもりで。)悪名高きTokyo RPG Factoryの作品。安かったので買った。 クロノトリガーを引き合いに出すから、叩かれたのであって、 週末に映画館に映画を見に行くくらいの気持ちでやれば、 すぐにクリアできるし、後にも何も残らないので頭を使いたくないときにおすすめ。 ドラゴンクエストヒーローズ1・2(60h、60点。面白さがわからなかった。)ドラクエに惹かれて、初めて無双系と呼ばれるゲームをプレイした。 1をクリアした段階で、かなりお腹いっぱいであったが、 買ってしまったので2までがんばってクリア

この記事は技術同人誌 Advent Calendar 2019の12月8日分の記事となります。 私は、今年の9月に技術書典7に初参加し、技術同人誌『RustではじめるOpenGL』を頒布させていただきました。 現在もPDF形式のダウンロード版と、紙版の両方をBOOTH.pmで販売させていただいてます。 toyamaguchi.booth.pm ただし、紙版のほうは一部コンテンツが抜けていたことがあとから発覚しまして、別記事にて内容を通知させていただいております。 このようなコンテンツの抜け漏れがあった場合、PDF形式のダウンロード版ではすぐにアップデートをかけることができたのですが、紙版では対応が難しいところが難点です。 今回、私がAdvent Calendarのためにお伝えする内容は、このような抜け漏れ対策のためのものです。 コンテンツの抜け漏れ対策スクリプト 私がやらかしてしまったのは

Frontend Conference Fukuoka 2019

本番環境でやらかしちゃった人のアドベントカレンダーです。 例） 本番DB吹き飛ばした 本番サーバをデストロイした ネットワーク設定をミスって本番サーバにアクセス出来なくなり、サーバが世界から孤立した などなど... 以下の２点については必須項目なので、記述お願いします。 惨劇はなぜおこってしまったのか 二度と惨劇を起こさないためにどうしたのか もう二度とあの惨劇を繰り返さないために、みなで知見を共有しましょう。