Beyond The Limit

はじまりは2001年

守破離

2018年に入り、ちょこっとだけ昇進しました。
所属部署のチームリーダーとなり、自分含めて4人チームのマネージメントをしています。
実際のところは、部署には部長がいて、その中に兼務という形でチームが存在しているので、部署における本来の自分の仕事・チームリーダーの仕事・チームの仕事といくつかを同時にこなしているわけです。 こういった事情もあり、かなり忙しいのだけど、とても楽しくやり甲斐を持って働いています。

そんな私ですが、昨年から今年にかけてこんなことをやってみました。

昨年:(自分は違う部だったけど)部の朝会を持ち込んだ

朝会自体はそれまで開発部門と運用部門でしていたのですが、それが終わった後に運用部門だけでするようにしました。
スプリントとかの概念がないのですが、勝手にデイリースクラムと呼んでます。(改めてちゃんと勉強しないといけない) 元々忙しい部署だったのですが、忙しいからこそ共通認識を持って仕事していくことが重要と考えて、始めた次第です。

今年:部の朝会を強化した

チームリーダーになったこともあり、それまでの朝会を強化しました。
主な強化ポイントとしては、

  • ニコニコカレンダーの導入
    • 朝の忙しさバロメーターという形でシールを貼るようにした
  • ホワイトボードの導入
    • その日やることを簡単にホワイトボードへ書くようにした
  • 少しだけ念入りに共有するようにした
    • 昨年よりも少しだけ朝の共有内容を濃くするようにした

まだ導入して3週間も経っていないですが、個人的には「そういった文化がなかった」所で「新しい文化」が生まれて、小さく広まっていけばいいかなと思っています。
特にニコニコカレンダーは端的に忙しさを現せるので、ちょっと会話が生まれて良い雰囲気になってる気がします。

WEBやアプリに残さずに物理ホワイトボードを使った理由は、チーム外からも何やってるのかが見えることにより、他チーム・部署へのヒントになったり、会話が生まれれば良いなと思ったからです。 実際、別部署の人がチラッと見に来たりしてたので、ちょっとは効果があったかな?

今年:目的(やること)が明確なMTGを増やした

メンバーみんなが忙しい状況ではあるのですが、忙しさの整理・忙しさの根本的な改善を目指して、MTGを増やしました。 忙しいのにMTGを増やすというのは逆行しているように思えますが、そのMTGでやることを明確にしておいて、何に困っているのか・何を整理すべきなのかをしっかり話し合う時間を設けるようにしました。 短期的に見たらMTGの時間は増えるものの、長期的な視点で忙しくなくするにはどうすればよいのかを考えるようにしています。 楽をするために時間を割く、そんな認識です。


他にもちょいちょいいろんなことをやり始めていて、まだ結果も出ている状況ではないですが、経過の状況としてはちょっとずつ今までよりも更に上手く回っているかなという個人的な所感です。

やったことがないこと・未知のことを導入してやり始めるには、しっかり計画立てて目的をハッキリ明確にして、そこから何が得られるのか結果を見据えて…というやり方も一つの方法ですが、上記まとめたことは全て気軽に始めたことです。

先ずはやってみて、それが上手くいかないなら原因・理由をしっかり考えて話し合って、改善していけば良いと思っています。 今までの仕事柄、0を1にするよりも1を10にしたりそれを維持したりということが多かったのですが、難しく考えずに先ずやってみることの大切さを最近感じています。

今年に入って増やしたMTGも、仕組みが固まったり、メンバーの習熟度が上がったら発展的に閉会するかもしれませんが、それは「目的を果たしたので大成功!」ですね。

いきなり大きなことをやるのではなく、重たく考えずに気軽に動いて、小さく始めて、徐々に拡げていって、改善を繰り返して、目的を果たしたらクローズする。 まだクローズしたものはありませんが、こんな感じで小さなチームを良い雰囲気でマネージメントしていければなと思います。

今年一年を振り返る

転職して数か月経過しますが、はてな記法の癖が未だに抜けない所があり、MarkDownでちょっとだけ苦労しています。
今年一年を振り返ると、公私ともに色々とあり、せっかくなので忘れないうちに改めて書いておきたいなと思います。

家を買った

