問題解決より深掘りを優先する人が困っていたこと - 覚書
何らかの問題を解決しなくてはならなくなった時に、解決よりも深掘りを優先してしまう特性の人がいます。 たとえば問題に対する短期的な対策を考えることをおろそかにして、根本原因究明と根本対策方法をじっくり考え込んでしまうような人が該当します。他人事のように言ってますが、筆者もそうです。本記事は、そういう筆者が過去に仕事で困っていたこと、ある時から状況によって取り組み方を変えられるようになったという話をします。 上記のような特性の人は、調査のたびに深い知識が得られ、血肉となっていきます。それゆえ技術に明るい人とみなされることもあります。その一方で、困ることもあります。とくにそれは発生した問題が自分ではなく他の誰かのものだった場合、かつ、急ぎ問題解決が必要な場合です。業務ではこのような場面が非常に多いです。 この場合、問題の深掘りを最優先にしてしまうと仕事が遅くなりがちです。みなさんも、「あの人、技
エンジニアのための時間管理術
はじめに 時間管理が上手くなりたいと日々思っているため、このテーマにしました。 自戒の念を込めて😅 タイムマネジメントの王に!!! おれはなるっ!!!(CV.田中真弓) ※掲載内容は個人の見解であり、所属する企業を代表するものではありません。 参考にした書籍 『エンジニアのための時間管理術』 Thomas A. Limoncelli 著 株式会社クイープ 訳 発行年月日：2006年10月 ページ数：272 ISBN：978-4-87311-307-4 タイムマネジメントについての考え方や手法を取り入れたいと思い読みました。 時間管理した先のゴールは？ 自分のための時間・家族との時間を最大化する。 前提 エンジニアはタイムマネジメントが難しい。 プロジェクトワークと割り込みが入り混じる職業。 外部からの割り込みは生産性を低下させる。 中断した作業に戻るには時間がかかり、エラーが紛れ込む可能
ミーティングの最初にルールや心構えを読み上げる - Konifar's ZATSU
ミーティングのファシリテーションをする時にミーティングのルールや心構えを音読するようにしてみていて、思ったよりいい感じなので雑に書いておきたい。 たとえば月1の開発チームのミーティングでは、次のようなルールを明記して読み上げている。 ドキュメント・Slackへのコメントを歓迎します。事前・MTG中いつでも質問・意見を入れてください あまり厳格にしすぎずハードルを上げない 議事録はみんなでMTG中に書く 最初に声に出してアナウンスすると、それに応えて意識した行動を取ってくれる人が増えているように思う。 他には、インシデント対応の初動で集まった時にはインシデントコマンダーの立場で次のような心構えを画面共有で映して話す試みを始めた。 犯人探しをしない チャレンジしてリリースすれば一定インシデントは発生する 犯人探しをせずユーザーへの対応と改善に目を向け、落ち着いてOne Teamで対応する 同期
正しく評価される自己評価の書き方 - るさんちまん
はじめに 会社員として働く上で評価は最も大きな関心事の1つでしょう。評価によって自身の職位や給料が決まるのでそれも当然です。 しかしながら、「納得感のある評価を受けられていますか？」と問うと明確にYesと答えられる人は稀でしょう。「成果を出したのに正しく評価されていない」と不満を持っていたり「評価は偉い人が勝手に決めるものだから…」と諦めている人もいるのではないでしょうか。少なくとも過去の私はそうでした。 そもそも、評価をどのように受けるべきか指導や研修を受けたことはありますか？私にはその記憶はなく、自身が評価者の立場になって初めて評価というシステムに真剣に向き合うことになりました。 評価の際に被評価者としてできることは、評価者に自分の成果や成長を適切にアピールすることです。そして、アピールの方法として最も確実かつ重要なのは伝わる自己評価を書くことです このエントリは、被評価者が評価者に正
フルリモートで相手に気持ちよく仕事をしてもらうためのコツあれこれ
社内のプチ発表に使った資料です。 文章のコツ 前置き フルリモートでは、文章でのやり取りがメインになる。 なので、文章がヒドいと「この人と仕事するのキツイ」と思われちゃう😢 そう思われないための色々思ったことを自戒メモ。 なるべく箇条書きにする
ベロシティを高く保つ仕事のすすめ方 / Maintaining a High Velocity as Productivity Hacks
https://findy.connpass.com/event/318375/ での登壇資料です。
兼務による体制構築はプロジェクトの効率を損なわせる｜mtx2s
ソフトウェア開発プロジェクトは、「兼務」を用いるチーム編成が多用されやすい対象ではないでしょうか。エンジニアであれば誰もが経験したことがあるでしょう。1人で複数のプロジェクトやチームを掛け持ちするあれです。マネージャーであれば、組織の人的リソース配置を考える時の手段の1つとして用いたことが何度かあるはずです。 しかし、兼務が引き起こす様々な弊害や問題については、あまり意識されないまま多用されているように感じます。 たとえば、兼務者本人にとってプロジェクトの掛け持ちは、仕事のマルチタスク化やミーティングの増加に苦しむ原因になります。組織の観点からも、兼務への依存は、知識の偏りや負荷の偏りという弊害をもたらすことに繋がりかねません。プロジェクトの観点から見ると、兼務という形での「人的リソースの共有」は、プロジェクト間での「リソースの競合」を引き起こしやすく、それが市場投入までの時間を長くする要
ひとり会社の起業について学んだ10のこと - GoTheDistance
note.com 僕の間違いじゃなければ、時々はてなのブログでコメントを頂いた方のように思う。Python関係で。大変お世話になりました！ 法人の設立にあたっての事務処理と、会社運営のお気持ち編を、自分の体験からまとめてみます。2016年6月にノリ（そうだ独立しよう）だけで起業して7年ほどひとり。今は2人体制になった。 会社を大きくする方法はなんもわからんので、そういう内容を期待される方はすいません！沿わないと思う！ 1. 決算処理は専門家に任せたほうが良い 自分は前職の会計事務所でお世話になったため、起業当初から会計事務所を利用させてもらっている。年間30万弱。決算処理込み。 6月1日に創業したけど、タイミング的に6月になっただけで、深い意味はなかった。会計事務所的に3末はGW進行と重なるので避けたほうがいいかも。 決算処理は確認しないといけない事項が多すぎて、素人がいくら確認しても漏れ
引き受けないお仕事の基準｜Tetsuya Morimoto
たまたまお仕事の断り方という記事を読んだ。ひとり会社を経営してもうすぐ5年が経とうとしている。うちの会社では過去に1度、大きな失敗を経験してふりかえりを行った。その際に引き受けないお仕事の基準というものを社内で作成した。その失敗に至った原因の1つとして、本来引き受けるべきではないお仕事を受けてしまったと後になって反省した。 時代の流れや人手不足もあり、システム開発やプログラミングのお仕事はまだまだ好況にみえる。うちのような零細企業でも、実際に引き受けられるお仕事より依頼の方がずっと多い。そして残念ながらせっかくいただいた依頼をお断りすることもまた多い。 引き受けないお仕事の概要経理の本に書いてあったやるべきではない取引起業したばかりの頃に読んだ次の経理の本にも「やるべきではない取引」として次のリストを提案していた。 報酬が魅力的でも信用できない相手や嫌いな相手との取引 入金が遅い取引 自分
クレディセゾンでDXを進めてきた5年間を振り返る｜小野 和俊
はじめにクレディセゾンに来てちょうど５年が経ったので、これまでの取り組みをまとめてみようかと思う。書き進めていくうちにとても長くなってしまったので、1年につき3トピックに絞ってあとはカットした。それでも5年分なこともありかなり長くなったので、目次から各トピックに飛んでもらえればと思う。社内の関係者も読むかもしれず、「自分のやったことが載ってない！」と思うこともあるかもしれないが、内製開発案件だけでも53案件あり全部載せるととんでもない量になるので許してほしい。それから、振り返ってまとめると退職すると勘違いされるかもしれないけれど、退職するわけではありません！ 2019年：ゼロからのスタート1-1. 内製開発エンジニア募集を始める「日本のそれなりの規模の事業会社の中に、内製開発チームを立ち上げることはできるのだろうか？」 2019年3月、クレディセゾンに来たばかりの私にとってはこの質問への答
メンバー1人1人のスキルアップを促す「等級（グレード）」と「給与テーブル」｜風音屋（かざねや）
風音屋（@Kazaneya_PR）では、メンバー1人1人のスキル水準をモニタリングし、さらなる成長を促すための仕組みとして「等級（グレード）」を設定しています。プロフェッショナル人材が少しでも正当な評価とフィードバックを受けられるように試行錯誤を経てきました。 採用選考を進める中で「自分の場合はどのくらいのグレードになるのか？」というご質問をいただく機会が多々あります。この記事では、どういった考え方でグレードを設計・運用しているのかを、給与テーブルとセットで解説します。 注意事項クライアントワークを担当するAnalytics部門を想定した内容となっています。Backoffice部門の給与テーブルは試行錯誤中ですが、ベースとなる考え方は同じような形に落ち着くはずです。 人事周りのルールは今後変わっていく可能性があります。最新状況についてはカジュアル面談でお問い合わせください。 すべての人にと
社外勉強会への参加は個人のキャリア戦略だけでなく組織が取り組まなければならない課題でもある | Marginalia
引用第7章 越境学習 7.2 越境学習の深層に存在する主要な社会的ニーズ 一般的に人は同じ組織のなかに長くいると、「過剰適応の罠」 や 「能動的惰性」 にとらわれる可能性が高くなるといわれている。ここで 「過剰適応」とは、組織に人が過剰に適応しだすことによるデメリットである (Chao 1988)。また、能動的惰性とは 過去の成功体験にしがみつき、それを永遠に繰り返そうとする個人の状態をさす(松尾2011)。 第3章で論じたような組織社会化の諸力の影響が強ければ強いほど、個人は組織に慣れていく一方で、 ともすれば組織に過剰適応を果たす。自己の組織の特殊性,ステレオタイプ、特有の思考形式を獲得し、 次第に無自覚になり、「文化的無自覚性」の境地に至る。それが進行しだすと、今度は「能動的惰性」 を獲得する。かくして、創造的な仕事を行おうとする個人,自らのキャリアや能力開発に意識的な個人は次第に減
令和最新版エンジニアのリーダーシップ論 - エムスリーテックブログ
エムスリーエンジニアリンググループ製薬企業向けプラットフォームチーム（「Unit1」）の三浦 (@yuba)です。乗り物大好き男の子ですので好きなテレビ番組は銀河鉄道999とナイトライダーです。 さて「フラットな組織」だとよく言われるエムスリー、特にわがエンジニアリンググループなのですが、そのフラットってどういう感じなんでしょう？ 上意下達の体制でない中では、人々はどう組織としての目標を共有して一緒に動いているんでしょう？ この疑問への、（管理職でない）一般エンジニアとして5年半やってきた私なりに得た答えをご紹介したいというのが今回のお題になります。これは エムスリー Advent Calendar 2022 の5日目の記事です。前日は id:hsasakawa による グローバルサービスの開発における技術的な意思決定 - エムスリーテックブログ でした。 そしていきなり最初に結論から言っ
軽率に会社を設立してみた
Tue, Feb 6, 2024 2-minute readひとり合同会社を設立してみました。 なんで？「ソースコードの一行一行は、経営判断そのものだ。」という好きなフレーズがあります。とあるブログ記事の書き出して、ざっくり要約すると、プログラミングの過程においては常になんでこう書いたのか？読みやすさとかパフォーマンスとかトレードオフすべき都合があって、なにを優先すべきか？の判断がなされているはずで、それはつまり経営判断だよね、という内容です。 昨年執筆した「メタエンジニアリング 理論と実践、そして未来」という同人誌でも、このフレーズを引用させてもらいました。文中には「経営とメタエンジニアリング」という章を設け、メタエンジニアリング（つまりエンジニアとエンジニアリング組織への投資）と経営の関係について考察しています。 過去、エンジニアリングと経営の板挟みになった経験は（程度の大小こそあれ）
組織という仕組みで解決することの難しさ、あるいはマネジメントに超人を求めるのは間違っているだろうか - Kengo's blog
そりゃ間違ってるんだけど、ではどうするべきなのかが見えてないなぁという話です。 事業が大きくなると組織という仕組みの重要性が上がる 同僚が何千人といたメガベンチャーから社員数20数人のスタートアップに転職してから1.5年経ちました。ここまでに自分が貢献した内容にはSREや医療情報技師としてのものも当然あるのですが、マネジメント経験のあるIndividual Contributorという立場から組織の成長や組織における連携について補足や関連情報を提供するということも意外とありました。例えば社内ブログや社内勉強会で触れたものには以下のようなものがあります： コーチング紹介 ヒューマンスキル紹介 爆速アウトプットを組織的に支える施策 事業の急成長における表側と裏側 稟議入門 こうした知識や観点を個々人が持つことは、ボトムアップと呼ばれる自発的な行動を支援する意味では大きな意味があります。そして少
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
管理職が一度は読んでおきたい定番「マネジメントの名著」7冊を解説
集中して作業する技術/how_to_work_deeply
Notion – The all-in-one workspace for your notes, tasks, wikis, and databases.
仕事の進め方がグダグダの会社はどうすればいいのか、「プロジェクトマネジメントの基本が全部わかる本」の著者に聞いてみた
リモートワークにおけるファシリテーションの方法論[増補版]_COPILOT![リモートワークにおけるファシリテーションの方法論[増補版]_COPILOT](https://cdn-ak-scissors.b.st-hatena.com/image/square/0b5d2f3bd255efef3c2c9bbfeed073d400e628c5/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2F372179d31405454b9d047426e018ff19%2Fslide_0.jpg%3F27620682)
