PCでスマフォをUSB充電したら仕事をクビになった


まず俺の話ではなく全く関係ない人間の話なんだけど、注意喚起としてメールが回ってきた。
その話聞いてちょっと違うんじゃない?と思ったのでちょっと書いてみる。

そのクビになった技術者がいる現場では、どうやらPCにスマフォをつなげてはいけないというルールになっていたそうで、それを破ってPCのUSB端子でスマフォを充電しちゃってた。それがみつかってクビになったらしい。ルールを破ったのだからクビになっても仕方がない。それは正論。でもね、ちょっとまって。二つの観点からちょっと違うんじゃない?と思ったことがあるので順に書いてみるよ。

まず「セキュリティルール」という観点から。

セキュリティルールってのは「守る」ためにある。つまり、まっとうに働く人(社員やパートナー含め)を守り、企業の情報(=企業の資産)を守りるためにあるわけで、人間を罰するためのものじゃない。言い換えると、セキュリティルールってのは「ルールを守らせる」のが目的ではなく、被害を防ぐことが目的なわけだ。今回の件では、ルール違反は見つかったが、本来の目的は侵されていない。つまり、「被害は無かった」わけ。でも被害が発生する可能性のあるセキュリティルール上の違反が見つかった。しかも、過失はあるが、故意でルール違反を犯したわけでもない(「普段の癖でやっちゃった」らしい、それもちょっとアホすぎるけど)。それをいきなり当事者をクビにして「ハイ終わり」ってのはセキュリティ運用上どうなのかなと思った。

セキュリティルールってのは状況に応じてどんどん変更されるべきものだ。守るべき対象がどんどん変わっていくのでルールも変わっていく。さらにルール上の問題が見つかったらそれに合わせてルールを変えるか運用を変えていく。今回の件で言えば、ルール違反が発生して、それが重大な問題であると認識したのであれば、ルールを変更するか、運用を変えるべきじゃないのか?(=技術的な対策を打つ、なども含め)

ルール違反者を見つけ出し、それを切り捨てて、それでセキュリティが守られると思っているようならそれは大きな間違いだ。現状でルール違反者が発生する可能性があって、それが重大な損害の発生につながる可能性がある判断したのであれば(重大な問題が発生すると判断したからクビにしたんだよね)、次のルール違反者が出現する可能性も十分にあり、それが損害に発展する可能性も十分にある。それってまったくセキュリティリスクをケアできていないよね。

もうひとつは「雇用者(=管理者)」という観点。

損害が発生していない過失を見つけたからといってその過失者をクビにするのは雇用者としてどおなのかなとも思う。企業活動上でヒューマンエラーなんていたるところで起こっている。例えば、メンドくさくて手順通りにやらなかった、でも問題はなかった。これと今回の「PCでスマフォ充電しちゃった」問題と何が違うの?前者はお説教ですんで、後者はクビなわけ?

企業活動上、ヒューマンエラーが発見された場合には原因を明らかにして今後ヒューマンエラーが起こらないようになにかしらの「対策を打つ」というのが常識だ。そこには、ヒューマンエラーを起こした人間を罰する、というのは含まれない(別途で損害賠償という責任追及手段をとる場合はあるけど)。一般的な常識と今回の問題を照らし合わせれば、うっかり「PCのUSB端子でスマフォを充電」しちゃわないように対策を講じるか、うっかり「PCのUSB端子でスマフォを充電」しても問題ないようにするのが順当な考え方だ。逆に「PCのUSB端子でスマフォを充電」しちゃった人間をクビにするのはちょっと常識から外れている。

ってな感じで、「PCのUSB端子でスマフォを充電したらクビになっちった、テヘペロ」的なメールにとっても違和感だらけだったので書きなぐってみました。お粗末。

「バグのないプログラムを書け」はできるんじゃない?


プログラムのわからないえらい人「バグのないプログラムを書くことはできないのか?難しいかもしれないが、十分に気を付けていれば防げるのではないか?」にどう返したらいいのかわからない

http://anond.hatelabo.jp/20170214114736

バグは人のミスなんだから、理屈的には正しいような気がする

だけど未だかつて人類はこれを達成できていないという観測的事実がある、何故そうなるのかを説明することは可能だろうか

ふと思ったんだけど、この増田さんが言われた「バグのないプログラムを書け」はできるんじゃない?

ゼロにはできないけど、限りなくバグの少ないシステムは作れると思うよ。理論的にはね。

でもね、問題がある。

