orangeitems’s diary

40代ITエンジニアが毎日何か書くブログ

女性を男性職場の潤滑油のように利用しないでほしい

f:id:orangeitems:20190117174401j:plain

 

多重請負からユーザー企業に転職した方のお話

うーん。これは良くない。

もともとは2016年の日経xTECHの記事だそうですが、問題があります。

 

tech.nikkeibp.co.jp

 

長いですが、最後まで読んでみてください。

 

私の考えるこの記事の問題点

私も下請けからユーザー企業ではないですが転職した経験があるので、初めの方は共感して読んでおりました。この記事の4ページまではふむふむと読んでおりました。

5ページ目以降、「銀の弾丸はあった」の章以降に、問題を感じます。

問題を凝縮している段落が下記です。

 

 だが、彼女は現場の空気を一変させる力を持っていた。彼女が現場に入ってしばらくすると、今までいたメンバーが異常なほど高い生産性を発揮し始めた。

 思い当たる節がある。当時の開発現場は典型的な男性職場だった。火事場になると、身だしなみに気をつける余裕もなくした男性陣が、うつろな目をして蠢くようになる。

 私も現場をたらい回しにされていたころ、半年以上女性と口を一切きかなかったことがある。そもそも現場に女性がいなかった。女性を見るのは通勤の行き帰りだけ。それが当たり前の業界で、当たり前の環境だった。

 そういうところに女性が現れたのだ。20代、30代の独身も多い。男性陣に感じるところがあったのは間違いない。

 

火事場になった男性職場において、若い女性がいることでモチベーションが上がる。これを「銀の弾丸」と呼んでいるようですが。

今もって男性職場が多いIT業界において、女性を潤滑油のように機能させることを期待したり、それが「銀の弾丸」のようにポジティブに表現することは、私は「悪」であると考えます。

 

銀の弾丸とは

銀の弾丸の意味については、Wikipediaより引用します。

 

ja.wikipedia.org

原論文は英語である。日本語では『銀の弾丸はない』と、翻訳されることもある。ブルックスは、「銀の弾丸」(Silver Bullet)として、魔法のように、すぐに役に立ちプログラマの生産性を倍増させるような技術や実践 (特効薬) は、今後10年間(論文が著された1986年の時点から10年の間)は現れないだろう、と主張した。

 

男性職場に若い女性を投入すると、すぐに役に立ちプログラマの生産性を倍増させるような特効薬になる、と言っているのです。

 

なぜおかしいか

逆の立場になって考えましょう。

あなたが男性だとします。

火事場になった女性職場があるとして、その会社に一定期間派遣されるとします。

そうすると、あなたの魅力によって、女性社員の生産性が倍増するというのです。

あなたがシステムエンジニアだとして、そんな仕事を受けますか?

考えるべきは、男性・女性比率にかかわらず生産性を上げるためのマネジメントであり仕事のやり方です。そして性差に関わらず、本来のスキルにしたがってプロジェクトに組み込み、評価する態度こそ職場にとって重要です。

ユーザー企業の担当者がこの「銀の弾丸」を期待し、それをベンダー側がくみ取って若い女性をアサインするようなことは、IT業界にとって「悪」です。優秀な女性ほど、このような扱いを受けることに傷つくでしょう。

 

プロジェクトに必要なのは、技術はもちろんだが、やる気、そして円滑なコミュニケーションである。男社会であった開発現場に女性が登場すれば、女性の存在がきっかけになって、チーム内のコミュニケーションの度合いが向上し、男性はやる気を出す。最近、聞く機会が増えた多様性の好例といえばいいのだろうか。

 

多様性の効果について、絶対に意味を取り違えていると思います。多様な価値観によって異なる価値観、視点、経験やアイデアをコラボレーションすることで、より良いサービスを生み出すことがメリットです。今回の文脈では、女性の役割は女性であることだけであり、本来の業務にはタッチしていないので多様性の意味を為していません。

こういう記事に対して問題であるという声を挙げることに意味があると思います。私は本来の意味で女性がIT業界に技術者として参加してほしいですし、そうすることで生産性は上がると思っています。このような記事が2019年になっても表に出てくるようだと、明るい未来が見えません。

女性を男性職場の潤滑油のように利用しないでほしい。

 

えらく核心をついているPivotal CEOのKubernetes評

f:id:orangeitems:20190117110128j:plain

 

