ハイテク津波……失業者63%の一人にならないために

今後10～20年で47%が職を失う可能性が高く、19%が職に中程度のリスク

http://www.inc.com/ed-hess/is-your-business-ready-for-smart-robots-and-artificial-intelligence.html

AIやビッグデータ、3Dプリンティングなどの活用により、現在のビジネスがある日突然立ち行かなくなる時代に突入しようとしています。

顔の見える仕事と、マニュアル化できない仕事は生き残ります。

それ以外は全滅であろうといっても過言でない予想です。

重要なのは、自分が生き残ったとしても、自分の顧客がつぶれれば、やはり売り上げ減で自分もつぶれるという認識です。

この際、人間はもう働かなくてもいいんじゃね？　という議論もあります。

が、私は古い人間なので、働いているのが好きです。

であるならば、我々は備えなければなりません。

だからなんで電子書籍を画面で読もうとするわけ？

画面での読書は時系列があやふやになるという実験結果

私は古い人間なんで、電子書籍のオンデマンドプリント&装丁&製本サービスがコンビニにあればいいとおもっているんですが。

頒布の利便性において、紙の書籍は電子書籍にかなうべくもありません。

紙の書籍は運送のエネルギーを大量消費しますので、環境にも優しくありません。

また、紙の書籍はあらかじめ印刷するため、返本というむだが生じ、環境に優しくありません。

しかし、頒布を電子的に行うということは、閲覧も電子的に行わねばならないということを意味しません。

プリントしてしっかり製本して読むほうが、ブラウジング（ペラペラめくって目的の箇所をすばやく見つけ出す）も楽だし、拡大表示も楽だし（目的の箇所に目を近づけるだけ）、目にも優しいとおもうし、水濡れや乱暴な扱いにも耐えます。

もちろんせっかくなんで多少のバリアブルプリント要素ありで。

名入れとかだけでなく、登場人物の名前を変えることができるとかすれば、 妄想やプレゼントに最適です。

Redmineでステータス名上限が30字って少なくなーい？

なんか、Redmineへの細かい不満ばっかり書いてしまっていますが…。

これもまた、タイトルそのまんまです。

How to change max ticket status length of 30?
私とおなじ悩みを公式フォーラムに2年以上前に書いたひとがいますが、放置民です。

Redmineのソースを直接いじくったり、Redmineが使ってるデータベースフィールドの設定をいじくったりすれば、変更できるんでしょうけども…。

日本語だったら全然余裕なんですけどね…。
英語にしたとたん、「OP」とか略称使いまくっても、なお字数多すぎになってしまいます。

「Waiting for」を「W8ing 4」と若者風味にしてみましたが、やはり30字には収まりませぬ。
「notification」が長すぎですね。

結局「Waiting for OP, QC & UPN」としました。
もうこれ見ただけじゃ何のことやら… (^^;;;)

妹に朝日新聞勧誘員が「夜働いて新聞代を稼げ」とおっしゃったのは広義の強制にあたらないのか

朝日新聞が、従軍慰安婦の日本政府による強制性に関する度重なる報道を、虚偽と知りながら数十年にわたり訂正してこなかった件について、いまだ謝罪すらないことに国民から「知る権利はどうした」「天下の公器はどうした」と怒りの声があがっています。

が、そもそも朝日新聞は私の妹に対して、広義の強制を行った前科があると私は思っておりますので、虚偽であれ、たとえ真実であれ、朝日新聞がそもそも女性の権利を云々することはチャンチャラおかしいです。

妹には今はイケメンの旦那さんがいますが、かつて独身で親元を離れ独り暮らしをしていた頃、朝日新聞の勧誘員が家にやってきたそうです。

「アカが書き　ヤクザが売って　バカが読む」

と申します。
そのような勧誘員が、若い女性の独り暮らしの家に勝手に来るだけでも、じゅうぶんに広義の強制性が成立する事案であると考えますが、
「お金がないので無理です…」
と答えた妹に対し、こともあろうにこのヤクザ勧誘員は

「夜働いて新聞代を稼げ」

とぬかしたそうです。

夜働くかどうかは、個々人の自由であり、朝日新聞様に強制されるいわれはございません、とおもいますがいかがでしょうか？
これは、広義の強制性にはあたらないのでしょうか？

Redmineでトラッカーごとにデフォルトのステータスを指定できない

もう、タイトルに尽きるですが…。Redmineで、トラッカーごとにデフォルトのステータスを指定できないのです。

新規チケット作成の際に、ワークフローにデフォルトのステータスからの遷移を入れてないトラッカーを選択すると、ステータスのドロップダウンリストの選択肢が、デフォルトステータスのみになってしまいます。

かべのなかにいる！ 状態です。

トラッカーのワークフローで遷移を定義してるいちばん上の行のステータスが初期ステータスになってくれたり、遷移を定義してる行のステータス群が選択肢になってくれたりしないものでしょうか…。

