正しいものを正しくつくる 開発

このようなことでお悩みではないですか?

  • 開発会社に依頼しても、なかなか動くモノができあがらず意図どおりのプロダクトにならない
  • システムはできたもののビジネスの変化に応じた拡張ができない
  • つくり手の観点からさまざまなアイデアを出してもらい、一体となって良いモノをつくりたい

ギルドワークスの開発とは?

エンジニアがアイデアを実現する
  • ユーザーに使われるものこそをつくる
  • アイデアを素早く形にし、動くプロダクトで市場に問う
  • これまでの環境や生活、状況を変えるために必要なプロダクトを創る
  • 上野

  • 佐々木

  • 今橋

開発で実際に手を動かしてプロダクトをつくる、職人ともいえる役割がわたしたちエンジニアです。

プロダクトをカタチにする役割を担うエンジニアだからこそ、コードでプロダクトや事業を駆動する
アイデアをすばやくコードに繋ぎ、動くプロダクトでもって、顧客、ユーザーが評価しつづけることで、ソフトウェアが洗練され、サービスが成長し、ビジネスが発展するとわたしたちは考えています。

つくり手の観点からも、ビジネスに対してさまざまなアイデアを出し、チームで一体となって良いモノをつくっていくことをお約束します。

ユーザーにとって価値のあるものを開発する

ソフトウェアの開発も、ひとむかしまえに比べると便利なツールがたくさん出てきてかなり身近になりました。
しかし、比較的容易に、安価に開発が行えるようになったことと比例するかのように、「できあがったソフトウェアが想像と違った」「アイデアをまったく反映していないシステムができあがった」という課題もかつてなく増えています

ギルドワークスでは、「いわれたものをただつくるだけ」や「なぜつくるのか?という理由のない開発」はしません。
お客様が実現したいプロダクトの価値は何か。ユーザーにとって価値のあるものは何か。それらを実現するためにソフトウェアはどのようにあるべきか
お客様、ユーザー、ソフトウェア開発チームがひとつとなって、これらの問いに答えながら開発を進めます。

お客様のビジネスの成功を目指す開発

なぜそのソフトウェアをつくるのかということを考えると、必ず「お客様のビジネスの成功のために」が大前提となります。

通常の開発では、お客様にまず事業化をしていただいてから仕様書をつくったり開発を始めたりしますが、ギルドワークスではそれではリスクが大きいと考えています。
事業化をするまでに価値探索をしてそのプロダクトに価値があるかどうかを検証し、さらに実用最小限の動くプロダクト(MVP)までつくります。ここではじめて事業化できるかどうかがわかるからです

通常の開発の流れ
ギルドワークスの提案する開発の流れ

アイデアをすばやくコードに繋ぎ、動くプロダクトをいちはやく確認していただくために、開発は、週単位という短いサイクルで反復的に行います。
短いサイクルで開発を回すことで、フィードバックの取り込みをより素早く実現できるからです

お客様からのレビューや、必要であればユーザーへのインタビューなども週1回という短いサイクルで行い、改善を繰り返しながら理想とされるソフトウェアへ近づける手法をとります(アジャイル開発)。
これにより、意思疎通のためだけの膨大なドキュメント(仕様書)を作成する必要がなく、実用最小限で動くプロダクトをいち早く市場に投下することができるため、プロダクトの価値を問い直すことも、また、別の方向へ発展させていくこともできます。

アイデアやビジネスは、「ソフトウェアを利用する人の関心事」であると言い換えることができます。ギルドワークスの開発においては、「ソフトウェアを利用する人の関心事=ドメイン」を常に意識しています。
ドメイン駆動設計
ギルドワークスでは、価値探索や開発の活動の中で、様々な関係者の関心事=ドメインを、対話を通じて捉えます。
そうやって得たドメインの知識=言葉を研ぎ澄ませ、モデルとして実装し、動くソフトウェアプロダクトとして成長させていきます

ドメインと実装を合致させていくと、クライアントの関心事とソフトウェアの動く仕組みが近づいていきます。そうすることで、仕様の変更や追加にも、大きく構造を変化させることなく、しなやかに対応していくことができ、結果的に変更コストやメンテナンスコストが低い、的を得たソフトウェアをつくることができます
アイデアや企画をソフトウェアとして実現し、お客様のビジネスの成功を目指すからこそできる、ギルドワークスならではの開発だと考えています。

クラウドサービスを活用し、リモートワークも可能に

ギルドワークスのメンバーも、ギルガメッシュも、開発はリモートワークが中心。リモートワークを後押しするクラウサービスを活用しています。

場所や時間の制約がないということは、エンジニアにとってはムダなことが一切ない理想的なスタイル。
エンジニアの開発効率を落とさないために、リモートワークというワークスタイルを取っています。

お客様の声

株式会社クラフル 代表取締役社長 大野 拓海氏

http://www.craful.jp/

クラフルは事業構想などは固まっていたものの、会社設立した直後ということもありチーム内にエンジニアがいない状態でサービスとして具現化できない状態でした。
また、私たちはスタートアップで限られたリソースの中で、スピードを持って開発する必要があったということもあり、外注先というよりワンチームのメンバーとしていっしょに動いてくれるギルドワークスに「Craful」のMVP(実用最小限の動くプロダクト)開発の依頼をしました。

USM(ユーザーストーリーマッピング)などをいっしょに作成することで、世界観・価値観を共有しながら最初のプロダクトに必要な最低限必要な機能を洗い出せ、スピード感をもって開発・リリースすることができました。

お役に立てました

ご要望、ご状況をお伺いした上で、適切な解決方法をご提案しますので、お気軽にご相談ください。

  • 開発会社に依頼しても、なかなか動くモノが見れず意図どおりのプロダクトができない
  • 半年も待ったのにイメージと違うシステムが納品されてしまった
  • システムはできたがビジネスの変化に応じた拡張ができない
  • つくったシステムが数年しかもたなくて困っている

お気軽にお問い合わせください

お問い合わせ Contact