質問をストーミングする「Qストーミング」

アイデアを出したり、課題について考えたりするとき、ブレインストーミングはごく一般的に使われていると思います。

ブレインストーミングのメリットは、グループでアイデアを出すことでアウトプットの質が高まることです。

Q思考 シンプルな問いで本質をつかむ思考法 は、「質問」を仕事や生活に生かそうという内容の本ですが、この本によると、ブレインストーミングにも弱点があるそうです。

1. 他人がいることがプレッシャーになり、つい当たり前な結論に収束しがち
2. アイデアが発散しすぎて、収拾がつかなくなる

確かに思い当たる節はありますね。

この本で代わりに紹介されているのが、質問をストーミングする「Qストーミング」です。

Qストーミング

このQストーミングは、実際に研究も進んでいるそうで、この方が良い結果につながるという研究もあるとのこと。

理由としては、

• アイデアを出すより、疑問を出す方が簡単
• 疑問、質問は他人の評価を受けにくい（プレッシャーになりにくい）
• 間違った問いに答えようとするのを避けられる

ということです。

やり方はシンプルです。ブレインストーミングの要領で、アイデアの代わりに質問をどんどん出すことです。

進め方の方針としては、

• とにかく数を出す（５０〜７０くらいらしい）
• クローズド<=>オープンの変換を繰り返し、質を高める
• 討論を通じて、「ベスト・クエスチョン」（２〜３個）を決める

良い質問があると、調べてみたくなるのが人間心理だそうで、そういう質問を見つけるのがゴールだそうです。

まずは一人でやってみました

ミーティングなどで使う前に、どのような感じかやってみました。

1. テーマを用意
2. 10分くらい質問をストーミング
3. 出した質問をブラッシュアップ

最初こそ、ちょっと出しにくかったですが、すぐにたくさん出てきました。

一つの質問を出すと、それについて考えて、さらに質問が湧いてきます。新しいことを知ると、頭の中で次々疑問が湧いてくるのと同じ感じです。それを書き出していくと、頭の中で考えてるよりも、堂々巡りにならず、どんどん先に進んでいきます。

そのテーマについて、多角的に考えることになるので、その問題自体に対する理解が深まりました。的確な質問をするには、問題のポイントをつく必要があるので、その問題自体をよく考えることになります。それだけでもかなり効果はあると思います。

普段なかなか答えが出しにくいような問題に向いていますし、アイデアが煮詰まった時など、一人でやるのもオススメですのでお試しください。

Google DevFest Tokyo 2016 に行ってきました

1000人を超える申し込みがあったようで、午後から雨が上がったこともあり、かなりの人出でした。

DevFestはこんな感じのイベントです。

DevFest は、Google Developer Group (GDG) コミュニティによって世界各地で開かれるデベロッパー向けイベントです。DevFest Tokyo 2016 は、普段は別々に活動している複数のコミュニティが集まり、新しいノウハウや最新情報を共有するだけではなくコミュニティやプロダクトを超えた交流の場となる「技術者の祭典」となることを⽬指して開催されます。どうぞみなさんも一緒に盛り上がりましょう！

対象はどちらかというと、初心者向けと、最近のGoogleの動向が多かったです。 各発表が基本20分だったので、一通り表面をなぞるのにはちょうど良かったです。

Android関連が半分以上あり、特にFirebaseの話題が多かったです。

普段GCPしか触ってないので新鮮でした。

GCPはGCPUGが1会場を通してやっていました。

気になった話題

ざっくりですが、気になった話題です。GCPばかりです。

• GCPのIaasの強化
  • サブネット対応
  • Google Cloud SQL v2
• GCEでPerconaクラスタ最強説
  • インスタンスは安いし、性能は良いし、Perconaならクラスタリングも楽。
  • バックアップなどの運用系は用意する必要あり。
• Cloud Machine Leaning
  • Tensorflowのマネージド
  • 別の環境で学習させたTensorflowのモデルをそのまま使える
  • これまでクラスター立ち上げてた必要がなくなるか?
• プリエンティブルVM
  • GAE + キュー+ プリエンティブルでクラスター作れば、安価にかなりのコンピューティングができる
  • Firebaseと組み合わせれば、モバイルのサービスに。
• GAEが枯れてきた
  • GAEの機能強化は落ち着いた。
  • GCPの各種サービスとの連携は強化。
  • GCPのフロントとしての地位を固めてる。
• GKE
  • 最小構成(3台)でも十分使える。
  • 構成管理もまとめてできるのが良い。

日本Androidの会

基本、GCPの話ばかり聞いてたのですが、このセッションだけ、Androidの話を聞きました。

Androidは随分裾野が広いですね。 教育の話は、実践の中で作り上げたプラクティスの話でした。

例えば、「他人に教える」が最も教育効果が高いとかの話は聞いたことある方が多いと思いますが、それを実践して、さらに、ならではのノウハウを取り入れているのでとても参考になりました。

