客先常駐という働き方はもうやめにできないか、っていう話が盛り上がっています。

実際自分が体験して、また仲間を現場に送りこむ立場になって思うのは、この働き方は働き手にあまりに負荷をかけるのではないかということです。
IT業界で客先常駐という働き方はもうやめにできないか - あいむあらいぶ

どういう問題があるのかについては、記事に書かれているとおりだと思いますので、元記事を読んでいただければと思います。

そういう問題が起きがちであることは認めつつも、それを解決することにほぼ成功していた会社で働いた経験があるので、この記事では、どういう対策が行われていたかを書いてみようと思います。



イソップ童話の「オオカミ少年」は、嘘をついた少年が狼に食われるという結末が有名ですが、もともとそんな結末はなくて、「村の羊はすっかり食べられてしまったとさ」というのが結末だったんだそうです。

日本ではイソップの話であるとして、狼に食べられるのは羊ではなく「羊飼いの少年」とする寓話がいくつも存在する。
(嘘をつく子供 - Wikipedia)

誰かが作り替えた話が、「そっちのほうがわかりやすいから」ということでどんどん広まっていって元の話を駆逐してしまう展開は、パクツイとかバイラルメディアでよく見られる現象ですね。

ところで、「村の羊はすっかり食べられてしまったとさ」という結論が元だとすると、これってどういう教訓だったんだろう、というのがfacebookで話題になりました。

食べられたのが少年じゃなくて村の羊ということは、村の人々の行動に問題があったということになります。ウソだかホントだかわからない話を鵜呑みにして、いきなり全員で武器を持って大騒ぎしちゃったことが問題なんじゃないでしょうか。
村人は、少年の話をきいた時点で、とりあえず武器を持った人を索敵に出して、他の人は冷静に待機しておくべきだったのです。
そういう対応なら、嘘だと判明しても「コラ!」って叱れば済む程度の話だっただろうし、対応コストが低いから、二回目以降も同じ行動を取り続けることが出来て、本当に狼が来た時には全力で事にあたることが出来たはずです。

センセーショナルな情報を見たからといって、真偽を確かめずに大騒ぎしてはいけない。

最近はバイラルメディアとかの流行りで、「わー!」「大変!」と言いたくなるようなタイトルの付いた記事があふれています。いちいちまともに受け取って騒いでいたら、体も心も疲れてしまいますよね。
本当に「これは大変だ」と思うのなら自分で真偽を確かめてから話題にすべきだし、そうでないのなら「ふーん」と言いながら判断を保留するくらいの態度がいいんじゃないでしょうか。オオカミ少年の話題を聞いてそんなことを思いました。



2008年の公開以来、沢山の皆様に使っていただいた「メイドめーる」ですが、サービスを終了させることにしました。

直接的な要因としては、GoogleカレンダーのAPIが更新されて、コードをバージョンアップしないと正常に動作しなくなっていたことです。このまま放置して意味不明なメールを送信し続けるよりは停止させたほうがいいと判断しました。

サービス終了の時、「社会環境が変化して役割を終えた」というのがよくありますが、メイドめーるに関しても同じことが言えます。
メイドめーるを開発した2008年は、iPhone3Gの発売直後、まだAndroidは存在すら怪しい時代でした。iPhoneでGoogleカレンダーを見るためには「同期」が必要で、Googleカレンダーと同期させる方法がブログネタとしてアクセス数を集めるような時代だったのです。

時は過ぎて、GoogleがAndroidOSを発表し、Googleのサービスはスマートフォンからアクセスできることが当たり前になりました。Google Nowでは、その日の予定をお知らせするのはもちろん、現地までの所要時間を計算して、「もうそろそろ出ないと遅刻しますよ」と通知までしてくれるようになりました。僕自身、GoogleNowのほうが便利なので、メイドめーるについては使わなくなってしまってずいぶん時間がたってしまっています。

