カブトムシの壺

消しゴム付き鉛筆

どうしたら早く仕事を終わらせられるのか

baigie.me

 

私はたぶん仕事が遅い

社会人生活11年目だけども、よくある悩みとして「人間関係」というのがある気がして。ただ幸い私は職場環境で人間関係に悩まされたことが少なく。私の一番の悩みは「自分の仕事が遅いこと」であったし、今でもそうである。

 

というのも

 

「自分の特性」

・あまり自分のキャパシティを考えずにとりあえずやってみます、と言ってしまうところがあり、気づけば仕事が積もり積もることが多い

・それでいて、仕事もプライベートも同じくらい大事にしたいので、仕事は可能な限りさっと終わらせたいという気持ちが高い

・完璧主義的な面があるので、自分が網羅的に理解、整理出来てないと感じると意思決定のスピードが遅くなってしまって最後の最後の締切までアウトプットを渋る傾向がある

・気になることが出てきてそれが短時間で終わるタスク(連絡・相談など)だと思ってしまうと、自分がやるべきタスクは後回しでなんとかなるかと思ってしまう

・自分で言うのもなんだけども頭の回転の速さとか器用なところはあって、その場の機転でなんとかすることも多い。それもあって、なんとかなるかと考えがち。

 

という特性があり、それが相まって「なんだかんだで結局自分の仕事って遅いな」と思う場面が多いのである。多分1週間に2,3回は思っている。

 

ただ、最近諸事情によりそんなことをダラダラと言ってられないことになり、もう「仕事を最速で出来る前提」で動くことになった。

 

どうしよう

どうすれば良いかなぁと試行錯誤して過ごしつつ、こちらの本 「なぜ、あなたの仕事は終わらないのか」と、この記事を読んで今のところ自分の納得いく答えが出たように思うので、まとめておく。

 

baigie.me

 

Q. どうして仕事を早く終わらせられないのか

A. それはお前がまだまだ弱いからです 完

 

もう少し書く。

 

仕事が終わらない理由

「なぜ、あなたの仕事は終わらないのか」という本では"ロケットスタート時間術"というものを説明されていて、この本では「期日までの最初の20%の期間で80%終わらせる」というものを紹介している。

これは本の著者がエンジニアでもあるし、私もITの世界に生きるものなのでとてもよく分かるのだが、「ITのプロジェクト = 不確実性をどれだけ下げられるかの戦い」という面でとても合理的な戦術だ。

私もこの本を一部実践してみたのだが、その中で気づいたことがある。それは「そもそもの最後の成果物のイメージやプロジェクトの成功のイメージの具現化ってむずくない??」ということだ。というか、それが具体的にイメージ出来た時点でほぼ終わってるのかもしれない。

 

その中で先ほどの記事を読んで、「そもそもの知識や理解が足りないからゴールをイメージ出来ていないだけだし、次のアクションをすべきかの意思決定が遅いだけなのでは」ということに、はたと気付いた。

 

つまり、自分は仕事が遅いことを「決断力や行動力が少ない、優柔不断」という性格のせいにしてたけども、単純に「知識や理解・整理」が足りないせいだということだ。

 

この仮説に立って考えると対処は明確で、

 

・知識不足 => 関連の本を読んで、網羅的・体系的に理解する。資料を読み込む。

・理解・整理不足 => 自分なりの言葉で整理し直す。図解する。人に説明してみる。

MTGにて相手と意思疎通が出来ずに時間がかかる => 本を読んで言葉のボキャブラリーを増やす。相手に合った言葉選びをする。自分の経験を増やして例示できるようにする。

 

という感じになるかなと思ってきた。つまりは

 

Q. どうして仕事を早く終わらせられないのか

A. それはお前がまだまだ弱いからです。まず上記の内、どこが弱いかを分解して対処しましょう、となる。

 

終わり

