Cloud Automatorを支える技術

Cloud Automatorアドベントカレンダー 大トリの25日目を担当します。

qiita.com

Cloud Automatorとは、AWSの運用を自動化するためのサービスです。ですので一般の方にはあまり(というかほぼ)馴染みのないサービスですが、アドベントカレンダー最終日の今回は、Cloud Automatorの裏側の技術について書きたいと思います。

サービス概要

Cloud Automatorには大きく2つの機能があります。サービスサイトから引用します。

cloudautomator.com

1. 運用自動化
Amazon Web ServicesAWS)の運⽤に⽋かせないバックアップ、インスタンスの起動 / 停⽌など、様々なオペレーションを⾃動化します。 また、RDSの起動 / 停止やEC2インスタンスのタイプ変更といった、AWSが標準で提供していない独⾃のアクションも多彩に取り揃えています。

2. AWS構成の自動チェック
お客様のAmazon Web ServicesAWS)リソースが決められたルールにしたがって構成されているか定期的にレビューします。 これよって、AWSの環境が当初計画された通りに運⽤されているかどうかが誰でもすぐに把握できるようになります。

アーキテクチャ

運用自動化機能の裏側

AWSから提供されるAPI等を利用して自力で運用自動化を行う場合、

  • エラーのハンドリング
  • リトライ制御
  • 回避不可能なエラー時の通知

などなど、自前で行うには様々な苦労が伴う部分ですが、これらをWeb画面上からの入力指示のみで実現するために、Cloud Automatorの裏側の技術はこのようになっています。


全体イメージ

運用自動化の全体アーキテクチャは、こちらのブログに詳細が記載されています。

cloudautomator.com

f:id:haru_skywalker:20171225230850p:plain


OpsWorks + SWF部分の詳細

OpsWorksとSWFの詳細については、こちらのブログに記載されています。

cloudautomator.com

f:id:haru_skywalker:20171225231930p:plain

AWS構成の自動チェック(構成レビュー)の裏側

f:id:haru_skywalker:20171225233452p:plain

こちらはブログが存在していないので構成図のみになりますが、主に以下のアーキテクチャで構成されています。

  • AWS Config:AWSリソースの変更等の検知
  • AWS Lambda:AWSリソースの構成評価
  • Amazon SNS:評価結果の通知

AWSリソースがルール通りに構成されているかをチェックする心臓部分は、約50個からなるLambdaファンクションによって行われ、それらはPythonで実装されています。

操作画面/その他の裏側

フロントエンド

実際にユーザーが触れる管理画面は、Rails+Reactで作られており、heroku上で動いています。(EC2ではないです…!)

Rails、React、および利用gemやnpmパッケージ等のバージョンは、定期的に最新に追随しています。

SPAではなく、Railsがベースにある上で、非同期処理が必要な部分がReactで実装されています。しかし一部ではまだjQueryCoffeeScript)での実装部分も残っており、完全にReactへの置き換えがされるのはまだもう少し先・・・になりそうです。

外部利用サービス

外部利用サービスについてはこちらに記載があります。

cloudautomator.com

上記ブログに書かれていないサービスも多数利用しており、たとえば

  • ログ管理:Papertrail
  • ジョブ監視:Dead Man's Snich
  • 操作マニュアル:ZenDesk
  • 画面操作ログ解析:Hotjar

などなど、他にも挙げるとキリがないのでこの辺にしておきます。

さいごに

いかがでしたでしょうか。

Cloud Automator に限ったことではないですが、サービスの裏側は、このような様々な技術要素で構成されており、エンジニアチームは日々システムの健康を維持すべく努力を続けています。また、これからも技術進化への追随や、新機能の開発にも邁進していきますので、今後ともどうぞよろしくお願い致します。

私個人から見たチームの変化について

今年の1月15日に現在の会社に入社して、もうすぐ1年が経ちます。

フリーランスを卒業して「会社員」というステータスが久しぶりだったので、入社当初は色々戸惑うことが多かったのですが、今では立派な不良社員になりました。