エンジニアのスキルアップといえども、楽しいというのは重要ですね！

ROOM A 15:30-16:10

TensorFlow on Android
古川 新
日本Androidの会 学生部

メイドさんと一緒に楽しく学ぶ、ソフトウェア技術者教育方法論
鈴峰 きり
日本Androidの会 /株式会社テクモード

全て参加費無料ということで、各ユーザグループと電気大の学生さん？のボランティアの方がかなり参加していたようです。このような大規模なものになると相当大変かと思います。ありがとうございました!

GCPUG Beginners Tokyo で LTしてきました。

先週の金曜日(2016/10/7)に渋谷道玄坂のロフトワークさんで行われたGCPUG Beginners Tokyo #1でLTしてきました。

当日は、GASエキスパートのサントリーさん（@soundTricker318）が、メインのハンズオンを担当され、その後の懇親会のLTセッションの一人として参加しました。

GCPを使い始めた方が対象のハンズオンということで、bdutil を使ってクラスター構築など試してはどうでしょうか？という内容で話してきました。

資料は、SpeakerDeckで公開しています。

bdutilで3d大Hadoopディストリビュータイッキ試し

bdutilとDataProc

サントリーさんに、「bdutilの日本語情報はほとんどないので貴重なLT笑」とおっしゃっていただいたり、LTの後には、DataProcとbdutilどちらがいいの？という話にまで発展したりと会を盛り上げるのに多少なりとも役に立ったようでよかったです。

その時の話をまとめると、Hadoopクラスタをマネージド的に使いたい時はDataProcで、Iaas的に使いたい時は、bdutilが良いというところです。

DataProcは、Googleの各種サービスをフル活用したクラスターを立ち上げることができ、スムーズにアプリが完成するのに対し、bdutilは、簡単にディストリビュータの提供するHadoopクラスタが立ち上がりますが、それを使って何をどうするかは、ユーザに任されています。

Hadoopsディストリビュータのそのままのクラスタが欲しい時や、既存のDataProcでは、対応できないレベルのチューニングやアーキテクチャを採用したい時はbdutilの方が向きそうです。

ハンズオンのクオリティが半端なかったです

ハンズオンの資料(一部GCPの入門用の資料参照)が非常に秀逸でした。

Google Cloud Platform ハンズオン

簡単スタートアップガイド

多少画面が変わっているとかはあったのですが、とにかく１ステップ１ステップが丁寧で、はまりようがないと言っていいくらいわかりやすいものでした。

今回のテーマである、GoogleCloudComputingの他にBigQueryなども含んだ資料ですが、総ページ数は、300ページをに迫る分量です。

チューターとして待機していたのですが、サントリーさんのインストラクションのうまさもあって、ほとんど出番がない状態でした。

新しい技術をスムーズに導入するのは、相応のコストがかかりますが、しっかりやれば、必ずしも難しいものではないと思えました。

GCPUGの皆様のおかげです！

GCPUGさんのイベントにスタッフ参加したのは初めてでしたが、初心者の方でも気楽に参加できるゆるい雰囲気があってよかったです。

また、当日参加された方向けの無料クーポン（60日無料トライアルとは別のものです）が用意されていたりと至れり尽くせりでした。

GCPUGの皆様、特にこの会の発起人の安藤さんのおかげで、GCPを使ってみようという方がまた増えたと思います！

AWS Lambdaで既存のコードを走らせる時に検討したいこと

既存のコードをLambdaで走らせる際に、検討すべき項目をまとめました。

既存のコードを持っていこうとすると、「Java/Pythonだから、そのまま動くでしょ?」逆に、「既存コードは全部書き換えないとでつらい」の中間くらいの手間になります。

実際には、全体的な構成を変える必要があるので、新しく作り直す方がいいと思います。

ですので、以下は、どうしても既存コードを持っていく必要がある場合のみご参考に。

Lambdaの特徴

立ち位置

• dockerなどコンテナーは、サービス単位で起動できるが、lambdaは、プログラム単位で起動できます。
• マネージドなコンテナーの機能限定版と言えます。

コーディングはロジックに集中できる

• Pythonの実行環境設定など、すべてLambdaがやってくれるので、ロジックに集中できます。

awsのイベントベースを学ぶ必要がある

lambdaを活用するなら、awsのイベントベースのやり方を学ぶ必要があります。

プログラム上の影響

以下はJavaのバッチの例です。

既存コードを持っていくとすると、キッカーとなるshellが内部でJavaのプログラムを呼び出すような構成は割とあると思います。

cron -> kicker.sh -> java program -cp ... -> read data file  write ... -> check_output.sh

この場合、lambda化で影響がある箇所は、これだけあります。 コンテナ化よりも変更箇所は多いと思います。

• cron(実行タイミングを管理)
• kickerとなるシェル
• javaへ渡すデータ作成をs3などにする
• java内のread/write処理(ラップするなど)
• ログ処理の変更
• check_output.sh(エラー検知など)

