credo

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

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

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

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

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

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

クレドを掲げる意味

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

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

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

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

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

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

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

仮説検証を助ける開発

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

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

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

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

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

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

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

本当のチームを作る

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

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

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

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

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

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

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

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

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

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

開発の楽しさ

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

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

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

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

space-19070_640

ドメイン駆動設計の探求 其の一 モデルと実装を協調させる、とはどういうことか

どうも、ギルドワークス 前川です。 以前ご紹介した通り、ギルドワークスではドメイン駆動設計(DDD)の勉強会を社内で行っています。 その中で出てきた指摘に、ハッとする物があったので、今回はそれについて、ご紹介します。

「それ、ソースコードに書いてないじゃん」

それは、DDDを前提においたコードレビューで飛び出した指摘でした。

コードはかなりシンプルな、ユーザからの投稿とそれに関する感想を閲覧する、といったサービスに関するものでした。 こういった場合、当然のように、『”投稿”がトップレベルのオブジェクトにあり、それにぶら下がる形で”感想”オブジェクトがある』という様なモデル化をしていました。

一方このドメインにおいては、投稿もさることながら、投稿に対する感想の方がドメインにおける重要な関心事、なのでした。

それを話した時に、弊社増田の口から飛び出たのが、、、

「んで、それはソースコードの何処に書いてあるの?」

実装に構造を語らせるために

この時、僕は軽く衝撃を受けました。

「だって、ソースコード見てそのドメインの関心事が分からなければ、3年後見た時にわかると思う?」

…はい、分かりませんよね。そりゃあ。

そう、エヴァンスのDDD本に書いてあった、以下の一節は、そういうことを言っています。

ある種の意思決定をすることによって、モデルと実装の協調が保たれ、互いがもう一方の効果を高めるようになる。

— 『エリック・エヴァンスのドメイン駆動設計』 第二章の導入より

モデルと実装が、協調している。モデル通りの実装になっているし、実装からモデルがわかる。そのモデルというのは、ただの設計構造ではなく、顧客の関心ごとを反映した「ドメイン」である、ということ。

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

「それに答えなんかないですよ。色々実験してみることです。例えば、感想が重要な関心事なら 主従関係をひっくり返して、感想を投稿の親にしてみては?」

確かに、ソースコードで物を語るには、クラスの所有関係を表すのが一番です。なんとなく、理屈で収まりがいいツリー構造を考えてしまいますが、勇気を持って構造を組み替えたりして、色々実験しなければなりません。

確かに、DDDではリポジトリという形で、永続化処理をドメインから分離しています。そうすることで、永続化層の理屈をドメインから分離し、ドメインの中で腹落ちするようなモデルを構築していくのですね。

ドメインの設計を、ソフトウェアシステムにおけるその他の大量の関心事から分離することで、設計とモデルとのつながりが非常に明確になる。

— 『エリック・エヴァンスのドメイン駆動設計』 第二章の導入より

と、偉そうなことを書いていますが、私もまだまだ勉強中の身。これからも色々と実験を重ねていきたいと思います。

ギルドワークスでは、こうやってドメインのあるべき構造を追い求めてくれるような、ギルドメンバーを引き続き募集中です!興味を持たれた方は、こちらからどうぞ

1573998777_d19fe34cbe_o

エクストリームプログラミング 第二版 でXPに再入門しています。 #xpe2nd

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

さて、皆さんはもうお読みになりましたよね!新訳版エクストリームプログラミング!非常の楽しい本なので、是非皆さんもチェックしていただければと思っています。

XPへの誤解

さて、このようにテンション高く始めてしまいましたが、私は実はXPの旧訳は読んだことがありませんでした。のみならず、XPをテーマにした本自体を、あまり読んでいませんでした。

実は私と同世代くらいの(昭和ギリギリ50年代くらい生まれくらいの)エンジニアには、結構同じ境遇の人、あんまりXPに関する書籍を読んでいない、という方が多いのではないかな?と思ったりしています。

なぜでしょう?それは、私がソフトウェアを本格的に勉強し始めたのと時を同じくして、XPの熱狂は去り、Scrumの波がやってきた、ように見えたのです。

その時、ソフトウェアの入門者を取り囲む空気には、少なからず偏見のようなものがあったと思っています。「XPは技術寄り」「Scrumの方がフレームワークとして定まっているので組織に入れやすい」「XPはスーパーエンジニア向けのもの」など、XPは効果的なんだろうけれど、とても導入が難しいエクストリームなものという言説は、同時いわれていたのではないでしょうか?

ギルドワークスにおけるXP

実はギルドワークスに入ってからも、少なからずこういったイメージを持ってしまっていたのですが、増田さんや市谷さんなど、ギルドワークスのメンバーから、XPの価値原則について、何度も熱く語ってもらいました。

