works

この blog では今やっていることも含め、なるべく旬な ShakeSoul の様子をお伝えできればと思っています。
今回は今まさにやっているお仕事の紹介。

実は7月末あたりからコミュニティーエンジンさんとお仕事していて、初台によく通っています。長期にわたるプロジェクトになるのでおそらく今後数ヶ月間一緒に続けて行くことになる見込みです。

コミュニティーエンジンはオンラインゲームの開発を効率化するミドルウエアを製品としてリリースしていて、その他Webの開発やサービス立ち上げのコンサルティングなども手がけているソフトエンジニア集団で、エンジニアドリブンな会社です。

彼らと会話をしたり仕事を進めて行く中で学んだことと気づいたことがいくつかあったので紹介すると、

• 用語の定義は大事
  ゲームでよく出てくる用語として「アイテム」「装備」とかかがありますが、実はサービスごとにその意味が若干違ったりします。その違いはシステムを作る上で致命的な不整合を生むので、この「暗黙の了解」のようなものを排除するために「＊＊とは？＊＊＊である」という、用語の定義をしっかりしてます。
  お互いの共通認識を作るために、まず最初にやるのが用語の定義になっている気がします。
• 名前が大事
  これも用語に通じるところがありますが、モジュールやプロセスに対するネーミングは誰が見ても分かりやすいものにする必要があります。これも共通認識を作る上で大事なことで、分かりづらいまたは本来の意味とは異なるイメージを持たれてしまわないように、良い名前を考えるのも大事にしている気がします。
  用語の定義と違うのはネーミングセンスのようなものが必要なところだと思います。
• 分かる分からないを明確に意見する
  エンジニアと話していて思うのは、不明確やなぁなぁな部分はなるべくその場で「分からない」と明確に意見してくれることかと思います。これはすごくありがたいと思っているのですが、不明点はどこかの時点でなくさなくてはいけないし、実際コーディングするエンジニアが明確になっていないと進まないので、そのこと自体をエンジニアがよく理解していることの現れでないかと思います。
• 対外的な分かりやすいドキュメントを作ることも重視する
  Web作りを早くする時にはソースのコメントで示してなるべくドキュメントは最低限にする。という考え方もありますが、誰もが分かる単純化したドキュメントもエンジニアがつくっているのが結構驚きでした。
  受託開発なので発注者に示すという意味もあると思いますが、プロジェクトに関わる他のエンジニア、顧客とのインターフェイスになる人など社内の人も含め作っているものの内容を知ってもらうために作っている気がします。これも複数名で取り組む際の共通認識を作る大事なことだと思います。

いくつか書きましたが、他の会社さんと一緒に仕事するとその会社の文化が分かって面白いし勉強にもなります。
私にとって非常に良い刺激になっているので、私も良いパフォーマンスをしてうまくプロジェクトに反映していければと思っています。

今後も仕事の様子などを紹介できればと思います。お楽しみに〜

提案してみました。

まずは基本業務内容の金額にOKが出れば1年間の売上目標の半分以上いくので良いかと思っていて、障害対応の部分はプラスアルファの金額としてみてますが、さすがに24時間はもう割けられないのであまり時間が取られない環境にしたいところです。

こちらとしては早めにお返事いただきたいけど、それは向こうの事情もあることだけどもなるべくこちらのペースで早めにコミットさせてしまいたいところ。

現状の会社との話がある程度進んだので、会社自体の2009年02月スタートが確定になりました。

そこからは対会社としてどうなることやら未確定ですが、引き続きサービスのインフラ部分とシステム運用部分をやらせてもらえたらと思ってます。

一応、12月中にはやる/やらない、やる場合の業務内容を決めたいところです。