物事の抽象度を上げて見ることの重要性

ビジネス 問題解決

抽象度を上げて見るとは

A君、B君、C君、D君、E君、という5人の男性がいたとします。

  • A君とC君が会話をしている
  • B君とD君とE君が会話をしている

この二つの事象を抽象度を1つ上げて見るとどう表現されるでしょう？

  • 男性どうしで会話をしている

になりそうですね。もう一段抽象度を上げてみると、

  • 人間どうしで会話をしている　※変な表現ですが

ということになりそうです。
つまり、抽象度を上げるとは、その情報度合いの具体性を落とし、より抽象的に表現すること、になります。こう考えると、無意識のうちに抽象度を上げて物事を見ている方は結構いるかと思います。

抽象度を上げてみることの重要性

いくつかあると思いますが、個人的には問題解決、問題発生の予防になるというのが一番重要なのかなと考えています。以下に例を挙げて考えてみます。

システムエンジニアリングにおける例

私はシステムエンジニアなので、エンジニアリングにおける例で見てみます。
以下のように5つのシステムがあり、矢印の通りシステム間連携をしているとします。

f:id:roku_sui:20200528002139p:plain

こういった構成でシステム間結合テストを行う場合、一般的に「疎通確認」といってテスト前にシステム間でちゃんと連携できているかの確認を行います。

ところが、この疎通確認を行わずにいきなりテストを始めると、高い確率で以下の図ような問題が発生します。

f:id:roku_sui:20200528003157p:plain

事象としては、

  • システムAとシステムBの連携がうまくいかない
  • システムAとシステムCの連携がうまくいかない

となります。
ですが、この時にこの具体的な事象だけにとらわれず抽象度を上げて見れると、問題の根本解決に繋がります。
上記例を抽象度を上げてみると、つまり、

  • システム間の連携がうまくいかない

という問題が潜んでそうなことがわかります。以上から、（例えば）一度テストを止めて全てのシステム間で疎通が取れることの確認を行ってからテストを再開する、という対策を打てたりします。

このように、似通った具体的な事象が複数ある場合、抽象度を上げて見ることで問題の把握や解決に繋がることが多々あります。
積極的に抽象度を上げていきましょう。

以上です。

【SlideShareから移行3】自分のことは棚に上げる

SlideShareはもう使わないので、SlideShareに上がっているドキュメントをはてなブログに移行します。本記事は移行活動Part3です。これは確か自社勉強会用に2017年にまとめた資料です。

【SlideShareから移行2】ChatOps With Slack

SlideShareはもう使わないので、SlideShareに上がっているドキュメントをはてなブログに移行します。本記事は移行活動Part2です。これは確か自社勉強会用に2016年にまとめた資料です。

【SlideShareから移行1】問題解決プロセス

SlideShareはもう使わないので、SlideShareに上がっているドキュメントをはてなブログに移行します。本記事は移行活動Part1です。これは確か自社勉強会用に2014年にまとめた資料です。

14年間勤めた会社を退職します

ビジネス 転職活動

はじめに

はてなブログデビューしました。そしてデビュー作が退職エントリーです。

退職エントリーを書く目的

今や退職エントリーは世の中に溢れかえっていますが、私は以下の目的で書いています。

  • 自分の今までとこれからを俯瞰しアウトプットすることで頭の中を整理したかったため
  • 将来また振り返った時に当時の心境の変化が分かるようにしておきたかったため

14年間勤めた会社を退職します

2006年1月に入社し約14年間（正確には14年半）勤めた会社を退職します。まさか14年後に退職エントリーを書いてるだなんて入社当時は想像もしなかったですし、当然ながらそこまでのキャリアプランも持っていませんでした。ただ、現実はこんな感じで退職エントリーを書いております。14年間も続けられたのも、社長や上司、同僚、部下、色々な人に支えられてきたからだと考えており大変感謝しています。また、エンジニアとしてもビジネスパーソンとしても人間としても成長できた14年間でした。非常に充実していました。ですが退職します。

退職を決めた時期

2019年8月頃になります。ただ、もうかれこれ4〜5年前から、いつかは退職するだろうなというビジョン（というか退職しないと次のステップには進めないなという懸念）はありました。

退職理由

退職理由は3つあります。

1. 開発しているシステムにオーナーシップや貢献実感を持ちたかった