春前に家を買いました。
買うとは・買えるとは思っていなかったので、個人的にもびっくりという感じはありますが、一年近く経っても満足度が高い状態が続いているので、買ってよかったなと思っています。
年収ベースで考えると、ちょい頑張ってるぐらいだったのですが、自分にとってはモチベーションアップにつながる面もあるので、総合的に見てもよかったですね。

車を買った

夏前に車を買いました。
都内在住ではないので、車があるとやっぱり便利だし、気分転換にもなります。
事前に社内のSlackで車に詳しい人たちにも相談し、満足のいくものが買えたのも大きかったように思います。

家自体は駅から徒歩圏内、近所に深夜までやってるスーパーやドラッグストア、24時間営業のコンビニもあるのですが、ちょっと出かけたい時などにも使えるし、飲食店は車じゃないと難しかったりもするので車は最高です。

転職活動をした

積極的にいろいろ動きました。
知人から声かけてもらえたのだけど、タイミングが合わずという状況でもあり、今までと同じように自主応募メインでした。
あんま書けない色々なものが見えたこともあり、大変だったけど無駄な時間ではなかったです。

退職をした

2年ほど勤めた会社を辞めました。
自分のやりたいこと・自分のやれること(出来ることではない)・自分のできること・周囲から求められるものとは何か、を考えるいいきっかけになりました。

新しい会社へ入社した

年収も上がり、仕事も楽しく良い転職となりました。
4か月ほど経ちましたが、(限度はあるけど)好き勝手にやらせてもらえて有難いです。
ここで言う好き勝手とは「組織における最適化とは何かを考えて自ら行動し、周囲と協力・関係して動いていく」ということです。
意識高いイメージですが、自分ができることは何でもやる・自分が出来ないけど必要そうなことは相談して進める(提案する)といったことなので、意識高いどころかちょっと泥臭い感じですね。
バリバリ頑張って泥臭いこともやると決めていたので、楽しくやっていけています。
直属の上司が「会社の求めているものと本人のやりたいことが合致しないと不幸」という考え方なのも大きいように思います。

ちょっと昇進した

年内最終日に新年度の話があり、ちょっとだけ昇進しました。
今までは自分で手を動かすことが多かったのですが、今後は自分で手を動かしつつ、それを型化していき、チーム内外に広めてさらなる効率化を図ることもしないといけません。
入社して4か月、プロジェクト管理ツールの導入推進・ドキュメントの標準化なども自分なりに進めてきたのですが、もっともっと頭を使って仕組みを考えていく必要が出てきました。

来年やりたいこと・やってみたいこと

人手が少ない中でサービス・システム支援を回していくにはどうすればよいのか。

チーム

ベタな感じもありますが、

  • 毎朝の短時間での朝会
    • 今年導入したけど、来年も継続していく
  • 週1または2週に1回で30分ぐらいのチーム定例会
    • 初めての取り組みみたいなので、無理ない範囲でやっていく
  • 月1で1on1
  • メンバーの業務理解
    • 大枠では同じ本部だったのですが、部署が違ったこともありそこまで把握していなかったため、まずここからですね。。
  • 自分以上に出来る人を増やす
    • 今年一年手を動かしてばかりでしたが、来年からは一歩引いていかなければいけない

定期的に集まる時間や接点を増やして、コミュニケーションし易くするというのは定番ですが大事なことだと思います。
自分自身が「所属部署のメインプレーヤー兼、同部署内のちょっと毛色の違うチームのチームリーダー」という状況かつ、基本外出ありの人(自分)と基本外出なしのチームという関係なので、過去の経験踏まえて上手いことやっていきたいですね。

個人

今のメインの仕事はカスタマーサクセスを担当しています。
カスタマーサクセスと言っても幅広いのですが、業務自体はそつなくこなせるようになってきたので、

  • 統計の基本を学びたい
  • 顧客業務フローと業界の理解を深めたい
    • ECから趣味のスクールまで幅広く支援をしているので、ある程度範囲を絞って業務知識を深めたい
      • EC/ITは経験あるので、それ以外の所もですね


ちゃんと地に足をつけて、来年もしっかり頑張りたいですね。

はてなを退職しました

昨日付ではてなを退職しました。

この記事を書いてから、2年少しですが、こんな日が来るとは2年前は微塵にも思っていませんでした。 というのが正直な気持ちです。 sharatani.hatenablog.com

