37555_normal_1453207702_e3838fe38299e3838ae383bc21

価値探索 × プロダクト開発 -ギルドワークス事例発表- in 大阪 を開催しました

ギルドワークス 前川です。 2/26(金)に、「価値探索 × プロダクト開発 -ギルドワークス事例発表- in 大阪」と題しまして、『価値探索』と『プロダクト開発』の2つを中心に、最近のギルドワークスの活動を紹介しました。

価値探索 × プロダクト開発

まずは私から、ハンドメイドのアイデアを共有するアプリ、Craful開発の舞台裏をお話しました。

価値探索を行う意義の一つとして、顧客と開発者の一体感を生み出せるということがあります。実際Craful様の事例では、開発者全員がそのビジョンに共感し、アプリやサービスを良くするための提案を出しあう、非常に熱気にあふれた開発を行うことができました。このような 本気の開発 を、これからも常に行っていきたいと思っています。

価値探索 × 現場コーチ

続いて、ギルドワークスの中村から、「価値探索につながる現場コーチの価値」というタイトルで、ギルドワークスの開発・価値探索と並ぶ柱である現場コーチの活動を紹介しました。

ギルドワークスの現場コーチは、開発の現場だけを見ることはほとんどありません。自律的に動くチームを作るためには、現場の人間一人一人が自分たちが作っているプロダクトと、それが支えるビジネスを意識する必要があります。そんな現場に変えていくギルドワークスの現場コーチについて、事例を交えながら紹介しました。

ギルドワークス × Craful

その後は休憩を挟んで、Crafulの代表である大野さんに登壇いただき、そのあと私と大野さんの対談形式で、ギルドワークスの価値探索と開発についてディスカッションしました。

価値探索から、開発、そしてリリースにいたるまでを思い返す中で、価値探索から開発という流れを行ったからこそできたことが色々とあったことに、改めて気づきました。

対談では、価値探索を通してユーザを理解しようとしたからこそ無駄な機能を作らなくて済んだエピソード、大野さんから事業について発信することで、開発チームがどんどんビジネス側に踏み込めるようになったエピソードなどがあがりました。このようにクライアントと開発者の距離が縮まり「越境」することで、より良いプロダクト開発ができるんだ、ということを実感しています。

この対談はアンケートでも非常に評価が高く、皆さんも興味深く聞いていただいたようです。

最後に、大野さんがCrafulを通して今後考える野望を話していただき、クロージングとなりました。

ギルドワークスでは、これからも、Craful様の事例のようにクライアントとガッチリと手を組み、本気のプロダクト開発をしていきたいと思っています。そんな開発に興味が有る方は、ぜひお問い合わせ下さい

6028684379_5988baf925_b

デジタルとアナログ。「どちらか」ではなく「どっちも」使おう!

デジタルツールは素晴らしい!けれど…

最近、プロジェクトを支えるデジタルの便利なツールが本当に増えています。BacklogJiraなどのプロジェクト管理ツールや、SlackHipChatなどのチャットツールがありますね。

それらは、どんどん高度に、そして使いやすくなっています。Jiraを例に取ると、実際のタスクボードのようなビューでチケットを表現して、それをマウスを使ってドラッグ&ドロップで移動させる、なんてこともできます。


Jiraホームページより抜粋)

他にも、チケットに対応したgitブランチを自動で作ってくれたり、チケットの話題を話すチャットルームを作ってくれたりなど、ツールとの連携によって色々便利な使い方ができるようになっています。

こんな便利な機能を知ってしまうと、アナログのタスクボードを使ったタスク管理ではなく、全てデジタルでやるのが効率が良さそうですよね。

しかし、いざデジタルで運用するとうまくいかない場合が多いです。特によく聞くのが、「情報が更新されない」や「そもそも使ってくれない」という、初期導入に失敗している事例です。

デジタルという新しいツールを使いこなすのは、やはり難しいのです。