デフォルトステータスなどを指定しているからいけないのかとおもい、すべてのステータスにおいて、「デフォルト値」のチェックを外してみました：

すると、単に、そういうことはしてはいけませんよ、というエラーが出ましたorz：

このような、ものすごく多くのひとがぶつかるであろうものすごくFAQっぽい疑問点は、私が提起するまでもなく、公式フォーラムにも3つほど「できないんですけど…」というスレがありますね。

どうも、現状では、「新規」というユニバーサルなデフォルトステータスを作るしかないようです。ダサイけど…。

当社の給与構成要素の先月度円グラフ―パラメータのチューンナップは何より雄弁な社員へのメッセージ

DTP部門のさらなる強化にあたり、今日は、月々の個々人の給与額決定にかかるさまざまな細かいパラメータを、いろいろ振って試算してみていました。

とりあえず先月はこんな感じです：

社員全員の合計ですので、個々人では当然比率が異なります。
また、月によっても、実績給などの額は当然異なります。

重要なのは、当社には、一人として同じ給与額をもらっている社員はいないし、また、一人として毎月同じ額の給与をもらう社員もいないということです。

そして、給与を構成するそれぞれの要素の重みづけをどのようにするか、そのパラメータは、賃金規定に明示されて廊下に貼り出されているわけですが、これをどうチューンナップするかで、当然、社員のインセンティブ、モチベーション、行動はまったく異なってきます。

会社の理念やめざす方向にてらして、社員の行動が、期待した通りの行動にならない場合は、パラメータが間違っているわけですので、これまでにも何度も、その微調整を繰り返してきました。

現在では、上の円グラフのようになっています。

この大きな割合は、もう、そう変えるつもりもなく、今日検討していたのは、実績給をゲットするためにはさらに細分化されたいくつかの手段があり、個々人の得意分野がそれぞれ異なっても、いずれであっても汗をかいた者にはきっちり実績給で報いねばならないという考え方から、DTP部門のさらなる強化にあたり、その新状況に合致したルールを検討するということでした。

えてして会社を始めるときには、いろいろ自分が経てきた職場の給与体系や、あるいは人事や経営に関する本などを読んで、固定給主体とするべきか、実績給主体とするべきか、技能手当主体とするべきか、勤続手当を重視するべきか、迷いがあることとおもいます。

しかし私の考えは、上の円グラフにも如実に現れているように、いずれも重要であるということ、ただしそれらの重み付けは、カンボジアの若者たちにＩＴ分野での仕事をしてもらう場合には、上記のような配分が良いのではないかということです。

百篇訓示を垂れるより、このパラメータを示すことが、社員のどういったコンピテンシや行動に報いるのかという点において、何より雄弁な社員たちへのメッセージであることは間違いがありません。

そして社長は社員にあらゆることを聞くことができ、また社員も多くのテーマに対しては、聞き方と聞く姿勢さえ正しければ、真摯に答えてくれますが、ことこのパラメータを決めるにあたってだけは、社長は社員に聞くことはできません。ただ社員の行動を見ることしかできないのです。

なぜなら社長とは、誰もがたくさんほしい給料と、その額にともなうあらゆる個人的達成感と社会的名声の配分を、一方的に決めるという悪者の役であるからです。

その悪役をともに務めてもらおうとして社員を友達にすることはできません。

そして、きちんと見れば、パラメータが正しいか間違っているかは、如実にわかるものです。

「社長、あなたは、間違っていますよ。あなたが言ってる理念とあなたが示したパラメータが矛盾していますよ。あなたがめざすと言ってる方向性とあなたが示したパラメータが矛盾していますよ」

社員はこれを口では言ってくれませんが、行動によってこの上なく明々白々に示してくれます。すなわち、会社の理念やめざす方向にてらして、

「あの社長ならこのパラメータは整合するね。あの社長らしいね。この会社に入った以上、あの社長なら当然こうなるよね」

と社員が納得して行動してくれたときが、パラメータが正しいとわかるときなのです。

電話番号リンク2種類のスキーム：貴女は「tel:」派？ 「callto:」派？

Redmine上でユーザーの電話番号カスタムフィールドからリンクを張りたいと思い、カスタムフィールド定義の「値に設定するリンクURL」フィールドでtel:%value%と記述しましたが、なんとなく恐れていたとおり、パソコンでこれをクリックしてもSkypeが起動しませんでした。

この問題について書かれたページです：
Geek alert … tel: or callto:?

電話番号リンクのスキームは、公式には「tel:」と定められていますが、一方でSkype（ひいてはMicrosoft）は、独自に「callto:」を用いているのはご存知のとおりです。

スマホではtel:が効くことが多いようですが、パソコンではtel:は効かないようです。

より個別のスキーム対応について書かれたページです：
How to mark-up phone numbers?

PHPコードにより環境を判別していずれかのスキーム識別子を出力する例です。PHPerならこれでいい：
Adding Phone Numbers To Web Pages With HTML5 and Microdata

個人的には、時代はスマホだろってことでtel:で押し通すことにします。