「バグが限りなく少ないプログラムを書く」ためには膨大なコストと時間がかかる。

システム構築ってのは必ず予算と工期が決まっている。

だから100万円でシステムをつくるのに、1000万円かけて「バグが限りなく少ないプログラム」は作れないし、1ヵ月の工期に1年もかけていられない。

100万円のシステムを1ヵ月で作るのに1000万円かけて1年もの時間を費やしていいのなら「バグが限りなく少ないプログラム」は作れるんじゃないかな。

その「プログラムのわからないエロい人」に言ってみたらいいよ。「予算と工期を最低でも10倍用意したらできるかもよ」と。加えて「それでもやるか?」と。

それでもゼロにはならないから、世の中のシステム障害ってのものが後を絶たないのだけどね。

【寄稿】システム開発の見積が高い4つの理由(ワケ)


Giochiamo!!ジョキアーモ!!からの寄稿記事です。

≪元サイトで読む≫

【ワケ1】儲ける必要のある「会社組織」が見積もっているから

システム開発という話から逸れますが、そもそも会社組織というものは絶対に儲ける必要があります。トントンじゃ絶対にダメなんです。なぜなら、そもそもマイナスからスタートしているからです。

会社組織というものは存在しているだけで経費がかかります。事務所賃貸費用、間接人件費、税金などなど。これは、仕事をしていなくとも必要であり、組織が生きていく上で絶対に必要となる生命維持(「法人は人格を有する」とはよく言ったものです)の費用です。したがって仕事を受ける以上、それなりに儲けを乗せないといけません。逆を言えば、会社組織というものは儲けが少ない仕事は受けてはいけないのです(儲けが少ない仕事ばかりしていると生命維持に支障がでてきます)。

したがって、当然ながら見積額にはその会社がその仕事で活動するうえで最低限以上の利益(経費といってもいい)が乗ります。つまり、会社組織が大きければ大きいほどこの利益が大きくなってきます。大きなシステム会社に見積もりを要求するとビックリするような金額が出てくるのはこのためです。

以前、勤めていた会社では「最低でも経費は6掛け」で計算していました。つまり原価100万円(原価=直接経費)の仕事は167万円以上の金額で提示していました。これがある程度の会社組織ならば当たり前のようにされています。一般の方々から見たら6掛けされた見積額と原価額を聞くと「ボッタくってるなぁ」と感じるかもしれませんが、これでも儲かっているわけではないんです。いろいろな経費を引くと、これでもトントンなんです。これには僕もビックリしました。このように会社組織の生命維持に必要な経費というものはとても大きいものなんです。

【ワケ2】システム会社が得意な技術が決まっているから

システム会社には得意な技術が必ずあります。建設会社を例にわかりやすく例えると、マンションなどのコンクリート構造物が得意とか、橋梁などの鋼構造物が得意とか、身近でいえば木造の家を作るのが得意だとか、そういう得意分野みたいなものがあるのです。具体的には、Windows系.NETが得意とか、業務システムをJavaで構築するのが得意とか、PHPでWEBサービスを作るのが得意とか、SAPやSalesforceなどの特定アプリケーションの導入やカスタマイズが得意とか。そのシステム会社によほど経営的な判断(新しい分野にチャレンジしよう、など)があった場合以外は、通常、その会社得意な技術やアプリケーションを使ってシステムを構築することを前提として提案や見積額が提示されます。

一方で、システム開発というのは不思議なもので、技術ごとに人件費単価が異なっているのです。つまり、.NETで工数1人月で作る場合と、Javaで工数1人月で作る場合と、PHPで工数1人月で作る場合でかかってくる人件費は異なっているのです。さらに不思議なことに、この人件費単価はかなり差があり、へたをすると費用が1~3倍になることがあります。

そこで、とある会社に「あれがしたい、これがしたい」と要望を持ち込むと、その会社が得意な技術と作り方でソロバンをはじきます。そうすると必然的に価格が異なってくるのです。つまり他社と1~3倍ほど差がある見積額が出てくるわけなんです。

具体例を出すと、Javaでシステムを構築する技術者の一般的な人月単価(技術者1人に1か月間作業をさせるのに必要な価格)は平均で60万円と言われています。一方でPHP技術者は平均月額単価は30万円です。しかもPHPはそもそも簡単学習、短工期を最大のメリットとしている言語ですので、Javaよりも高速で(短い工期で)構築することができます。おのずと見積額にも明確な差がでてくるわけです。(※ただし双方にメリット・デメリットがあるので一概に価格では決められないことはお断りしておきます)