2015年6月、まだ上場前のはてなに入社し、職種としてははてなで初めてのセールスエンジニアとして採用され、途中で職種・役割が変わりましたが、2年2ヶ月のはてな生活でした。

改めましてお世話になった皆さん、ありがとうございました。


私が会社としての「はてな」を知ったのはITmediaのこの記事でした。 www.itmedia.co.jp

当時は小さなシステム開発会社で3次請けの立場でSEとして働いており、なんだか凄そうな人が小さな会社に行って大丈夫なんだろうか、そういう時代になるんだろうかと思っていた次第です。

それから10年が経ち、はてなに入社し、2年という短い期間ではありましたが、色々な仕事ができて楽しい2年でした。


次は感情データを分析してマーケティングの支援を行う、Emotion Techという会社で働きます。 肩書きとしてはチーフセールスエンジニアなのですが、実際にはセールス・コンサルティング・導入支援といったビジネス寄りの仕事をします。

はてなと比べてもまだまだ小さな会社ではありますが、その分出来ることも・やることも・チャンスも多い環境です。 Emotion Techを選んだ理由はいくつかあるのですが、その中の一つに「社長の人柄の良さ」というものがありました。 ちょっと心配になるぐらい人が良いのですが、小さい組織だからこそ、社長の人柄って会社を選ぶ中でも大切な要素だなと個人的には考えています。

※前職はてなでも栗栖社長の人柄が物凄く良かったこともあり、はてなへの入社を決めました


もしEmotion Techの仕組み・サービス・採用にご興味がありましたら、ぜひお声がけ下さい。

Dockerメモ5

データ専用コンテナ

  • 名前の通りデータ専用のコンテナでアプリ関係は動かさない

systemd対応のDockerコンテナ

  • CentOS7.xではdocker run実行時に--privilegedオプションを付与する必要がある
  • --privilegedオプションを付与すると、コンテナは管理者権限モードで実行される

Dockerfile

  • イメージファイル
  • FROM行で使用するDockerイメージを指定する
  • MAINTAINER行でメンテナー名などを記述する
  • ENV行で環境変数を指定する
  • RUN行で実行するコマンドを記述する
  • ADDまたはCOPY行でホストOS側のファイルをコンテナ内にコピーする -- ADDは圧縮tarファイルを解凍・展開して元のファイルはコピーされない、COPYは単純に圧縮tarファイルをコピーして解凍・展開は行わない
  • ENTRYPOINT行でコンテナの実行時にコマンドを実行する(実行後はすぐに終了する) -- 終了させたくない場合などはtail -f /dev/nullなどの終了しないコマンドを記述しておく -- CMD行でもコンテナの実行時にコマンドを実行することが可能、ただしENTRYPOINTとは違いが有る
  • EXPOSE行で外部に開放するポート番号を指定する

  • docker buildコマンドを実行する時はDockerfileのあるディレクトリを指定する必要がある -- docker buildのhelpを見るとUsage: docker build [OPTIONS] PATH | URL | -と記述がある -- 直下にDockerfileの名称で置いている場合はdocker build -t test:testdocker --no-cache .こんな感じで末尾のドットが必要 -- こうしてDockerイメージが作られる、イメージの確認はdocker imagesコマンド

  • ホスト側から直接コンテナ内のコマンドを実行するには、docker execコマンドを使用する

Dockerメモ4

ホストOSからコンテナへディレクトリを共有する

  • DockerはホストOSのディレクトリをコンテナ側へ見せることが可能になっている
  • -vオプションを利用して-v <ホスト側ディレクトリ>:<コンテナ側ディレクトリ>とする
  • docker run -v /root/docker-testdir:/root/docdoc -it --name test0x1 centos:centos6.6 /bin/bashこんな感じ、ホスト側の/root/docker-testdirをコンテナ側の/root/docdocディレクトリに割り当てる
  • コンテナ側で/root/docdocの中にファイルを作成すると、ホスト側では/root/docker-testdirの中にコンテナ側で作成したファイルが存在する
  • つまりホスト/コンテナ側から読み書きできる状態になっている

書き込み不可でコンテナへディレクトリを共有する

  • -v <ホスト側ディレクトリ>:<コンテナ側ディレクトリ>:roとする

