「クローズド掲示板」というニーズがある

オフ会とか趣味のつながりの仲間内でのクローズド掲示板というニーズがある。職場や友だちとは別のつながり。

以下選択肢

• メーリングリスト
• mixiコミュニティ
• FaceBookグループ
• LINEグループチャット
• Yammer
• Slack
• FC2SNS

一昔前ならmixiコミュニティ。今ならFaceBookグループ。
ただし、オフ会って趣味のつながりであって、リアルなソーシャルグラフとは別。
どちらかというとTwitterのフォロワーのつながり。

できればハンドル名でのコミュニケーションをとりたい。

そうなると単体のメーリングリストってのがちょうどいいのだけれど、「いいね」がないとか、通知がうざいという、メーリングリスト本来の課題は残ったまま。メーリングリストも、GoogleGroupsは管理画面が超分かりにくい。

単純に掲示板って話で言えば、LINEのグループチャット通知のコントロールもしやすい。知らないモノ同士も集まりやすい。LINEはハンドル名でやってる人も多いが、ハンドル名と実名を使い分けたい人には辛い。趣味のつながりを「足したい」人にとっては、アカウントはたしたいもの。LINEをPCで使ってない人も大事を考えると、スマホしばりという制限もコミュニティとしてはハードルを高めている。

Yammerは企業向けで、独自ドメインがないと辛いし、Slackはアカウント作成の時点で英語だらけでみんなに使わせるには厳しい。

専用のSNSを立ち上げるという案もある。FC2でも無料のSNSを立ち上げることができる。ただしこれはmixiをもう一つ立ち上げるようなものなので、その中でもう一回コミュニティを立ち上げて正体をするという階層になって正体後の導線が分かりにくい。

ソーシャルとか要らないから、コミュニティだけ使えればいい。
実はmixiはアプリとしては、mixiコミュニティといってコミュニティ単体を取り出して使えるようになってる。人をたどる昨日とかは薄め。

今見るとmixiのコミュニティだけはまだまだアクティブに使われている。これでいいかも知れない。

ということで
案０．メーリングリスト
案１．mixiコミュニティ

全部ブラウザ計画

だいぶブラウザのみで仕事ができるようになってきた。ブラウザだからこそ効率よくすすめれるところもあるので、まとめたい。

モダンでMacなRubyな話

言語としてのRuby単体ではなく、周辺の便利ツールとそのレイヤーを整理。

Herokuを使うという腹ぎめ

●PHPという存在
ケータイ公式サイトから始まって、ソシャゲの会社がボコボコでるところまで、PHPばっかりだったんですね。PHPの何がいいかって言うと、Apacheとの結合がしっかりしていた。Apacheのプロセスをしっかり管理していれば、PHPもついでに管理できる。Webサーバとアプリケーションサーバが別れてないから、ノードが減る。ノードが減るから故障管理も減る。

デプロイなんて言葉も、PHPを使ってる人にしたら、それファイルのコピーじゃないですかって話。

phpmyadminもWordPressもPHP。ロリポップにコピーするだけで動いてくれる。まぁ便利。
ロリポップで始めてアクセスが増えたら、ちゃんとしたサーバに載せ替えればいい。

大きい方のスケールも、APC使えば、Apacheのメモリの中にPHPのコンパイル結果が入るから爆速。相当気になんない。でも事情が変わってきた。

●外部環境の変化

・Rubyが速くなってきた
・Rubyのバージョンが安定してきた＆バージョン共存のためのソリューションがしっかりしてきた
・Apacheのスタンダードが崩れてきた（のでPHPの相対的優位性が崩れてきた）

●Herokuを使うとこれがいい

・AWSからゼロから構成しなくていい
・CDNとの連携とかすごく楽
・PaaSを使うという腹ぎめとほぼ同じ
・PaaSは、小規模から大規模までシームレスに「アプリ構築のみ」に集中できるというのがメリット

●herokuの競合と比べるとこれがいい

• GoogleAppEngineと比べると
• GAEはGAEでしか動かないフレームワーク他にもってけない。
• Windows Azureと比べると
• Windows Azureは、.netフレームワークをベースに作っているので、開発環境がVisualStudioを想定している。（プレーンテキストエディタでも理屈の上では開発できるはずだが、情報が少ない）Macで.net開発は全くイメージつかない。
• つまりherokuは「ロックインされないPaaS」と言える。

●PHP＋ロリポップ→PaaS
という時代の流れ。PHPだとファイルコピーするだけでどこでも動くってメリットって、クラウドになるとぐっと薄れる。PaaSでも小さく初めてシームレスに大きく育てることができる。
対応すると書いてはいるが、必要となる知識の量が全然違う。Herokuを使うのはRoRとGitの知識が必要で、htmlにphpタグを埋めたものをFTPでアップしていた人がすんなり以降出来るとも思えない。そこは課題。