弊社はSESというビジネスモデルの中の2次受けに位置しています。商流的にはそういった形でしたが、幸いにも出向先の現場ではわりと裁量を持たせていただきました。そのため、仕事もやりやすかったですし勉強になることも多々ありました。ただ、長年その中にいると、色々と疑問も生まれてきます。それが「自分の開発しているシステムに対するオーナーシップや貢献実感」です。SESは契約上「労働力の提供」という形となります。また、2次受けの場合一番重要視されるのは「より良い労働力を提供することで一次受け企業様のビジネスに貢献すること」になります。それはそれで良いと思いますし、私自身長年そのビジネスモデルの中にいたので否定はしないのですが、今後の働き方や将来を鑑みると、

  • このサービスはうちの会社が運営している、うちの会社のサービスが世の中に貢献している
  • 「契約上」エンドユーザーと「（ここ大事なのですが）二次受けではなく直」でやりとりすることでエンドユーザーのビジネスに「直接的」に貢献している

という実感を日々持って働きたい（つまり事業会社だったり一次受け企業で働きたい）と思うようになり退職を決意しました。これが1つ目の理由です。

2. 自分の理想像の追求

長年在籍して、エンジニアとしてはもちろんのこと、組織戦略的？なことから顧客折衝や調整事、チームマネジメント、新人教育の計画・ファシリテーション、最近だとインターン、その他諸々幅広い業務を担当してきました。上司からは、今までやってきてできるようになった業務（もう君がやるまでもないでしょうという業務）は下の世代に任せて君は新しい価値を、という話が以前からありいくつかの業務（例えば新人教育の計画・ファシリテーションや（まだ完全ではないですが）顧客折衝や調整事等）においてはある程度委譲でき後輩を中心に回るようになりました。じゃあ自分は？となった時に、当然求められるものは周りと明らかに違い今までに比べ難易度も高くなってきます。それはそれでやりがいがありそうなものだったのですが、それは自分の目指す理想とは差がありました。その中でモチベーション高くそれを遂行しビジネスに貢献すること、期待に応えることは難しいと感じるようになり退職を決意しました。これが2つ目の理由です。

3. 残ったもの感

今は役職がありそれなりの立場についています。ただ、俯瞰して見るとこれは単に、優秀な同期や同年代の先輩、後輩がどんどん辞めていく中で、結局残っているのは自分くらいという状況が生み出している、というのも少なからずあると思っています。そうした中で与えられた役職や立場というのは個人的には非常に微妙な状況だと考えています。話が逸れますが、退職を切り出した時に上司からも「将来の社長は君だと思っている、期待していたんだよ」的なこと？を言われたりもしました（社長からも任せられる人がいないからやってみるか？という話は過去に何度かありました）。恐らく、このまま居続ければ部長になり、社長になり、といったキャリアもあったかもしれません。ですが上述した心境を鑑みるとあまり惹かれませんでした。話を戻すと、つまり同年代で優秀な社員が多数在籍する会社、切磋琢磨しあえる会社、協力しあえる会社、より規模の大きい会社に魅力を感じ、そういった環境の中で今まで以上に色々なことにチャレンジしたいと思った、というのが3つ目の理由です（もし何らかの役職に就くのであれば「人がいないから〇〇さん「で」いいよね」といった消去法的な形ではなく、「たくさん人がいるけどその中でも〇〇さん「が」いいよね」が理想だと思っています）。
※弊社に優秀な人材が「いない」ということではなく、弊社にも優秀な人材は多数在籍しています。

ちなみに、報酬は同業他社やエンジニア業界の平均と比べるとかなり高く、専業主婦の嫁、娘一人を養いつつ投資信託や娘の将来のための貯金に回したり自分の欲しいものを買えたり等は余裕でできたので、金銭的な不満とかではないです。つらつらと書いてきましたが、14年間勤めた会社を退職します。

退職にあたり悩んだこと

自分のチームメンバーのことを考えると退職するかどうか非常に悩みました。ただ、管理職やリーダーと言われる人達の究極の役割は「自分がいなくても回る状態を作ること」だと考えていて（≒その人がいないと回らない、その人がいないと何もできない、という状態は人依存度が高く悪だと考えている。つまり今までやってきた業務をいつまでも自分がやり続けるのではなく自分の手から離して積極的に別の世代に委譲していく必要があると考えている）、そういう意味では私の代わりになるメンバー、キャリアップにチャレンジしているメンバー、もはや1エンジニアとしてチーム内で高く評価され年々単価が上がっている若手メンバーを見れば、そこに関しての責任みたいなものは少なからず果たせたのかなと思っています。また、自分のようなキャリアパスを辿るのか、別のキャリアパスを見つけてそこを突き進んでいくかは、誰かに言われてそうするものではなく最終的には自身で考えて決めるものだと思っており、そういう意味ではエンジニアとして一つのフラッグシップになれたかなとも考えています。管理職やリーダーと言われる人達の退職は無責任と捉えられがちですが、それは価値観の経年劣化な気がしており、これからはチームに対する責任を果たしつつ1つのチームに閉じこもり続けるのではなく管理職やリーダー自身のキャリアップも積極的に図っていくべきなのかなと考えています。

