読者です 読者をやめる 読者になる 読者になる

Gaiax Engineers' Blog

Gaiaxの技術者ブログです. 社内の様子をありのままにお伝えしていきます.

スクラムを始めて2年、現在のプロジェクトの形

Advent Calendar

こんにちは。Gaiax 技術開発部の菊池です。
この記事は、Gaiax Advent Calendar 2016 - Qiitaの15日目の記事です。

はじめに

今回は自分がスクラムマスターとして活動しているプロジェクトでのスクラムについて紹介をしたいと思います。
スクラムマスターとしては3つ目のプロジェクトです。初めてスクラムを知った時から、2年ほど経過しようとしていて、その間にCSM(認定スクラムマスター)とCSPO(認定スクラムプロダクトオーナー)の研修を受講し、認定を受けています。
現在のプロジェクトでは、スクラムの形がほぼ出来上がってきたと感じていて、今の所のスクラムへの取り組みの答えなのかなと感じています。そんなプロジェクトを紹介したいと思います。


開発しているプロダクト

開発しているプロダクトはTRUST DOCKという本人確認のサービスです。

trustdock.io

身分証をアップロードし、その身分証に不正がないか確認したり、本人のものかなど包括的に確認を行うサービスです。個人の信用が重要となるWEBサービスにおいて、広く展開をさせていきたいと考えています。


チームの構成

チームの構成は開発者が二人、プロダクトオーナーが1名、スクラムマスターが1人の4人体制です。
開発チームは経験豊富なエンジニアと2年目の若手エンジニアです。プロダクトオーナーは開発の経験があり、開発者と技術的な会話もすることができるプロダクトオーナーです。
そしてスクラムマスターが自分です。自分の役割としては、スクラムマスター以外に、サービスのUXを設計したり、開発の経験を通して開発チームの相談役などもしています。
スクラムマスターとの兼務は、できれば避けたいところではありますが、帽子をうまくかぶりわけ活動しています。


開発で利用しているツール

開発の中で使っているツールは次の2つです。開発で利用しているテストなどのサービスなどもありますが、スクラムのお話なので今回は割愛します。

GitHub

みなさんご存知、ソース管理はGitHubで行っています。スクラムにおけるストーリーも、trustdock-issuesというレポジトリを単独で作成し、こちらで管理しています。

Slack

チーム内のチャットでのコミュニケーションにはSlackを利用しています。共有、相談などのチャンネルのほか、フィードバックの通知チャンネルや、アラートなどの通知もSlackに流れるようになっています。
対面で話せるような座席に配置しているので、何か課題があった場合などは、すぐ後ろを振り返ってその時々解決しています。チャットツールを介して議論を行うとエビデンスとして残るメリットもありますが、そういう内容の場合は、対面ですぐさま解決しつつ、必要があればissueに記載するようにしています。


スクラムイベントとそのサイクル

スクラムで実施しているイベント(タイムボックス)は次の通りです。

スプリント:1週間

開発のひと回しです。プランニングから始まり、実装、レビュー、振り返りまでを指します。

スプリントプランニング(計画):2時間

スプリントの計画を行います。水曜日の午前中に実施しています。

朝会(デイリースクラム):15分

毎朝10:00に実施しています。「昨日実施した内容」「今日の実施予定」「スプリントゴールに向かって障害になること」「ニコカレの顔確認」「レトロスペクティブの内容再確認」を実施しています。

プロダクトオーナーレビュー:1時間

プロダクトオーナーへデモを実施し、受け入れ条件をクリアしているか確認します。

スプリントレトロスペクティブ:1時間

スプリントの振り返りを実施しています。振り返りの内容を次スプリントへ活かしています。

プロダクトバックログリファインメント:1時間

優先度順に並べられたストーリーに対して、開発チームとプロダクトオーナーが完了条件などの合意をとり、さらに優先順位が正しいか確認します。

相対見積もり会:1時間

開発により実施されています。リファインメントでプロダクトオーナーと完了条件の合意が取れたもののうち、見積もりされていないストーリーに対して相対見積もりがされます。

スクラム以外で実施していること

インセプションデッキ

事業としてのチーム内での合意形成にはインセプションデッキを利用しています。合意のとれたインセプションデッキは印刷していつでもチームが確認できるよう貼り出しています。変更などがあった場合はメンテナンスを実施します。

がんばった会

何かを成し遂げた、しんどくなった時はみんなで夕ご飯を食べに行き元気を出します。


イベントごとの様子や工夫

それではもう少し詳しく各イベント毎の状況や工夫を紹介します。スプリントは現在28(28週)まできています。