アナログツールも、素晴らしい

アナログツールは、その難しさを軽減してくれます。それはアナログツールが持つ、「常にそこにある」「手で書けて、触れられる」「作りやすく、捨てやすい」という特性が、かなり強力だからです。

例えばミーティングで話しているうちに追加のタスクが出てきた時、デジタルツールでは「後で増やしておきます!」となります(が、3回に1回くらいは忘れてしまいます)。

これがアナログだと、その場でタスクカードに追加の情報とともにすぐに書いておくことができます。このようなアクションの「軽さ」は、導入時には非常に重要なのです。

両方使うと、もっといい

とはいえ、冒頭でお話したデジタルツールの機能や、デジタルデータならではの「トレーサビリティの高さ」「メトリクスの取りやすさ」「検索のしやすさ」は、非常に強力です。

ただし、こういった利点を享受するためには、まずはツールを導入し、使いこなせることが大前提となります。

ギルドワークスの現場コーチでは、「どっちも使う」ことがほとんどです。 タスクマネジメントでは、アナログのタスクボードとデジタルのサービスの両方でタスクを管理します。

アナログとデジタルでデータが重複してしまうので、一見効率が悪いように感じるかもしれません。しかし、これらは同じ情報に対して異なる見方になるため、うまく共存できるのです。

例えば、目で見る日々のタスク管理にはカンバンを、細かい情報の蓄積にはデジタルツールを、というように、同じ情報でも、アナログとデジタルで注目するポイントは変わってくるでしょう。

このように、アナログとデジタルを「同時に使う」ことも、現場で考えてはいかがでしょうか?

また、このような悩みをギルドワークスに相談したいという方は、是非お問い合わせ下さい

Photo credit: AnxiousNut via VisualHunt.com / CC BY-SA

0c58a10e-ca8f-b5b6-7c72-090c896740c9

これでできる!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プロジェクトでやってしまえばあとは同じ作業で展開できますので、チャレンジしてもらえればなぁ、と思います。

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

Apple_with_a_bite_taken_out_of_it

iOS9 アプリ開発でのハマりどころ

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

iOS 9 公開後一月ほどたちましたが、皆さんもうアップデートされているでしょうか?OSのアップデートはワクワクして楽しい半面、やはりアプリのつくり手としては思いもよらない不具合に遭遇したりすることもあるので、なかなか困り者です。

じつは私がiOSアプリ開発をはじめて、初めて本格的なバージョンアップを体験するのがこのタイミングでして、なかなか落とし穴にハマりましたので、色々共有させていただきたいと思います。

ハマりどころ① スプラッシュスクリーンがない場合の表示崩れ

まず最初に、ひどい目にあったのが本案件、スプラッシュスクリーンがない場合の画像崩れでした。

上記Qiita記事にもあるように、iOS9 / XCode7 で起動した場合に、黒帯が出てスクリーンが表示されない、という不具合に遭遇しました。

StackOverflowなども参照した結果、どうやらiOS9よりスプラッシュイメージを適切な画像サイズにするなり、ストーリーボードを指定するなりしないと画面崩れが発生するようになったようでした(画面サイズの検知に起動時の大きさを使うようになった、という情報を見かけました)

スプラッシュスクリーンなどただの飾りと思って油断していました。。。Appleのガイドラインを守らないものに振りかかる神罰、と言った感じですね。

ハマりどころ② Bitcode問題によりiTunes Connect にアプリがアップロードできない

iOS9から新たにAppThiningと呼ばれる、アプリの最適化が導入されました。

その中にBitcodeという項目が有ります。これは、アプリの中間コード(Bitcode)をアプリケーションに埋め込んで提供することで、Appleが各CPU向けの最適化を行ってくれるものです。そしてこの機能はデフォルトでONになっています。

しかしながら、cocoapodsCarthageなどのライブラリツールで外部ライブラリを取り込んでいる場合、そのライブラリがBitCodeオプションを有効化しているか、という問題に突き当たります(そして多くの場合有効化していません)。