まだガラケーのユーザーが残っているじゃないか、iPhoneのGoogleNowはそんなに便利じゃないぞ、というような状況は知っておりますし、メイドさんが好きだったのに、というユーザーさんがいてくださることはありがたいことなのですが、そもそもGoogleカレンダーを便利に使うためのサービスである以上、Googleと競争をするというのも馬鹿げた話ですから、これ以上の改善については、Googleにお任せするのが良いかと考えました。

お預かりしていたデータについて

メールアドレスやアクセストークンについては、責任をもって破棄させていただきます。
メイドめーるのサービスについては、ドメインを引き継いで運営したいという会社さんがおられるため、ひょっとしたら今後、運営会社が変更になってサービスが再開する可能性がないとは限らないのですが、その際にも、新たな会社さんにユーザーデータを勝手に譲渡したりすることはありません。

ソースコード

githubで公開しました。相当古い環境だし、テストも書かれていないのでこれをそのまま動かすことは困難だと思いますが、何かの参考になるかということで公開しておきます。

mogya/maidmail


今や会社でもドキュメントをGoogle Docsで作成してメンバー間で共有することは珍しくないと思うのですけど、これをやると、メンバー管理問題が発生します。
「もぎゃさーん、Aのドキュメント見えないので権限追加してください」「はいはい」
「Bさんが、ホゲホゲのドキュメントに対する編集権限をリクエストしています」
「ぼく総務部じゃないんだけど!」


ダイナミックに人が増えたり減ったりする組織になると、ドキュメント一個一個に対して共有なんてしてられないのですよね。

一般にこういう問題に対してはGoogle Apps For Workを使うことが勧められているのですけど、これだと自社ドメインのメールアドレスを持った人しか管理できないのですよね。

で、Googleグループ。実はGoogle DocsにはGoogleグループを指定して共有する機能があります。

tmp_txt_-_Google_ドキュメント_15_33_45.png

こうしておくと、Googleグループに参加している人に対してまとめて権限を付与できるようになるので、新しいメンバーが参加した時も、誰かいなくなった時も、Googleグループのメンバー管理機能を使って管理することが出来るようになります。
自社ドメインじゃないgmail.comのユーザーも追加できるし、いまやGoogleアカウントはgmail以外でも使うことができるので、実質的にどんなメールアドレスでも管理することができるのがメリットですね。

Google_グループ.png


この記事は、以前書いた「不要なところは削除してやりたい放題できる『編集』 - もぎゃろぐ」の再掲です。需要はあると思うのになぜか広まらないのでもう一回書いてみる!

WEBサイトをキャプチャするとき、微妙に都合の悪い要素を削りたい時ってあるじゃないですか。広告とか、ユーザーさんのお名前を伏せ字にするとか。普通そういう処理は画像編集ソフトでやるのですけど、めんどくさいじゃないですか。動画とかそう簡単じゃないし。
そういう時、ブラウザで見ているページの中身を一時的に書き換えることができます。

編集

このリンクを右クリックして「お気に入りに追加」します。
alert.JPG

こういう警告が出ます。警告の内容は書いてある通りなので、信用できる方だけ「はい」を押してください。


先ほどのように、編集したいページに行ったら、そこでお気に入りから「編集」を選ぶと、WEBページにカーソルが出てきます。
Cursor_and_仕事管理___Any_Times・エニタイムズ.png
任意の箇所を変更することが出来ます。
Cursor_and_仕事管理___Any_Times・エニタイムズ 2.png
余計なところを削除したりできるのが、撮影の時に嬉しいです。
仕事管理___Any_Times・エニタイムズ 2.png
撮影に邪魔なカーソルは、どこか画面に映らない場所に移動させておきます。
あと、書き換えた画面は、もう一度ページを読み込み直すと元に戻ります。


(2015-01-13 追記) sssslide側で対応していただけたので、ここで紹介したスクリプトを使わずとも、本家に掲載されているブックマークレットがそのままスマホでも動作するようになりました! (追記終わり)

SSSSLIDEというサイトがあって、SlideShareSpeaker Deckにアップロードされているスライドを、縦に並べてみることができる。