スプリントプランニング:2時間(水曜午前中)

スプリントプランニングでは、これから始まるスプリトでどこまで実装できるか検討します。今回のプロジェクトでは、ストーリーの見積もりを相対的に見積もっています。相対見積もりとは、実時間での見積もりではなく、実装の大きさを基準となるストーリーからどれくらい差があるかという観点で見積もりをします。
前スプリントで実装できた相対見積もりのポイント数(実績)から、今回のスプリントでどのストーリーまで実装できるかプロダクトバックログからおおまかに割り出します。
その後、ストーリーを実装のタスクレベルまで落とし込み、実時間見積もりをおおよそでしています。このとき、どうしても発生してしまうプロジェクト外のタスク(例えばこういう記事の執筆や、勉強会など)も同時に洗い出し、スプリントの計画をたてます。洗い出された開発タスクはGitGubのissueで管理されているストーリーの詳細に転記し、実装もれなどないようチェックリストとして機能します。
この時プロダクトオーナーも参加して、内容の確認を行いながらチームでの合意を取ります。 f:id:sohismyson:20161215130314j:plain

朝会:15分程度(毎朝)

朝会では、「昨日実施した内容」「今日の実施予定」「スプリントゴールに向かって障害になること」「ニコニコカレンダーの顔確認」「レトロスペクティブの内容再確認」を実施しています。
完結に共有相談できるよう、各自が事前に考え「真剣に参加する」よう促しています。スクラムのTipsにある、障害になることは別に時間を切り出して、関係者だけで議論することはしていません。小さなチームですので、課題があればその場で解決しています。タスクの実装は基本的に個人で行いますが、成果はチームとして出す意識を持ち、遅延などあれば積極的にフォローしあいます。 f:id:sohismyson:20161215112433j:plain
ニコニコカレンダーも取り入れていて、各自の今日の体調や気持ちの表情シールをスプリントバーンダウンチャートに貼り付けています。チーム内の雰囲気も把握できますし、お互いフォローもし合えるのでよい取り組みです。 f:id:sohismyson:20161215125447j:plain
また、レトロスプクティブであげたトライすることもできる限り確認しています。
最後に「今日も1日、宜しくお願いします!」と声をだし(オフィス内なので大声はだせません)メリハリをつけて1日のスタートを切っています。

プロダクトオーナーレビュー:1時間(火曜午後)

スプリントで実装されたストーリーが完了条件を満たしているか、開発からプロダクトオーナーに対してデモがされます。開発は円滑なデモができるよう、デモを想定したデータ作成やデモの順番などを事前に準備しています。スクラムマスターは進行だけを行い開発がメインで実施します。
完了条件を満たしたものはDoneとし、万一足りなかった場合は差し戻し、追加の要素が出てきた場合は、別のストーリーとして切り出し、プロダクトバックログに追加されます。
Doneにできた時は、チーム全員で喜び小さい音でですが拍手をし、達成感をしっかり感じるようにしています。 Doneできなかった時は、後のレトロスペクティブで原因などを考え対策を検討します。

スプリントレトロスペクティブ:1時間(火曜午後)

スプリントの振り返りです。KPT法を用いて実施しています。
Keepではスプリントないで良かったことや、継続して続けていきたいことを考え付箋に記載し貼り出して行きます。続けて発生した課題をProblemとして貼りだします。このProblemから特に解決したいことをピックアップし解決策をチーム全員で検討します。次回のレトロスペクティブの冒頭で、このTryとしてあげた解決策が実施され、課題が解決されているか確認を行います。 f:id:sohismyson:20161215125654j:plain
レトロスペクティブの時間は、チームに向き合うとともに、自分へも矢印を向け振り返りを行います。自分の課題を他のメンバーの前で発表する事はとても勇気が必要なことですが、しっかり共有されています。これはとても素晴らしいことだとチーム全員が感じていて、チームでアイデアをだしたり課題解決に向けて活動をします。 スクラムの自己組織化と振り返りを通じた自分たちの活動の最適化のコアになる活動であり、とても重要なイベントです。
ただ、形骸化もしやすいのもあり、おやつや飲み物を用意して雰囲気をコントールしたり、振り返りすることの意味を改めて考えるなどして活動を続けています。

プロダクトバックログリファインメント:1時間(月曜午前中)

