ふりかえりに入る前にする2つの質問

現場コーチをやっていると、ふりかえり(例えばKPT)で、いきなり「続けたいこと(Keep)」を出し始めるような場を見かけることがあります。このような場合、往々にしてどこかフワッとしたふりかえりになりがちです。

私は、よく現場コーチでふりかえりをする際に、以下の2つの質問をするようにしています。

ふりかえりに入る前にする2つの質問

1:「前回から今回の間でなにがありましたか?」
2:「前回から今回の活動はうまくできましたか?」

この2つの質問を答えも含めて5分程度でサッとやってからふりかえりに入っていきます。
#こういうのも含めて「ふりかえり」と呼ぶ方もいると思います。

1:「前回から今回の間でなにがありましたか?」

前回から今回の間であったことをそれぞれ思い出してもらい、その思い出したもので印象に残っていることを1人1つずつ話してもらいます。例えば「クライアントに動くものを見てもらった」「◯◯機能をリリースした」「残業しなかった」などです。

何があったかを思い出すこでふりかえりのインプットになりますし、それを実際に口にすることで緊張がほぐれたりして後の会話がスムーズになる効果があります。

ふりかえりのインプットとしてを重視するなら、もう少し時間をとり、言葉を出しつつ付箋に書いていく方法もしたりします。

2:「前回から今回の活動はうまくできましたか?」

うまくできたかどうかを(いったんは主観で)「5段階評価するとしたら?」と1〜5までを指で表現してもらいます。
これも何があったかを思い出すことでふりかえりのインプットになりますし、場によってはなかなか出しにくい「自分の意思を表明する」ことをやりやすくなる効果もあります。
#「前回から今回の間でなにがありましたか?」とセットでやる場合もあります。

またperfection gameという方法を使うこともあります。
perfection game

この「どうだった?」という評価は、ふりかえりの最後でも使うことができます。
なんとなくTryは出ているけど何かモヤっとすると感じの時に、「これまで話したことやここに出ているTryで、最初に出した5段階評価のポイントは変化しそう?」と聞きます。

こういうちょっとした質問を投げかけることで「Tryをやろう」という気持ちにもなりますし、「これ以外にもっとやってみれば良いTryはないのか?」と見つめなおすことができます。

さらに、ふりかえりなどの場で定期的に表明するこの5段階評価のポイントを記録しておくと、チームがプロジェクトを進めていく中でどのような変化があったか?というのを時系列で見ることもできます。
#この「これでうまくできそう?」という表明はふりかえり以外に何か計画を立てたりするミーティングでも使うことができます。

このようにいきなりふりかえりをするのではなく、ちょっとした質問を投げかけることで、「正しいものを正しくつくる」現場に近づいていくと考えています。

最後に

このような現場コーチの活動を始めとして、ギルドワークスのやっていることに興味を持った方はお気軽に【ギルドワークスに依頼する】をご覧の上、お問合せください。

このブログでは他にふりかえりのTipsとして以下のようなエントリに書いているので、興味がある方は読んでみてください。
Tipsその1:「根本的な帰属の誤り」
Tipsその2:Problemの深堀りの質問
Tipsその3:安全な場を作るためのグランドルール
Tipsその4:ふりかえりのふりかえりをやってみる
Tipsその5:TryをActionに分解する
Tipsその6:空中戦のミーティングに対してやってみればいいこと

※参考:「これだけ! KPT」「リーン開発の現場 カンバンによる大規模プロジェクトの運営
※アイキャッチの写真:https://www.flickr.com/photos/dpstyles/4835354126/

開発チームがいない、タレントが足りていない、あるいは企画を練るためのリソースが割けない、ノウハウもない。だから、発火ワークスがある。

11月24日、株式会社HackCamp様と私たちギルドワークスにて、企業の新規事業開発を支援する新サービス「発火ワークス」を立ち上げました。その発表イベントでは、新規事業周辺に課題をお持ちの方々にお集まり頂き、われわれのこれからの取り込みについてお話をいたしました。

hackaworks

発火ワークスのコンセプトなどについては、サイトが詳しく、ご興味のある方はご覧頂きたいと思います。

発火ワークス〜ハッカソンのその先へ。組織の枠を超えて感動プロダクトを創造する為の開発支援サービス