そんな私個人の今年の振り返りは別途書くとして、チームや担当サービスがこの1年でどのように変わったか?を少し振り返ってみたいと思います。

f:id:haru_skywalker:20171220163608p:plain

ミーティングについて

週次ミーティングの在り方の見直し

アサインされた当時、定例のミーティングは以下の2つでした。

  • 朝会(毎朝、今日何をするかを報告する会)
  • 週1回の週次ミーティング(一週間何をしたか、次週何をするかの報告)

アサイン当初は右も左も分からない状態で、ミーティングもただ参加するような状態でしたが、会社にも慣れてきた頃、ミーティングの在り方をもう少し見直したほうがいいと思うようになりました。

というのも、当時の週次ミーティングは朝会の延長なような状態で、全員が集まる価値が生かされていないと感じたのです。そこで上長に相談して週次ミーティングの在り方を大幅に見直しました。その後も何度か内容の見直しが入り、最終的に現在はこのような内容に落ち着きました。

  • 各チーム担当分の進捗状況の報告
  • 次回リリースに関する報告
  • 技術的課題の共有
  • 発生した障害の共有
  • 技術的ナレッジの共有
  • ユーザからの要望の共有
  • 売上・成長率の報告
  • 新規Issueの確認、およびマイルストーンの設定
  • 未解決Issueの棚卸し(月1回)

内容は今後も少しずつ変化していくと思いますが、その時々で最適な会議体を検討する風潮が根付いたことが、良い変化だったと思います。

おそらく入社直後だったから、第三者的な視点で長年の慣習に疑問を持てたのでは?という気もするので、転職直後の「曇りなき眼」のうちに、思い切って既存の体制に斬り込む勇気も時には大切だと思います。

ミーティング開催日の見直し

しばらくずっと、週次ミーティングは金曜の夕方に行われていました。でもこれにもちょっと不満がありました。

ミーティング内容の見直しの結果、せっかく様々な議論が出来る場になったのですが、金曜夕方に密度の濃い話をしても、具体的なアクションを起こせるのは週末を挟んだ月曜になってしまうのですよね。打合せで何かが決まったら、さっさと動いたほうが良いことって多いのですが、週末を挟むと残念ながら忘れちゃったりするんですよね・・・

ということで、週次ミーティングは火曜の午前中に行うよう開催日の見直しをしました。体感的に月曜って何かと忙しかったりするのと、ハッピーマンデーや振替休日などの影響を受けやすいので、週の前半、特に火曜は個人的にちょうど良いと思ってます。定時近くは避けて可能な限り午前中にやるのもポイントで、熱量のあるうちにアクションが起こせるため、午前中に行うのはなかなか良いと感じています。

技術的負債への取り組み

負債返済の日を作る

これはつい最近決まったことですが、「月に1日だけ技術的負債を返済する日」というのを設けることになりました。

なかなか手を付けられていない技術的負債が蓄積しており、しかし他タスクとの優先度を考えると、いつまでも放置されてしまうのが現状でしたが「月1日であれば通常業務への影響度も少なく済む」ということで、試験運用的に月に1日行うことで始まりました。

これはまだ始めたばかりなので、効果がどの程度出るかは未知数ですが、個人的には「負債が溜まり続けることへの精神的負担」の軽減効果は大きいと思っています。稼働ベースで言えば全体の5%程度しか負債返済に充てられないのですが、それでも「負債を返済する機会がある」ということ自体が、エンジニアの精神衛生には大切なことだと思っています。

全体に関わる技術的負債について

現在、サービスの根幹部分で、インフラコスト/開発効率/学習コスト共に負担の大きなアーキテクチャが採用されたままの状態にあります。

サービス開始当時はそれしか選択肢が無かったのですが、現在は他にも代替となるものが出てきました。しかし、今から変更するのは大きな労力を伴うが、このまま突き進めばデメリットも膨らみ続ける、という悩ましい問題にぶち当たっていました。