プロダクトバックログ(PBL)のメンテナンスをする時間です。PBLは実装するストーリーが一意の優先度順に並べられたものです。この順番に変更が無いかと、完了条件の合意が取れていないストーリーについて、プロダクトオーナーから説明をうけ、チームで完了条件を作り合意して行きます。
おおよそ3スプリント先くらいまで分のストーリーをストックできるよう、リファインメントを実施しています。余裕がある際は、優先度に変更がない時に限りスキップもしています。
プロダクトオーナーから提示された内容を鵜呑みにするのではなく、当事者意識をもちチーム全員で整合性などを検討します。

相対見積もり会

リファインメントで完了条件の合意が取れたストーリーに対して相対見積もりを行います。相対見積もりする際にチーム内で意見をすり合わせ、だいたいの実装方針がきめられます。この時、お互いフォローできるような体制が出来上がります。プランニングポーカーを用いて実施しています。この見積もりに時間をかけすぎるのも好ましくないので、時間を気にしながら実施しています。


まとめ

現在のこの形は、プロジェクトのチームがスクラムを通して改善してきた積み重ねの結果です。紆余曲折ありながらも、真摯に向き合った結果、今があると考えています。
開発チームも、サービスを自分たちのものと捉え積極的に活動しますし、チャレンジや改善活動を重ね、技術的にもエンジニア的にも成長を続けています。プロダクトオーナーも、初めはプロダクトオーナーの役割がわからず勉強してもらい、多くのディスカッションを重ねてきました。いろいろなスクラムの事例を見ていますが、今の所自分の中では最強のプロダクトオーナーだと感じています。
ただ、まだ改善できる余地はあると思うので、ダッシュして息切れしない程度に走り続けたいと思います。スクラムという手法に関していうと、数ある開発手法の1つだとは思っていて、課題もあるとは感じますが、よい仕組みだと感じていますし、これまからも続けていきたいと思います。スクラムについてなど、何かお話したいことがあればお気軽に声をかけていただければと思います。

サービスがより多くの人に利用していただき、世の中に価値を届けられるよう引き続きチームで頑張っていきたいと思います。
それではみなさま、良いお年を。

事業部制の組織形態と今思う大事にしたいこと

ガイアックスの技術責任者のhidehigoです。
Gaiax アドベントカレンダー Gaiax Advent Calendar 2016 - Qiita の8日目です。
昨年も1人1エントリで完走することができましたが、今年は、もう少しラインナップを広げて完走を目指します。お楽しみに!

今日は、少し組織寄りの話、思想寄りの話をします。
Gaiaxでは、全社の組織を、2015年から事業部制組織という形に切り替え運営しています。
昨年のエントリから少し引用します。

Gaiaxというのは、なかなかにボトムアップな風土の会社でして、事業の裁量を広げさらに加速すべく、この形態に移行しました。 私の考えですが、機能組織がいいか事業組織がいいか、は時によって最適が変わるものだと思っています。エンジニア/エンジニアリングは「機能」を担う面が強いため「機能か、事業か」という問題はエンジニアにとって実は大きな影響があります。 事業組織への移行の判断時、それから約1年経った現在、今のGaiaxには事業組織がベターと考えています。

Gaiaxのエンジニア組織について - Gaiax Engineers' Blog

今年1年では、事業が、子会社化してさらに自立度高く運営する、という選択をできる制度を作り、事業部制をさらに推し進めています。

上に引用した昨年のエントリでは触れませんでしたが、’エンジニアにとって実は大きな影響’というのは、一部のエンジニアにとって所属の部署が変わる、ということに留まりません。
事業部制において、事業所属のエンジニアは、事業の実現したいミッションにコミットし実現に全力を注ぐことになります。必然、エンジニアリングとしては、事業のサービスやアプリケーションの機能、ユーザーインターフェース、あるいはその実現スピードに重点を置くことになります。(もちろん何かをやらない、という話ではありません)。
一方で、技術開発部所属のエンジニアは、一段後方から事業を、また事業の開発チームを支える、たとえば共通のサービスを提供したり、開発プロセスや手法の強化のための支援、全社のセキュリティのルール整備などのように、支援の要素が増えます。
一つの会社に所属するエンジニアに、貢献方法に大きく2つのパターンができるということになりますし、マインドも必要なスキルセットも少し違うという状態になります。

ここのところ、そんな事業部制組織を運営する上で大事だと思うことを少し表現できるようになってきました。

キャリアパスと評価の仕組みをどうデザインするか
分散しがちなノウハウを集中するために、技術選択を集約するか
薄れていく全社の横のつながりをどう作るか
などいくつも大事な論点はありますし、制度や運用として整えられていくべきです。

一方で、メンバーひとりひとりがそうあってほしい、と願うところもあって、
それは、技術でもなく、心もちでありメンタリティについてなのですが、