●セキュリティやらレギュレーションがどうたらこーたら
最悪発注元から、herokuやだって言われたり、AWSやだって言われたり、クラウドやだって言われたら、専用サーバにRubyで作りなおせばいいっちゃぁいい。PaaSのメリットが享受できないだけで、大したマイナスではない。

オフィスリノベーションのコツ

自前のオフィスをリノベーションしてみました。私も勉強しながらではありましたが、知識は付きましたので、ここにメモ。

カレンダーの同期あれこれ

なんらかのアプリで予定表ができたのなら、それをGoogleカレンダーやiCloudのカレンダーに取り込みたいよね。

●icalの取り込み
メリット：手軽
デメリット：スマホだと、icalファイルの取り込みに対応しておらず、一度GoogleカレンダーのPC版に移動する必要がある。

●招待メールの送信
メリット：招待を受けてからの導線がシンプル（たぶん）
デメリット：一つずつしかできない

●インテントを利用
メリット：導線が最短
デメリット：一件ずつしかできない。スマホしばり。

●GoogleカレンダーAPIを使う
メリット：一括で操作可能、相手に渡した後も修正が可能
デメリット：ユーザに認証してもうらうのがちょっと手間

「シリアライズ」目的のORマッパーがあってもいいじゃない

ORマッパーでやりたいことって、その名の通り、オブジェクトとRDBを対応付けたいだけったりする。拡張性があった方がいいのだけれど、やりたいことしては「シリアライズ」に近い。

そしてシリアライズってデータ構造丸出しで、いわゆる「カプセル化」ってことは優先度が低い。

そんなわけでシリアライザーとしてお手軽につかえて、拡張しようと思えば拡張できるというORマッパーを自作してみた。オブジェクトとRDBというよりも配列とDBという組み合わせ。

UXって何よ？

UXってあれこれ言われているけど、どれもイマイチしっくり来ない。ユーザーインターフェースの改善だけじゃなくて、ユーザエクスペリエンスだよとは言うが、スコープが広くなった分、考える幅が増えている。だから定義しにくい。

ソーシャルな時代のプログラマーって何

SOLアイアーキテクト SEメンバーブログ:ソーシャルな時代におけるプログラマーという職業
http://iaseteam.eshizuoka.jp/e1306132.html

これに影響を受けて書きます。特にこの一節がポイント。

ログイン状態を保持するときの問題点

もうWebのシステムもログインしっぱなしでいいんじゃない？ってシーンは多いよね。

バックドアを作るという開発手法

あんまり開発手法として語られないけど、バックドアって概念があるよね。

サービスって作っていく時には、下から順に作っていくので、単体テストのフレームワークとかが開発手法として充実してる。んでも完成後のシステムのメンテに関しては割りとルーズ。エンジニアから手が離れてしまっているからかも知れない。

本番環境と開発環境の区別をつけるためのあれこれ

ファイルに書き込むという方法

分かりやすいが、リポジトリ管理がしにくい。リポジトリ管理をしないで済むように、リポジトリ上は、ignore設定するという手もあるのだが、リポジトリを全部持ってきてすぐ動くというのができたらやりたい。

環境変数に書き込むという方法

ファイルには存在しないのでいいような気もするが、環境変数に値をセットするというファイルはどこかにあるはずでそれはやっぱりリポジトリ管理をしたい。

ファイルパスで管理するという方法

