業務改善のために取り組んだことと沼からの脱出方法について
たまにはジンジニアっぽいことを書いてみようかなと。
2016年の4月に現職に入社したのですが、入社して一番びっくりしたことは、足元の業務が思いっきりカオスだったことでした。
カオスな状況
- Googleドライブの管理がエリアスではなくすべて個人で権限がついており、入社しても必要なデータがすぐに見れない
- というか、部署や業務として必要なデータがフォルダにまとめられておらず、個人で管理されている
- 同じ名前のファイルが複数あり、どれが最新なのかも不明
- そもそも使われていない、あるいは存在すら忘れられているメーリングリストがある
- 現在進行形で使われているメーリングリストに、（過去の経緯から）現在は不要な人が入っている
- 必要な書類がデータで管理されておらず、紙で保管
- その紙も、コピーのコピーのコピー、という状態のままで管理されており、印刷が歪んでいたり変な斑点が入っている状態のものを利用せざるを得ない
- マニュアルやドキュメントが存在せず、何が正しい業務フローなのか不明
- ついでに言うと、ミーティングの議事録も存在していなかったので「言った／言ってない」「聞いていなかった」などなどの状況も発生
- 人事管理システムの運用がうまくなされておらず、システムに入っているデータが本当に正しいのかどうかが分からない
- いろんな書類やらフローやらがアナログのままになっている
ということで、ひとつのファイルを探すだけで丸一日かかるとか、手戻りがあるとか、逐一車輪の再発明をしたりとか、過去の経緯を記憶の彼方から引っ張り出してもらったりとか、そういうことをやらざるを得なかったのでした。
なんでそんなことになっていたのか
これは急激に変化した／成長した会社によくあることだと思うのですが、一般論として。
人事やバックオフィスの業務って、社員数が少なく、ビジネスもまだ大きくないうちは手作業でできちゃうんですよね。
システムを導入するよりはエクセルで管理したほうが、費用面でも工数面でもコストが低いです。
特にバックオフィスは「コスト部門」なので、システム導入にあたってはハードルがある場合も多いかと思います。
小さい会社だと一人で業務を担当していることも多いですし。
そうやって担当者の個人に紐づく形でやってきた業務が、社員数が一気に増えると全部崩壊しちゃいます。
少ない人数のうちは一人ひとりの顔と名前とそれぞれのステイタスが一致していたし、目視でデータを確認しても30-50人分くらいのものであればすぐに目を通せてミスもすぐに発見できたことでしょう。
ところが、人数が増えてくるとバックオフィスの人員を補充したり、システムを導入したりというのが始まります。
会社が急激に変化しているので、そこについていけない人や変化後の会社の状況に合わなかった人は辞めていったりします。
これまでのアナログなやり方では限界がきてしまい、方法を変えていかなければいけません。
そして、秘伝のたれをずーーーーっと温めていた人事担当者が辞めたとき、そしてたれの製造法が正しく伝授されなかったとき、カオスが起きます。
…という一般論なことがまさしく弊社でも起きていたんですね。
長年ずっと担当していた人事の人が退職し、それだけで済んでいたらよかったのですが、その後、短期間の間に担当者が次々と変わっていき、それぞれのやりかたで業務がスクラップビルドされ、短期間なのでそのスクラップビルドも不完全なままで次の人に引き継がれ、その引き継ぎもきちんとされていたわけではなく…。
ということが積み重なって、前述のカオスになっていたようでした。
やったことは、とにかく小さいことの積み重ね
ここまでカオスな状況だと、より成果を上げていくために頭を使うような業務に時間を割くことはできません。
なので、まずは少しでも今のルーティンワークにかかる時間を削減し、頭を使って仕事をする時間を確保するということを考えました。
なんせ、業務に圧迫されて息ができないような状況ですし、それでも新しいタスク（例えば、新しい採用や新しい入社者の対応）があるのでさらに息をするスペースがなくなっていきます。
根本的にフローを見直したり、フローの概念から考え直すことも必要なのだとは認識していましたが、そんな概念的なことを言ってられるような余裕がなかったので…。
具体的にやったこととしては、以下の感じ。
- 同じチームの人にGoogleDriveの基本的な使い方、機能、概念をレクチャーする
- 会議の議事録を残す
- 最初はSlackにPostしていましたが、ドキュメントのシステムを導入したタイミングでシステムに移管しました
- 手元のフォーマットを改善する
- 入力を少なくするようにプルダウンにしたり、部署名などわりと変更があるものについてはマスターデータ化したりなど
- 権限が大丈夫な範囲内で、社内システムの管理者権限をもらう
- ワークフローなど、システムに載せることができそうなものは載せていく
- ルーティンワークや作業について引き継いだ（あるいは説明を受けた）際には自分だけのメモにせず、マニュアルを作成する
- 最初なGoogle Documentでやってたけど、いろいろ編集とかやりにくかったのでドキュメントのシステムを入れました
- メーリングリストを整理できる範囲で整理する
- あまりに膨大すぎて全部は無理だったけど、いらないメーリングリストを20個以上なくしました
- ドキュメントのシステムを導入したタイミングで、手元のルーティンワークをマニュアルにし、業務を可視化（できる範囲で）
- いろいろ検討してみた結果、今のところKibelaというやつを使ってみています
- 元ファイルを見つけ出す
- これが一番時間かかった…
- 今すぐには改善できないことや実はあまり意味のなさそうな改善案については「これをやらない」あるいは「もっと後に先送りする」ということを決める
- 何かをやるだけではなく、やらないことを決めるということもとても大事だと思いました
少しでも前進するための工夫と「沼」について
上記のことは一気にできたわけではなくて、半年くらい（かな？）をかけて徐々にやったことです。
当然のことですが、こういった業務改善だけが仕事というわけにはいきませんでした。なんせ、バックオフィスの人数が余っているような組織ではないので…。
日々のその他のタスクがある中で少しでも前進するために工夫していたことは、
①シリアスにしすぎないこと
②タスクの粒度を小さくすること
③進捗を可視化すること
でした。
シリアスにしすぎないこと
テキストにしてみて改めて思ったのですが、結構ひどい状況ですよね…。
それを「ひどい」「やってられない」「嫌だ」と表現することはできますし、事実として自分自身としてもそう思っていたのですが、ネガティブな言葉を遣いすぎたりすると他責になりがちなのと、より気がめいっていくばかりであまり良い方向に働かないなと思ったのでした。
なので、あのひどい状況のことを総称して「沼」と呼ぶことにして、それを少しずつ改善する／したことを「沼を退治する」とか「沼が浄化された」とか、思ったよりタスクが小さかった／大きかったことを「沼じゃなくて水たまりだった！」とか「水たまりかと思ったら底なし沼だった！」とか、そんな感じのちょっとふざけた言葉で表現していました。
小手先のことかもしれないですし、そういった表現をすること自体が根本解決になるわけではないのですが、なんとなく気持ちが軽くなり、ちょっと楽しげな雰囲気になったように思います。
タスクの粒度を小さくすること
「業務改善をする」といったような大きなテーマを設定した際にやりがちなのが、「そもそも業務改善とは」といったような大きな概念や目標を設定しにいったり、そのためのロードマップやマイルストーンをかっちりひいたり、そういった目標設定やロードマップに時間をかけて実際の改善に取り組むのは壮大な絵が描けてから…といったことかなと思います。
広く「業務改善」というプロジェクトことに取り組む場合、目標設定やロードマップも大事です。プロジェクトなので。
ただ今回の場合は「プロジェクト」という感じよりは「あまりにも苦しすぎて息ができず、このままでは酸欠で死んでしまうので、まずは今よりも息ができるような状況を作り出したい」ということがメインであって、大きな絵を描くのであればそれば息ができるようになってからと思っていました。
なので、大きな絵のタスクを設定するのではなく、大きなタスクは今すぐできるようなタスクにできるだけ小さくして、それを一つ一つなくしていくことを考えました。
こうすることによって、業務の合間のちょっと余裕ができた時間にすこしずつタスクに取り組めるようにもなりました。
進捗を可視化すること
実際に取り組んだことって一つ一つは些細なことなので、今取り組んでいる泥沼がどのくらい改善されたのか分からず、そして少しも前進していないように見えてしまって「この小さな改善に意味はあるのか」とかそういうことを感じてしまうんですよね。
なので、①上記で細分化したタスクはポストイットに書き出す ②それを沼ゾーンに貼る ③タスクをこなしたら、浄化されたゾーンに移動する ということをやっていました。
アナログのカンバンですね。
また、可視化することによって自分以外の人ともチームで改善に取り組むことができるようになりました。
タスクの振り返りについては特に期限を設定して見直しをしていた訳ではないのですが、3ヵ月に1回くらい見直していました。
自分の場合は、その他の業務量との兼ね合いでそのくらいのスパンが最適だったなと思います。
見直しをすると、「あら、意外と前進してるじゃない！」とリアルに見えて、なんだかうれしくなったりできました。
ということで、半年くらい運用したものがこちら。詳しいタスクの内容はお見せできないのですが…。
沼のタスクは似たような感じのテーマやらタスクをグルーピング化したりなどしてました。
少し大きめのテーマ的なタスクもあります。
前よりは息ができるようになったので、今後はもう少し粒度の大きなタスクも取り組めるようになりそうな気がしています。
（また、チームでタスクの洗い出しからやることになると思います。）
やってみてよかったこと
とにかく、気持ちがすっきりします。
また、自分は（人事という職種ではあるのですが）システムを触るとかそういう作業が好きなので、目の前の沼にムカつきながらも実はちょっと楽しくやっている部分もありました。
今回書いた事例は、わりと極端な例だとは思うのですが、バックオフィスとかルーティンワークの現場って、実はどこも似たりよったりな状況なのかなと思ったりするので、何か参考になることとかあればと思います。
話しかけやすい人になれるように気を付けていること＆「ありがとう」のトレーニング
この記事はコミュニケーション Advent Calendar 2016 11日目の記事です。
qiita.com
いきなりですが、私は人間が苦手です。
人間が苦手であるが故に、そしてあろうことか人事という仕事に就いてしまったがためにコミュニケーションでは苦労することも多いです。
そんな自分が気をつけていること、そして日々やっているトレーニングの話をします。
「なぜ話しかけやすい人」であることが重要なのか
人間が苦手であるため、自分から人に話しかけるという行為が苦手です。
仕事の場面では苦手だの何だの言ってられないですが、それでも心理的ハードルは高い。
なので、向こうから話しかけてもらえると仕事でのストレスを軽減することができます。
もっと大きい理由は、バックオフィスの業務だから。
特に人事は、「何か困ったこと」が起きた時に相談がくることが多いです。
人手が足りなくて大変とか、誰々さんが退職・休職するとか、仕事での人間関係で悩んでるとか、家族が増えるから手続きが必要とか、お引越しするとか、ネガティブなこともポジティブなことも含めて「何か」が起きてから話が来ることの方が圧倒的に多い。
だから、本当にコトが起きてから話が来るよりは、何か困りそうな気配がした時に事前に気軽に声かけてくれたら即時で対応することができる可能性が高まるし、対応に時間がかかることだってあるからコトが起きる前に話が来ていればもっと早く対応できたかもしれないのに（できなかったかもしれないけど）ということだってある。
例えば、人を採用するには時間がかかるから、本当に人手不足になってからだと遅いとかそういうこと。
バックオフィスは社員の毎日の生活と密接しているからこそ、何か困った時や困りそうな時に気軽に声をかけることのできる雰囲気を身に纏っておくことは大事だと思うのです。
ということで、気をつけていること
人間って、ちゃんと話を聞いてくれる人に次からも声かけようって思うんだと思う。
まずはそれを気をつけてます。
そして、「聞く」っていうのはテクニックなので、コミュニケーション能力とかあんまり関係ないのかなと。
コミュニケーションは技術でありスキルなので、自分みたいな人でも人事が何とかできてます。
何かしら反応をする
（相手や相談内容によるけど）「お」でもいいし、リアクションでもいいし、話しかけられたらとりあえずレスをします。
今すぐに対応できなかったら「今○○で手が離せないので後ほどお願いします」っていうことを言ったりもします。
何でもいいから、とにかく反応をする。
すぐにできなかった時は「反応遅くなってごめんなさい」って言う。
ちゃんと聞いてるよ、気にかけてるよ、気づいてるよ、ってことが相手に伝わることが大事だと思います。
聞いてくれない人に次から話しかけようって思わないと思うから。（大事なので2回言った）
とにかく相手に言い分を聞く
これは、何か人間関係の悩みだったりそういう場面の時に気をつけてます。
若手社員の話を聞くときとか。
私ももうアラサーですし、社会人経験も人生経験も少々ついてきてしまっているので、ついつい「それはさ〜」って言いそうになっちゃったりするんですけど、グッと堪えます。
相手の目線や立場から見えている風景をまず理解しようとします。
で、全部を聞いてから、「自分はこう思うよ」って言います。
順番、大事。
聞いてくれない人に次から相談しようって思わないから。（大事なので3回目)
奇跡のワード「うーん、それはどうしてそう思うの？」
それでも「え、それ違うのでは…？」って思うことってあります。
そんな時のマジックワード「それはどうして？」っていう言葉があります。
ついつい相手の考えを否定したくなる時、まずは聞いてみます。
言い方によっては詰めてしまうように聞こえてしまうこの言葉、何と「うーん」をつけると柔らかくなるということを発見しました。
もっと柔らかくしたい時はこの言葉の後に「いや、単純に、どうしてかなーって思って」とつけると更に柔らかくなります。
詰めたいのではなくて、相手の考えを教えて欲しいということを伝えようとすることが大事です。
だって、聞いてくれない人に相談しようと思わないから。（大事なので4回目）
「ありがとう」は無料サービス
自分のことを相手に相談するのって、実は勇気がいることです。
そして、「相談したら迷惑かな…」って少なからぬ人が感じていたりするものです。
だから、相談してくれた人には必ず「相談してくれてありがとう」って言います。
お世辞じゃないよ。
だって、先に相談してくれたことで自分の後工程も楽になっているはずだから。
「ありがとう」の瞬発力を鍛える
予定や用事がない限り家の外に出ない人からすると、人間と会話するっていうのはハードル高いと思うんです。
「ありがとう」とか「ごめんなさい」とか、そういうのは無料だって言われて大事だって言われても、人間とできるだけ接しない生活をしているといざという時に口から出てこないもんだと思うんです。
なので、「ありがとう」の瞬発力のためにはトレーニングが必要です。
日常生活でできます。
それは、コンビニとかスーパーとか何かお店で買ってお釣りとかレシートもらう時に「ありがとうございました」って言うんです。
タクシー降りるときとかでもいいです。
ラーメン屋さんで食べて帰るときでもいいです。
知らない人に言葉をかけるのが恥ずかしい？
大丈夫です、お店の人なんてあなたのこと覚えてないから。
覚えていたとしても「ありがとう」は相手にとって嫌な言葉ではないから大丈夫。
ちょっとした場面で日頃から「ありがとう」って使ってください。
いざという時にちゃんと口から出てくるようになりますから。
日頃からやってると、習慣になり、癖になります。
多分、1-2ヶ月もすれば自然と「ありがとう」って言えるようになると思う。
最初のほうにも書きましたが、コミュニケーションは技術でありスキルです。
練習すれば誰でも身に付けることができます。
参考になれば幸いです。
「プログラミングの楽しみ」というお話
先日Facebookでとあるエンジニアの方が「日本中の営業や人事採用担当者に、プログラミングの楽しみ方を教えたい。」という投稿をされていて、そこに色んな方が「ぜひ教えて下さい」というようなコメントを書いていて、興味深いなぁと思って見てました。
最近はあまりプログラミングをしていないけど、自分がプログラミングを始めた時のこととか書いてみようと思います。
ちなみによく人に間違えられるのですが、私は理系出身ではありません。
小学生の頃から算数と理科が苦手で、その苦手をずっと克服できずに文系学部に進学したという、筋金入りの文系人間です。
プログラミングを始めたきっかけ
プログラミングを意識して始めたのは、新卒で入社した人材紹介会社でIT業界向けの営業に配属されたことがきっかけでした。
理由はだいたいこんな感じかな。
お客様の言っていることがよくわからなかった
「Javaの経験3年以上の人を採用したい」という話だったので経験が5年くらいの方をご紹介したら、「この人の使ってるJavaのバージョン、古いんだよね…」とか言われるんですよね。
で、ちょっと経験少ないけど…と思って経験1.5年くらいの人を「難しいかなー」と思いながら紹介したら、「この人はとても良い！言語の経験は少ないけどプロジェクトマネジメントの経験もあるし、何より家でも勉強している」ってなったりとか。
当時は「What????最初に聞いたことと違うじゃないか！！」って思ったものです。
他にもいろいろわからないことがあったのですが、あまりにわからなすぎてどうしようかなと思って、「とりあえずJavaってよく聞くから、Javaをやってみればいいんじゃないか」って思ったのが大きいです。
ちなみに、こうやってJavaを始めてみたのですが意味不明すぎて脱落し、そのあとすぐに「初心者にはPHP良いらしい」というソース不明の情報をもとにPHPを勉強しはじめたのでした。
PHPはとりあえず、本に書いてあった「お問い合わせフォーム」が作れるようになったところで満足して終了しました。
これが、社会人になってから2ヶ月目〜4ヶ月目くらいのことです。
最初は2ヶ月くらいしか続かなかった。
キャリアコンサルタントに職種チェンジになったこと
入社して半年のタイミングで、法人営業から個人側へと異動の辞令が出ることになります。
転職を希望されるお客様に対して、キャリアにあった求人の提案やキャリアプランを一緒に考えるなどするわけなのですが、なんせ当時、社会人歴半年なわけですよ。
自分よりも圧倒的に社会人経験が豊富な人の、しかも仕事やキャリアの相談に乗るなんてナンテコッタ！と強く思いました。
人生経験も浅く、社会人歴ぺーぺーで経験も知識もない自分が相手に対してすべきことは、まずは相手に敬意を払うことなんじゃないかって思ったんですよね。
少なくとも、何も努力しないでいるのは相手に対して非常に失礼なことなのではないかと。
当時はアプリケーションエンジニアの担当部署へ配属だったこともあって、アプリケーションエンジニアがどんな仕事をしているのかを勉強してみようと思って、最初はすぐに脱落してしまったJavaをもう一回やってみたのでした。
今考えたら、他にも勉強すべきこととかあったんじゃないかって思うんですけど、なぜかプログラミングの勉強の方向に行ったわけですね、はい。
ちなみにですが、この時に自分だけではどうしようも勉強できなくて勉強会に行きだしたことがきっかけで、ITエンジニアのコミュニティと関わっていくことになります。
やっていて楽しかったこと
プログラミングの勉強は、実は結構楽しくやっていました。
うまくいかないこともたくさんあったけど、一定の期間（今も少し）続けることができたのは、単純に楽しかったです。
自分で作ったものが動くということ
Hello Worldみたいな些細なものであったとしても、自分が意図した通りにプログラムが動くということが非常に楽しかったです。
初めて画面に「Hello World」が表示された時のあの感動は今でも忘れられません。
どうってことないプログラムだったとしても、それが「自分が意図してつくった」もので「意図した通りに動く」っていうことはとても凄いことだと思うのです。
ほら、人間って思い通りにいかないから…。
自分の成長を感じやすい
営業やキャリアコンサルタントや、そのあと人事として採用担当者になったりするのですが、こういう職種の「自分のスキル」ってすごくわかりにくいと思うのです。
プログラミングを始めた頃は前述の通り社会人なりたての頃だったので「そんな短期間ですぐにスキルアップとかないだろ！」と今なら言えるのですが、当時はそんな風に思えるわけもなく、「同じようなことを3ヶ月もやっているけれども自分は成長しているのか」などなど感じていたのでした。
その点プログラミングは、「前にできなかったことが調べなくてもできるようになった」「以前はエラーが出た時の処理を自力で解決することができなかったけれども、今回はできた」とかみたいに、わかりやすく成長を感じることができました。
ドラクエみたく、自分がレベルアップしていく感覚を得ることができて、勉強を続けるモチベーションになりました。
プログラミングも突き詰めていくといろいろあると思うのですが、趣味の範囲でやる分には自分にとってちょうどよかったのだと思います。
やってよかったこと
やってよかったことはたくさんあります。
仕事に直結したこと
IT業界で人材紹介業やら採用担当者やらやっていて、技術的なことを知っていることに越したことはないと思います。
会社や社員や仕事やらの理解のスピードは明らかに知識がない時よりも早くなったと思います。（※あくまで自分調べ）
エンジニアとも仲良くなりやすい
どんな人でもそうだと思うのですが、自分のことを知っている人や知ろうとしてくれている人には心を開きやすいと思うのです。
あと、共通点が少しでもある方が話しやすかったりしますよね。
ロジカルになった（と思う）
物事、議論、論点、業務などなどを整理するのが得意になった…ように思います。以前よりは。
怠け者になった
普段の業務の中で「めんどくさい」と思う感度が人より高めなんだろうなと思うことが多いです。
バックオフィスの仕事をしていると、紙の作業とかルーティンワークがどうしても多いですが、そういうものに対して「めんどくさいから自動化したい」という気持ちが強いです。
物事を改善する際には、そもそもの問題点や改善ポイントに気付くということが必要だと思うのですが、そういう意味で「これが問題だ」「改善できそうだ」ということを特に意識しなくても気付きやすいのは自分の強みになっていると思います。
（意識できるともっと良いとは思いますが）
PCとお友達になりやすい
クラウドの普及によって場所や端末にとらわれない働き方ができるようになりましたが、リモートワーク等をうまく機能させるためにはツールをうまく使えないとダメなんですよね。
業務に合わせて製品を作るのではなくて、製品に合わせて業務を変えていかないといけないし、製品の特徴をうまく利用することによってもっと楽に仕事ができるようになります。（ここまで、一般論として）
プログラミングを勉強したことによって「この業務はこういう風にやっている」「この製品はこういう風に使うことができる」みたいなことを意識的に理解したりできるようになったと思うし、少なくとも「わからなくて怖いから使えない／使わない」といったことは一切なくなりました。
こんな感じかな。
良かった点の一番大きなことは、自分の人事としてのキャリアの中で差別化ができるようになったことかもしれない。
エンジニアバックボーンから人事になっている人は少なからずいらっしゃいますが、文系職バックボーンからエンジニアと話ができるっていうのは単純に優位性があると思うのです。
「とりあえずやってみてば良いのではないか」というノリでプログラミングを始めているので、今みたいに「ジンジニア」とか自分で名乗って出しゃばるようになるとは当時は全く意図してなかったですが…。
非エンジニアの人でプログラミングを少しでもやってみたいと思う人が増えるといいなぁと思います。
プログラミング、怖くないよ！楽しいよ！！
モバイルファクトリーを退職してHDEに入社しました
人生初の退職エントリーなので、なんか一番それっぽいタイトルをつけてみた。
3月末付けで株式会社モバイルファクトリーを退職して、4月付けで株式会社HDEに入社しました。
モバイルファクトリーの時は、いろいろと仕事上で外部露出することはあったのだけど、メディアに取材されたこともないし、社内の役割としても単なる担当者で特に特筆するような役職がついていた訳でもなかったので「ただのメンバーの退職」だと自分は思ってたのですが、いろんな人にびっくりされたり連絡もらったりで、そんなことに自分はびっくりしていたのでした。
何やってたの？
モバイルファクトリーではジンジニアしてました。はい。
採用全般（全雇用形態、全職種）と、採用ブランディング的なことと、会社サイト運用と、業務の効率化と、なんか外に出る系のこととか、いろいろやってました。
何やってたかって言われても、なんかいっぱいやっていたとしか表現できないw
なんでやめたの？
モバイルファクトリーは皮肉抜きにとても良い環境で、良い人がいて、それなりに裁量がありました。
働き方も超絶ホワイト。おやすみも取りやすいし、無駄に残業することもない。仕事が終わればさっさと帰る。福利厚生も充実している。
どこをつっつかれても大丈夫なくらいクリーンでした。
給与の面ではちょっと不満があった時期もあったけど、上場したことによって大幅に改善されて、今や業界随一のホワイト企業なんじゃないかと思います。
そんな環境でぬくぬくと仕事してたんですけど、満足できなかった、というよりも、かえって焦りとかありました。
バックオフィスとしてはいろいろな経験をすることができて、それはそれで良かったのですが、自分が責任者として何かを決定したり、責任者としての情報にアクセスするようなことができなかった。
自分が責任者じゃないのはすごい楽で、正直なところあまり頭を使って仕事することもほとんどなくなってきて、環境は良いし人もいいしで本当にぬくぬくと仕事してたんですけど、「これで良いのか」というのはずっとあったんですよね。
エンジニアの人が「この会社でしか通用しない技術の持ち主になるんじゃないか」みたいなのと似てるのかな。どうなんだろう。
他にも細かいこととか言い出すときりはないんですけど、それはどこの会社でもあることかなと。
エレベーターが遅いとかオフィスグリコがすぐに売り切れるとかみたいなことから、ミスコミュニケーションとか音楽性の違いみたいなものまで、いろいろありますよね。
人間や自分が完璧ではないのと同じように、会社とか組織とかいうのは完璧ではないと思っているので、それを許容するかどうかは人それぞれにしろ、そういうものだと思っています。
転職活動についてちょこっと
もやもやものがだんだん塊になってきて、それをどうしようかなーと1年くらい悩んでました。
転職するのも手段ではあるのですが、最初から転職って決めるのではなくて、もうちょっと今の環境で何かできるんじゃないかとかも含めて、いろいろ試したりとかもしてました。
その時試した手段のひとつが、外に出しゃばってみるということ（本当はそういうの苦手）だったりします。
1社目が人材紹介会社だったので、その時の友人に相談して、なんか良さげな会社があれば紹介してもらうようにお願いしていました。
お願いしていた友人が退職することになり、別の人に担当が引き継ぎになったのですが、そこでHDEを紹介されて気づいたら話が進んで入社に至りました。
実はHDEについては3年前くらいから知っていて、社長の小椋さんとはSNSでつながっていることもあって何となく近況とかは知っていました。
あと、YAPCでいろいろお世話になっていた牧さんがご入社されていたことも知ってて、なんかよくは知らないけど何となく知ってる…みたいな感じではありました。
自分がコミュニティ活動をしていることもあって、コミュニティとかのつながり経由でいろいろお話はいただいてたんですけど、実際に転職したのはエージェント経由っていう、なんかそんな感じでした。
（だからってどうこうないんですけどね…ｗ）
入社してからのこと
以前から何となく知ってたし、面接でもいろいろ聞いていたので「すごいカオスなんだろうなー」って思って入社したのですが、自分が想定していたよりもさらにカオスでした！！
- 社内インフラがまだ整備されていない（ドキュメント管理ツール、コミュニケーションツールからその他細かいところまで）
- 本当に、日本人以外の人がいっぱいいる！（同じ日に入社した人の半分が日本人以外）
- 「なるほど、これも決まってないのね！」っていうことの連続
前職の時も、なにも整備されてない的なカオスは経験したことはありますが、今のほうがもっとカオスな感じします。
で、これは自分でもちょっと意外な感じだったのですが、カオスなんだけどそれにムカついたりストレス感じたりみたいなことは今のところないです。
前はそういうの嫌いすぎてストレス感じてたのに。
なんでなんだろうって考えたのですが、以前は何か改善提案をしても「これで完璧だから改善とかいらないし、今のままでいい」っていう感じでコミュニケーションがシャットダウンされていたように感じることが多かったのですが、今は「そうなんだよー、カオスなんだよー。で、どうしたらいいと思う？」になるからかなーって思ってます。
正直、それは会社の違いによるものなのか、カオスの程度によるものなのかはまだわからないのですが。
少なくとも、モバイルファクトリーはHDEよりももっといろんなことが整備されていて（それは、上場するには＆会社経営にとって、とても重要で素晴らしいこと）、HDEは本当に何も存在しないので、カオスや問題意識を認識しやすいだろうということはあります。
どんな感じなのかはゆくゆく分かったりするのかな。
ということで
開発環境がなくなったので普通の人事に戻ります！
会社変わっても自分は変わらずなので、とりあえず飲みに行きましょう！
例のあれ
そういえば、今月が誕生日でもあるらしいよ…|дﾟ)
http://www.amazon.co.jp/registry/wishlist/1EVNTOZFBM38B
退職エントリー書くと「で、お前誰？」っていうブコメが来るという噂をきいたのだけど、本当なのかな。
気づいたらコミュニティ駆動でキャリア的なものが形成されていた、というお話
タイトルがポエムっぽいですが、たぶんポエムです。
2016年のPyConでは副座長やることになった
なんとなく参加することになったPyConスタッフ歴ももう4年目。
1社あたりの在籍期間よりも長くなりました。
2013年からスタッフとして参加し、「来年はやめよう」って毎年思いつつ、なんか気づいたら続けてます。
飽き性の自分としてはなかなかすごい。
気づいたらPyConスタッフの中でもベテランになっており、気づいたら今年は事務局チームの副座長をやることになりました。
なんちゅうこっちゃ。えらいこっちゃ。
リーダーとかマネジメントとか避けてきた
こうやって勝手に「ジンジニア」とか名乗ってる人なので説得感ないですが、人前に立ったり目立ったりするのは苦手です。
いつも永遠の二番手でありたい。
マネジメントとかリーダー的なことも苦手で、前に立ってくれる人を影で操ってる人というポジションが好きです。
前に立つのはめんどくさい。
そんなこんなでリーダーとかそういうのを避けてきたのですが、自分もいい感じの年齢になり、自分のキャリアを考えた時にもう少しリーダーシップを発揮する場面というのがあるといいのかなと思うようになりました。
リーダーシップとマネジメントはイコールではないですが、第三者から見た時にわかりやすいような経験って大事かなと。
ただ、いわゆるベンチャーの管理系職種というのはちょっと難しくて、いわゆる「マネージャー」になったとしてもそもそも人数が少なかったりなどして、キャリア（ここでいう文脈だと、転職した時にわかりやすいような、市場で売れる経験と経歴）としては物足りないなーとか、あまりにも同じ部署の人数少なすぎて、名ばかりのマネージャーになるしなーとかあります。
実際、今の会社の部署でも、仮にマネージャーになったとしても実際の業務は変わらないだろうということで、マネジメントコースじゃなくてプロフェッショナルコースを選択したりしてます。
…とかいうようなところで、今年のPyConでは副座長をやるというようなことになったのでした。
振り返るとコミュニティ駆動
そんなこんなで今までのことを振り返ってみると、常にコミュニティ駆動だなーっていうのに気付きました。
1社目（大手人材会社）にいた時からPyConスタッフを始めたのですが、その頃はただただエンジニア的なものに憧れていて、エンジニア的な価値観（というのがいったいどういうものなのか、今となってはよく定義できないですが）に触れていたくて、というか、人材会社の価値観が嫌で嫌で仕方なくて、スタッフ業務にちょっとでも関わっているだけで楽しかったのでした。
余談ですが、2013の頃の自分は、今振り返ると恥ずかしいくらい「そこに参加していること」が目的で役立たずでした。
当時のことを知っている座長のたかのりさんや、一般社団法人の寺田さんによると「まさか翌年も続けるとは思わなかった。まさかずっと続けるとは思わなかった。」とのことです。
単なるミーハーっぽかったんですね、はい。
PyCon APAC 2013が開催されるちょっと前くらいに今の会社に転職して「人材会社の価値観ではない何か」という環境を手にいれることになったのですが、仕事でそういう環境を手にいれる前にコミュニティで手に入れてました。
2014年のPyConでは、一悶着ありつつも「ジョブフェア」という企画を形にすることができたのですが、これも「採用という経験とか知識を活かしながら何か別の形のものをつくりたい」とぼんやり思っていて、カンファレンスという大きな場でそれを形にすることができました。
その後くらいから、仕事の場でも他社を勝手に誘ったりとかして、採用イベントとか、採用目的じゃないなんだかふわっとした会を企画するようになりました。
これもまた、仕事よりもコミュニティでの実現が先だった。
んでもって、今回。
本職の仕事でマネジメントっぽい役割と肩書きを手にいれる前に、コミュニティで先に手にいれることになりました。
不思議なもんだ。
もう少し具体的な何か：コミュニケーション
これまではキャリアっぽい話をしてきましたが、コミュニティ活動で手に入れたもう一つのことがコミュニケーションの取り方だなーと思います。
1社目ではへっぽこ営業をしていたのですが、そんなにちゃんとした営業をしてなかった、もとい、営業に全く興味なかったというのもあって、お客様に対して「許可を取る」「伺う」ようなコミュニケーションしてたんですよね。
これは社内でも同じことで、上司に対して伺ったり、許可を取ったりみたいなことをしていました。
当時は全く気づかなかったけど。
ところが、コミュニティに入ると、そういうコミュニケーションの取り方では物事が前に進まないわけです。
役割として座長とか副座長とかリーダーとかあるけど、会社じゃないので全員フラット。TOPと思ってる人が別にTOPじゃない。伺ったところで誰も許可してくれない。
ワタワタしてると「で、あなたはどうしたいの？何がいいと思うの？」って感じのことが返ってきます。
結構な衝撃でしたし、「んなこと言われたって、何がしたいとかどうしたらいいとかわかんねーよ！！！」っていう逆ギレ状態。
あれだけ「裁量が欲しい」って思っていたのに、いざ裁量がある状態になると今度は「権限で誰かに決めてもらいたい」って思うんですね。人間とは不思議だ。
そんなコミュニケーションの取り方にも慣れ、「こうしたいと思うのだけど意見下さい」とか「これでいいですよね？何か問題あれば教えてください」みたいな感じのことができるようになりました。
できるようになったら今度はそれが普通になって、「で、あなたはどうしたいの？何がいいと思うの？」みたいなことを自分が言うようになりました。
なんということでしょう。
仕事でも、今の会社に入社した頃は確認待ちをしたりでひとつのことを決めるまでに時間がかかったりしていました。
1社目の時みたいに「伺う」まではいかなかったけど、誰かの許可を待ったりとかそういうことはしてたなーと思います。
コミュニティで「自分で決める」ということを経験してからは、「こういうふうにやりますけどいいですよね？ダメだったらあなたがケツ拭いてください。私の失敗をカバーするのがあなたの仕事なので。」って上司に言えるくらい図太くなりました。
…ちょっと図太くなりすぎたか。
そうやって自分で決めるようになったら、仕事のスピードがむっちゃあがりました。
「自分はこうしたいから、あなたはこうやって欲しいのだけど、どうだろうか」とか、相手に要求もするようになりました。
「仕事なんで、結果出してなんぼですよね」と偉そうに言えるようになったし、結果出すためにどうすれば最短なのかを考える余裕ができるようになりました。
…なんか上から目線だな。
仕事のスピードが上がったら残業しなくなったし、一定の時間内で自分のやりたい業務をやる時間を作ることができるようになりました。
…時期によっては足元の業務で忙しいけど。
そんなこんなで副座長の抱負的ななにか
副座長の立候補を座長に送るフォーマットに「やりたいこと」という項目があったのですが、そこに「業務の省エネ化／クオリティはちゃんとやりつつ、もっと楽チンにしたい」って書きました。
事務局の業務はスポンサーやチケット購入者などと細かいいろいろなやりとり（問い合わせ対応とか、「この情報ください」とか「いついつまでにこれやってください」とか）がたくさん発生するのでオペレーションがとても多いです。
参加者管理／スポンサー対応／グッズ発注／受付対応など、わりと色んなことをぐるっと「事務局」としてやってるので、開催後もタスクが細々あったりします。
その辺、自動化とかテンプレ化とかツール導入とかで楽チンにして、もっとPyConでできることとか、メンバーとか自分の実現したいことに取り組む時間を確保できたらいいなーって思います。
なんか、仕事でやってることっぽい。
…これまでコミュニティ駆動だったのに、ここだけは仕事駆動だな。
以上、ポエムでした。
採用にまつわるエトセトラな話をした、というポエムなお話
先週くらいに頼まれたのでゆるふわっとした社内でLTをした。
背景とか経緯とか
ディレクターが集まるミーティングがあって、そこではミーティング参加者やその他の人に発表して欲しい内容をリクエストして発表してもらうという勉強会がある。
私はそのミーティング参加者ではないのだけど、採用についてのリクエストをもらったので話すことになった。
話したこと
ディレクター向けなので、採用に関する細かいノウハウとか話してもあまり意味ないなと思ったのでちょっと抽象的な話にしてみた。
発表資料はこれ
採用にまつわるエトセトラ from Mamiko Tsuda
www.slideshare.net勝手にジンジニアって名乗ってたりとか、PyConのスタッフも4年目だったりとかで、おかげさまで「新しいことにチャレンジしてる人」みたいな感じの褒め言葉をかけてもらえる機会がちょいちょいあったりする。
非常にありがたいと思っている一方で、採用に関して自分固有のこととか特殊なこととかはやってないのでそういった言葉をかけていただくことに恐縮したりしてます。
（新しそうに見えるのは見せ方の問題かなと）
考え方自体はとてもクラシックだし、書いてあることもすごく普通のことすぎてわざわざ発表する意味あったのかしらとか思いながら資料作ってました。
天才な人と普通な自分というポエム
採用とかいろいろやってると、とても幸いなことに社外のいろんな人と会う機会があります。
そして、自分の場合はエンジニアの人にそう感じることが多いのですが、たまーに訳わかんないくらい優秀な人に出会ったりします。
意味わかんないけどなんか天才、っていう人。
そういう人と話してると、自分は到底この人にはかなわないな、って思います。
この人の見えてる風景を想像することすらできない。
また、びっくりするくらい優秀なんだけど、訳がわかる人にはたくさん会います。
エンジニアに限らず、職種も業界も越えて、すごく優秀な人。
そういう人と話してると、本当に基本的なことが当たり前にちゃんとできてるんだな、って思います。
ごめんなさい、ありがとうが言えるとか、床にゴミ落ちてたら拾うとか、たぶんそのくらいのレイヤーのこと。
喋るのが得意不得意とか、そういう次元ではないようなこと。
天才な人と話してると、この人には絶対になれないって強く思います。
でも、優秀な人と話してると、もしかしたらこんなに普通な自分でも、ひとつひとつのことを積み重ねていけばその人に近づけるんじゃないかって錯覚します。
ちょっとやそっとじゃその優秀な人になんてなれないし、自分みたいなぐーたらな性格の人はなかなか難しいというのも頭でわかってるけど、錯覚してるので「ちゃんとやろう。近づけるかもしれない。」って自分に言い聞かせることができます。
錯覚の力ってすごいですね。
でも、普通な自分にはその錯覚を信じるしかないので、とりあえずやってみる訳ですね。
もはやそこまでいくと、錯覚というよりは妄想ですね。
…っていうようなポエマーなことを資料を作ってる時に考えていたのでした。
たまには自分の考えをまとめるのも良いことかもしれない。
その他質問とかもらったこと
発表のあとに質問もらったこととか、その場でコメントあったこととか、補足したいことをを少しだけ書いてみる。
モチベーションの管理は？やっぱりラーメン？
ラーメンに限らず、美味しい食べ物とお酒があると嫌なことを忘れられる性格なので、嫌なことがあると美味しいものを食べて飲みます。
お刺身とビール買って帰って、さっさと寝るとか。
自分の場合、食べることが人生の中心なので、ごはんが美味しくないとテンションが思いっきり下がります。
お昼ご飯がはずれだった日には、午後半休取るくらいの勢いです。
なので、お昼はだいたい同じようなお店に行って、同じようなものを注文します。
新しいお店にチャレンジする日は、やる気なくなっても大丈夫なように、重めの予定が午後に入っていないことを確認してから行きます。
で、優秀なディレクターってどんな人？
ディレクターに限らず、その職種に必要な基本的なことが身についている人かなと思います。
ディレクターの場合はコミュニケーションもとても大事な基礎的スキルなので、ホウレンソウとか挨拶するとか、そういったことかなと。
エンジニアの場合も同様ではあるのですが、コミュニケーションの対象が人間ではなくてコンピューターの方が得意といったケースもある職種ではあると思うので、その辺はディレクターとは根本は同じでも多少違ってくるところがあるかなと思います。
とはいえ、会社でチームで仕事をするので、人間とのコミュニケーションも大事ですが。
つださん、いろいろやりすぎてて何やってる人かわからなかった。
自分もよくわかりませんw
が、これまで仕事でコミュニケーション技術を磨いてきていて、さらにコミュニケーションという技術はいろんなことに汎用性があるものなので、その技術を使って仕事してる人、という感じです。
採用とエンジニアリングと私
はじめに
この日記はモバイルファクトリーアドベントカレンダー23日目の日記です。
昨日は@yashims85さんのReactiveExtensionsでstreamを分割するというお話でした。
当初は@kfly8さんが書く予定だったのですが、雑談の最中に「それ、面白いから記事書いてよ」という話になり、参加することになりました。
今日は、採用担当としていろいろ担当している時に利用している思考フレームワークについてのお話です。
採用においてやっていること
採用活動においては、どのような手法で人を集めてくるのかということをまずは検討します。
その手法について、一般的なサービスの説明は以前に社内LT用にスライドをつくりましたので、そちらをご覧ください。
www.slideshare.net
また、その過程で考えているフレームワークとしては、とても素朴なPDCAです。
そちらも、以前の勉強会で発表したことがありますので、ご覧ください。
採用を支える技術 from Mamiko Tsuda
www.slideshare.net
かけるべきコストとアウトプット
自分自身が普段の業務において行っていることとしては、上記の通り非常に素朴なことです。
最近はダイレクトリクルーティングやらリファラル採用やら、採用関係のバズワード的なものがいろいろあってサービスもいろいろ出ていますが、本質的には新しいことは全くないですし、既存サービスが名称と見せ方を変えただけというものも少なくありません。
エンジニアリングと同様、銀の弾丸はありませんので、地道なことをひたすらやり続けるしか採用に至る道はないと思っています。
また、銀の弾丸はなくても札束の塊でぶん殴るということはできますが、コストに見合うだけのアウトプットが得られるかどうかは見極める必要があります。
これもまた、エンジニアリングと同じですね。
採用活動については、採用という行為そのものが会社としての利益を生み出している訳ではありませんので、そこに予算やコストをかけるべきなのかどうかは慎重に考える必要があります。
これは、採用に限らず管理部門といわれる業務一般的に同じことです。
細かくPDCAを回すことによって、採用にかけるコストは抑えることができます。
実際、モバイルファクトリーの場合は、採用担当は自分ひとり*1ですし、1人あたりの採用にかけている成果報酬や媒体費用*2も一般的な相場の3-5分の1程度です。
これは、お金をかけるべきポイントの見極めを細かくやっていることと、社員からの紹介や勉強会経由で会社のことを知ってくださった方からの応募から採用に至っていることが大きく寄与しています。
細かいPDCAを回すこと
実際に行っている思考フレームワークとしては素朴なものですが、これらを細かいサイクルで回していくということが非常に大事だと思っています。
これは、エンジニアリングでいうとことの「ちゃんとテスト書け」と似たようなことではないかと思います。
例えばですが、面接官として面接に入っている時には、相手の反応に合わせて聞き方は話し方を変えます。
自分が発した質問に対しての反応が自分の想定したようなものでなかった場合、特に自分の意図したことがうまく伝わっていなかった場合に、どうすれば相手が受け取りやすい言葉になるのかをその場でPDCAを回して振り返っています。
また、前回うまくいった採用手法が同じようなケースでうまくいかなかった場合、どうしてなのかを採用活動を行っている過程で考えます。
採用市場は日本経済や競合他社の動向に大きく左右されるので、その場その場での細かい振り返りが大事です。
特に、「P =企画すること、意図すること」を言語化できるレベルで考えておかないと、その方法がうまくいかなくなった場合のリカバリーがききません。
採用がうまくいったケースでも、その要因分析をきちんと言語化できるレベルで振り返っておくことも大切です。
前述の通り、採用市場は水ものなので、もしかすると単純に運が良かっただけなのかもしれないからです。