Kubernetesのリアル

Kubernetesでアプリ開発したことで、かえって今までより工数がかかっている。また、運用方法も今までと違うしベストプラクティスも少ないので本番稼働後も不安。そんな体験をしている人がそろそろ増えてきているのではないでしょうか。

実際、Kubernetesを実装しているIaaSの種類によって運用方法も若干違いますし、オンプレで構築する際も何のベンダーのソフトウェアを使うかで作法が変わってきます。また、進化するスピードも速いので、覚えたこともすぐ陳腐化する恐れがあります。

安定期に入るまでは仕方ないのですが、理想と現実は違うことは頭に入れておいた方が良さそうです。

 

Pivotalについて

Pivotalという企業は日本ではあまり知られていないと思うのですが、クラウドの世界では有名な企業です。現在DELLの子会社であり同社が70%の株式を保有しています。同じくDELLの子会社であるVMwareとの関係が深く、両社は協業関係にあります。

Pivotalの最も有名なプロダクトは、Cloud Foundryです。いろんなクラウドベンダーがPaaSとしてリリースしているので存在はご存知の方は多いのではないでしょうか。去年リブランディングを行い、Kubernetesを取り込んでいます。

 

www.atmarkit.co.jp

 Pivotalは2018年9月25日(米国時間)、同社が開催中の「SpringOne Platform 2018」で、アプリケーションプラットフォームの新版「Pivotal Cloud Foundry 2.3(PCF 2.3)」を発表した。

 PCFは、Cloud Foundryプラットフォームである「Pivotal Application Sercice(PAS)」、Kubernetes環境を提供する「Pivotal Container Service(PKS)」、そしてマーケットプレイス機能である「Pivotal Services Marketplace」を統合したもの。それぞれに進化が見られる。

 

従来のCloud Foundry部分はPASに、また新たにKubernetesをPKSとしてリリースしています。またサーバレスを実現するPFSも取り込まれています。全方位でクラウドサービスの実装を行っており、かつVMwareとも親和性が高い点でオンプレミスでは強い存在感を持っています。

 

Pivotal CEOがいいことを言っている

そのPivotal CEOのインタビュー記事が@ITに掲載されましたが、なんだか核心をついているなと思いましてご紹介します。

 

www.atmarkit.co.jp

「ほぼ更新することのない古いシステムがあり、これをモダナイズすることが非常に困難であるなら、コンテナ化してPKS上で動かせばいい。あるいは、社内開発のデータサービスを活用したい場合に、コンテナ化して動かしたいかもしれない。(PKSの利用を既存システムの稼働に限定するなら)運用としてはこうしたシステムを動かせ続ければいいだけになる。しかし、頻繁に更新し、本番環境にプッシュしなければならないようなインタラクティブなアプリケーション開発にPKSを使うのは、得策ではないと思う。アプリケーション開発者には、複雑なKubernetes活用のプロセスに関わらせるよりも、PASやPFSを使って効率を高めてもらう方がいいと考える」

これまでの古いアプリケーションはクラウドへ仮想マシンとして動かし、新しいアプリケーションはコンテナで開発しKubernetesで運用すべきだ、とこれまでいろいろな人がおっしゃっていませんでしたか?。CEOは全く逆のことを言っています。過去の資産はコンテナ化してフリーズして動かせばいいが、頻繁に更新するアプリケーションはKubernetesだと複雑すぎる、こう言っているわけです。

これは、マイクロサービス設計の否定とも言えます。モノリシックのままコンテナに閉じ込めておけという意味なのです。頻繁に更新し、プッシュするためのKubernetesなはずなのですが、「複雑」だと言っています。確かに、私もそう感じていました。特に開発者がインフラのことに気を遣ってコンテナ化しなければいけない点が、特に複雑と感じさせてしまう要因と言えます。

インフラエンジニアはKuberenetesで相当に楽になる雰囲気ではあるのですが、開発者はインフラのことを多少は知らなければいけなくなり、運用プロセスが複雑になるのは事実であると感じます。

 

「今は、多くの人々がコンテナとKubernetesに興奮を覚え、その一部はKubernetesが結局のところは基盤だという事実を見失っている。だが、アプリケーション開発者や企業における事業部門のトップ、そしてCIO(最高情報責任者)が最終的に気にしなければならないのは生産性、セキュリティ、そして一貫性だ。Kubernetesを使っている多くの人たちが、『もっと高い抽象度が欲しい』『使いにくすぎる』と言っている。だからこそPivotalでは、複数レベルの抽象度と、自動化の提供に注力している」