この結果、せっかく時間をかけてビルドしたアプリがiTunes Connectで弾かれる、という悲しい自体になります・・・

スクリーンショット 2015-10-21 21.04.31

このように数多くのアプリが弾かれてしまいました。

解決方法は簡単で、Build SettingsEnable Bitcode をFalseにすればOKです。

ただ言うまでもなく、Bitcodeオプションは今後有効になるのが標準となるべきもので、CocoapodsやCarthageでも対応が進んでいます。できるだけ早く、有効にできるようになりたいですね。

ハマりどころ③ システムフォント変更におけるUI崩れ

これは特に英語対応をしている場合の要注意項目となります。

iOS9では、英語システムフォントが Helvetica Neue からSan Francisco に変更となっています。

上記記事から分かる通り、結構サイズもダイナミックに変わる、大きめの変更です。

従って、何も考えずにシステムフォントを指定している場合、OS毎にフォントの横幅が変わり、改行などの文字崩れが起きてしまいます。

カツカツのUI設計をしていると、ここで思わぬ折り返しが発生してしまい、泣くことになってしまいます。。。

最も大切なことはOS更新時期とリリース次期をかぶせないこと

今回の最大の教訓はこれです。OSの更新時期は、こういった思わぬトラブルに加え、AppleStoreの審査待ち渋滞も数多く発生します。ですので、できるだけOSの大型更新時期と、アプリのアップデートは分けるようなリリース計画にすべきですね。(新OS対応の特急申請などは割と通りやすい印象もありますし)

ここは神様に逆らってはいけない世界。色々と智慧をめぐらせ、Appleと賢く付き合っていきましょう。

Toolbox_icon_transparent_background

コーチの道具箱 その1

ギルドワークス 前川です。

本日は、私がいろんな現場にコーチとして出向く際に必ず持っていくある道具についてお話ししようと思います。

それは、ホワイトボードマーカーです。私のカバンには、少なくとも4色(赤青緑黒)のホワイトボードマーカーを入れるようにしています。

いったい何でそんなかさばるものを持ち歩いてるのか、ちょっと説明したいと思います。

大前提: ホワイトボードを制する物は議論を制す

ホワイトボードがあるのに、そこに何も書かれない会議というのは、基本的には議論が空回りする空中戦となります。ただ、そこでホワイトボードの前に立つのは結構勇気がいるもので、遠慮する方も多いです。

なので、現場コーチをしていると、ホワイトボードを書くということが非常に多いのです。

理由① たいていのホワイトボードマーカーはインクが切れている or 薄い

そんなとき、さぁ板書しよう!と思って手にとったホワイトボードマーカーは、3割位の確率でかけず、8割位の確率で色が薄いのです。

もちろん、お願いすれば新しいマーカーが出てくることは多いのですが、そのやり取りの間議論を止めてしまうのも、、、となります。

そんなとき、カバンからさっと書けるホワイトボードが出てくると、非常にやりやすいんですよね。

理由② 会社のホワイトボードマーカーの品質が悪い

さて、仮に書けるホワイトボードマーカーが出てきたとしても、残念ながらその品質が悪いことが多いです。品質が悪いとは・・・

  1. すぐに書けなくなる(インクのノリが悪い)
  2. 綺麗に消せない
  3. 芯がフニャフニャで書きにくい

というあたりがネックとなります。残念ながら100均などで売られているお買い得なマーカーはイマイチなことが多いですね・・・

なので、自分のお気に入りのマーカーを持っておくことが必要です。私のお気に入りはシャチハタの「潤芯」です。4本まとまったボックスがあるのと、その名の通り乾燥に非常に強くて書き味が良いのがポイントです。

理由③ アイスブレイクになる

そして実は、カバンからホワイトボードを取り出して、4色をバッと持つと、おお!という雰囲気になります。