発表イベントでは、株式会社チカクの梶原さんにも来て頂きました。チカクさんのプロダクト、まごチャンネルは様々なメディアで取り上げられ多くの人の期待を集めるプロダクトになっています。

私たちが梶原さんに開発の相談を受けた際、まごチャンネルはプロトタイプとして存在したものの、プロダクトに仕立てるためにはまだ距離がある状況でした。基本機能の作りこみ、管理機能の充実など、やることはまだまだありました。しかも、まごチャンネルを作りこむには、iOSアプリ、Androidアプリ、サーバーサイドそれぞれの開発スキルが必要であり、そもそも開発チームの結成が容易ではありませんでした。

それでも、私たちがまごチャンネルというプロダクトづくりに惚れ込んだのは、梶原さんのまごチャンネルへの熱に触れられたからに他ありません。梶原さんは、何度となくプロトタイプを使ってもらった最初のユーザーであるおじいさん、おばあさんの話をします。

その話の中でテレビに映し出された孫の姿を目にするや、難しい顔をしていたおじいさんは相好を崩し、おばあさんはこれはいくらなんだと聞いてくる。何よりもそれを、梶原さんが目を輝かせて全身で楽しそうに話す。その感情に振り切られる感覚を覚えながらも、こう思えてくるのです。梶原さんが垣間見た風景。その風景を私たちも見たい

その思いのためだけに、プロダクトをつくる。果たしてまごチャンネルは、前進した。来春には、きっと日本のどこかでお茶の間の風景が、変わるはずです。

さて、私たちは一つの仮説を立てました。アイデアを持ちながら、前に進めないでいる人たちが、スタートアップにも、事業会社にも大勢いるのではないか。開発チームがいない、タレントが足りていない、あるいは企画を練るためのリソースが割けない、ノウハウもない。事業会社とて、有利とはいえない状況にある。既存事業を抱えながらなので、新規に挑んでいくための人も時間も確保できない。

ならば、私たちが開発チームとなり、タレントを揃え、企画自体も一緒になって練り上げていく。それによって、前進するプロダクトと思いをもっと増やしていきたい。発火ワークスというオープン・イノベーションを提供するサービスを始めるには十分な理由でした。

発火ワークスという関わりを提供することで、前進していきたいという熱を持った人たちと出会う。願わくば、同じ方角を見つめたい。おじいさんとおばあさんの話を楽しそうにする、あの時の梶原さんのように。風景をどう変えていくか、一緒に企みたい。そう発火ワークスによって、あなたも発火するし、私たちも発火するのです。

発火ワークスへのお問い合わせは、こちらからできます。ご質問でも結構です。その他私たちへのご相談はこちらから。いずれも、ぜひお気軽に。

これでできる!iOSアプリ DeployGate配信自動化までの13ステップ

どうも、ギルドワークス 前川です。

さて、みなさーん、継続的インテグレーション(以下CI)してますかー!

さて、以前お伝えしたように、ギルドワークスでは、iOSの開発においても積極的なCIを行っています。

これは、特にリモート開発が多い環境では、正しいものを正しくつくる ために常に安定したベースラインで確認できる環境を作ることが、非常に重要だからです。

とはいえ、なかなかiOSの自動ビルドには越えなければ行けないハードルが多かったりします。 今回は、ある一つのiOSプロジェクトを作成してから、誰でも実機上で確認できるようになるまで(技術ベースで言うと、DeployGateを用いてAdhoc配信するまで)を、ざっと紹介したいと思います。

1. iOSアプリケーションを作成し、iOSアプリケーションをGithubにPushする

まずは、大前提ですね。作成しているアプリケーションを、GithubにPushします。

2. CircleCIにて、ビルドの設定を行う

続いて、CircleCIにて、該当プロジェクトをビルドするように設定します。 この辺りは、公式ドキュメントを参照してくださいませ。

CircleCIはGithub認証が必須ですが、Githubを利用している限りは、特に迷うことはないかと思います。

こんな感じで、選べるはずです。

ead596c5-51ef-49df-a973-edaeae6229b0

3. CircleCIにて、Experimental OptionのiOS Buildを有効にし、チャットにて、制限回避をお願いする

さて、そうするとCircleCIでは勝手にビルドが始まるのですが、このようになります。

da7b9d58-10a9-44df-8dd2-14c564569010