今、Kubernetesのコミュニティーは高い抽象度、および使いやすさの実装に力を入れている最中ですから、バージョンが変わるとどんどん中身が変わります。Pivotalはそこをわかっていて、現状のバージョンでも使いやすいように手を入れているというわけです。各クラウドサービスのKubernetesが微妙に違うのもそのせいですね。

 

まとめ

Kubernetesが本当に使いやすいものになって、基盤となりコモディティー化し、物理サーバーのようにどの会社から買っても同じようなものになるとすれば、その上にサービスを実装すればよいこととなります。なかなか現状を分かっているコメントだなあと感心したので、共有しておきます。

今後Kuberenetesがらみの開発プロジェクトが増えてくると思いますので、今の現状が理想までは届いていないことをご留意ください。なんとか各ベンダーがオーバーライドして本番運用できる体になっています。

でも私も現状のKubernetesは「もっと高い抽象度が欲しい」「使いにくすぎる」と言っておきます。

 

オープンソースとフリーライダー、昔からそこにあった問題。クラウドサービスによって潮目が変わる。

f:id:orangeitems:20190116163952j:plain

 

もう無理 from オープンソース

オープンソース開発元が、成果物をそのままクラウドベンダーがビジネス利用し、しかも巨額の利益をオープンソース開発元に還元しない、いわゆるオープンソースのフリーライダーが横行しているという件です。

 

www.publickey1.jp

オープンソースソフトウェアの開発元がクラウドベンダへの不満を表明し、商用サービス化を制限するライセンス変更を行う例が続いています。

 

実際のライセンス変更の中身を見ると、こんなことが書かれています。

www.confluent.io

コードを使用してSaaS製品を構築できますか?

はい、ほとんどの場合Yesです。SaaS製品を構築している場合は、Confluentコミュニティソフトウェアを使用できます。

唯一の制限は、ソフトウェアを当社の独自のマネージドサービスオファリングと競合するオファリングとして提供するマネージドサービスオファリングにあります。したがって、たとえば、KSQL自体が提供されている製品であるSaaS製品を構築することはできません。

 オープンソースの開発元がマネージドサービスとして運用しているビジネスと競合して、オープンソースを利用してはならぬ、ということです。

オープンソース開発者が、「もう、無理。。」、と言っているように思います。

 

オープンソースフリーライダーの議論は古くからある議論

まだ強気だったころ (2006年)

2006年の記事を紹介します。

hyoshiok.hatenablog.com

フリーライダーというのは、共有地の悲劇として知られている、誰もがそこから利益を得るのだけど誰もそこのコストを負担しないようなことが続くと、財が消費されて終わるという時、コストを負担せづに利益だけを得る人を言う。

 嗚呼、まさに今回の件を表現していますね。

オープンソースって、フリーライドされまくるんじゃないかという懸念に対する文章です。この文書の結論として、以下のことを言っています。

 

OSSの場合、フリーライダーが仮に存在したとしてもOSSに直接的な悪影響を発生しにくいというような意味でネタにマジレスかこわるいであった。

 当時は、クラウドのない世界でした。ハードウェアがあり、OSがあり、そしてミドルウェアがあるという古き良き時代でした。ハードウェアベンダーはその上に乗っかるOSとして何もしなければWindows Serverにすべて市場を奪われる危険性があったのですが、だからといって各社独自OSを作るより、Linuxとそのうえで動作するミドルウェアをオープンソース化するほうがコストが安いと判断しました。ハードウェアベンダーはお金だけではなく人的リソースも含めてオープンソースを支援し、Linux全盛の今日があります。

さて、オープンソースがあるからハードウェアが売れる。ハードウェアが売れるからオープンソースに投資する。この関係ですが、ハードウェアベンダーはあくまでもハードウェアを売るのが目的だったので、オープンソース開発元が行うマネージドサービスオファリングとは競合しなかったというわけです。

 

まだ強気だったころ2(2008年)

ダメ押しにもう一つ。

www.nurs.or.jp