そこで、新しいアーキテクチャへ乗り換えをチームで慎重に検討したものの、最終的には「今はサービスのグロースが最優先」という結論になったため、乗り換え自体は見送りになってしまいました。しかし、ただ見送るというだけでなく、「売上目標が達成されたらアーキテクチャ変更を再検討する」という結論になったのは個人的にとても良かったと思っています。

今回のような「新しいアーキテクチャへのチャレンジ」が見送られるようなケースは、往々にしてエンジニアのモチベーションをポッキリ折りやすいものです。しかし条件付きでも可能性があるのと無いのでは話は大きく違うし、今度はその条件をクリアしようという別のモチベーションにも繋がります。また、このような議論および結論が出せたこと自体が、チームにとって意義のある結果だったと思っています。

開発以外のタスクについて

マーケティングや営業活動

残念ながら、現在サービス専用のマーケティング部隊や営業が不在なため、チームとしても開発だけに専念していれば良い状態ではないのですが、アサイン当初はその辺がかなり手薄な状態にありました。

そこでチーム内で話し合った結果、直接的な営業活動は引き続き営業部門をはじめ他部署に依存するものの、社内の情報連携や、整っていなかったマニュアルを充実させていくなど、他部署との強化を図ることになりました。またマーケティングについては、サービスサイトや販促パンフレットの見直しから始め、外部メディアへの露出、開発ロードマップの公開などを行いました。

まだ十分とは言えないものの、この1年間で開発以外の部分については、以前より大幅に改善されたと思っています。

ユーザーヒアリングの実施

本来であれば定期的にユーザーヒアリングは実施すべきなのですが、慢性的なリソース不足でなかなか実施出来ないでいました。

現在、サポートページから要望等を投稿してもらう仕組み自体はあるのですが、表面的な要望しか分からず、もっと踏み込んで「具体的にどのように利用され、顧客の業務のどこに影響し、どのような不便を強いているのか」といったことを詳細に把握するために、ユーザーヒアリングを実施しました。

このヒアリングは、この1年で一番効果が大きい部分であったと個人的には感じています。

インタビューからは非常に多くの収穫があり、その結果として現在大きな仕様追加の開発を行っている真っ最中です。一般利用者向けのサービスとは違い、企業ユースのエンタープライズサービスの場合、顧客の業務に関する部分はヒアリングでしか把握出来ない、ということを改めて感じた次第です。

また、顧客だけでなく社内の各部署にヒアリングを実施したのも非常に良かったと思っています。弊サービスは社内でも多く使われているため、日々の業務効率に繋がるために必要機能や、どうすればもっとセールスに繋がるか、といった視点でもヒアリングを実施しました。これは代表から「売り上げを伸ばすことだけが利益ではなく、社内の業務効率を改善することも利益に繋がる」と言われたことが大きいのですが、それが結果として営業やサポートといった多方面からの意見の収集に繋がり、顧客だけではなく社内に目を向ける良いキッカケになり、そこから多くの課題も見えてきました。

現在はこれらヒアリングの結果から、必要な機能の開発中です。リリースされてからが本番ではありますが、以前よりは確実に効果が高い方向に舵を切れている感覚があります。

さいごに

この1年間で、サービスの売上は年間目標を達成出来るかどうかギリギリなところですが、成長率としてはかなり良い数字となっています。

これは勿論チームだけでなく、営業を始めとした他部署からの協力があって達成できた数字であり、1つ1つは小さな変化ですが、積み重ねの結果がしっかり数字として現れていることが大変嬉しく思った1年でした。

会社の規模が違うと何が違うのか、自分なりに考えてみた

f:id:haru_skywalker:20170929181259j:plain

1月に会社員に戻ってから、早くも8ヶ月が経っていました。

これまで私は、千人以上の大企業か、少人数ベンチャーのどちらかしか経験がなく、現所属の100人前後の規模の会社は初めてだったので、色々と新鮮な日々です。

私の経験から、会社規模によってどんな違いがあるかをちょっとまとめてみました。当然これが全ての会社に当てはまらないとは思いますが、何かの参考になれば幸いです。

