インターネット企業ではたらく。

2月を最後にブログの更新が滞っていましたが、
3月下旬に急に部署異動のコンタクトがあり、
4月から新しい部署に異動という、
いろいろバタバタした数カ月でした。

異動先はソーシャルゲームに関わる部署でしたので、
(私はこれまでソーシャルゲームを遊んだことがありませんが、)
急成長している市場の中で、
自分がさらに成長できるチャンスと思い、
異動の話にOKをしました。

前部署では、
エンジニアが自ら新しいものを生み出すための環境作り、
例えばノーエンジニアデーの導入や書籍購入制度の導入など
1つ1つ実現してきましたが、
まだまだやりたいことは多くありました。

新しい部署の組織規模は、
前部署と比較すると10倍以上大きく、
何事も一筋縄ではいかなそうですが、
その分、挑戦のしがいがあります。

現在は、縦軸と横軸の2つの役割を兼務しています。
・あるソーシャルゲームのエンジニアチームのマネージャー
・複数あるソーシャルゲームの開発ラインを横断して関わる仕事

新しい部署で1ヶ月半が過ぎ、課題が見えてきました。
というかすでに山積み。
同じインターネットの仕事ではありますが、
ウェブメディア(前部署)と同じところ、違うところありそうです。
このブログの更新頻度が高くなりそうな予感がします。

私の所属部署では複数のBtoCのメディアを運用していて、
１メディアにつきエンジニア１名が担当しています。
インフラ機器選定やラッキング作業、システム設計・開発、監視等、
そのエンジニアの裁量は多岐にわたります。
エンジニアとしての視野は必然的に広がり、
非常にやりがいのある職場ではないかと感じています。

しかしそれは、場合によっては膨大な運用作業に日々が埋もれてしまい、
いつの間にか働く意義・目的を見失いがちです。
エンジニアは、基本的にはモノづくりが好きな方が多いので、
同じような作業を日々繰り返すような運用作業では
モチベーションが保てないことが多いと感じています。

最近ではスマートフォンが注目されていますが、
情勢の変化が激しいIT業界の中におけるエンジニアの役割として、
新しい市場を見据えた技術の研究開発であったり、
流行技術の調査研究は欠かせませんが、
その時間を確保することは容易ありません。
市場参入への出足が遅れることは、大きな損失へつながると考えていますので、
この課題を解決することは非常に重要と思っています。

それらの状況を打開するために、昨年の秋ごろから、
私の所属部署の中でノーエンジニアデーを試験的にはじめました。
# 今回は、その中間報告的な内容になります。

まずノーエンジニアデーの導入に際し、
エンジニア以外のメンバーに対する配慮は非常に重要です。
これまではいつも自席にいて、緊急時にすぐに相談にいける人が、
週に一度、丸一日いなくなりますので、当然不安を覚えるはずです。
緊急時の連絡手段を必ず用意し安心感を持ってもらう事は重要です。

一方で、エンジニアが、邪魔されないまとまった時間を確保するために、
翌日以降の対応で良いものは、なるべく目にしない仕組みは必要です。
現在は、Redmine の使い方を共有して、皆にチケット登録してもらっていて、
今のところうまくいっています。

【ノーエンジニアデーのルール】
・ノーエンジニアデーは毎週水曜日
・通常通りに出勤する
・会議室や空きスペース等、社内の好きな場所で仕事をする
・緊急時にすぐに連絡がつくように、内線もしくはSkypeは準備する

ノーエンジニアデーと言っても、「自宅やカフェで仕事をする」のではなく、
通常通り出勤し「社内の好きな場所で仕事をする」というスタイルをとっています。
「自宅やカフェで仕事をする」場合は、無駄な出勤時間を有効に使えるなど、
いくつかのメリットはあります。しかし、セキュリティ面の懸念であったり、
「社内の好きな場所で仕事をする」より大幅に上回る成果が期待できない限りは
しばらくは社内ノーエンジニアデーを続けていく予定です。

ノーエンジニアデーを続けていく中で、その成果については、
なるべく部署の皆に発表・共有することを推奨しています。
部署の皆の協力でノーエンジニアデーが成り立っていますので、
その成果については報告すべきだと思います。

とある機能のプロトタイプを開発して、
部署の皆に共有してくれたエンジニアがいました。
「これはあくまでプロトタイプなので、皆さんの担当メディアで、
今後これをどう活用できるかのアイデアをください。」という締めくくり。
エンジニアから発したアイデアが、部署の皆の協力を得て、
最終的により良いサービスがユーザに提供できるという流れは
とても素晴らしく、エンジニア冥利につきるのではと思います。

ノーエンジニアデーを実施する中で感じる課題は、
日々の運用業務をノーエンジニアデーでもやってしまいがちな点です。
基本的に何をしても良い日としていますので、
日々の運用業務を集中的に処理する使いかたはOKですが、
毎週それを続けるのは、本来の目的から逸脱しますので、
何らかの対応は検討したいと思っています。

今後やりたいこと、理想としては、
エンジニアメンバーで一日で１サービス創り上げるぐらいの開発合宿的なことを
定期的に実施して、試験的サービスを矢継ぎ早にリリースしてみたいですね。