「あなた」には「街をきれいにするという義務」はないかも知れないが、街がきれいになれば、気持ちよく街に住めるだろう。だから街をきれいにしたいと考えることは、何もおかしくはない。そこに「住んでいる」者の当然の「権利」なのだ。それは「街をきれいにしない人」はフリーライドしているように見えるかも知れないが、たとえば「ゴミ箱」をどこに置くかは、「街をきれいにしている人」が決めることが出来るし、「自分の家の前を最初にきれいにする」ことだって出来る。「貢献」する者は、意思決定に参加する権利を得るのだ。

「あなた」には「フリーライドする権利」がある。それがオープンソースだ。しかし、「フリーライドしない権利」もあるし、そっちの権利を行使した方が得であることも少なくないのだ。

 今、クラウドベンダーが真顔でこれを言ったら、蹴り飛ばされるだろうなあという内容です。結局のところ、ハードウェアベンダーであったり、RedHatのような会社がメリットがあるからお金も人も「好きに」出してくれるだろうということを前提としています。

特定のクラウドベンダーの登場で、この前提が大きく崩れたということに他ならないと思います。

 

予見されていた今の状況 (2004年)

これは日本の中の話とも言えますが、フリーライダー問題はこの時点で問題提起されています。

tech.nikkeibp.co.jp

まず,企業は,社内のオープンソース/フリー・ソフトウエア活動を認知すべきです。オープンソース・ソフトウエア開発者が,夜,家に帰って寝ずにやっているのが健全な姿ではないはずです。昼間,勤務先でもできるように,活動を認めなければなりません。

 また,オープンソース/フリー・ソフトウエアの開発者を雇用すべきです。開発者が好きでやっているのは確かですが,かすみを食っているわけではない。経済的基盤が必要です。

 例えばSRAは,PostgreSQL開発チームの中心メンバーであるBruce Momjianをコンサルタントとして契約して収入が確保できるようにし,彼がPostgreSQLの開発に注力できるようにしています。PostgreSQLを使用して恩恵を受けている企業はほかにもたくさんある。何もしないで利用するだけでは,フリー・ライダー(ただ乗り)と非難されることになりますよ。

(中略)

また,ソフトウエア開発自体がプロセスであるということが考慮されていない。ソフトウエアは何年にもわたって改善され続けていかなければならないのに,作るだけ作ったらそこで支援もおしまい,というのでは,よいソフトウエアは決して生まれない。単年度予算主義から抜け出すことが必要です。

 フリーライダーが、オープンソースを破壊するというのは、そもそものITの単年度予算主義から生まれているという指摘です。仕事しながらオープンソースを触っていたら、そりゃあ業務外じゃないかみたいな文化って残念ながら現実も変わっていませんね。そして日本がオープンソースに対するフリーライダー気質は変わりないかと思います。

 

でも問題意識もある(2019年、2017年)

こちら、今日出たばかりの記事。

developer.hatenastaff.com

具体的には以下のようなトピックを取り上げます。

- OSSコミュニティがどの様に成長し、どの様に人を育てるのか、
- 「普通の」エンジニアがOSSに貢献する方法や
- 良い車輪の再発明、悪い車輪の再発明
- OSSフリーライダー問題
- 業務でどうOSSに関わるか
- エンジニア向けSaaSを運営する上で、どの様にOSSを戦略的にやるか

 ということで、はてなは、フリーライダーには心を痛めていて、社内的にどうするかを具体的に行動されている企業だと思います。

 

こちらは2017年の話。

www.iii.u-tokyo.ac.jp

【講義概要】
IT企業においてオープンソースソフトウェア(以下、OSS)の活用は一般的になっており、コスト削減のためにのみOSSを活用することは競争優位を得る要因ではなくなっている。OSSを活用したITソリューション市場で優位性を獲得するためには、OSS自体への知識、開発力を高める必要があり、そのためにOSSの開発プロセス自体に関与すること、すなわち開発プロセスの過程へ貢献することは避けられない。しかしながら、日本の多くのIT企業にとって主要OSSは,未だに活用対象であり,これに対してOSSへの開発貢献は依然として低く,日本のIT企業がOSSのフリーライダーとなっている。

 一般的にはそうですよね。。

 

核心と怒り(2017年)

www.geek.sc

これは名文なのでぜひ読んでいただきたい。

耳の痛い人は非常に多いと思います。。

 

オープンソースが変わる潮目?

このように、フリーライダーに長年の間寛容な姿勢でいたオープンソース開発側も、一部のクラウドベンダーのフリーライダーの度が過ぎることから、態度を硬化させたということが起こっているのです。