今後

2020年7月1日から新しい会社です。

転職活動

色々な会社を見て回れたり自分の市場価値を俯瞰して見ることができたりで非常に勉強になりました。また、非常にありがたいことに3社受けて3社とも内定いただくことができました。せっかくなので転職活動についても書きます。

転職活動期間

2019年10月頃～12月頃に下記媒体に登録を行い情報収集、絞り込み。2020年1月に退職の旨を会社に伝え、同時に数社に話を聞きに行き始め、2020年2月～3月で面接（3月に内定）、といった形で活動しました。なので、大体半年くらいで次の会社が決まった形になります。ただ、業務の都合上、6月まで在籍しなければならなかったので退職時期が今となりました。

転職活動に使った媒体
  1. ビズリーチ
  2. OpenWork
  3. Green

基本的に自分からは探しにいかずスカウトが来た中でマッチしそうな企業やエージェントを絞っていきました（ビズリーチはめっちゃスカウト来ましたが、多分企業スカウトもエージェントスカウトも数打てば当たる的な形でスカウトしてきた感がありました）。

面接で聞かれたこと

覚えている範囲になります。当たり前の質問から抽象的な質問まで色々ありましたが、技術的な質問はそこまで多くなかった印象です。抽象的な質問は、回答の内容とそれがロジカルに話せるかを試されていた感じがします。

  1. 自己紹介
  2. 職務経歴
  3. 転職理由
  4. この会社を選んだ理由
  5. いつから入社可能？
  6. これまでで苦労したこと
  7. 技術とマネジメントどちらを中心にやりたい？
  8. 自分の強み
  9. ミドルウェアは使いこなせる？（まあ人並みにと回答）
  10. インフラの構築はできる？（できないと回答）
  11. 入社したら何やりたいか
  12. どいうったシステムの開発がやりたいか
  13. 将来どうありたいか
  14. プロジェクトマネジメントで気を付けていること
  15. 一番辛かった経験
  16. 一番難しかった経験
  17. 今の年収と希望年収
新鮮だったこと

新しい会社でのことです。

  1. 社用携帯を支給していただける（今まではプライベート携帯に業務ツールを入れて業務連絡を行ったりしていたので、これが一番新鮮だったかも）
  2. 裁量労働制の適用（今までは例えば30分とか1時間の遅刻で午前休扱いになってたが、裁量労働制なのでそうはならない、これが二番目に新鮮だったかも）
  3. 様々なキャリアパスがある
  4. グループ会社が複数ある
  5. 拠点が全国にある

最後に

転職活動を通して改めて思ったのは、楽しかったこと、苦しかったこと、悔しかったこと（仕事中悔し涙を流したことが14年間の中で2回ありました）、色々ありましたが14年間必死にやってきて良かった、ということです。14年間で11のプロジェクトを経験してきましたが、1つ1つのプロジェクトの経験が濃厚だったため、面接でも全てを伝えきれないほどでした。ただ、やはりそういった経歴はどの会社に行っても評価に値するということを実感しましたし、今後も自分の強みとなると思います。また、Qiitaにも定期的にアウトプットしていて良かったと思いました。職務経歴書でスキルセット、マインドセットを全て表現するのは難しく、それを補うためにこういったアウトプット成果物があるのとないのとでは企業側の印象が全然違うんだな、と実感しました。
qiita.com

ここまで育ててくれた会社や支えてくれた同僚、部下、後輩の方々には大変感謝しています。それだけに、こういった形で退職することとなり申し訳ない気持ちもあります。ただ、やはり自分のやりたいことや自分が望む会社で働くことはそれくらい重要なことだと考えていますし、何より「1つの会社に長くいること」は人生の目的ではないと思うので、このような決意をしました。今後も頑張りたいと思います。

今のテンション

以上です。