【ワケ3】正しく要件を定義していないから

システムを作る上で最も重要な作業の一つに「要件定義」といわれる作業があります。この作業を簡単に説明すると「お客様の要件や要望を聞いて、お客様が何をしてほしいのか決める」作業となります。これは「お客様の御用聞き」をする作業ではありません。「お客様に本当に必要なこと」を正しくかつ詳細に探り当てる作業なのです。さらにいうと「お客様にはいらないこと」をちゃんと明確にする作業でもあるのです。そして要件定義をするうえで一番重要なことは、要件定義の段階では決して「お客様に必要なモノ(機能や形姿)」を具体的に定義してはいけないのです。

基本的にお客様はご自身のことをよくわかっておられません。ご自身にとって「本当に必要なモノ」を見えていないことが非常に多いのです。お客様は、ただ、漠然と「ほしい」と思ったから来ただけなのです。したがって作り手である我々が「そもそもなぜ、ソレがほしいと思ったのか?」「ソレを持つことによって何を成したいのか?」を紐解きながら「ただ、ほしい」という気持ちを解きほぐし、「お客様に本当に必要なこと」「お客様には要らないこと」を明確にして、お客様と共有していきます。これが要件定義という作業です。具体的なモノの話は、要件定義が明確になった後に具体的に設計されます(これを基本設計といいます)。

シンプルに考えてみてください。本当に成すべきことがわかっていないのに、本当に役に立つシステムができると思いますか?本当に成すべきことが分かっていないのに、システムを正しく使うことができると思いますか?本当に成すべきことがわかっていれば、不必要を極限までそぎ落とし、必要最低限の機能で最大の効果を上げるシステムを作ることが可能となります。つまり、要件定義が正しくできていれば「必要なシステムを安く作る」ことも十分に可能なのです。逆を言えば、要件定義が不完全もしくは間違って行われていた場合「必要以上かつ不必要で余計なものを作ってしまう(=高価になる)」危険があるわけです。

私のところに他社で出された見積を片手に「このシステム作るのにこんなに費用かかるの?」と相談に来られる方が多くいます。すこし時間を頂戴して、その方の要件をゆっくり紐解いていくと、実際にはその金額の半額以下で十分に構築可能なことがたくさんあります。つまり、お客様の要件を慎重に抽出してから、違ったやり方、異なる技術、その方の妥協点などをよくよく探っていくと1/5の価格で出来てしまうことも当たり前のようにあるのです(ただし、価格を下げるということは何かしらの代償が伴います。それを必ず説明してご納得いただかない限り、その仕事はお受けできないことがあることはお断りしておきます)。

この要件定義を正確に行うことが、正確な見積もりを出す根拠となります。強いて言えば、本来であれば要件定義ができていなければ見積はだせないのです。すでにお気づきと思いますが、要件定義は発注前に行われなければなりません。つまり、専門の技術者が要件定義をするのではなく、営業担当者が要件定義を行うことが多いのです(一般的な会社組織では技術者を動かすのは発注がなされた後になります)。要件定義を行うにはそれ相応の知識と経験が必要となります。一般的な技術者であっても要件定義を正確に行うことは難しいのです。要件定義を行う営業担当者にその知識と経験があるか・・・それが大きな問題となります(ここを重視して優秀な営業担当者を配置する会社組織ももちろんあります)。したがって、「だされた見積もりが高い」と相談に来られた場合、私はその方が話を持ち掛けたシステム会社の要件定義があまり正確に成されていないのではないか?と常に疑い、まず要件を慎重に分析することから始めるのです。その結果が前述の事例に結びつきます。

【ワケ4】その仕事を「やりたくない」から

最後は、単純な理由なのですが、あなたの持ち込んだ要望について、そのシステム会社が「できるけど、やりたくない」場合があります。【ワケ1】でもすこし触れましたが、会社組織には「やってよい仕事(=やるべき仕事)」と「やってはいけない仕事」があります。やりたくない理由はとても簡単で単純に利益に結びつかないのです。これは会社ごとにかなり明確に決まっています(これが明確でない会社は前述のとおり存続が危ういです)。しかし、お客様に対して「それは儲からないのでやりません」とはさすがに言えません。言えば失礼どころか信用を失いかねません。したがって、かなり利益を乗せた金額(=本来ならやらないが、このくらいくれるなら受けてもいい金額)を提示して「申し訳ありません、うちではこのくらい頂かないとできません」と頭を下げるのです(これなら営業職も頭を下げやすいのです)。

