投稿者「yokoi」のアーカイブ

TestCafeでのE2EテストをBrowserStackでやろう

yokoi|2017年07月26日
JavaScript

ランサーズCTOの横井です。

最近、個人でE2Eの画面テストを書く際にSeleniumからTestCafeに乗り換えつつあります。導入が(個人的には)Seleniumより楽っていうのと、要素の出現とかをよしなに待ってくれるので、テスト書くときにあんまりその辺を意識しないで書けるっていうのが良い感じです(まだでかいプロジェクトでがっつり使い込んでいないので、落とし穴にはまっていないだけかもしれません)。

とりあえず

$ npm install -g testcafe

やるだけでサクッと始められますが、今回はより色々な環境でのテストを行いたいので、BrowserStackと連携させてみます。

準備

まずは今回のテスト用の画面を作ってしまいます。

<!DOCTYPE html>
<html>
<head>
    <meta charset="utf-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <title>samplepage</title>
    <link rel="stylesheet" href="">
</head>
<body>
    <h1>hello world</h1>
    <script>
    !function() {
        if ( typeof history.pushState !== "function" ) {
            throw Error("under IE9!!");
        }
    }();
    </script>
    
</body>
</html>

だけのシンプルなindex.htmlを作ります。普通のプロジェクトであればローカルにサーバがいたりするかと思いますが、今回はサンプルなので、適当にテストコードの最初らへんで立てちゃいます。その上でテストを書いたのがこちら。

const nodeStatic = require('node-static');
const fileServer = new nodeStatic.Server('./public');

// サンプル用にサーバを立てる
const __server = require('http').createServer( (req,res)=>{
    req.addListener('end', ()=>{ fileServer.serve(req, res); }).resume();
} ).listen(3000);

fixture('Sample Test')
    .page('http://localhost:3000/')
    .after( async (ctx) => {
        __server.close();
    });

test('Assert page title', async (t) => {
    const title = await t.eval( () => window.document.querySelector('title').text );
    await t.expect( 'samplepage' ).eql( title );
});

この時点でもコマンドラインから

$ testcafe chrome tests/sample.test.js

で、Chrome上でのテストが動かせます。

BrowserStackを使用する

まずは、BrowserStackに登録したのち、ログイン後画面から「Account->Settings->Automate」のところにUsernameとAccessKeyが書いてあるのでコピっておきましょう。

次に、TestCafeから使えるようにtestcafe-browser-provider-browserstackを入れておきます。あとは環境変数に「BROWSERSTACK_USERNAME」と「BROWSERSTACK_ACCESS_KEY」をセットして

$ testcafe "browserstack:Chrome@53.0:Windows 10" tests/sample.test.js

上記を動かすと、BrowserStack上で指定したテストが動き、結果をコマンドライン上で確認できます。あとは、BrowserStackで指定できる組み合わせで色々指定すればOKというわけです。

もうちょいプロジェクトっぽくする

このままだと、環境変数毎回設定したり、どのブラウザでテストしているかの見通しが悪いのでプロジェクト化します。
まずはpackage.json

{
  "name": "sample_test",
  "description": "E2E test using testcafe",
  "scripts": {
    "test": "node runner.js"
  },
  "dependencies": {
    "dotenv": "^4.0.0",
    "node-static": "^0.7.9",
    "testcafe": "^0.15.0",
    "testcafe-browser-provider-browserstack": "^1.1.1"
  }
}

環境変数は.envファイルに逃がします。あとはブラウザの指定をコードで管理したいのでTestRunnerのキックをコードで行います。

require('dotenv').config();
const createTestCafe = require('testcafe');
let testcafe         = null;

createTestCafe('localhost', 1337, 1338)
    .then(tc => {
        testcafe     = tc;
        const runner = testcafe.createRunner();

        return runner
            .src('tests/sample.test.js')
            .browsers([ 'browserstack:Edge@15.0:Windows 10', 'browserstack:IE@10:Windows 8' ])
            .run();
    })
    .then(failedCount => {
        console.log('Tests failed: ' + failedCount);
        testcafe.close();
    })
    .catch(err => {
        console.log("err", err);
        testcafe.close();
    });