最後に、ノーエンジニアデーは、仕事をしやすい仕事環境として捉えるのではなく、
さらにそこから先の、エンジニアが新しい何か生み出す仕組みへと昇華すべく
改善を進めていけたらと思っています。

仕事に満足できない事を悩んだり、
仕事内容ついて満足感を得られない事を悩んだことがあります。

過去を振り返ると、なんとなくやらされ仕事を続けてる時や、
成果を出るまでに時間のかかる仕事、
期待に応えようと努力しているけど、なかなか期待に応えられない時などに、
そう悩む場合が多かったように思います。

悩んでいる時に、同僚や後輩が自分より先に出世していると、
「早く追いつかないと！」という焦りや、
「自分はこのままで良いのか？」という危機感、
「なぜあいつが出世するんだ。」と同僚の出世を認められない…
と思う人もいると思います。

その会社で働き続けたいのであれば、
その現状で良いと思う人はいないのではないでしょうか。

仕事をうまくすすめる、成功させる「やり方」や「考え方」は、
状況により様々ですが、書籍やセミナー、Web を探せば、
自分にあった参考となる情報は見つかるかもしれません。

書籍をよんだり、セミナーに参加して何とかしようと努力して、
最終的に改善できた人は非情に素晴らしいと思います。
どのようにして改善できたのか、必死に聞いて自分の参考にしたいと思いますし、
逆に自分が改善できた時には、
同じように悩んでいる同僚に相談にのってあげたいと思います。

一方で、努力していろいろチャレンジしているけど、
それでもうまく成果に結びつけることができない場合もあります。
私は、情熱が持ててない人、もしくは情熱を仕事に傾けるのが下手な人に
多いように感じました。

情熱はあるよ。でも…という方もいるかもしれませんが、
その場合は、情熱が周囲のメンバーに伝わっていないかもしれないですね。
仕事はチームプレーですから、情熱がメンバーに伝わらなければ、
残念ながら、情熱がないのと変わらない。

「私は情熱がある」と、あえて言う必要はありませんが、
成果が伴わなくても良いので、ミーティングでの発言や作成した資料、
その他様々な行動に「情熱を込めて」仕事をすることが、
満足できず悩んでいる現状を打開する最初の一歩だと思います。

情熱があれば、様々な面で成長速度が加速する
情熱があれば、良い仕事が回ってくる
情熱があれば、良いメンバーが集まってくる
情熱があれば、周りが助けてくれる
…などなど、情熱効果は他にもあるかも。

例えば、良い仕事をして期待に応えようと思い、
作成する資料の質を上げるために、
メンバーや上司に質問したいと思うけど、
でも迷惑をかけては良くないと思い、
結局自分一人で資料を作成してしまう…

この場合、遠慮なく周りのメンバーを巻き込むべきだと思います。
情熱のある人、やる気のある人は、必要なときは皆を巻き込んで仕事をします。
巻き込まれる側は、お互い様だと思いますし、
やる気のある人に対してそこまで嫌な気はしないでしょうね。

たまに情熱とワガママを勘違いする人を見かけますが、それはいけません。
仕事に望む姿勢としては、以前のエントリ「チームと信頼について」や
謙虚かつ情熱が大事だと思います。

どのように情熱を傾けたらいいの？という場合は、
中長期的な自分の目標と、仕事で自分に期待されている役割について
ぜひ上司を巻き込んで整理してみると良いと思います。
情熱を傾けられる仕事に一歩近づくかもしれません。

久しぶりにまとまった休暇をとり、
久しぶりに実家に帰省しました。
これからまたしばらく忙しくなるので、
それに備えて鋭気を養うことが出来ました。

その帰省中に父と雑談をする中で、
自分のこれまでの体験と非常に共感した話がありました。
今回はその内容に触れたいと思います。

父は、現在は転職して造園業を営んでいますが、
前職では、建設会社の創業メンバーとして
休日返上で20年以上働いていました。
現在はその職を離れて10年ほど経っていますが、
帰省中に、その前職の会社が今年倒産したという話を耳にしました。

前職の父は、創業当時は、ただひたすら、がむしゃらに働いていたと言っていました。

その創業期の様子を私なりに想像すると…
・何もないゼロからのスタートで、
・創業メンバーの志は皆同じで、
・同じゴールを目指して取り組んでいて、
・その中で様々な衝突がありつつも、
・お互いの貢献を尊重し合い、
・調和や信頼が生まれていて、
・少ない人数でありながらも、
・それぞれのメンバーが自分の役割・責任範囲を超えて
取り組んでいたんだろうと思います。

父が退職するまでの20年間で、
社員は入れ替わりを繰り返しながら創業メンバーは徐々に退職していき、
創業期から残ったメンバーは社長と父の二人となったそうです。
社長は、創業時から苦労を共にした父を大切に考えていたらしく、
父を成長させようと勤務時間後に様々なことを叩きこんでいたと聞きました。

当時の父も、それに応えようと頑張っていたといいますが、
先日の倒産の話をしたときにこう言っていました。