以上が、システム会社の見積が高い4つの理由(ワケ)です。
いかがでしたでしょうか?
あなたの手元にある「システム会社が作成した見積書」が高い理由をお分かりいただけましたでしょうか?

PHPerはワープアまっしぐら。PHPerの単価が月60万~とかありえない。


そもそもPHPerの単価が月60万~とかありえない。

「フリーランスエンジニアが知るべき、PHP案件のトレンド、特徴、単価相場とは」
https://freelance.potepan.com/blogs/1685.html
より引用

~前略~

フリーのエンジニアが受け取る報酬の相場は一般的にプログラマで「40~60万」、システムエンジニアで「60~80万」と言われています。もちろんスキルや時間によりますが、一般的にはPHPですと相場は月60〜高い方で90万ほどです。

~後略~

この記事についてモノ申したい。

PHPが短期開発に向いているのは正しいが、それはPHPが規模の小さいシステム開発に向いているという理由がある。1人ないし2人という小規模でチャチャっと作ってしまうようなシステム開発でPHPは非常に大きな力を発揮する。そういう小規模なシステムだけに予算自体も少ない。大きなシステムほど成功すれば大きな利益が得られるが、システム規模が小さくなれば利益も少なくなり、自ずとシステム開発予算も小さくなる。

PHP案件は予算200万以下という案件が圧倒的に多い(比べてJava案件は億規模がゴロゴロある)。これに原価60%だと計算すると120万になる。これがエンジニアに支払われる金額となる。予算200万の規模だと工数は延べ2~3人月ぐらいが良いところだろう。工数がかかりすぎだと思うだろうか?これに要件定義や設計期間、運用テストなども含まれていると仮定すると、妥当な数値だ。単純に120万を3で割っても一人当たり40万だ。上流工程で月40万とかはありえないので、マネジメントをする上流SEだけ月60万と計算すると、コーダーに支払われるのは一人当たり30万となる。この計算、発注者と受注者の間にウワマエを刎ねるハイエナ会社(管理費、口座貸費用などの名目でウワマエを刎ねる)が一切いないことを前提に話している(つまり商流が1段)。ハイエナがいればそれだけ技術者に流れる金も少なくなる。

次にPHPは比較的に習得が容易だ(PHPフレームワークなども含め)。つまりPHPerはたくさんいる。技術者がたくさんいれば相場は自ずと下がる。さらに高度な技術者は単価の低いPHP案件など受けない(Java案件などの単価の高い案件にいく)から、PHP案件しか受けられない技術レベルの低い(=単価を安くせざろうえない)技術者しかいない。結果、案件争奪戦はダンピング合戦となり、PHPer=低単価が決定される。結果、高いレベルの技術者は余計にPHPからはなれていく。ここ7~8年ぐらいこの負の連鎖が続いた。これがPHPerのエンジニアリングサービス(技術者派遣)の実情だ。ぶっちゃけて、Javaなら月60万から、PHPなら月30万から、と買い手と売り手の双方で価格相場が形成されている。PHPerがこれを超えて単価を勝ち取るにはPHPコーディング以外の付加価値が必要となる。

ではそもそもPHPで予算規模の大きなシステムはあるのか?あるにはある。しかし全体からすればごくごくわずかで、しかも首都圏に限られる。もちろんそこには高レベルの技術者が集まってくる(Javaでバリバリ稼いでいるけど、PHPが好き、などの場違いな高段者)。あなたはそこで彼らと肩を並べる自信はあるだろうか?

ではなぜPHP案件で予算規模の大きなシステム開発案件がないのか?それは大手システム開発会社が関わっているからだ。大きな予算がついているということは失敗が許されない。つまりリスクをちゃんとヘッジしてくれる大手システム会社にまず話が持ち込まれる。そういう大手はよっぽどのことがない限りPHPなど絶対に使わない。かならずJavaが提案される。(なぜかって?そりゃJava技術者のほうが人件費単価が高いからだよ!!そのほうが見積額を高額にできるからねっ!!)

さらに、エンジニアリングサービスにも地域格差というものがある。関西(主に大阪)は首都圏(主に東京)に比べて単価が80~70%と思っていい。東京での単価60万が大阪なら48万に、東京での単価40万は大阪だと32万になる。「SEなら東京にいけ」というのはこういうところからも来ている(そもそも案件数が首都圏は関西の2倍以上あるというのが主な理由ではある)。