これまでのキャリア(ざっくり)

※ここにある従業員数などはすべて当時の情報です。

  • 新卒入社:1000人超の中堅SI企業
  • 転職1:10名前後のベンチャー
  • 転職2:2000人超のグローバル展開しているコンサル会社
  • 転職3:5名のベンチャー
  • フリーランス:主に数人〜30人前後のスタートアップ
  • 現在:100人弱のCI企業

出戻ったり、他にも色々しているので、転職回数自体はもう少しインクリメントされてますが、ざっとこんな感じです。

ベンチャーはどうだったか

早速ですが、まずはベンチャーがどんな感じだったかを書きたいと思います。

良かった点

これはなんといっても経営者との距離の近さでした。大企業に所属していた時には、社長と話をする機会なんてまったく無かったし、正直顔も覚えてないです。

社長との距離が近いと何が良いかと言うと、会社が何を目指しているのか、どんなビジネスを見据えているのか、社長の熱意や温度感をリアルに感じられたこと。そしてそれに対して自分がどう貢献していくべきか、といったお互いのビジョンの共有が当たり前に出来たことです。

サラッと書いてますが、これが大企業になると現場にそのような情報が届くのは、伝言ゲームを経た結果のただのテキスト情報です。自分ごととして捉えるにはあまりに難しい。

あと、フリーランスでスタートアップを手伝っていた時は、会社やサービスの成長過程を共有させてもらえたのは、かなりエキサイティングでした。自分たちの手で作り上げていく感は、文化祭前の興奮に似た状態が続いている感じに似ています。そういった面白さはありました。
・・・ただしそれは、私が部外者でリスクを取っていない立場だったから、単純に面白さだけを感じられた、というのもあるとは思います。

悪かった点

逆にベンチャーで一番しんどかったのは人間関係です。仕事の内容とか給料よりも、これが一番辛かったです。特に超小規模の会社では、上司とウマが合わない場合は地獄でしかないです。チーム替えとか部署移動とか、そんなことできませんからね。少人数の会社に入るのであれば、メンバーが一緒に働きたい人たちなのかどうか、見極められるケースだけオススメします。

ウマが合わない以外でも、例えば「女性が1人しかいない」といった環境もかなり辛いものがありました。トイレが男女共用だったり、トイレ掃除をさせられたり。(トイレの話ばっかりだな💧)
「私、トイレ掃除するためにこの会社に入ったんだっけ?」と何度思ったか分からないです。家事は普段の自宅で既にお腹いっぱいなのに、なんで会社でまで・・・という気持ちが大きくなりすぎました。

大企業はどうだったか

良かった点

一方、大企業で良かった点は、やはり福利厚生の手厚さとか、研修制度の充実とか、ありきたりですがベンチャーを経験した後では身に染みてありがたかったです。

あとは、規模の大きな仕事をそれなりのポジションで経験できたことは良い経験値になりました。また、自分の望むプロジェクトへのアサインも時には叶ったり、社内に選択肢が多かったのは良かったな、と今になって思います。

悪かった点

ただし、何かと事務手続きが多かったり、例えば客先常駐の仕事が長く続くと帰属意識が薄くなったり、意思決定プロセスが面倒だったり、よく分からない中間管理職が増殖したり、それなりに大企業ならではの問題もあります。

でも私が一番辛かったのは、人数が多いと無能な人も多いということ。よく言われる「働き蜂の法則」に従って、優秀な人もいるが、無能な人もそれなりの数いるという現実。それが何に影響するかというと、無能な人を基準に仕事を組まなければいけなくなることです。ベンチャーで少数精鋭だった時には考えられないような、スケジュールのバッファやレビューの頻度など。
私が所属していた環境が特別だったせいだと思いたいですが、おそらくこれが現実でしょう。

大企業・ベンチャーの良い点/悪い点って、両者ほぼ裏返しのような関係。だから、何を重視するかによってどちらが向いているのかは、人によって分かれると思います。