仕事を早く終わらせるための答えが、仕事を叩き潰すために入念に準備するというのはどこか矛盾している。なんだか自分でもこれで良いのか感はあるけども、向かうべき方向性がはっきりして晴れやかな気持ちでもある。と言うわけで、これからは仕事が遅い原因を見極めて、その原因を本気で叩き潰しにいくようにする。

マネージャーはなぜ忙しいのか。3年間やって少し分かってきたこと。 とか今年の感想

この記事は、

 

フラー株式会社のカレンダー | Advent Calendar 2023 - Qiita

 

の3日目の記事です。

 

ポエムです。一年をふりかえります。

 

1

気づけば、エンジニアリングマネージャーをやっている時間が長くなりました。去年もマネージャーだったし、今年もマネージャーだった。

新規案件の見積もりや、開発の上流工程に参加したり、アサイン計画などなど。いわゆる、マネージャーとはこういう仕事をやるものなんだなと一周した感覚が今年の何処かからありました。

 

しかし、慣れても忙しいのは変わりなかったりします。

というか、もはや「忙しい」という話とかでもないかもしれないということが分かってきました。

 

というのも「役割」を減らさないと一生仕事が減らないということです。

 

例えば、プロジェクトA,B,Cのエンジニアリングマネージャーを務めていたとして、直近の緊急性のあるタスクを全て終わらせた、としても更にその先を見通すとやることは沢山あるわけで、仕事が減らないのです。

 

タスクの優先順位をつけるというよりも、役割の優先順位をつけておく方が良いなぁということに気づいてから多少楽になったように思います。

 

2

今年は、社内の勉強会で「概算見積もり」の話をしました。

余裕はなかったけど、どうしても話したかったので。話したいことを話せたので楽しかった。来年も一度くらいは何か話す。クライアントワークだとどうしても、お客様があってのものなので、社外に話しにくく、すごくモヤモヤするところなのだけども、ここは話しても良さそう、ここはダメそう、の感覚がわかってきたのも今年はよかったように思う。

 

3

最後に今年読んで、とても良かったスライドとかポストとかを載せます。

speakerdeck.com

今年もkonifarさんの言葉に何度勇気をもらえたか分からない。いつも読んでいます。

 

 

マネジメントやっぱり何も分からないので、EVeMさんのツイートをよく読んでメモしています。僕の考えの半分はEVeMさんに書いてあること。

 

 

https://twitter.com/onigiritan/status/1706240678915944477

当たり前だけど、論理とか理屈だけではないよねってハッとしました。

 

いつもキレッキレさかいふうたさんのポスト。「率先垂範」が私の今年のテーマですが、おそらくしばらくそうなりそう。難しい。

 

毎年、雑で、すみません。

他の方はもっと良い感じの記事を書いてると思いますゆえ。

 

明日は@Nao1215さんで

Golang】hottest - ユニットテストのエラーメッセージを抽出するCLIGitHub Actionsを作った話

です。

統括マネージャーとしてダメだったなと思うところ

この記事は、

フラー株式会社のカレンダー | Advent Calendar 2022 - Qiita

の18日目の記事です。

 

 

何かしら業務に関連したこととか書こうと思います。タイトル通り、今年は統括マネージャーというエンジニアリングマネージャーの中の、組織開発的なところも行う役職につきました。ダメだったなと思うところを書こうと思います。

 

統括マネージャーの仕事

・クライアントワーク案件のアサイン調整

・売り上げ目標の予実把握と管理

・組織課題の発見と対処

 

などなど

 

ダメだったところ

1.自己管理が出来ていなかったところ

↓この資料にも記載されておりますが、マネージャーは自分の時間の管理が大切ですが、自分自身の業務管理が出来てなく、常に稼働率100%の状態で、落ち着いて考える時間が持てなかったように思います。また、プロジェクト管理をするマネージャー業務と組織管理をするマネージャー業務を兼任していたのも頭が混乱する原因の一つでした。

 

www.ryuzee.com

 

□「対処」

