読者です 読者をやめる 読者になる 読者になる

成長し続ける企業の要件

最近、リクルート楽天、他優良なスタートアップ企業の方から

話を聞く機会があった。

視野・視座が広がり、起業する際の役にも立ちそうだったので

「成長し続ける企業」をテーマに考えを整理してみる。

 

成長し続ける企業の代表「リクルート

「成長し続ける企業」という点において、

特に印象づけられたのは、リクルート

 

創業: 1963年8月26日

有名な社訓: 自ら機会を作り出し、機会によって自らを変えよ

ポリシー: 「リクルートの使命は、どれだけ人を集めるかではなく、生活者、消費者と企業を結びつける、『マッチングプレーヤー』としての役割を担うことです。よい就職ができた、よい人材を獲得できたと、双方に満足いただけるサービスをいかに提供していくかに重点を置いています」

(引用: リクルート、成長加速の”3段ロケット” | 企業戦略 | 東洋経済オンライン | 経済ニュースの新基準)

 

何よりリクルートの方に話を伺っていて感じたのは、

50年以上の歴史をもちつつ

未だに挑戦者としての気概を社員一人一人に与え、いや、引き出し、

継続的な飛躍を狙っている点。

また、オンライン・現物問わず、またその融合により、

広い事業ポートフォリオを実現し、かつ、広義の仲介業をメインにすることで、

それが安定した高収益性をもたらし、挑戦を後押ししている。

 

その挑戦の一端として、最近ではAirレジなどに見られる、

これまでの営業をベースにした仲介ではなく

技術を基礎としたサービス提供も拡大させている。

https://airregi.jp/

 

そこで、挑戦に伴うのがリスク(不確定さ)。

リクルートでは、挑戦についてはそのプランニングや予算管理も含め

大きな裁量を持って現場のマネージャーをはじめとしたメンバーに与えているものの

撤退については、特にその上層部を中心に判断をしており、

一定リスクの取り方が上手な印象も受けた。(当然といえば当然か)

 

リスクの取り方でいうと、

楽天では、スモールスタートといった考え方が強いらしく

小さく始め、成功したのちに、大きく事業を拡大させるというアプローチが

取られる傾向があるとのこと。(これも当然といえば当然か)

ただし、楽天の場合は、事業が比較的トップダウン

高速である反面、第三者的な観点を挟みにくい。

そのため、直近はその打破のために社内コンサル的な部門も設立されているとのこと。

 

####################################

蛇足で、ゲームビジネスなどは、スモールスタートでいくら成功しても

後発の大手競合に食われてしまうので、

一定、初期から完成度・コンテンツ量をもたすために投資が必要になりがちだが、

どうにか、このスモールスタートに近づけるよう、

リスク緩和を行うプロセスを取れると一つの発明かもしれない。

 

例えば、社内に仮想アプリマーケットを用意し、

そこに社内のだれもがアプリをリリース可能にし、

フィードバックをもらえ、またそこでの継続プレイ率や、

仮想通貨の消費量などを監視できる仕組みを設け、

そこから自動で事業の投資価値を計測し、見込みがあるものに積極投資を

行うことなどができると理想的か。

####################################

 

「成長し続ける企業」の話に戻ると、

肝要なのは、

起業家精神(アントレプレナーシップ)を始めとする素質と覚悟をもった人材を集め、

彼らに相応、もしくは拡張した挑戦の可能性を与え成果に見合った評価・昇進を行う。

そして、こういった枠組みがあることをメッセージングとして常に意識すること。

 

例えば、リクルートでは、企業内の所属変更の制度があるらしく、

転属を希望し、転属先が許可した場合、元の部署では引き留め権限がないとのこと。

そのため、マネージャーは、部下にパフォーマンスを十分に発揮できる職務を与え

キャリアパスを発展させ、また、満足度の高い就業を実現することが

自然と求められる。

こういった制度を用意し、また、社員へのメッセージングとしても

実際に活用していくことで、自然と免疫・代謝が保たれるように感じられた。

 