これをrunner.jsとして、npm test時にキックするようにすればOKです。あとは、browsersの引数の配列を増やしていくだけで、一個のテストを一気に色々な環境で動かすことができます。

実際に意味のありそうなことをやってみよう

冒頭のindex.htmlのscriptタグの中のコードはIE9以下であればErrorとなるはずです。なので、ブラウザーの指定で

.browsers([ 'browserstack:Edge@15.0:Windows 10', 'browserstack:IE@9:Windows 7' ])

IE9を指定してテストを実行してみます。

すると

Running tests in:
 - Edge 15.15063.0 / Windows 10 0.0.0
 - IE 9.0.0 / Windows 7 0.0.0

 Sample Test
 ✖ Assert page title

   1) Error on page "http://localhost:3000/":

      under IE9!!

      Browser: IE 9.0.0 / Windows 7 0.0.0



 1/1 failed (2s)

しっかり検知できました! IE9を外してあげるとテストはパスします。

まとめ

いい感じですね。

CTOのGitHubコミット履歴で振り返る2016年

yokoi|2016年12月25日
開発よもやま

スクリーンショット 2016-12-25 11.34.34

ランサーズCTOの横井です。
クリスマスというよりは、どちらかというと年末感のほうが強いので、GitHubのcontributionsの履歴でも見ながら今年を振り返ってみたいと思います。

ちなみに自分の立ち位置ですが、普段はプロダクト全体を見ている感じで、どこか特定のチーム/プロジェクトに所属ということはなく、コード書く局面は大体下記の状況だったりします。

  • (1) どこかのチームのヘルプ
  • (2) 急ぎのバグ改修
  • (3) 他事業部とかのツールづくり
  • (4) 新規事業/アイディアなどのプロトタイプづくり

言語的には下記みたいな順番くらいで使っていたような気がします。

  • JavaScript / Node.js (プロト作るときにいつもNode.jsで作ってしまう傾向がある)
  • PHP (ランサーズのメイン部分なのでやっぱり多い / WordPressのプラグインとか作ってた時期に増大)
  • Ruby (ランサーズの本体以外は大体Rubyなので)
  • Python (機械学習やってるところで一回だけコミットしたような……)
  • AWK (ログは今年もいっぱいパースした)

古くを遡ればJavaエンジニアだったはずなのですが、一年間でただの一回もJavaを書かなかった、というのは今年が初めてかもしれません。
ついでにいえばFlasherでもあったはずなのですが、ActionScriptをただの一回も書かなかったのも今年が初めてかもしれません。
(去年は奇跡的に、弊社に唯一残るAdobe AIRアプリの改修でActionScriptと、中でNative Extensionsで使ってた箇所のJavaを一回だけ直した)

という個人的にはエポックメイキング的な一年でしたが(別に感慨はないです)、ひと月ずつ気になるところを振り返ってみたいと思います。
(1)~(4)の関係上、非常に個人的かつ断片的なまとめになりますが、まあそれもいいかな、と。

January 3, 2016

スクリーンショット 2016-12-25 14.57.27

社内ツールであるHTMLツクールのコミットから一年が始まっています。このツールは何かっていうと、地獄の作業であるところのHTMLメール作成(CSSをインラインで書く必要があるとかtableレイアウトであるとか各種メーラー対応とか……)でデザインチームが疲弊していたので、jadeでテンプレート化して、inlinerjuiceでビルドする感じにすることで、(多少なりとも)HTMLメール作成の手間を減らそうとしたものになります。テンプレが固まってから以降はキャプチャのように簡易的なCMSにしてしまって、基本デザイナー/エンジニアが関わらなくてもメルマガ担当者が自分でHTMLメルマガを作れるようにしました。この日のコミットはそのCMS部分のredo/undo機能の実装。意義はわかるが、1月3日に何故やっていたのかはもはや不明です。このツールのコマンドライン版で`html2cool -S xxxx`とか作ってたのですが、これは今でもお気に入り。

February 17, 2016