自分と違うOOをリスペクトする

この点が重要だと考えています。

たとえば自分と違う職種
たとえば自分と違うキャリアの志向
たとえば自分と違うスキル
たとえば自分と違う価値観

さらにいうと、AかBかという二元論になる要素である場合に、自分でない他方をリスペクトするというのが絶対的に重要。

上記した、貢献の2つのパターンは二元論になりがちな要素です。
しかし、エンジニア人生通じてどちらかの貢献方法を決めなければいけないわけではないですし、 その時その時の興味や、伸ばしたい領域、取り組みたいことなどで変わるものですし。
たとえば、チームの誰かが、別のキャリア、ステップを希望するようになった。それは全力でリスペクトし、応援したい。

こうして書いたら、ほとんどの人は反論も感じないと思います。
でも、これと同じ構造の話がそこここにあるんじゃないかな。
それが、事業部制のデメリットとして表出し、感じられている一因じゃないかな、と考えています。

極端なケースでは「みんなと違う、わたし(たち)」という形でアイデンティティを保とうとしてしまうことさえ。
得てしてこれは、ネガティブなスパイラルを助長します。

最後に、

自分とは異なる考え方を受け入れられないのも、暴力のひとつの形です。それでは真の民主的精神は、一向に育たない。

これは、マハトマ・ガンジーの言葉ですが、ダイバーシティについての考え方として多く引用されています。
他者との違いを尊重し、応援しあえる。それが一体感やシナジーと呼ばれる行為・思いやりにつながる、そんな組織を目指したいと思います。

自分が作った小さなツールに自信を持とう

こんにちは、おがた (@xtetsuji) です。Gaiax では2015年6月に入社後、インフラチームという組織に属して、サーバハードウェアの取り扱いから大気汚染度の計測まで、幅広く担当させていただいています。

この記事は Gaiax Advent Calendar 2016 の 4日目です。

今回は「小さなツール」というテーマで書いてみることにしました。

簡単な自己紹介

私は2003年に学生を卒業してIT企業に入るまで、実は本気でプログラミングをしたことがありませんでした。もっとも、学生時代に授業等で BASIC や C を書いたことはありましたが、自分に必要だとも面白いとも感じなかったし、そもそも自分に向いているとすら思っていなかった。職業プログラマになってからも、バリバリ書くかと言われたら世代や経験年数が似たプログラマよりは全然書けないと思います。

社会人1年目の2003年は、ログファイルを集計する仕事があり、そこで Perl を使い始めたのが私と Perl との本格的な出会いでした。Perl を選んだ理由は、単に先輩方が Perl を書いていたからという理由。かれこれ10年以上 Perl を書いています。むしろ Perl 以外はそれほど書けません。

ガイアックスが3社目で在職1年数ヶ月となりました。ちなみに1社目約10年、2社目約10ヶ月という経歴です。

万能なツールを目指すべきか

1社目には、東京のオープン系ITエンジニアにしてはかなり長い年数在職していたので、その間に様々な先輩・後輩・同僚と出会い、様々な仕事を体験することができました。もちろん、商用サービスの開発を進めていたこともあれば、その周辺領域で大小様々な社内ツールの作成も行いました。

「せっかく社内ツールを作るなら万能ツールにしたい」と考えるのは自然な考えでしょう。私もあります。

しかしながら作成可能性を考えず万能ツールが作れたとしても、意外に使ってもらえなかったり、保守運用フェーズでの属人性の問題が露呈したり、そもそも日々変化を続ける業務に合わせるコストがツールの重厚長大さによって引き上げられる問題等、時間の経過に従って悩みが噴出する、そんな印象があります。

私もクラスファイルが何十何百にも及ぶ重厚長大な社内ツールを書いたことがありますが、努力の割に使ってもらえなかった思い出があります(作った楽しさは置いといて)。たとえ多少使ってもらえたとしても、重厚長大なツールはメンテナンスコストが掛かるのも無視できません。

そのツールを開発した私は、本来その業務から別の業務の開発に移っているはずなのに、前の業務の重厚長大なツールの保守のために呼ばれることもある。愚直な作業フローであればアルバイトを増やして対応できる業務が、重厚長大なツール自体がボトルネック、さらに悪いときには単一障害点になる状況もあるのです。それは他者が作った社内ツールでも似たような状況でした。

保守運用をする立場の私

凄腕プログラマが腕を振るえば何の問題も無い万能ツールが生まれるのかもしれませんが、誰しも凄腕ではないし未来予知ができるわけでもないので、ツールの保守運用を任される立場だと悩むことになります。