自分が起業する際には、こういったことを肝に銘じ、組織を強めたい。

 

次の項目では、こういった「成長し続ける企業」の要件について

会社を、個人・組織・企業の3つのレイヤーに分け、代表される要素を記す。

 

成長し続ける企業の要件

要するに、以下の3点に集約される。

・個人レベル: 起業家精神(アントレプレナーシップ)

・組織レベル: 客観的評価機構

・企業レベル: 明確で着実なビジョン

 

個人レベル: 起業家精神(アントレプレナーシップ)

今回、すでに成熟しつつある中で、さらに進化を遂げている企業から

多くを学んだ。

 

その中で、企業の継続的な成長には

起業家精神を尊重し、それをすべての従業員に期待することが

極めて重要だと感じさせられた。

ここでいう「起業家精神」とは、以下を含むものである。

 

・高い視座

(マネージャー、部長、経営企画、取締役、社長、投資家、競合が何を思うか)

・成し遂げたいビジョンをビジネス的要件や野心・問題意識から導く力

・その実現のための計画・推進力

・結果へのコミットメント

 

サービスは、そこに進化を伴わない限り、

いつか飽きられるか、もしくは、洗練された新たなサービスに駆逐される。

社員一人一人が、この感覚を持ち、

日々進化・飛躍するための種を探しつつ、実際に形にして進み続ける企業は、

当然、そうでない企業と比にならない飛躍を遂げる。

そして、利益を生まないサービスは、人を雇う力を失い、

結局、従業員やその家族を不幸にする。

 

もちろん、企業はあらゆる人種・役職の集合体であり、1つの組織である。

ただただコーディングが好きなエンジニアもいれば、品質の高い絵を描きたいデザイナーもいる。

企業のビジョンに同意するものもいれば、興味を抱かないものもいる。

彼ら"プロフェッショナル"は、正直、それをできれば個人としては満足する。

多様性を尊重できることは、

彼らに代表される、尖った人材の確保を容易にするため

企業にとって都合のよい側面はある。

 

しかし、これまで共に仕事をした中で、

そういった尖ったスキルに頼って生きてきた人間で

プロジェクト運行上、輝く人間はいた試しがない。(あくまで自身の経験上)

大概、コミニュケーションスキルや、QCDなどの概念を欠き、軋轢を生みやすい。

 

とすると、一種のバランス感覚やビジネスマインド、起業家精神

併せ持つプレイヤーを、自身の企業では歓迎したい。

芸術性の高いUIよりも、使い勝手の良い調和のとれたUIが優れ、

個性的で卓越したコードよりも、保守性や可読性の高いコードの方が望まれる。

エンジニアの場合は、アンテナの高さや、プロセス改善自体に興味があるかも

一つの鍵となるが。

 

改めて、鍵は社員一人一人の起業家精神

そして、それを後押しする制度とメッセージング。

 

組織レベル: 客観的評価機構

企業が成熟するほどに、欠如しがちと思われるのが客観性。

過去の栄光や歴史は、容易に人を驕らせ、疑念を埋もれさせる。

結果、うさぎと亀の昔話でいう、うさぎになりさがる。

 

そこで重要なのが、客観性。例えばの観点は下記の通り。

いずれも数値に落として相対性を確認できると理想的。

<企業>

井戸の中から井戸を良くしようとするのでなく、井戸の外から俯瞰する。

他社との現場のビジネスマンレベルでの交流を図れれば理想。

 

<組織>

脱・仲良し経営。中立性、客観性を保つために

社内コンサルでも、外部コンサルでも、客観的に評価を行う立場を設ける。

 

<サービス>

事業、サービスの客観評価の積極的な導入。カスタマーやクライアントに

どう評価されているか、どうしたらそこに改善の余地があるかを把握する。

また、リリース前の機能についても、同様に客観的評価を尊重し、判断基準に加える。

 

ちなみに、社内での企業改革に向けた提案 / コンサルに対して、