つまり、金を稼ぎたいなら、PHPではなくJavaをやれ、というのが結論だ。というか常識と言っても過言ではない。

冒頭サイトで

PHPの場合はなにしろ開発需要が大きく、求人案件数も多いため、フリーランスの皆さんも多くの案件から自分に合ったものを選ぶことができます。

とあるが、この文章の後ろには「単価(給料)を選ばなければ」という一文が隠れていることを声を大にして言いたい。PHPの仕事は腐るほどあるのだ。だが誰が見てもワープアまっしぐら。あるていど会社組織の体を成している組織(社員を抱えていて食わせていかなければならない組織)では、その単価の安さから受けることができない(受けたら赤字確定だから)。したがってPHP案件は常時人不足。そこが辛うじて現在の単価を維持しているカラクリだ。

このままだと、PHPがあまりにも悲しいのでPHPの優れている点もあげていく。
(技術的に、ではなく、ビジネスとして、という観点から)

PHPはJavaに比べて圧倒的に「安く」作れる。PHPはあらゆるコストがJavaに比べてとても低いのだ。つまり同規模のシステムであれば、Javaに比べPHPのほうが1/10の金額で作れる。これは予算が限られている顧客にとって最大のメリットとなる。したがって、我々のような極小規模のインディペンデント会社が、技術者を売るのではなく、システム開発の全体像から提案して受託開発の受注を狙う場合は、PHPで提案することにより顧客に刺さる可能性が飛躍的に高まる。さらにインフラ周りや改修などの運用コストも低く抑えられるので提案力が出てくる。つまり、起業するとかフリーランスでシステム開発受託を狙う場合、大手と差別化をはかるという意味でPHPは大きな武器となる。逆に、前述に戻るが、末端技術者としてPHP案件に従事するというのであれば、経済的にジリ貧以外のなにものでもない。ワープアまっしぐらだ。「それでもPHPが好き」というのであれば別だが・・・

三菱東京UFJ銀行のワンタイムパスワードについてサポートに電話してみた


三菱東京UFJ銀行のワンタイムパスワードについてサポートに電話してみたのでその内容を書いてみる。まだワンタイムパスワードの申し込みをしていない方は参考にしてほしい。

三菱東京UFJ銀行のワンタイムパスワードについてサポートに電話してみた

スマフォアプリでワンタイムパスワードを生成する方法と、ジャパンネットバンクや三井住友銀行のようなパスワード発行機(カード型)を使う方法の二種類選べる。

スマフォアプリでは、1口座しかワンタイムパスワードを生成できない。たとえば、UFJで個人口座と事業口座を持っている場合、スマフォアプリではどちらか一方の口座しかワンタイムパスワードを生成できない。一つの端末でどちらか一方の口座しかワンタイムパスワードを生成できない。

アプリで初回登録時(※初回のみ必要で一回設定すればよく、ワンタイムパスワードの生成のたびに必要ではない)に設定用番号なる番号が必要で、その番号の取得は、毎日8:00~21:00、1日3回までと制限されている(※つまり、無理やり1端末で複数口座を運用する方法の障害となる)

一度申し込んだ後にカードからアプリ、もしくは逆にアプリからカードへの変更が可能である。

カードからアプリへ切り替える場合は即日だが、アプリからカードへ切り替える場合は郵送期間も含めて10日前後かかる。

アプリの場合はインストールしたアプリから、カードを申し込む場合はネットから申し込んでほしい。

IT系でよく使う「経営者」「マネージャ」「ディレクタ」「プロデューサ」というチョット意味不明な役職を「戦争」に例えて説明する


説明をスタートする前に、戦争において「戦術」と「戦略」の違いをご存じだろうか?とりあえずウィキペディアの「戦術と戦略」ご覧いただきたい。

以下「ウィキペディア – 戦術 – 戦術と戦略」項より抜粋

