会社の案件でインセプションデッキやってみたよ
- まずはインセプションデッキと実際にやってみたアクティビティの概要を説明
- 社内の偉い人にインセプションデッキやらない？って提案してみた
- インセプションデッキのアクティビティが4時間構成になる
- 試してみてブラッシュアップした
- お客さんと試してみた
- 結論
ご無沙汰しております。ずっとサボっていました。 転職して1年半くらいが経ちますが、いつの間にかスクラムマスターをやっています。
いろいろありました。スクラムやっていますが、うまくいかないことおおすぎるやろってくらい、想定外のこともありました。
その話はまた別途書きます。 今日は、とりあえずずっと書こうと思って書いてなかったインセプションデッキの話をします。
あんまり大したこと書いてないけど、インセプションデッキやってみようかなーと思っている人が誰かに説明しやすいように、インセプションデッキってこんなだよ！Litaはこんなことやったよ！というのを紹介するためのスライド作ったので誰かの役に立つといいな。
まずはインセプションデッキと実際にやってみたアクティビティの概要を説明
スライド見てね！（雑）
インセプションデッキの紹介 from lita
社内の偉い人にインセプションデッキやらない？って提案してみた
ことの始まりは、なんか何やるかも分からない新規の案件にアサインされることになったこと。 ある日突然、「これからお客さんと何やるかを含めて検討していく予定で、スクラムでやるよ！一緒にやって！」と社内の偉い人に言われた。
その偉い人は、新しいものが好きなタイプで、チャレンジすることを許してくれる感じの人だったので、それならインセプションデッキやりませんか？と提案してみた。
「インセプションデッキって何？」と聞かれて、ちょっと説明したら、「いいじゃん！やろう！せっかくだから他の案件でもできるようにテンプレ化して！」と言われた。
とりあえずやってみるか、ということでテンプレートを作ってみた。
インセプションデッキのアクティビティが4時間構成になる
そもそもそんなに時間が取れない、と事前に釘をさされていたので、頑張って最低限必要と思うところを切り出して、短くなるように構成してみた。
…結果、4時間になった。 4時間！だいぶ短くなったな、と思って偉い人にテンプレートを持っていったら、長すぎると言われて撃沈した。
2時間くらいにしてほしいらしい。 正直やる気あんのか？と思ったけど仕方ないので短くした。 削れるところは削った。 そして結果、スライドにあるように無理矢理すぎるかなーという時間構成になった。
とりあえずやってみるか、ということになったので、まずは社内案件で試してみた。
試してみてブラッシュアップした
やはり時間が足りない。
社内案件の参加者の声からは、以下のような声があがった。嬉しい声もあったが、時間が足りなかったという声が多かった。 そりゃそうだよねー。
- 案件に関する理解が深まった
- プロジェクトメンバーといろいろ話せてよかった
- 案件の目的について考えることが今までになかったのでいい機会だった
- エレベーターピッチを作るのに時間が足りなかった
- 全体的に時間が足りなかった
偉い人に、「やっぱりちゃんとやるなら2時間は短すぎますよ！」という話をしたら、『うーん、そうだねぇ…もうちょっと削れない？』と。
苦渋の決断で、 ’やらないことリスト’ と ’ご近所さんを探せ’ が削られた。
やった方がいいと思うんだけど、最終的には偉い人判断で「やった方がいいのはわかるけど、ここはさらっとわかっている範囲を紹介するだけにしよう」と。
じゃあ案件が始まってから継続的にみんなでアップデートしていけるようにWikiにしてまとめていきましょう、ということで合意。
その後もいろいろ調整して、結果として以下の4項目をやることに。
- 我々はなぜここにいるのか
- エレベーターピッチ
- 俺たちのAチーム
- トレードオフスライダー
それにプラスして、チームビルディングのためのアクティビティとして、以下を追加し、キックオフアクティビティとした。
- Pet Peeve(苦手なこと共有)
- グランドルール
そして時間も基本は4時間でやっていこうということになった。
ただし、一気に4時間はお客さんの時間が取れないことが多いので、2時間ずつの2部制とした。
前半2時間はアイスブレイクと我々はなぜここにいるのか、エレベーターピッ、後半2時間は俺たちのAチーム、トレードオフスライダー、Pet Peeve、グランドルールの作成。
お客さんと試してみた
反応は上々、チームの士気も高まった。
お客さんからも、「初めてやったけど、モチベーションが上がったしこれからチームとしての一体感が生まれた気がする。正直長いと思っていたが、やってよかった。」という感想をいただけた。 案件開始後にも「あの時キックオフに時間をかけたおかげで、今までのプロジェクトにないくらい良いスタートダッシュが切れたと思う。」とも言っていただけた。
チーム内からも、「はじめはチームがぎこちないことも多いが、このプロジェクトはそういうことがない。」「自分のプロジェクトに愛着が持てる気がする」などのフィードバックをもらった。
4時間でも時間は足りなかったけれど。
結論
やってよかった。
時間はかかるけど、初めにやっておくことでチームとしてのスタート地点に立ち、スタートダッシュする準備ができるというのはよい効果だと思う。
気になっている方がいたら、ぜひ一度やってみてください。
個人的には時間があったらパッケージデザインも是非やってほしい。 プロダクトやプロジェクト自体を絵として可視化することで見えてくるものって結構多い。 時間はかかりがちだけど、文字だけでの認識合わせより絵や図を使った認識合わせの方が認識があいやすいのと同じで、パッケージデザインにすると文字や言葉だけじゃ伝わらないことまで伝わりやすかったり新しい気づきを得やすくておすすめです！
以上、久しぶりの更新でした。
インセプションデッキ、やってる人も多いと思うから今更感はありますが、そんなことは気にしないｗ
プロダクトマネジメントを読んで
いいプロダクトを作ってビジネスとして成功させるには？を考えらせられる本
「プロダクトマネジメント」を読んで思ったことをつらつら書いていきます。
読んだのはこの本↓
プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける | Melissa Perri, 吉羽 龍太郎 |本 | 通販 | Amazon
ユーザ企業あるあるっぽいものが詰まってました。
(私はユーザ企業に勤めたことはないですが、仕事で関わっていたユーザ企業さんや、ユーザ企業に勤める友人からよく聞いたような話がいっぱいでした)
エンジニアも、企画も、運用も、総務も、管理職も、とにかく全員読んでおくと会社の価値が上がりそうな気がしました。
特に以下の考え方が浸透することが大事だと感じます。
- プロダクト自体に価値はない。プロダクトは価値を届けるためのツールである。
- 会社は価値や成果の定義を明確にして共有することで、社員は方向性がわかり、働きやすくなる。成果の定義が定量的であれば、評価もしやすくなる。
- ユーザ目線になるというのは、一生懸命会社の中で考えて妄想するのではなく、ユーザ本人の意見を確認したり、自分で実際に体験してみるということ。
- ユーザに確認しても、ユーザ自信が本当に欲しいものを明確にわかっていることは稀なので、最小限のコストで実験し、本当に必要なもの、欲しいものは何か？を知っていく。そうすることで成功の道筋を立てることができる。
- 小さくたくさん失敗し、失敗から学ぶことが大事。安心して失敗できる文化をつくれ。
- 経営層を説得するときは、実験の結果であるファクトを持っていけ。
以下は、読んで自分が思ったことをまとめました。
プロダクト自体に価値はない
プロダクトやサービスに価値はありません。
価値があるのは、顧客やユーザーにとって意味のあること、つまり問題を解決したり要望やニーズを叶えたりすることです。
プロダクトやサービス自体に価値があるわけではなく、それを使って得たユーザ体験に価値がある。
プロダクトとは、価値を運ぶものです。
プロダクトありきではなく、ユーザに提供できる価値ありきで考えないと、自己満足になりがちです。
ユーザが体験に直結しない技術やデザインに凝りすぎてしまったり、他との差別化と言いながら求められていない機能を追加してしまったり。
もちろん技術もデザインも、他との差別化も大事ですが、どうユーザが嬉しいの？を意識してやる、やらないの選択をしないとビルドトラップにハマります。
アウトプットで評価しない。アウトカムで評価する。
アウトプットで評価しない。アウトカムで評価する。
どれだけ生産できたではなく、どれだけ顧客の価値を生み出せたかで評価する。
アウトプットは評価しやすいです。でも、たくさん生産できたからって、たくさんの成果に繋がるわけではありません。
たくさんの人に喜んでもらい、必要としてもらい、それによって得た成果で評価するべきです。
そのためには、何に価値をおくのか、どんな成果を求めているのかを会社として、チームとして定義し、合意し、それに沿ってどれだけ実現できたのかを評価をする必要があります。
成果、価値の定義を明確にして、会社として共有することはとても大事です。
これがないと、みんなが向かっている方向がバラバラになって、力が分散されて発揮できません。最悪の場合、意図しない足の引っ張り合いになります。
これがちゃんと定義されていなくて、暗黙知になっている会社やチームが多いように感じます。
今、自分のいる会社、チームもそうです。
当然わかるでしょ？くらいの空気。分かんないから。
しかもその評価、誰かのお気持ち次第のやつじゃん、みたいなのも見受けられるとモチベーションも下がりますよね。
ちゃんと定義して、口頭だけじゃなくて、いつでも見返せる形で共有しておいて欲しいところです。
プロダクトマネージャーとプロダクトマネージャーは違う
この本には、プロダクトマネージャーとプロジェクトマネージャーの違いについても書いてありました。
プロジェクトマネージャーは「いつ」に責任を持つ。プロダクトマネージャーは「なぜ」に責任を持つ。
プロダクトマネージャーは自分の意見を実現するのではなく、ユーザに価値を届けることが仕事です。
また、チームメンバーになぜそれが価値なのか、なぜ必要なのかなど方向性がわかる情報は伝えるが、何を作るべきかは伝えません。
プロジェクトマネージャーは期限に責任を持ち、期限までに顧客に最大限の価値を届けることが仕事です。
明確に役割が違いますが、実質兼務している会社も多いように感じます。
役割が違うので、できるだけ人を分けた方が良いと思います。
価値を届けたいプロダクトマネージャーと、期限を守りたいプロジェクトマネージャーでは、守らなければならない優先度が異なるからです。
プロダクトビジョンを作って共有する
Amazonはプレスリリースでプロダクトビジョンを語って共有するそうです。
確かに、プレスリリースをみると、「ユーザはこんなことができるようになって、こう嬉しいです。」みたいなことがわかりやすく整理させれています。
これはみている人全てに価値を共有しているということになり、考えているタイミングで何をユーザに届けたいのか？が明確になります。
社員にも会社はユーザにいつまでに何をどう届けたいと思っているのか、が共有できます。
とてもいい方法だと思いました。
まとめ
全体として、「妄想で仕事をするな、必要なのは明確化された価値の定義とファクトである。」「自己満足でプロダクトを作るな。ユーザに価値を届けるためツールであることを忘れるな。」っていうのがわかりやすく纏まっている一冊だったと感じます。ユーザ企業じゃない私が読んでも学ぶところのある良い本でした。
受託であってもプロダクトを作っていくときは、上に書いたようなマインドを持ってやっていきたいです。
インフラ初心者がADサーバとSCCMサーバ作ってVMをドメイン参加させてみたらつまづいた話
はじめに
はじめに、少し自分のことを。
Lita、インフラ初心者。 VPNとか、サブネットとか、聞いたことはあるし、なんとなくはわかるけど、説明しろと言われたらちゃんと説明できない。 そんなレベル。
ということで、これをやる前にこの辺のサイトを読んだり、YouTubeでインフラ系の動画見たりして少し基本的なところを勉強しました。 実際のところどのサイトがいいのかよく分からなかたので、適当に読み漁りました。
ネットワークの基本やVPN関連で何かおすすめ（書籍でもサイトでもドキュメントでもYouTubeでも）があったら教えてもらえると嬉しいです。
IPルーティングのキホン | ネットワークのおべんきょしませんか？
【初心者向け】社内ネットワーク構築の手順と注意すべき5つのポイント｜ICT Digital Column｜【公式】NTTPC
読んだだけ、見ただけでは正直よく分からないので、とりあえず試してみた第一弾がこれです。
なので、大体のエンジニアの人から見たら、多分「こんなことも分からないのかよ」レベルの話しかしてません。（インフラわかるマンが読んでも多分面白くないよ！）
それでもインフラ超初心者にとっては、何かの役に立つかもしれないし、自分の備忘録にもなると思ったので書きます。
インフラできるマンの皆さんは、私が違うこと言ってたら指摘していただけると嬉しいです。
参考にした資料
これを参考にしました。資料自体は古いんですが、仕事で使う予定のSCCMの構築もしたいと思っていたのでこれを選びました。
これを見ながら1ステップずつ、間違えないようにちゃんとやったんですけどね、見事に色々つまづきました。 すごい丁寧な資料なんですよ、これ。絵も多いし。でもたくさんつまづいた。
悲しくなったけど、なんとか成功したのでよかった。ちなみに10時間くらいかかりました。
SCCM 評価ガイド
アーキテクチャが知りたい場合はこちらを参考に http://download.microsoft.com/download/F/0/D/F0D20D4C-B594-4341-924C-55DFF50FED88/SCCM_Architect_EvalGuide_jp.docx
ADサーバを作ってみた
上記の評価ガイドの「4. ドメインの構成」をひとつずつ実行…しようと思ったんですけど、まずはネットワークの構築からやらないといけなかった。 これはガイドに書いてなかったので、別で調べながらやりました。
まずはこのあたりを参考に、AzureでVnetとVMを作成しました。 Vnetは、あとでSCCMサーバを立てるのに同じネットワーク内である必要があったのでここで作っておきます。
Azure Virtual Network | Microsoft Docs
クイック スタート - Azure portal で Windows VM を作成する | Microsoft Docs
VMはどのサイズにしようか迷ったけど、Standard B2sにしました。テストで使うくらいなら、これで十分でした。
あとはひたすら評価ガイドに従って淡々とやっていきます。ドメインコントローラの構築までは、手順通りにやっていけば問題なくできました。
VMをドメイン参加させてみた
次は、SCCMサーバ用にVMを作りました。Vnetははじめに作ったものを使います。
SCCMサーバ用のVMは、それなりのサイズを求められたので、Standard DS12 v2 を選びました。
ドメイン参加させるまでに色々つまづいたので、つまづきポイントを下記に記載しておきます。
つまづいた
ドメイン検索できない問題
評価ガイドの35ページ目あたり、ドメインを指定して参加させるぜ！なフェーズ。
「OK」ボタンを押しても、そんなドメインは見つからない、とエラーが出る。 「DNS解決できません。このPCはこのDNSを参照していますが、あってますか？」って想定してたのと全然違うIPがでてきた。
（エラー画面キャプチャしてないからない）
なんで…？と思って20分くらい試行錯誤した結果、解決策と原因は下記でした。
解決策
これで解決しました。下記のサイトが参考になりました。
Azureの仮想マシンでActive Directoryサーバーを構築する際に気をつける5つのこと | 株式会社オートマティゴ
SCCM用に作ったサーバがドメイン参加できたので、続いてSCCMのインストールやらなんやらをやっていった。
次にSCCMサーバを立てて、別のVMを管理してみたら、またつまづいた
つまづいたところだけ書きます。私は下記2点で2.5時間くらい無駄にしてしまったので、「本当不親切な資料だなぁ…！！！」とプンプンしましたが、多分経験のある人ならさらっとやるんだろうな。
下記以外は、手順通りにやったら問題なくいけた気がします。
インストーラーがどれか分からない。は？マウント？EXEしかないんだが。
評価ガイドの41ページ目あたりに「SCCM のインストールメディアを使用して拡張」って書いてあるんだけど、SCCMの評価版インストーラーにはEXEの選択肢しかなく、マウントできそうなものが見当たらない。
え、どれなの？と探し回ったけど、マウントできそうなものはない。 しかも2016だと種類いっぱいあって、どれがなんなのか分からない。調べてもよく分からない。
仕方なくEXEをダウンロードし、実行してみる。
まさかのEXEを実行したら展開されるだけオチ！！！
結果としてこれをDLしたらできた。
- SC_Configmgr_SCEP_1606.exe
で、EXEをダウンロードして、VM上で展開、対象ファイルを実行するだけでよかった。
なんてこったい。
ちなみに評価版ソフトウェアはここにあります。
今回は、これのSystem Center 2016（SC_Configmgr_SCEP_1606.exe）を使いました。
Windows ADKのインストールバージョン、どれなの…
Windows ADK では、OS バージョンに合わせて Windows ADK 自体のバージョンが用意されています。また、SCCM でもバージョンに合わせて適切なバージョンの Windows ADK をインストールする必要があります。
めんどい… 最新のADKをインストールしておけば大丈夫、なんて思った私が甘かったです。失敗しました。ちゃんとこれを見て調べてからインストールしましょう。 （Windows10用です）
疲れていても、手を抜かない。基本でした。初心者たるもの、少しの手間を惜しんで調べないと後からえらいハマる。
私はまぁいっか、と思ってしまったやつほどハマる。
Windows 10 のサポート - Configuration Manager | Microsoft Docs
こちらを見ながらインストール対象を選択。足りないものがあると、SCCMのインストール時にエラーが出ます。
最新の評価版を使うときは、ADKとプリインストール環境(PEのアドオン)の両方のインストールが必要っぽいので気をつけてください。
ちなみにSCCMサーバ構築の前提条件がこちら
いっぱいあって萎えた。
サイトの前提条件 - Configuration Manager | Microsoft Docs
Tips
当たり前の話かもしれないですが、ぐぐる時に自分が気をつけていることを書いておきます。
- 検索ツールの期間を「半年以内」もしくは「1年以内」に設定する。
- 技術系の記事は、古い記事を参照してしまうと、今となってはアンチパターンになっているものに当たったり、すでに使えないツールやサービスが出てきたりして非効率になるので、できるだけ新しい記事だけを参照するようにしています。
- できるだけ公式ドキュメントを参照する。日本語版が古そう、もしくは意味わからんかったら英語版を見てみる。
- 特に仕事で調査するときはできるだけ記事の信頼度が高い方が良いので、最終的には公式ページを必ず確認するようにしています。
- 初心者には公式ドキュメントは敷居が高く、個人のブログの方が分かりやすく感じることが多いと思いますが、更新されていないことも多いし、信頼度が低いものも多いので、補佐的に使うくらいにしておいた方がいいと思います。
仕事でエンジニアしている人には当たり前のことだと思うけど、「これから頑張っていくよ！」な人の参考になれば。
転職して1ヶ月弱、フルリモートで勤務してみた
転職から1ヶ月弱たった
転職から1ヶ月弱が経ったので、この1ヶ月に感じたことをまとめてみる。
アウトプットの習慣がないので、少しずつ増やしていきたい。
1週から3週目。オリエンテーションの日々。
初日から在宅勤務というのは初めての体験だった。1週から3週目は、オリエンテーションで会社のこと、勤怠など自社ツールの使い方を教えてもらい、会社で必須とされるスキルの研修などに参加した。
3週間オリエンテーションというと長い気はするが実際は5営業日分で、1週目は1日で終わってゴールデンウィーク、2週目も2日だけ。3週目からがやっと本格始動という感じだった。
1日目。まずは様子見。
1日目から5営業日分はオリエンテーションだったので、朝起きて準備をして、パソコンの前でTeamsを開いて待機した。 5分前くらいからTeamsに入って開始を待つ。
カメラをONにするべきか、OFFのままでいいのか迷う。 ONにしろと言われたらONにしたらいいか…と思い、OFFのまま待つ。できればはじめに指定しておいてほしい。
同期、12人中2人だけカメラがON、あとの人はOFF、講師もOFF。今回はOFFが多数派だったのでOFFのままでいく。 一応襟付きの服に着替えていたけど、次からは基本不要そうだからカジュアルな格好にしようと思う。一応化粧はしておこう。
オリエンテーションの内容は、会社の事務的な手続き方法や、自社ツールの使い方について。 情報量が多すぎてしんどい。 自社ツール、なんでこんなに多いの。勤怠系だけで3つあるのとか地獄。
しかも入力面倒くさい！
何かご事情があるんだろうから仕方ない…。 1日目が終わってみての感想は、同期のキャラが濃すぎるということと、自社ツールがクソすぎてつらいという2点。
パスワードやらなんやらサイトごとに色々登録させられて、サイトごとにパスワードのポリシーも違うから考えるのも大変だった。
そして次の日からゴールデンウィーーーク！
旅行とか行けないからずっと家にいたけど、堕落して過ごす。 初日に聞いたことほぼ忘れる。あかん。やばい。と思いながら、ゴールデンウィークが終わった。
2日目。早くもやらかす。
朝起きて、準備してPCの前へ。電源をONにすると、BitLockerのPINを求められる。
ヤバイ…覚えてねぇ…！！！！！文字列と数字の組み合わせにした気がするけど、なんだっけ？ 焦って思いつく限りのPINを入力してみる。
…。 ぎゃーーーー。ロックされたーーーーー！！！！
終わった…。別の自宅PCから会社にメールをする。 Teamsをインストールし、講師と上司に連絡。 テクニカルサポート部門にPINが分からなくなったのでリカバリーキーをください、と依頼する。
凡ミスすぎて凹む。 忘れると大変だからって、一応メモしてパスワードかけて置いといたのよ、デスクトップに。（おい
BitLockerを有効にしたことがなかった私は、ログイン後に必要なPINだとばかり思っていたのが敗因でした。 知らない仕組みを使うと言われたら、ちゃんと調べよう、という当たり前ことができていなかった、私が全て悪いです、はい。
とりあえず会社の諸々には自前PCからもアクセスできたので、そのままオリエンテーションを受ける。
午後になってテクニカルサポートからリカバリーキーが送られてきた。 無事リカバリーができて、会社のPCにログイン。
会社アカウントのパスワードは覚えていたのでセーフ。
オリエンテーション2日目も会社生活の基本的なところの話と、コンプライアンスとかの研修の説明をしてもらった。 自社の取り組みや、社長のありたがいお話とかを聞いて、ちゃんとした会社だなーとおもった。（月並み
3日目から5日目。チームに分かれて研修。
新しい会社は、出戻りの人がそこそこ多いらしく、今回の自分の同期も12人中5人は出戻り組でした。 出戻り組と初めて組とは研修の内容も違うらしく、ここからは別々の研修を受ける。
会社で求められる必須スキルの研修をさせてもらう。 こうやって体系立てて教えてもらうのは初めてだったので新鮮。
基本いつもやっているような内容だったので、復習と思って聞いていた。 チームでのアクティビティもありつつの内容だったので、あんまり眠くなったりはしなかった。
後から同期から聞いた話、普通にあとでやれって言われてたWeb研修とか他ごとしながら聞いてたって人もいてびびった。 チームでのアクティビティ、ディスカッションでも発言する人少ないなーと思ってたのはそういうことか！！！
在宅勤務のいいところとも言えるし、悪いところとも言える。
オリエンテーションは基本ずっと同じような形式で進められていったけど、先生によって品質が全然違ったように思う。 いい先生の特徴として感じたのは、下記。
- タイムボックスを守る
- 重要なところを重点的に話してくれる
- 否定ばかりでなく、肯定的なフィードバックを必ずくれる
- 指摘の仕方がうまい
逆にこの先生は微妙だなーと感じた点は下記。
- タイムボックスを守らない。お昼の時間に入っても終わらない。
- テキストを読んでいるだけで、どこが大事なのか分からない。話が平坦でつまらない。
- 指摘するのが指導だと思っている感じがした上に、改善方法を示さない。「これが良くないから、こうするといい」、とかではなくて「ここが良くないからやめようね」と言う感じ。
自分ももし教える立場になったら気をつけていこうと思う。
6日目から8日目。ひたすらWeb研修と自社ツールへの情報登録。
案件のアサインがすぐあるよ、と聞いていたが、お客様との契約の問題でプロジェクトが開始できず、開始できるまではお勉強してていいことになった。 ありがたい。
と言うことで、入社後に必須と言われたWeb研修を全部終わらせ、自社ツールへの情報登録とか、会社に空き時間を見つけて今月中にやっておくように言われたタスクたちをひたすら終わらせた。
コンプライアンスをこんなにちゃんと勉強させてもらったのは初めてだったのでとても勉強になったけれど、全部英語なのはちょっと辛かった。
あー、外資系だなー…ってなった。英語がんばろう。
4週目。反省点がありすぎた。
インフラ周りのお勉強をしよう、と言うことでこの週はAzureにVPN構築してローカルPCと繋げるようにしてみたり、VMでADサーバ作って、別で作ったVMをドメイン参加させてみたり、SCCMをインストールしてみたり色々していた。
そこでつまづいた技術的な話は、長くなりそうなのでまた別のところでまとめる。
この週は色々失敗があった。圧倒的に上司とのコミュニケーションがうまくいかなかった。
この上司、私を誘ってくれた人であり、まさか入社後に上司になると思っていなかった友達感覚の相手だった。 考え方やアプローチが真逆なのは知っていたので、入社前に「希望すれば自分の部下で配属もできるよ」と言われていたけど、ちょっと微妙かもなーと思って希望しなかったのに、気付いたら部下になっていた。
ちゃんと仕事は仕事で割り切って部下として接しようとしていたつもりだったけど、タメ口じゃなくて敬語にするとか、なんか形だけになっていた気がする。
失敗の具体的な内容と次のアクションをまとめておく。恥を晒していこうず。 レベルの低い失敗ばかりで自分でやってて落ち込みまくったけど、これが今の実力ということで受け止めてる。
中長期的なビジョンの説明ができなかった
上司との初回の面談の時に、自分がこの会社で将来どうしていきたいのかを聞かれてちゃんと話せなかった。 上司からの会議設定の時にアジェンダがなかったのもあったんだけど、何の準備もなく話をする感じになってしまって、どういう案件がやりたい、どういうのはいやだ、みたいな子供のわがままみたいな発言になってしまった。
何かやりたいことがあって入社したんだから、やりたいことやビジョンはあるよね？って前提での面談だった思うんだけど、うまくまとめれてなかったし正直この会社での中長期的な目標も立てれていなかった。
それでどうしたいの？そういう案件にアサインしてあげてもいいけど、それだと大きな案件を任せづらい人材になっちゃうと思うけどそれでいいの？など指摘されて、ハッとした。指摘してくれる人でよかった。
面談終わった後に反省して、リベンジさせてもらうようにお願いした。 次までには中長期的なキャリアプランを自分で考えて持っていき、レビューしてもらうスタイルにした。
上司承認時、目的や理由の説明をちょっと適当にしてしまった
会社の福利厚生の英会話を受けたいので承認お願いしますっていう内容だったので、そんなにハードルも高くないし「英語のドキュメントや研修を辞書がなくても概要を理解できるようにしたいから」というの理由を書いて申請したら、「この内容では弱くて承認できない、5Wを意識してちゃんと書いて」、と言われてしまった。
上司に「適当でいいよ」と言われていたのを変な風に鵜呑みにしたのが良くなかったし、上司として目的や理由が不明確なものを承認するわけにはいかないと思うので、私が圧倒的に悪かった。
上司として承認する以上、何かあった場合に上司にも責任が問われるわけで。 相手の立場に立って、というのが全然できてなかった。あまり深く考えず、まぁこれくらいでいっか、って思って申請してしまったので、友達感覚が抜けていなかったところがまだあったんだと思う。 慣れるまでは、ちょっと堅苦しいくらいに丁寧にやっていこうと思ったし、下記を実行していく。
- 申請時には、自分がこれで承認を求められて承認できるか？という観点で自己レビューする。
- 5Wが満たされているか？SMARTな提案か？を確認する。
認識齟齬による手戻り発生
今週お勉強内容の説明が甘く、その結果上司がやってほしいと思っていたことと違うことをやって1日くらい潰してしまった。
上司の希望をちゃんと汲み取れなかった上に、ちゃんと認識合わせができていなかったのが原因なんだけど、正直これには上司にも少し良くないところがあったと思っている。当然、自分の良くなかったところが大きいんだけど。
上司は端的に説明し、分からない部分を追加していくタイプ。 分からないところは聞けば教えてくれることもあるんだけど、上司の判断で「それは今知っておかなくても良い。なんで知る必要あるの？」と情報を開示してくれないことも割とある。多分情報を与えすぎて部下を混乱させないようにしているんだと思うけど、それがあるから質問しづらくなっていたりはする。
それに加え、一度言ったら8くらいはわかってほしいと思っていて、私が1言っても2か3も分かっていないのがちょっと理解できないらしく、機嫌が悪いと「普通に考えたらわかるよね？」とか言われてしまったことがあったので正直怖い。 チャットしても返信が遅いことも多く、忙しいのもわかっていたので、自分のことで手間を取らせるのも微妙だなーと思ってしまっていた。
早い話、心理的安全性がないように感じてしまっている。普段はいいけど、仕事の時は怖い。 悪い上司じゃないと思うし、できる人だと思うから、これをどう克服していこうかはもう少しいい方法を考えたい。
それで自分も、ちょっと不安なところがあっても質問せず、全く見当のつかない部分だけに絞って質問するだけになっていた。 その結果、文字列上ではあっていると思われた認識も、数時間かけて実施して、つまづいて1時間くらい調べて、それでも分からなくて質問したタイミングで(この時点で開始から約6時間くらい経ってた)違っていたことが発覚する、という事態がおきた。
つまづいた部分を上司に質問した時、「なぜそれが必要なのか分からん」と言われ、はじめは文字列で説明してたんだけど全然伝わらず。 最終的にやろうとしていることを図にして説明したんだけど、それでも「なんでこうなるのか分からん」と言われた。 でも図にしたことで、上司の言っていることと自分の理解に明らかに差があることは分かったし、これまでのやりとりや事前にもらった資料を見直して、やっと齟齬の原因が分かった。それでなんで上司に「なぜ必要なのかが分からん」と言われたのかも理解できた。
これを経て、やっぱり分からんものは分からんし、上司の普通も新しい会社の普通も私の普通と同じかなんて分からないから質問していくしかないし、めんどくさがられても細かい認識合わせが必要だ、と吹っ切れた。怖いとか知らん。
それに文字列だけではなくて、図にして説明するのも認識合わせ時には有効なことを再認識した。 物理的に同じ場所で仕事している時は、その場にある紙とかホワイトボードとかにちゃらっと絵を書いて説明するって普通にやってたのに、 リモートになったらそれを全然しなくなっていた。
リモートに慣れていないというのもあるけど、パワポとかで絵にするのはチャラっとやるにしても手書きより手間だし時間がかかる気がしてハードルが高くなっていたように思う。
でも手戻りが発生するくらいなら、少しくらい時間がかかっても図にして説明するべきだったし、図にわかりやすくまとめられれば文字列で何回もやりとりするよりも早く相手に伝わると思うので、来週からはやり始める前に図にできるものは簡単な図にして認識合わせしていくことにした。
普段オフィスでチームが一緒に働いている時はできることが、リモートになった途端できなくなるということは普通にあることを認識できたし、 それができないってことはちゃんと習慣になっていなかったか、どういう時に必要、なぜ必要だということを正しく認識できていなかったということなんだと思う。 レベル低い失敗をたくさんしてしまったけど、学びの多い週でした。
来週
来週もお勉強週なので、着手前にやろうとしていることを図にまとめて、上司と認識合わせするところから始めようと思っている。
きっと来週もたくさん失敗をすると思うけど、失敗を無駄にしないようにしていきたい。ただじゃ起き上がらない精神で精進します。
8年弱お世話になった某TRを退職します(退職の理由と今後)
退職の理由と今後
今までの話
「8年弱お世話になった某TRを退職します」というタイトルで、ここまで2記事を書いてきました。
某TRとの出会いの話と、謝辞というポエムは下記にあります。
8年弱お世話になった某TRを退職します - litamemo
8年弱お世話になった某TRを退職します(謝辞) - litamemo
本記事は、その続きで退職の理由を書いていきたいと思います。
退職の理由
転職を決めた理由としては、自動車業界以外の仕事をしてみたいという思いが湧いたのと、自分が他の会社でどれくらいやれるのかを確かめたいと感じたことの2点があります。
他になかった訳ではありませんが、ここでは割愛します！！！(キリッ
ということで、上記2つについて下記に詳しく書いていきます。
気づいちゃった
そもそも飽き性の自分が7年以上も同じ会社で仕事をしてこれたのは奇跡的なんですが、その理由が社風や高い指導が受けられる環境と案件の性質にあったように思います。
某TRは某自動車会社の案件をメインで請け負っていて、その多くの案件は1ヶ月から6ヶ月の期間で受注から納品を終えるような案件でした。 案件によってやることや担当者が違うことと、リリース、納品が終わると一度自分の手からプロダクトが離れることにより、案件ごとに一度自分の中で区切りができてリフレッシュができていました。
あるWebサイトを担当した時、常に改修案件が立て込んでおり、リリースしてはまた次の改修、というのが1年以上繰り返された時期がありました。 大した変化もなく、お客さんもメンバーも変わらず、淡々とこなす。自分にとってそれはあまり楽しくない時期でした。
その後、とある会社に出向し、研究開発系の業務に携わりました。そこでの業務はゴールもなく、手探り状態でずっと同じところで足踏みをしているようなプロジェクトでした。私にはそれがどうしても辛く、初めて仕事にやりがいが持てなくなりました。
ゴールを定義しようとしても上司に阻止され、前に進めようとしても阻止され怒られる、自分で考えろと言ってくる割に、自分で考えて提案すると怒られる(上司の考える正解を部下に考えさせて当てて欲しいだけのやつ)の繰り返しだったので、やりがいが持てないのは当然だったんですが。
そんな出向の日々が1年くらい続いた頃、今までは忙しくしてて気づかなかったことにふと気づいてしまったんです。
私、自動車業界の仕事しかしてないな、って。
何で今更気づいたのかというと、出向先で思うことがありすぎて、「仕事って何なんだろう」「自分がここにいる意味」とかなんか哲学的なことを考えたり、休憩時間に物思いにふけることとかが増えまして。*1
さらにふと気づいちゃったんですね。
ゴールや区切りがない仕事は苦手で、定期的なリフレッシュが自分には必要ということと、他の業界の仕事もやってみたいという気持ちがあることに。
私の中で、ある意味終わり(ゴールやリリースという区切り)があるというのはすごく大事なことだったんだと思います。 それから、定期的に環境ややること(プロダクト)が変わるということも。
自社にいる頃は、それが満たされていたので全然気づかなかったのですが、自分は変化を好む生き物だったんだと。
自分には何ができるんだろう
転職を考えたときに湧いてきたのが、今の自分には何ができるんだろう？という疑問です。
自動車業界のドメイン知識はそれなりにある。お客さんからも上司からも仕事もそれなりに評価してもらえている気がする。
でもドメイン知識がなくても、私は仕事がちゃんとできるんだろうか？ 依頼者を満足させられるだろうか？
わからない。自信もない。でもこのままドメイン知識があるだけで、その界隈から離れると何もできない人になりたくはない。
私は某TRが初めての現場で、他のIT企業を知らないので比較対象もなく、自分がどれくらい他の企業で役に立てそうなのかの判断材料がありませんでした。 さらに、できる系エンジニアに囲まれて仕事をしてきたので、一般の(?)エンジニアと仕事をするというのがよくわからない状態にもなっていました。
某TRに参入する協力会社のエンジニアの方の中には、『え、流石にこのレベルはヤバイ』と私が思うような人もいました。 例えば「エラーメッセージを読まない、読めない」「gitが使えない、使い方が調べれない」「テストを通すためにテストコードをバグに合わせて修正する」「環境依存の値をコードにベタ書きする」「選択肢が常に1つしか提供できない」などです。
でも、それが一般的レベルのエンジニアなのか、一般的なエンジニアよりレベルが低いのか、それすら判断できる材料がない。 圧倒的に経験値も比較対象も足りない…
それで、「よし、転職しよう」と。
転職活動
その後、自社に戻れることになり、退職時期をいつにしようか考えました。 すぐ辞めるのか、もう少し某TRで学べるところを学んで辞めるのか。
正直、自社に戻ってすぐはもう少し様子をみて決めようと思っていました。
ですが、自社に戻ったら尊敬する上司もいないも同然の感じになっていたし、尊敬する先輩方とも事業部が離れることになりました。 事業部ごとにかなり色が違っていて、事業部が変わったら別の会社のような文化が形成されていました。
それは、私が気に入っていた文化とはかなり違うものでした。 ということで、会社に「転職を考えています。転職活動します。」と伝えて転職活動開始。
退職時期は、転職先が決まる前に決めました。 先に決めておかないと、会社に引き止められてずるずるいてしまいそうだったので、それを回避する意味も込めて。
転職活動は、リファラルを使いました。あとは、いろんな会社を比較するためにビズリーチに登録して活動しました。
ビズリーチを使ってみた話はこちらに書いたので良ければ参考にしてください。
リファラルは、「転職考えてるんだよねー」という話を知人にしたら、「うちきたら？」って言ってくれた方や、タイミングよく「今人探してるんだけど、興味ない？」と言ってくれた人が数人いたので話を聞かせてもらった感じです。
リファラルで興味を持って面接までやってもらった会社は2社。 どちらの会社も個性的な人が多そうで、やっていることも面白そうな会社ですごく迷ったんですが、最終的には福利厚生の手厚い方に決めました。
福利厚生とか自分の中にも安定を求める心があったんだなーなど色々新しい発見があって転職活動は楽しかったです。
転職先
転職先は、東京が本社のコンサルもやっている感じのSIerです。外資系です。最近多いですよね、外資系。
入社手続きの書類ですが、専用のWebサイトからDLして印刷して、記載してスキャンしてアップロードするようなやつがあって萎えたり、大学の卒業証明書とか健康診断書とか揃えないといけない書類たくさんあって「うえぇ(涙目)」ってなったりしましたが、何とか今揃えられる書類は全部提出できました。
正直めんどくさすぎたのと専用Webサイトの仕様があれすぎたのとで、本当にこの会社で良かったんだろうか…とか思ってしまったりもしたけど、紹介してくれた知人に「うちの人事、ちょっといけてないんだよね。ごめんね。」って言われたので開発はまともだと信じて頑張って終わらせました。
人事、大事やぞ？
5月から東京に引っ越す予定をしていましたが、新型コロナの影響で引っ越しは延期となりました。 入社初日から在宅勤務は初めての経験なので、どんな感じなのかが読めずに漠然とした不安もありますが、せっかくなので落ち込むよりも楽しみたいと思います。
5月から何をやるのか
まだ何も決まっていません。はじめの一週間は研修。決まっているのはそれだけです。 研修後に、相談しながらアサイン案件を決めていくと聞いています。
ただ、サインの条件に「自動車業界以外の仕事をさせてもらえること」というのを入れたので、自動車業界以外のお仕事をさせてもらえる…はずです。 もし自動車業界の仕事のアサイン要望があっても、拒否権があると聞いているのでとりあえず信じています。
自動車業界が嫌というわけではなく、せっかく自動車業界以外の仕事がしたくて転職したのに、多少知識があるからって自動車業界の仕事ばかりにアサインされたら意味がないので、断固として拒否します。もし強制されたら、すぐにでも辞める所存。約束違いますし。
やってみたいこと
できればコンサルの案件をやってみたい、と要望を出しています。
やったことがないので、どんな感じか挑戦してみたいというのと、正直今まで仕事で出会ってきたコンサルの方々にあまりいいイメージがなかったので、実際に自分がやってみたり、他のコンサルの人のお仕事をみさせてもらうことで、何か変わる部分や見えてくるものがあるのかを確かめたかったからです。
今後どうなっていくのかまだまだ全然分かりませんが、やったことがないことに挑戦したり、初めましての開発メンバーと一緒に仕事させてもらったりして、経験値を増やしていきたいと思います。
不安もありますが、楽しみもあるので、苦労も含めてできるだけ楽しんでやっていこうと思います！
*1:一応言っておきますが、出向業務は辛いことも圧倒的に多かったですが、反面教師には最高な先生との出会いや、某TR以外のITベンダーの方々との貴重な出会いがあったので最終的には行って良かったと思っています。学びはたくさんありました。
8年弱お世話になった某TRを退職します(謝辞)
謝辞
某TRでは、本当にいろんな人にお世話になりました。業界未経験で何もわからなかった私が、今ITの人として仕事していられるのは某TRでご指導下さった方々のお陰です。
こんな豪華なエンジニアと一緒に仕事ができたのはとても幸運だったと思います。 本当に上司、先輩、同僚共に恵まれました。ありがとうございました。
某TRの人たち
某TRは、キャラが濃い人が多いです。みんなどっかぶっ飛んでるというか、尖っているというか。 でもそんなところが私には面白くてちょうど良かったし、某TRにも某TRのみなさんにも愛着がありました。
(過去形になってるけど今も一応ありますよ！
ということで退職済みの方も含めて、下記にお世話になった方、影響を受けた方へのお礼を書いていきます。 一応名前は伏せて書きますが、ほぼ出ちゃってるかもしれない人もいるので嫌な方がいたら、お手数ですがご一報ください。
注）今回もポエムです。
上司の皆様へのお礼
私はきっと扱いやすい部下ではなかったと思いますが、皆様嫌な顔せずにご指導くださる良い上司でした。
役員のKさん
私を面接し、採用してくれた上司です。 仕事の仕方や考え方にとても影響を受けた一人です。
Kさんに感謝したいのは、まず未経験の私を採用し、見守りながら育ててくれたことです。 Kさんは基本誰かの意見を否定する事はせず、肯定しながら正しい方向に導いてくれるのが上手な方でした。
また、エンジニアにとって仕事がしやすい環境を考え、実際の所属エンジニアの声を取り入れながらそれを提供してくれたことも感謝しています。 この方が築き上げてくれた環境がなければ、某TRにこんなに技術力の高いエンジニアが揃っていなかった可能性が高いと思いますし、いいエンジニアがいるから、いいエンジニアが集まる、という良い循環ができたのは、Kさんのお陰だったんだなーと、Kさんがいなくなって痛感しました。
私はKさんが築き上げた某TRが好きでした。ありがとうございました！
マネージャーのSOさん
入社当時から長年お世話になったマネージャーです。私の仕事の仕方のベースは、多分SOさんに大きく影響を受けていると思います。
常に新しい課題を与えてくれて、無茶振りだったかもしれないけれど、自分の今できるよりも2,3歩先のことに挑戦させてくれたこと、とても感謝しています。 私が失敗することを見越して、フォローできる準備をしてくれていたり、いつもちゃんと最後まで面倒を見てくれる良いマネージャーでした。
某TRで失敗から学んで一歩ずつ成長できたのは、SOさんがいつもフォローしてくれていたおかげです。ありがとうございました！
マネージャーのジャニさん
ジャニさんは、私が某社に出向していた頃に某TRに入社し、出向から戻った後の私の直属の上司となった人です。 ジャニさんは優しくて温和で人当たりの良い、今まで某TRにいなかったタイプのマネージャーだった気がします。
トラブルがあったときに、どっしり構えて慌てないところ、見習いたいです。 そのほかにもマネージャー力ってこういうことを言うんだな、というのを近くで見て学ばせてもらいました。
私から垂れ流される愚痴を、文句を言わずに聞いてくれてありがとうございました！
エンジニアの大先輩方へのお礼
皆さん本当に技術力が高くてできるエンジニアの方で、質の高い指導を受けられました。みなさん尊敬する大先輩なので、またいつか一緒にお仕事ができたら嬉しいです。
BLSさん
尊敬する偉大なエンジニアです。技術力がとても高く、物知りで人望もあつい。すごい。
入社当時、「初めての言語、何がいいと思います？」の質問に「OCaml」との回答をいただき、手をつけてみて見事に挫折した事は今となってはいい思い出です。
実装などで困った時は力を貸してくれ、設計についてもたくさんのご指導をいただきました。 説明もいつも分かりやすく、相談事には建設的なアドバイスをくれて本当に感謝しています。
特に、出向中は顧客の立場でBLSさんのチームと仕事をさせていただき、設計についてのたくさんのご指摘、アドバイスをいただいた事はとても勉強になりました。
あの時はせっかく意見やアドバイスをいただいても、出向先のうまく上司を説得できないことが多く、本当に苦労をおかけしてしまいました。 最後に仕事で関わったのがそれだったので、いつかまた一緒に仕事をして成長したなーと思ってもらえるように頑張ってリベンジしたいと勝手に思っています。
ありがとうございました！
KYNさん
尊敬する尖りまくったエンジニアです。技術力がとても高く、様々な方面の知識が豊富。
テストに関する考え方や、スクラムについてはKYNさんに教えていただきました。
はじめはなんちゃってアジャイルからスタートし、一緒のチームで開発をさせてもらう中で、ちゃんとしたスクラムを学ぶことができました。
怖いこともあったけど、答えをくれるのではなく、自分で考えて答えが出せるような回答をくれたり、方法論を教えてくれたりと、本当にたくさんのご指導をいただきました。
いつも圧倒的な知識量で信頼できる回答をくれる先輩で、技術的選定などでも相談させてもらうことも多かったです。 一緒に仕事ができて良かったです。ありがとうございました！
MYZKさん
クールで無口な天才気質エンジニアです。私の中では何をお願いしても安心してお任せできるスーパーエンジニアでした。
MYZKさんはもう某TRを退職していますが、入社して一番はじめに同じチームで仕事をさせてもらい、コーディングについては一番影響を受けたエンジニアだと思います。
入社当時、「DBって計算機もできるんですよ」って言われて、何を言っているのか微塵もわからなくて困惑したのはいい思い出です。
KYZKさんは「命名は大事」「テストは先に書く。テストのないコードの書き直しはリファクタリングとは言わない。」「コミットはこまめに、目的単位でまとめて実施」「誰かのブログではなく、公式ドキュメントを確認する」「エラーメッセージはちゃんと読んで調べる。無視しない。」など、基本的なことをたくさん教えてくれました。
また、MSDNを読んでもわからない、と泣き言を言う私に、「だったらMSDNに書いてあるメソッドごとにテストコード書いてみたらいい」とアドバイスをくれました。これを実際にやってみたのをきっかけに、MSDN恐怖症もなくなりました。
素人の私の面倒臭い質問に、嫌がりながらも分かるまで教えてくれました。本当に感謝しています。 ありがとうございました！
OTFさん
爆速実装エンジニアのOTFさん。技術に関する知識量が豊富で、実装で困った時は他の人が思いつかないような妙案で解決してくれることもありました。
怖い基礎勉強会に「基礎だから初心者でも大丈夫だよ」と半ば騙されて連れて行ってくれた事は良い思い出です。 あれをきっかけに、「基礎」と「基本」は全然違うものなのだ、日本語は難しく奥が深いということを学びました。勉強会の内容はわからないものがほとんとでしたが、こういう話についていけるようになりたい、とモチベーションをあげることができました。
同じチームで仕事させてもらえた期間は短かったですが、自分にはない視点の意見をくれて刺激がありましたしOTFさんと一緒に仕事ができて楽しかったです。 ありがとうございました！
MEDさん
なんかもうよくわからないけどすごいエンジニア。途中で某TRを退職し、起業をされた大先輩です。
同じチームで仕事をさせてもらう事はほとんどありませんでしたが、キレッキレの回答と安定感が印象的な先輩でした。
退職後に一度同じプロジェクトで少し関わらせてもらいましたが、私のありえないくらいふわっとした要望や質問に的確に対応してくれて感動しました。 自分の曖昧さを反省するとともに、MEDさんと仕事をすることで情報の取捨選択の重要性と、本当に必要なものは何かを考えるきっかけを与えていただきました。
ありがとうございました！
DCLQさん
ふわふわ系エンジニア。技術力が高く、大人で物腰が柔らかい印象です。
一緒のチームで仕事をさせてもらった事はほぼないですが、困った時はアドバイスをくれたり、調べ物を一緒にやってくれたりと何回も助けていただきました。 話していて安心感を与えてくれるので、私の中ではすっかり癒し系のイメージがついていますが、技術力の高さが半端ない事は周りのすごいエンジニアたちのお墨付きです。
短い間でしたが、同じ会社で仕事ができて良かったです。ありがとうございました！
KJTさん
お父さん系エンジニア。お父さんって言うと複雑そうな顔をされますが、褒めてます。
某TRには、協力会社の一員として参入していただいていました。入社2年目から3年目くらいの頃によく一緒に仕事をさせてもらって、本当にお世話になりました。 訳わからないことを言って困らせることもあったと思いますが、いつも優しく対応してくれて感謝しています。
KJTさんのコードはC#でも関数型っぽく書かれることが多い印象で(式が多い)、はじめは読むのに苦労しましたが色々教えていただいて少しは理解できるようになりました。
ありがとうございました！
同僚の皆さんへのお礼
ほぼ全員がエンジニアとしては私よりも先輩で圧倒的にできるマンです。この方々のおかげで仕事中も息抜きしながらわちゃわちゃ仕事ができました。
COくん
やくざ系できるエンジニア。口は悪いけど面倒見のいい、良い人です。
仕事も確実にこなしてくれるので安心感がありました。バイクも乗せてくれてありがとうw
困った時は案件が違っても助けてくれたこと感謝しています。 ありがとうございました！
NNさん
言わずと知れたNNさん。ピアノも上手、仕事もできる。
よくない事は、ちゃんとよくないって言ってくれてありがとう。 サイトの案件では本当にお世話になりました。私がありえない凡ミスをしてバグを埋め込んでいたのも気付いてくれてありがとう。
NNさんには色々感謝しています。関東に引っ越したらライブ行きますねー。
TNさん
こちらも言わずと知れたTNさん。ツイッタのすごい人。(雑)
本のレビュー、やらせてくれてありがとうございました！ それから例の案件も付き合ってくれてありがとう！
感謝感謝です。あとツイッタの使い方、TNさんとNNさんを参考に勉強させてもらいましたw そっちもありがとう！
ZKYさん
ZKYさんは真面目で堅実なエンジニアなイメージ。
いくつかの案件を一緒にやらせてもらいましたが、一緒に悩みながら楽しく仕事をさせてもらえました。 ゲーミフィケーションを取り入れてやった案件が印象的でした。
あの案件がなんだかんだで楽しくできたのはZKYさんのおかげです。ありがとうございました！
RYKさん
イケメンパパエンジニア。金髪まだですか？w
RYKさんとは案件で絡む事は少なかったですが、パントリーでの雑談付き合ってくれてありがとう。
仕事中の息抜き、大事。 また面白い話や愚痴がたまったらご飯行こうw
かえる
かえる系エンジニア。
出向中はかえるさんとお互い愚痴を言い合えたから何とか乗り越えられていた気がします。 あれほど心がすさんで愚痴が多くなり、口が悪かったの人生史上あの時期が一番です。
今はあんなに口悪くないんでw
あの時は本当にありがとうございました！
ANNちゃん
ANNちゃんは事務系のお仕事なので案件で絡むとかはなかったんですが、数少ない女性ということで色々気にかけてもらいました。
ANNちゃんの絵、可愛くて好きです！ 仕事も丁寧で、いつもいろんなことに気を配っていてくれてありがとうございました。
ありがとうございました
こう振り返ってみると、本当にたくさんの人にお世話になって今に至るんだなーと実感します。
某TRに入社して、たくさんの人と関わり、皆さんにご指導いただきながら少しずつできることが増えていきました。 今までありがとうございました！皆様のご指導を無駄にしないよう、これからも精進します！
8年弱お世話になった某TRを退職します
某TRを卒業します
某TRについて
私がいた某TRは、愛知のSIerです。知ってる人は知ってる、チョット怖い会社です。(?)
優秀なエンジニアが複数在籍し、書籍を出している人や講演会で講師をしている人などいろいろいました。 プログラミングや技術選定で困った時は、何を聞いても基本のきから、基礎まで教えてくれる人が揃っていました。
入社当時はそれが普通と思っていましたが、今ではこれがどれだけ恵まれていたかを実感しています。 素晴らしい上司、先輩の揃った職場でしたが、そんな某TRをこの度退職することにしました。
上司、先輩方へのお礼を含めて、入社から退職の経緯までをざっくり書いておこうと思います。 ちょっと長くなりすぎそうなので、複数回に分けて投稿しようと思います。
某TRとの出会い
IT業界に入るきっかけ
「場所を選ばない仕事がしたい。船旅しながらできる仕事がいい。」そんなことを思って選んだのがIT業界でした。
先に言っておきますが、船旅をしながら仕事ができるほどのスキルは身についておらず、目標は未達です。 現実はそんなに甘くなかった。スキルがなければ、自由も手に入れることは難しかった。入社前の私は、そんなことも分かってなかったひよっこでした。
IT業界に入る前は、営業職とテレビ業界でのお仕事をしていたので、入社当時はITに関する知識はゼロでした。 ちなみに大学も外国語学部卒業なのでプログラミングは当たり前のようにやったことはありませんでした。 プログラミングなんて難しいことはできる気もしなかったけどIT業界に入りたくて、何から入ったら興味を持って勉強できそうかを考えた結果、デザインには興味があるという結論に達しました。
まずはやってみようということで、入社前にウェブデザインの学校に3ヶ月通いました。 デザインを考えるのは楽しいし、HTMLとCSSを書くことでWebサイトがそれなりに出来上がっていくのは楽しく、毎日通って3ヶ月程度で卒業しました。
家がない、職もない
未経験だけど雇ってくれるところがあるといいな…なんて思いながら就職先を探そうと思ったら、いろいろあって住民票が浮いてしまっていることに気づきました。
住民票や住所がないと派遣の登録もできなくて、とりあえず家を借りようと思ったんですが、住民票も住所も職もないと家も借りれないことに気付いて絶望。 とりあえず営業時代にお世話になったIT企業の社長に電話して会いに行った。
りた「住所ないし未経験だけどIT業界で働きたい。どこか雇ってくれるところないでしょうか？」
社長「んー。うちくる？」
ということで、就職が決まりました。職があるということで、家を貸してくれる不動産屋が出てきて、家が決まりました。
某TR参入
この会社は在籍エンジニアの派遣をしている感じの会社で、初めて派遣された先が某TRという会社でした。
面接の時、あまりに未経験者っぽさ丸出しだったので受かるかどうか心配だったんですが何故かスルッと受かり、協力会社の一員として某TRに参入しました。
面接してくれた人にあとで聞いた話、「やる気があったから採用することにした」とのことでした。やる気、大事。 これが某TRとの出会いでした。
そこから1年、協力会社として働きつつ、給料の安さに悩んでやっぱり業界を辞めようと思って在籍の会社にも某TRにも「やめます」と伝えたところ、「やめるくらいならうちきたら？」と誘っていただき、入社する運びとなりました。
某TRでやってたこと
ざっくりいうと、「開発に関わる某かは大体一通り経験したよ」みたいな感じです。 実装は苦手です。雑魚エンジニアですみません。
広く浅くという感じで、専門性があまりないところがウィークポイントです。 顧客折衝やいろんなタイプの人と一緒に仕事ができる(比較的誰とでもうまくやれる)のは強いところだと思っています。
身についたスキル
某TRの仕事では、下記のようなスキルが身につきました。
個人的に一番やって良かったのはスクラム開発です。 きょんさんにご指導いただけたことも大きかったと思います。転職先でも最も役に立ちそうなスキルの1つです。
これ以降は日記みたいな感じで印象に残っている思い出を少し書いていきます。
無茶振りばかりされていたらしい入社当初
参入直後にやったのは、今でも忘れないペーパープロトタイピングでのとあるサイトの試作でした。
参入した頃からずっとお世話になったマネージャーは、新しいことが大好きな人で、ペーパープロトタイピングも新しい試みでした。 試行錯誤しながら、何度も書き直しました。 テストをしたり、設計系のドキュメントも書きました。何も分からなかったので、初めは質問ばかりしていました。
質問して、やってみるを繰り返していくうちに、わかることも増えていきました。
後になって聞いた話、当時のマネージャーは無茶振りと思われる仕事の振り方が多く、私も周りから見たら、無茶振りに付き合わされている可哀想な子、と思われていたらしいです。
私は、IT業界に入って初の仕事がこれだったので、そういうもんと思っていて、やれと言われていることは、全て自分にできると思われて仕事を振られているのだからできるはず、って思ってひたすらにやっていただけでした。
苦労もあったけど、このマネージャーの元で仕事させてもらえたことで、自分の実際の能力よりも少し先のことに常にチャレンジさせてもらえたことになり、成長はできたのではないかと思っています。
プログラミングコンプレックス
入社から半年くらい経った時、初めて実装をやらせてもらいました。 家で勉強したりはしていたけど、いざ書いてみるとどうしていいか全然わからなくて、また質問ばかりの日々でした。
大体毎日何かにハマって、数時間無駄にしてしまう。 もっと早く聞けばいいのに、もう少し調べたらわかる気がしてしまって粘る。結局分からなくて聞く。
そんなループでした。
実際、自分が3時間悩んでいたところなんて、先輩に聞いたら30秒で解決するような問題で、本当に時間を無駄にしてしまって毎日自己嫌悪が止まりませんでした。 周りの先輩ができる人たちすぎたこともあり、自分のできなさに本当に嫌気がさしました。
それでも、先輩に教えてもらいながら実装をやっていくうちに、できることも分かることも増えていきました。
エラーメッセージはちゃんと読むことすらできなかった私でしたが、今ではエラーコードを読んで何とか自分で解決できることも増えました。 要件に則って、簡単な改修であれば一人で全部やれるようになりました。
複雑な要件の場合は、今でも誰かの力を借りないと解決できないことは多いし、プログラミングに関してはコンプレックスしかないですが、入社当時よりはかなりできるようになったと思います。うまくできないけど、読みやすいコードを書こうと意識できるようになったのも成長だと思っています。昔は動けば何でもいいくらいに思ってたけど、今ではリーダブルコードに書いてあることの重要性を身をもって体験し、大切さが身に染みています。
これもあとで書きますが、お世話になった先輩方がご指導くださったおかげです。本当に感謝しています。
自分の理想とするポジション
プログラミング以外でも、たくさんの学びがありました。 自分が実装を頑張るよりも、実装以外のところで力を発揮した方がチームとしての効率が良かったこともあり、 ドキュメンテーションや顧客折衝系のお仕事も多くやらせてもらいました。 優秀なエンジニアと仕事させてもらうことが多かったので、優秀な人とどう仕事をしていくのが良いかについては、ひたすら考えさせられました。
自分の中のひとつの結論としては、他人の強いところと自分の弱いところを比較して落ち込むよりも、 自分の強いところを伸ばし、弱いところは助けてもらった方が良いということです。 もちろん、弱いところを補う努力も必要だと思います。
一人一人だとできることは限られますが、チームとなるとできることは増えます。 チームで見た時には、一箇所だけ尖っているよりも、丸に近い方が乗り越えらえれる問題も多いと思うので、自分はチームの中の凹んでいる部分を補える人でありたいなーと思っています。
比較的うまく顧客折衝ができたことと、力のあるエンジニアと一緒に仕事させてもらえたことで、お客様には好評いただくことが多く、いろんなお仕事の引き合いをいただきました。 そのおかげで、出向や業務委託など、いろんな立場でのお仕事をさせていただき、視座を変えることが昔より楽にできるようになりました。
大変なこともたくさんあったし、人知れず泣いたこともあったけど、今思い返せばどれも大変良い経験でした。
謝辞
- お世話になった上司方
- お世話になった先輩方
- お世話になった同僚たち
お世話になった方々には下記のリンクに一言ずつお礼を書かせていただきました。
(関係者以外の人が見ても面白い事はあまりないと思います…。)
8年弱お世話になった某TRを退職します(謝辞) - litamemo
退職の理由と今後
ざっくりいうと、いろいろあったんですw
下記に詳しく書きました。
