情報共有ができれば、チームは100万倍の力を発揮すると思う

(自分に対するメモ。数ヶ月後とかに読んで、どう思うかな。)

チームにおいて、様々な不満が出るのは、しっかりとした情報の共有がされていないことから発生していることが多いと思う。

同僚がどんな事に挑戦しているのか、何に困っているのか。

すぐ隣の席の同僚も表面的には、分かっていても、実際に一緒に作業していない限り、

  • 今日、明日何をやる予定なのか?
  • 実際、何をやっているのか?
  • 何に困っているのか?
  • 何に興味があるのか?
  • お客さんと話した内容

などは、日報などがない限り、分からないのが真実だと思う。

そんな中で、チームとして力を発揮するのは、どうなんでしょう??

きっと、チームとしての利益は、あまりないと言えざるおえないと思っている。

だから、チームに適切なツール(場)とマインドを提供してあげても、情報共有をするメリットが充分にあると思っている。

まずは、何を共有しても良いという場を作る。

ツールを導入して、良くあるのが、「このツールで何を投稿して、何を投稿しちゃいけないんですか?」といった質問や 声に出さないけど、頭の中で思っていることだと思う。

ツールを導入して勘違いをしてしまうのは、「なんでも投稿していいよ!」と言えば、みんなが投稿してくれると思っていること。 だけど結果は、誰も投稿してくれない寂しい状況になるだけ。。。

だから、導入する目的を理解したホスト役の人が重要だと思っている。

ホスト役の人、自らツールを使ったり、時には、声掛けして、忘れられないようにしながら、ツール自体の社内での地位を高めていく必要があると考えている。

適切な情報共有が進むと、きっと社員間の話合いの中身が変わってきて、結果に結び付く会話になっていくと思う。

それは、ただ単に個人の作業の効率化が出来た!ということではなく、チームとしての高い結果を出せる組織に変わるといった次元の異なる現象じゃないでしょうか。

きっと100万倍の力を出すのも夢じゃないと思っている。

ISUCON4の予選にでやした!

結果からいうと惨敗。

詳しいログは、id:tknzkの記事参照

ISUCON4の予選に出た #isucon - tknzk's tech log

感想

1年前も出たんだけど、家庭の事情で、途中から離脱させてもらったので、フル出場は初めてでした。

まぁ、いろいろ普段の勉強不足というか実力不足をヒシヒシと感じることが出来ました。><

良かったのは、普段触ろうとして触っていなかった、Redisやxbuild 、PHP5.6などの技術に触れられたこと。

あとは、普段とは違う頭を使ったことなど。。。

反省点

  1. またまた家庭の事情で、リモート参戦。これは良くないですね。次回があれば、俺の家に集まってもらうとかのほうがいいのかとか思ったり。
  2. ローカル環境を作る事に凝りすぎた。すぐにやめるべきだった。
  3. ごりごりのインフラエンジニアに参戦してもらうのが良い気がしてます。
  4. ルールブックを事前に目を通していなかった。

などなど。

最後に

運営の関係者の皆様、ありがとうございました!! 楽しく参加させていただきました!

チームのみなさんも、ありがとう!!

エンジニアリングの価値を最大化するには?

特に受託系のエンジニアの仕事を第三者から見ると、「ただ作っているだけ」という風に見られてしまう事があるんですが、これってきっと開発フローに問題があるのかと最近思っています。

アジャイル系の本を読むとその辺りを強く思うんですが、ウォーターフォール開発において、開発者の目標は、「仕様書通り仕上げること」になります。

そうなると、事業じゃなくて仕様書?に対して、コミットすることになるから、「ただ作っているだけ」の近い状態になってしまっている。

だけど、アジャイル系の開発になれば、開発した結果のフィードバックを受けて、どうやって問題を解決していくのかを検討しながら開発することになるので、エンジニアリングのフローの中に、作る以外の価値を生み出す作業が自然と組み込まれる。

だから、エンジニアにエンジニア以外の営業とか別の仕事をやらせて、「ただ作っているだけ」を解消するより、開発フローを見直して、エンジニアリングの価値を最大化する方が、エンジニアはもっと元気になると思うし、組織も大きく成長できると思う。