gasshuku

横須賀で開発合宿でした。ちょうど稟議が手間感が高まっていたので、ChatOpsならぬメールOpsというコンセプトで、IMAPを監視して、メール受信のトリガで動いて、件名/Fromメールアドレスでルーティングするようなフレームワークっぽいのを作りました。稟議を特定のメアドにメールで送ると、このサービスがよしなに承認ボタンつきのHTMLメールを自動生成して決裁者(というか僕)に送って、そのHTMLメール中の承認ボタンを押すと、決裁されるというイメージ。結局これは稟議フローの改善には導入しませんでしたが、今でもリポジトリ名であるringi-desu(稟議です / 稟議Death)のセンスには脱帽です。

March 19, 2016

スクリーンショット 2016-12-25 14.09.15

この月は非常にバタバタしていて、ランサーズストアQuantPropagといった新サービスたちの追い込み等もありてんてこ舞いな月でした。
 
そんな中で選んだコミットは、3月23日に行った「Lancer Of The Year」という、ランサーズで活躍してくださったランサーさんを表彰させていただくイベントにまつわるものです。イベント自体はヒカリエホールで行って、そのイベント中にリアルタイムで投票を行う、というものだったのですが、投票時間5分間限定のものだったこともあり、重複投稿自体はフロントでLocalStorageで管理し、ページはS3でWebサイトホスティング、投票APIの向き先はただのApacheが置いてあるだけでアクセスログをパースして集計、というのを直前に組んでいました(他にも小細工はしていますが)。実際の投票の瞬間には楽屋裏でリアルタイムで僕がAWKで集計していたわけですが、自分が作ったものを大勢の人が目の前で使ってくれる瞬間を見れる機会はそうそうあるもんじゃなく、非常に感慨深かったです。来年は弊社期待のエース@takepoあたりに味わってもらいたいものです。

Apr 19, 2016

名称未設定

4月はランサーズストアPropagが世にリリースされ、その追加開発などでちょこちょこ入っていました。どちらかというと年度が変わったタイミングで、評価面談や組織づくりのほうに力を入れていたこともあり、そんなにコードを書いていた記憶も無いですが、コミットを見るとランサーズストアのz-indexの修正とかを行っていたようです。可愛いですね。

May 24, 2016

スクリーンショット 2016-12-25 15.05.53

地方創生事例を紹介する「ランサーズ エリアパートナープログラム」と、さすらいワークを提唱する「LOHAI」 の2つのGitHubリポジトリを作成していました。リポジトリの作成のみで中身の開発は僕はしていないです。これらのサイトは8月くらいにローンチすることになります。

June 16, 2016

名称未設定

Quantの正式ローンチの月。追い込みはQuantチームに任せ、ランサーズのほうに導線貼ったり、LP用意したりといったCTO的庶務をコミットしていたようです。まあ、つまり、誰かがやるんです、こういうことは。

July 29, 2016

7月の大半は、8月のリリースラッシュに先駆け、プロジェクトマネジメントだったり各種調整だったりといった方向に時間を使っていたのですが、最後のほうで(運命の流れで)Wordpressプラグインを作る流れになり、最終週あたりはWordpressプラグインを作っていました。Wordpressと生まれて初めて真剣に向き合い、とまどい、時には傷つきながらも前に進めた気がする7月でした。

August 23, 2016

8月は色々ありました。前述のランサーズエリアパートナー、LOHAIのリリース。ランサーズのAppサーバのコード化(最後にここだけ残っていた)etc,etc…。そんな中でも思い出深いのがKPIモニタリング基盤の一新で、当初担当エンジニアと「サーバレスだぜ!」とかテンション上がってS3 + Lambdaで行こうぜ!とかキャッキャ話していたのですが、いざやってみると弊社の目的にはあまり向いていなく(ポイントで立ち上げるというよりは、常駐的にずっと動かすほうがよろしかった)、やっぱやめてEC2で常駐させて動かそうとなって、Lambdaに載せてたNode.jsを諸々書き直してたりしました。多分この1年で一番量書いた。あと、この月に子供が生まれて父親になりました。

