情報共有ができれば、チームは１００万倍の力を発揮すると思う
（自分に対するメモ。数ヶ月後とかに読んで、どう思うかな。）
チームにおいて、様々な不満が出るのは、しっかりとした情報の共有がされていないことから発生していることが多いと思う。
同僚がどんな事に挑戦しているのか、何に困っているのか。
すぐ隣の席の同僚も表面的には、分かっていても、実際に一緒に作業していない限り、
- 今日、明日何をやる予定なのか？
- 実際、何をやっているのか？
- 何に困っているのか？
- 何に興味があるのか？
- お客さんと話した内容
などは、日報などがない限り、分からないのが真実だと思う。
そんな中で、チームとして力を発揮するのは、どうなんでしょう？？
きっと、チームとしての利益は、あまりないと言えざるおえないと思っている。
だから、チームに適切なツール（場）とマインドを提供してあげても、情報共有をするメリットが充分にあると思っている。
まずは、何を共有しても良いという場を作る。
ツールを導入して、良くあるのが、「このツールで何を投稿して、何を投稿しちゃいけないんですか？」といった質問や 声に出さないけど、頭の中で思っていることだと思う。
ツールを導入して勘違いをしてしまうのは、「なんでも投稿していいよ！」と言えば、みんなが投稿してくれると思っていること。 だけど結果は、誰も投稿してくれない寂しい状況になるだけ。。。
だから、導入する目的を理解したホスト役の人が重要だと思っている。
ホスト役の人、自らツールを使ったり、時には、声掛けして、忘れられないようにしながら、ツール自体の社内での地位を高めていく必要があると考えている。
適切な情報共有が進むと、きっと社員間の話合いの中身が変わってきて、結果に結び付く会話になっていくと思う。
それは、ただ単に個人の作業の効率化が出来た！ということではなく、チームとしての高い結果を出せる組織に変わるといった次元の異なる現象じゃないでしょうか。
きっと１００万倍の力を出すのも夢じゃないと思っている。
ISUCON4の予選にでやした！
結果からいうと惨敗。
詳しいログは、id:tknzkの記事参照
ISUCON4の予選に出た #isucon - tknzk's tech log
感想
１年前も出たんだけど、家庭の事情で、途中から離脱させてもらったので、フル出場は初めてでした。
まぁ、いろいろ普段の勉強不足というか実力不足をヒシヒシと感じることが出来ました。＞＜
良かったのは、普段触ろうとして触っていなかった、Redisやxbuild 、PHP5.6などの技術に触れられたこと。
あとは、普段とは違う頭を使ったことなど。。。
反省点
- またまた家庭の事情で、リモート参戦。これは良くないですね。次回があれば、俺の家に集まってもらうとかのほうがいいのかとか思ったり。
- ローカル環境を作る事に凝りすぎた。すぐにやめるべきだった。
- ごりごりのインフラエンジニアに参戦してもらうのが良い気がしてます。
- ルールブックを事前に目を通していなかった。
などなど。
最後に
運営の関係者の皆様、ありがとうございました！！ 楽しく参加させていただきました！
チームのみなさんも、ありがとう！！
エンジニアリングの価値を最大化するには？
特に受託系のエンジニアの仕事を第三者から見ると、「ただ作っているだけ」という風に見られてしまう事があるんですが、これってきっと開発フローに問題があるのかと最近思っています。
アジャイル系の本を読むとその辺りを強く思うんですが、ウォーターフォール開発において、開発者の目標は、「仕様書通り仕上げること」になります。
そうなると、事業じゃなくて仕様書？に対して、コミットすることになるから、「ただ作っているだけ」の近い状態になってしまっている。
だけど、アジャイル系の開発になれば、開発した結果のフィードバックを受けて、どうやって問題を解決していくのかを検討しながら開発することになるので、エンジニアリングのフローの中に、作る以外の価値を生み出す作業が自然と組み込まれる。
だから、エンジニアにエンジニア以外の営業とか別の仕事をやらせて、「ただ作っているだけ」を解消するより、開発フローを見直して、エンジニアリングの価値を最大化する方が、エンジニアはもっと元気になると思うし、組織も大きく成長できると思う。
最近の「あとで、読む」の環境設定について
いろいろと、Webサービスもアップデートがあって、自分の「あとで、読む」の設定を見直したので、まとめてみます。
「あとで、読む」は、エンジニアの嗜み？？
自分は、サラリーマンのWebエンジニアで、朝９時から夜まで、会社に出社し業務をこなしています。 業界特有の問題？ですが、とにかく忙しいです。 どうしても、日々仕事だけをこなして過ごしてしまいがちな家業ですが、同時に技術の進歩は、本当に早い！ 自分から追いかける姿勢がないと、気付くと置いてきぼりのエンジニアになってしまい、ゆくゆくはお仕事をもらえない状態になってしまうのかなぁと日々、感じます。
そこで重要になってくるのが、空き時間ですね。 どんなに忙しい人でも、きっと電車を待っている時間だったり、ちょっとした休憩時間などの空き時間がありますよね。この時間を如何に有効に活用するかで変わってくるのかなぁと思います。
そして、空き時間なので、腰をあげて、「よっこいしょ！」って感じの作業は、向かないですね。自然とiPhoneを覗き込むだけで、有益な情報をゲットできたり、新しい技術を習得するきっかけを掴めたりしたら、いいですよね。
そこで、自分は一歩すすめて「Kindle」を有効に扱うという結論に達しています。
どこで情報を集めるのか？？
情報を集める場所は、どこがいいのかは、所属する業界や自分が目指している方向性によって、変わってくるかと思いますが、自分のお勧めのWebエンジニアの情報収集方法は、以下の通りです。
自分は、この３つのアプリ・サービスで、情報を集めています。 上でも書いた通り、空き時間を有効に扱う為に、まずは情報収集だけをやって、気になったら、すべて「あとで、読む」系サービスに集約し、消化していくという形で、効率化しています。
「あとで、読む」系サービス
「あとで、読む」系サービスは、いくつか存在しますが、現時点では、以下の２つのサービスを利用しています。
今のところ、情報をかき集めて、Pocketに突っ込んでいます。 その後に、IFTTTで、全ての記事をInstapaperにも同期しています。
なぜ、この２つ使っているかというと、もともとPocketに集めて、Readabilityに同期して、そこからKindleに未読の記事を毎朝、送信する設定にしていたのですが、数ヶ月前にReadabilityがサービスをアップデートした際に、記事がKindleに送信されなくなってしまいました。 自分の設定や理解不足なのかもしれませんが、解決することが出来なかった。
そこで、昔触った事のあるInstapaperを思い出しました。 でも、あまり使いたくなかった。理由としては、この系のサービスは、基本的に対象の記事をスクレイピングして取得してくれるのですが、記事に画像があってもInstapaperの場合、取ってきてくれないので、記事を読んでいて、理解できない場合が生じてしまうのが、主な要因でした。
しかし、ダメもとで試してみたら、なんと今のInstapaperは、画像データもちゃんと取ってくるようになっていたので、すぐにReadabilityから乗り替えました。
PocketでFavしたら、はてブ！
IFTTTで、メール送信して、はてブしています。
InstapaperでLikeしたら、はてブ！
IFTTTで、なぜかInstapaperのTriggerチャンネルがないので、Instapaperの設定で、tumblarに連携ができるので、一旦tumblarに連携してから、IFTTTで、メール送信して、はてブしています。
なぜ、はてブ！をするのか？？
なにか、貢献する的な心理的な要因がありますね。 やはり、日本のWeb系のエンジニアは、はてブをチェックしり、コミットしたりする人がまだまだ多いので、自分が見つけた記事で、「こんな記事みつけたぜ！」とか、教えてもらったので教え返す的な感覚かなぁと思っています。
Kindleで集中して記事を読む
Instapaperから送信されたKindleを通勤の合間に読みます。 Kindleは、とにかくドキュメントを読むことに特化したツールなので、 読んでいる最中にTwitterの通知が来て、そっちを見に行っている間に、 時間が過ぎて、結局記事を読まないままになってしまったりということがないのが 気に入っています。
ただ、Instapaperで不満だったのは、Readabilityのように、Kindleに送信したとに、送信した記事を「既読」にする機能がなく、毎日前日に送信された記事と重複した記事が何件が送られてしまっていました。
ストレスを感じて、どうにかIFTTTとか使ってなんかできなかなぁと考えていました。
ある日、Kindleに送られてきた記事のヘッダーをよくよく読んでみたら、こんなことが書かれていることに気付きました。
この「All Archive」クリックするだけで、送信されてきた記事すべてを、「既読」のステータスに変更することができます。 あと個別の記事ごとに「Like」することも出来て、もっと深堀したい記事に関しては、Likeしておいて、PCで確認したりできて、いい感じです。
以上、最近の自分がやっている「あとで、読む」の環境でした！！是非、参考になれば、うれしいです。
参考にさせていただいた記事
- (快適に「あとで読む」ための環境 TATSUHIKO MIYAGAWA'S BLOG)http://weblog.bulknews.net/post/13811211811
受託において、Immutable Infrastructureはちょっと。。。
最近は、「Immutable Infrastructure」が流行っていますが、仕事の受託に取り入れることを考えていたんですが、どうもしっくりこないなぁと思っています。
だって、受託開発の場合、サーバーはお客様のものですから、なかなかImmutable Infrastructureの運用フロー？に合わせてもらうのも難しい（例えば、バージョン管理ツールと使ってもらうとか。。。）。
だから、Chefとかの冪等性のあるプロビジョニングツールの運用がしっくりくるなぁと最近思う訳です。
その辺の、縛りとかで、どっちの運用にしていくのかが、決まってくるかと思います。
SEKAI NO OWARI
最近、SEKAI NO OWARIの曲ばかり聞いている。
とっても自分としては、新鮮でハマった。
幻の命というのも良い曲だ。これは、ピアノのさおりちゃんが、１５歳のときに作曲。２０歳の深瀬くんが歌詞をつけて、完成した曲のようで、１５歳でこのメロディーを作れるって、すげぇなと。
昔のブログを読むとうれていないころに、近くの無料で見れるステージとかに出演していて、見に行けば良かったと後悔？したりしている。
明日も聞こう。