戦略と戦術を明確に区分分けする事は出来ないが、概念上は区分されるべきものである。戦略は戦役全体での勝利を収める為に指導する術策であり、[32]戦術は戦場において実際に敵に勝利するために戦闘部隊を指揮統制する術策である。つまり戦略は大局的な観点から目標設定の整合性や他方面の状況などを調整した巨視的な術策であって、戦略上の都合によって採りうる戦術に制約が生じることはありうる。
戦略と戦術の類似点をいくつか挙げることは出来る。両者ともに目標達成の手段という共通の性質を持ち、また戦略・戦術は共に一般的な理論であると同時に特殊的な術である。初心者はしばしば戦略を理論、戦術を実践として誤解するが、双方とも理論と術を併せ持っている。加えて情勢判断に基づいた戦力準備・戦力運用・教育訓練が三位一体となって目標達成を追求するという基本的な枠組みも類似している。[* 防衛大学校・防衛学研究会編『軍事学入門』(かや書房、2000年)144項より]
戦略と戦術の異なる点も挙げることが出来る。それは戦略と戦術が上下関係に属していることと関係して、考慮すべき問題の大小、配慮すべき時間の長短、視野の広狭などが決定的に異なっている点である。また戦略家・戦術家の思考様式の差異であり、戦術家としての役割を担う下級指揮官は一定の条件下で与えられた任務を達成するために判断すればよいが、戦略を担う高級指揮官は下級指揮官に任務を与える場合に必要な戦力を与えなければならず、また常に全体的な状況を把握して指導することが重要である。[* 防衛大学校・防衛学研究会編『軍事学入門』(かや書房、2000年)145項より]
また戦略・戦術の概念は近代以降に精緻化が進み、戦略は国家戦略、軍事戦略、作戦戦略に構造化されている。[* 防衛大学校・防衛学研究会編『軍事学入門』(かや書房、2000年)141項](戦略を参照)また作戦的な性格と戦闘的な性格から戦術を作戦術と戦術に区分する場合もある。

とある。このことを簡単にするために、ここでは、戦場という現場で行う術を「戦術」、戦場以外で行う術を「戦略」と定義する。厳密には違うかもしれないが概ね間違ってはいないはずだ。

まずは「経営者」から説明していく。

経営者の役割はとは戦争をする(つまりプロジェクトを行う)に当たって「どうなれば勝利なのか」「どうなると敗北なのか」「戦うことによって何を得るのか」を定義することだ。つまり目的を明確に定義することに尽きる。目的を達成するための手段や方法を考えるのは経営者の仕事ではない。経営者は戦略も戦術も定義してはならない。その役割は他者に任せなければならない。

次に「プロデューサ」について。

プロデューサの役割は、経営者が定義した目的を達成するための「戦略」を練ることだ。戦略の中でも「勝つための戦略」という攻撃的(オフェンシブ)な戦略を考える役割を担っている。したがって、プロデューサはリスクを恐れず打って出て、戦うことにより得られる目的を最大化することを考える。従って正面突破が難しいようなのであれば奇抜な策を提案することもあるし、十中八九勝てて、だれがやっても最大の効果が得られる勝ち戦ならばプロデューサの出番は少ないだろう。プロデューサはその役割の性質上目立つ。どのような職種においてもプロデューサが派手に見えるのはそのためだ。

「マネージャ」について説明する。

マネージャはプロジェクトを進めるにおいて、また戦う組織を維持運営する場合においてもっとも重要な役割を担う。マネージャもプロデューサと同じく「戦略」を練ることを役割としている。しかしプロデューサとは視点が違い「負けない戦略」という防衛的(ディフェンシブ)な戦略を考案するのがマネージャの最も重量な役割だ。戦争においても仕事上のプロジェクトにおいても、勝てなくても負けなければよいのだ。現実での戦いというのはゲームのように勝ち負けだけのゼロサムゲームではない。勝てないとわかっていても戦わなければならないことが往々にしてある。その時に「負けない戦略」が非常に重要になってくる。逆に、いくら勝てそうな相手だからといっても、どんな不測の事態が起こらないとも限らない。相手の戦力や戦略、戦術の予測を見誤っている可能性もある。それらのリスクをあらかじめ予見して、もしもの時を考え、被害を最小限に抑える方策をあらかじめ立てて置き、必要とあらば躊躇なく防衛的な戦略を発動させるのがマネージャの仕事だ。つまり、自組織を永続させることがマネージャの最も重要な役割と言い換えてもいい(戦って勝ったとしても自身がボロボロで再起不能ではそれは負けたに等しい)。さらに加えると「マネージャ」の重要なもう一つの役割として、戦線を維持して戦力を常に最高の状態に保つための兵站(ロジスティクス)を整備することも「マネージャ」の大きな役割だ。なお、現在のアメリカ軍では軍事作戦費用の50%以上をロジスティクスに費やしている。「マネージャ」はそれだけ重要な役割を担っている。

そして最後に「ディレクタ」だ。