中規模会社はどうなのか

まだ入社1年未満ではありますが、端的に言って私には今が一番居心地が良いです。

まったく不満がないわけでないですが、自分の成果が会社に与える影響をほどよく感じられ、ベンチャーのような人間関係の苦労も薄まりました。大企業と比較すると、人によっては待遇面や環境など見劣りする部分があるかもしれませんが、個人的にはその辺の差は他のメリットで相殺されている感じです。

社長が雲の上の存在でもなく、あらゆるリソースが不足しているようなベンチャーとも違い、今まで所属してきた会社との違いを楽しんでいる毎日です。

ただ、企業風土が自分とマッチしているかどうかも大きな要因ではあるので、単純にいいよ!と言えるわけではないのですが。

さいごに

転職回数が多いと日本では何かと不利になるケースが多いので、なるべく自分にマッチしている会社を選びたいものです。それで会社規模によってどんな違いがあるか、を自分の経験を元にまとめようと試みたものの、最終的には「企業風土」などという明確に計れない言葉を出してしまい、こんなの何の役に立つんだ・・・という申し訳ない気持ちで一杯になったところで、終わります。

活発な議論を促すために必要な「心理的安全」の具体策について考えてみた

f:id:haru_skywalker:20170626175155p:plain

私は現在、Webサービスの開発に携わっていて、サービスの今後の追加機能だとかプロダクトの今後について、チーム内でミーティングをすることがよくあります。現会社に入社するまでは、フリーランスで数社のベンチャーやスタートアップのプロダクトの開発チームの一員としてお仕事をさせてもらっていましたが、その時にも、同様にプロダクトの方針に関わるミーティングにも何度か参加させていただく事がありました。

入社して5ヶ月が経ったのですが、フリーランス当時と今とで、チーム内のミーティングの在り方が全然違うなぁ、と思うことがよくあります。そのことについて少し書きたいと思います。

スタートアップでよく見る人間関係

私の半径5m内での感想になりますが、スタートアップの創業メンバーというのは、以前から友人関係・同僚関係にあった人同士が会社を興しているケースが多く、人間関係がフラットな状態から始まっていることが多いように思います。人間関係がフラットというのは、先輩/後輩、上司/部下、経営者/従業員といった、各人をカテゴライズする属性を感じさせない人間関係のことを言っています。

そういった人たちのコミュニケーションは、多少の気遣いはあるものの、会話は基本タメ口だし、時には冗談も言い合える関係。プライベートな情報も日常的に共有しており(おそらく無意識に)、その人の性格だけでなく、得意・不得意、共感ポイントなどもある程度分かり合っている。

そのため、定例ミーティングも形式的なもので終わらず、何も発言しない人がいた…といった無意味な打合せは少なかったように思います。

少人数のプロダクト開発の現場において、例えばプロダクトの今後の方向性を議論するような重要な場面では、密度の高いブレストが求められると思います。フラットな関係の人同士の集まりでは、「一理あるけど、それってちょっと違くね?うまくいえないけど」といった気軽な会話が可能で、総じて活発な議論になりやすい。(議論が発散していくリスクも多少ありますが)

一方で、フラットな関係ではないサラリーマンチーム(と、ここでは呼ぶことにします)の場合、もし誰かの発言に違和感があっても、「うーん、それはどうなんだろう… でもハッキリとした根拠や理由が今は思いつかないな… なんて言えばいいだろう」などと心の中でワンクッションが入って、発言を迷っているうちに話がどんどん先に進んでしまう、といったケースはあるんじゃないでしょうか。(私はよくある)

「活発な議論」というお題目においては、どう考えてもフラットな関係のメンバー同士のほうがその目的を達成しやすいと思うのです。

フラットな関係を作るためには

チーム開発の文脈では、「発言しやすい雰囲気(心理的安全)を作るのが大切」といったことがよく言われています。

確かにその通りなんだけど、でも具体的にどうやったらいいの?といつも思うのです。いきなり全員が友達になれるわけではないし、ある程度の規模の会社なら、当然ながら上司/部下の関係は出来上がっていて、すぐに取っ払うことも難しい。