実はPCだとそんなに必要性を感じないのだけれど、スマホで使うととても便利。

Screenshot_2015-01-12-22-09-02.png

slideshareのスマホViewは、横にスライドして読むようになってんだけど、普段左手でスマホ持っていると、この動作はちょっとやりづらい。縦にスライドするほうが楽だし、全部表示されていたほうが断然早く読めるよね。



スタートアップツールチラ見せ♡ナイトというイベントでAnytimesのツール導入状況についてお話してきました。

  • 社内でLINEが実用的に使われているところが笑わせどころのつもりだったのですが、案外みんな使っていることが判明して、LINEすげーと思いました。
  • 新しいツールを導入する時は、ゆるさが一つのポイントになる。
    • slackだったら高橋くんみたいなおもしろロボットをいれておくとか。
      トレタでの「slack」活用を紹介してみる - @hitoshi annex on hatena
    • Anytimesの場合は、そこまで手はかけ(られ)なかったのですけど、デザイナさんがslackbotのカスタマイズ(だれかが「いいね」と言ったら「いいねいいね!」と返すとか)で遊びはじめたのが良いきっかけになりました
    • slackでbotを導入する時はアイコンが命。男性の多い会社だったらアイドルとかアニメとか、そうでなかったら会長とか社内の有名人とか、そんなのを使って親しみやすさを作る。


管理画面チラ見せ♡ナイト#2 (#admin_night)見て思ったこと。「管理画面にも銀の弾丸はない」

個別の話も面白かったんだけど、それよりも、会場で質問している人と、登壇して自分の作った管理画面を説明している人の対照が面白いなーと思った。
僕もそうなんだけど、「うまくいかないんです」と質問している人たちはたいてい、本業とのリソース配分に悩んでいて、「どのくらいのリソース配分でやったんですか?」「何日くらいで作ったんですか?」と聞いていた。
それに対する回答は「マネージャさんの要求に答えて作っていたスクリプトが管理画面になりました」「本業の合間に楽しいから作ってました」というものばっかりで、具体的に工数確保した人がぜんぜんいなかった。
あと当然だけど、「これを使ったら一瞬で管理画面ができたんですハッピー!」みたいな話もなかった。

ベンチャー企業にリソースが足りないのは当たり前の話なので、そこで工数確保とか考え始めるとなんにも動かなくなってしまう。
エンジニア一人で開発からメンテナンスサポートまでやっている状態で管理画面を作るのと、サーバエンジニアが副業で作るのでは後者のほうがちょっとリッチかもしれないけれど、まあその程度の差で、ダブダブにお金があまってるから管理画面にデザイナとエンジニアを貼り付けられるような会社なんて存在しない。

その中でどうするかといえば、本業の開発と一緒で、やることが多すぎる状況の中でほんとに必要なのはどれか見極めるとか、エンジニアが楽しいから勝手にやっちゃうとか、そんな解決方法しかないんだと思う。

その他のメモ

  • おだんみつさんは @masuidriveに這いよる謎人だと思っていたけど、21cafeの頼りになるお姉さんだと見解を改めた
  • 「管理画面のデザインの良さはオペレーターのやる気に繋がる」
  • 「本業よりもクイックに喜びの声が上がるのでむしろやる気が出る」
  • 「画面横幅は貴重なリソースなのでムダにしない」
  • datadog 管理画面的にいろんな情報を集約してくれるサービス


RubyHirobaのLTについていくつかお話できることを。

結果的につまらないプレゼンで時間をとってしまって、さらに運営に余計な対応をさせるはめになってしまったことはホント申し訳ないと思っております。

今回話題が公になったので、引き続き議論していただくための参考資料として、僕の側から見て何が起きていたのかを説明させていただきます。

前日まで

 RubyMLのメールでLT募集のことを知りました。

