Webエンジニア・デザイナーのためのパーソナルコーチ
緊急度は低いけど重要度が高いっていうことが、Webエンジニア・デザイナーな人には結構あるんじゃないかということを先日、30歳からのスタートアップの橋田さんとしゃべってました。
具体的な例
- RailsとかCakePHPで開発をしてて、フロント側の開発もやらないといけなくなったけどJavaScriptは正直そこまで得意ではないと感じてる
- 目先の仕事では凄く困ってないけど、今後のことを考えてこのままの手法で開発進めると、フロント側のコードは大変なことになりそうだから、JavaScriptについて理解を深めておきたい
- JavaScript界隈の技術動向が早く、フレームワーク１つとっても、Backbone.jsとか、Knockout.jsとか最近だとAngularJSとかReact.js色々ありそうだし、altJSとかもあったり、サーバーサイドのNode.js・・・という感じでどこから手を付けていいのか悩む
というようなケース
こういう状況の人のためのヒントとして
- 現時点のJavaScriptについての理解の棚卸しのために概要を説明するプレゼンテーションならびにハンズオントレーニング
- その人の興味・関心や、エンジニアとしての指向性のヒアリング
を提供することで、大きな絵が描けるようになり、今後どういう風にJavaScriptをマスターしていけばいいのか、道しるべが得られるのかなと思ってます
どういう道しるべがあるのか？
最近は大きく2つにわけて考えたほうが良い気がしてきたのでこのあたりが道しるべになるのかなと。
- Webアプリでフロントエンド側により特化（深化）していくパターン
- より特化（深化）していくパターンだと、最近流行りのJavaScriptフレームワークの比較検討ができるし、それに関連してAltJSでどれがよいとか、テストフレームワークとして何がよいとか、Grunt/Gulp.jsみたいな話・・・という感じでHTML/CSS/JSについて2つも3つも深い所の話が出てきそう。
- JavaScriptという言語を軸にフロント・バックエンド・スマフォアプリの開発可能性を探るパターン
- （フロントエンド側により特化していく人に比較して）最新のJavaScriptフレームワークについて凄く知ってるわけではないけど、例えばLAMPスタックと違う方向でMEAN(MongoDB, Express, AngularJS, Node.js)というアプローチがあるので、そういうアプローチがどういう所で有効なのかとか、もうちょっと広く捉えていく傾向にあるのかなと。
最初からどっちに進むのか決めなくても良い
目指す先として上記の2つがあるかなと思っているのですが、最初にどっちに進むのかを明確に決めなくてもいいかなと思ってます。
汚い絵ですみませんが、こんな感じでスタートしてから矢印が一直線になるかもしれないし、途中で全然関係ない方向に進むのもアリかと思ってます
LEAN IN(リーン・イン) 女性、仕事、リーダーへの意欲を最近読んでるのですが、
一つの企業なり組織なりに就職し、そこで一本の梯子を上っていく時代はとうの昔に過ぎ去ったのである。ローリーは、もっとよい喩えとしてパティ・セラーズの言葉をよく引く。それによれば、キャリアは梯子ではなくジャングルジムだ。ローリーが言うとおり、梯子には広がりがない。上るか下りるか、とどまるか出ていくか、どちらかしかない。ジャングルジムにはもっと自由な回り道の余地がある。
という事が書かれていましたがこのジャングルジムというイメージが割りと自分としてはしっくり来る感じで
「あー、この人がイメージしてる世界観は、きっとフロント側をより深く追求したい人なのかな」
とか
「LAMPスタックにかぎらず、JavaScriptな技術を中心にすることでこういう（＝MEAN）アプローチもあるっていう道しるべを提供してあげるとスキルの幅が広がるのかな」
とか
「一番最初の話の中のxxxという所がまだちょっと理解が浅そうだから、追加情報を提供したほうがいいのかな」
という感じでその人が目指す道しるべを、対話を通じて大枠を示してあげたほうが実は良いんじゃないかと思ってます。
本題のWebエンジニア・デザイナーのためのパーソナルコーチ
Webエンジニア・デザイナーの人がある程度自己学習で進めるところもあるのですが、大局観を養うという部分では個人でどうにかするのはちょっと厳しいのかなと思ってます。※ここ書いててちょっと自分が意図してる言葉になってない気もするので後で書き直すかも(^_^;)
自分の考えを出して、それに対するフィードバックを得て、そこの気づきを踏まえて次に進み、さらに自分の考えを出して・・・という感じのプロセスを定期的に積むことで
パーソナルコーチのような立場で、相手の力量とか指向性とか考えて、相手に寄り添いながら教えるようなプログラミング講座ってたぶん無い気がしてるし、パーソナルコーチに近い素養っていうのは、7年位自分がやってきたキャリアカウンセリングの手法が活用できると思ってます。
- 最初のガイダンスで基本を教える
- 対話をしながら次に進む進路をちょっとづつ決める＆その方向に進むための講座を別途行う
- 方向性が固まって、仮にそっちで仕事をしたくなったら、可能性のありそうな知り合いを紹介はする
- 転職支援みたいなことはやらない。
という感じで過去自分が仕事でやってきた部分を色々組み合わせることで、ビジネスとしてもしっかり成り立ちな気がしてきました。
集客の部分が課題になるので、まずはストリートアカデミーだったり、他の所でイベント行うなどして、
- 1回1時間で6000円（2000円ｘ3名。講座自体は1時間）
- 月8回開催（週2回開催として）
- パーソナルコーチ的な発想なので、1人の人に対して一定期間関わる感じだろうけどその辺りの細かい所はまだ考えてない
という感じで月5万円の売上を安定して稼げる仕組みを作ろうと思ってます。
Titanium + Alloy + napp.alloy.adapter.restapiで作る簡単Qiitaビューワーアプリ
最近、技術系のネタをQiitaに集中していたのですが、ブログのアクセス解析の状況見てたらTitanium Mobile alloy」「ACSとは」 という意図したもので流入しはじめてきたので、Alloyネタをこっちにも書いておきます。
こんな感じの簡単Qiitaビューワーアプリを Alloy + napp.alloy.adapter.restapiで作る方法について簡単に解説します
自分の環境
- OS X
- 10.9.5
- Titanium SDK
- 3.4.0.GA
- XCode
- 6.0.1
- Node.js
- v0.10.13
- alloy
- 1.4.1
- CoffeeScript
- 1.7.1
開発前の事前準備
Alloy用の RestAPI Sync Adapter の配置
- PROJECT_FOLDER/app/assets配下に、alloyフォルダを作成して、その中にsyncフォルダを作成します
- Alloy用の RestAPI Sync AdapterというのがGitHubにあるのでダウンロードして、上記作成したsyncフォルダに配置します。最終的には、PROJECT_FOLDER/app/assets/alloy/sync/restapi.js
alloy.jmkの準備（任意）
自分はCoffeeScriptで書くことが多いので、PROJECT_FOLDER/app/alloy.jmkを作成して、以下のように記述してます。
task("pre:compile", function(event,logger) { logger.info('pre compile start!'); var wrench = require("wrench"), fs = require("fs"), path = require("path"), controller_root = event.dir.controllers, model_root = event.dir.models, coffee = require("coffee-script"); wrench.readdirSyncRecursive(controller_root).forEach(function(controller){ if (controller.match("coffee$")) { fs.writeFileSync( path.join(controller_root,controller.replace("coffee", "js")), coffee.compile( fs.readFileSync(path.join(controller_root, controller)).toString(), { bare: true })); } }); wrench.readdirSyncRecursive(model_root).forEach(function(model){ if (model.match("coffee$")) { fs.writeFileSync( path.join(model_root,model.replace("coffee", "js")), coffee.compile( fs.readFileSync(path.join(model_root, model)).toString(), { bare: true })); } }); }); task("post:compile",function(event,logger){ logger.info('compile finish'); });
PROJECT_FOLDER/appのフォルダ構成で関連しそうなところだけ抜粋すると以下のようになります。
├── alloy.jmk
├── alloy.js
├── assets
│ ├── alloy
│ │ └── sync
│ │ ├── restapi.js
│ ├── android
│ ├── blackberry
│ ├── iphone
│ └── mobileweb
├── config.json
├── controllers
│ ├── index.coffee
│ └── index.js
├── models
│ ├── qiita.coffee
│ └── qiita.js
├── styles
│ └── index.tss
└── views
└── index.xml
実際の開発の流れ
WebAPIと連携するアプリ開発はTitaniumの得意な所かと思うのですが、Alloy用の RestAPI Sync Adapterを使うことで、これまで以上に開発が捗るかと想います。
実際の開発手順を順番に示していきます。
QiitaのWebAPIにアクセスするためのModelの開発
RestAPI Sync Adapterを使うことで、Web APIとの連携処理がだいぶスッキリ書けるようになります。
Alloy用の RestAPI Sync AdapterのHow To Useを見ればおおまかに利用方法がわかるかと思いますがシンプルにアクセスするだけというような状況でしたら
- Web APIのエンドポイントURLを指定
- collection_nameを指定
という所がポイントになります。
今回は、
- Web APIのエンドポイントURL
- collection_name
- qiita
という形にして、app/models/qiita.coffeeを以下のように作成しました。
exports.definition = config: URL: "https://qiita.com/api/v1/items" adapter: type: 'restapi' collection_name: 'qiita' extendModel: (Model) -> _.extend Model.prototype, () -> return Model extendCollection: (Collection) -> _.extend Collection.prototype, () -> return Collection
注）Modelのファイル名とcollection_nameは同じ形にしておかないとエラーになります。
Controllerを作成
Controllerから上記作成したModelを呼び出すには
qiitaItems = Alloy.createCollection 'qiita' qiitaItems.fetch success: () -> # 任意の処理 error: () -> # エラーの時の処理
という形にします。今回は簡易的なビューワーアプリを目指して作ったので、QiitaのWebAPIからパブリックな投稿情報を取得して、TableView使って表示することにしたので以下のようにしました。
$.index.open() $.activityIndicator.show() qiitaItems = Alloy.createCollection 'qiita' qiitaItems.fetch success: () -> $.activityIndicator.hide() _stringify = JSON.stringify(qiitaItems) # 注１ items = JSON.parse(_stringify) return refreshMainMenu items error: () -> $.activityIndicator.hide() Ti.API.info "error" # Qiitaから取得したデータをTableViewにセットする処理 refreshMainMenu = (items) -> rows = [] for item in items Ti.API.info item.title row = $.UI.create "TableViewRow", classes: "itemRow" data: item titleLabel = $.UI.create "Label", text:item.title classes: "titleLabel" bodyLabel = $.UI.create "Label", text:item.raw_body classes: "body" row.add titleLabel row.add bodyLabel rows.push row return $.mainMenu.setData rows
注１
本来はstringify→parseは全く意味がない処理なんですが、restapi Adapter使うと何故かわからないのですが、JSONのパース処理でエラーになります。
何か不要な文字か制御コードが含まれているようなのですがJSON.stringifyで文字列化して、その文字列化したものをJSON.parseすることで回避できます。
Viewの生成
取得した投稿情報を表示するためにXMLとTSSを以下のように準備しました。
index.xml
<Alloy> <TabGroup> <Tab id="tabOne"> <Window id="mainWindow" class="container" title="Qiita"> <ActivityIndicator id="activityIndicator" message="Loading.." /> <TableView id="mainMenu" /> </Window> </Tab> </TabGroup> </Alloy>
index.tss
"#mainWindow":{ statusBarStyle:0, translucent:false, navTintColor:"#0066ff", backgroundColor:"#fcfcfc", tabBarHidden:true } "#mainMenu":{ backgroundColor:"#fcfcfc", separatorColor: '#cccccc', width:Ti.UI.FULL, height:Ti.UI.FULL, left:0, top:0, zIndex:1 } "#activityIndicator":{ top:"50%", left:"20%", textAlign:'center', backgroundColor:"#222", font:{ fontSize:18 }, color:'#fff', zIndex:10 } ".itemRow":{ width:Ti.UI.FULL, height:"15%", hasChild:true, backgroundColor:"#fcfcfc" } ".titleLabel":{ width:"90%", height:"20%", top:"5%", left:"5%", textAlign:'left', color:'#59BB0C', font:{ fontWeight:'bold', fontSize:16 } } ".body":{ width:"90%", height:"70%", top:"25%", left:"5%", textAlign:'left', color:'#222', font:{ fontSize:12 } }
最後に
QiitaのようなWeb APIや、Titaniumの開発元が提供してるACSと連携するようなアプリ開発をする場合のサーバーとの通信部分の処理でAlloy＋napp.alloy.adapter.restapiを使うことですごくスッキリ書けるように思います。
投稿数を絞って取得したい場合にはクエリーパラーメーターを付与する必要があるのですが、その辺りについてはまた別の機会に書きたいと思います。
参考情報
ホテルがペア宿泊券をなぜ無料配布するのか？
タイトルやや釣りっぽくってすみません(^_^;)
朝日新聞の夕刊紙面を見てたら宿泊券招待みたいな記事が出てました。 （紙面だけの情報かと思ったのですがちょっと調べたら、千葉県の「鴨川シーワールドホテル」がペア３組を招待（１泊２食付き、１人１万４０５０円相当）という感じでWeb上でも掲載されてました）
このキャンペーンのからくりってどうなってるんだろうとふと気になったのでそれについてちょっとまとめようかと思います。
本題に入る前になんでこんなことまとめようと思ったか？
最近の自分の仕事ですが
- コードを書く（この画面の左側の作業）
- ビジネスプランについて一緒に考える（右側の作業）
という感じになっててます。
ビジネスプランについてあれこれ考えるのは結構好きだし、そこの仮説が甘いと、後々になって「あれ、これ何で作ってるんだっけ？」という罠に落ちちゃうんじゃないかなとちょっと心配してます。
あとは、ビジネスプランみたいな所から関われない仕事だと単に下請け仕事っぽくなってしまって、そういうポジションが確立されるのは、ちょっと嫌だなぁ・・というのがあったりするんで
キャンペーンにかかる金額をおおまかに考察してみた
汚い字だけどザックリこんな感じで、最近愛用してるダイソーで買った子供用のスケッチブックに書き出しながら考えていきました
考える前に数字をちょっと丸めてます
元の情報を簡単に整理すると
- 宿泊券：1万4050円
- 来年３月１９日（木）まで有効
- 優待券：1万1030円
- 往復はがきで応募した場合、落選時に宿泊券の割引が適用される優待券が返送される
- 往復はがきに郵便番号、住所、氏名、電話番号を記す必要ある
- 応募受付は１週間
となっていました。
金額が若干計算しづらいので以下のように数字を修正してます。
- 宿泊券：1万5000円
- 優待券：1万2000円
- 元の優待券の金額設定がベースの宿泊券の3000円引きという設定みたいだったのでこの金額
優待券の扱いについてちょっと深堀する
１週間という期間限定ですが、朝日新聞の夕刊紙面+αという感じで告知してるのでそれなりの応募はあるのかなと思ったのですが、コスト負担の計算をするという観点にたてば、応募総数は無視してもよくって、落選時に優待券が返送される条件にマッチする往復はがきで応募する数がポイントかと。
そこの数の設定ですが、根拠ないですがまずは500名としました。
最大でどの程度のコスト負担になるのか
優待券は、3000円引きの割引券と考えて、かつ優待券を発送した全員が使うという条件で見積もると
- ペア宿泊券：6万円
- 15000ｘ2名ｘ３組
- 優待券：150万円
- 500ｘ3000円
- キャンペーン受付と優待券発送の事務作業：20万円
- 1週間の受付期間＋その後の商品発送業務だと1名の事務作業員が2週間程度行えば実施可能。外部に委託したとしてアルバイトの人件費＋その作業スペースの場所代＋諸経費含めてこの程度でイケる？ここは深く考えてない）
という感じで総額176万円だけど、計算面倒なのでここも数字まるめて200万円で考えます。
ペア宿泊券を無料配布してるのか自分なりの仮説
すごく乱暴に言うと、1人宿泊する度に4000円づつ赤字が出るこのキャンペーン。
でも、最大で1名あたり4000円で新規顧客開拓出来るなら全然割りに合うという根拠があるんじゃないかと思ってます。
以下根拠
- これから稼働率落ちるので、まずはお客さんに来てもらいたい
- 鴨川がおそらく今の時期ハイシーズンではない。
- 海が近い所なので、夏場とくらべた場合という意味で
- 券の締め切りが来年春までと締め切り作ってる。
- 鴨川がおそらく今の時期ハイシーズンではない。
- 仮に全員が宿泊券、ならびに、優待券を使わなかったとしてもキャンペーン受付と優待券発送の事務作業にかかった作業費の赤字で済む
- （500名という数字の根拠が正しいか一旦脇に置いて）一定数の個人情報が獲得できたのでその情報をベースにして、ハイシーズンに向けて次の販促につなげられる
- 20万円近くで宿泊予備軍の名簿を作ったと考えればむしろ安いと判断
- ハイシーズンに向けてどういう媒体にどの程度予算を使うのか下調べとしても使える
- 今回、夕刊紙面＋Webという感じで情報掲載されていたけど、もしかしたら他の媒体使っても同じ情報掲載してるのかなと推測
- そうなると、どこにどの程度の予算を割くとどの程度の収益がたつのかあらかじめシュミレーション出来る
また、今回宿泊券を使うかもしれないお客さんからするとまぁ得してるのかなと。
- ペア宿泊券あたった人：無料なのでもちろんうれしい
- 往復はがきで応募してハズレた人：ハガキ代金程度で通常料金よりも安いのでうれしい（でも上記ロジックが正しいとすると自分の情報を4000円程度で売ったとも見れるけど・・）
広告売りたい人がこの話を持ちかけたのかな？
上記のコスト負担の所で
キャンペーン受付と優待券発送の事務作業：20万円
という項目あげましたが、これをそのまま広告枠の金額として考えると広告売りたい人がこの話を持ちかけたのかな？
施設に対して
「これからのオフシーズンに備えてこんな広告を20万円でだせますが、やりませんか？」ともちかけて、こういう事務作業は広告代理店さんなら手慣れてるだろうし、こういうお客さんを多数集めれば広告枠もしっかり埋まるし・・と考えると納得いくかなぁと
おまけ
上記のような考えはすぐに浮かんだのですが、それをブログにするのに無駄に時間かかったので、自分の仕事の時間がなくなってるというあまりいただけない状況になった(^_^;)
ただ、こういうことも出来るっていうアピールとかんがえると、投資対効果として悪くないかなあと
色々なサービスを組み合わせる「化学式」の発想
お手伝い所の会社で、新しくやろうとしてることがあって、必要最低限というのがそもそも何なのかという話をしながら、開発を進めています。
議論しながら作ってる過程でふと「化学式」の発想って大事だなぁと自分の中で気づきがあったのでちょっとブログにまとめておこうと思います
クラウドの時代にはクラウド間を結合させる化学式を知っていることのほうが大事（By サーバーワークスの大石さん）
前職で技術セミナーとかキャリアセミナー系の運営を一時期やっており、その主幹はマーケティング部門で自分は部門外だったのですが、それなりに人脈が合ったこともあり、イベントの趣旨を踏まえつつ、先方にとってメリットがありそうな人とか会社の方を紹介するというこんな↓社内向けにマッチングサービスみたいなこともやってました^^
マーケティング部門 ⇔ 自分 ）⇔ これまでの社外活動で得た人脈通じて社外のエンジニアの方など
そういう活動の中で、サーバーワークスさんに2,3回ほどお話しいただいたり、ワークショップをやってもらったことがあるのですが、サーバーワークスの大石さんのお話しの中で、クラウドの時代にはクラウド間を結合させる化学式を知っていることのほうが大事というニュアンスのことをお話しされてました。
私が講演などでよく話している「クラウドインテグレーターの強みは、クラウド内もしくはクラウド間を結合させる化学式を知っているかどうかだ」という文脈においても、salesforceとAWSという重要なクラウドの知識が両者のアライアンスで結集されることは非常に大きな意味を持つことになると確信しています。
現在の自分の状況
ついつい機能とかに目がいってしまう傾向に陥りがちですがそれが本当に必要なのか？というのを議論の中で見失わないように常に意識しており、そのかいあってか、効果測定したいポイント含めて当面検証しないいけないことが明確になってきました。
実際にユーザさんがその機能をつかってもらう前に、色々な準備（アプリをダウンロードするとか、ユーザ登録するとか・・・）が必要になるような仕組みだとそもそも使ってもらえないという状態になりそうなので、そういうユーザさんには、ネイティブのアプリではないけど、他の手段で代替できそうなアプローチを見つけてそちらでいくことにしました。
一方で、ユーザさんの中でも特定の属性の人には必須となる機能がネイティブのアプリでないと実現できない所が出てきたのですが、幸い、その属性にマッチする人は直接あって状況説明しつつこちらがアプリの設定まで出来そという目処があったのでネイティブのアプリを最低限作りこんでます。
議論を踏まえて必要な機能
あまり細かいことは流石に書けないのですが
- ネイティブのアプリ
- ユーザ向けの機能
- Webアプリ
- ユーザ向けの機能
- 効果測定のためのツール（GoogleAnalyticsも含む）
- バックエンドで定期的に動作するcron的なアプリ
- ユーザ向けの機能
- 効果測定のための集計処理
という感じでアプリが必要になりそうな気がしてきました。
とりあえず考えた構成
DBの機能＋Web API＋αを持ってるという部分で使い慣れてるACSを起点にして、JavaScript/CoffeeScriptで書けるもので周辺を固められないかなぁと思ったら意外とすんなり出来ました。
- ネイティブアプリはTitanium Mobile一択。
- Webアプリもユーザ向けについては、ペライチ的な1枚もの情報で済むので、基本的にはAmazonS3のStatic Web Hostingの機能でHTML/CSS/JavaScriptと画像で事足りそうな
- トラッキングの処理とか細かい所で多少作りこみが必要だったのですが、最近のJavaScriptフレームワークで標準的に持ってる機能を使えばすぐに実現できそうだったので最近使い慣れていたAngularJSを使ったモノで検証して実際に意図したことが出来ることを確認
- 効果測定のためのツールでGoogleAnalyticsは別として、それ以外にちょっと固有の日々集計処理が必要になりそうで後述のHubotとGoogle Apps Scriptあたりを組み合わせて行う予定
- バックエンドで定期的に動作するcron的なアプリ
- CoffeeScriptで書けるGitHub製のBotツールであるHubotを活用。Heroku上でcron的に動作させてACSに定期的に接続＆特定の条件にマッチしたら処理を実行するイメージ
- 効果測定のための集計処理もACSにある特定の情報抽出→何らかの数値集計処理→結果を社内で使ってるSlackに流す or 抽出したものをGoogleスプレッドシートに貼る→ピボットテーブルか必要だったらGoogle Apps Scriptとかで処理を書く
別のものに作り変えたくなるタイミングで違う化学式を思いつくかが自分の今後の課題
最初に引用したサーバーワークスの大石さんは、クラウドインテグレーターという立場だからというのもあると思いますが、個人とか小さい会社で働いてる人こそ、こういう化学式をいくつも知ってると、これからやろうとしてることの技術的な観点での実現可能性を把握しやすいっていうのを今回仕事してみて気づきました。
今考えた構成のものをずっと使っていくことはそもそも視野にいれてないし、捨てる前提で考えようとはしてるのですが今のところACSに依存してる所が多いため、別のものに作り変えたくなった場合に、違う化学式をサクッと思いついて実行できるのかが自分の課題な気がしてます。
- バックエンドはMongoLabを採用してデータはそっちに移行する
- MongoLabのデータにアクセス出来るWebAPI的な仕組みをHeroku＋Node.js的なもので実装する
- フロント側のアプリ（ネイティブ、Webアプリ的なもの）を一部修正
という感じになりそうな気もしてるのですが、修正箇所とか移行作業が多く、もうちょっと違うアプローチないかなぁ・・
※最後に宣伝的な内容
最近の自分の活動成果を違う所で活かしたいと思って基本的にはプログラミング経験が無い方（プログラミングに興味があるけど、学び方のとっかかりがつかめない方とか仕事上、インターネット上のサイトの情報をよくチェックしてて、ひたすらコピペする作業に疲れを感じてる方）を対象に日々の面倒をプログラミングで解決！【入門編】というのを定期的に開催しようと思うので興味ある方のご参加お待ちしています
スタートアップのWebエンジニアとチームの文化の作り方考えませんか？というテーマでトークイベント実施しました
先週の木曜日ですがスタートアップのWebエンジニアとチームの文化の作り方考えませんか？というタイトルでトークイベント実施しました。
10名〜12名程度の規模で毎回やってって今回も、最終的な申し込みが9名で、当日全員参加という感じで講師⇔参加者はもちろん、参加者同士の交流も結構活発にあったようで、イメージしたとおりに運営が出来たかなと思ってます。
また、料理の方も、日本唐揚協会のサイトの地図をなんとなく眺めていたら、会場で使ってるコワーキングスペースCo-Edoから割りと近くにあるうまからさんが、唐揚の予約ができるということだったので、3日前に予約して、当日それと、あとはおにぎりを別のお店で購入して提供しました。
自分で運ぶ手間があるものの、ピザ2枚と同じ位の金額で、揚げたての唐揚プラスαを提供出来たので今後はこの唐揚とビールとプラスαの料理というのを標準構成にしていこうかなと思ってます。
写真を交えつつ本編のイベントを簡単に振り返る
いつも通り、最初に30分程度、唐揚とビールをつまみに交流会を実施しました。今回は登壇してもらった藤井さんが色々な人に喋りかけてくれて、参加されてる人同士もそれなりに互いに交流出来ていたので、最初の場作りもそんなに苦労すること無く本編に入ることが出来ました。
最初、藤井さんに20分程度、事前に準備してもらったスライドをベースに喋ってもらい、その内容を私の方で進行しながらこんな感じで都度ホワイトボードに書き出しておきました。
チーム作りに必要な文化の4本柱
チーム作りに必要な文化の4本柱として以下を上げていました
- モラル
- 技術(スキル)
- イシューとバリュー
- 笑い
最近、自分はリモートで仕事をしてるのですが、あとは互いに共通の話題となるようなことで盛り上がるようなことを取り入れるような工夫とか努力をしてるので、最後の笑いってチームの文化作りには大切かなと割りと感じているのでここを少し掘り下げて質問しました。
チームメンバーに共通の笑いのテーマって難しくない？
藤井さんは、まだ0x26歳らしいのですが、他のメンバーは10進数で20代の人が多い職場環境のようだったのでそうなると、共通の笑いのネタって意外と無さそうな気がしたので、その点について聞いてみました。
すると、藤井さんが、ある種いじられキャラとして成立してて、確かに、実際こんな感じで広報の人に問い詰めらて踏みつけられてる変な写真つきの前代未聞のイベント決定までの軌跡の記事が出てるのがその現れかと一人納得しました。
会場にいた人は上記の記事は知らないと思ったのですが、藤井さんが、ある種いじられキャラっていうのはなんとなく喋っていた雰囲気とかからは伝わっていたのかなと思ったのですが、1つ気になったことをもう少し掘り下げて聞いてみました。
誰が最初のいじり役だったのか？そしてフォロワーはいたのか？
今でこそ、藤井さん＝いじられキャラの図式が成立してるけど、それが成立するのに、
- 最初に誰かがツッコミというか、藤井さんをいじりはじめた
- そのイジる姿を見てて、「あー、こういう風にすればいいのか」というフォロワーがいた
というのがあって初めてこの図式が成り立つのかなと思ったので、いじり役が誰か聞いてみました。
※フォロワーは以下参照
リーダーと同じくらい大事な役割の「フォロワー」
これは、@kyannyさんがTEDの社会運動をベースに話を展開していったのですが、最初に物事をはじめるようなリーダーの存在はもちろん大事だけどでもその後につづくフォロワー(追随者)が重要な役割を担っていて、その人が、みんなに どう従えばいいか示すことをするのも同じくらい大事っていうことを話してくれました。
※リモートワークの問題意識より引用
すると、藤井さんをいじるのは社長らしく、いつも藤井さんと社長とで何か言い合っているそうです。それを見ていた他の人もいつのまにか追従していたようです。
そのフォロワー役が誰だったのかは具体的に聞き逃してしまったのですが、いづれにしても
- イジる人：社長
- フォロワー：他の誰か
というのが成立してたようです。
また、トークイベントの中でも触れたのですが、20代の人⇔社長⇔藤井さんという感じの年齢構成になっていそうで、社長が年齢的に真ん中でちょうど上と下をつなぐ立ち位置にいらっしゃって、そういう意味でも、トークノートでは社長の立ち位置が結構重要な所にいるのかな〜ふと感じました。
この後は、参加者の方々が聞きたい内容を隣同士ペアーになってもらって紙に書き出してもらってそれをベースに、藤井さんに再度喋ってもらい、午後9時で一旦トークイベント自体は終了して、その後任意でまた懇親会をしてという感じでイベントを無事終えることが出来ました。
今後のトークイベントですが当面活動ストップしようかと思ってます
やりたいネタは結構あって、例えば
- 先日書いたリモートワークについてのやつをソニックガーデンの倉貫さんをお招きしつつ行う
- 非エンジニアのスタートアップの起業家の方がエンジニアの仲間集めに苦労する一方で、シードスタートアップに特化した開発支援を行うために、株式会社StartupTechnologyを設立された菊本さんのような方がいるので、こういう所での場作りのお手伝い的なこと
- 最近やってないけど、インフラエンジニア系の話題
とか他にもやりたことはあるのですが、トークイベントを開催する度に、赤字が続いてます。
というのも、参加者からわずかですが、お金をいただいているのですが、そこから会場利用代金、飲食代金、講師謝礼というのを考えると、現状の想定参加人数で黒字にするのはちょっと無理かなと・・・
かといって、
- 参加料金を値上げ
- 期待値が上がってきて、そうなると、イベント自体の空気がちょっと変わってしまいそうな懸念があるのでそういうのは避けたい
- 想定参加人数を増やして最低15名とかにする
- 話す人→聴く人という構図になってしまいそうで、互いの交流を図る運営を行える自信がないのと、何より規模が大きいのは自分が一番やりたくないのでそれならば多少無理してでも今の人数規模を維持するものを開催したいと思ってます。
- 10名程度のトークイベントでもいいので懇親会程度の料金をスポンサードしてくれる人とか会社を探す
- その規模をスポンサードするメリットをこちらが提供できない。（どこかの会社のリクルーティング目的のイベントなら成立するのですが、応援したいような人がいる会社でないと気乗りしない・・）
という感じなので、良いアプローチが思いつかないので、収支的に赤字にならないようなイベントでない限り、当面活動ストップしようかなと思ってます。
色々あって念願だったTitaniumでのiOSアプリ開発の仕事をしてます
タイトルですべていい尽くしてますが、色々あって念願だったTitaniumでのiOSアプリ開発の仕事をしてます。
これまでの経緯
9月半ば頃に、フリーになって3ヶ月ほど経過したのでふりかえりでは
知り合いの所のWebサービスの開発＋運用＋開発体制の整備
と書いていましたが、そちらのサービスとは違う新しいサービスをやる方向になりました。
これからやろうとしてるサービスが価値あるものなのか検証をするのにあたって機能的な部分とは別に、実際にユーザの手間がかからないように配布して、使ってもらう・・・という状況になり出来ることなら何もつくらずにいきたい所なのですが、ある所だけは、スマフォの機能を使わないとサービスのキモになりそうな所の検証が必要になってきました。
そんな状況なので、MVP（Minimum Viable Product）となるものを作るために、自分が慣れてるTitaniumでスマフォアプリを作り、バックエンド側も慣れてるACSをベースに足りない所は、最近のJavaScript界隈の技術要素（Node.js、Hubot、あとは実行環境としてHeroku）で開発することになりました。
ちょっと前まではRails＋AngularJSな感じだったので久しぶりなのですが、我が家に帰ってきた感じで、Titaniumでの開発を最近やってます^^
いつでも捨てられる安心感があるのが心強い気がする
基本的にはエンジニア的な役割出来るのが自分1人というのもあって、慣れ親しんでるTitanium、ACS、Node.js、Herokuと、ちょっと前までいじっていたAngularJSを一部使う形で作ってますが、ずっとこの構成を続けていくとはそもそも考えてません。
というのも、ACSの無料枠を超えるほどに利用率が上がった場合に、有料プランが、サイト上に具体的には記載がなく、Contact Sales という状況なのと、もくもく会とかで聞いた話だとおそらく資金的に今手伝ってる会社では支払うには厳しいのかなと思ってます。
なので、これからやろうとしてるサービスに必要になるであろう機能がある程度見えてきた段階で、少なくともACSを使っている部分は別途違う仕組みを使って作りこむ必要が出ると思ってます。
もちろん、ACS的なものを最初から作れればいいのですが、そこまでの余力が無いし、そもそも論でいうと、そうなるかどうかもわからないので、そうなりそうなタイミングで、切り替えを考えようかなぁと思ってます。
いつでも捨てられるというのは、極度にそこに依存しないように考えるべきなのかなとふと気付き、自分でもよくわからないのですが、何故か安心感があってそれが心強くもあったりします。
おまけ：Titaniumで開発する中で得られた知見はQiitaに投稿してます
ちょっと前のもくもく会で、Qiitaへの投稿をしましょう的なLTに刺激を受けて、こんな感じでQiitaに出来る範囲ですが投稿してます。
- Titanium用のGoogle Analytics for iOSモジュールの作り方
- Titanium + Alloy + napp.alloy.adapter.restapiで作る簡単Qiitaビューワーアプリ
今後もQiitaに投稿する or それとも自分のブログに投稿する（あるいは両方に投稿する）かはちょっと悩み所なのですが、Qiitaに情報集めておいたほうが結果的には有益な気もするので、Qiitaを中心に投稿していこうかなと思ってます
リモートワークの問題意識
「リモートのメンバーがいる状況でのファシリテーションについてどうすればいいのか手応えを掴んできた」 っていうことしゃべっていたのをふと思い出し、連絡をした所、gaoryuさんも日々、模索中とのことで、似た境遇の人同士でしゃべれば何かヒントになるかなと思って来週会うことになりました。
どうせなら、似た境遇の人を他にも誘ったほうがより議論が深まるかなと思ったので、知り合いを誘って来週そんな感じで集まることになってます リモートのワークスタイルを3ヶ月やってみて感じてることより
と書きましたが、先日これを話題にして、私、id:gaoryuさん、@kyannyさんの3名で集まったのですがかなり濃い話が出来て、ブログにまとめようと思ってもうまくまとめきれない状況になってます^^;）
その時に感じた熱量というか想いみたいなものを忘れないように、ひとまず、まとまりそうなところだけ書いておこうと思います。
リモートの問題意識
id:gaoryuさんが、いつものように持参されたノートを使ってこんな風に↑に書き出してくれたメモを見変えていたら、リモートの問題意識っていう内容に自然と目が向いてしまいます。
そこで書かれてる内容はというと
- キョリ
- 時間
- コミュニケーション
- 価値観
という感じです。
@kyannyさんの所はこのエントリで書かれてるように、キョリ的な所で完全にリモートだし、上記では書かれないですが、以前はイギリスのチームと一緒に仕事を指定たので、時間的な部分でもリモートワークにおける問題意識というのをお持ちでした。
自分の場合には、日本人同士なんで、一見すると物理的な所だけ・・という感じがしそうですが、リモートワークしてて、時間的な所の問題意識が実はあったんだなと気づかされました。
日本人同士でのリモートワークでも時差を感じる背景
元々、自分は朝型の生活リズムであることに加えて、他にいくつか仕事をしてるので、1つの仕事を朝から夜まで関わることが出来ないという状況があります。
一方で他のメンバーの方というと
- フルコミットしてる方
- 本業の合間とかの空き時間を使ってお手伝いしてる方
という感じになってます。全員がフルコミットしてる状況なら、キョリの問題意識だけになりそうですが、本業の合間とかの空き時間を使ってお手伝いしてる方がいる状況だと、例えば、
- 作業自体は簡単だけど比較的急いで対応してもらいたいタスクがあった場合とかに、他の人にお願い出来ない（もしくはお願いしても、意図した時間内で終わるかどうか見えない）
- ある時間帯に生じた出来事についての認識に温度差が生まれやすい
ということが割りと生じてしまい、１つ１つの出来事はそれほど些細なことでないのかもしれないですが、こういうちょっとしたことの積み重ねによって、リモートの陥りやすい構造の絵につながるのかなと。
リーダーと同じくらい大事な役割の「フォロワー」
これは、@kyannyさんがTEDの社会運動をベースに話を展開していったのですが、最初に物事をはじめるようなリーダーの存在はもちろん大事だけどでもその後につづくフォロワー(追随者)が重要な役割を担っていて、その人が、みんなに どう従えばいいか示すことをするのも同じくらい大事っていうことを話してくれました。
このフォロワーの話は印象深いのですが、うまくまとめきれないので、別の機会に改めて書くかも
その他、印象に残ってる話題など
- リアルでは、仕事と関係ない雑談とかから、インプットを得られる。しょうもない呪術師みたいな変な土産品とかオフィスないで流れる音楽とか
- リモートは物理的な場所だけが問題ではなく時差もあるのでそこも課題
- 物理的ｘ時間的に差があることで、結果が出るまでの過程のコンテキストが共有されてないから、別に悪気があるわけでもないし、正論なんだけど相手のちょっとした一言も印象が変わる
- プロジェクターは１つである必要がない。
- 場作りをする上で2つあったほうがいいなら準備する
- そして、机の配置もそもそも場に沿った形にするのがあるべき姿
- フィードバック大事。どんな時でも
リモートワークは色々課題があるけど、考える余地があるので面白い気がする
はてなのCTOのid:stanakaさんがはてなMackerelチームの開発フロー（スクラム、リモート）について話しました #nanapi_study #hatenatechについてのはてブコメントで
って書かれてましたが、確かにそうだなぁと思ったので、こういうリモートワークをする上で現状の課題や問題意識を持った人同士で集まるトークイベントは改めて実施したいし、実際興味・関心ありそうな人が周囲に数名いるのでそういう人プラスαで来月あたりに実施しようかなと思ってます