ガイアックスに入社してからは、自分でツールを作るより他者が作成したツールを保守運用する機会が多く、まさにツールの保守運用を任される立場というのが今の私かもしれません。

ガイアックスにある社内ツールはそれこそ大小様々。手を入れたくても何が起こるか分からないし作成者はもういないしで難儀している重厚長大な社内ツールもありますし、比較的気軽に手を入れても大丈夫な小粒な社内ツールというものもあります。前者の立場の気持ちも分かるので、開発者の当時の気持ちを考えながら保守運用の方法を考えるというのも私の仕事の醍醐味と言えましょう。

ガイアックスのエンジニア風土には、とにかく「無ければ作る、あってももっと良く作れそうなら作る」という精神を感じます。保守運用フェーズでの問題点を上述しましたが、「作る人」であるわけで、とてもポジティブな精神でしょう。問題点を解消する文書化だったりといった手法は、これから強化していってもいいと思います。

小さなツールが意外に喜ばれる

私は前職で大小様々な社内ツールを作りましたが、ある年の年末、後輩に「僕が作ったツールで今年一番だったものは何?」と聞いたことがあって、その回答に仰天したことがあります。

「おがたさんが書いた、数字を与えるとその長さのランダム文字列が返ってくる Perl スクリプト、あれ超役立っているんすよ!」

「え?」と素で声が出てしまいました。「あの色々なデータを取り出して集計できる管理ページとか、mod_perl であらゆるガラケーコンテンツを透過的に変換したりリダイレクトしたりするやつとか、もっとスゴイやつ書いたじゃん!?」とか言っても、得てして重厚長大ツールは大きすぎて存在に気づかないし、見えないところで透過的に処理する仕組みはそもそも見えないのです。

そのスクリプト、これぐらいだったような…。

#!/usr/bin/perl

use strict;
use warnings;

my $num = shift;
my @char = (“a”..”z”, “A”..”Z”, 0..9);

my $str = join “”, map { $char[ int rand @char ] } 1..$num;
print “$str\n”;

使用者にとって、そのツールが何千行何万行かは関係なく、目下の業務にどれだけ役立つかが大事なんですよね。この後輩の返答はしっかりと私の心に刻まれ、その後もオーバーテクノロジーの抑止などの教訓としています。

複雑なロジックが必要になる場合の一つの考え方 もちろん、上述の後輩が本当は「必要不可欠かつ無意識に使用していた」重厚長大ツールの存在に気づいていないだけということもあります。対峙している業務には一定以上の複雑さを持ったものもあり、それに対峙するには社内ツールも一定以上の複雑さを持つのは仕方がないでしょう。

複雑なツールを扱いやすい状態に置くにはどうすればいいか、数年前に色々考えたのですが、そのヒントの一つは「UNIXという考え方」という書籍にあるかもしれません。本書に書かれていることをざっくり言えば、「ツールは一つのことだけやる」「ツールを組み合わせる」ということでしょう(え、ざっくり過ぎる?)。

本書は ls コマンドですら複雑だと一喝します。ls は本来のファイルリストに集中すべきで、n*m のテーブル表示は別のコマンドが行う(ls はそのコマンドにパイプで出力を渡す)べきだとさえ言います。確かに自分が ls のメンテナだったら、(最初は楽しく書くかもしれませんが後々忙しくなったら)ファイルシステムを扱うこととテーブル表示を扱うことは分けて考えたいかもしれません。極端に感じることもありますが、それくらいの考え方でいないとツールはすぐ重厚長大になってしまい、保守が難しくなるのかもしれませんね。

こういう機能分離が意識される用語はいくつもありますが、一つは層(レイヤー)という言葉があります。具体例は枚挙に暇がないですが、Perl でウェブアプリケーションを作る際には Plack::Middleware を利用したり、その思想の根底には HTTP のリクエストフェーズがあったり、さらに OSI 参照モデルもあったり…。複雑なロジックが必要になる場合は、一つの方法として層という切り口で考えることで、一つ一つの問題を単純化できるかもしれません。

(まだもうちょっと追記予定です)

障害対応管理ツール「Reactio」のおもひで話

Advent Calendar

Reactio運営責任者の @norinux です。 2016年7月に、無料化してから気付けばまもなく半年を過ぎようとしています。 Gaiax Advent Calender に便乗して、Reactioについてすこしおもひで話をします。

Reactioとは?

2015年の5月に正式リリースした当時は、まだ数社しか利用していなかったサービスが、1年半以上立つと、400オーガニゼーションを超えるくらいに成長して来ました。