[ruby-list:49953] 9/21(日) RubyHiroba2014の参加受付中です

 これは面白いんじゃないかな、と思って、今回のようなLTをやろうと思っている旨を当人に相談した所、OKが出たので、LTthon | RubyHiroba 2014を見て、応募フォームからタイトル書いて申し込みました。この時、アンチハラスメントポリシーにはぜんぜん気付かなかったです。わりとギリギリの話題をやろうとしている自覚はあったので、気づいていたら止めてたと思います。

 LT申し込みフォームにタイトル記入欄があったから、内容が明快にわかるように「社長が美人で何がわるい」というタイトルで申し込みました。ダメならここで止めてくれるだろうと思ってました。
 結果的には、工数がないからノーチェックで通ってしまったのだそうです。ボランティアだからそうなることは仕方ないと思うのですけど、この時点でそんな可能性はまったく思いつかなくて、当日の案内メールが来たことで「あ、OKなんだな」と理解してしまいました。

当日

 一人目の人が欠席で、結果的にぼくがトップで発表することになりました。

 発表が*終わってから* 「ところでRubyHirobaにはアンチハラスメントポリシーというのがあります」といわれて、ドキっと思わなくもなかったのですが、その後「PHPをDisったりするのは禁止です」というから、「あ、これは場を盛り上げるためにぼくのネタを引き継いで冗談を言っているのだな」と理解しました。

 その後も、Tシャツ取りに行った時とか、「ここで食事しても大丈夫ですか?」ってスタッフの方に確認に行った時とか、どこかのタイミングで直接言っていただけたら、記事の公開を見合わせるとかもありえたのですけど、上述の通り冗談をいわれていると思っていたので、ぎりぎりオッケイなおもしろいプレゼンをしたつもりでいました。

 時間があればもう一個枠をいただいてRails+GoogleAnalysticsの話もやろうと思っていたのですけど、前日から体調不良気味だったし、午後になって枠がいっぱいになっていたので、無理せず帰宅しました。ひょっとしたら運営の方は、終わってからお話をしたかったのかもしれないですね。

月曜日

 土曜日のRuby関西同窓会で、LTと同様の話をしてスカウトした方がオフィスに来てくれたので、僕としては成功したつもりになってました。
そこで、資料に出ている当人にプレゼンを見せて、「公開してもいい?」と聞いたところ、「いいよ」とのことだったので、ノリノリで資料も公開しました。

半日後くらいにRubyHiroba運営の方からメールを頂いて、ここで初めて事態を悟りました。
指示に従って資料は非公開にして、連絡を待っていたのですが、今日になって、「RubyHirobaの アンチハラスメントポリシーに明確に抵触するものではない、という結論になりました」というメールを頂きました。WEBサイトで「残念ながら、ジェンダーや性的な表現について、アンチハラスメントポリシーに抵触する発表がありました」と書かれていることとの整合性については、僕にはよくわからないです。

LTthonで行っていただいたプレゼンですが、運営で協議したところ、RubyHirobaの アンチハラスメントポリシーに明確に抵触するものではない、という結論になりました。 曖昧な言い方で大変申し訳ないのですが、「あのようなポリシーを掲げているイベント での発表としてはあまり好ましくない。しかし、どこがダメで誰に対してのハラスメント であるかを明確にすることが難しい」という判断です。

ただ、ポリシーに抵触するのかしないのかはさして重要ではなくて、くだらないLTのために運営に余計な手間を取らせてしまったことはほんと申し訳ないし、調子のってたなーと思っております。以後気をつけます。



modern.ieでIE8の動作確認していて、昨日まで動いていたはずのデザインが突如崩壊した!リリース直前なのに!respond.jsが効いてない!?なんで?

コードを戻してみたり、「respond.js 効かない」でググってみても直らない。迫るリリース時刻!電車の動き出す音!

って時は、そのVirtualMachineが外部ネットワークに接続できるかどうか確認することをおすすめします。CDN上のrespond.jsはネットワークにつながってないと当然動きません。
ホストマシンのrailsでテストしていると意外と気づかないので、パニックになった時は一度ご確認を。

・・・あー。びっくりした。



Powered by
Movable Type