もちろんディレクタは戦術を担当する。経営者が戦闘(仕事上で言えばプロジェクト)の目的を定義し、それに沿った戦略をプロデューサとマネージャが立案、準備をする。その戦略を受けて戦場で最も効果的に、かつ効率的に結果を出すために指揮を取る。つまり、戦場において、与えられた人的、物的資源(リソース)を最大限有効活用して戦略を具体化して目的を達成させるのがディレクタの役割だ。

なお、筆者の個人的主観だが、第二次世界大戦の日本軍には「マネージャ」職が欠落していたように思う。逆に「プロデューサ」と「ディレクタ」職は非常に優秀な人間が多かった(ロジスティクスが互角であった場合、総合すると日本軍は勝っていたそうだ)。つまり、勝つための戦略は立てられるが、物量に勝る相手に対して「負けない戦い」ができず自身がボロボロとなり再起不能となった。それを顧みず戦いを続けた結果が第二次世界大戦の結果につながったと思っている。もし当時の日本軍に優秀な「マネージャ」職が存在していて、「プロデューサ」と「ディレクタ」と同等かそれ以上の発言力があったとしたら、いまの歴史は大きく変わっていたはずだ。

この説明では仕事上のプロジェクトの役職を戦争に例えて説明してみた。「戦争とビジネスは全く違う」と反論される方もおられるだろう。しかし、現在主流のプロジェクトマネジメントの源流は、戦争大国アメリカでの戦争理論からきている。また、完全な戦争論であるランチェスターの法則を取り入れた企業が結果を残しているのは、戦争とビジネスが非常に似通った行為であることを如実に示している。

いかがであっただろうか?身近なプロジェクトに照らし合わせるとこの説明は非常にしっくりくるはずだ。そして、うまく回っているプロジェクト、成功したプロジェクトをみると、この役割がぴったり当てはまっていることが多いのではないかと思う。

2015年11月16日からauでスマートフォン回線を契約するとボッタクリのパケット定額プランが強制加入になる


スマートフォンを使用する場合、通常だとパケット定額プラン(カケホーダイプランなども含めたパケホプラン)の割引プランをに何も考えず加入している方が多いだろう。一方で、比較的割安なポケットWiFiやWiMAXなどのモバイルWiFiルータを持ち歩き、ネット回線はポケットWiFiやWiMAXなどの回線を使用して、スマートフォンのモバイルデータ通信は基本的にOFFで運用する方法がある。近年MVNO(仮想移動体通信事業者)が非常に充実してきており、メガキャリア(DoCoMo、au、Softbankなど)よりも安価にモバイルデータ通信手段を調達できるようになってきたので、この運用方法を選択する方がさらに増えてきたのではないだろうか。

当然ながら、このポケットWiFiやWiMAXなどのモバイルWiFiルータを使用してスマフォを運用する場合にはメガキャリアの高額なパケット定額プランには加入しない。auショップやDoCoMoショップで店員に「ネット通信量が高額になりますよ」という脅しに屈せず「すべてなし、基本料金のみで!!」と豪語して、おもむろにモバイルデータ通信をOFFにして、自分の持っているWiFiに接続するのだ。

そこで本題。

auではこの「高額なパケット定額プランには加入しない」ができなくなる。正確には2015年10月27日現在は「高額なパケット定額プランには加入しない」は可能なのだが、auでは2015年11月16日からパケット定額プランが強制加入になる。また、一度でもパケット定額プランを付けてしまうと今後は「パケット定額プランが外せなくなる」。なお、このパケホ強制はiPhoneだけでなくすべてのスマートフォンに適用される。ガラケ(フィーチャーフォン)は除外とのことだ。

こればっかりは正直暴挙と言わざろう得ない。月々5000円弱の高額な定額プランが強制加入とは殿様商売にもほどがある。現在、ガラケーユーザは月々2000円弱しかコスト負担していない。それがスマフォにしたとたん、スマートバリュー等の割引をしたとしても6000円弱が確定する。初期投資で機種を一括購入、基本プランのみを契約して(分割割引を放棄して)、ネットは自宅やWiFiスポットを使用するという運用方法も取れない。もちろん、ヤフオクなどで白ロム機やSIMフリー機を購入して基本プランのみで運用する方法もできなくなる。完全にユーザの利便性と多様性を無視した暴挙だ。

益々MVNOなどの格安キャリアへの転出組が増えるだろうし、auから他キャリアへの転出も増えるだろう。さらばau。

