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を印刷
・ユーザは上司の決裁を印鑑でもらう
・ユーザは承認済み決裁書類を経理に提出する
・経理は、紙で提出された決裁書類を受領し、データ作成日と申請者をキーに
　「フォームの回答」シートを参照し、決済済みカラムにフラグを立てる

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

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

HTML5ハイブリッドアプリ開発実践入門

買ってみた。
WebViewアプリの作り方の本。

その中で、スマホHTMLならではの極めて実践的なコツが書かれている。