Reactioがどんなサービスかというと、下記の製品サイトをご覧ください! (雑なのはご愛敬でw)

reactio.jp

現在のサービス利用状況としては、登録されたインシデント数は合計26000インシデント以上。 自社利用を元に考えると、おためしで立てたテストや、ただ通知として利用しているケースなども含まれているかと思うので、すべてが実際に起きた障害としてカウントできないですが、平均すると一日50件近くのインシデントが日々登録されているという状況です。

そんな、Reactioが生まれた経緯をご紹介いたします。

Reactioが生まれたワケ

まだ当時(2013年頃)、私がインフラのリーダーを担当していた頃は、すべてオンプレミスで、1000ノード近くのサーバをインフラチームで運用していました。

やはり、1000ノード近くあると日々何かしらのトラブルが発生していました。 そのたびに、関係者への連絡、原因の調査、暫定対応、恒久対応の検討と実施、そして障害報告を作成するのが、チームの重い仕事のひとつでした。

ある日、いつものように発生したトラブルが、大問題に発展したのです。

それは、Aサービスという受託開発プロジェクトでした。 Aサービスには、A社という発注元の会社と、Gaiaxの開発チーム、私がいたインフラチームという三つのステークホルダーがあったのですが、その連携でミスが起こりました。

f:id:norinux:20161130233229p:plain

発生した大問題

  • 1:00
    • 障害が発生(インフラチーム)
      • H/W,OS,ミドルウェアに問題はなく、アプリケーションが原因でトラブルと判断
    • エスカレーション(インフラチーム)
      • インフラチームが、営業担当と、開発チームに電話で連絡
  • 1:30
    • 障害対応(開発チーム)
      • 営業担当が指揮して、開発チームで障害対応を実施
      • 営業担当がインフラチームに追加調査を依頼
      • インフラチームが、調査結果を報告
  • 2:00
    • 障害復旧(開発チーム)
      • 障害が復旧し、クライアントのA社に報告メールを送信
  • 3:00
    • 障害が発生(インフラチーム)
      • 開発チームで障害対応中で、継続アラートだと判断。
  • 9:00
    • 障害が発覚(クライアントA社)
      • ユーザからの報告でクライアントのA社がサービスが閲覧できないに気付く
      • A社から営業担当にエスカレーションされて発覚

もう私が気付いた時には、あとのまつりでした。 その数日後、この問題を部署内の会議で報告し、別の開発チームが、「なんとかしたいね!」と共感し立ち上がってくれて分析したのです。

今までの考え方は、連絡網を用意して予め用意した手順に沿って対応して、情報を整理した上で、原因分析して報告しましょうという考え方でした。

f:id:norinux:20161130233845p:plain

しかし、障害というのは「いつ」「どこで」「どんな問題」が起こるかわからないので、計画的な対策ではなく、反応性が非常に重要だったのです。 そして生まれたのが、Reactio(当時:Twinkling)という社内ツールでした。

f:id:norinux:20161130233931p:plain

その後は、事業としてサービス化したくさん社外に方々に利用頂けるようになりました。 自社特化した機能を使いやすくするために多くの改修を進めきて、いまでは無料化し少数精鋭で運用している状況ではあります。 それにしても、エンジニアが気付いた課題を、エンジニアが解決するツールを作って、 それが世の中のエンジニアが利用してもらうというのは、エンジニア冥利につきる最高の体験です。

最近は素晴らしく便利なSaaSが沢山あるので、わざわざ自社ツールを作るケースは減りつつあるとは思います。ましてや作れば負債を産んでしまうという考え方もあります。 しかし、はじめに誰が言ったかはしらないですが、「ないものは、つくるしかない。」というエンジニアドリブンな心持ちが、私は大好きです。

ちなみに、12/21に、「エンジニア交流会〜マル秘?こだわりに社内ツール社内ツール大公開!」という交流会イベントを開催しますので、興味のある方は是非ご参加ください!!! (※Reactioの話は一切しませんがw)

gaiax.connpass.com

以上!

関係性技術のフォーラムの総会で登壇してきました

f:id:gaiax-tech:20161121214625p:plain

CEATEC JAPAN 2016で展示してきましたでも書きましたが、ガイアックスは未来予測の新技術である「関係性技術」の産業化推進フォーラムである「モバイルソーシャライズシステムフォーラム」に参加しています。