クラウドベンダーのフリーライダーサービスをユーザーとして使おうものなら、自身がフリーライドしていることと同じ意味になってしまうのがわかりますでしょうか。

ライセンス上それができなくなったとして、AWSのAmazon DocumentDB(mongoDB互換)の例のように中身をそっくり入れ替えてクローズドソースにしてしまうのが果てしてよいことなのかどうか。

オープンソースの潮目が変わったと感じる2019年1月のこのトピックでした。

 

ワークスアプリケーションズの経緯から学べること

f:id:orangeitems:20190116112727j:plain

 

ワークスアプリ筆頭株主が経営権売却へ、の記事

日経ビジネスが、ワークスアプリケーションズの件でスクープ記事を出しています。

 

business.nikkei.com

システム大手のワークスアプリケーションズ(東京・港)の筆頭株主が経営権を売却する交渉を進めていることが16日、日経ビジネスの取材で明らかになった。働きやすい会社としての評価も高く、若者を中心に就職先として人気を集めてきたが、最近は業績不振に陥っていた。ワークスアプリの株式を6割強保有している投資ファンドが、全株を手放す意向で、売却に向けた入札を実施している。新たなスポンサーの下で経営の立て直しを迫られることになりそうだ。

 

ネットメディアにおいても、ここ数年革新的な企業として取り上げられることが多かった同社ですが、どこに業績不振となる原因があったのでしょうか。

巨額の訴訟等は有名なのですが、見方を変えて、これまでのメディアの記事を中心にこれまでの経緯を追ってみたいと思います。

 

2000年~2009年までの記事から

2004/12/3 ビジョン

www.atmarkit.co.jp

最後に牧野氏は、「多くの大企業では、会計システムそのものにはR/3を利用していても、周辺システムがレガシーである場合が多い。当社のシステムは周辺システムもノーカスタマイズで対応できることを強みにリプレイスを狙う」と戦略を披露。さらに、「SAP、オラクル、ピープルソフトの世界3大ベンダに対して、日本の商習慣に完全対応していることを強みに競争し、ERPパッケージ世界4大ベンダの仲間入りしてみせる」と夢を語った。

私は企業のビジョン以上には企業が成長することはないと信じていますが、SAP、オラクルと並ぶERPベンダーになりたいというビジョンを立てた時点で、SI、人事、財務、いろんな面における大胆な施策が実行に移されたと解釈しています。

それが正しいかどうかにかかわらず、ビジョンによって組織は大きく動かされていくのです。

 

2008/3/7 人事

www.atmarkit.co.jp

ワークスアプリケーションズのいまの基本方針は優秀な人材は数の限度を設けずに「すべて採る」(小河原氏)ということ。そのためにはIT業界の外からも人材を求める。同社はIT未経験者を対象にした採用活動「問題解決能力発掘プログラム」を実施している。IT業務は未経験でも、“地頭”のよい若手を募集し、5カ月の特訓で同社のコンサルタントや研究開発エンジニアに育て上げる。

この「すべて採る」という方針が、記事冒頭の2018年6月期に7,000人の社員数まで膨張していることは明らかだと思います。

 

2009/1/23 ビジネスモデル

japan.zdnet.com

ワークスの場合、製品の作り方がユニークだ。COMPANYでは基本的に個別のカスタマイズを行わない。顧客のニーズは汎用化した上で、標準機能に取り込んでいく独特のやり方をとる。宮越氏は「パッケージの標準機能としてお使いいただく。ニーズを汎用化し、標準機能にするのは、当社の開発陣にとっては困難なことだが、それが当社の価値だ」と話す。

ワークスを語るときに外せないのがCOMPANYという製品です。日本のSIがフルスクラッチ・カスタマイズありきの常識の中で、ノンカスタマイズのパッケージソフトウェアビジネスを立ち上げました。

お客様目線で言えば、COMPANY利用中で保守料さえ支払えば、どんな機能変更が起こっても定額保守内でやってくれると思うに違いありません。他ベンダーから見ればどうやったら採算が取れるのか不思議だったはずです。

 

2010年~2014年までの記事から

2010/10/26 人材戦略

mag.executive.itmedia.co.jp

内容の濃い記事であり引用は控えます。

とにかく課題解決型の人材を登用し、イノベーションを最も重要視し、チャレンジした結果失敗に終わっても責任を問わないということだと思います。