・最近はNotionに細かくTodoリストを立てつつ、GoogleカレンダーMTGの予定と作業時間を細かく管理して、上手く回るようになってきました。

・また、プロジェクト側のマネジメント業務はできるだけ減らすようにしつつだが、いっそプロジェクト側のマネジメント業務を優先して行うようにしていて、それも良かった。

 

2. メンバーとの対話が足りなかったこと

・ピープルマネジメントは他のマネージャーに任せる、という立て付けで業務を行ったんですが、それもあんまり良くなかったように思います。マネージャーの業務って周り回って絶対に最終的に人に還元されるものだからです。その1次情報となる、メンバーとの会話は貴重で、ここが不足していて、何の課題にフォーカスすべきなのかの感覚を失いがちになっていたように思います。

 

□「対処」

・雑に定期で1on1をするなどしても良いかもなと思っています。これはすぐ出来ることなのでやります。

 

来年やりたいこと

・結構マネジメントをやってみて、「なんか正解、本に書いてありそうだな」って思うことも増えたのでそろそろちゃんと本を読みます。輪読会やります。各位、よろしくお願いします。

 

雑ですが、この辺で。

 

最近の仕事の仕方メモ

実現したいこと/こうなりたくないこと

  • 社内のSlackはなるべく早く返したい(気持ち的にも落ち着かないし、覚えておくのもいちいちメモしておくのも大変)
  • 残業ありきで組みたくない(一定の時期に負荷が高まるのは大丈夫だけど中期で続くと私は体調崩すので)。昼間は諦めて、夜に、、、というのが楽だけどそうしたくない。

やり方

  • 思いついた仕事を一定まで自分で潰すところまでやる、を繰り返す。
  • 「一定」というのが大事。時間かかりそうなことをすべて後回しにしないで、一段落つけられるところまでやる。
  • 思いついた順にやってくと、本当に優先度高いタスクが埋もれてしまうのでは、と懸念していたけど、全てのタスクを見通して並べるほうがもう大変なのでそこは諦め。本当に重要で、優先度高いものはどうせ何度もリマインドきたりするのと、動物的な勘が反応するのでまぁ大丈夫、と思うようにする。
  • 一定潰すまでSlackには反応しない。即レスはできなくなるけど、妥協する。一定潰した後に、まとめて反応して返す。
    • 近日中にやらないといけないこと、はタスクバックログ的なものに思いついたときに書いておく。

良質な問いを投げかけること

課題解決よりも課題発見の方が大事、というようなことが「イシューからはじめよ」にも書いてあった気がする。

 

組織の課題を発見して解決することがマネージャーの仕事だとして、そうでない方の自律性を促すという意味では、良質な問いを投げかけて自身の課題を自分で把握してもらうことも重要だと思った。

 

今、月に1度1on1をしていて、人によっては「うーん」と中々答えが出てこないときがある。そんなときは質問の仕方を変えてみたり、色々とこねこねして気まずくならないように会話を続けるけども、もしかしたら私の質問の仕方だったりそもそもの1on1の意図が伝わってないかもなと以下の記事を読みながら思った。少しフォーマットを考えてみよう。

 

 

あと、こういうことを書くのは手の内を明かしているような気がして、嫌というか恥ずかしいと言うか、まぁ真面目に書くとこれを読んだ1on1の受け手への影響がどうなるのか分からないなと思っていてオープンにしていなかったけども、そんなに悪い影響与えないかなぁとか、うじかわはこんなこと考えてるんだなって分かるのも悪くはないんじゃないのと思って今年はこういうこともダラダラと書いてみる。1週間に1度くらいはこうやって休日にふりかえりながら書いてみようと思う。(ダメそうだったらやめる)

 

今日はそんな感じで。

「コーディングしない」という不安に対してマネージャーはどう向き合うか

この記事は、フラー株式会社 Advent Calendar 2021の19日目の記事です。


18日目の記事は@nnsnodnbさんの 「ハードコードを許されない変数をどうしても Xcode プロジェクトの Info.plist に差し込みたいでした。

 

 