共有可能なディレクトリの確認

  • docker inspect <container id> | <container image>で表示される
  • こんな感じで出てくる、docker inspectコマンドで色々と情報が取れる
    "Mounts": [
      {
        "Source": "/root/docker-testdir",   #コンテナ側ディレクトリ
        "Destination": "/root/docdoc",      #ホスト側ディレクトリ
        "Mode": "",                         #読み込み専用ならroと表示
        "RW": true,                         #読み書き出来るのでtrueになっている
        "Propagation": "rprivate"
      }

コンテナ間でのディレクトリの共有

  • docker run -v /root/dockertest -itd --name test0x4 centos:centos6.6 /bin/bashこれでコンテナtest0x4の/root/dockertestディレクトリができる
  • docker run --volumes-from test0x4 -it --name test0x5 centos:centos6.6 /bin/bashこれでコンテナtest0x5のroot/dockertestはtest0x4のディレクトリと共有されている -- --volumes-from <container id>オプションが必要 -- --volumes-from:ro <container id>にすると書き込み不可で共有されるが、提供側のコンテナでは読み書きが出来る

Dockerメモ3

Dockerコンポーネント

  • Docker エンジン:Docker本体のこと
  • Docker コンテナ:Dockerエンジンが実行するコンテナのこと
  • Docker クライアント:Dockerデーモンが提供する各種コマンドなどのIFのこと
  • DockerコンテナはホストOS上で複数同時に起動することができる、ホストOSから見ると分離された名前空間として見える

コンテナの起動

  • 例えば"/bin/bash"でコンテナを起動した後のプロンプトで"root@11450a5780f2"等と表示されるが、@の後ろはコンテナID
  • hostnameはコンテナIDが自動的に設定されるが、-hオプションで設定することも可能
  • コンテナをバックグラウンドで稼働させる場合は-dオプションを強する
  • 起動のコマンドはdocker start <container id>でOK、起動後はdocker psで確認ができるが、バックグラウンドで動いている

コンテナのイメージ化

  • 作成したコンテナをイメージ化することができる
  • docker commit <container id> <repository name>:<tag name> -- docker commit c7c2983acd46 local:test-run こんな感じ
  • アプリケーションごとにコンテナを作成してイメージ化しておけば、必要な時に必要なものをすぐ実行可能な状態でコンテナの再利用をすることができる
  • docker images --no-truncで本来のイメージID64文字で表示が可能、通常は12文字。イメージIDのみ出力したい場合はdocker images -qでOK

シェル変数にコンテナIDを入れると便利

  • abc=$(docker run -d --name centos-test -i -t centos:centos6.6 /bin/bash)を実行すると、コンテナIDがabcに代入される
  • コンテナIDは長いので便利そう?

コンテナの停止

  • docker stop <container id>でOK

コンテナのアタッチ

  • 一度停止したコンテナはdocker start -i -a <コンテナID>で再接続ができる -- iは標準入力を受け付けるオプション、-aはアタッチ
  • バックグラウンドで動作しているコンテナはそのままdocker attach <container id>でOK

コンテナとコンテナイメージの削除

  • docker rm <container id>でコンテナは削除可能 -- docker ps -a | awk '{print $1}' | xargs docker rmでまとめて一括で消せる -- 起動中のコンテナは削除できないが、-fオプションを付与することで強制的に削除可能
  • docker rmi <Image id>でコンテナは削除可能 -- docker images | awk '{print $3}' | xargs docker rmiでまとめて一括で消せる

コンテナの自動廃棄

  • docker runコマンドに--rmオプションを付与して起動すると、コンテナ停止時に自動的に廃棄される
  • -dオプションとはセットで利用できないので注意

Dockerメモ2

導入について

  • CPU:ハイパーバイザー型の仮想化ソフトウェアはCPUコアあたりのゲストOS数の目安があるが、Dockerの場合はそれがない
  • メモリ:ホストOS分+全コンテナで使用するメモリ容量を考慮して計算する
  • ディスク:Docker領域はユーザーの数やコンテナ数によって使用量が変わるので、OS領域とは別でディスクを確保した方が良い
  • devicemapper関連のパラメーターはDocker運用後には簡単に変更がきかないため、事前に注意が必要

コマンド

  • docker info:Dockerの設定値他の状態を取得できる
  • docker version:ClientとServerのバージョン情報を取得できる