眉をひそめるようでは、その会社に未来はないと思った方が良い。

提案者は、その会社を見捨てていない、

むしろ、倒産してほしくないと切に願う一人であることを忘れてはならない。

自身が、経営判断に疑問を抱いたことはないか、

"経営判断"という名前だから触れられないものだと思って鵜呑みにしていないか、

間違っていると思ったのに結局問題提起を行っていないまま過ごしていないか、

一度、考えてみて欲しい。

そういったアイディアの一つ一つは、本来、企業の寿命を長くし、

また、あなたのキャリアや年収を引伸ばすための、材料となるはずだ。

 

企業レベル: 明確で着実なビジョン

ここまで、個々人の起業家精神や、組織の客観性の重要性に触れたが、

大前提として重要な概念を最後に記す。

 

それは、企業としての明確で着実なビジョンの重要性だ。

ビジョンは、読み手や読む角度によって、展望、道標、目標などとして受け止められる。

ちなみに書き添えた言葉の意味については、

"明確さ"は、当然、ステークホルダーに誤りなく、今後の期待値調整を行うため。

"着実さ"は、期待が信頼に足ると示すことで、企業の理性を示すため。

 

このビジョンを明確に描くために必要なことは、

現在が既に、あるビジョンの途上であるという自覚に他ならない。

ビジョンに途切れがあるのは企業として怠惰そのものである。

個々人のキャリアやモチベーション管理でも用いられる人事手法に、

Management By Objectives(MBO)という言葉があるが、

個々人を包含する企業そのものについても同じこと。(程度が低い話ではある)

 

では、どの程度の期間を見越し、

どの程度の粒度でビジョンが描かれていると良いのだろうか。

 

継続的に成長したい気持ちは当然あるので、遠い未来まで描きたい可能性はあるが

そこは"着実さ" = 信頼と相反するものを生み得る。

そのため、まず5年を描くことが望ましいと考える。

比較的に、時流や社会現象の予測が立ちやすい範囲とも思われる。

例えば、自身が勤めていた金融コンサル企業や、例えば楽天のVision2020なども

5年程度を見越し、将来をデザインしている。

 

次に、その粒度だが

ビジョンは、人を突き動かす指標となるものであるべき。

そのため、噛み砕いて、事業や日々の業務レベルに落とせるように、

数値となって示されることが望ましい。

 

個別部署での数値までは論じないにせよ、ある程度の根拠と見通し、また熱意をもって

事業ポートフォリオや注力事業がどのように変化し、その結果として、

最終的に売上や利益がX%成長 = X億円達成といった形で示されるべきである。

 

  

以上、改めて整理すると、最近の各社の話を通じ、

以下の3点が「成長し続ける企業」にとり、肝要であると見受けられた。

 

・個人レベル: 起業家精神(アントレプレナーシップ)

・組織レベル: 客観的評価機構

・企業レベル: 明確で着実なビジョン

 

この記事が、皆さんの企業の改善において

少しでもお役に立てば、幸いです。

FacebookやTwitterのアプリ内ブラウザで画面高さが適切にとれない

今回は、TwitterFacebookのアプリ内ブラウザ(embedded browser) に

フッターの固定メニューが正しく表示されない事態が発生したので、

その解消の経緯をメモ。

inappbrowserキライ。

 

結論

inappbrowserでは、

innerWidthなどは、URLやステータスバーなどの表示領域を含まれる、

ブラウザ全体の高さを取得してしまうのでNG。

 

レイアウトの観点では、画面最下部に寄せるなどの表示を

行うためには、position: fixedを用いるべし。

 

ベース資料

まず、いろいろぐぐって、これに行き着く。日本語記事はなかった。

html - Wrong viewport/page height in embedded Facebook browser in iOS 9.x - Stack Overflow

 

また、ちゃんと動いている例を探してみる。このあたりはちゃんと動いている。

Core Layout: Demo App

スマートフォンページのフッターに固定メニューを作成してみました

 