前回のブログ更新からあっという間に1年が経ちました。過去類を見ないほどに異常な状況下になってから2年も経つことになるのだなと思うと、不思議な気持ちになります。家族共々無事で過ごせることのありがたみをしみしみと感じてゆっくり年末を過ごそうと思います。

 

久々の更新ということで、テーマに沿いつつも、今年一年をふりかえりながらダラダラと書こうと思います。

* 他の記事のような有用な情報は多分ありません。(居酒屋で「マネージャーになって、コーディングしなくなって、不安とかないんスカ??」って後輩に聞かれたとしたらこう答えるなぁという回答をまとめておくことで、少しでも中間管理職になりたい人を増やせれば!という作戦の記事です。)

 

引き続き、チームマネージャーとしての仕事を1年しておりました。エンジニアの応募者の方とのカジュアル面談、書類選考、チームメンバーの1on1、評価面談、アサイン調整、プロジェクトのリスク管理工数管理、概算見積もり、人が増えてきたことに付随して生まれた組織課題に対する提案と実行などが主な仕事でした。

 

その中で、「出来れば現場感覚を忘れないようにコードを書いてほしい」と上司から軽めのお達しがあったのですが、序盤についてはコードレビューをしていたり、少し自身でコーディングしていた部分があったのですが、徐々に自身でコーディングすることから離れていきました。

 

なぜか。色々な事情はありますが、端的に言えば、得意な人に任せて、私は私の役職でしか出来ないことに注力したほうが組織が上手く回りそうだなと思ったためです。

 

また、高専から長らくコーディングをやっていましたが、自分よりも得意で向いている人を本当に沢山見てきました。なので、組織を俯瞰する役割になったときに、自身がやるというより、出来る人を採用したり、育てたり、開発が上手く回るように障害を取り除いたりする方に自然と考えが及ぶようになりました。あくまで自然に。気づいたらそうなっていたという感じです。

 

しかし、「コーディングしない」というのは中々にもどかしく。不安になることも少々ありました。どんなことに不安に思って、今はどのようにそれを整理をつけたかというのを書きます。

 

「転職出来ないのでは、の不安」

 マネージャーの仕事というのは、社内の調整や外部のクライアントとの調整などひとりで完結する仕事というのがほぼなく、すべてチームプレイなので、成果を示すことやどんなスキルが伸びたかというのが非常に分かりにくいです。なのでふと、自分の市場価値が分からなくなってくることがありました。社内では評価されても、社外だとスキルが微妙なのでは、みたいな不安です。

 

(対処) 自分の職務経歴書をアップデートして、外部の会社の人と話したり、カジュアル面談などしてみるのが良かったです。転職エージェントの人と話すだけでも。あくまで、めちゃくちゃ良い条件のところがあればというのは伝えた上で。実際やってみると、今の会社の良いところ沢山あるなぁと見つめ直すことも多かったです。結構疲れますが、今の自分の足りないところとかも知れることになります。

 

「口だけマンになってないか、の不安」

 ふと、自分は結局口を出すだけで何もやってないから、チームから面倒くさいと思われてないかなど不安になります。

 

(対処) 面倒くさいって思われてても何でも良いから、最終的にチームの目標達成をするのが自分の仕事と割り切る。というか、多分面倒くさいって思われてない。少しでもネガティブになったら終わり。

 

「あの頃の未来に僕らは立っているのかな、の不安」

 ふと、「昔コード書いてたときは」という発言が多くなっていることに気づき、このままだと若手エンジニアに裏で「昔、コード書いてたときはって言われても、俺その頃見てないから説得力ないわ」って言われてるのではと不安になります。

 

(対処) たまにコード書いたり、コードレビューしよう。

 

という訳で、色々書いているうちに不安になって少しコードを書きたくなりました。明日少し、Androidのコードでも書いてみようと思います。来年は少しコードを書こう。何かテーマがぶれましたが、そんな感じで。

 