残念ながら、警告が出て、失敗・・・というかビルドが行われません。 これは、CircleCIはiOSに関してはまだExperimental(実験的)な機能という扱いであり、設定をしてやらないといけないからです。

というわけで、Project Settingから、iOSビルドをONにします。

a5ed097f-6dbf-48a4-bebb-89936799c883

さて、なんとそれだけではうまく行きません。何かというと、、、

CircleCI is currently offering beta access to our iOS build system. Please contact support if you would like access.

なんとサポートに連絡する必要があります。 とはいえ、ご心配なく。サポートは、実はとても簡単にアクセスできます。

a0596661-19f2-4f87-be11-1e76bbab850a

ここから、チャットでお願いしましょう!

スクリーンショット 2015-11-20 08.47.40

こんな感じの、シンプルな英語で大丈夫です。

4. Schemeを共有設定にする

さて、これでようやく、iOSビルドの準備が整いました、、とおもいきや、まだ成功しません。Build Schemeを共有しなければなりません。

XCodeで、[Product] -> [Edit Scheme…] と選択し、Schemeの編集画面に行きます。

ここでSchemeを共有しておきます。

06c01938-899f-41c0-9e06-1c19369ebf40

これで、CircleCI上でのビルドが回り始めたはずです!

6. circle.yml を導入

とはいえ、実はCircleCIのデフォルトはXCodeのバージョンがかなり低いため、設定を行わないとビルドは成功しません。 画面からでも設定はある程度行えるのですが、設定ファイルとしてレポジトリに入れるほうが、バージョン管理もできますし、好ましいです。

ということで、circle.yml といわれる設定ファイルを追加します。

レポジトリのrootに circle.ymlを置いておくことで、CircleCIが勝手にその内容を読み取り、ビルドしてくれます。

詳しい書き方は、以下を参考にするとよいでしょう。

ここでは、ひとまずXCodeのバージョンを指定すれば良いので、以下のように書いておきます。

machine:
  xcode:
    version: "7.1"

これで、ビルドが通ったのではないでしょうか。


少し休憩

ここまでで、自動テストと、XCodeで設定してあれば、テストも通るようになります。現状、ベータアクセスのため一手間必要ではありますが、非常に簡単にビルドが行えることが、分かっていただけたでしょうか?

ただし、ここまではSimulator上での実行。ここからは、実機ビルドです。 そのためには、おなじみのApple Mamber Centerでの設定が必要となります。

6. Apple Member Center で Certificate を作成する

今回の実機配布は、DeployGateを利用する想定です。DeployGateはAdhocビルドの配布を行いますので、Certificateを作成する必要があります。

とはいえ、Certificate作成については、多くの先例があるため、紹介に留めます。

7. Apple Member Center で AppID を作成する

AppIDも同様に、先例の紹介に留めます。

8. Apple Member Center で Deviceを登録する

次に、テストを行う端末のDeviceIDを登録します。 DeviceIDを確認する手段は色々ありますが、まずは以下のように直接確認しましょう。

UDID自体は、iPhone をUSBにつなぎXcodeを起動 「Window」->「Devices」にIDが確認できます

from [iPhone] Provisioning Profile の作成

確認したUDIDと、それを識別する名前をセットにし、Member CenterのDevicesの中に追加します。

9. Apple Member Center で Provisioning Profile を作成する

こちらも定型です。

ただし、このProvisioning Profileは、Deviceが追加されるごとに書きなおす必要が有ることに注意しましょう。


もう一度休憩

ここまで設定すれば、手元でAdhoc配布用のビルドが作成できるようになっているはずです。

次にやることは、これをCircleCI上でやること。もう一息ですが、ここからが大変でもあります。頑張りましょう。


10. DeployGateでAPI Keyを取得する

まずは、DeployGateに登録し、API Keyを取得しておきます。 プロフィールページからいけますね。

ffe8196b-e3c0-431a-b371-30525c258689

11. 証明書キーファイル(p12ファイル)をレポジトリに入れる

次に、CircleCI上のMacでビルドするために、証明書をインストールする必要があります。いろいろ手段はあるかと思いますが、今回はp12ファイルをレポジトリに入れてしまいます。

p12ファイルはキーチェーンアクセスから暗号化することができますので、それを入れておけば最低限のセキュリティは担保できるでしょう。

上記はプッシュ通知用の作業ですが、手順としては同じです。これをレポジトリに入れましょう。