2014年10月~11月のサイトを閲覧したスマフォ・タブレットの機種別シェア


直近30日分のGoogle アナリティクス 解析結果にて。

ちなみにこのサイトじゃないよ。

俺がやっているWEBサービスのTOPページです。

言っときたい事は、このサイトのように、其の筋の人間が多いサイトじゃないってこと。システム関係の人間じゃない方々が8割以上なのは確か。

やっぱりiPhone, iPadがおおいなー。appleシェアが落ちてるとはいえ、やっぱりスマフォ・タブレット対応の最有力はまだまだiPhone, iPadなんだね。

ちょっとびっくりなのはWindows RT Tabletが以外と多い事。

Windows RT、シェアのばしてるねー。

ランサーズの「タスク」で仕事を依頼するとクソな成果品を拒否できない事がある


先日、ちょっとした文章作成をランサーズで依頼した。

ランサーズってしってる?ずいぶん前から有名なんだけど、ネット上で仕事を発注して見ず知らずの人間に仕事をしてもらうサービスだ。すべてのやり取りはランサーズサイト内で行われる。もともとWEBサイト作成やロゴデザインなんかが有名で、近年になって、少額で簡単な仕事を「タスク」という形で頼めるようになった。1仕事10円とか50円とかで仕事してもらえる。今回はその「タスク」ってやつでちょっと長めの文章作成を作成してください、●件募集ね、って依頼してみたわけ。

依頼した件数を書いちゃうとバレバレになりそうだから書かないけど、そんなに多い数じゃない。実はこの「依頼数」ってのがミソだった。

仕事を依頼して数日したら、さっそく文章がいくつか上がってきたわけ。それみたら、まークソなんだわ。こっちの指示はガン無視だし、意味わからん文体でそもそも日本語になっていない。到底そのままじゃ使えない。しかも1件とかそんなんじゃない。全部クソ!!こら全部拒否だわ、と思った。そしたら拒否できねーでやんのッ!!

「依頼数の30%を超える拒否はできません」

おいッ!!
ってことは、3件依頼したとしたら1件も拒否できねぇってことじゃん!!

ここまで書いたら正直に言います。
俺が依頼した数は3件です。
クソが3件きました。
はい拒否できません。
1件も受け取り拒否できません。

ちーん・・・・・・

全額無駄になりました・・・

_ノ乙(、ン、)_

まぁね、最初にランサーズの仕組みをちゃんと読んで無かった(事前調査もしなかった)俺が悪いですよ、ええ、俺が悪いんです。でもね、仕事を依頼した側としては、仕様に沿っていない、仕様ガン無視で作られた成果は受け入れできないもんでしょ、フツー。それを「依頼数の30%を超える拒否はできません」という理由で強制的に納品させるのはちょっとヒドイよ。これって、依頼主の意図を無視して書いちゃったモン勝ちってことじゃん。

っということで・・・・対策としては・・・・

「クソが来る事を見越して1件当たりの単価をクソ安くして数を稼ぐ」

しかないのですよ。そう

「下手な鉄砲数撃ちゃ当たる」

戦法ですね。

あ・・・だからランサーズって悪い意味での価格破壊の急先鋒なんだね・・・

Googleが定義する「みんなが素晴らしい管理者と認める8つの行動(オキシゲン・エイト)」


WIRED VOL. 7に面白いことかいてあった。

天下のGoogleが「良き上司(=良き管理者)」を従業員にインタービューしながら分析したんだそうだ。
その結果が以下のもの。

  • 1.良い指導者でること
  • 2.細かい事まで口出ししないこと
  • 3.従業員の幸せに関心があると態度で示すこと
  • 4.生産的で結果志向であること
  • 5.チームの話に耳を傾けること
  • 6.従業員のキャリア開発を支援すること
  • 7.明確なビジョンをもっていること
  • 8.最低限の専門的技術をもつこと

ちなみに「8.最低限の専門的技術をもつこと」が項目のなかで一番重要視されていなかったそうだ。つまり管理者としてふさわしい人間は、「仕事」に向き合う事よりも、「仕事をする人間(=部下という人間)」に向き合う事が重要だということ。言いかえれば、「仕事」を大切にするのではなく、「仕事をする部下という人間」を大切にすることが一番重要である、ということだ。Googleで「オキシゲン・エイト」と呼ばれる評価基準は、実際にGoogleの人事体制を決定する評価基準として使われているそうだ。

あなたが所属している組織、もしくはあなたの会社の組織体制ではどうだろうか?