いきなりフラットな関係に持っていくのはかなり無理があるので、おそらく段階的にやっていく必要があると思っています。

例えば、まずファーストステップとして、「お互いをニックネームで呼び合う」くらいから始めてみる。これ、人間関係構築の初期における鉄板で、ニックネームで呼び合うと、セカンドステップの「タメ口で話す」に移行しやすい、という副次効果もあります。

ビフォー: 「阿部さん、この件の進捗どんな感じでしょうか?」
アフター: 「アベちゃん、この件の進捗どんな感じ?」

“ちゃん付け” で呼びかけてるのに、敬語だと逆に違和感ありますからね。

私にはこの程度しか今は浮かばないのですが、精神論ではなく実践できる具体的案について、何かアイデアがあればぜひ共有していただきたいです。

さいごに

一見するとくだらないと思われるかもしれません。でも、本気で「チームの心理的安全」について考えるなら、ただ漠然と「各人が気をつける」だけでは何も進展しないので、具体策にまで落とし込んで実施していく必要があると思うのです。

もし、ニックネームやタメ口は性に合わないわ… というメンバーが多そうな場合には、もういっそ諦めて、誰か絶対的なリーダーシップを持った人の独裁チームにする方がまだマシ。だと私は思っています。中途半端にお互いを立てあって、気を使い合った上辺の議論よりも、ジョブス的なリーダーシップを持つ人に導いてもらうほうが、議論もまとまって意味のある打合せになる気がします。

アプリエンジニアもUIレビューしよう

f:id:haru_skywalker:20170617020613p:plain

私が所属しているチームはBtoBのWebサービスを開発しているのですが、専属デザイナがいるわけではないため、デザイナ経験のある私がUI全般の責任者をしています。

UIに変更が入る時は、Issueの時点でデザインをどうするかコメントを求められたり、担当者がPRした内容のうちUI部分のレビューをする、という感じになってます。

小さな機能変更であれば、現場の開発者がボタンを1個増やす程度の修正はよくあるかと思います。そういうちょっとしたUIの変更時に、コードレビューとは別に「UIレビュー」を別のエンジニアがやってみたらどうだろう?と、ふと思いました。

というのも、今日偶然このスライドを見て、これは良いなと思ったのです。


初めてのレビューでも、二次受けレビュアーがいてくれれば安心できますよね。自分が気付けなかった部分があれば、指摘で更に成長できる。

これって何もコードレビューだけじゃなく、色々なことに応用できそうです。そう、UIレビューです。

ツールを使うだけがデザインではない

デザインを勉強したいけど、デザインツールを使ってまで何か作るのはちょっと…と思ってる人は多いんじゃないかと。それなら、UIレビューから初めてみませんか。

おそらく、大半のエンジニアはUIデザインに真剣に向き合う機会がほとんど無いと思うのです。なのでレビュアーになることでその機会を作りましょう。

実際にやってみると分かるのですが、デザインルールが決まっていないグレーゾーンのものって結構多くて、例えばサブミットボタンなら色や配置は決まっていても、そうでないボタンの色/大きさはどうすべきか?など。ある程度ルールがあったとしても、やはり例外は出てくるものです。そんな時に、

  • このボタンデザインはこれで正解なのか
  • 配置はここで良いか
  • ラベルは利用者にとって分かりやすいか
  • 前後のパーツとのバランスは取れているか
  • 押した時の動きはどうか

たかがボタン1つですが考える視点はいくつもあります。コンシューマ向けサービスだと、更にコンバージョンへの影響なども気にする必要があるかもしれません。

レビューを正しく行うことよりも、これらを真剣に考えることが大切なのです。二次受けのレビュアー(デザイナ)がいれば、自分のレビューの答え合わせになりますし、気付けなかった指摘があれば一粒で二度美味しい。

これならイラストレーターやフォトショップを使うこともないので、やってみようかな?という気持ちになれたんじゃないでしょうか。