September 20, 2016

事業オーダーでのプロトタイプとかを作ってました。テクニカル的にはちょっと面白い(トリッキーな)ことをやっていたりしますが、それはさておき、プロトタイプとはいえ2016年になってUnderscore.jsのtemplateを使ったところが感慨深かかったです。確かHTML一枚で作ろうとして(webpackとか使わずに)、そうするとライブラリはcdnjsとかから持ってくることになり、その中でテンプレートエンジン的なもの、という感じで思いついたので入れたという感じ。HTML一枚で作ることのメリットとしてはサーバ等も用意せず、そのままエンジニア以外に渡して「ファイルをダブルクリックして」と言うだけ、というお手軽さがあります。

October 19, 2016

企画部の部長も兼任することとなり、改めて組織づくりに時間を使っていた月でした。どういう組織をつくるか、という点ではクレド的なものを作成しはじめたり、どう作るかという点で「プロジェクトにおける7つの問い」をコミットしていたりしました。

November 8, 2016

10月に引き続き。細かいところを直したりのリリースはしていましたが、「何を」「どう」作るのかに時間を当てていました。UI/UXのイベント等にも登壇したりしていました。

December 21, 2016

といった感じで、プロダクト全体を見ていくことになり、コードからは一旦離れてたかに見えましたが、ここにきて12月はログまわりを設計し直していたりしました。一年の最後の最後にきてログです。裏側です。お前冒頭の(1)~(4)のどこでもねえじゃねえか、って感じですがログです。ログはすごい大事なのです。この辺も色々まとまったら改めてブログに書ければと思います。

まとめ

いかがでしたでしょうか。自分のコミットログを遡ればある程度この1年でランサーズでつくってきた色々が出るかと思いましたが、なにぶん個人のコミットログに依存することが大きく、かつピックアップしているところも思い出補正も大きく、偏りは多分にありますが、まあまとめると色々あったなあ、と。CTOという役職として「どこで「どう」コードを書くかっていうのは色々書きたいこともあるのでいずれ。

プロトタイプアンチパターン「愛ゆえに」

yokoi|2016年12月01日
開発よもやま

ランサーズ Advent Calendar 2016 1日目の記事です。

CTOの横井です。僕は単騎で新企画とかやるときは、とりあえずプロトタイプベースで進めていくことが多いです。

その甲斐あってなのか、プロトタイプで終わったもの、社内ツールとして使われたもの、プロダクトとしてリリースしたもの等等含めて、ランサーズ来てからの1年半で、0からつくったものが大小合わせて30本くらい自分のプロジェクトディレクトリにありました(ちょっとしたコマンドとかライブラリチックなのは除いて、画面があるもの限定です)。

前職の受託開発時代とかもプロトタイプベースでお客さんに提案していたり(週1で客先でプロトタイプノックをすることもありました)したので、そう考えるとトータルでは結構つくってきた気もします。

今回は、そんな自分がプロトタイプづくりを経て感じたアンチパターンを紹介したいと思います。
 

プロトタイプアンチパターン 愛ゆえにパターン

最大の敵はプロトタイプに愛を抱いてしまうことだと思います。実現したいこと、届けたい価値に愛を持つのは大事です。大事ですがプロトタイプそのものに愛を抱くと大抵不幸な結末を迎えることになります。まさにサウザー様が言っていたとおりです。愛ゆえに人は苦しまなければならぬのです。

以下にプロトタイプに愛を持ってしまうとどうなるかの例を書きます。

折角つくったのにみんなが見てくれない! 試してくれない! と鬱々とした気持ちを抱えながら日々を過ごすことになる

結果1年後くらいに「あのときのプロトを続けていれば……」みたいな怨霊と化す

プロトタイプを見せるプレゼンの場で、上手く動かない! となったときにみんなに見せたい気持ちから、突然その場でバグ探しとか、見せよう見せようとして結果全員に物悲しい時間が訪れることになる

仮説が成立していないことがわかっても、プロトタイプを捨てたくなくなり、ついついそれを守るための理屈を考えてしまう