IMG_0352

あんまり普通の人はカバンにホワイトボードマーカーは入れていませんので、これだけで、最初に「コーチってこんな人なんだ」という最初の一歩を踏み出せるんですよね。そういう意味でも、特に最初に出向く現場には、必ず持っていくようにしています。

私にホワイトボードマーカーと一緒に現場をサポートして欲しい方は、是非お問い合わせください

credo

ギルドワークスの開発クレド

本日、ギルドワークスの『開発クレド』を公開しました。

クレドとは、「約束」を意味します。「クレド」の取り組みとして最も有名なのはリッツ・カールトンホテルでしょう。

リッツでは、従業員全員がクレドが印刷された紙を携帯し、常にクレドを胸に仕事をしています。

ギルドワークスでも、私達から顧客に向けて行う絶対に破ってはいけない約束、それを開発クレドとして定めました。

本エントリでは、それを簡単にご紹介したいと思います。

クレドを掲げる意味

クレドの前文として、まずはこのような言葉を掲げています。

ギルドワークスの開発チームは、顧客の「未来」の価値を最大化することを目的とします。「今」だけをみた場当たりで局所最適な価値ではなく、「未来」を見通した上で、そこに到達するための「今」の価値を届けます。

これは、『正しいものを正しくつくる』というギルドワークスの目的を、開発側の言葉に言い換えただけです。
ただ、どうしても開発をしていく中で、この目的は少し大きな言葉過ぎて、ちょっと見失ってしまいがちになります。

開発クレドの最初の言葉は、開発に寄り添った言葉で、見失いがちなギルドワークスのモットーを再定義しています。

そして、以下の言葉に続きます。

そうあるために、開発チームは以下に示す約束を遵守します。

「そう ある」としたのはこだわりがあります。頑張ってその状態になるのではなく、自然な状態として「ある」ということを大事にしたい、と思っています。

仮説検証を助ける開発

さて、この前文に続くクレドの一つ目はこれです。

  1. チームは顧客と会話しつづけ、サービスをより良くする仮説を見つけ、検証していきます。

私達の開発は、極論すれば作り上げることを目的としていません。そうではなく、顧客の仮説検証を助けるための一つの手段が開発なのです。
ギルドワークスでは、開発中も常により良い仮説を探求し続け、それを検証していきます。

顧客の関心事を反映した、深いモデルとしなやかな設計

二番目に掲げるのが、こちらになります。

チームは顧客と利用者の関心事を反映した、深いモデルとしなやかな設計を追い求めることで、ソフトウェアを顧客の要望に機敏に対応できるようにします。

「エリック・エヴァンスのドメイン駆動設計」をお読みになった方はピンとくると思いますが、この一節はドメイン駆動設計を強く意識しています。
顧客の関心事 = ドメイン をしっかり捉え、それを反映したモデルにしていくこと。それこそが、顧客が思い描いているソフトウェアを作る最短の道だと信じ、ギルドワークスでは開発を行っていきます。

本当のチームを作る

次は、チームの話を掲げています。

チームのメンバーは熱意や期待、時にはタフな質問も率直に伝えあいます。

「タフな質問」をできるチームになるのは本当に大変です。特にリモート開発においては、濃ゆいコミュニケーションをするのはなかなか難しいでしょう。

しかし、逆にリモートだからこそ、チームが一体となって、答えづらいような質問をお互いにし合い、開発を前に進めていくことが重要です。

ギルドワークスでは、「ドラッカー風エクササイズ」などのチームビルドを行い、ワンチームとしてプロジェクトを行うための取り組みを積極的にに行っています。

フィードバックループを機能させる。

最後に、フィードバックをうまく回そう、という話をしています。

つねに「よりうまくやろう」というフィードバックを、設計・チーム・プロダクトすべてにおいて行い、継続的な改善を回し続けます。