12. circle.yml を編集し、ビルド環境を整える

続いて、circle.yml を用いてビルド環境を整えます。 大きくやることは、

  1. cupertino の導入
  2. 証明書のインストール
  3. Certificateのインストール
  4. Provisioning Profileのインストール

の4つになります。

① cupertino の導入

cupertino とは、Member Centerにアクセスして CertificateやProvisioning Profileを取得してくれるコマンドラインツールです。

これを用いて、Apple Member Centerからビルド時にダウンロードします。 これは、Provisioning Profileがデバイスの追加ごとに再作成となるため、開発中は結構変わってしまうからです。リポジトリに入れてしまうと、管理が大変になります。

インストールは簡単です。circle.yml の依存関係解決後に、gemでインストールします

dependencies:
  post:
    - gem install cupertino

② 証明書のインストール

次に証明書のインストールです。ディレクトリ内に p12 ファイルは配置しているはずですので、それを展開します。

dependencies:
  post:
    - gem install cupertino
    - security import ./certificates/xxx.p12 -k "login.keychain" -P "${PRIVATE_KEY_PASSPHRASE}" -T /usr/bin/codesign

ここで、 ${PRIVATE_KEY_PASSPHRASE} で指定した環境変数だけは、誰にも知られたくありません。そんな環境変数は、CircleCIのSetting -> Environment Value から追加できます。パスワードなど外に漏れるとマズい情報はここに書きますね。

85630427-78c0-4865-bcfd-944958da4bca

③ Certificateのインストール

次に、Certificateです。Certificateについては、cupertinoを用いてダウンロードし、インストールします。

dependencies:
  post:
    - gem install cupertino
    - security import ./certificates/xxx.p12 -k "login.keychain" -P "${PRIVATE_KEY_PASSPHRASE}" -T /usr/bin/codesign
    - ios ios profiles:download "provision_name" -u "${user_id}" -p "${password}" --type distribution  --team "A_team"
    - security import "cert_name.cer" -k "login.keychain" -T /usr/bin/codesign

④ Provisioning Profile のインストール

最後に、Profile です。こちらもCertificateとほぼ同様ですね。

dependencies:
  post:
    - gem install cupertino
    - security import ./certificates/xxx.p12 -k "login.keychain" -P "${PRIVATE_KEY_PASSPHRASE}" -T /usr/bin/codesign
    - ios ios profiles:download "provision_name" -u "${user_id}" -p "${password}" --type distribution  --team "A_team"
    - security import "cert_name.cer" -k "login.keychain" -T /usr/bin/codesign
    - ios profiles:download "profile_name" -u "${user_id}" -p "${password}" --type distribution  --team "A_team"
    - cp "profile_name.mobileprovision" "$HOME/Library/MobileDevice/Provisioning Profiles"

これで、ビルドするための環境が整いました。

13. circle.yml を編集し、schenzenを用いてipa build を行い、DeployGateに配信する

最後に、テスト成功時にはパッケージビルドをして、DeployGateに送信しましょう。

これには、 schenzen というコマンドラインツールを使います。

schenzenは

  • ipaファイル(iOSにデプロイされる元ファイル)の作成
  • ipaファイルの各種サービスへの転送

を主に行うツールです。

テスト後、Deployにこれらのコマンドを用いたビルドをcircle.ymlに追記していきます。

deployment:
  staging:
    branch: master
    commands:
      - ipa build -w test.xcworkspace -s scheme_name -c Release -m "${profile_name.mobileprovision}" --sdk "iphoneos" --xcargs "CODE_SIGN_IDENTITY=\"CODE_SIGN_ID\"" --verbose
      - ipa distribute:deploygate -a $DEPLOYGATE_API_TOKEN -u $DEPLOYGATE_USER_NAME 

これがDeployの基本形で、上記はmaster branchにマージされたものを、自動的にビルドし、deploygateで送信しています。

デプロイの詳細な書き方は以下を参照ください。

ipaコマンドがschenzenです。 “CODE_SIGN_ID” というのは、キーチェーンアクセスで「情報を見る」などした時に表示される、”iPhone Distrobution: Guildworks.inc (XXXXXX)” のように、”サイン区分 + 会社名 + カッコつき数字”で記述されているものです。

さぁ、これでDeployGate配信までたどり着けるはずです。