UIレビューの具体例

デザインレビューって個人の好みになってしまうのでは?と懸念するかもしれませんが、大きなデザイン変更ではなく、ちょっとした変更のレビューであれば、好みが入る余地はあまり無いです。

例えば今日私が実際にレビューしたのは、こんな感じでした。

これまではグレーのボタンが1つだったボックスに、機能追加でボタンが2つ追加されていました。1つの時は良かったのですが、狭いボックス内にグレーのボタンが3つとなると事情は変わってきます。私がコメントしたのは、

「メイン操作となるボタンだけ色を付けて目立たせ、利用者が迷いなく操作できるようにしよう」

というものでした。結果だけ聞くと簡単そうだと思ったかもしれません。実装している時には既存のデザインに引きずられたりして、案外気付かないものですが、レビュアーになるとよく見えてきます。

そしてこの程度なら、指摘された人は今後似たようなケースの時にすぐに応用できますね。小さな変更のレビューでは、指摘の大半は容易に実践できて応用可能なものなので、爆速でパターンの引き出しが増えていきます。

毎回レビューするのも大変だとは思うので、期間を決めてやるといいかもしれません。例えばチーム内で週ごとに順番でやるのも良いと思います。

さいごに

どんな方法であれ、大切なのは真剣に向き合う機会を作ることです。それが意識に繋がります。私たちの身の回りは、ありとあらゆるデザインで溢れています。意識が芽生えるだけで、目に入るほぼ全てのものが勉強対象になるのです。

今日、新しい洗濯機が届いたのですが、この操作パネルを見てください。

一色しか使っていなくても、ボタンの形状や大きさが異なるだけで、分かりやすくなっています。 意外と身近なところに色んな発見やヒントはあるのに、意識していないと気付けない。でも意識していれば気付くこともある。ただそれだけのことなのです。

Slackの専用チャンネルでフロントエンド周りの情報を垂れ流している話

f:id:haru_skywalker:20170613005305p:plain

早いもので、私が転職してから約5ヶ月になろうとしております。

二週間ほど前から、社内Slackでフロントエンド周辺の最新記事やトレンドなどを垂れ流すチャンネルを作りました。

内容は、Webブラウザ関連だったり、JavaScript関連だったり、JSフレームワークだったりと、とにかくWeb周辺で私がビビっと来た旬の情報を垂れ流すだけの、フロントエンド情報の専用チャンネルです。

なぜそんなチャンネルを作ったのか

単に自分の情報を整理する場が欲しかったのと、あわよくば他の人からも何らかフィードバックがあったら最高だと思ったから。

私が所属する会社はクラウドインテグレーションがメインなので、フロントエンドの話で盛り上がれる機会があまりないのです。無いなら自分で作ろうぜ!の精神により、勝手に作って勝手に垂れ流して、勝手にコメントしております。

現段階では9割方私しか発言していないですが、そんなこたぁ構わない。私が飽きるまで続ける所存です。

やってみてどうだったか

今まではローカルのメモにURLと簡単なコメントを残したりしていたのですが、これってすごく勿体無いなと。自分で言うのもなんですが、情報収集だけは割りとコツコツやってきたほうなので、こういうのは共有したほうが絶対良いよな、と。なんなら他の人の意見も聞きたいし、と。

でも、パブリックにするのは私の性格上ダメなんですよね。情報元に気を遣って当たり障りないコメントにするのは面倒だし、中途半端な知識のままネットの海に流したくないし・・・とアレコレ考えるとスピードが落ちる。何よりブログ形式にするほどの熱意も無い(文量的な意味で)。

なので、結論としてはSlackで簡単なコメント付きで共有するくらいが丁度いい。これが本当に丁度いい。

ちょっとしたコメントと共にURLを共有するのをマイルールにしているのですが、実際に続けてみると、内容をそれなりに理解しないと簡易コメントも書けないので、流し読みで終わらせず、知らなかったこと・分からないことは調べる癖が付きました。今までのようにローカルでストックするだけだと、この強制力は働かないので、これは続けてみて良かったと実感している点です。

