管理職のきみと、いつか管理職になるきみと、管理職が苦手なきみへ | サイボウズ式
マネジメント 新しいチームのあり方を探求 就活 就活生必見！サイボウズの疑問 ティール組織 会社の「あたりまえ」が変わる 多様性 100人100通りの個性 ワークスタイル 働き方、生き方、もっと自由に 青野慶久 サイボウズ社長の想いと覚悟 キャリア 人生の「積み上げ方」を見直す 複業 複数の「本業」をもつ働き方 人事制度 多様な働き方を支える仕組み マンガ サクッと手軽に読める！ こんにちは、Twitterで平安文学や読んだ本の話、働き方や好きなソーシャルゲームの話をしていたら、いつの間にかフォロワー数がだいぶ増えて、あちこちでいろんな原稿を書くことになった、「たられば（@tarareba722）」と申します。普段は出版社で情報系Webサイトの編集長を務めております。 本日はサイボウズさんからのご依頼で、仕事と働き方、それから「そのがんばりは、何のため？」という、いわゆるモチベーションにつ
「事業がわかるエンジニアがいない」 - timakin.com | Seiji Takahashi (@__timakin__)
単純に仕事の用事なのですが、俗に言う経営層と言える立場の方々にヒアリングする機会が増えたことで、とあるセリフを頻繁に耳にするようになりました。 「事業の話ができるエンジニアがいないんだよね。本当に困りますよ」です。 これは僕が事業の話をできるとかそういうことを言いたいのではなくて、各社の経営層の切実な想いであり１つや２つの組織で聞いた発言ではなく、あらゆる組織で耳にする強烈なペインであると言いたいんです。 本当に、文字通り、全ての組織でこの発言を聞きました。 僕個人としては、「え？そうなんですか？結構いると思いますが」って当初反応してたんですよね。何故なら、自分の周りには幸い「技術にだけ興味があるエンジニア」が少ないからでして、彼らがそこまでの切実さで何を求めているのかはっきりとわかっていませんでした。ただ、僕も諸事情あって彼らと似たような視点を持たなければいけない状況になり、この発言の理
転職基準 スタートアップへの転職を検討するための予備知識
フォーカスするためには、たぶんどうやってフォーカスするか（前回）に加えて、何にフォーカスするかを決める必要があって、今回は後者、つまり「フォーカスポイントを決める」方の話です。 スタートアップの初期は Y Combinator 的に言うところの Do things that don’t scale （スケールしないことをしよう）をはじめとした明確なフォーカスポイントがあると思います。ただ次第に自分たちでフォーカスポイントを決めなければいけなくなってきて、そのときにどのようにフォーカス先を意思決定すれば良いのか、どうすれば良い意思決定ができるのか、という問いが出てきて、その際に方法論の必要性が生じます。 そこで意思決定の方法論を検討するのですが、スタートアップのような情報不足や資源の制約下では、ゲーム理論をはじめとしたいわゆる規範的な normative 意思決定理論よりは、行動経済学や認知
エンジニアがはてなでマネージャーをやるということ - An Epicurean
このエントリーははてなディレクターアドベントカレンダー2016の15日目の記事です。また、このエントリは先日の はてなエンジニアセミナー #7 でお話したことを、書き起こしたものでもあります。 Mackerel というサーバー監視・管理SaaSの開発チームのディレクターを務めている id:Songmu です。はてなのチーフエンジニアも兼務しています。 これまでの経歴としては、中国でITベンチャーの立ち上げに関わったり、その後語学学校で営業兼システム担当、SIer、Web企業でソーシャルゲームのリードエンジニアなどの経験を経て、2年ほど前にはてなに入社しました。 現在兼務している、ディレクターとチーフエンジニアという職位は、一般の企業では両方共課長格くらいで、W課長みたいな社内では珍しい立ち位置です。 Mackerelのディレクターとしては、プロダクトマネージャーとスクラムマスター的なことを
ADHDで管理職をやっている者なんだが
週末の借金玉氏(id:syakkin_dama)のエントリやそれを受けて書かれたわかり手氏(id:ganbarezinrui)のエントリ、http://anond.hatelabo.jp/20170227005158 あたりのブコメとか読んでいて、随分と世知辛いねえ、と思ったのだけれど、良い場所が無いので増田にこれを書いている。たぶん超長い。 俺はタイトルに書いてあるようにADHD（診断済み）だ。典型的な注意欠陥・多動性が認められ、一方でASDの症状はゼロという純正ADHDマンである。なので先のお二方のエントリは全力で泣きながら、共感しすぎてヘドバン状態で読んだ。でもわからない人には何が「なので」なのか本気でわからないんだと思うし、それで正常なんだろうということも理解している。 んで、一般的なIT関連の企業で管理職をやっている。それなりに多様な部下もいる。業界的にブラックな香りがするWeb
転職して7年が過ぎた
これを一部でシェアしたのは2014年なので結構前ですが、エンジニアのキャリアパスを考えるにあたって参考になるかと思って公開します。あくまで個人的な体験談で会社の見解などとは関係ないということに注意してください。 -------- 入社日記念の無料マッサージクーポンのメールを受け取って気づいたんだけど、こないだで入社後7年が経過したらしい。僕は結構長い期間をここで過ごしたことになるんだなと思った。ちょっと以前のことを振り返ってみようと思う。言うまでもないけどこれは僕の書ける範囲での個人的な感想と体験談であって会社の見解等を表しているものではない。 きっかけ そもそも最初は2007年にGoogle Japanのリクルーターからメールをもらったのがきっかけだった。Google Japanの知り合いから紹介で誘いがきて、「お、これは引き抜きってことかな？」と思ってよろこんで話を聞きに行ったのだった
1on1ミーティングに備えるアンケート - しるろぐ
最近は、大体月一ぐらいのペースでメンバーと1on1ミーティングをするようにしている。 一人あたり30分から60分ぐらいで、前回のミーティングからの振り返りとその他相談を話す感じ。相談は仕事のことが主だけれど、プライベートな内容もある。 1on1ミーティングにあたって今年から事前アンケートを用意するようにしたのだけれど、そこそこいい感じに回っているのでまとめてみる。 事前アンケートを用意するメリット 話すことが事前に想定できる アンケート自体がアジェンダになるので、ミーティングがコントロール可能になる。 どんな話をするか分かっていると安心感もあるし、話が横道に逸れることもない（雑談は雑談で良いものだけど）。 その場で回答が思いつかなくて適当な返しになることがなくなる（お互いに） 自分の体験談なんだけど、何か質問をされたときにその場では「うーん、今は特に思いつかないです」と答えたのに終わってか
新入社員が来てメンターになれって言われたけど、どうすればいいのかという対話テクニック - Qiita
エンジニア組織を強くするための本を出版しました Qiitaでエンジニアリングをめぐる様々なコミュニケーションの問題とその解決策や考え方を書いてきた。それらの背後にあるエッセンスをこの度書籍として出版するに至りました。 エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング この書籍は、エンジニアリングを「不確実性を削減する」という第一原理で捉え直し、様々なエンジニアリングとその間のコミュニケーションをめぐる現象を説明していくものです。 はじめに 最近、メンター制度として新入社員や若手のメンバーに対して、先輩をつけて相談事に乗ってあげたり、仕事のサポートをしたりといったような教育プログラムを組む企業が増えています。このメンターという役割は、ちょっとした訓練が必要だったりするのですが、このあたりの研修や訓練をせずにいきなり明日からメンターね！なんてことがままあります。
クズが教える新人プログラマ処世術 - Qiita
Welcome to Underground という訳で今年から新人プログラマとして働く方、おめでとうございます。 この先、皆さんには 糞みたいな上司と争ったり、糞みたいな炎上プロジェクトに突っ込まれたり、糞みたいなクライアントの対応したり 素敵なイベントが沢山あることでしょう！ そんな皆さんにクズと自認している私が僭越ながら処世術をお教え致します。 学生時代からOSSに貢献してたり、スタートアップに潜入してたりする意識高い学生は回れ右してお帰りください。 クズなりの糞みたいな職場の乗りこなし方 大小様々な会社が古今東西色々とございますが、中には糞みたいな会社や糞みたいな部署や糞みたいなチームがあります。 そういったところへ自分が配属された時にはまず 次の転職先を探してください。 そのような現場に回されてしまっても無理してあなたはそこで働くことはありません。 さっさと転職しましょう。 え？
グーグルが突きとめた！社員の「生産性」を高める唯一の方法はこうだ（小林 雅一） @gendai_biz
社員の生産性を極限まで高めるには、どうすればいいのか――米グーグルが2012年に開始した労働改革プロジェクトの全貌が明らかになった。 社員同士のコミュニケーションを中心に、その仕事ぶりを徹底的に観察するワーク・モニタリングは、果たして功を奏したのだろうか？ ●"What Google Learned From Its Quest to Build the Perfect Team" The New York Times, FEB. 25, 2016 プロジェクト・アリストテレスとは 上の記事によれば、米グーグル（持ち株会社に移行後の正式社名は「アルファベット」）は2012年に生産性向上計画に着手した。 この計画は「プロジェクト・アリストテレス（Project Aristotle）」と呼ばれ、同社の「人員分析部（People Analytics Operation）」によって実施された。 グ
「リモートワークは手段でしかない」GitHubが作りだす“幸せの最適化”
2016年2月25日、世界をログする書き起こしメディア、ログミーが初のリアルイベント「ログミーLIVE」を開催しました。第1回目のテーマは「働き方」。1人目の登壇者、ギットハブ・ジャパンの堀江大輔氏は、同社が最も大切にしている“幸せの最適化”という価値観を紹介。その上で、社員の半数以上がリモート勤務を導入するGitHubのワークスタイルについて語りました。 第1回 ログミーLIVE「GitHubの働き方」 堀江大輔氏（以下、堀江）：今日はGitHubがどういう働き方をしているか、どうしてそういう働き方をしているかを紹介しようと思っています。 いきなり言い訳から始めるんですけど、花粉症がすごいひどくて、じゃあ薬を飲もうと思ったら、いつも以上にとろんとしていて、忘れそうなのでここにコンピューターを置いておきます。 堀江氏のプロフィールとGitHubの社風 まず自己紹介なんですけど、私、堀江大輔
フルタイムRubyコミッター採用までの道のり - Money Forward Developers Blog
エンジニアの越川です。 今朝プレスリリースを出させていただきましたが、当社ではフルタイムRubyコミッターを採用致しました。そこまでの道のりを紹介させて頂きます。 マネーフォワード、フルタイムRubyコミッターを採用～Ruby1.8.6/1.8.7のリリースマネージャである卜部昌平氏が就任～ 左：技術顧問 松田明氏/中央：Ruby開発者 卜部昌平氏/右：代表取締役社長CEO 辻庸介 何故やるのか プロダクトを開発する上で、Railsを選択する理由については、以前個人ブログに考察を書きました。 それでもRailsを選択する3つの理由 - pblog Railsを用いた開発に必要な事を整理すると Railsの哲学を理解し規約を守る 周辺のエコシステムを活用し、自らもそのエコシステムの住人となること 進化に追従すること 概ねこの辺りが重要な事柄かと思います。 その際、Railsのスペシャリストを
Tech Lead（TL/テックリード）の役割 - サンフランシスコではたらくソフトウェアエンジニア - higepon blog
Tech Lead（TL/テックリード）の役割。聞きなれない名前かもしれない。リードプログラマやテクニカルリードと呼ばれることも。過去にいくつものチーム（最大で10人以上）の Tech Lead をやってきた自分の経験を踏まえて書いてみる。 Tech Lead の主な役割 Tech Lead はエンジニア班長と言いかえるとイメージがわきやすいかもしれない 顧客に提供したい価値（プロダクトゴール）を正しく理解する エンジニアチームの生産性を可能な限り最大化。プロダクトマネージャ・デザイナと顧客に価値を提供する Product の Launch に責任を持つ Product の Launch 後のメンテナンスに責任を持つ エンジニアを過負荷から守る ときにはマネージャ、プロダクトマネージャのアイデア、スケジュールに NO を言う。代替案を提示する チーム内のテクニカルデザイン、採用技術などに責
より良い組織を作るために - クックパッド開発者ブログ
はじめに こんにちは、投稿推進部部長の勝間です。 突然ですが、皆さんは「組織における課題」について考えたこと、意識したことはあるでしょうか。 「組織における課題」なんて言葉を使うと、たとえば 事業戦略の方向性 人事評価制度 マネジメント層の育成 など、少し高いレイヤーの話が思いつくでしょうか。 ともすれば自分とは無関係な話のように思えるものかもしれません。 一方で、このようなものはどうでしょうか。 なんとなく、最近社内の空気変わった気がする なんとなく、隣の部署が何やってるかよくわからない このような、もやっとした感覚、は普段働いている中で感じたことがある人も少なくないかもしれません。 こういった「具体的な何か」というより「抽象的な違和感」を私たちが抱くことも組織における課題といってもいいかと思います。 このような組織における課題、違和感を認識したとき、私たちはどのように向かい合うべきでし
ソフトウェアエンジニアの成長カーブ（再掲載）：柴田 芳樹 (Yoshiki Shibata)：So-netブログ
「ソフトウェアエンジニアの成長カーブ」 最近良く話していることなのですが、社会人として働き始めた新卒の技術者は、最初の数年は成長していきます。与えられた業務を遂行しながら、そのための学習もしていくからです。しかし、2、3年すると開発業務をこなせるようになり、特に新たな勉強をしなくても、日々、会社に行って開発業務が遂行できるようになります。 この状態、つまり、継続した学習をしなくなった状態で、10年とか経過すると、ソフトウェアの世界は大きく変化している可能性があり、新たな技術が登場し、その人の技量は相対的に今度は低下しはじめます。しかし、この時点で、新たなことを学習するのは困難だったりします。学習する習慣が無いわけですから、勉強しろと言っても、「なぜ、休みの日に勉強しなければならないのですか」ということになります。 そのような人に対して、マネジメントは、その人ができる仕事を与えて、何とか仕事
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Wantedly（ウォンテッドリー）はたらくを面白くするビジネスSNS
優秀なエンジニアになる方法: 電子情報通信学会誌 Vol.84 No.10 pp.741-749 2001年10月
自己都合退職で失業保険受給をするための全知識|コロナ禍での制度変更点も分かりやすく解説
リモートワークの話
僕は会社を良くしたい( ｰ`дｰ´)ｷﾘｯ - Google スライド