明日は、スーパーアルバイター @maezawa1234 で「なにか書きます!」の記事です。お楽しみに。

 

小さな開発組織のマネージャーになってから1on1で考えていることを少しだけ書く

この記事はフラーAdvent Calendar 2020の22日目の記事です。 21日目はinoriko771 さんで「docker-composeでローカルでの動作確認用環境を準備したお話」でした。

 

 今年の夏にマネージャーやってくださいというオファーを受けて、「そろそろAndroidだけじゃなくてそういうこともやっていくかー。良い機会かもしれない」と思ってやりました。主に、他社様から依頼を受けてアプリ開発やWebフロントの開発をする仕事のエンジニアとデザイナーのユニット、正社員13名のチームのマネジメントです。

 正直、「マネージャーとは?」みたいな感じでそもそもあまりピンときてなかったのはあるのですが、まぁやってみながら考えるかーという感じで半年間やっています。その中でも1on1をたくさんやったなぁと思ったので今日は1on1にフォーカスをあてて考えていたこと・今考えていることを整理してみたいと思います。

 

1on1をやる時に考えていたこと

この本を参考にしつつ、チーム内全員と月に一度必ず1on1をしています。

 

 書籍に忠実に、話し手が主役になるようになるべく聞き手に回って、自分からの話が多くならないように(というか極力何もしない)しています。

 

 なんですが、簡単には書籍通りにならないなと思ったことはありました。例えば入社歴がまだ浅い人にはフィードバックを多めに返してあげても良さそうとかです。そもそもその人の振る舞いを褒めるということをしないとどういう振る舞いが求められているか分かりません。また、このリモート下で振る舞いも画面越しかSlack上での振る舞いしかわからなくなってきました。なので、特に入社歴が浅い人にはフィードバックを多めに返すようにしています。

今でもそうしているのですが、リモート環境下で雑談の時間が減ったこともあり、新入社員の方には入社してから1ヶ月間は1週間に1度お話をしています(メンターはメンターとして別にいます)。これは私が自主的に始めたのですが、毎回入ってきた社員から「これは続けた方が良いと思います」みたいな言葉を頂くのでこれからも続けようと思っています。

 今の組織を俯瞰して見つつメンバーに一番近い存在として私を利用してくれれば良いのかなという役割で考えています。

 

軽さを大事にすること

あとは、エッセンスとして取り込んでいる考え方を少し紹介すると、このお二方の言葉で表現されるような、社内だけの世界で考えないようにする「軽さ」のようなこともお話のテーマとして大事にしています。その方が結果的に成長の幅が広がりそうだと思っているし、そう考えた結果会社に居続けることは違いそうとなった時にまた考えれば良いかなぁと。

 

もちろん積極的に転職を勧める訳ではないので、言葉の強さみたいなことは気にしながら聞きますが。

 

大事なのはテクニックとかではないのかなと

 まだ半年しかやっていないので、なんとも言えないですが、他の会社のマネージャーが言ってたことなんですが「楽しげにする」ということは1on1で大事にしています。楽しげでなくとも疲れたなぁという感じで話さないということです。いつも、なにかセンシティブな悩みを抱えているのかもしれない、という気持ちで真剣に向き合ってお話を聞くように集中して30分間は話を聞くようにはしています。

 今、1on1の4周目なのですが、ようやくその人の本質的な部分とか価値観が分かるというか、今までの話をつなげつつ本音で話せるようになってきました。いや、勘違いかもしれませんが。ただ、そういう感覚は出てきました。細かい聞き方だったりの工夫とかは必要であれど、これからも大事な時間として扱っていこうと思っています。

 

結局ふわふわした話になってしまった。難しいですね。マネジメントの題材は。もう少しかっちりした話を次はしたいです。

 

駄文ですが、読んでくださりありがとうございました。

 明日は Masahiro Mitta さんで GitHub Actions&Firestore Emulatorでテストを書いたお話です!!よろしく!!