Akio Watanabe

エンジニアリングから一転、組織マネージメントの面白さに取りつかれてます。

Akio Watanabe

エンジニアリングから一転、組織マネージメントの面白さに取りつかれてます。

最近の記事

【2ヵ月/90人/1時間】オンライン1on1してわかったこと

今の会社に2021/03に転職をしまして、VPoEとして活動することになり、 一番最初にやらなきゃ。と思ったのが、メンバー全員と1on1でした。 VPoEって、人材戦略を考える人です。組織開発もミッションとして持ってます。でも誰一人顔を知らない状態で、施策出してドヤ顔してたら微妙ですよね。なので、まず全員と1時間、お話ししようって思いました。 ※これ許してくれた上司に感謝しかない。 なかなかこの短期間で、これだけの方と1時間お話をすることは無いので、 学ばせてもらったことを

    • なぜ、感謝するのか

      個人的に、「ありがとう」という言葉が口癖になっていて。 ちょっとしたことでも、すぐに伝えられるように、昔から意識して口にするようにしていた気がします。 当時は何を考えていたわけでもなく、感謝は口にした方が良い。と勝手に思っていたんですが、理由を言語化してみたくなりました。 結論から言うと、 同じ考えの人なんて、この世に一人もいないから、 少しでも、何かが伝わりあったら、それだけでも、とても有難い事 という事。 ダイバーシティは、ずーっと前から ダイバーシティだ。多様性

      • リモートはコロナのため?新しい働き方のため?

        元々、管理ができていた時代長くその仕事を行っていることで、ノウハウを蓄積し、この先起こるであろうリスクを、ある程度把握できていた時代。 その頃は、人を「生産性」という数字に置き換える事で、「人数」や「効率性」が武器になっていました。 今はVUCAの時代と言われて久しく、とうの昔に終身雇用も崩れ、キャリアなんて誰も保証してくれなくなり、自分で作る時代になりました。 「マネジメント」という言葉の持つ意味も複雑さと多様さを含み始めた昨今、コロナを理由にリモートワークに切り替えざる

        • テキストコミュニケーションのガイドラインを書いてみた

          背景ほぼ全員がテレワークとなり、文字ベースのコミュニケーションが圧倒的な割合を占めるようになったので、 自部署の皆に、円滑なコミュニケーションを心がけてほしくて、ガイドラインを書いてみました。 ※社内では、Slack使ってるので、それベースです。。。 相互に伝えあうことが目的であることを意識する1)読み手の気持ちを考えて書くこと 雑でもいいんです。ただ、変な風に読まれたら素直に謝る。 「アーそういう風にもよめるなー」 と思ったら、書き方が悪かったと思って、素直に謝りまし

        【2ヵ月/90人/1時間】オンライン1on1してわかったこと

          チームビルドからフロービルドへ ~タックマンモデルで大切な事

          突然ですが、肩がこる原理、知ってますか?1)特定の姿勢を続ける 2)筋肉が緊張し続ける 3)血管が収縮して、血流が悪化する 4)老廃物がたまり、痛みが出る この結果が、肩こりが生じます。放置すると、痛みにすら慣れ、 こっていることを忘れてしまいます。 チームや組織が硬直化する原理も同じようなもの1)特定の仕事を、同じやり方で続ける 2)期待が膨張し続ける 3)視野が収縮して、情報の流れが悪化する 4)個別最適化が始まり、歪が出る 成果が出た。という成功体験をベースに、特

          チームビルドからフロービルドへ ~タックマンモデルで大切な事

          いきなり1on1を受けたら、気持ち悪いほどスッキリした話

          前置き前回のEM集会で登壇されていた、nitt-sanさん。いきなり1on1とか、相当エモくも尊敬できる取り組みをされていて、人に1on1されることなんて、そうそうなくなってきたし、他の人の1on1を受けてみたい、学びたい!と、お願いしてきました。 今回の1on1のnitt_sanさんによるまとめは、こちらからどうぞ。 アンケートを書くまずは、今日話たいことのアンケートに答えていきます。 書いてる最中も、ちょいちょい話しかけられます。 設問の置き方も計算されてるのかな?

          いきなり1on1を受けたら、気持ち悪いほどスッキリした話

          「相手が変わらない」なんて、偽りは止めよう

          人が他人に不満を持つとき、その不満を掘り下げていくと、 「自分は何かをやってほしいのに、相手はやらない。」 「自分はこうなってほしいのに、相手はなってくれない。」等の、 「自分の要求が叶えられない事」に、大抵は帰結します。 あなたのため、将来のため、なんのためかんのため どんな理由をつけても建前で、本当は、 誰かに何かを変えて欲しい時は、必ずと言っていいほど、自分が何かを得たいときだ 昔、これに気付いて、これを自分で認められたとき、なんかこう、達観できた気持ちになって、

          「相手が変わらない」なんて、偽りは止めよう

          とあるエンジニア組織が成長していく軌跡(第4回 3カ年計画編 後編)

          ビジョンの種を見つけ出し、3か年計画を立て始めます 前回の振り返りビジョンを見つけるために、3年後どうなっていたいか。を考え、2年後どうあるべきか。1年後に何をしているべきか。とブレイクしていきました。 3年後(という理想的な)の組織イメージ今の採用を考える上で、選ぶ側だと思っている方は少ないと思います。 売り手市場だから。とかではなく、働く人の考え方が根底から変わってきていますよね。もはや、企業が人を選ぶ時代なんて終わっています。 また、キャリア形成を重要視する風潮は

          とあるエンジニア組織が成長していく軌跡(第4回 3カ年計画編 後編)

          とあるエンジニア組織が成長していく軌跡(第3回 3カ年計画編 前編)

          ミッションを考えた後、成長戦略を考えていきます。 そのために、まずは、ビジョン探しをしていくことにしました。 前回の振り返り 前回、色々と悶々と考えた結果、 Prideを持ち、Speedを意識し、Valueを生み出す。 をミッションに定め、そんな組織を創るための成長戦略を考えて行きました。 マインドと行動指針ミッションを定めたあと、成長戦略に入る前に、このミッションに向かうために、どんなマインドでいて欲しいか。どんな行動をとって欲しいか。 その辺りを考えていきます。

          とあるエンジニア組織が成長していく軌跡(第3回 3カ年計画編 前編)

          とあるエンジニア組織が成長していく軌跡(目次)

          第1回 背景と経緯編 これを書こうと思った背景と、経緯をまとめています。 僕が勤めている会社の状況から、部長をやっている組織の課題等 第2回 ミッション再構築編 ミッションを再構築するまでの経緯や考えをまとめています。 第3回 3カ年計画編-前編 ミッションから、中期計画に落とすまでの経緯等。 ミッション~ビジョン策定まで 長くなってきたので、分割しました。 第4回 3ヶ年計画編-後編 ビジョンから計画までの経緯。 思い出せば出すほど、赤面。ワードセンス、どこかに落ちて

          とあるエンジニア組織が成長していく軌跡(目次)

          無駄なルールはなんで増えるのか考えてみた

          今年の抱負に組織文化を作りたい。となったのは、去年のサイボウズデイズに参加させていただいて、青木社長のお話に、 会社はルールでは縛らない。文化で縛るんです。 という話がありました。良い言葉なんだけど、それを採用しようとして、ルール完全撤廃なんてしようものなら、回らなくなることは火を見るより明らか。ようやく最近腹落ちして、文化を作りたい!となったので、その解釈をアウトプットしてみます。 ※超個人的解釈です。 ルールが必要な理由そもそも、の話ですね。 業務を回すのに必要な

          無駄なルールはなんで増えるのか考えてみた

          とあるエンジニア組織が成長していく軌跡(第2回 ミッション再構築)

          第1回では、背景を書きましたが、今回はミッションを再度定義し直した話を。 ところで、エンジニア組織って?会社の中にある組織は、すべからく価値の提供を求められています。エンジニア組織。と一言で言っても、会社によって求められる価値は様々ですし、そもそも「エンジニア」の定義も会社によってバラバラ。 今いる会社で当てはめるとしたら、システム構築する人をエンジニアと呼ぶ傾向が強いので、モノを作り出す組織と定義して、考えています。 業務分掌では足りない過去、あなたの組織のミッション

          とあるエンジニア組織が成長していく軌跡(第2回 ミッション再構築)

          とあるエンジニア組織が成長していく軌跡(第1回 背景と経緯)

          前回書いたノートで宣言した風土を作りたい。という想いが形になるまで時間がかかりそうなので、こっちの2018年振り返り記事で、今もなお取り組んでいる施策達はどういう想いで、何をやったのか。を、自分たちが歩いている軌跡を残しつつ、細かい振り返りをするためにも、書いていこうかと。 2018年度に取り組んだ(今も取り組んでいること)1)部のミッション再構築と明文化(作って話して、今も話してる) 2)組織の3カ年成長計画の提示(作って話して、今も追いかけてる) 3)エンジニア評価の再

          とあるエンジニア組織が成長していく軌跡(第1回 背景と経緯)

          エンジニアを増やす事と離職率を下げる事に共通する1つの事を、今年は頑張る

          採用活動を頑張っても、人が辞めていくんじゃ意味が無いので、しっかりと離職率も併せて下げていくことを考えています。 ただ、最近のエンジニアの平均勤続年数は3年程度。増やしつつ離職率を下げる。と、両軸を狙っていかないと、もうどうにもならなくなるのは、火を見るよりも明らか。 IT人材白書 2018一応、今期の上半期は2桁の離職率だったのが1桁に減ったので、これを更に下げるべく去年探していたら、あー、、、見てなかったな。と気づき、熟読。ここに、1つデータとしていいものがありました。

          エンジニアを増やす事と離職率を下げる事に共通する1つの事を、今年は頑張る

          2018年最後に、エンジニアマネージャーとして今までを振り返ってみた

          エンジニア組織の課長を3年くらい。 PMやQCや技術サポートの組織なんかの課長を1年くらいやって、 今は、部長をやらせてもらっていて。 という構成で、過去を振り返ると、だいたい5年くらいになります。 区切りもいいので、気づいたこと、得たことをアウトプットして見ようかと。 エンジニアマネージャーって何する人?エンジニアマネージャーって言葉も、広義ですよね。って事で、 いわゆる管理職や組織長と呼ばれる、組織マネジメントをする人。 に絞って振り返ります。 1年目:はじめての、マ

          2018年最後に、エンジニアマネージャーとして今までを振り返ってみた