ということで、Core Layoutは、そのライブラリがベースなので使うのやめて、

フッター固定の記事に従ってみる。

 

最終的な適用内容

* bodyやhtmlなど、最も外枠になるdomをこの設定で、置く。

  # 多分、この限りでない。

  position: absolute; top: 0; left: 0; height: 100%; width: 100%;

  # bodyとhtml要素にも、position:fixedを一度設定したものの、position:fixedでは、

  背景の高さがとれていなかったので、absoulteに寄せることに。

 

* body内の、背景画像をはめ込むための全面を満たすdomをこの設定で、置く。

  position: fixed; top: 0; left: 0; right: 0; bottom: 0; overflow: hidden;

  # ここにbackgroundを、幅100%, 高さautoで指定すると背景の画像が適用される。

 

* 念のため、以下に記載の、ウィンドウサイズをhtmlのdomに書き添える処理を実施。

 

試行錯誤の過程 

高さの指定の仕方を変更。

height:100%で指定するのでなく、以下の通りの指定に変更。

以下の通り、viewportの指定と合わせ技に。

<meta name="viewport" content="width=device-width, initial-scale=1.0001, minimum-scale=1.0001, maximum-scale=1.0001, user-scalable=no, shrink-to-fit=no"/>
html, body, 任意のheight:100%の外枠のdom {
  position: absolute;
  top: 0;
  left: 0;
  bottom: 0;
  right: 0;
  overflow: hidden;
}

 => だめ。

 

続いて、サンプルに全く習って、viewportをこう書いて 

<meta name="viewport" content="width=device-width, initial-scale=1.0, minimum-scale=1.0, maximum-scale=1.0, target-densityDpi=device-dpi"/>

このメソッドをangularのinit処理に書き足してみる。

function _fixViewportHeight() {
    var html = document.querySelector('html');

    function _onResize(event) {
        html.style.height = window.innerHeight + 'px';
    }

    window.addEventListener('resize', _.debounce(_onResize, 125, {
        leading: true,
        maxWait: 250,
        trailing: true
    }));

    _onResize();
}

_fixViewportHeight();

=> やっぱりだめ

 

vhとか、vwで幅・高さを指定してもだめ。

 

ここでposition:fixedに気づく

 

fixedを適用した結果、背景画像が表示されなくなる。(高さが0になる)

 

fixedを広く指定しすぎないよう、調整して、高さを保つようにする。

 

修正完了! 

 

その他、過程で確認したこと。

viewportに、"shrink-to-fit=no"を追加。

 => これは、そもそも、iOS9?になって、一部で

  スクロール中などに勝手に画面サイズへの最適化を図ろうと(?)

       リサイズのような挙動が発生してカクつくことへの対応のための模様。 

 

 

参考 : 

html - Wrong viewport/page height in embedded Facebook browser in iOS 9.x - Stack Overflow 

ios8.1 - Web page not getting 100% height in Twitter app on iOS 8 - Stack Overflow 

html - iOS9 Safari viewport issues, meta not scaling properly? - Stack Overflow