最終的なcircle.ymlはこれくらいのボリュームになります。

machine:
  xcode:
    version: "7.1"
dependencies:
  post:
    - gem install cupertino
    - security import ./certificates/xxx.p12 -k "login.keychain" -P "${PRIVATE_KEY_PASSPHRASE}" -T /usr/bin/codesign
    - ios ios profiles:download "provision_name" -u "${user_id}" -p "${password}" --type distribution  --team "A_team"
    - security import "cert_name.cer" -k "login.keychain" -T /usr/bin/codesign
    - ios profiles:download "profile_name" -u "${user_id}" -p "${password}" --type distribution  --team "A_team"
    - cp "profile_name.mobileprovision" "$HOME/Library/MobileDevice/Provisioning Profiles"

deployment:
  staging:
    branch: master
    commands:
      - ipa build -w test.xcworkspace -s scheme_name -c Release -m "${profile_name.mobileprovision}" --sdk "iphoneos" --xcargs "CODE_SIGN_IDENTITY=\"CODE_SIGN_ID\"" --verbose
      - ipa distribute:deploygate -a $DEPLOYGATE_API_TOKEN -u $DEPLOYGATE_USER_NAME 

さて、長い記事にお付き合いいただきありがとうございました。 このように、けっこう大変ですが(順調に行けば1時間ちょっと、ハマると半日位かかってしまいますが)、1プロジェクトでやってしまえばあとは同じ作業で展開できますので、チャレンジしてもらえればなぁ、と思います。

このように、ギルドワークスではデプロイの徹底的な見直しを通じて、「正しいものを正しくつくる」を実現しようとしています。コーチや開発など、お手伝いできることがあればぜひ、お問い合わせください

TensorFlowをアプリで使ってみる

水谷です。

先週、Googleが機械学習システム「TensorFlow」をオープンソースで公開しました。

曖昧な言葉や口語を的確に理解して検索結果をだすRankBrain、最近Inboxアプリに搭載された自動応答機能や、スマートフォンのカメラで看板の文字などを写して、その文字を翻訳してくれるGoogle翻訳アプリも、このTensorFlowをベースに開発されているようです。

詳しくはこちらなどを参照してください。

http://googledevjp.blogspot.jp/2015/11/tensorflow-google.html
http://www.publickey1.jp/blog/15/googletensorflow.html
http://www.itmedia.co.jp/news/articles/1511/10/news055.html

ここでは、手っ取り早くアプリを動かしてその技術を体験していきたいと思います。

準備

Java JDK

まずJDKが必要になるので以下よりダウンロードします。

http://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html

私の場合は、Macなのでjdk-8u66-macosx-x64.dmgをダウンロードして、ダウンロードしたファイルを開いて「JDK 8 Update 66.pkg」ダブルクリックして、その後ウィザードに従ってインストールします。

Android SDK

次にAndroid SDKを以下のページからダウンドールしていれます。

https://developer.android.com/sdk/index.html

ページの下の方にある「android-sdk_r24.4.1-macosx.zip」をダウンロードします。

ダウンロードしたファイルを解凍して、アプリケーションフォルダに配置しておきます。

$ cd ~/Downloads
$ unzip android-sdk_r24.4.1-macosx.zip
$ mv android-sdk-macosx ~/Applications

NDK

あと、NDKも必要になるので、以下よりダウンロードします。

http://developer.android.com/ndk/downloads/index.html

実行形式のファイルになっているので実行権を付与して実行します。できたファイルをアプリケーションフォルダに配置します。

$ cd ~/Downloads
$ chmod +x android-ndk-r10e-darwin-x86_64.bin
$ ./android-ndk-r10e-darwin-x86_64.bin
$ mv android-ndk-r10e ~/Applications

Bazel

Bazelも以下よりダウンロードします。

https://github.com/bazelbuild/bazel/releases

インストールスクリプトを実行します。

$ cd ~/Downloads
$ chmod +x bazel-0.1.1-installer-darwin-x86_64.sh
$ ./bazel-0.1.1-installer-darwin-x86_64.sh --user

PATHの設定

SDKとNDKのPATHを設定しときます。

# android
export ANDROID_HOME="$HOME/Applications/android-sdk-macosx"
export NDK_HOME="$HOME/Applications/android-ndk-r10e"
export PATH=$PATH:$ANDROID_HOME/tools:$ANDROID_HOME/platform-tools:$NDK_HOME