去る11月10日、そのモバイルソーシャライズシステムフォーラムの総会が開催されました。80社以上が加入するこのフォーラムの総会は年1回行われ、1年間の活動報告や、翌年の役員の選出などが行われます。今回は、その1年間の活動報告の1つとして、会員企業を代表して、弊社の取り組みについて発表してきました。

活動の振り返り

まず、弊社が関係性技術と出会ってから、現在までの流れを振り返りました。ちょうど出会って2年。技術の成長とともに、弊社も実用化へ向けて一歩一歩進んできました。2年前は展示を見に来たお客さん側だったところから、共同展示という形で見せる側に回ってきたとことがわかります。 f:id:gaiax-tech:20161121214801p:plain

また、この1年間で、関係性技術をAPIレベルで使うことにチャンレンジし、Qiitaの記事のレコメンド機能を作り、技術の有用性を検証してきました。その結果、全くチューニングせずとも75%の精度で、リコメンドエンジンとして使えるという主観評価の結果がでました。
f:id:gaiax-tech:20161121215139p:plain


今後の展開

次に、これらの成果を今後どうつなげていくかについて、発表しました。これは、CEATECで出展したものと全く同じに内容になります。写真以外にハッシュタグが重要な役割を持つInstagramにおいて、いかにいいハッシュタグを選ぶかが運用の鍵になるため、いいハッシュタグをリコメンドするために、関係性技術が活用できるのではないかと考えています。

f:id:gaiax-tech:20161121214835p:plain


人材マッチング事業への応用例

人材マッチング事業への応用例も発表しました。そちらの内容につきましては、以下のサイトを御覧ください。

sairu.com

今後の取り組み

弊社の今後の取り組みについて、発表しました。関係性技術を事業で実用化すること、もっと違う応用方法を検討すること、そして、いちはやく提供していただいた関係性APIを今後他の会社で使うときのサポートを行うことを方針としております。 関係性APIの利用サポートに関しては、ノウハウの提供やライブラリの提供などを考えています。

f:id:gaiax-tech:20161121214901p:plain

新たなつながり

関係性技術がもたらすものは、データの解析だけではありません。会社と会社の新たな関係も生み出しています。

以前より、フォーラムの会員企業であった、エースチャイルド社と、弊社グループ会社のアディッシュのスクールガーディアン事業部が、このフォラームを通じてつながりました。エースチャイル社のSNS見守りアプリ「Filii」とアディッシュの匿名でいじめを通報できるスマホWEBサービス「Kids' Sign」による、コラボ企画が産まれています。

prtimes.jp

f:id:gaiax-tech:20161121214957p:plain

発表の後での懇親会では、検討から実用への流れが理解しやすいなど、たくさんのお言葉をいただきました。 このように、技術の検討から、応用の検討、そして会社間のコラボの創出など、新しい価値を生み出していく関係性技術を使って、ガイアックスの事業がより強くなるよう努めていきます。

この技術が使ってみたい、試してみたいと思いましたら、是非モバイルソーシャライズシステムフォーラムのサイトを訪れてみてください。

CEATEC JAPAN 2016で展示してきました

CEATEC JAPANとは CEATEC JAPANとはアジア最大級の最先端IT・エレクトロニクスの総合展示会で、広い幕張メッセを埋め尽くす、大きなイベントで、電機、ITはもとより自動車、ヘルスケアなど、幅広い企業が展示を行われ、多くの来場者で賑わうイベントになっています。

f:id:gaiax-tech:20161110115937p:plain ガイアックスは、2015年より未来予測の新技術「関係性技術」の産業化推進フォーラム「モバイルソーシャライズシステムフォーラム」に参画し、関係性技術の事業への展開の検討を行ってきました。

今回は、10月4日(火)・5日(水)にモバイルソーシャライズシステムフォーラムの幹事をされている、神戸デジタル・ラボ様のブースにお邪魔し、関係性技術の事業への応用事例を紹介してきました。

関係性技術について詳しくはこちらをご覧ください。 mssf.jp

観光マーケティング向け行動分析エンジンの展示

神戸デジタル・ラボ様の展示は、観光マーケティング向けの行動分析エンジンでした。長野県白馬村と共同で行っている実証実験において、観光客の行動を分析し立ち寄りニーズの予測など、観光産業への応用の検討について展示を行いました。この分析エンジン部分に関係性技術を使用しています。 f:id:gaiax-tech:20161110120010p:plain

ガイアックスは関係性技術のリコメンドへの応用例を展示