開発の各工程への影響

上記のように、アーキテクチャレベルで変更がかかるので、行程のほぼ全般に影響が出ます。

導入に関しては、できるだけ初期の設計段階で検討すべきです。

Lambdaの開発・テストは、サーバベースでやっていた時とは異なるので、その準備などにかかるコストも見込んでおく必要があります。

まとめ

lambda化はプログラムの修正以外にも工数がかかります。

lambda化すれば定型的な処理がほとんどAWS上の設定にできるので、かなり簡潔になります。

上記のメリットと、コストを比較検討するとよいかと思います。

Webアプリケーションサーバ構築時のチェックリスト

Webアプリケーションサーバを構築する際にチェックしたいことをまとめました。

できるだけ簡潔にしたので、状況によって追加が必要な項目があると思います。

アプリの開発の詳細は含んでいません。開発が終わってもサービスインするまでには、プログラム開発以外で必要なことがたくさんあります。それらを主にリストアップしました。

ここ数年、DevOpsが流行っていますが、開発を始める前に、運用を含めた全体像を考慮して開発・運用が連携するのは理想的だと思います。

また、最近はサーバーレス構成もあると思いますが、検討ポイントとしては多くの部分が共通すると思います。

サーバ構築時のチェックリスト

1. 進め方
   1. 初回ミーティング
      1. 参加者(開発、運用、ステークホルダー)
   2. スケジュール
      1. 開発
      2. 外部テスト
      3. 告知
      4. リリース
   3. 担当者のアサイン
      1. 全体の管理
      2. 開発・構築
      3. 外部連携
   4. 情報の共有方法
      1. 随時連絡する方法
      2. 定期ミーティング
         1. タイミング
         2. 参加者
2. コスト項目
   1. インフラ調達(初期、ランニング)
   2. 開発コスト
   3. 運用コスト
3. 設計
   1. アプリ
      1. 機能/非機能
      2. デプロイ
   2. ログ
      1. 出力内容
      2. 収集方法
      3. ローテーション
   3. ハード要件
   4. 構成
      1. 耐障害設計
         1. ロードバランサー
      2. セキュリティ
         1. SSL
         2. アクセス制限
         3. 認証方法
      3. 環境
         1. 設置するネットワーク
         2. ホスト名
   5. 構成管理
      1. ツール
      2. 構成設定の管理
   6. 運用
      1. サービス保証のレベル
      2. サポート体制
      3. 監視
4. 構築・テスト
   1. アプリ
   2. ミドル(Web, アプリサーバ)
   3. ハード(インスタンス)
   4. 監視
   5. 外部との連携
      1. 調整のフロー(担当者)
      2. テスト手順
      3. スケジュール調整
   6. リリース
      1. リリース方法
      2. リリース後の確認方法
      3. 切り戻し方法

開発でわからないことがあった時の質問の仕方

仕事で開発をしていると、他の人とコミュニケーションをとりながら進めることが多いと思います。

新しいプロジェクトに入った場合、先輩や周りの人に聞くスキルで仕事の進みが変わります。

整理されてない状態で質問すると、質問される方も何を答えればよいか判断できなく、お互いにやり取りが負担になります。結果、必要なことまで質問できないようになってしまうと更に悪い方向に行ってしまいます。

聞くことのテンプレート

ということで、テンプレートにまとめました。

全くの新規案件でしたら、「動いているもの」はないかもしれませんが、実際、既存の修正などが多いと思うので入れました。

仕様が「まとまってない、メンテされてない」などの事情で使えない場合や、仕様読むよりソースの方が早くて確実などあると思うので、動いているものの確認以降は、ケースバイケースで順番が変わると思います。

# 案件があったら

## 何をやればいいのかを確認

要件はどこにありますか?

## 動いているものを確認(再現)

どのサービスですか?
どこで動いてますか?
ログはどこにありますか?
確認できる環境はありますか?

## 仕様を確認

仕様はどこにありますか?
(信頼性はどの程度ですか?)

## ソースコードを確認

ソースコードはどこにありますか?
(リポジトリの信頼性はどの程度ですか?)

それぞれで、まずは「どこにあるか?」を聞くようにします。

どこにあるかが想像つかない状態だと、相当にロスが発生するためです。どこにあるかわかれば、それを調べて「わかる・わからない」だけです。

対象にたどり着いたら、調べます。

たどり着けなかったか、理解できない場合は、そこでストップして周りの人に聞きます。

「ここまではわかりました。これを調べてますが、わかりません。」と聞くと質問される方もどこまで分かっていてどこまで分かってないのかがわかり、何をどのレベルで答えればいいのか判断できるので答えやすいです。

手書きでもいいので、書いたものを持って行って見せながら言うとさらに確実になります。

全ての質問は、「この話は、誰に聞くのが一番ですか?」を入れて、適切な相手を探すステップを入れると更にいいと思います。

聞く方、聞かれる方お互いにスムーズにコミュニケーションとれるといいですね。