「じゃあ仮説の方向性を変えて……」のときにもなんとか今のプロトタイプを変更することでどうにかならないか考えてしまう

 
……耳が痛い!

つまるところ、これって手段が目的化しちゃったって話なんですが、じゃあどうするかっていうと単純で、プロトタイプそのものには愛を持たないようにすることがコツかなと思います。
そもそも、本来的に仮説を検証するための手段としてのプロトタイプになんで執着しちゃうのかって話なんですが、これはもう手間をかけちゃったからだと思うんですね。自分のコストを投下すればするほどもったいなくなってくる。なので、愛を持たないようにするための手段としては「時間をかけない」「(作り方そのものについては)悩まない」というところかなと。

時間をかけない、って意味だと、例えばプロトタイプ開発用に必要なものが揃ったスケルトンプロジェクトみたいなのをあらかじめつくっておくとか、それに適した技術選択にしておくとかがあります(自分の場合だとフロントとサーバーサイド両方での思考のスイッチングコストを減らしたいのでサーバサイドはNode.jsでやっちゃうことが多いです)。

悩まないという点では、もうとにかく色々なパターンを知っているか、過去につくったことがあるか、がものをいうかと思います。まあ、そういう意味では一つのプロトタイプづくりは、次のプロトタイプづくりを更に早めるための経験値稼ぎでもあります。それの極北は、めんどくさいところを勘で察して、程々にごまかすなんちゃって実装の知見だったりします(これは完全にプロトタイプづくりのみのためのスキルですが)。

個人的な指針としては、午前中で一段落つくかどうか、みたいなものを置いていたりします。

丸一日かけちゃうと、それを捨てざるをえないときに「無駄な一日だった……」と悲しくなっちゃいますが、午前中だけだと仮にまるっと捨てても「午前中調子出なかったなー」くらいの軽い気持ちでいられるのです。

勿論これは僕個人の感情にのみ由来する話で、本来的にはプロトタイプを捨てるとはいっても、無駄になるわけではなく、必ず得られるものがあると思っています。ただ、それと、自分が無意識的にでも抱いてしまう感情の折り合いはどうにかつけていくしかないかなーと。

といいつつも、またうっかりプロトタイプそのものに愛を抱いてしまって、執着して、を繰り返しているので、人生は修行だなーと思います。

CTOが語るUIUXというテーマでお話してきました

yokoi|2016年11月28日
DevOps

CTOの横井です

先日(11/26)、dots.さんところで「dots.CareerMeetUp – UIUXの巻」に登壇して、UI/UXについて話してきましたー。

 

UI/UXというタイトルではあるんですが、UXとかについて集中して考える環境をつくるには、みたいな内容です。

プロダクトをつくるにあたって、すっごいざっくりいっちゃうと、「どういうリソース(予算、人、技術、等等)で」「何をつくるか」につきるかと思います。

で、ここでいう「何をつくるか」っていうのは「機能/サービス」とかではなくて、「どういう体験/価値」を届けられるか、それがUXかなと個人的には思っています。という話はさておき、「どういうリソースで」と「何をつくるか」の間の話として「どうつくるか」みたいなプロセスの話があります。

前回書いたブログの内容は、まさにその辺の話だったりするので、まんまその辺の話をしてきました。UXの話っていうと、結構アウトプットしたもの以降の話が多い印象もあったので、たまにはこういうのもいいかなと。

———-

そういえば、イベントのパネルディスカッション時に「UIUX担当者が今後つけるべきスキルとは」みたいな話があって、まあ、UIUX担当者っていうと色々なパターンがありすぎて難しいところもあるんですが、その時答えたのは、以下の3つでした。
 
・専門の深さ
・視野の広さ
・視座の高さ
 

デザイナーの方が多そうだったので、例として出したのは

・専門の深さ
色彩理論に詳しいとか、海外のデザイン流行に詳しいとか、そもそもみんなうならせるグラフィック力とか

・視野の広さ
企画とかエンジニアリングのことも把握しているとか、色々なターゲットを想定できるとか