# bazel
export PATH="$PATH:$HOME/bin"

Build Tools

SDK Managerで23.0.2をいれます。

SDK Managerを起動します。

$ android

23.0.2をチェックしてインストールします。

Android_SDK_Manager

アプリのビルドとインストール

準備ができたのでアプリをビルドして実機にいれていきます。

TensorFlow

TensorFlowのソースをGitからcloneします。

$ git clone --recurse-submodules https://github.com/tensorflow/tensorflow

ビルド

SDKとNDKの場所を指定する必要があるのでWORKSPACEというファイルを編集します。

$ cd tensorflow
$ vi WORKSPACE

上記の手順のとおりであれば以下を追加します。

android_sdk_repository(
name = "androidsdk",
api_level = 23,
build_tools_version = "23.0.2",
# Replace with path to Android SDK on your system
path = "/Users/hirotaka/Applications/android-sdk-macosx",
)

android_ndk_repository(
name="androidndk",
path="/Users/hirotaka/Applications/android-ndk-r10e",
api_level=21)

ビルドをします。

$ bazel build //tensorflow/examples/android:tensorflow_demo -c opt --copt=-mfpu=neon
.
.
THIS TOOL IS DEPRECATED. See --help for more information.

INFO: From Generating signed apk:

THIS TOOL IS DEPRECATED. See --help for more information.

Target //tensorflow/examples/android:tensorflow_demo up-to-date:
bazel-bin/tensorflow/examples/android/tensorflow_demo_deploy.jar
bazel-bin/tensorflow/examples/android/tensorflow_demo_unsigned.apk
bazel-bin/tensorflow/examples/android/tensorflow_demo.apk
INFO: Elapsed time: 294.089s, Critical Path: 283.02s

ワーニングはいくつかでるのですが、エラーがなければ5分くらいでパッケージができます。

実機にいれます。

$ adb install -r bazel-bin/tensorflow/examples/android/tensorflow_demo.apk
5101 KB/s (97789592 bytes in 18.718s)
pkg: /data/local/tmp/tensorflow_demo.apk
Success

試してみる

アプリが追加されているのでアイコンをタップして起動します。

カメラが起動している状態になるので、その画面をとおして何かを表示します。そうすると、アプリがそれが何なのかを青い部分に名称を表示します。

これは、事前にいくつかの画像を学習して、いままでみたことない画像でも学習した内容からアプリが推測しているのです。

とはいえ、あまりにもいままで学習した内容からかけ離れているとうまく表示されないようですね。

学習している内容は以下にまとめてあります。

https://github.com/tensorflow/tensorflow/blob/master/tensorflow/examples/android/assets/imagenet_comp_graph_label_strings.txt

なるべく特徴のあるのが認識されやすいみたいです。ふぐ(puffer)は見事に認識しました!

IMG_1288

まとめ

今回はアプリを動かすまでで終わってしまいましたが、機会があれば中の処理もおっていきたいと思います。

実際のサービスで使われている技術が、こうして手軽に使えるのは非常にうれしいですね。これでどんなアプリをつくろうか考えるとわくわくします。

この記事を読んでギルドワークスに興味を持たれた方はお気軽に【ギルドワークスに依頼する】をご覧の上、お問合せください。

空中戦のミーティングに対してやってみればいいこと

ミーティングがうまく進まないと「正しいものを正しくつくる」ことはできません。

ミーティングがうまく進まない原因として、「議論が見える化されておらず空中戦になる」「参加者に当事者意識を持っておらず発言が少ない」など色々な事象と原因の組合せがあります。その中の1つに「ファシリテーターが議論に入ってしまうことで、場が進まなくなったり、議論の流れを見失ってしまう」というのがあります。

こういうミーティングの時、当事者以外の人にファシリテーターをやってもらうことでうまくいくことがあります。
#現場コーチがそのままファシリテーターをすることも多いです。

当事者以外の人にファシリテーターをやってもらうメリット

1:当事者全員が会話、議論に集中することができる

複雑なテーマや考えることが多いテーマの場合、やはりそれぞれの議論に集中し、深く思考する時間、集中力が必要になってきます。一方、ファシリテートも別の視点で高い集中力が必要になってきます。その両方を十分にうまくやることはなかなか難しいことです。