XPといえばどうしても、全員同席テストファーストなどのプラクティスが強調され印象に残ってしまっていたので、XPの価値と原則について、改めて考えなければ、と思っていたのでした。

そんな時にちょうど出版されたのが、新訳版エクストリームプログラミングです。迷わず手を取り、読み始めました。

XPの価値と原則

まず、びっくりしたのは、最初の一文です。

エクストリームプログラミング(XP)とはソーシャルチェンジである。

帯にも書いてあるこの言葉は、本文の最初に出てくる言葉です。

ソーシャルチェンジってなによ?となりますが、あとがきで簡単に触れられています。

XPは必ずしも「社会」を変えるための活動ではない。隣の席にいるプログラマとうまくコミュニケーションしたり、顧客と密接にやりとりしたり、ユーザーが安心して使えるソフトウェアを届けたりする。そうした「人間関係」を扱う活動こそが、エクストリームプログラミングである。

そう、XPのというとバリバリの技術に尖った手法、というイメージを持ってしまっていたのですが、違います。人間関係を、仕事をしやすいよう変えていくのが、XPなのです。

なので、XPの価値には“コミュニケーション”“勇気”といった、人間関係を透明でわかりやすく、話しやすくする仕組みが埋め込まれていますし、原則にも”人間性“や”多様性”など、人間関係を豊かにする活動が詰め込まれています。

プラクティス以前に語られる、こういった価値と原則は、実はギルドワークスの「正しいものを正しくつくる」「越境」といった言葉に非常に密接にリンクしている、ということに遅まきながら気づいたのでした。

私も、皆さんと一緒に、自分の周りを Social Change していきたいと思います!

※アイキャッチの写真 https://flic.kr/p/3p69ZX

8117046049_12e955f7b2_o

リモート開発のコミュニケーションで意識しておきたいこと

上野です。
今回はリモート開発におけるコミュニケーションの意識の仕方について書いてみます。

ギルドワークスでは開発を様々な地域の方々と組んで行っております。
基本的にオフィスに集まることがないので、東京の人でも実質はリモートワークになります。

そんなギルドワークスのリモートワークでの主なコミュニケーションはSlackです。また会話が必要な定例MTGなどはSkypeで行っています。

「コミュニケーションを取る」という意味では、この2つのツールでほぼカバーできます。しかし、ツールだけでコミュニケーションが成り立つわけではありません。

ネットワーク越しゆえ、意識してコミュニケーションを取らないとほとんど会話がないこともあります。
こういう状況が続くと「正しいものが正しくつくれていない」ことになります。

  • 誰が何をやっているのかわからない。
  • どうあるべきかわからない。

思い込みで作ってしまってプルリクで指摘されて違っていることに気がつけないということも起こりえてしまいます。

このような状況にならないために意識していることを上げてみます。

雑談できる場をつくる

仕様や機能のことだけを話しましょうとしても限界があります。
なので雑談したり、画像貼ったりという「席の隣同士でちょっと雑談する」ような場につくるようにしています。
常に雑談をし続ける場であるのではなく、他愛もない会話ができる場であることで、ここどういう機能でしたっけ?であったり、どうあるといいんだろうという議論をしやすくする狙いがあります。

定期的に顔を見て話す

直接会えるなら直接会える場を作りましょう。
遠距離であればSkypeでも構いません。
音声で話せばいいというわけではなく、カメラでお互いの顔を見て話すようにするのがポイントです。
文字だけでは相手の表情が分からず、実は困っていることがわからないこともあります。顔を見て話すことで意外と分かり合えることもあります。

最初に会いに行く

リモート開発だから会う必要がないことはありません。
一度対面で会って話をすることがプロジェクト開始後もコミュニケーションを取りやすいと感じています。
相手の顔を知る、相手の環境を知るというのは思いの外重要なことです。

こちらの記事も参考にしてください。
リモートワーク隆盛のいまこそ、パートナーに会いに行く

簡単なことが、意外とできなかったり
気が付くとコミュニケーションが止まっていたりというのがリモート開発では起こりやすいことだったりします。

ギルドワークスではリモート開発を行うにあたり上記のようなことを意識して開発を行っております。

私達と組んで熱く語り合い、「正しいものを正しく作る」仲間も募集しています。是非お声かけ下さいませ。

※アイキャッチの写真:https://www.flickr.com/photos/86979666@N00/8117046049/

14485059353_8d009d4eb3_b

開発チームのビルドをどのように始めるか

ギルドワークス市谷です。

ギルドワークスで手がけている開発プロジェクトは、チームメンバーがだいたいリモートワークで参画しています。ギルドワークス自体も、仙台や大阪で開発しているメンバーがいますし、一緒に組んでいるフリーランスのデベロッパーも、東京にかぎらず日本の場所を問わず参画してもらっています。東京在住であったとしても、所在が離れあっているため、結局どのような立ち位置であれリモートワークなチームとなるわけです。