・視座の高さ
事業観点/経営観点、市場とか経済がどうなっているか、など

 
で、まあこんなのUIUX担当者に限らず全部そうですよね、って話なんですが、一個そのときの補足をしておくと、必ずしも誰もが上記3つを全て出来るようになれということではなく(出来るにこしたことはないし、出来ることを求められるロールもあるかと思いますが)、自分のバリューをどこにつくっていくか、というときの方向性かなーと思っています。

特にUIUX担当、みたいなワードの場合、どうしてもふわっとしてしまうことがあるので、「実質それってデザイナーですよね」とか「実質それって企画ですよね」みたいな話になりがちで、かつ評価基準も難しい(その成果が出るのに時間がかかることも多く、また成果自体も複合的な要因になりやすい)。そのときに気になるのはやっぱり、この人はどういうことができるのか、どういうバリューがあるのか、だったりします。この辺の強みが明確で、かつそれを伝えられる人は魅力的だなーと思います。という話でした。

企画/開発の境目を取り除こうとしていたら プロジェクトにおける6つの問い をつくっていた話

yokoi|2016年11月04日
DevOps

ランサーズCTOの横井です。

元々ランサーズではプロダクト開発部というところの部長もやっていたのですが、10月の組織変更で改めてプロダクト企画部長も兼任となりました。これまで以上に統合的にプロダクトづくりに取り組んでいけるんじゃないかなーと思っております。

……というものの光陰矢のごとしでして、あっという間に1ヶ月が過ぎました。

最初は、企画と開発を両方同じ人間が見るんだから、統合的な何かを生み出さないとあれですよねー、打ち首獄門ですよねー、とか思っていて、思っていてというかこの記事の冒頭でも書いてるんですが、まあとにかくそういう何かを考えようと。

ランサーズの(少なくともこの1年の)企画は、開発と組織が分かれていたこともあり、ものづくりにおける理念みたいなところとかプロセスとかを企画/開発でちゃんと共有できていたわけではありませんでした。勿論中には各施策レベルでそれらが上手く回るチームはありましたが、残念ながら全体としてはうーん……という。

実際にあったかどうかは別として下みたいな感じでそれは噴出していたりしてですね

  

企画:見積りが毎回ずれるんだけどどうなってるの!

開発:企画の意図がそもそもわからん! というか要件が詰まってないんだからそりゃずれるよ!

  

みたいな。まあ、あるあるといえばあるあるですね。このままでは戦争はこの世界から消えません。

  

そこでとりあえずプロセスを一本化しようと思い立ったわけです。

それにあたって当初はかなりガチガチに考えていて、企画/開発の機能/職掌分解からはじまって、ワークフロー描いて、じゃあここは何のツール使おう、○○とxxが選択肢だよなー、じゃあそれのプロコン出してどれにするか決めて、次はそれが上手く回るような運用フロー考えて、でもやっぱり最後はみんなのモチベーションだから、みんながそのプロセスに乗りたくなるような仕組みを考えて、あー、複雑になりすぎたからちゃんとドキュメント書いて、新しい人とかのことも考えて入社フローにも組み込んで……

    

あああああああああ!!!!

    

……となってしまったので、改めて考え直そうと。改めて考えると、自分がやりたかったことって○○ってツールを使うこと、とか、xxっていうやり方を試してみること、じゃなかったんですね。じゃあなんなのかってことを考えるにあたって、みんなへの手紙のつもりでまとめてみようと、そういうつもりで書き始めたのがタイトルにある「プロジェクトにおける6つの問い」です。お前、みんなへの手紙の件名に「問い」とか書くのかよ、って感じですが、タイトルは後付けです。
  

プロジェクトにおける6つの問い

ステークホルダーと合意したものがまとめられているか?

  • プロジェクトの目的 / 背景 / KPI / 撤退基準などを全員と合意しておきましょう
  • 途中で道に迷わないようにするため、後から振り返られるようにするためです

受け入れテストは作成されているか?

  • 仕様書は必ずしも必要ではありませんが、達成すべきことは「実装前に」明確にしましょう
  • 達成すべきことが明確でなければそれは実装する段階ではありません(勿論決まっていないことを後回しにするのはありです)