下記は個人的な感想です。

社員が数千人となると、イノベーション志向は乏しくても、調整型/業務遂行型の人材は特に必要になると思います。これを軽視すると、タイプの違うイノベーションが混在してしまったときに摩擦が起こりマイナスのエネルギーが生まれます。勝ち負けということにまで発展し、優秀だった人材が退職していくというシナリオも生まれます。戻ってきてほしいという制度をいくら作っても、戻る隙間もないと思われます。

私個人はイノベーション志向が強いので大きな組織が合わないと思っていて、仮に数千人もイノベーターが同居してしまい調整型がいないとすると、やむなく誰かが調整役にならねばならず、本来は業務に対する課題解決をしたいのに、顧客と自社、自社の組織間、部門の担当者間での調整に追われ・・嫌になってしまうということが起きるのではないかと想像しますがいかがでしょうか。

 

2012/9/13 クラウド(IaaS)対応

japan.zdnet.com

ワークスアプリケーションズは9月13日、IaaS/PaaS「Amazon Web Services(AWS)」上で同社の統合基幹業務システム(ERP)パッケージ「COMPANY」を稼働、運用するサービス「COMPANY on Cloud Managed Service(CCMS)」を発表した。9月下旬から提供する。

 2012年の段階でAWSでビジネスインするというのは、かなり素早い対応だと思います。ここに来てのAWSの隆盛はご存知の通りです。

 

2014/10/8 SaaS対応

tech.nikkeibp.co.jp

ワークスアプリケーションズは2014年10月7日、同社が開催したイベント「COMPANY Forum 2014」で、SaaS(ソフトウエア・アズ・ア・サービス)型ERP(統合基幹業務システム)「HUE(ヒュー)」を発表した。2015年春に販売を始め、2015年中に提供を開始する。牧野正幸代表取締役CEO(最高経営責任者)は、「HUEはこれまでのERPの常識を創造的に破壊する、全く新しいERPだ」と語った(写真)。

長期に記事を追っていると、どうもこのHUEというプロダクトに相当な投資をしていることがわかります。HUEの登場を機に経営に対するネガティブな記事が出るようになっていることから、ここは大きなポイントとなると思います。

下記は個人的な感想で根拠はありません。

新規ビジネスを立ち上げる決断をした時点で、優秀なエンジニアがHUEに流れた可能性があると思われます。しかし、主力パッケージCOMPANY自体が、定期保守の中で顧客の希望をパッケージに取り入れるというモデルであるため、この維持が立ち行かなくなりトラブルが続発したのではないかというのが私の推理です。

定期保守による定期収入を基本としたストックビジネスを会社の基盤であるとした時点で、このストックビジネスに対応するコア人材は絶対に手放してはいけないと思います。もともとイノベーション体質の人材ばかりだとすると、優秀なエンジニアがHUEに偏ったのは想像に難くありません。

なお、繰り返しますが勝手な想像です。

 

2015年~現在までの記事から

2015/2/11 HUEとクラウドネイティブ

japan.zdnet.com

代表取締役最高経営責任者(CEO)の牧野正幸氏は、HUEについてERPパッケージをSaaS対応にしたものではなく、「ゼロから作り直している」と説明。“SaaS型ERP”や“クラウドERP”ではなく、“クラウドネイティブ”なエンタープライズアプリケーションという言葉でHUEの立ち位置を表現している。

内容の通り、一から作り直したとすると相当な投資をしたことがわかります。

 

2015/12/11 AI

japan.zdnet.com

代表取締役で最高経営責任者(CEO)の牧野正幸氏は、「完全に分業化している企業は違うかもしれないが、経営層の仕事でもスプレッドシートに入力し、分析といった、経営判断とは異なる業務はたくさん残っている。こうした業務が人工知能によって自動化されれば、仕事の50%は省力化されるのではないか」とERPに人工知能を組み込むことで、業務効率が大幅に改善されると説明した。

さすがイノベーションをコアビジョンにするだけあって、2015年の時期にAIを取り入れようとすることは称賛されるべきだと思います。

実際におっしゃっていることは、のちのRPAにつながっていますし、また、AIにおいては2019年になってもまだまだビジネスになっていないのが現実です。先見の明はあったものの、資源を投入するにはまだまだ様々な壁が大きく、現場は困難を極めたのが想像できます。もし、本格開発するのが今だったら結果は違ったのかもしれません。