リモートワークに限らず、チーム運営を間違えると「何を何のために作っているのか」が見えにくくなりがちです。目の前のバックログを倒して続けていれば、目的にあったプロダクトがいつ出来上がるだろうというのは、いくら何でも楽観的過ぎますよね。プロダクトオーナーと目線を同じくとしたチームでなければ、期待するプロダクトを作り出すのは難しいところです。プロダクトオーナーやチームの他メンバーとの接点が少ない、限られる場合には、意識を高く持ち保つにはさらに不利といえます。では、どのようにしてチームビルドを始めると良いでしょうか。

ギルドワークスでは「何を何のためにどれだけ作るか」を見定める、いわば開発の入口を整えるために価値探索というフェーズを設けるようにしています。我々が仮説キャンバスと呼んでいる一枚絵でコンセプトをまとめ、仮説検証を行なうようにしています。検証を終えるまで、開発は始めません。No Why, No Devの考えを取っています。

結果、開発を始める際には「コンセプトが簡潔にまとめられた検証済みの一枚絵」「ユーザー行動に基づいて整理された必要な初期のバックログ群」が用意されており、「プロジェクトの方針を可視化したインセプションデッキ」づくり、そして「バックログの手入れ(内容を理解し、開発可能に仕立てていく)」からプロジェクトをスタートするのです。「何を何のために作るのか」の背景のすりあわせ、ディスカッションをチーム全員で行います。

プロジェクト立ち上げの時期は、さらにプロダクトの初期モデリングをチームで行うようにしています。インプットとなる情報から叩き台となるモデルを作り議論したり、白紙のホワイトボードから全員でモデリングを始めたり、やり方は様々です。この初期モデリングを通じて、このプロジェクトにおける関心領域は何なのか、その可視化と共通理解を作ることを目的としてやります。この際には、一箇所に集まるか、オンラインでアウトプットを共有しながら進めます。

以上のように、開発プロジェクトを始める際には私たちは「状況作り」を重視しています。時間は相応かかりますが、この時間を惜しんだばかりに、後々途方も無いすれ違いを生んでしまいかねないことを考えると、躊躇の必要がない取り組みといえます。

ギルドワークスの取り組みをご紹介する場「開発者ギルドカンファンレンス」を設けました。ぜひご参加ください。

26156_normal_1435841034_doorkeeper用バナー

Two facing laptops with an arm emerging from each screen and shaking hands on a white background

リモートワーク隆盛のいまこそ、パートナーに会いに行く

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

先日、市谷と私がそれぞれ島根でお話をしてきたのを、ご報告させていただきました。

さて、島根にはもちろんAgile Shimane の皆さんにお会いする、という目的もあったのですが、もう一つギルドワークスとして重要な目的が有りました。

実は今、ある開発をギルドメンバーとして一緒に進めているエンジニアの方が、島根は出雲に本拠を置いていらっしゃるのです。

もちろんこれまでもSlackやSkype、そしてGithubなどを通して十分なコミュニケーションは取っていました。仕様を伝えて、見積もりを伝えて、コードをコミットし合い、進捗を確認して、LGTMして、などなど。

でも、これらのやりとりは、ともするとビジネスライクで「表面的」な関係になってしまいます。ギルドワークスは、お客さんだけでなく、ギルドメンバーともお互いに越境したい。仕様について「これでいいの?」「コンセプトからするとこうあるべきなのでは?」と語り合ったり、設計について「こうすればもっとお客さんのドメインを表現できる」と深く探求したり、など、もっとお互い踏み込んだコミュニケーションをしたい、と考えています。

それには、やはり文字や音声だけのやりとりだけでは、圧倒的に情報が足りません。どんな環境で仕事をされているのか。お昼はどんな場所で食べておられるのか。仕事を終えた後はどんなところで飲んでおられるのか。飲みながら、どんな思いで開発について語っておられるのか・・・

今回の島根訪問では、ギルドメンバーのこういった熱い思いを、しっかりと聞くことができました。出雲蕎麦を食べながら会社を設立された熱い思いを伺い、終電ギリギリまで駅前のバーで技術話で盛り上がり、なんとも楽しい時間でした!

リモートでほぼ仕事ができる環境が整っているからこそ、敢えて直接話しをしに行く。そこで意気投合した気持ちを軸に、もっと深い話をSlackやSkypeで発信していく。

まさに、今そういう開発ができているように思います。

これからも、全国に散らばる仲間たちと、語らいに出かけようと思っています。

そして、私達と組んで熱く語り合い、「正しいものを正しく作る」仲間も募集しています。是非お声かけ下さいませ。

アイキャッチ画像: https://flic.kr/p/c1iJvo