さいごに

私としてはこのSlack垂れ流しは結構気に入っております。

情報のシャワーを浴び続けるうちに、点と点が繋がって線になることはよくあるので、数ヶ月単位では目に見えた効果を感じなくても、年単位になると違うはず。そして何より継続は力なり。ほぼ自分のためにやってるようなものなので、これからも自分よがりな垂れ流しを続けます。

以上。

特に理由はないけど1日1冊読むチャレンジをしてみた話

f:id:haru_skywalker:20170323004538j:plain

タイトル通りで、特に理由はないけど最低1日1冊読んでみるかと思って3日続けてみた。(先週分も合わせると計24冊。内15冊は漫画)

たった3日なので、まったく偉そうに語れるような身分ではないけど、ちょっとした感想を。

  • 今自分がめっちゃ気になる・知りたい内容であれば1冊読む程度なら楽勝
  • 「ちょっと興味がある」レベルの内容だと途中で何度も睡魔に襲われる
  • 1日2冊行けるかな?とチャレンジしたら、インプット過多になって辛かった

概ねこんな感じ。読んだのはいわゆるビジネス書の類なので、小説とか技術書だと全然違うと思う。

上記以外で思ったことを、ダラダラと書いてみる。

興味津々な分野をまとめて読む

たとえば、マーケティングとかプロダクトマネージメント、UI/UX周りが自分の中で今一番知りたい情報なのだけど、関心度が高い分野は「仕事に直結しそうな情報が知りたい」など、自分の目的が具体的かつ明確なので、書籍全体を熟読する必要がなく「ここは役に立ちそうだからじっくり読もう」「ここは読まなくても良さそう」などの判断が簡単。つまり、必要な情報の取捨選択が容易なので、サクサク読み進められる。(=必要ないと思ったページはガンガン飛ばす)

今直面している課題や自分の状況に置き換えながら読めるので、読みながらアイデアもどんどん出てくるし、それをメモる行為も楽しい。あっという間に読了。

同じ分野の本を連続して読むと、表現が違うだけで内容が重複することが多いので、2冊目以降はさらにスピードが加速する感じ。なので、短期間でまとめ読みすると効率がめちゃ良い。

興味が薄い分野の対策

まず興味を持つことが大切なので、最初に目次をじっくり眺め、内容を予想して「ここは知りたい内容かも」と具体的にイメージするのが大切かなぁ、と。これは今も試行錯誤中。

ただ、確実に読書ペースは遅くなるので、もしなかなか読み終わらないなら、途中でやめても良いと決断する勇気も必要かと。(高い本だとツライですが…)

それから、睡魔に襲われた時は無理をしない。寝よう。

とりあえずアウトプットする

1冊読めば何かしら響いた情報がある。でもブログを書くほどではないし、そもそもブログとか面倒。そういう時はどこか垂れ流せる場所にとりあえず記録する。ツイッターでもいいけど文字数制限が面倒。今日試してみて良いなと思ったのがSlack。自分専用のチャンネルにダラダラと垂れ流してみた。

自分なりに理解した情報を、自分の言葉で言語化すると、記憶の引き出しが1個増えたような感じになる。インデックス付きでDBに格納されるようなイメージというか。同分野の書籍を複数読んだら、リレーションも増えていくイメージ。インデックスの再構築も起こる。

私はどうにかして仕事に繋げてやる!という気持ちで読んでいるので、アウトプットするモチベーションになっている、というのもある。

さいごに

しかし、興味津々なものってそんなに多くはないので、楽勝モードなのは最初だけだろうなぁ。

電車の移動時間で読むのが私的には一番ピッタリ来るので、リモートワークな日は読まない可能性が高いし、まぁ年間60冊読めれば良いほうかなと思ってる。

そして何より、Kindle unlimited のおかげで、値段を気にせず色々読めるのは大変ありがたい。アマゾンさん、ありがとう。