Google Glassですら、失敗の扱いを受けていますから、どれだけイノベーションを成功させるのが難しいかということを暗示している気がします。

news.yahoo.co.jp

 

2017/6/4 ぶれない人材採用方針

style.nikkei.com

多くの日系企業が海外の優秀な人材獲得に苦戦するなか、アジア圏を中心に多くの大学新卒者の採用に成功してきたワークスアプリケーションズ。2016年度も中国やインドの有力大学を出た理系の学生たちが入社した。米シリコンバレーのIT企業幹部にはインド工科大学(IIT)出身が多い。アジアのエリート大学の学生がワークスアプリを選ぶ理由のひとつは、若いうちから能力を伸ばせる機会が多く、将来のキャリアアップの「踏み台」になり得ることだという。米グーグルやアマゾンとの人材獲得競争に挑む牧野正幸最高経営責任者(CEO)に聞いた。

人材採用に関する姿勢は、当初から全く変わりませんよね。

 

2017/10/10 訴訟

it.impressbm.co.jp

日本のERPシステム大手であるワークスアプリケーションズ(ワークスAP、牧野正幸CEO)に関して、気になる話がある。2017年5月に兼松エレクトロニクスがワークスAPに対して14億円強の賠償を求めて訴訟を提起したこと、それに予約購読制の情報誌「FACTA」が2017年10月号に掲載した「業務ソフト大手『ワークスアプリ』が視界不良」と題する記事だ。ワークスAPに何かが起きているのか。実際のところはどうなのか─。牧野CEOを直撃した。

対外的に潮目が変わったのはFACTAの記事からです。本記事では財務面についての内容が主ですが、システムエンジニア目線で言えばプロジェクトにおいてテストフェーズに入る合意が顧客と取れないほどの混乱が生じていたことが大事だと思います。

なお、HUEではなくCOMPANYの問題です。

 

2017/11/11 火消し

style.nikkei.com

最近、一部で当社の「資金調達がうまくいっていないのではないか」という趣旨の報道がありました。社員と顧客には、すぐに説明しましたが、銀行やファンドとの守秘義務があり、すべては明らかにできなかった。非常に申し訳ない思いでした。私に限らず、経営者は、じっと我慢し、時機を待つなかで、自分だけで抱えなければならない事柄も多いはずです。

日経が火消しに協力したような形になっている記事です。

 

2017/12/25 財務増強

tech.nikkeibp.co.jp

日本とシンガポールに拠点を置く投資会社ACAグループから50億円の出資を2017年10月に受けたワークスアプリケーションズ。それまでワークスアプリケーションズについては、「財務基盤に不安あり」との報道も流れていた。ERPパッケージを手掛ける同社のCEO(最高経営責任者)を務める牧野正幸氏に真相を聞いた。 

私もこの時点で、とりあえずの急場はしのぎ切ったとみていました。

 

2018/11/6 さらなる訴訟

www.nikkei.com

古河電気工業は2018年11月6日、同社と同社の子会社である古河ASがワークスアプリケーションズに対して訴訟を提起したと発表した。損害賠償金として50億4644万3971円の支払いを求めている。

古河電工の発表によると、同社と古河ASは2016年に基幹系システムの構築プロジェクトをワークスアプリケーションズに発注。しかしプロジェクトに遅延が発生し、本稼働予定日までにシステムが完成しないことが判明し、契約を解除。支払い済みの代金の返還などを求めて提訴したとしている。

こちらは既報の通りです。

 

2018/11/7 財務面の記事

kabu-press.com

かつて日本を代表するベンチャー企業として知られていたワークスアプリケーションズ。上場していましたが、2011年にファンドの支援を受けてMBOを行い非上場化していますが、2018年6月期に180億円の赤字の計上が官報で判明しました。

数字はうそをつかないというか・・。総資産519億に対し株式資本が26億。ここから、冒頭の記事に返るということになります。

ACAが株式を手放すと同時に、どこか別の投資会社が引き受けつつ資本増強することで安定化する・・のかはわかりませんがそのような筋書きが現実的だと思います。

 

まとめ

世の中の新規事業のほとんどが失敗に終わる中で、売上400億クラスまで手を広げており学ぶべきところは多い事例だと思っています。