「よりうまくやろう」という気持ちは、皆が持っているものだと信じています。でも、それを保ち続けるのはやはり大変です。

ギルドワークスの開発では、ふりかえりやレビューなどの仕掛けを通じて、この「うまくやろう」という気持ちを引き出し、常にフィードバックループを機能させ続け、改善し続けるチームを目指します。

開発の楽しさ

この4つがクレドの本文なのですが、最後に、ギルドワークスとしてぜひ付け足したかった言葉が、「楽しさ」です。

そして、これらの活動はチームに「新しいモノ・サービスを生み出す楽しさ」をもたらし、それによって顧客とチームメンバーが一体となって価値のあるソフトウェアを作りあげます。

クレドに定めるような開発を行うのは、仕様書通りの開発を行うのに比べ、大変なこともあります。ただ、こうやって生み出すサービスについて知識を深め、チームとしての絆を強めることで、本当に作っていて「楽しい」開発が行えるのではないか、と私達は考えています。

このようなクレドに共感して開発を依頼していただける方、そしてこのようなクレドを掲げた開発チームにジョインして一緒に組みたい方を、ギルドワークスではお待ちしています!

arrogance_by_italianmare-d4gqh5o

現場改善でハマる罠

ギルドワークス 前川です。

ギルドワークスでは、様々な現場に入り込んで現場改善を行っています。もちろん皆さんの現場でも、様々な改善が試行されているのではないかと思います。そんななかでハマりやすい罠について、今日はお話します。

改善をリードする立場とされる立場の間の意識ズレ

あなたが現場改善をリードする立場だった時、あなたの頭のなかには、それが最高にうまく行った場合のバラ色の未来が思い浮かんでいることでしょう。

しかし、改善というのは大抵、即効性のある効果があるものではありません。これまで慣れたプロセスを変えてしまったら、どこかで不慣れによる作業効率の低下や、手順が変わったことによるミスなどがでてくるでしょう。

あなたにとっては、それは改善の効果が出るまでの一過性の痛みに過ぎません。しかし、他のメンバーにとってはどうでしょう?

「いらんことをされて、面倒くさくなった」と思われていませんか?

それを、「分かっていない。利点が見えていない。ずっと使っていたら分かってくれるはず。」と無視するのは簡単です。しかし、そんなふうに強引に進めた改善がたどるのは、早晩打ち捨てられてしまう衰退の道です。

改善をスムーズに進めるために

では、どうすればいいか?

そこに大切なのは、「誠意」です。

丁寧な説明でその「誠意」が事足りる場合もあるでしょうが、もう少し踏み込んだ対策として、即効性のある短期的な改善を組み合わせる、ということがあげられます。

たとえば、バージョン管理システムを新たに取り入れることを考えてみましょう。さきのことを考えると、自分の更新を追うことができ、またいつでも戻ることができる、というのは大きなメリットです。

しかし、最初の導入では、多くの人は「”コミット”とかいうわけのわからない手順が増えてしまった」「新しいツールを導入して怖い」「勝手にマージされて壊れたりしないのか?」などの不安や手間を考えてしまいます。

そこで、バージョン管理の利点を語って皆が納得すればよいのですが、それで納得できない人もいます。

そういう人には、先述した短期的な改善を組み合わせて提示するといいでしょう。例えば、コミットフックの機能をうまく使って、エラーを自動検知したり、同時にJenkinsも導入してテストを回してみたり、など、多少導入の手間が増えてしまっても、メリットがすぐ受けられる、即効性のある改善とセットにするのです。

このように、改善を進めていく側だけの目線や都合だけでなく、改善の結果を受け取る人達の気持ちにも寄り添っていく姿勢が、現場改善では重要となる場合が多いです。

自信と傲慢は違います。皆さん、その点気をつけて、現場を良くしていきましょう!

ギルドワークスが、そのお手伝いをできるのならば、お気軽にお問い合わせください。

アイキャッチ: http://fav.me/d4gqh5o