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

Gaiax Engineers' Blog

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

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

こんにちは、おがた (@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分の休憩をはさみ、いくらご飯の提供です。

続きを読む

社内技術展示会「さきがけ展示会」を開催しました

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

ガイアックスには、「さきがけ」というチームがあります。このチームは、「自ら新たな技術を切り開き、事業の可能性を広げ続ける」をミッションとして、事業では抱えきれないような新規技術を、事業にさきがけて、技術探索、プロトタイピング、そして技術の社内展開などを行っています。

この「さきがけ」チームが「さきがけ展示会」と題し、社内向けに技術展示会を開催しました。

続きを読む

『駅すぱあと』のヴァル研究所さん見学会

8月3日(水)にヴァル研究所さんを見学に行ってきました。

経路検索アプリを提供する『駅すぱあと』のヴァル研究所さんでは、開発部門、営業部門から広報、そして総務のいたるところでカンバンやKPTを導入しているということをお聞きし、是非見学にとGaiax社の開発メンバー、総務の方たちとお邪魔しました。

入口を入ってすぐの受付ではペッパー君がお出迎えしてくれました。
f:id:gaiax-tech:20160805174721j:plain

受付横には明るくオープンの打合せスペースがありました。
f:id:gaiax-tech:20160805174724j:plain

本日、ヴァル研究所さん社内を案内していただく新井さん(写真中央の立ってる方)です。!
f:id:gaiax-tech:20160805174726j:plain

社内見学開始!

最初に案内いただいたのは通路にある壁一面のホワイトボード。
f:id:gaiax-tech:20160809141933j:plain
リリーストレイン(をオマージュしたマイルストーンのようなもの)を開発部内のチームごとに書いたもの。これは衝撃的でした。
各チームが、現在、何に注力しているかがよくわかり、チーム間の依頼もしやすくなっていると思います。
情報共有のための連絡会もあると思いますが、いつでも目にすることのできる形で目の前にあるとわかりやすいですよね。

検査チーム

try-100
f:id:gaiax-tech:20160809142012j:plain
自分の専門、部署を超えて何かするというチャレンジですね。
奉仕:誰かがちょっと忙しい、ちょっと困ってることを手伝ってあげる。
越境:他部署が抱えてる小さな問題、実はちょっと聞いてみれば答えが出ることだってあります。
いと楽し:いつもの業務に関係あることを、楽しく業務できるように工夫したこと。

楽しくなりますよね、こういうの。
昨期の下半期では100のtryを目標とし、400のtryを達成したそうです。半端ない・・・。

サービスプラットフォームチーム

普通のカンバンです。
f:id:gaiax-tech:20160809142110j:plain

しかし、左手前に見えるポストイットの上にある黒い何かに注目すると、カメラなんです。
f:id:gaiax-tech:20160805182416j:plain
このカンバン、設置場所の関係上、確認する際には席を立ち、カンバンが見える場所まで移動する必要があるのですが、その都度、席を立つのは手間だということで社員の方が自作したそうです。
5分間隔でカンバンを撮影し、専用に準備したウェブページにアップロードされるそうです。
リモートワーク、テレワークにも最適ですよね、これ。

サービスを見守る「開運べいだー神社」

f:id:gaiax-tech:20160805183306j:plain
障害監視のためRaspberry Piを利用してXFD(eXtreme Feedback Device)を作成し、トラブルが発生するとべいだーさまが荒ぶります。
そのため、たくさんのお供えがしてあります。
荒ぶっているべいだー様をちょっと見てみたい気持ちになったことは心にしまっておきます。

サービスプラットフォームチーム

バイナリデータリリースされるまでの流れです。最後はパッケージングされプレゼントになっているところが素敵です。
f:id:gaiax-tech:20160805183840j:plain

営業でも利用されておりましたが、こちら写真が取れないため、割愛させていただきます。

次はSalesPromotion・広報チーム

可愛いお姉さんに説明していただきました。
手前のホワイトボードはニコニコカレンダーで、当日の体調が10までの数字で表されているのですが、ホワイトボードにもポストイットにも絵が描かれており、今まで見てきた開発部門とは一線を画していました。
しかも、4枚の数字が重なると、どこかにみんなで食べに行くというおまけつき!
みんなで美味しいものを食べに行くってモチベーションも上がるし、やっぱり、美味しいものは正義ですね(可愛いお姉さん談)。
f:id:gaiax-tech:20160805183910j:plain

上の写真の奥に見えるホワイトボードのカレンダーに貼ってある付箋紙のタスクやリリースが終わると鶴に生まれ変わるそうです。
f:id:gaiax-tech:20160805184924j:plain

最後は総務部

こちら総務部では、KPTもカンバンもどちらも利用されていました。
KPT
f:id:gaiax-tech:20160805194325j:plain
カンバン
f:id:gaiax-tech:20160809153249j:plain
終了したタスク
f:id:gaiax-tech:20160805194336j:plain

一番驚かされたのが、運用方法です。
KPTでは、作業の難易度を付箋の色で表し、期の終わりに難易度ごとに集計して振り返りをする。
カンバンでは、作業工数をフィボナッチ数列で表し、誰の作業が大変か見える化する。
フィボナッチ数列の適用内容:1(5min), 2(10min), 3(30min), 5(1h), 8(2h), 13(4h), 21(8h)となっており、想定時間がわかりやすくなっています。
付箋の色で難易度を示したり、フィボナッチ数列で作業工数を表すなど、総務部の方たちが自分たちで考えて運用しているとのことです。
技術系の部署では、外部の運用ルールを取り入れるのはよくありますが、定着せずうまくいかないこともままあります。
しかし、ここの総務さんたちは、運用ルールを取り入れ、さらに改善していく姿勢には驚かされることばかりです。
素晴らしいですね。

最後に、総務さんはイベントカレンダーのようなものを作ってらっしゃり、人と人のつながりを大切にされてることを感じながら社内見学が終わりました。
f:id:gaiax-tech:20160805185255j:plain


見学の時間に1時間ちょっとを想定していましたが、説明を受けてるうちについつい熱くなってしまい質問がどんどん増え、気づけば2時間30分近くも説明いただきました。
新井さん、ありがとうございます!

その後は、喉を潤しに近くのお店へ、新井さんを含め、参加したメンバーととも消えていきました。
高円寺といえば抱瓶というくらい有名な沖縄料理屋さんへ。らふてー美味しかったです。
f:id:gaiax-tech:20160805191834j:plain

結局23時まで飲んで、明らかに飲んでた時間の方が長かったです。

新井さん、ヴァル研究所の皆さん、お仕事中お邪魔したにもかかわらず、快くご対応いただき丁寧な説明、ありがとうございました。

株式会社ヴァル研究所

www.val.co.jp