ガイアックスでは、関係性技術を使って、Qiitaの記事リコメンドを行う実験を行った結果、主観評価で75%の精度を得られ、技術の有用性を実証しました。そのさらなる展開として、ソーシャルメディア事業への応用例、人材マッチング事業への応用例を展示し、関係性技術を事業への展開へステップを提示しました。 f:id:gaiax-tech:20161110120030p:plain
今後も、展示会に技術展示を出展することがありましたら、毎回レポートしていきたいと思います。また、ガイアックスでは、関係性技術を応用し、データ解析の観点から、技術で事業をドライブしていきますので、また進展がありましたら、随時報告していきます。

ニュースリリース

株式会社神戸デジタル・ラボ
 http://www.kdl.co.jp/news/2016/10/ceatecjapan_2016.html

バイルシステムソーシャライズフォーラム
 http://mssf.jp/topics/2016/09/ceatecjapan-2016.html
 http://mssf.jp/topics/2016/10/ceatec2016doc.html

ガイアックス
 http://www.gaiax.co.jp/news/press/2016/0927-2/
 http://gaiax-blockchain.com/ceatec-japan-2016

最後に、多くのお客様にご来場いただき、ありがとうございました。

合同エンジニア勉強会

DIP株式会社さん、GMOメディア株式会社さんと勉強会を開催しました。

ガイアックスでは社内エンジニアによる、エンジニア勉強会を毎月開催しています。
基本的に内部のみの開催ですが、他社のエンジニアの情報や、社外の人がいる緊張感のある勉強会も行いたいと思い、6月に交流会を行ったGMOメディアさん、知人エンジニアが所属するDIPさんに話を持ち掛け、今回の合同開催となりました。

f:id:gaiax-tech:20161102182316j:plain

各社会社紹介の様子

まず、弊社ガイアックスの佐々木から会社紹介。 f:id:gaiax-tech:20161102183450j:plain 続いて、GMOメディアの天野さん。 f:id:gaiax-tech:20161102183455j:plain 続いてDIPの上田さん。
すいません、すいません、DIPさんの写真が撮れていません。(土下座)

気を取り直して、発表の様子を紹介

前半の部(4名)

1番手 Gaiax 小中(新卒1年目)

まずは、弊社ガイアックスの新卒1年目小中くんが発表しました。

f:id:gaiax-tech:20161102185134j:plain f:id:gaiax-tech:20161102183515j:plain

新卒1年目なのに発表がスムーズなのは関西出身だからか。
内容は、MySQLのインデックスについて、勉強しなおした内容を披露。
私は、勉強嫌いだからか、構造まで調べないんですよね。
INDEXの貼り方とか、経験とEXPLAINして覚えた人なので、初めて内部を理解しました。

2番手 DIP 友兼さん(新卒2年目)

続いてDIPさんの新卒2年目友兼(ともかね)さんの発表。

f:id:gaiax-tech:20161102185032j:plain f:id:gaiax-tech:20161102185143j:plain

外部での発表は初めてと言われてましたが、私の司会なんかより流暢な発表で、自分が恥ずかしくなりますよ、コレ。
発表の内容は、インターン制度を実行してみた話についてで、内容も面白く、よく考えられた構成でした。
さすがギロッポンいにしえ女子

3番手 adish 坪井(新卒2年目)

3番手は、ガイアックスのグループ会社adish所属の坪井くん。

f:id:gaiax-tech:20161102195018j:plain f:id:gaiax-tech:20161102191924j:plain

発表の内容は、LINE Messaging APIであれこれのタイトルでしたが、紆余曲折があり新サービス チャットボットのhitobo | アディッシュ株式会社アーキテクチャでした。
これがまた、いい感じの説明で、Fluxの解説が分かりやすく、楽しく開発が行われていることもよくわかりました。

ここまで新卒1年目、2年目の若者枠のフレッシュな内容でしたが、ここから開発や運用にまつわるコストや苦労話になりますw

4番手 DIP 栗生さん

年配枠から、まずはDIPの栗生さんより、LINEバイトルのお話し。

f:id:gaiax-tech:20161102191928j:plain
ここで問題発生。
なんと栗生さんご本人の写真が取れてない!!!

完全にいいわけですが、前半終了時に冒頭のいくら丼を提供するため、準備に追われていました。
そのため、写真を撮り忘れたのです、お許しを・・・

でも話は準備しながら、ちゃんと聞いてましたよ!
言っていいのかわかりませんが、負荷テストを行った際、問い合わせ数マックスを想定した場合、サーバ台数が○○台になって、恐ろしく準備に手間かかり、かつお金もかかるテストをしたという話は、耳がダンボになってました。

ここで15分の休憩をはさみ、いくらご飯の提供です。

続きを読む