# 創業メンバーを大切にするのもいいかもしれないが、会社の成長の妨げとなってはいけない。
# 成長性のある社員もいたが、社長は私とそりが合わない人はすべて辞めさせてきた。
# その人達がいま要職に就いていれば倒産はなかったのかもしれない。

これを聞いて、(初代)経営者の難しさの一端を感じた気がしました。

創業当時から苦楽を共にしてきたメンバーであればなおさら、
人生と共に長く働き続けていきたいですし、
事業の成功を分かち合うことは最上の喜びだと思います。
それは創業メンバーでなければできないことだと思いますので、
(私は経営者の経験はありませんが)
創業メンバーを失うことは、これらを失うことなんじゃないかと想像すると、
相当の決断がいるのではないかと思います。

父の話は人事面の話でしたが、おそらく何事においても経営者という役割は、
決断する度胸、またそれを判断するタイミングが、
会社の成功や失敗につながる重要な事なんだと感じました。

そして、非情になれるかどうかが、実は一番重要なんじゃないか、ということを感じた休暇でした。

社会で働く場合、チームで働くことがほとんどです。
チームとは、ある共通の目標や目的に向かって、
メンバーそれぞれが役割を担当し遂行する人の集まりです。
「チーム」の定義はこのようにシンプルですが、社会の中で経験するチームは、
同じものが二つとないように思います。

ある目標に向かって皆が一丸となって取り組み、最終的に目標を達成してその喜びや感動を分かち合う…このようなチームはとてもすばらしいと思います。
その一方で、うまくいっていないチームは仕事中の不満が多く、よい方向に軌道修正されないことが多いように思います。
この世に同じものが二つとないチームなので、理由や対応方法はは千差万別だと思います。
今回は手始めに「信頼」をテーマにチームワークの話を書き綴ってみようと思います。

よく見かける質問：「チームワークで一番大事なことは何ですか？」。
一番多い回答が「信頼」だと思います。
ところが仕事上の信頼を得るのは簡単ではないですよね。
初めてあったメンバーから、ただ単に「俺を信頼しろ」といわれても信頼できないと思います。

「あの人に任せれば確実に進めてくれる」
「あの人に相談したら解決方法を知っていそうだ」
「あの人だったらなんとかしてくれる」
このような評価を得る人は、必ずその分野やその役割について信頼に足る成果を出している人であったり、成果に至らなくても信頼に足る姿勢が見え、それが認められた人かもしれません。

逆のことを言うと、その分野や役割について成果を出せてない人や、
その分野や役割への取り組む姿勢が見えない人は、信頼が増す事はないでしょう。

信頼される人には必ず理由があります。

たとえトップダウン的に無理難題な仕事を押し付ける上司でさえ、
成果を出せば評価されることもあり、ある部分では信頼されることはあるかもしれません。
その場合は、メンバーは最初は不満に思いつつも、一応仕事なので頑張りますが、
いつかはその上司から離れていき、チームの崩壊を招きます。
そのようなチームで継続的な成果は生むのは困難です。

継続的な成果を生むチームとはどのようなチームでしょうか。
チームメンバーがそれぞれ機能的に役割を果たし、期待以上の相乗効果を生むチームかもしれません。

機能的に役割を果たすための、最初の一歩は「コミュニケーション」と「合意」が重要かも知れません。
コミュニケーションと合意をメンバーの皆と着実に進め、
このチームの中での自分の役割を、自分だけでなくチームメンバーに合意してもらうことが、
まず最初に重要だと思います。

自分の役割をチームの皆に合意した後は、役割を果たせるように尽力するわけですが、
順調に最後までいくことは、経験上ほとんどありません。
順調にいかないときこそ、コミュニケーションと合意が重要になってきます。
これを怠ってしまうと、信頼を得ることは難しいかもしれません。
解決策を考えたり相談したりしながら落としどころを探り、
最終的にはメンバーで合意をとることが重要です。
勝手に物事を進めることは信頼を失うどころか、今後チームに受け入れてくれない場合があります。

このようにして、コミュニケーションと合意を怠ることなく役割を果たす努力を続けていくことは、
共に働きやすいメンバーだという認識をもたれやすいと思いますし、
最終的に信頼を得る一つの方法なのかもしれません。

初めまして。松尾隆司と申します。
本日からオルタナティブブログに参加します。
よろしくお願いいたします。

私は、BtoCの自社メディア(メルマガ配信スタンド、ポイントサイト)のシステム担当を約3年、Q&Aサービスの立ち上げとその戦略・サービス企画・システム開発・システム運用などの経験を約４年間、現在はアライアンス事業を展開する事業部のエンジニアやデザイナー集団のリーダーを勤めています。

主な仕事内容としては、新規事業のスタートアップに関するシステム全般のマネジメントや、エンジニア･デザイナーのマネジメント、新規事業立案を担っております。

本ブログでは、これらの仕事を通じて思う事や日々の活動ついて綴りたいと思います。
皆さんのご感想やご意見をお待ちしております。

どうぞよろしくお願いいたします。