2016年1月26日デジタルとアナログ。2016年1月12日2016年あけましておめでとうございます。大阪」と題しまして、『価値探索』と『プロダクト開発』の2つを中心に、最近のギルドワークスの活動を紹介しました。プロダクト開発まずは私から、ハンドメイドのアイデアを共有するアプリ、Craful開発の舞台裏をお話しました。価値探索を行う意義の一つとして、顧客と開発者の一体感を生み出せるということがあります。実際Craful様の事例では、開発者全員がそのビジョンに共感し、アプリやサービスを良くするための提案を出しあう、非常に熱気にあふれた開発を行うことができました。これからも常に行っていきたいと思っています。現場コーチ続いて、ギルドワークスの中村から、「価値探索につながる現場コーチの価値」というタイトルで、ギルドワークスの開発・価値探索と並ぶ柱である現場コーチの活動を紹介しました。ギルドワークスの現場コーチは、開発の現場だけを見ることはほとんどありません。自律的に動くチームを作るためには、現場の人間一人一人が自分たちが作っているプロダクトと、それが支えるビジネスを意識する必要があります。そんな現場に変えていくギルドワークスの現場コーチについて、事例を交えながら紹介しました。Crafulその後は休憩を挟んで、Crafulの代表である大野さんに登壇いただき、そのあと私と大野さんの対談形式で、ギルドワークスの価値探索と開発についてディスカッションしました。価値探索から、開発、そしてリリースにいたるまでを思い返す中で、価値探索から開発という流れを行ったからこそできたことが色々とあったことに、改めて気づきました。対談では、価値探索を通してユーザを理解しようとしたからこそ無駄な機能を作らなくて済んだエピソード、大野さんから事業について発信することで、開発チームがどんどんビジネス側に踏み込めるようになったエピソードなどがあがりました。このようにクライアントと開発者の距離が縮まり「越境」することで、より良いプロダクト開発ができるんだ、ということを実感しています。この対談はアンケートでも非常に評価が高く、皆さんも興味深く聞いていただいたようです。最後に、大野さんがCrafulを通して今後考える野望を話していただき、クロージングとなりました。ギルドワークスでは、これからも、Craful様の事例のようにクライアントとガッチリと手を組み、本気のプロダクト開発をしていきたいと思っています。そんな開発に興味が有る方は、ぜひお問い合わせ下さい!イベントギルドワークスについて現場コーチ仮説検証デジタルとアナログ。前川博志コメントするデジタルツールは素晴らしい!けれど...最近、プロジェクトを支えるデジタルの便利なツールが本当に増えています。BacklogやJiraなどのプロジェクト管理ツールや、SlackやHipChatなどのチャットツールがありますね。それらは、どんどん高度に、そして使いやすくなっています。Jiraを例に取ると、実際のタスクボードのようなビューでチケットを表現して、それをマウスを使ってドラッグ&ドロップで移動させる、なんてこともできます。(Jiraホームページより抜粋)他にも、チケットに対応したgitブランチを自動で作ってくれたり、チケットの話題を話すチャットルームを作ってくれたりなど、ツールとの連携によって色々便利な使い方ができるようになっています。こんな便利な機能を知ってしまうと、アナログのタスクボードを使ったタスク管理ではなく、全てデジタルでやるのが効率が良さそうですよね。いざデジタルで運用するとうまくいかない場合が多いです。聞くのが、「情報が更新されない」や「そもそも使ってくれない」という、初期導入に失敗している事例です。デジタルという新しいツールを使いこなすのは、やはり難しいのです。アナログツールも、素晴らしいアナログツールは、その難しさを軽減してくれます。それはアナログツールが持つ、「常にそこにある」「手で書けて、触れられる」「作りやすく、捨てやすい」という特性が、かなり強力だからです。ミーティングで話しているうちに追加のタスクが出てきた時、デジタルツールでは「後で増やしておきます!」となります(が、3回に1回くらいは忘れてしまいます)。これがアナログだと、その場でタスクカードに追加の情報とともにすぐに書いておくことができます。このようなアクションの「軽さ」は、導入時には非常に重要なのです。両方使うと、もっといいとはいえ、冒頭でお話したデジタルツールの機能や、デジタルデータならではの「トレーサビリティの高さ」「メトリクスの取りやすさ」「検索のしやすさ」は、非常に強力です。いった利点を享受するためには、まずはツールを導入し、使いこなせることが大前提となります。ギルドワークスの現場コーチでは、「どっちも使う」ことがほとんどです。タスクマネジメントでは、アナログのタスクボードとデジタルのサービスの両方でタスクを管理します。アナログとデジタルでデータが重複してしまうので、一見効率が悪いように感じるかもしれません。これらは同じ情報に対して異なる見方になるため、うまく共存できるのです。目で見る日々のタスク管理にはカンバンを、細かい情報の蓄積にはデジタルツールを、というように、同じ情報でも、アナログとデジタルで注目するポイントは変わってくるでしょう。みなさーん、継続的インテグレーション(以下CI)してますかー!さて、以前お伝えしたように、ギルドワークスでは、iOSの開発においても積極的なCIを行っています。ために常に安定したベースラインで確認できる環境を作ることが、非常に重要だからです。いえ、なかなかiOSの自動ビルドには越えなければ行けないハードルが多かったりします。今回は、ある一つのiOSプロジェクトを作成してから、誰でも実機上で確認できるようになるまで(技術ベースで言うと、DeployGateを用いてAdhoc配信するまで)を、ざっと紹介したいと思います。iOSアプリケーションを作成し、iOSアプリケーションをGithubにPushするまずは、大前提ですね。作成しているアプリケーションを、GithubにPushします。CircleCIにて、ビルドの設定を行う続いて、CircleCIにて、該当プロジェクトをビルドするように設定します。この辺りは、公式ドキュメントを参照してくださいませ。CircleCICircleCIはGithub認証が必須ですが、Githubを利用している限りは、特に迷うことはないかと思います。こんな感じで、選べるはずです。Buildを有効にし、チャットにて、制限回避をお願いするさて、そうするとCircleCIでは勝手にビルドが始まるのですが、このようになります。残念ながら、警告が出て、失敗・・・というかビルドが行われません。これは、CircleCIはiOSに関してはまだExperimental(実験的)な機能という扱いであり、設定をしてやらないといけないからです。Settingから、iOSビルドをONにします。なんとそれだけではうまく行きません。access.なんとサポートに連絡する必要があります。サポートは、実はとても簡単にアクセスできます。ここから、チャットでお願いしましょう!こんな感じの、シンプルな英語で大丈夫です。Schemeを共有設定にするさて、これでようやく、iOSビルドの準備が整いました、、とおもいきや、まだ成功しません。Schemeを共有しなければなりません。選択し、Schemeの編集画面に行きます。ここでSchemeを共有しておきます。導入とはいえ、実はCircleCIのデフォルトはXCodeのバージョンがかなり低いため、設定を行わないとビルドは成功しません。画面からでも設定はある程度行えるのですが、設定ファイルとしてレポジトリに入れるほうが、バージョン管理もできますし、好ましいです。いわれる設定ファイルを追加します。circle.ymlを置いておくことで、CircleCIが勝手にその内容を読み取り、ビルドしてくれます。詳しい書き方は、以下を参考にするとよいでしょう。CircleCIここでは、ひとまずXCodeのバージョンを指定すれば良いので、以下のように書いておきます。"7.1"これで、ビルドが通ったのではないでしょうか。休憩ここまでで、自動テストと、XCodeで設定してあれば、テストも通るようになります。現状、ベータアクセスのため一手間必要ではありますが、非常に簡単にビルドが行えることが、分かっていただけたでしょうか?ただし、ここまではSimulator上での実行。ここからは、実機ビルドです。Centerでの設定が必要となります。作成する今回の実機配布は、DeployGateを利用する想定です。DeployGateはAdhocビルドの配布を行いますので、Certificateを作成する必要があります。いえ、Certificate作成については、多くの先例があるため、紹介に留めます。作成するAppIDも同様に、先例の紹介に留めます。Deviceを登録する次に、テストを行う端末のDeviceIDを登録します。DeviceIDを確認する手段は色々ありますが、まずは以下のように直接確認しましょう。CenterのDevicesの中に追加します。作成するこちらも定型です。Profileは、Deviceが追加されるごとに書きなおす必要が有ることに注意しましょう。一度休憩ここまで設定すれば、手元でAdhoc配布用のビルドが作成できるようになっているはずです。次にやることは、これをCircleCI上でやること。一息ですが、ここからが大変でもあります。Keyを取得しておきます。プロフィールページからいけますね。証明書キーファイル(p12ファイル)をレポジトリに入れる次に、CircleCI上のMacでビルドするために、証明書をインストールする必要があります。手段はあるかと思いますが、今回はp12ファイルをレポジトリに入れてしまいます。p12ファイルはキーチェーンアクセスから暗号化することができますので、それを入れておけば最低限のセキュリティは担保できるでしょう。Appiaries上記はプッシュ通知用の作業ですが、手順としては同じです。これをレポジトリに入れましょう。用いてビルド環境を整えます。Profileのインストールの4つになります。Profileを取得してくれるコマンドラインツールです。Centerからビルド時にダウンロードします。Profileがデバイスの追加ごとに再作成となるため、開発中は結構変わってしまうからです。リポジトリに入れてしまうと、管理が大変になります。インストールは簡単です。証明書のインストール次に証明書のインストールです。ファイルは配置しているはずですので、それを展開します。指定した環境変数だけは、誰にも知られたくありません。パスワードなど外に漏れるとマズい情報はここに書きますね。Certificateのインストール次に、Certificateです。Certificateについては、cupertinoを用いてダウンロードし、インストールします。こちらもCertificateとほぼ同様ですね。Profiles"これで、ビルドするための環境が整いました。行い、DeployGateに配信する最後に、テスト成功時にはパッケージビルドをして、DeployGateに送信しましょう。いうコマンドラインツールを使います。https://github.com/nomad/shenzhenschenzenはipaファイル(iOSにデプロイされる元ファイル)の作成ipaファイルの各種サービスへの転送を主に行うツールです。テスト後、Deployにこれらのコマンドを用いたビルドをcircle.ymlに追記していきます。branchにマージされたものを、自動的にビルドし、deploygateで送信しています。デプロイの詳細な書き方は以下を参照ください。CircleCIipaコマンドがschenzenです。カッコつき数字”で記述されているものです。さぁ、これでDeployGate配信までたどり着けるはずです。最終的なcircle.ymlはこれくらいのボリュームになります。$DEPLOYGATE_USER_NAMEさて、長い記事にお付き合いいただきありがとうございました。このように、けっこう大変ですが(順調に行けば1時間ちょっと、ハマると半日位かかってしまいますが)、1プロジェクトでやってしまえばあとは同じ作業で展開できますので、チャレンジしてもらえればなぁ、と思います。このように、ギルドワークスではデプロイの徹底的な見直しを通じて、「正しいものを正しくつくる」を実現しようとしています。コーチや開発など、お手伝いできることがあればぜひ、お問い合わせください。公開後一月ほどたちましたが、皆さんもうアップデートされているでしょうか?OSのアップデートはワクワクして楽しい半面、やはりアプリのつくり手としては思いもよらない不具合に遭遇したりすることもあるので、なかなか困り者です。じつは私がiOSアプリ開発をはじめて、初めて本格的なバージョンアップを体験するのがこのタイミングでして、なかなか落とし穴にハマりましたので、色々共有させていただきたいと思います。スプラッシュスクリーンがない場合の表示崩れまず最初に、ひどい目にあったのが本案件、スプラッシュスクリーンがない場合の画像崩れでした。起動した場合に、黒帯が出てスクリーンが表示されない、という不具合に遭遇しました。bottomスプラッシュスクリーンなどただの飾りと思って油断していました。Appleのガイドラインを守らないものに振りかかる神罰、と言った感じですね。アプリがアップロードできないiOS9から新たにAppThiningと呼ばれる、アプリの最適化が導入されました。watchOS)その中にBitcodeという項目が有ります。これは、アプリの中間コード(Bitcode)をアプリケーションに埋め込んで提供することで、Appleが各CPU向けの最適化を行ってくれるものです。この機能はデフォルトでONになっています。cocoapodsやCarthageなどのライブラリツールで外部ライブラリを取り込んでいる場合、そのライブラリがBitCodeオプションを有効化しているか、という問題に突き当たります(そして多くの場合有効化していません)。Connectで弾かれる、という悲しい自体になります・・・このように数多くのアプリが弾かれてしまいました。FalseにすればOKです。言うまでもなく、Bitcodeオプションは今後有効になるのが標準となるべきもので、CocoapodsやCarthageでも対応が進んでいます。できるだけ早く、有効にできるようになりたいですね。システムフォント変更におけるUI崩れこれは特に英語対応をしている場合の要注意項目となります。上記記事から分かる通り、結構サイズもダイナミックに変わる、大きめの変更です。従って、何も考えずにシステムフォントを指定している場合、OS毎にフォントの横幅が変わり、改行などの文字崩れが起きてしまいます。UI設計をしていると、ここで思わぬ折り返しが発生してしまい、泣くことになってしまいます。大切なことはOS更新時期とリリース次期をかぶせないこと今回の最大の教訓はこれです。OSの更新時期は、こういった思わぬトラブルに加え、AppleStoreの審査待ち渋滞も数多く発生します。できるだけOSの大型更新時期と、アプリのアップデートは分けるようなリリース計画にすべきですね。(新OS対応の特急申請などは割と通りやすい印象もありますし)ここは神様に逆らってはいけない世界。智慧をめぐらせ、Appleと賢く付き合っていきましょう。本日は、私がいろんな現場にコーチとして出向く際に必ず持っていくある道具についてお話ししようと思います。それは、ホワイトボードマーカーです。私のカバンには、少なくとも4色(赤青緑黒)のホワイトボードマーカーを入れるようにしています。何でそんなかさばるものを持ち歩いてるのか、ちょっと説明したいと思います。ホワイトボードを制する物は議論を制すホワイトボードがあるのに、そこに何も書かれない会議というのは、基本的には議論が空回りする空中戦となります。そこでホワイトボードの前に立つのは結構勇気がいるもので、遠慮する方も多いです。現場コーチをしていると、ホワイトボードを書くということが非常に多いのです。薄いそんなとき、さぁ板書しよう!と思って手にとったホワイトボードマーカーは、3割位の確率でかけず、8割位の確率で色が薄いのです。お願いすれば新しいマーカーが出てくることは多いのですが、そのやり取りの間議論を止めてしまうのも、、、となります。そんなとき、カバンからさっと書けるホワイトボードが出てくると、非常にやりやすいんですよね。会社のホワイトボードマーカーの品質が悪いさて、仮に書けるホワイトボードマーカーが出てきたとしても、残念ながらその品質が悪いことが多いです。品質が悪いとは・・・すぐに書けなくなる(インクのノリが悪い)綺麗に消せない芯がフニャフニャで書きにくいというあたりがネックとなります。残念ながら100均などで売られているお買い得なマーカーはイマイチなことが多いですね・・・なので、自分のお気に入りのマーカーを持っておくことが必要です。私のお気に入りはシャチハタの「潤芯」です。4本まとまったボックスがあるのと、その名の通り乾燥に非常に強くて書き味が良いのがポイントです。アイスブレイクになるそして実は、カバンからホワイトボードを取り出して、4色をバッと持つと、おお!という雰囲気になります。普通の人はカバンにホワイトボードマーカーは入れていませんので、これだけで、最初に「コーチってこんな人なんだ」という最初の一歩を踏み出せるんですよね。いう意味でも、特に最初に出向く現場には、必ず持っていくようにしています。前川博志1件のコメント本日、ギルドワークスの『開発クレド』を公開しました。クレドとは、「約束」を意味します。「クレド」の取り組みとして最も有名なのはリッツ・カールトンホテルでしょう。リッツでは、従業員全員がクレドが印刷された紙を携帯し、常にクレドを胸に仕事をしています。ギルドワークスでも、私達から顧客に向けて行う絶対に破ってはいけない約束、それを開発クレドとして定めました。本エントリでは、それを簡単にご紹介したいと思います。クレドを掲げる意味クレドの前文として、まずはこのような言葉を掲げています。ギルドワークスの開発チームは、顧客の「未来」の価値を最大化することを目的とします。「今」だけをみた場当たりで局所最適な価値ではなく、「未来」を見通した上で、そこに到達するための「今」の価値を届けます。これは、『正しいものを正しくつくる』というギルドワークスの目的を、開発側の言葉に言い換えただけです。しても開発をしていく中で、この目的は少し大きな言葉過ぎて、ちょっと見失ってしまいがちになります。開発クレドの最初の言葉は、開発に寄り添った言葉で、見失いがちなギルドワークスのモットーを再定義しています。以下の言葉に続きます。あるために、開発チームは以下に示す約束を遵守します。ある」としたのはこだわりがあります。頑張ってその状態になるのではなく、自然な状態として「ある」ということを大事にしたい、と思っています。仮説検証を助ける開発さて、この前文に続くクレドの一つ目はこれです。チームは顧客と会話しつづけ、サービスをより良くする仮説を見つけ、検証していきます。私達の開発は、極論すれば作り上げることを目的としていません。なく、顧客の仮説検証を助けるための一つの手段が開発なのです。ギルドワークスでは、開発中も常により良い仮説を探求し続け、それを検証していきます。二番目に掲げるのが、こちらになります。チームは顧客と利用者の関心事を反映した、深いモデルとしなやかな設計を追い求めることで、ソフトウェアを顧客の要望に機敏に対応できるようにします。「エリック・エヴァンスのドメイン駆動設計」をお読みになった方はピンとくると思いますが、この一節はドメイン駆動設計を強く意識しています。捉え、それを反映したモデルにしていくこと。それこそが、顧客が思い描いているソフトウェアを作る最短の道だと信じ、ギルドワークスでは開発を行っていきます。本当のチームを作る次は、チームの話を掲げています。チームのメンバーは熱意や期待、時にはタフな質問も率直に伝えあいます。「タフな質問」をできるチームになるのは本当に大変です。リモート開発においては、濃ゆいコミュニケーションをするのはなかなか難しいでしょう。逆にリモートだからこそ、チームが一体となって、答えづらいような質問をお互いにし合い、開発を前に進めていくことが重要です。ギルドワークスでは、「ドラッカー風エクササイズ」などのチームビルドを行い、ワンチームとしてプロジェクトを行うための取り組みを積極的にに行っています。フィードバックループを機能させる。最後に、フィードバックをうまく回そう、という話をしています。つねに「よりうまくやろう」というフィードバックを、設計・チーム・プロダクトすべてにおいて行い、継続的な改善を回し続けます。「よりうまくやろう」という気持ちは、皆が持っているものだと信じています。それを保ち続けるのはやはり大変です。ギルドワークスの開発では、ふりかえりやレビューなどの仕掛けを通じて、この「うまくやろう」という気持ちを引き出し、常にフィードバックループを機能させ続け、改善し続けるチームを目指します。開発の楽しさこの4つがクレドの本文なのですが、最後に、ギルドワークスとしてぜひ付け足したかった言葉が、「楽しさ」です。これらの活動はチームに「新しいモノ・サービスを生み出す楽しさ」をもたらし、それによって顧客とチームメンバーが一体となって価値のあるソフトウェアを作りあげます。クレドに定めるような開発を行うのは、仕様書通りの開発を行うのに比べ、大変なこともあります。やって生み出すサービスについて知識を深め、チームとしての絆を強めることで、本当に作っていて「楽しい」開発が行えるのではないか、と私達は考えています。ギルドワークスでは、様々な現場に入り込んで現場改善を行っています。皆さんの現場でも、様々な改善が試行されているのではないかと思います。そんななかでハマりやすい罠について、今日はお話します。改善をリードする立場とされる立場の間の意識ズレあなたが現場改善をリードする立場だった時、あなたの頭のなかには、それが最高にうまく行った場合のバラ色の未来が思い浮かんでいることでしょう。改善というのは大抵、即効性のある効果があるものではありません。これまで慣れたプロセスを変えてしまったら、どこかで不慣れによる作業効率の低下や、手順が変わったことによるミスなどがでてくるでしょう。あなたにとっては、それは改善の効果が出るまでの一過性の痛みに過ぎません。他のメンバーにとってはどうでしょう?「いらんことをされて、面倒くさくなった」と思われていませんか?それを、「分かっていない。使っていたら分かってくれるはず。」と無視するのは簡単です。そんなふうに強引に進めた改善がたどるのは、早晩打ち捨てられてしまう衰退の道です。改善をスムーズに進めるためにでは、どうすればいいか?そこに大切なのは、「誠意」です。丁寧な説明でその「誠意」が事足りる場合もあるでしょうが、もう少し踏み込んだ対策として、即効性のある短期的な改善を組み合わせる、ということがあげられます。バージョン管理システムを新たに取り入れることを考えてみましょう。さきのことを考えると、自分の更新を追うことができ、またいつでも戻ることができる、というのは大きなメリットです。最初の導入では、多くの人は「”コミット”とかいうわけのわからない手順が増えてしまった」「新しいツールを導入して怖い」「勝手にマージされて壊れたりしないのか?」などの不安や手間を考えてしまいます。そこで、バージョン管理の利点を語って皆が納得すればよいのですが、それで納得できない人もいます。いう人には、先述した短期的な改善を組み合わせて提示するといいでしょう。コミットフックの機能をうまく使って、エラーを自動検知したり、同時にJenkinsも導入してテストを回してみたり、など、多少導入の手間が増えてしまっても、メリットがすぐ受けられる、即効性のある改善とセットにするのです。このように、改善を進めていく側だけの目線や都合だけでなく、改善の結果を受け取る人達の気持ちにも寄り添っていく姿勢が、現場改善では重要となる場合が多いです。自信と傲慢は違います。皆さん、その点気をつけて、現場を良くしていきましょう!ギルドワークスが、そのお手伝いをできるのならば、お気軽にお問い合わせください。Blog.投稿先:キャンセル。