ファイルのフルパスが
/nfs
で始まっている時には本番環境扱いでその他は開発環境扱いというのも便利。
フォルダ名の命名規則がしっかりしていれば割りといい線いってるかもしれない。
phpとかだと
if(strpos(__FILE__,"/Users/")!==false){
とかだと、Macっぽいパスで管理してるよねーって話。理想的には、

OSの違いで管理するという方法

本番サーバはさすがにUnix系で、開発はMacやWindowsということは多い。大概の開発言語はOSを取得する関数はある。CentOSだったり、Darwinだったり、

ドメイン名で管理するという方法

一見するとこれが一番良さそうだが、コマンドラインやcronから起動するときにはドメイン名という概念がそもそもない。

ローカルホスト名で管理するという方法

hostnameコマンドで帰ってくるホスト名なら、コマンドラインからでも取得できる。
しかしながら、今度はWebサーバが複数台になるとホスト名も複数パターンあり得る。

ブラウザ上で漫画を読むJavaScriptフレームワーク考える

週刊少年ジャンプのコミックスがいよいよ電子書籍に出始めたということで、メジャーどころも電子書籍に出てきた。アプリで読ませたりもしているが、ブラウザ上で試し読みさせるストアも多い。そこで漫画をスマホブラウザ上で読ませる仕組みについて検討してみたい。

GoogleのOAuthをユーザ・インターフェースなしに突破する

Googleの認証って昔はクライアントログインと言って、ID/PASSを直接入れるというパターンがあったが、セキュリティ的にダメってことでいよいよそのAPIが使えなくなった。ユーザからはなんの認証もなくファイルをアップロードするけど、サーバ側のプログラムでは、僕のGoogleDriveに格納したいなんて要件はありがち。その場合には、まじめにOAuthというのを使わなくちゃいけない。だけどよくあるOAuthって、ログイン画面にブラウザ上でリダイレクトするんだけど、今回はサーバ側で「とあるアカウント」で無理やり認証したい。ということでその解説。

タブレットが向いているお仕事ってのもある

タイピングしない業務であれば、タブレットが十分業務に使える。
SNSに投稿された画像やテキストのチェックなどで、実はリードオンリーの業務は多い。
PCよりもタブレットに適しるんじゃない？ってことを考えた。

GoogleNowで改めて見直されるプレーンテキスト解析技術

GoogleNowというスマホアプリがある。アプリとしてはGoogle検索なのだが、検索アプリを立ち上げると検索ワードを入れる前に必要そうなデータを提示する。

自宅と職場の位置を「なんとなく」推測して天気予報を出してるところくらいは想定の範囲内なのだが、すごいのがGmailの受信内容からの推測。

私が経験したのは、以下２つ

• Amazonの購入完了メールから、発送・到着までのお知らせをしてくれる
• 楽天トラベルの予約完了メールから、当日の飛行機の時間やそこに行くまでの経路を案内してくれる

いずれも、人が見るためのメールを解析して、メタ情報を抽出している。

Amazonに関しては、配送業者がヤマト運輸だったり郵便局だったりバラバラなのだが両方に対応しているのがすごい。
楽天トラベルに関しては、飛行機の便の名前と日付情報から推測しているのかもしれない。

ここから学べることというのは、人が見るためのプレーンテキストであっても、そこからメタ情報は抽出できるということ。HTMLのスクレイピングは、HTMLの構造をある程度利用していたが、素のプレーンテキストであっても推測はできるのだ。

発展させると、人間が認識できそうなメタ情報はいっぱいある。

• 飛行機の便
• 日付
• Lコード
• Pこーど
• イープラス
• 駅名（時間はかかるが認識可能）
• ライブハウス名
• 劇場名

例えばツイッターのワードをガーッとなめて、PコードっぽいものやLコードっぽいものがあればそれは予約可能なイベント情報だってことなのだ。

スマホアプリ受託あるある

• 情報提供型のサービスとはいえ、スマホアプリやんないとダメだよね
• リーチ取るためには,iPhoneとAndroidの両方対応するよね
• 無料集客したいからソーシャルメディアとも連携はとるよね
• コンテンツにいいねをつけるにはパーマリンク必要だよね
• じゃ、スマホWebも作るよね
• スマホWebでもアプリっぽいUIにするよね
• そこまで来たらネイティブアプリもWebViewで作る方が開発効率いいよね
• AppStoreの審査に出したら「これただのWebじゃねーか」って弾かれるよね
• AppStore対策で、ARとかつけちゃうよね

一番最初のステップで無理があるのかもしんない。

Androidのメモ帳アプリを試してみた

スマホに限らず、ガラケーの時からメモ帳は割りと大事。

ところがスマホになってからメモ帳の機能が豪華になってきた。
豪華なだけならいいのだけれど、ネストが深くなってメモとしてシンプルではなくなってしまっている。

カテゴリ分けとかリマインダーとかどうでもいいから、最小限のステップで入力ができて最小限の深さで再表示できるのがベスト。

以下試してみた。

ポーリングだっていいじゃない同盟

ポーリングってダサいイメージがあるけど、ダサいだけなら構わない。ダサい以上のデメリットがあるかどうか考えてみよう。

CTOってこれといった定義があるわけじゃないけど、私なりのCTOの定義をメモ

CTOってこれといった定義があるわけじゃないけど、私なりのCTOの定義をメモした

ログサーバが大事な理由

Webのシステムってログをどうするかってことが後回しになりがちだけど、超重要。

ログサーバがあるのとないのでは大違い。ログサーバのいいところをガンガン書くからね。

【メモ】地域SNSの可能性と課題

以下本当にメモです。地域SNSってどこまでいけるんだっけってことを考えた。

Gmailにも僕の既読状況がわかる仕組みを入れてみた

LINEやチャットのメリットは「相手が読んでいるのかどうかがわかる」ってとこ。メールはそのテンよくわからない。PCの前にいるのか席を外しているのかで状況が変わってくる。そこでメールにも、未読／既読状況をわかる仕組みを考えて作ってみた。

シナリオ

• 登場人物
  • Aさんと私の二人
• Aさんは私にメールを送信する
• 私はちょうど打ち合わせ中でメールが見れてない
• Aさんは私の受信箱の未読状況を確認する
• 受信箱の未読状況を見る限り、ここ１時間はメールを見れていなさそう
• ２時間前までは返信をしているので今日は活動していそう

実行画面

私の受信箱の状況です。

http://goo.gl/VQLDTN

ソースコード

function doGet(e) {
  Logger.log("start");
  Logger.log(Session.getEffectiveUser().getEmail());
  var buff = "";
  var aryInbox = getInboxStatus();

  //未読のメッセージをビルド
  var aryOut = Array();
  var dateList = aryInbox.unread;
  for(var i=0;i<dateList.length;i++){
    strDate = formatDate(dateList[i]);
　　if(typeof aryOut[strDate] === 'undefined'){
      aryOut[strDate] = new Array();
    }
    aryOut[strDate].push(formatTime(dateList[i]));
  }
  buff += "◆未読("+dateList.length+")\n";
  for(var k in aryOut){
    buff += k + aryOut[k].join(",") + "\n";
  }  
  //既読未返信のメッセージをビルド
  var aryOut = Array();
  var dateList = aryInbox.working;
  for(var i=0;i<dateList.length;i++){
    strDate = formatDate(dateList[i]);
    if(typeof aryOut[strDate] === 'undefined'){
      aryOut[strDate] = new Array();
    }
    aryOut[strDate].push(formatTime(dateList[i]));
  }
  buff += "\n◆既読未返信("+dateList.length+")\n";
  for(var k in aryOut){
    buff += k + aryOut[k].join(",") + "\n";
  }  

  //返信状況をビルド
  var aryReply = getReplyStatus();
  buff += "\n◆返信状況最近" + aryReply.length + "件 返信日時 <- 元時刻(リードタイムH)\n"
  for(var i=0;i<aryReply.length;i++){
    var row = aryReply[i];
    buff += formatDate(row.sent) + " " + formatTime(row.sent) + " <- " + formatTime(row.reply);
    buff += " (" + Math.floor((row.sent.getTime()-row.reply.getTime())/ 3600000) + "H)\n";
  }

  buff += "\n※ 未読と既読は受信トレイのメインカテゴリのみ対象。返信状況はスレッド単位です。"
  var output  = ContentService.createTextOutput(buff);
  return output;  
}

// 受信トレイのメインタブのみを対象に未読と既読のメッセージを取得する
function getInboxStatus(){
  var myMail =Session.getEffectiveUser().getEmail();
  var aryUnread = Array();
  var aryWorking = Array();

  var threads = GmailApp.search('category:primary', 0, 20); //メインタブ
  //var threads = GmailApp.search('is:inbox', 0, 20); //テスト用
  for (var i = 0; i < threads.length; i++) {
    messages = threads[i].getMessages();  
    lastMessage= messages[messages.length-1]; //最後のメッセージだけを見る
    if(lastMessage.getFrom().indexOf("<"+myMail+">")>=0){  
    }else{
      if(lastMessage.isUnread()){
        aryUnread.push(lastMessage.getDate());
      }else{
        aryWorking.push(lastMessage.getDate());
      }
    } 
  }
  return {unread:aryUnread,working:aryWorking};
}

//返信状況を返す
function getReplyStatus(){
  var myMail =Session.getEffectiveUser().getEmail();
  var aryReply = Array();

  //送信済みメールの返信時刻と返信先のメールの送信時刻を見る
  var threads = GmailApp.search('is:sent', 0,10);
  for (var i = 0; i < threads.length; i++) {
    messages = threads[i].getMessages();
    if(messages.length==1){ //メッセージが一件の時は処理の対象外
      continue;
    }
    for(var j=1;j<messages.length;j++){
      //自分からのメールの一つ前が自分以外のメールの時を返信扱いにする
      if(messages[j].getFrom().indexOf("<"+myMail+">")>=0 && messages[j-1].getFrom().indexOf("<"+myMail+">")<0){
        aryReply.push({sent:messages[j].getDate(),reply:messages[j-1].getDate()});
      }
    }
  }
  //Logger.log(aryReply);
  return aryReply;
}

// 日付のフォーマット mm/dd(aaa)で表記
function formatDate(date){
  var weekDays = ["日", "月", "火", "水", "木", "金", "土"];
  var strMonth = ("00"+(date.getMonth()+1)).slice(-2);
  var strDate = ("00"+date.getDate()).slice(-2);
  var strDay = weekDays[date.getDay()];
  return strMonth + "/" + strDate + "(" + strDay + ")";
}

//時刻のフォーマット(hh:mm）で表記
function formatTime(date){
  var strHour =  ("00"+date.getHours()).slice(-2);
  var strMinites = ("00"+date.getMinutes()).slice(-2);
  return strHour + ":" + strMinites ;
}

//テスト
function testRunner(){
  var d = new Date();
  Logger.log(formatDate(d));
  Logger.log(formatTime(d));
  var aryInbox = getInboxStatus();
  Logger.log(aryInbox);
  var aryReply = getReplyStatus();
  Logger.log(aryReply);
}

解説

• getInboxStatus()で受信箱のメインカテゴリの中を検索
• メインカテゴリだけにしているのは、メルマガや通知メールをのぞいた返信が必要そうなメールだけを対象にしたいから
• getReplyStatus()は、「送信済み」で検索したスレッドを対象に検索
• 本当はメッセージ単位で操作をしたいが、GmailのAPIがスレッド単位でしか検索できなかった
• スレッドからメッセージに分解するときに、たまに４～６秒かかる。これは制約として仕方がない
• スレッドの数かける数秒とすると処理時間がかかる。キャッシュした方がよいのかもしれないが、「メールを受信したらキャッシュ削除」というトリガが作れないので、キャッシュクリアのタイミングがいまいち。
• 自分からのメールか相手からのメールかの判断をするフラグがなかったので、Session.getEffectiveUser().getEmail();で、このアプリの実行ユーザのメールアドレスがFROMに含まれているかどうかで判断している。
• このWebアプリのURLにリクエストを出すのは不特定多数の人間だが、アプリは私の権限で動く。それがEffectiveUserってやつ。
• GASではプレーンなHTMLを出すプレームワークがなかったので、プレーンテキストで表示するだけにしている。HTMLだとJSでUI作るからちょっと遅いので単なるレポートはプレーンテキストで表示。かなり割り切った。

一番しっくり来る通知ってなんだろうということを考える

Webサービスでかなり大事なKPIが継続率。有料バナー使って人を集めてきても、再来訪してもらわなければすげーもったいない。コンテンツの更新通知なんかをメルマガで出したりしているけど、いろんな選択肢があるはず。それ考えてみよう。

Gmailの未読件数だけは全公開するというGoogleAppsScript

LINEなどのチャットツールとメールの違いは、未読既読がわからないということ。

メールの受信ボックスはあくまで相手先のものなので、送り主からは全くわからない。ただ、相手先がメール全体を読み終わっているのかどうかくらいはわかると便利かもしんない。

ということで、「受信トレイに滞在しているメールの件数と未読件数だけは全公開するスクリプト」を作ってみた。

ちなみに、私の受信トレイの現状はこう
https://script.google.com/macros/s/AKfycbxyed24cnf6igf00mx90Oc4iqHnQOjT4PKjHaB9jjy1gDFcfIBa/exec

ソースコード

function doGet(e) {
  var buff = ""; 
  buff += Session.getActiveUser().getEmail() + "\n";
  buff += "未処理件数：" + GmailApp.getInboxThreads().length + "\n";
  buff += "うち未読件数：" + GmailApp.getInboxUnreadCount() + "\n";
  var output  = ContentService.createTextOutput(buff);
  return output;
}

解説

• GmailAppクラスのgetInboxThreadsやgetInboxUnreadCount で件数を取得
• GoogleAppsScriptのHTMLサービスは画面側でHTMLをJavaScriptで生成するのがレスポンスの遅さにつながっているっぽいので、プレーンなテキストで表示（createTextOutput）
• 今のGmailは受信トレイの中がタブで別れているがこのソースではすべてひとまとまりとして扱ってる

以上です。

株式情報を得るにはヤフーファイナンスが一番しっくり来るという話

投資ツールっていろいろあるけど、ヤフーファイナンスは昔から情報が網羅されていて、ほぼそれだけで大概の情報は得られるよねーって話。

きっかけは好材料が出たとき

例えば、駐車違反の取り締まりが厳しくなりますよーって時には、じゃぁパーキングの業績が上がりそうだなーって考える。
鉄が値上がりするなら、じゃぁ鉱山機械作っている会社が儲かりそうだなーって考える。

「企業名　株価」で検索

Googleが一番上にチャートを出してくるけど、チャートを眺めるのはずっとあとなので、まずはヤフーファイナンスをみる。

まずは最低購入代金を見てポートフォリオを組めるかどうかを判断

ここで100万を超えると気軽には買えない。基本はポートフォリオ運用なので、４銘柄から５銘柄に分散させることが大前提。投資余力を100万と置くと、20万～30万の単位で買うのがちょうど。

なによりもPERをみる

PERってのは純利益と株価の比率。利益は株主のものだから、「理論上何年で元が取れるか」って指標。ここで100倍とかだとバブル状態。100年かかって元が取れるってのはやってらんない。金融商品ってのは人間様のためなので、寿命からみて十分短い時間で改修できるのが最低条件。ただ収益改善が急激に見込めそうな場合には、今年が100倍でも来年は20倍かも知れない。利益がほとんどない場合には、あてにならない。安定している状態のPERは20倍くらいが妥当。20年かかって元が取れるってこと。

PBRは念のためにみる

１を割ると割安だけど、拡大フェーズではあまり参考にしない。
安定フェーズで１を割っていてなおかつキャッシュリッチの場合にはどっかできつめの株主提案が出て自社株会をするとかそういう株主還元があるかもしんないけど、小口株主にはコントロールできないので、買収されるかもって時には参考にする。

企業情報＞決算推移を見る

３年単位での決算推移を見る。基本は黒字であること、さらに成長していること。
V字回復っていいながら、当期利益だけが回復している時には、意図的に前期に特損を
出しただけの可能性もある。売上と営業利益で成長性を見るのが大事。

真面目な財務分析だとキャッシュフローを見た方がいいのだろうけど、ヤフーファイナンスにはあんまり情報がない。

長期的には、大事な情報なんだけど、やたら現金を貯め込むタイプとか、在庫が多いとかってのは、会社の体質に近い。PBRがめちゃくちゃ低い時みたいに、会社の体質ごと変わると化けるけど、個人投資家レベルではそこをコントロールできる立場ではない。

最後にチャートを見る

チャートは最後の最後に見る。あまりに荒れている時にはギャンブル性が高いことを踏まえた増えで買う。業績がよくなるのと連動して株価も良くなっていることが理想。

【メモ】「独学力」があると環境に依らず成長出来る

エンジニアの能力を見るときには、「独学力」でその後の成長まで見据えたスキルを測る。

独学力を分解してみよう。

１．ググリ力
Googleでの検索能力は大きく調査能力を左右する。

• すぐ検索する
• 検索ワードは正しい？
• 信頼できるサイトかどうかを見ている？
• 日本語での情報が無いと思ったら英語で検索をしている？

２．ローカル開発環境を持ってる？

単にググってコピペするだけじゃなくて、「このオプションって使うとどうなる？」「実際にどれくらい処理時間かかるんだっけ？」を「すぐに試せる」環境は必要。テストサーバもあった方がいいが、何よりもローカルの環境でなんぼでも失敗してもいい環境を持っているかどうかが大事。

３．小さく試している？

関数ごとに小さく試してお勉強しているかどうか。いきなり大きなプロジェクトの中で試してはいないか？「動いた実績のある」小さなサンプルソースの集合が、あとで大きく役に立つ。プログラムを作る以前に、「思い通りにコンピュータを動かす」という小さな積み重ねが大事。

４．作りたいものが作れてる？

これは学習に目的意識があるかどうか。チュートリアルをコピペするだけじゃダメ。目的があってこそのプログラム。邪な動機でもなんでもいい。目的からブレークダウンして勉強ができないとその後厳しい。

電子カルテのUI/UXを考える

電子カルテって国策としては「余計な診療をあぶりだすことで無駄な医療費を下げたい」という意図もあってなかなか進まないんだど、各医療機関ではだいぶ進んでいる。

もちろん各SIerもソリューションを提供しているのでこの市場はプレーヤーも多い。改めて再発明してみよう。

フォルダ名／ファイル名をつけるというストレスから自分を解放する

エバーノートみたいなものはいっぱいあるが、エディタがいまいちだったり、ファイル単位でどっかにもっていけなかったりとか、やり過ぎ感がある。プレーンなエディタでありながら、ファイルの保存だけを、「固定の場所に」「しかもクラウドで」ということができればそれでいいじゃないっすか。

ということで、いつも使ってる、gPadというフリーウェアのテキストエディタを使って保存マクロを作った。これがあればエバーノートは要らない。

新バージョンのGoogleSpreadSheetについて

エクセルの代わりになりそうでならないGoogleSpreadSheet。
地味にバージョンアップしたのでご紹介。コンシューマー版にちょっと遅れて、GoogleAppsもバージョンアップするはず。

パスワード入力を廃したWebサービスが生き残るという皮肉

一ユーザとしてはパスワードの入力ダイアログは面倒。しかしセキュリティのことを考えると、ID/PASSの入力は必須とされる。

本当にそうか？ちゃんと考えてみよう。

専門学校はちゃんと卒業生に順位をつけて欲しい

大学というものには大した価値はないのだが、少なくとも高校から大学に入るときに受験勉強をがんばったんだなーってことは分かる。でもそれだけのために大学入るのってかなりムダ。職能を身につけたいのなら専門学校がいいのだけれど、医療系以外の専門学校になると、ほとんど入れてみんな卒業できちゃう。専門学校によっては明らかに授業数がすくなく、そういうモラトリアムでしかない。

これなんとかしたいよね。考えてみよう。

オフィスの「壁」というメディアを上手く使おう

交通広告という広告媒体がある。電車の釣り広告とか駅の壁とか。人がたくさん通るからそりゃメディアとしては使える。オフィスも従業員がたくさんあつまる。なんでもメールで広報の時代だけど、総務や社内広報のメディアとしては壁は使えるメディアなのだ。

WebのUIはプロダクトそのものだという認識を持った方がいい

昔はWebのシステムって仮にコンシューマー向けであっても、情報システム部門が管轄。スタッフ組織。社内システムを面倒見る感じの延長。内線電話とか経理システムとかと同じ並び。確かに、ネットワークだしSIerさんに発注しなくちゃ行けないしで、「必要スキル」は似てそう。でも内部スタッフとコンシューマーとでは使う人が全然違う。だからダメ。

伊勢丹は「流通業」だけど倉庫じゃない。確かに何らかの商品を売っては居るが、伊勢丹のプロダクトは伊勢丹そのものだ。WebのUIも何かを売るためのツールではあるが、ユーザの購買体験の大半はUIから得ている。伊勢丹が伊勢丹という店舗にかける思いと同じくらい、コンシューマー向けのUIには、営業部門直下で管理した方がいい。

ドキュメントを全てメールにしてみるとどうなる？

メールとドキュメントの棲み分けって難しい。メールというコミュニケーションツールよりも前に、「ワープロ」なるものがあって、コンピュータはドキュメント生成マシンではあった。メールが登場してメール本体がドキュメントの役割を担うようになった。もう全部メールでいいんじゃない？って話。

社内の承認フローをメールだけでやりきる方法

ペーパーレス談義をまだまだ続ける。社内の承認フロー（稟議とか決済とか言ったりするけどここでは承認と呼ぶ）をメールでやりとりする方法を検討する。

ワークフローのシステムってパッケージっぽいものがあるのだけれど、大した機能がないくせに制限が多い。じゃ、制限をとっぱらっちゃって、メールだけで社内承認ワークフローが作れないか。

会社対会社での書面でのやりとりがメールでよくなってきたという相場感

社内のワークフローはグループウェアのようなものでペーパーレスが進んだとしても、会社をまたがる場合には、どうしても紙ベース＆捺印＆郵送（もしくはFAX）という流れが多い。でも徐々に改善しつつある。メールでのやりとりが徐々に進んできているのだ。こういうのはあくまで「商慣習」なので法律じゃない。契約書の外の世界なので、互いに合意することが大事なのは、これまでもこれからも変わらない。

仕事の現場でOfficeが本当に必要かをちゃんと考えてみようよ

大概の会社では、MS-Office（以下Office）で作ったドキュメントがめちゃくちゃ飛び交う。「Officeで作ったドキュメントを売る」という事業ならそこがんばる必要あるが、ほとんどの会社はそうではない。

なまじっかOfficeが使えるPCとユーザが多いだけに、Officeを「そこまで排除する」インセンティブもわきにくい。しかしスマホとタブレットである程度仕事ができはじめると、MS-Officeが急に面倒になる。Officeモドキをインストールするという手もあるが、そこは「Offiiceそのものを使わずに仕事はできないのか？」を考えてみよう。

いいかげん「タブレット活用」って言葉やめない？

仕事でのタブレット「活用」って言葉がすげーやだ。道具であるはずのタブレットが目的化しちゃってる。情報端末なんだから、誰かと誰かのコミュニケーションが分断されているところの課題解決であってしかるべき。言葉が先行してすげーふわふわしてる。

新人ディレクターのためのWebサイトにまつわるレギュレーション

山ほどWebサイトを作ってきて、目つむったままでも作れるようになったので、守るべきレギュレーションを文書にしてみた。

大概の新人は、我が子として生み出したサービスが、「レビュー」のタイミングで悪者扱いになるので、最初は深く傷つくのだが、我が子を守るためのレビューなので、これはやっぱり「守るべき」。

デプロイにはFabricが超便利

デプロイって大げさな名前だなぁって思うわけですよ。業務報告受けていても、「今日一日はデプロイでした」って、そんなバカなと。アプリケーションって、基本的にはファイルのコピーなわけで、ファイルのコピーがそんなにたくさんの「工程」を経ているのなら、それたぶんまちがってる。

そんな分けで、Webアプリのリリースに関してまとめますね。

自分でやった方が早い症候群の治療法

新米リーダーが陥りがちな「自分でやった方が早い」症候群。本人には悪気はないからたちが悪い。そもそも、自分でやった方が早い症候群の何が悪いのかから説明し、その治療方法を解説する。

世のサービスで「自分でやった方が早い」で作られたものなどない

ファストフード、パソコン、自動車、世のサービスはほとんどがチームプレイ。つまり「仕事の相場感」から間違ってる。

リーダーには他にやるべきことがある

リーダーとしての仕事をした上で片手間に、実作業をしているのならいいが、リーダーとしてやるべきことが疎かになっているということが本人が気付いていない。俺の方がドリブルが上手いといって、ゴール前までドリブルをするゴールキーパーはいない。

比較優位という考え方

経済学には比較優位という考え方がある。マイケルジョーダンは運動神経抜群だから、庭の芝刈りもめちゃくちゃ早くて上手い。時給1000円の普通の芝刈り業者に頼むよりも、「より早く・より低コストで」芝刈りができる。したがって、マイケルジョーダンが芝刈りをした方が経済的に正しい。以上の考え方は間違いであるというのが、比較優位の考え方。マイケルジョーダンが他の仕事をしたときの、生産性は時給1000円以上の効果がある。下手でも芝刈りは別の人に任せた方がいいのだ。

実は頼み下手の言い訳

「自分でやった方が早い」は単なる言い訳に過ぎないケースが多い。実体は単に頼めないというだけ。「あなたがこの仕事をやるのがベストだ」という判断に自信がないから。ドリブルが得意なのではなく、パスに自身がないだけなのだ。

適切にタスクを割り振るための心がけ

1. 全ては経済合理性
• 比較優位の考え方に従えば適切な分業が経済的に正しい。そんなことは産業革命のレベルの話。誰がやるべきか以前に、分業することが何よりも正しい。「俺がやるよりもお前がやった方がチームとしてよい」と言い切る。
2. やり方を教えれなくてもいい
• 自分でやるときだって、学習と習熟を経てできるようになっている。他人にやらせる時だって、学習と習熟の両方を要求していい。「不慣れです」には、じゃぁいっぱいお願いするので慣れてください。でOK。逆に習熟するだけのボリュームの仕事の塊を作ることがリーダーの役割
3. 相場感だけは持つ
• 仕事をお願いした人が、いまいちな場合にはちゃんとやり直してもらう必要がある。自分にできないことでも、そこはお願いする側が品質の判断は行う
• 仕事が遅すぎるかどうかの相場感も必要。異常として検知して、スキルが足りないか、与えた情報が足りないかを調べてすぐに対処する。

Google Form を使ったワークフロー

◆GoogleFormがいいところ
・EUCでありながらマルチユーザ。
・究極のSSOワークフロー
・コンシューマー版GoogleDriveで無料でも作れる
・GoogleSpreadSheetと連携ができるので、WebDB＋Excelの業務領域を両方カバーできる。
・入力制約や、分岐がプログラマーでなくても構築できる

◆GoogleFormの辛いところ
・フォームそのもののUIはカスタマイズできない
・フォームでの再編集はできるが制約が多い
　（検索→一覧→詳細という業務フローが作れない）
・フォームからの新規投稿でしかスクリプトが起動できない（ボタンクリックでということができない）
・レコードにキーの概念がない
・GoogleSpreadSheetのレイアウト機能がExcelに比べると低機能

◆作りたいもの
・紙と印鑑を使った決済はそのまま残して、データの再入力だけを省く
・非エンジニアが運用できるという点はそのまま残したい

◆以上を踏まえて以下のシナリオを実現する
・ユーザはGoogleAppsログイン状態でGoogleFormから申請
　（この段階で「フォームの回答」シートにはデータが蓄積される）
・サブミットイベントをトリガーに、以下のスクリプトが起動
　・申請書フォーマットのスプレッドシートに、カラムのバリューをセット
　・値が入ったシートをPDFに変換
　・PDFを本人のメールアドレスに添付して返信
・ユーザはメールを受信してPDFを印刷
・ユーザは上司の決裁を印鑑でもらう
・ユーザは承認済み決裁書類を経理に提出する
・経理は、紙で提出された決裁書類を受領し、データ作成日と申請者をキーに
　「フォームの回答」シートを参照し、決済済みカラムにフラグを立てる

◆上記からしばらくして、経理の運用
・請求書が来たら、それが決済済みかどうかを、「フォームの回答」を検索
・領収書の精算が提出されたら、それが決済済みかどうかを「フォームの回答」を検索

「フォームの回答」シートは、経理だけではなく決済権限をもったユーザにも参照権限を与えておくと、部門のコスト見通しが見えてよい。