進捗が感覚ではなく、ストーリポイント+ベロシティ+バーンダウンチャートによって語られているか?

  • 過去のみなさんの実績が一番の信頼できる指標です
  • 進捗を求められてから進捗を考えるのではなく、実際の進行と進捗確認が一体となるようにしましょう
  • 日々可視化することで、自分たちの速度を客観視しましょう

難しいところを後回しにしていないか?

  • 難しい箇所等の不確定要素は「必ず」最初のほうに潰してください
  • プロジェクトの最後には「後は手を動かすだけ」のタスクが残るのが美しいです
  • 終わりになれば終わりになるほど、見積もり精度、確実性は増していきます
  • その余裕が+αのユーザへの価値をつくる時間に当てられます

いつでも人に見せられますか?

  • いつでもチームメンバー以外に見てもらえる環境をつくりましょう
  • チームメンバー以外からのレビューは、一番近いエンドユーザからの声です。欲しがりましょう
  • 「バグがあって見せられない……」「まだまともに動かないから……」作業の粒度が間違っているか、受け入れテストを見ていないサインです。それが続くプロジェクトは、リリースまで周りに見てもらうチャンスを失い続けます。

細部のUI/インタラクションについて考慮する時間を取れているか?

  • 神は細部に宿るし、考慮していない習慣が生まれるとそれが突如蘇ることはありません
  • +αの価値を考えられるということは、みなさんのプロジェクト運用が上手くいった証拠です。おめでとうございます!

==============================
  
ある日の出社前の15分くらいで勢いでぱーっと書いたのですが、いざ書いてみると自分の中では非常にしっくり来て、そのまま会社行って開発/企画陣に上の文章を見せて「自分はこれを問い続けるから、それに答えられるようなやり方/進め方はみなさんで考えてください。方法は任せます」と話しました。なんかちょっと開発寄りみたいな文章ですが、企画陣についても一緒です。
    
その後何があったか。

まだ上記の話をして2週間くらいですが、例えば、企画もGitHubを見て、Waffle.ioでIssueを管理していこう、となってWaffle.ioを導入していったり、企画メンバーと一緒になって色々試していっているような気がします。少なくとも自分があれこれ考えて「これだ!」とか押し付けていた未来よりは、間違いなく良いものになっている実感があります。

まだまだ正解は無いですが、自分の役目としては、上記をひたすら問い続けようかな、と。
    
おまけ

勿論15分かそこらで一人で考えたものが正解であるわけもなく、上記文章はGitHub上の弊社welcomeリポジトリ(最初に入った人が見るところ)に置いてあって、今後はプルリクベースでブラッシュアップしていきます。

というか3日くらいで早速一つ増やそうとしました。

スクリーンショット 2016-11-03 22.16.31

この辺の追加に関しても、企画/開発みんなで議論し合ったりしながら進んでいきたいと思っています。(ちなみに上記は早速企画/開発からツッコミが入りました)

ランサーズでは、思いを共にしながら自分たちで仕組みをつくっていける人を募集しています!

dotsで登壇してきました

yokoi|2016年08月02日
DevOps

CTOの横井です。

こないだの7/31にdotsさんで、下記のイベントに登壇してきました。

http://eventdots.jp/event/593939

当日は、アクトキャットさん、BECさん、サイバーエージェントさんと、ランサーズの4社で普段のプロジェクトの体制や進め方など、幅広くお話をさせていただきました。各社それぞれ規模感等の違いもあったり、一方で共通しているところもあったりで、非常に面白かったです。

自分は上の資料みたいな感じで、ランサーズストアとPropagというここ最近の新しいプロジェクトの2本についてそれぞれお話させていただきました。組織とか事業が拡大する中で、プロジェクトの進め方もまだまだ試行錯誤中ですが、改善改善ということで次回同じような資料つくるときは更なるブラッシュアップをしていかなければと心が引き締まる思いです。最近身が引き締まっていない(太った)ので、せめて心は引き締めていきたいと思います。