ios 9 Safari / Web App Viewport Problem (expand... | Apple Developer Forums

 

AngularJS ng-include使用時のhtmlのpreload方法

最近、転職活動に勤しみだしたnaosk8です。

 

今日は、Angular触っていて、いろいろぐぐって辿り着いた

ng-include使用時のhtmlのpreload方法。

 

前提 

- AngularJSのバージョン : 1.4.1

- やりたいこと :

 ng-include, ng-routeの対象となる全htmlを1ファイルにまとめ

 htmlファイルとしてはそれだけを取り扱うことで通信コストを下げたい。

 # アプリサイズも小さいので1ファイルにまとめてますが、

  サイズが大きい場合は分割単位は各々検討してください。

 

つまりはこうすれば良いらしい

AngularJS: load all templates in one file · GitHub

 

つまづき

一連のgit上でのやりとりでも書かれていますが、

以下のようにheadersも返してあげないと、ちゃんと動きません。

f:id:naosk8:20160414092043p:plain

 

また、Promiseの内部の結果をreturnするだけでなく、

Promise自体をreturnしないとだめ。

f:id:naosk8:20160414092201p:plain

 

運用上のノウハウ

リンク先のソース上、getする対象のhtmlに対して、

クエリパラメータで、バージョンを指定しておけば

そのバージョン更新を行うことで、一気に参照するhtml全てを更新可能。

逆に、それをしないと、部分的に古いキャッシュを拾い続けたりするので注意。

 

 

ではまたまた。

CloudFlareでJavascriptの初期化失敗 : RocketLoaderを使いこなせていないのが原因かも。

CloudFlareを使っていて、

今まで普通に動作していたJavascriptが、

突如、PCブラウザでのみ、初期化でこけるという事態に。

 

ファイルの分割の仕方などは変更していないのに。

 

結論、このサイトに記載の通り、

RocketLoaderの適用対象について、

一部のJSファイルを、手動で、RocketLoaderの適用対象外にしたら解決。

CloudFlareのRocket Loaderを個別に対処 « Everyday Pieces ::

 

大事なのは data-cfasync="false" です。

 

納得いってないものの。一旦、解決。

 

Facebookへのお問い合わせ・提案方法

Facebookページの作成をしようと思ったら、

部分的にいかがわしい文言が含まれるというだけで、(痴漢対策 <- "痴漢"的な話)

ページ名を名付けられず、くっという。

 

というわけで、

向こうの管理コストが爆増しそうなものの、

システム都合でFacebookの本義であるコミュニティ形成が阻害されているので

一報を入れることに。

 

全ての問い合わせには答えられないよ。

ということですが、皆さんも正式にこちらで投稿できるのでどうぞ。

Facebookヘルプセンター | Facebook > 報告する > ご意見・ご提案 (2016.03.21現在)

 

何かのお役に立てば。

GAE(GoogleAppEngine)でのapp.yaml設定サンプル

作成中のアプリの最終チェックしていたら、

一部CORS(Cross Origin Resource Sharing)の設定ミスがあったので調整。

 

GAEアプリでは、apacheの設定ファイルに書くような内容を

app.yamlというファイルに書くのですが、

なかなか、その設定の際にmime_typeを調べたりするのが手間だったので

良いサンプルを見つけて作業をしました。

 

こちらの通り。

GAE: App.yaml designed for serving a static site on Google App Engine (Python). Copy your static html and files into a folder called "static" next to app.yaml. Contains a bunch of mimetype declarations from html5boilerplate's .htaccess. May not be neces · GitHub

 

ちなみに、自分がハマったのは、font系ファイル(eot, svg, woff,ttf)の設定。

あとは、シングルページで、minifyしたhtmlをxhrで取得しているのですが

そこでcontent-type:text/htmlを設定し損ねていたこと。

 

と思ったら、抜け出せてなかったので、引き続き調査。

 

日々、精進。

 

PhoneGapでの署名付きapk作成手順

最近、珍しくブログ更新を継続できいるnaosk8です。

本日は、androidアプリのGooglePlayへの登録初心者な自分向けメモ。

 

GooglePlayへのapk提出に際して、

apkに対して署名を付す必要がありました。ので、その手順を。

 

まず、これでapkを生成。

$ phonegap build android --release

 

で、あとはこのサイトに記載の手順で完了!

何も迷うこと無く、すごく助かりました。多謝。

システム開発おぼえがき: Cordova(Phonegap)のコマンドラインで署名付きapkを作成する

 

ちなみに、zipalignを未適用で手動でリリース用apkに実行したのですが

導入には、こちらの手順書を参考にしました。

android sdkの`zipalign`をインストールする方法 - Qiita

 

なぜzipalignが必要なのかは、これ見て勉強になりました。

要するに、読み取り効率が良い状態を作ることで端末に優しいアプリにするため。

Androidにおいてなぜzipalignをやる必要があるのか - Qiita

 

ということで、本日は備忘メモでした。