イノベーションは成長のためには必須ですが、それだけでは企業は持続しないことを学びました。未来をどうするかも大事ですが、今をどうするかも同じだけ大事だということです。財務的に重要な局面であることはわかりますが、ワークスアプリケーションズのプロダクトを現在も利用している企業数も多く、現場は立ち止まることはできないはずです。今後のかじ取りに注目していきたいと思います。

 

Windows Subsystem for Linux(WSL)でやってみたいことメモ

f:id:orangeitems:20190114013420j:plain

 

構想メモ

Windows Subsystem for Linux(WSL)の昔の記事などを探ると、登場時はいろいろと問題があったようですね。最近WSL + Ubuntu + Dockerがまともに動くことがわかったので、時間があるときにいろいろやってみたいと思っています。

 

やってみたいことリスト

CentOS7のコンテナを入れてまともに動くかテスト

これ普通に動いたら、仕事で活躍しそう。WSLにおいては今UbuntuかSuseしか実質選べないのですが、Fedora待たなくてもDocker使えばCentOS動いちゃうんじゃないかと。本来はコンテナはできるだけ軽量化して1プロセスのために使うのが基本なのですが、むしろオンプレを詰め込んでみて、どれだけWSLで動けるか試してみたいです。

 

イメージを作ってみる

まだ時間が取れてなくて、docker run hello-worldしか試していないわけですが、イメージをいろいろ作って実用に足るか確認してみたいです。ここ最近、こういう人柱的なシナリオがなくなっていたので、オイラワクワクしてきたぞ。

 

WindowsのCドライブのディレクトリーを永続ストレージとしてマウントしてコンテナを起動してみる

これできると、もはや開発環境になると思いますし、開発用Linuxサーバーがいらなくなるんじゃないかという予感。ドキュメント入れ替えをWindowsローカルからエクスプローラでやるという・・。なお、普通に/mnt/c/temp直下にシンボリックリンク張ればいいだけのような気もする。

 

WordPressをコンテナで動かして、どれくらいメモリ使うか確認する

MySQLとapache+PHPでどれだけローカルのメモリを消費するか。軽量でかつ動くんだったら開発環境としては最優秀では。

 

crontabでバッチができるか

WSLはbashがwindowsで動くだけという先入観があったのですが、実はもうlinuxそのものなんじゃないかという気がしたのでテストしてみたい。特にcentosのコンテナで動かせればなんでもできる気がする(本来のコンテナによるマイクロサービスに触れる前に、普通のlinuxとして操ってみたい)。

 

多分にサポート外だけど、開発環境構築が発展しそうな発想

Windows 10にHyper-V入れてCentOS入れて、そこにapache + php + mysql/postgresql的な開発環境構成って多いと思うのですが、いかんせんメモリ食いで。とはいえ、WSLは純粋なLinuxではないわけだし、サーバーとしてはMicrosoftも使ってほしくないでしょうから何やらあるんだろうと思ってはいます。まあでも、ダメならダメだったと報告するのも味があるし、世の中の役には立つかなと・・。

今現在休日進行中で時間が取れないのですが、目標ができてブログ的には少し面白くなってきました。パソコン好きとしてはサーバーサイドに特化したKubernetesより身近ですし壊れてもいいかなという気軽さがあります。

お楽しみに。

 

追記

情報収集ベースでは、WSLではiptablesがサポートされていないことで、Docker Composeが使えなくて困る、という話があるようです。

海外の情報も見つつ、実際に試しながら、最終的な結論を出していきたいと思います。

 

追記2

私のデスクトップで試しているようですが、docker composeはどうしてもiptablesで失敗しますね・・。

$ sudo docker-compose up
Creating network "composetest_default" with the default driver
ERROR: Failed to Setup IP tables: Unable to enable NAT rule: (iptables failed: iptables --wait -t nat -I POSTROUTING -s 172.23.0.0/16 ! -o br-ce8c212419c2 -j MASQUERADE: iptables: No chain/target/match by that name.
(exit status 1))

WSL自体はLinuxカーネルで動いていないので、iptables等のネットワーク系のコマンドがまだまともに動かないことが原因のようです。2018 October Update(バージョン1709)および、Ubuntu 18.04LTSの組み合わせでかつapt-get upgradeもやってみたのですが無駄でした・・。本件の結果報告は、状況が変わってからになりそうで時間がかかると思います。何かいい方法があればいいけれど・・。