Google Cloud Next'19 Tokyoに行ってきた
昨年に引き続き、Google Cloud Next'19 Tokyoに参加してきました。
参加したのは7/31(水)の午後で、セッション４つに施設内を色々散策してきたでの、
その内容を書いておきます。
基調講演と一部セッションの動画が公式サイトの「Next OnAir」から視聴できますね。
セッション
去年と違うのは18時以降も2枠のセッションが追加されていて、18時40分開始枠では「Google幕の内弁当」が配られていました。
Google Cloudでデジタル変革を成功させるためにすべき３つのこと
Google Cloud Next ’19 in Tokyo | 7 月 30 日 - 8 月 1日
株式会社永和システムマネジメントの方によるアジャイルとベンダーとの共創による社内のDX推進の考え方と方法のお話です。
私(SIer)から見て、ユーザー企業向けのセッションだと聴講前から分かっていたのですが、故郷の企業がアジャイルをどのように取り組んでいるのか知りたく聴講しました。
大手ベンダーが諸々の理由でできていなかったDXやアジャイルの取り組みを、小回りがきく中小ベンダーが先に取り組むことで、貯めた経験とそのための施設を使ってDXビジネスをどんどん受注しようという狙いが見えました。
自分の認識範囲で内容をまとめておきます。
○DXのサービス企画は内製化。「発注・受託」→「共創・共育」へ。
従来のウォーターフォール開発だとモノができてビジネスを始めるまでに時間がかかるため、ビジネスを始めた時点で企画したときと市場が変わって無意味になる可能性ある。そのため、アジャイルの開発方法を用いる。また、ユーザー企業とベンダーの関係は「発注・受託」→「共創・共育」へと変わる。
○ベンダーに鍛えてもらう
業務を知ってもらう人がコードを書くのが最強だと考えている。そのため、ベンダーはプログラミングを教える。ユーザーは業務を教えて、共通理解を深める。
一緒に汗を書くことで、ベンダーの技術者の創発性を促す。今まで（ウォーターフォール）では工程で分かれていたため、技術者の創発性を活かすことができなかった。むしろ、設計した通りに製造をしてほしかったため活かせないようにしていた面もある。
○DX≒新規事業
DXは身近にあるところからでもよい。GCPが必ず必要でもなく、GSuiteでもDXツールになる。→事例としてGSuiteによる作業の見える化ツール
○技術者の技術点転換
レガシーな技術者でもDXの過程でGoogle App Script（GAS）から触り始めて、GAS→GAS+js（ライブラリ）→GCP+javaと約7カ月かけてモダンな技術転換ができる。
○質疑応答
詳細は書けないけど、大手SierはDXでは儲けられないから拡がらないのではないかと懐疑的な質問があった。
最後に、東京から遠いけど、Agile Studio Fukuiは見学者募集中！
データウェアハウスのあるべき姿とBigQueryの新機能
Google Cloud Next ’19 in Tokyo | 7 月 30 日 - 8 月 1日
従来のDWHが持つ要素をBigQueryではどの機能により解決できるのか、またBigQueryが目指すDWHの姿と独自の機能の紹介がありました。内容としては既にあった機能の国内初発表もあれば、世界初発表の機能もあったと思います。
これからのコンセプトとしてBigQueryをオープンデータウェアハウスと位置付けるようです。様々な外部のデータ処理からBigQueryへデータを連携し、処理して、アウトプットできるように機能強化をしていくイメージを持ちました。
○500slotで$10,000/月の定額料金
BigQuery pricing | BigQuery | Google Cloud
○処理速度改善
2018年に2分かかっていたペタバイトクエリが、2019年では数秒に向上。
○Persistant UDFs beta
ユーザーがJavaScriptで独自に開発した関数を保存して、SQLで呼び出して使うことができる機能。
New in BigQuery: Persistent UDFs - Felipe Hoffa - Medium
○自動再クラスタリング
クラスタ化したテーブルを無料で自動で再クラスタリングしてくれる機能
○Parquet&ORCの取り込み beta
Hadoopのファイル形式であるParquetとORCの取り込みをサポート
Cloud Storage からの Parquet データの読み込み | BigQuery | Google Cloud
Cloud Storage からの ORC データの読み込み | BigQuery | Google Cloud
○Cloud SQL Federation beta
BigQueryからCloudSQLへのクエリを発行できる。join可能で、CloudSQLにあるマスタデータとBigQueryにあるトランザクションデータをjoinさせてデータ分析が可能になうようです。今まで自前でCloudSQL→BigQueryへデータ移行していたユーザにとっては簡略化できるので良いかなと思います。発表時点では数日後にbetaになると言っていましたが、現時点ではまだのようです。
画像が粗くて分かりにくいですが、クエリを発行するデモがありました。
画面左下にある「External connections」がBigQueryと接続しているCloud SQLのデータベースです。先にこの設定をする必要があるようです。
クエリ発行部分では以下のクエリをたたいてCloud SQLからデータを取得していました。画像がないですが、JOINを使ったデモもあり。
SELECT * FROM EXTERNAL_QUERY("bigquery-federation-*****.us.demo_mysql_connection","SELECT * FROM ****_TABLES;");
○BigQuery Storage API
他のデータ処理技術と接続するためのAPI
BigQuery Storage API Overview | BigQuery | Google Cloud
○BigQueryストリーミング
リアルタイムにデータを処理する機能で機能改善を行っていることを言っていた。
○BigQueryのデータ共有方法
メンバーとデータを共有したり可視化するための方法
・DataPortal
・パートナーツール（Tableau,Lookerなど）
・BigQueryのクエリ保存機能
○BI Engine
（さらっと話していて聞き逃す）
○BigQuery ML
近日GAになるMLモデルがあるようです。詳細は画像を貼っておきます。
TwitterでのGCP事例:オンプレミスとクラウドで構成されたハイブリッドなデータ処理プラットフォーム
Google Cloud Next ’19 in Tokyo | 7 月 30 日 - 8 月 1日
TwitterをGCPに移行したお話です。50万core、12,500nodeあるHadoop基盤の一部をGCEとProcに移行しており、移行アプローチの話が良かったです。
内容については、実況した私のツイートを貼っておきます。
TwitterでのGCP事例:オンプレミスとクラウドで構成されたハイブリッドなデータ処理プラットフォーム #GoogleNext19
— タツヤ (@stand_arrow) July 31, 2019
Twitterの移行事例のページも紹介されていました。
Google Cloud Healthcare APIやGKEを活用した新世代の診療支援
Google Cloud Next ’19 in Tokyo | 7 月 30 日 - 8 月 1日
医療・ヘルスケアのDXで求められる条件とGCPのサービスと事例の紹介です。
ヘルスケアに関する認証（HIPPA）も取得しており、サポートする専用のAPIである「Healthcare API」と「Genomics API」の話をしていました。また、実際にGCPで医療サービスを運営している株式会社エムネスさんのサービス内容と今後の展望を紹介しており、面白いことをやっているなと感じました。
ただ、タイトルにあったGKEの話は出てこなかったですね。
Healthcare API - Powering Health Insights | Google Cloud
Google Genomics - Store, process, explore and share | Cloud Genomics | Google Cloud
施設の散策
認定者ラウンジ
昨年はなかったGoogle Cloud認定を持っている人だけがはいれるラウンジができたので行ってきました。また、限定バックパックもあったのですが数が少なかったみたいで品切れでゲットできなかったです。ホテルの一部屋を使っているのと、人も少なかったのもあり、静かでのんびりできる場所で良かったです。
Cloud Square
増上寺にあった展示と休憩エリアです。暑いのもあってかかき氷とレモネードが配られていました。また、Googleの社員が選ぶ本が展示されていて誰でも読める状態になっていました。暑いので見るだけで、読む気にはなれなかったですが。
GCPや技術の本だけでなく、マネジメントの本もあり多様でした。
以上、来年はいつするんでしょう？
AWS Summit Tokyo 2019 感想
6/12～6/14の３日間、幕張メッセで開催されていたAWS Summit Tokyo2019に行ってきました。参加したのは6/14(金)の午後です。
会場の様子。
滞在時間は約４時間と少なかったですが、規模が大きく、人も多いし凄かったです。
以下、参加内容です。
認定者ラウンジ
AWS 認定を保有している人のみが入れるラウンジです。先月SAAを取得していたので入ってみました。
中には席、電源、ラウンジ専用Wifiがあり、作業をする設備が整っていました。ただ、専用WIfiは通信状況が悪くスマホのデザリングで作業していましたが。
私が滞在中に、ドーナツとドリンク（お茶、コーラ、コーヒーなど）が配布されたので頂いたりも。
ドーナツ争奪戦！（一瞬でなくなった）
また、ステッカーとバッジがもらえたり、既に配布終了していましたが、インタビューに回答するとオリジナルTシャツももらえるようでした。
AWS DeepRacer
詳細を知らないのですが、AWSで自動運転モデルを作成する機械学習サービスである「AWS DeepRacer」のブースが目立っており、覗いてみました。
会社の同僚が別の日に走らせたらしく、面白かったと言ってましたね。作ったモデルをUSBに入れて持ってくれば走らせることができたみたいですが、そもそもAWSがこんなサービスやっているとは知らなかったので、知っていれば参加してたかな。
セミナー
１つだけですが、セミナーに参加しています。
業務に関わりのある顧客事例セミナーを受講しました。
内容は、クラスメソッドさんのこちらを見ていただければ。
感想ですが、まず建設業界に対するイメージが変わりました。100年続く老舗建設企業≒大手ゼネコンのイメージがあり、請負型ビジネスでITについてはまだまだ古いのかと思っていたのですが、前田建設工業ではOSSやアジャイルの導入を2011年から進めており、他も先進的な取り組みが多かったです。
新しい取り組みをし続けているからこそ、100年続いたのかもしれないと思えました。
余談ですが、前田建設工業にはファンタジー営業部という部署があり、宇宙戦艦ヤマトやマジンガーZなどの空想世界にある建造物を受注したら、どのように建設するか本気で考えているコンテンツがあり面白い取り組みです。
その他
他に書けないですが、業務に関わる企業ブースに行って、技術的な相談をしたり、先日買収ニュースがあったBI企業でお話を聴いたりしました。
以上です。読んで頂きありがとうございます。
アンケート回答でもらえたアイス
令和元年初日にAWS資格を取得するためにやったこと
タイトルにもある通り、令和初日にAmazon Web Services（以下、AWS）の資格の一つであるソリューションアーキテクト アソシエイトに合格しました。
受験の背景ですが、4月になって元号が決まったし、GW前半の予定がなかったので新元号初日に何かやりたいなと考えていたところ、業務でAWSを触る必要性が出てきたので新しく勉強する機会として良いと思い、令和初日に受験することにしました。
無事、合格することができたので、やってきたことを残しておきます。
AWSの資格について
AWSの資格ですが、ソリューションアーキテクト・デベロッパーにオペレーションを対象に専門知識を保有しているか検証するロールベースの認定資格と、ビックデータ・機械学習にセキュリティなど特定の技術分野の専門知識を保有しているか検証する専門の認定資格の２種類があるようです。私が受験したのは前者にあたる資格の一つである「AWS 認定ソリューションアーキテクト – アソシエイト」になります。
AWS 認定 – AWS クラウドコンピューティング認定プログラム | AWS
私のスペック
私の業務経験と知識ですが以下の通りです。
- 業務でGoogle Cloud Platform(以下、GCP)を使ったシステム開発経験あり。
- Google Cloud 認定資格のうちProfessional Cloud ArchitectとProfessional Data Engineerを保有。
というわけで、AWSの業務経験はないものの、パブリッククラウドの基礎知識と業務経験はあるため、私自身の勉強方針はAWSのサービスと特徴を広く浅く学習することに特化させています。
補足ですが、後者はGCPの認定資格で、２つとも2018/3に取得しています。Professional Cloud ArchitectはGCPを使ったクラウドアーキテクトの設計知識の認定資格、Professional Data EngineerはGCPを使ったデータ処理基盤と機械学習基盤の設計知識の認定資格となります。
Google Cloud Certified プログラム | Google Cloud 認定資格 | Google Cloud
試験場所
資格を取ろうと決めたところで、一つ心配になったのが"GWに試験やってるのか？"です。AWS認定の試験は、現状PSI またはピアソン VUE テストセンターで受験が必要となりますが、GW(5/1)はそもそも試験会場が営業しているのか心配でした。しかし、探したところ、東京駅付近のピアソン VUE テストセンターが営業しており問題なかったです。
勉強期間
勉強期間ですが2019/4/15に試験の申込をしてから試験当日までの13日間です。実際に勉強していた時間は、計測範囲内で約26時間になります。
勉強内容
ここからは私の勉強内容になります。
①読書
・徹底攻略 AWS認定 ソリューションアーキテクト – アソシエイト教科書 徹底攻略シリーズ (約11.5時間)
勉強に主に費やしたのが、この本の読書です。AWS Well-Architectedに沿って、AWSのサービス説明と試験の要点がまとまっています。また、模擬試験１回分がついてくるのも良かったです。この本を一通り読んだ後、後述の試験や問題集での不明点を理解するのに繰り返し読んでいます。
徹底攻略 AWS認定 ソリューションアーキテクト ? アソシエイト教科書 徹底攻略シリーズ
- 作者: 鳥谷部昭寛,宮口光平,菖蒲淳司
- 出版社/メーカー: インプレス
- 発売日: 2019/01/18
- メディア: Kindle版
- この商品を含むブログを見る
・AWS Well-Architected（約1時間）
AWSの設計方針がまとめられているホワイトペーパーです。日本語版PDFを１回だけ一通り読んでいます。
AWS Well-Architected – 安全で効率的なクラウド対応アプリケーション
②動画
・BlackBelt（時間計測なし）
YouTubeで視聴できるAWSのオンラインセミナーです。読書と模擬試験を終わらせた後に理解が足りていないと感じたところを補うために見たのと、本では扱っていないAWSのサービスを学ぶために見ました。具体的にはVPC、ECS、EKS/Fargate、コスト最適化の動画を視聴しています。
AWS Black Belt Online Seminar - YouTube
・AWS INNOVATION（約１時間）
2019/5/7までの期間限定となりますが、AWSのオンラインイベントでAWSソリューションアーキテクト – アソシエイトのオンラインセミナーが無償で視聴できます。AWS Well-Architectedに沿った内容で勉強初期のとっかかりに良かったです。
③テスト
・問題集（約４時間）
こちらのサイトは、AWS資格取得のための問題集サイトです。ゴールドプラン（3,880円税抜き）の契約をして、試験数日前からはずっとこの問題を解いていました。本に載っていない細かい仕様を知ることができたり、試験慣れをするのに良いと思います。
・模擬試験（約５時間）
模擬試験と して以下２つの試験を受けています。
- 本でDLできる模擬試験1回分
- AWS公式模擬試験1回（約2,000円）
後者はAWSが提供している公式模擬試験です。自宅などで本番と同じ試験画面で試験を受けることができます。試験終了後には分野別の正答率が出て自分の実力を把握できます。本番の雰囲気に慣れるのと実力把握のために１回は受験しほうが良いと思います。（復習のために、問題のスクショを忘れないように）
④実践
・AWS環境構築（約３時間）
少しではありますが以下の本を使って、AWS環境上でIAM、Route53とEC2を実際に触ってインスタンスを立てるところまで実施しています。実際に触ることで頭だけではなく体で覚えることもできた感じがします。
どちらもmochikoAsTechさん（TwitterID:@mochikoAsTech）著書の本です。どちらも技術書典５で購入した本になります。資格勉強としてはAWSのDNSサービスであるRoute53を学ぶのにあたりDNSの仕組みを復習するのと、AWSの権限の仕組みを触って学ぶのに良かったです。本題から外れますが、導入がインフラとは何か？という視点から入るので、インフラ・クラウドって何？という初心者の方にもお勧めできる本だと思いました。
⑤その他
・クラス研修
資格勉強から外れますが、勉強期間中に業務で「Big Data on AWS」のクラス研修を受講していました。ビックデータ関連のサービスに特化した研修なので、ソリューションアーキテクトの資格には幅が足りないのですが、セキュリティについては講師の方がソリューションアーキテクト向け研修とほぼ同じ内容と仰っており、資格勉強になりました。
Big Data on AWS - AWS トレーニング | AWS
試験感想
本番の問題ですが、模擬試験よりも難しかったです。時間不足にはならなかったものの、スコアが合格基準７２０点に対して７５５点と少しギリギリでした。余裕を持つためには、AWSの環境をもっと触ったといたほうが良かったかなと思っています。
参考
資格勉強にあたり参考にしたサイトです。
https://takulog.info/how-to-get-aws-solution-architect-associate/
才能分析ツール「ストレングス・ファインダー」
約２カ月ぶりのブログで、IT技術系の話ではなく、自己分析系の話。本題となるストレングス・ファインダーのミニセミナーを近々受講するので、復習を兼ねてブログにしておきます。
ストレングス・ファインダーとは
自分の才能を知り・活かすためのツール。
Gallup社が開発した自己分析系ツールで、「強みの心理学の父」ドナルド・O・クリフトンが中心となった研究により特定された３４の資質を元に自分の才能を知ることができる。
ここで言う才能とは"無意識のうちに頻繁に繰り返す思考、感情、行動のパターン"と定義されており、才能を活かした行動をすることで、生活や仕事で無駄な苦労をしないで成長および成功をしたり、他人と強み・弱みを共有するための共通言語として使えるようになるらしい。
診断を受けると、受診者の資質の順位が分かり、上位３０%程度(１位～１０位）が才能がある資質（≒強み）となり、下位３０％程度（２３位～３４位）が才能がない資質（≒弱み）となるようだ。
受け方・診断方法
ストレングス・ファインダーを受けたい場合、以下３つの方法がある。
- 書籍「さあ、才能(じぶん)に目覚めよう 新版 ストレングス・ファインダー2.0」を購入し、付録のアクセスコードを使用する。私はこの方法で診断を受けた。
- 公式Webサイトでアクセスコードを購入する。
- スマホアプリから有料で診断する。
で、診断方法には２コースあり、上位５つの資質が知れるコース（書籍はこれのみ）、３４の資質全ての順位を知れるコースがあり、前者は約２千円、後者は約１万円（執筆時点は割引で約５千円）となっている。先に上位５つを知ってから、追加料金を支払うことで３４の資質全てを知ることも可能である。
２コースについては、上位５つが最も発揮している才能で受信者がどの様なパターンで動くか大体説明できるらしいので、才能を知りたいという方は上位５つのみで十分だと思う。ただ、Gallupでは弱みを「成功の妨げとなるもの」と定義しており、下位１０％の資質が弱みとなりえるので、対策（＊）を検討するためにも半額のタイミングを狙って３４の資質全ての順位を知るべきだと思っている。
＊対策の例
・チームを組むときに、自分の弱みを補ってくれる資質を持つ人を探す。
・上位の資質で、下位の資質を補えるか検討する。
３４の資質
ストレングス・ファインダーにある３４の資質は以下の通り。
それぞれの詳細は割愛。全部知る必要はないため。知っておくと良いと思うのは、上位10%の資質の詳細と後述する４領域により自分の行動パターンがある程度分析できれば良いと考えている。
- アレンジ
- 運命思考
- 回復思考
- 学習欲
- 活発性
- 共感性
- 競争性
- 規律性
- 原点思考
- 公平性
- 個別化
- コミュニケーション
- 最上志向
- 自我
- 自己確信
- 社交性
- 収集心
- 指令性
- 慎重さ
- 信念
- 親密性
- 成長促進
- 責任感
- 戦略性
- 達成欲
- 着想
- 調和性
- 適応性
- 内省
- 分析思考
- 包含
- ポジティブ
- 未来志向
- 目標志向
ストレングスの４領域
３４の資質は４つの領域に分類でき、上位に多い領域ほど自分の強みとなる。
- 実行力：物事を成し遂げる領域（アレンジ、信念、公平性、回復思考、慎重さ、目標志向、規律性、責任感、達成欲）
- 影響力：主導権を握る方法を知っていて、はっきりと意見を表明し、他の人たちがそれに確実に耳を傾けるようにする（コミュニケーション、指令性、最上志向、活発性、社交性、競争性、自己確信、自我）
- 人間関係構築力：しっかりとした人間関係を構築し、チームをまとめ、単なる個人の寄せ集めではなく大きな 力を発揮するチームを作れる（ポジティブ、個別化、共感性、包含、成長促進、親密性、調和性、運命思考、適応性）
- 戦略的思考力：情報を取り入れ、分析し、より適切な判断を下せるようにします（内省、分析思考、原点思考、収集心、学習欲、戦略性、未来志向、着想）
私の診断結果・考察
私の診断結果は以下の通り。PDFをスクショして貼り付けている。
この診断結果から私は「プロセスを楽しむソロプレイヤー」なのかなと考えている。本当は認定コーチの方に専門的な分析を受けた方が良いのですが、まだ受講できていない。そのため、主観となるが、「プロセスを楽しむソロプレイヤー」と分析した理由は以下となる。
〇領域観点
上位１０位までに入っている資質の領域の数は以下の通り。
- 実行力：３
- 影響力：１
- 人間関係構築力：２
- 戦略的思考力：４
「戦略的思考力」がトップで、次点が「実行力」である。この２つで7割を占めている。情報を収集・分析してどう動くか判断して、物事を成し遂げるのが特に得意なようだ。人間関係構築に影響する「人間関係構築力」「影響力」は少ないため、マネジメントやリーダーはあまり得意ではないと思われる。３つはあるのでできないわけではない。
〇資質観点
上位１０位までに入っている資質を見てみる。
1. 学習欲：学習意欲が高く、常に向上することに駆り立てられます。成果よりも学習すること自体に意義を見出す。
2. 分析思考：理由や原因を追究します。状況に影響を与えるかもしれない全ての要素を考慮に入れる能力を備えています。
3. 目標志向：方向を定め、それに従い、道から逸れないように必要な修正を行います。優先順位を付け、そのとおりに行動します。
4. 内省：知的な活動を特徴としています。内観的で、知的な議論が好きです。
5. 収集心：収集し保管するニーズがあります。その対象には、情報、アイデア、芸術品だけでなく、人間関係も含まれる場合があります。
6. 慎重さ：意思決定や選択する際に細心の注意を払います。目の前に立ちはだかる障壁を予測します。
7. 成長促進：他者がもつ可能性を見出し、それを育てます。小さな進歩の兆候を見逃さず、その成長の証に満足感を得ます。
8. 活発性：アイデアを実行に移すことで物事を進めます。単に話すだけではなく、いますぐ実行することを望みます。
9. 親密性：他の人との親密な人間関係を好みます。目標達成のために友人と努力することから、大きな満足感を得ます。
10. 責任感：実行すると発言したことに対して心理的な責任感を持ち、誠実さや忠実さといった不変的な価値観を大事にします。
１０個の観点で見ると複雑になるので、さらに１～５と６～１０で分けてみる。
（）内は該当する資質
●１～５の観点で見られる得意な行動
・個人でも動ける資質が多く、単独行動ができる。（学習欲、分析思考、収集心、内省）
・目標達成に必要な学習及び情報収集を行い、達成させるための筋道を分析・思考し策定できる。（１～５全て）
・または、分析・思考した結果、今向かうべき目標を策定できる。（１～５全て）
●６～１０の観点で見られる得意な行動
・発言したことには責任感を持って、慎重に実行に移す。（慎重さ、活発性、責任感）
・親密な人間関係が構築しやすく動きやすい少人数チームだと成果を出しやすい。（成長促進、活発性、親密性）
最後に１～１０の観点で見てみる
●１～１０の観点で見られる得意な行動
・1on1のメンターもしくは少人数チームでのコーチングで、メンティーやメンバーを成長させることができる（分析思考、目標志向、収集心、慎重さ、成長促進、親密性、責任感）
〇まとめ
●「領域観点」で人間関係に影響する領域が少ないこと、「資質観点」でも一人でもできる資質が上位に多いことから、多人数で動くよりは一人で動くほうが得意だと見られる。
●「領域観点」で戦略的思考が得意なこと、「資質観点」でも目標達成までのプロセスを考えるための資質が多い。人間関係の資質も"親密性"・"成長促進"といったプロセス実施中の他人との関係性に特化した資質が多く、プロセス重視の兆候が見られる。
この２点から私は「プロセスを楽しむソロプレイヤー」なのかなと考えている。
私の資質の活かし方
資質の活かし方ですが、強み（≒才能）は"無意識のうちに頻繁に繰り返す思考、感情、行動のパターン"なので、すでに行えているもので改めて実行計画を詳細に考える必要はないと考えている。ただ、診断を受ける前と比べると、意識して動けてるようになっており、他者と役割分担をするときに何ができて、何ができないかをはっきりと伝えられるようにはなった。
とはいえ、１つ活かし方を上げると、強みを弱みを補うのに使っている。私の診断結果を見ると、３４位（最下位）にコミュニケーションがある。コミュニケーションは、"自分の考えを言語化し、他人に分かりやすく説明したり表現できる資質"である。この資質が最下位ということは、"他人に分かりやすく説明するのは諦めなさい"と言われているようなもの。とはいえ、他人に説明できないと生活は不便だし、仕事では非効率になりかねないし、評価されない原因になるので、上位の資質を使って以下の様なことをしている。
戦略：コミュニケーションを補うために、コミュニケーションが高い人の成果物を活かす。
具体的行動
・事前に「学習欲」「分析思考」「収集心」を使って、分かりやすく説明するパターンや語彙を書籍や動画とかなんでも良いので集め学ぶ。
・説明する場があると分かったら、前項で学習した内容と「目標志向」「分析思考」「内省」を使い、説明資料や文章を準備する。
・チームのときは「成長促進」「親密性」を使って、「コミュニケーション」が高い人を見つけて、説明をお願いするか教えてもらう。
まとめ
ストレングス・ファインダーの復習が目的でしたが、言語化することで自分の強みがはっきりと分かって良かったです。直近のミニセミナーでまた学べることがあるので、自分をアップデートしていきたい。
また、ストレングス・ファインダーで自分の才能を知ってみてもらえたらと思います。
追記（2019/3/24)
ミニセミナーに参加したのでご報告です。
こちらのミニセミナーに参加しました。
参加者は１１人（うち２人が認定コーチ）で老若男女問わず様々な方がおりました。
会場では、席が決めてありました。席には自分の上位５の資質が書かれている名札と参加者全員の３４の資質の一覧表があり、初対面の人たちと交流するのにあたり、資質によりあらかじめどの様な考え方・行動をする人か分かるようになっていました。
当日は以下の様なことをしました。
・自己紹介
参加者（１１人）がストレングスファインダーの経歴とこのセミナーでやりたいこと。
・診断結果の相談
各々の資質に関しての様々な相談と認定コーチによる強みの活かし方のアドバイス。
相談内容としてはこんなのがありました。
・診断結果上位の資質と自分が感じている資質に違和感がある。
・資質をどう活かせばよいか
・今後の働き方を考えているが、資質と合っているか。またどう資質を活かせばよいか。
私の相談は以下２つで、以下のアドバイスをいただきました。
①「私の資質の活かし方」に記載しているやり方で大丈夫か？
A.そのままで大丈夫。
②学習欲は結果よりもプロセスを重視する傾向があるので、目標達成しないままにならないか？（このときの目標達成は転職活動を指しています）
A．学習欲以外に内省・収集心及び慎重さが上位にあるため、一般的に情報が揃わないと動かないが、揃うと一気に動き出す傾向が高い。しかし、私の場合は上位にある目標志向の資質を使うことで、目標達成に向けて動くことができる。具体的には、短期的な目標（例：１週間に２～３社行く）を立てる。
・懇親会
予定にはなかったのですが、ミニセミナー終了後に翌日が祝日なのもあり、近くの居酒屋で参加できる人たちで懇親会を行いました。そこでは、プライベートなことも含めて、普段自分の資質がどの様な行動に出ているのか語りあったりしました。突発的なのもあり、お金の持ち合わせがなくて足りない分を出して頂いたUさん（誤ってたらすみません）には本当に感謝です。
私の感想ですが自己分析系セミナーは初参加で緊張しましたが、人の強み・弱みを表す共通言語を持ってるだけあって、初対面の人でもどのような思考・行動をするのか理解できるのですぐ打ち解けられました。資質の相談では、認定コーチの方から”そのままでいいよ”と返事を頂けたり、目標達成のためのアドバイスももらえて安心しました。また、他の人の34の資質を見て聞くのも面白かったです。
このセミナーで印象になった言葉は、認定コーチの方が仰っていた"(良い意味で)嫌なやつでいい"。他人に嫌われたくないという理由で、空気を読むとか何も言わないとかせずに、素直な自分を出した方が良いと私は解釈しています。以上！
参考
日本のストレングス・ファインダー関連のサイトだと以下がおススメです。
こちらの先生主催のミニセミナーに参加します。
本文中にもリンク貼りましたが、再度公式サイトのリンクを貼っておきます。
Knativeハンズオンをやってみた
1月上旬にKnativeハンズオンが公開されたので、発表当初から気になっていたのもありやってみた。ハンズオンでできることと、Knativeのことについてまとめておく。ちなみに、Knativeは当然だが、Kubernetesを触ってみたのも今回が初めて。
目次
Knativeとは？
Google Cloud Next'18で発表されたコンテナ実行環境上でサーバレスを提供するOSS。Kubernetesが提供しているカスタムリソース定義（CRD）を使ったAPI群とOSSのセットであり、Kubernetes上で簡易にPaaS/FaaS環境を実現できるようになるというもの。
背景
Knativeが出てきた背景は、以下にある記事を読むと、目的としてはサーバレスにおけるクラウドのロックイン回避と運用ロジック（API）の標準化。インフラ環境としてどこを使ってもよいが、その上で動作させるソフトウェアを運用するロジックは標準化（OSS化）させるべきという考えらしい。
Google Cloudは以前から、クラウドベンダーロックイン回避のため、GCPをいつ始めても止めても構わないという話もしているし、そのためにKubernetesも提供しているので、サーバレスにおいて似たような背景からKnativeを出したのは自然な流れだと思う。
できること
Knativeでできることは以下３種類のAPIで提供されている機能となる。
（Knativeハンズオンから引用）
ざっと読んだ感じ、今までGoogle App Engine、Cloud FunctionsやAWS Lambdaで提供されている機能を自前で用意しなくても、Kubernetesを使っていればAPIベースで簡単に使えるようになると読める。
直近の動き
Kanative関連の直近（2019/1/15)で大きなニュースは以下２つあり、Knativeを拡張した新たなサーバレス環境や既存FaaSの互換環境を提供するなど、サーバレス界隈の中心となっているように見える。
Knativeハンズオン概要
ここからハンズオンの内容に入る。実施にあたって、Kubernetesを動かす環境が必要なる。Googleのcodelabsだからだと思うが、GKEベースでのハンズオンとなっている。また、CLIもGCPのCloud Shellを推奨している。もし、他環境で試したい場合はGitHubのインストールガイドにドキュメントがある。また、Kubernetesの基礎知識と、できればIstioの知識もあると理解しやすい。
所要時間は、GKEとKubernetesを初めて触る私で３～４時間。ただし、コマンドの意味を知るために別の記事を読むなどの脱線を含めた時間。
codelabs.developers.google.com
ハンズオンで実施することは以下の通り。基礎知識の学習とKnative Eventingを除いたAPIの基本機能を試すことができる内容となっている。
- Knative概要と機能の学習
- Knativeインストール（Kubernetesクラスタ作成を含む）
- KnativeへのWebアプリケーションのデプロイ
- オートスケール機能利用とPodの監視
- Knative Servingを使ったBlue/Greenデプロイ
- Knative Buildを使ったビルドのテンプレート化
所感は後述するが、パブリッククラウドを使った場合はハンズオン後忘れずにKubernetesクラスタを削除しましょう。GKE未経験だったので詳しく知らなかったが、裏でGCEが動いており、放置するとノード数分課金されます。
Knativeハンズオンの一例
ハンズオンにある内容なので、詳細は割愛するが、インストールは以下のコマンドを使うことで実行できる。
Knativeインストール
１．Istioインストール
kubectl apply --filename https://raw.githubusercontent.com/knative/serving/v0.2.1/third_party/istio-1.0.2/istio.yaml
kubectl label namespace default istio-injection=enabled
kubectl get pods --namespace=istio-system
ハンズオンでIstioインストール後のpodの状態
username@cloudshell:~ (project name)$ kubectl get pods --namespace=istio-system
NAME READY STATUS RESTARTS AGE
istio-citadel-746c765786-bc8jd 1/1 Running 0 25m
istio-cleanup-secrets-bqchr 0/1 Completed 0 25m
istio-egressgateway-7b46794587-npc57 1/1 Running 0 25m
istio-galley-75c6976d79-8cb8h 1/1 Running 0 25m
istio-ingressgateway-57f76dc4db-pb5vz 1/1 Running 0 25m
istio-pilot-6495978c49-68j4t 2/2 Running 0 25m
istio-policy-6677c87b9f-mprxf 2/2 Running 0 25m
istio-sidecar-injector-879fd9dfc-r49wz 1/1 Running 0 25m
istio-statsd-prom-bridge-549d687fd9-d64sd 1/1 Running 0 25m
istio-telemetry-7d46d668db-2df7p 2/2 Running 0 25m
２．Knative(Serving&Build)のインストール
kubectl apply --filename https://github.com/knative/serving/releases/download/v0.2.1/release.yaml
kubectl get pods --namespace=knative-serving
kubectl get pods --namespace=knative-build
ハンズオンでKnativeインストール後のpodの状態
username@cloudshell:~ (project name)$ kubectl get pods --namespace=knative-serving
NAME READY STATUS RESTARTS AGE
activator-db79694db-lnjfv 2/2 Running 0 6m
activator-db79694db-n4hds 2/2 Running 0 6m
activator-db79694db-tbw9k 2/2 Running 0 6m
autoscaler-86d954bffc-hznf5 2/2 Running 0 6m
controller-5cc6f8cc95-rzm6k 1/1 Running 0 6m
webhook-654c8d7bff-kcdqm 1/1 Running 0 6m
username@cloudshell:~ (project name)$ kubectl get pods --namespace=knative-build
NAME READY STATUS RESTARTS AGE
build-controller-79d6cc9d57-j2vhd 1/1 Running 0 6m
build-webhook-f97d479f9-mdt27 1/1 Running 0 6m
所感
ハンズオンをやってみて、以下の様に感じた（薄い感想）。
- GAEでできること(Blue/Greenデプロイ）が、環境を選ばずに簡単に準備できるのは便利そう。
- GKEを使ってKubernetesクラスタを構築するの簡単だった（Knative関係ない）。
- Knative環境には、複数のサービスが動いており、リソースと運用が大変そう。（Kubernetes、Istio以外に、監視サービスのためにPrometheusとGrafanaがデフォルトでインストールされ動作している。）
次やってみたいこと
- Kubernetesのハンズオンと学習（時間あれば程度）
- Knative Eventingのサンプル実施
「エンジニアリング組織論への招待 不確実性に向き合う思考と組織のリファクタリング」の所感と備忘
年末、ようやく読み終えた。SNSのITエンジニア界隈で流行っているのと、カイゼン・ジャーニーを読み終えたところで次に読むマネジメント系の本としてちょうど良いと思い、Kindleで10月下旬から読み始めた。冒頭から個人的に学門的な観点で踏み込んでおり小難しいなと感じましたが、最後まで読んで、自主的に動ける人・組織へ成長させるための知識・技術及びIT技術と組織の結びつきが（完全ではないが）理解できたと思う。また、その様な内容だったので、エンジニアに限らず、社会人であれば読んだほうが良いと思う。
本書は全般的に学びのある内容だったが、その中から個人的に印象があった部分をまとめておく。
１．Chapter.2の「課題の分離」
こちらは学びというより、過去に得た知識を思い出したのと、再認識できた内容になる。本書では、メンティが抱える問題を傾聴するときに、その問題は本当に自分の課題なのか、他者（他チーム）の課題なのかを切り分けて、問題の対処をする必要がある。また、メンターもメンティの問題を「自分の課題」とは捉えて、メンティの課題を解決してはいけない。というものです。
この内容を読んだときに、数年前に読んだ「嫌われる勇気」の内容（アドラー心理学）にあった「課題の分離」を思い出した。当時は、心理学の知識と捉えたのと他事情で、仕事に適用させるところまでは考えられなかったが、心理学を具体的に活かす方法として知れてよかったと思う。
２．Chapter.3 の「プロジェクトマネジメントとプロダクトマネジメント」
こちらは、プロジェクトマネジメントとプロダクトマネジメントの違いを書いた部分となり、以下の様に書かれていた。
・プロジェクトマネジメント
・プロジェクトを「終わらせる」ためのマネジメント
・最大のリスクは「終了しないこと」
・プロジェクトマネージャーは「スケジュール不安」を減少させるために動く
・プロダクトを「終わらせない」ためのマネジメント
・最大のリスクは「終了すること」
・プロダクトマネージャーは「マーケット不安」を減少させるために動く
一番の違いは"終わらせる" or "終わらせない"という部分であるように思うし、違いを的確に表した文章だなと感じた。プロジェクトマネジメントの案件の経験を振り返ると、納品日または本番稼働日に向けて、計画されたタスクを全て終わらせるために動いているんだと気づくことができた。また、納品日または本番稼働日までにタスクが全て終わるかどうかの不確実性を「スケジュール不安」と呼び、プロジェクトマネージャーは「スケジュール不安」を減少させるために、品質・タスク・ステークホルダー・スコープなどPMPに定義されているマネジメント要素を管理・調整させていると認識できた。
プロダクトマネジメントの方は、経験がない（似たようなのはあるが）ので知識の取得に修まっているが、プロジェクトマネジメントとは全く動き方が異なるマネジメントであると分かりやすく理解することができた。
３．Chapter5.「技術組織」の力学とアーキテクチャ
こちらは一つの章全体となる。現在、職種はシステムエンジニアだが、チーム内でITアーキテクトに近い役割を担っている。個人的なITアーキテクトの定義は「ビジネス課題を解決するためのITシステムのアーキテクチャの策定・実行、またビジネスアイデアを実現させるためのITシステムのアーキテクチャの策定・実行」としているが、経験が浅いのもあり、ビジネスとITシステムの紐づけができていない。しかし、この章を読むことで、組織とITシステムの紐づけについて得るものがあった。例えば、言葉だけ知っており意味を知れていなかった「コンウェイの法則」「技術的負債」を知ることができた。
「コンウェイの法則」は次のようなものと書かれている。
システムを設計する組織は、その構造をそっくりまねた構造の設計を生み出してしまう
具体的には、組織構造から発生するコミュニケーションコストの高さにより、高い部分の機能追加は行われず、低い部分の機能追加が優先して実装されてしまうというもの。コミュニケーションコストを避けた機能追加で本質的な問題解決になる場合は良いと思える。ただ、そうでない場合は小手先による問題解決となり、追加された機能は"秘伝のタレ"として残り、システム全体のリプレイスやマイグレーション時の計画時に見逃されて、ユーザーテストで発覚して問題になる気がする。
でも、現実はリソースと納期の都合上、できる範囲（なるべくコミュニケーションコストを抑えて）での機能追加は観測できる範囲では多いので、コンウェイの法則は避けられない事象なのであると思う。
「技術的負債」という言葉自体は、コンピュータ技術者ウォード・カニンガムによって1992年に提供された概念であり、経験レポートで次のようなものと語っている。
最初のコードを出荷することは、借金をしに行くのと同じである。小さな負債は、代価を得て即座に書き直す機会を得るまでの開発を加速する。危険なのは、借金が返済されなかった場合である。品質の良くないコードを使い続けることは、借金の利息としてとらえることができる。技術部門は、欠陥のある実装や、不完全なオブジェクト指向などによる借金を目の前にして、立ち尽くすはめになる。
品質を犠牲にして開発を進めていくと、徐々に機能追加が困難なシステムとなり、コミュニケーションコストが増えていくことになると認識し、「コンウェイの法則」の延長上にある１つの状態だと感じた。こちらも避けにくい事象なのではないかと感じたが、本書ではフィリップ・クルーシュテンの４象限の定義により技術的負債は「見えないマイナスの価値」であるとしている。それならば見えるようにすれば良いと考えるが、直感的に簡単ではないと感じたし、見えるようにするためのコストをどうするかも考えないといけないが、本書にはそのためのヒントも載っているので、必要性が出てきたときに再読したい。
ここからは備忘として、Chapterごとに私が記録しておきたいところを、箇条書きベースでまとめておく。途中で力尽きて消そうかと考えたが、再読するときのことも考えて残しておく。
Chapter1.思考のリファクタリング
・「エンジニアリング」は「不確実性」減らす行為
→具体的にいうと、「曖昧さ」を減らし、「具体性・明確さ」を増やす行為
→「曖昧さ」は経済学や社会学の分野では「不確実性」と表現される
・仕事は「複数人」「情報があるかわからない」「答えが決まっていない」もの
・仕事が上手く進まない理由として、論理的思考の盲点。
→人は感情的になる。認知能力の限界、立場などによりコミュニケーションが失敗し、情報を正しく扱えなくなる。
・仕事では「経験主義」と「仮説思考」を使って答えに近づく
経験主義：行動を起こした結果で得た情報から問題解決を行う
仮説思考：限定された情報から想定した全体像を確かめる思考様式
・システム思考：仕事の正解を自ら設定する思考様式。限られた時間と資源の中で答えに近づくために必要。
・理性主義と経験主義
理性主義：「前提」から演繹的に世の中を説明する考え方。
・ウォーターフォールの「設計主義的プロセス」も、理性によって、設計主義的にソフトウェアをくみ上げることが可能であるという前提のプロセス
・スクラムは「経験主義的プロセス」。「スクラムガイド」に経験主義に対して言及がある。
・経験主義的発想では、「分からなかった」「正解ではなかった」も重大なヒントであり、次の行動を生み出す。
・仮説思考
・新しい諸概念を導入する唯一の論理的操作
・わずかな痕跡から説明可能とする大胆な思考展開・モデル化を行い、それを検証するための行動につなげる
・経験主義をさらに生産的なものにするための「大胆な跳躍」をもたらす
・仮説を検証するためのサイクル
・仮説を明らかにする＆検証できるのかというアイデアを持つこと
・リアルオプション戦略
・「遅延した意思決定」を行うための戦略
・小さく投資・失敗をして成功の確率を上げていくこと。巨額の投資判断による失敗を防ぐための考え方
・問題の解決と問題の明晰化
・問題の明晰化のほうが難しく、重要
・すぐ解けない問題は、問題が明晰ではない。問題をはっきりさせるために仮説検証をする思考に切り替える
・不確実性
不確実性の詳細
・環境不確実性：未来に関すること。経験主義・仮説思考で減少させる
・通信不確実性：他人に関すること。コミュニケーションで減少させる
・情報の非対称性：人により持っている情報が異なること。
・限定合理性：人の認識できる範囲でしか、合理的な行動をとれない。
Chapter2.メンタリングの技術
・メンタリングは思考のリファクタリング
・メンターの由来は、古代ギリシャ神話。おでゅせうす王の息子を立派な王に育てた賢者として伝承された「メントール」にちなんで。
・「自ら考える人材を作る」ためのテクニック
・自立型人材：自ら問題を発見し解決することができる。問題について、自分事として捉えている
・依存と自立の境界線：上司と部下の関係における期待値の違い。同じなら問題なし。違うなら問題あり。
・コンフォートゾーン：役割の中で、自分が「心地よく」いられる思考の範囲や行動の範囲
・学習性無気力：自立的な活動に対して、否定され続けた結果、生まれた無気力。
・自己効力感：自立的な活動に対して、肯定され続けた結果、生まれる感覚。
・自己効力感がコンフォートゾーンを上回るようにメンティを導くこと
・効果的なメンター/メンティの関係性
効果的な関係性を築くための条件
・謙虚：お互いに弱さを見せられる
・敬意：お互いに敬意をもっている
・信頼：お互いにメンティ（自身）の成長期待をもっている
それぞれの頭文字をとって、「HRT」と呼ばれる
・メンティの成長を手助けするために
・他者説得から自己説得に：自分で課題と答えを見つけさせる。
・他人が質問で促す
・体感を伴う
・行動の変化が発生しやすい
・悩むと考えるの違い
・悩むは状態
・考えるは行動
・前者は他人が観測できないが、後者は観測できる
・傾聴・可視化・リフレーミング
・悩むから考えるに移すためにメンターができる行動
・課題の分離
・ある問題は誰にとっての課題であるのか、はっきりさせること。
・他人の課題か自分の課題かで行動が変わる。
・心理的安全性
・「対人リスク」を伴う行動が増えている状態のこと
・それで、よくするために「問題に対して向き合う状況」を生み出している。
・ラーニングゾーン：心理的安全性が高く、責任も高い状態。メンティが目指す位置。
・メンタリングでは"メンティの弱さ・失敗を開示してもらう"、自分の弱さ・失敗を開示する状況を作りあげる必要がある
・メンターは、成長物語から弱さ・失敗を開示する
・行動を観測する
・メンティの行動は見れるが、内心は見れない
・「SMART」な行動
・S:具体的な
・M:測定可能な
・A:到達可能な
・R:関連した
・T:時間制限のある
・ゴール認識
・行動変化に至らせるためのゴールのレベル
0:願望
1:義務
2:欲求
3:意思
4:必然
Chapter3.アジャイルなチームの原理
・アジャイル開発は、チーム全体に対してメンタリングを行い開発出力を向上させる方法論
・「ソフトウェア開発を行うチームをどのように構築していくか？」がアジャイルの目的
・アジャイル開発が必要となった理由
・ソフトウェアが大規模化・複雑化
・マーケットの不確実性に対応する
・アジャイル開発は3倍の成功率、1/3の失敗率
・プロジェクトマネジメントとプロダクトマネジメント
・プロジェクトマネジメント
・プロジェクトを「終わらせる」ためのマネジメント
・最大のリスクは「終了しないこと」
・プロジェクトマネージャーは「スケジュール不安」を減少させるために動く
・プロダクトを「終わらせない」ためのマネジメント
・最大のリスクは「終了すること」
・プロダクトマネージャーは「マーケット不安」を減少させるために動く
・スケジュール不安：やってみないとできるか分からないという不確実性（方法不確実性）に依拠する
・マーケット不安：やってみないとマーケットに受け入れられるか分からないという不確実性（目的不確実性）に依拠する
・スケジュールとマーケットの２つの不安
・ウォーターフォール的な計画駆動は、スケジュール不安のみが前提となる
・初期計画で精度を高める。変化に弱い。
・アジャイル開発は、スケジュール不安とマーケット不安の両方がある。
・実験的に徐々に精度を高める。変化に強い。
アジャイルな状態
・情報の非対称性が小さい
・認知の歪みが少ない
・チームより小さい限定合理性が働かない
・対人リスクを取れていて心理的安全性が高い
・課題・不安に向き合い不確実性の削減が効率よくできている
・チーム全体のゴール認識レベルが高い
個人がアジャイルになり、他の人もアジャイルになれば、チーム全体が自然とアジャイルになる。
・ウォーターフールとアジャイル
・ウォータフォールの範囲
・方法不確実性（スケジュール通りに終わるか）
・目的不確実性（マーケット（客）に受け入れられるか）
・アジャイルの範囲
・上２つ
・通信不確実性（継続するチームマネジメント）
・スクラム
・振り返りのためのフレームワーク
・Whatに関する学習ループ：顧客に届けるものの検証
・Howに関する学習ループ：現場の改善「計画」「振り返り」
Chapter4.学習するチームと不確実性マネジメント
・不確実性マネジメントで管理する不確実性と管理手法
・方法不確実性：スケジュール予測と見積もりの手法
・目的不確実性：要求と仮説検証の手法
・通信不確実性：振り返りの手法
・スケジュールマネジメント
スケジュールマネジメントで見積もる３要素
・理想工期：工期人月/人数
・制約スラック：作業同士の依存関係による無駄な時間
・プロジェクトバッファ：見積もりの不確実性を吸収するための期間
これらに注目して改善を行い、リリース時期の精度を上げるのがスケジュールマネジメント
・プリンシバル・エージェント理論
経済における人間関係を「依頼者」と「代理人」との契約の束としてとらえる考え方
・エージェンシートラック：依頼者からみて、代理人に嘘をついたほうがメリットがあると思うことで、適正価格よりも費用が高くなるときの差額のこと
・コントロールコスト：依頼者の利益が、代理人の利益になるように監視やインセンティブの形で支払う必要があるコスト
・シグナリングコスト：「情報をもつ側」が情報を開示し、非対称性を解消するために支払うコスト
・マーケット不安
・時間境界型プロジェクト：特定時期（クリスマス商戦など）に向けた機能のリリースをするプロジェクト。この時間境界を「納期」と呼ぶ。
・機能境界型プロジェクト：ある機能のパッケージが固まってリリースしないと仮説検証にならないプロジェクト。この機能のラインのことをMVPと呼ぶ。
・スコープバッファ：機能境界型プロジェクトによる当初計画した機能とMVPの差
・リリースポイント：機能が完成して提供できる瞬間。また、プロダクトオーナーや経営者が初めてプロダクトを触って機能を確かめられる瞬間。触れられることで、初めて目的不確実性が減少する。そのため、リリースポイントはなるべく遅らせず、早めにしてもらうほうが生産的。
・ユーザーストーリー：各種機能の分解方法。サービス全体がある顧客にとっての物語になるように分解する。
・どのような人が
・何ができる
・そのことでどのような感情になる
・INVEST:チームが開発作業を開始するおにちょうどよい粒度のストーリーになっているか判断するフレームワーク
・リーンキャンバス：仮説を明らかにするフォーマット
・スクラム
不安への向き合い方をチームが学習するための方法論
役割
・プロダクトオーナー
・開発チーム
・スクラムマスター
イベント
スプリントの間に行うイベント
Whatの検査、Howの検査、日々の検査ができるようになっている
・スプリント計画
・デイリースクラム
・スプリントレビュー
・レトロスペクティブ
・ゴール設定
インセプションデッキ：ゴール認識を合わせるためのフレームワーク
Chapter5.技術組織の力学とアーキテクチャ
・労働生産性はビジネスの結果を分析する手法。
・偶発的にうまくいった場合も、必然的にうまくいった場合も区別なく計算される。組織内部を考察するには、あまり向いていない。
・必然的にうまくいった、いかないを分析できたほうが良い。
例：１枚の宝くじで当たるか祈るよりも、いくつ宝くじを買うことができるか
・不確実性を効率よく仮説検証する能力だと言いかえれる（投資規模やリソース？）
・不確実性の削減≒情報を生み出す。不確実性を削減できる力≒企業の情報処理能力。
・ガルブレイスの組織情報処理モデル
・保有するシステムを含む組織形態から、企業の情報処理能力が決定し、対象となる市場の不確実性から、必要な情報処理量が決定する。
・情報処理量に対して、企業の情報処理能力が上回れば「組織成果」につながる。
・エンジニアリングの不確実性とのつながり
目的不確実性：情報処理必要量（戦略）
方法不確実性：情報処理能力（戦術）
通信不確実性：情報処理能力（兵站）
・個人の総和が組織の能力にならない
・組織が完全な能力を発揮するのには組織内で行われるコミュニケーションが100%の完全な情報伝達が必要。
・実際は不可能で、人数が増えるほどコミュニケーションの失敗が発生する。
・理想的な情報処理能力の推移と、現実の情報処理能力の推移の差を埋めるのが「コミュニケーションコスト」
・組織のコミュニケーションネットワークはプリンシバル・エージェント関係
・組織とシステムの関係
・システムの構築を行う組織
情報処理のモデルで考えると、経営層が市場の不確実性を判断し、ビジネス部門が戦略を練り、開発部門が具体的で必要なシステムに落としていく。階層構造になる。
・開発部門は実現フェーズに近い組織
・コンウェイの法則：システムを設計する組織は、その構造をそっくりまねた構造の設計を生み出してしまう
・コミュニケーションコストが高い組織になるほど、コミュニケーションを避けるために実現性の高い機能を重点的に開発が効率が良いと判断するようになる。
→部分最適解のシステムになったり、経営層が気づかないまま組織設計上の問題が組み込まれることになる。
・エンジニア組織のアンチパターンへの処方箋
・組織全体のコミュニケーションの改善
・個々人：Chapter1
・マネジメントとメンバー、メンバー同士：Chapter2
・チーム：Chapter3,4
・組織と権限
情報処理能力の高い組織
・責任と権限が一致している
・不一致が生じると、認識している権限が違うという「情報の非対称性」により情報処理能力が低下する。
・権限を委譲できている
・権限が一人に集中すると、その人の情報処理能力が、その組織のボトルネックとなる。
・具体的な指示がないと動けない。マイクロマネジメント型組織
・抽象的な指示でも動ける。自己組織化された組織
・デリゲーションポーカー
・権限移譲のレベルをメンバー間で合意を楽しみながら作れる手法
・技術的負債
・アメリカのコンピュータ技術者であるウォード・カニンガムによって、1992年に提唱された概念
・追加開発により、徐々に初期の設計から逸脱することで追加開発工数が増えていく状態。
・技術的負債を抱えたシステムは、積み上げていくにつれバランスが悪くなったジェンガと似た状態
・なり得る要素「無鉄砲な/慎重な」「意図的な/無意識の」の４象限
・慎重で意図的：リスクより、リリースを優先
・慎重で無意識：たぶん大丈夫
・無鉄砲で意図的：設計する時間がないので、雰囲気で作る
・無鉄砲で無意識：設計方法がわからないので、雰囲気で作る
・見ることができないもの
・技術的負債は、見えないマイナスの価値
#bq_sushi tokyo #9 2018総集編に参加してきました
11/30、BigQueryのユーザ会であるbq_sushi主催の勉強会に参加したのでその内容と感想のご報告です。仕事でもプライベートでもBigQueryを触ることがあったので、前々から参加してみたかった勉強会です。
概要
今回の勉強会では、今年発表された新機能であるBigQueryMLとBIgQueryGISの実際に活用されている方による事例及び所感の発表、そして登壇者によるBigQueryのパネルディスカッションがありした。
BigQuery GISを用いた物件レコメンド
・スピーカー：中川帝人さん（株式会社オープンハウス）
・内容
自己紹介
・スピーカーさんは現職には入社10カ月目で情報システム部所属。経歴はずっとデータ分析の仕事。BigQuery歴6カ月。現職で使っているクラウドは主にGCP。
GISについて
GISは地理情報システムの略。専門的なツールもあるが高い。有名なのはPostGis。
・GISのツール
QGIS:オープンな地図情報システム
(あと1つ紹介がありましたが誤って名前でメモしたため分からない）
・地理情報の形状は、楕円形だったり多角形だったりするらしい。
・フォーマットは".ship"が有名
PostGisについて
PostgreSQL（以下、ポスグレ） の地理空間情報機能拡張。多様な測位や関数をつかえる*1
・課題：メモリや一時利用ファイルがすぐ枯渇する。リソース調整や拡張を（すぐに）できないから。
地理情報の精度について
・求められる制度は要件により異なる。
・物件だと、地価に影響するため測位結果が１ｍ単位の精度が求めらえれる。
・世界表標準の世界測地系を国内の住所判定で使うと、郵便番号が１個ずれるぐらいは普通に発生する。
BigQuery GISの活用事例
導入箇所：物件検索レコメンドの物件スコアリング集計。検索内容に対して、マッチしている・買ってくれる可能性が高い物件をレコメンドしたい。
業務について：オープンハウスさんは家を建てて売る会社（パワービルダー）であり、Webサイトで物件検索・販売も行っている。
物件検索で見るところ：ユーザはほぼ場所で見たり、検索してくる。ただ、以下の様な事例で曖昧に場所を検索してくることもあり、正確なインプットやアウトプットが難しい。
①憧れ：実際は買えないけど、憧れの場所も検索範囲に含めてくる。
②緊急度が高い：Uターンや転勤などの理由で、すぐ買える家を広範囲に指定してくる。
BigQueryの活用：
・既存のポスグレと併用しており、ポスグレの座標データをpythonで書いたETLでBigQueryへ流している。座標データは日々手メンテするため、更新しやすいポスグレはそのまま利用している。
・集計に使うデータは物件検索に使われているデータ
・レコメンド：複数条件から最も適合する物件を出している。
・スコアリング：１次元回帰で予測モデリングをして、スコアリングしている。
＊他にもあるようでしたが、主題からずれるのと業務にかかわる部分なのでこのぐらいだっと思います。
・SQLの性能：BigQueryといえどテーブル結合方法によっては遅かったり、落ちたりする。GISはもともと処理が重くなりやすいというのもある。今まで２、３回ぐらい落ちている。with句を使うなどして調整した。
所感
Good:とにかく集計できる。処理によるが早い。
リスク：
・取り込み時にデータを確認すること。ポスグレで入れることができても、BigQueryには入らない不正データがあったりする。
・バグがある。よく分からないが何か引っかかった。
ユースケース
〇：スマホアプリからの収集した大量の位置情報ログの集計
×：精微なポリゴンデータ
×：高精度な処理（測位図や超広域データ）
本題に入る前に、GISの基礎知識やサービスの紹介があったのは、私もGISの基礎を知らないので良かったです。住宅業界ならではの事例とBigQuery GISのユースケースがあったのも今後利用を検討するときの参考になります。
BigQuery ML を使ってみた話
・スピーカー：Wantedly 松村 優也さん (@yu-ya4)
・内容：
自己紹介
Wantedlyで検索・推薦を担当するエンジニア。所属するレコメンドチームは2名。
また、Data Driven Developer Meetupを運営している。
サービス紹介
Visit：企業に気軽に話に聴きに行くためのマッチングサービス
People：名刺サービス
BigQuery ML紹介
・Google Cloud Next'18で発表されたサービス
・BigQueryでSQLを使ってMLができる
・BigQueryで完結するので手軽
・現在サポートしているモデルは３つ
1.線形ロジスティック回帰
2.二項ロジスティック回帰
3.多項ロジスティック回帰
＊当発表とは関係ないですが、今後ランダムフォレストに対応予定とDogrunで話がありましたね。
なぜBigQueryMLを使ことにしたのか
BigQueryを使う基盤・推薦環境がある
BigQueyを使い慣れている
使えそうな問題があった
チームの事情
人数が少ない、時間があまりないため小さい改善を素早く繰り返す必要があった。
レコメンド基盤にはやり方がいっぱいあるが、時間がかけられないのでBigQueryにすることで、改善を素早く繰り返せる。
活用した問題
１日２回ニュースのプッシュ通知を送ってもよいユーザーを探す。
過去約１カ月のユーザーの行動データから説明変数を作り、１日前に２回プッシュ通知に反応したユーザーを当てるモデル作成。
結果、プッシュ通知の開封率が大きく改善（無駄なプッシュ通知を減らした）
身近な問題にBigQueryMLを使ってみた事例でしたが、成果も出ており有用性があるのが分かります。MLを使える基盤・データがあるからすぐできるのは、自社サービスでデータを収集できていることによる利点だなと思います。
bq_sushiパネルディスカッション
スピーカー：セッションを行った２人
内容：参加者からの質問回答形式。
覚えている質問を何点か記載。
１．Q.MLの料金が変わるが使い続けられるか？
A.以前は何度もモデルの作り直しをしていたが、新しい料金体系ではコストがかかるようになるため、考えてモデル作りをしないといけないと思う。
２．Q.クラスタリングテーブルの実例はあるか？
A.（会場にいたsimetalさんから）merpayでも実例はない。中間テーブル作成に使うことができるのではないか。
懇親会
個人的に初めてのことがあったので懇親会のこともメモします。隣の方とBigQueryについてお話していたのだが、なんか話が合わない感じがしたので、所属会社について尋ねたらマーケティング系企業の方でありエンジニアでなかった。今まで参加した勉強会ではエンジニアの方としかお会いしていなかったので衝撃的で、BigQueryの勉強会だと、昨今のビジネスへのデータ活用が流行っているためか、非エンジニアの方もいらっしゃるのかなと思いました。BigQueryがどのようなものか知るために参加したらしく、私からも知っている範囲でご紹介をしています。また、２人に聞いた話ではTresureDataを使っているが、定額制なのを良いことに、性能が悪いクエリが特定の時間帯に集中して何度も投げられるため、高負荷となりレスポンスが悪い。もう１人の方はsplunkを使っているが、年間数千万円と高いので代わりがないか探していると課題を聞くことができる貴重な機会でもありました。
初めてのbq_sushiでしたが、新機能を使いこなしていることの羨ましさと有用性を感じることができたのと非エンジニアの方と話す貴重な体験があったので良かったです。スタッフとかやってみたいですね。