2:アジェンダを考えるようになる

ファシリテーターを別の人に頼むには、その場の目的やアジェンダなどを伝える必要があります。
いきなり何もなくてポンと任されてもファシリテーターも困ってしまいます。

現場コーチをしていると「アジェンダがないミーティング」が時々あります。そういう時は「どういう目的で、何をどんな流れでやろうと考えています?」と当事者からヒアリングをします。その結果、準備が整っていないことや、そもそもミーティングが不要だったことが分かるということもありました。

ですので、ミーティングの準備としてアジェンダを考えるため、ムダな時間の使い方を防ぐこともあります。

3:新しい視線を得られる

当事者以外のファシリテーターはそのテーマに対して当事者達が持っている思い込みから距離が遠いところにいます。それ故、場や議論を俯瞰することができます。
それによって、当事者では見えていない新しい切り口や論点を見つけることができる場合もあります。
岡目八目的な効果です。

また当事者だと厳しいツッコミや指摘を(事情が分かっている故に)躊躇してしまうことがあります。が、当事者以外であれば、そこは空気を読まずに踏み込んでいくことができます。

4:自分のチームに持ち帰ることができる

これはファシリテーター側のメリットですが、別のチームのふりかえりにファシリテーターとして参加した場合、そこでのKPT(特にProblemに対するTry)を自分達のチームに持ち帰り、よりうまくやるためのヒントになります。

今回は、(この「ふりかえり」のTipsシリーズで扱っている)ふりかえりそのものではなく、ファシリテーターのことについて書いてみました。ふりかえりのTipsは以下のようなエントリに書いているので、興味がある方は読んでみてください。
Tipsその1:「根本的な帰属の誤り」
Tipsその2:Problemの深堀りの質問
Tipsその3:安全な場を作るためのグランドルール
Tipsその4:ふりかえりのふりかえりをやってみる
Tipsその5:TryをActionに分解する

※アイキャッチの写真:https://www.flickr.com/photos/tiarescott/69821764/

ギルドワークスに入社しました。

この度、11月に入社しました岩本です。

みなさまはじめまして、なので

  • 私が今まで何をしていたか
  • 私が大事にしていること
  • なぜギルドワークスなのか

をお話ししようと思います。

今まで

自社製品開発や受託開発のプロマネをやっていました。

規模や期間は長く、1年を超えるプロジェクトを多くやっていましたが、従来のウォーターフォール開発ではうまくいかないことを何度も経験しましたね。

プロジェクトに限らずですが私自身肝に命じている言葉があります。

「今まで出来なかったことは、やり方を変えない限りできない。」(スミセイ情報システム 小浜さん)

これ、ずしっと来ませんか?

ほんとにそうで、ぐぅの音もでない。

要は変える努力をしてますか?向き合ってますか?ということだと思うんです。

そんな思いで「何か変えなければ!」と模索していた頃アジャイルに出会い、自プロジェクトにアジャイルを導入することにひたすらトライし続けていました。

大事にしている事

「どうせやるなら○○で」

  • どうせやるなら 効率的に
  • どうせやるなら 新しい事を覚える、試す
  • どうせやるなら 楽しく
  • どうせやるなら 喧嘩してでもいいものを
  • どうせやるなら 失敗しても起き上がって学ぶ
  • どうせやるなら カッコよく
  • どうせやるなら 美しく

あげればきりがないですが、そういうことです。

二度と同じ経験ができない中で、いかにいっぱい得るか。どうせやるなら、”ただ” やるだけでは人生損です。

そしてその中で最も大事にしているのは「美しく」ということ。

これは、設計然り、コード、プロセス、プロダクト、チーム、全てにおいて目指すべき大事な事です。

正しいから美しいんじゃないの?

あるとき、代表の市谷から言われた事です。

ギルドワークスは「正しいものを正しくつくる」をミッションに掲げています。

「正しいから美しい」に妙に納得、バチっとあっちゃったんですね。

「どうせやるなら自分が正しいと思える、正しいことができるところで。」と入社に至りました。

これから、改善する楽しさや仕事から精一杯何かを得てやれ!というスタンスを現場コーチを通して感染させていきます!

そんなミッションを真摯に対応するギルドワークスに興味が湧いた方は「ギルドワークスと組む」などを見ていただき、お気軽にお問い合わせください。