資産公開10/18、auカブコム証券で15,000ポイント貰える

42歳のリアルとして資産を公開してみる。

元本 : 5,377,096 (先週差分 +7,320)
資産 : 6,116,935 (先週差分 +185,600)

口座銘柄評価額評価損益
特定口座eMAXIS Slim 米国株式(S&P500)1,752,560+263,076
特定口座iFreeレバレッジ NASDAQ1003,213,629+363,629
つみたてNISAeMAXIS Slim 先進国株式インデックス647,865+75,465
つみたてNISAeMAXIS Slim 新興国株式インデックス502,881+37,669

米国大統領選挙前で相場が荒くけっこう乱高下をしている感じ。長期投資を前提にしているので日々の株価変動とかは気にしないことにしているのだけど、一週間に18万円とか変動している事実を考えると、なんだか節約とか仕事とかってどうなのよ?とか思ってくる。まあとりあえずあまり気にせず種銭を増やすようにしていこう。

 

さて、種銭といえば、auカブコム証券のキャンペーンがあるとのこと。

https://kabu.com/company/lp/lp100.html

前にauポイントとPontaポイントとの統合があったが、その流れで、Pontaポイントで投資信託を買えるようにしたとのことだ。その新サービスのキャンペーンとして、11月末までに口座開設して12月末までに投資信託を買うと、最大15,000ポイントが貰える(色々条件あり。15,000ポイントもらうには50万円必要)。モッピーとかのポイントサイト経由で口座開設すればさらに5,000ポイントくらい加算できる。現金余力があり投資信託の長期投資をしている方は、いずれ入金するのだし、約2万ポイントを貰っておいて損はないだろう。僕もさっそく口座開設を申し込んでみた。

キャンペーンは置いておいて、Pontaポイントで投資信託が買えるようになるのは良いことだ。僕はお仕事の関係もあって格安SIMではなくauを使っている。すると長期優待だのauPayだのなんだので知らぬまにPontaポイントが溜まってくるが、どうにも使う場所ないよなーと思って放置していた。しかし、それで投資信託が買えるならバンザイだ。欲を言えば、楽天証券のように投資信託購入にポイントが付くようになると理想。

まあとりあえずくれるなら貰っておこう。

おわり。

体重公開10/17、毎日飲みながらでも痩せる食事

42歳のリアルとして体重を公開してみる。

今週の体重先週差分トータル
85.8kg-1.35kg-5.45kg

一週間で1kg以上減るならいいペースだろう。健康診断までおよそ2ヶ月あるので、そこまでに80kg切れるとうれしいな。

 

さて、ダイエットで重要なことといえば何を差し置いても食事だ。むかしダイエットしたときは、朝昼晩の工夫うんぬんとかいうレベルではなく、食事らしいものは月一回程度、それ以外はプロテインとビタミン剤だけで過ごしていた。んで、4ヶ月で30kgくらい痩せたと思う。人間、そんな食生活でも意外と生きていけるらしい。まったくオススメできないけど。

痩せたいとは思うけど、さすがにそんなダイエットもどうかと思って。今回はちゃんと食事を摂るようにしている。というか、毎日お腹いっぱいにしつつお酒ものんでいる。

で、そんなゆるふわダイエットにはどんな食事が良いかな?といろいろ試してみたところ、最近、すごくいいものを見つけて定期的に購入しはじめた。

こいつは低糖質の冷凍お弁当。糖質量は15g以下。7個と14個と21個セットがあり、21個セットで買うと一食500円を切るくらいの値段だ。まあコンビニ弁当を食べると考えればいいだろう。

この冷凍お弁当のいいところはメニューが豊富なところ。なんのかんのいって、毎日同じものを食べつづけるのは飽きてしまう。とはいっても、糖質量を気にしつつ、毎日メニューを考えるのは脳が疲れる。そんななか、何も考えず冷凍庫から出して温めるだけで、毎日違う糖質制限食が食べられるのはとてもラクちんだ。味もふつうに美味しい。最近はこの冷凍お弁当をおつまみにお酒を飲むことが多い。

ただ若干、量が少ないかな?とは思うので、どうしても満足できないとき用の低糖質ツマミをもろもろ物色中。オススメが知りたい。いまは業務用シーチキンを試行中で、糖質は100gあたり0.2g。業務用なので一袋がギャグみたいな量だ。

お酒飲みながらでも痩せたい人の参考になれば。

おわり。

EAの功罪-3 EAは桃源郷を語る

昨今、DX(デジタル・トランスフォーメーション)という言葉が賑わっているが、実は過去にも似たようなデジタル化の潮流があった。いま思い出すのも恐ろしい、そして、もう二度と関わり合いたくないEA(Enterprise Architecture)である。

先般、EAというIT開発方法論の概要を述べ、こと日本企業においては組織力学が働くことからなかなか理想通りには行かないことをお話した。
EAの功罪-1 理想のIT開発論とその現実 - 新鮮?
EAの功罪-2 地獄への道は善意で舗装されている - 新鮮?

今回はEAの功罪として功の部分、EAの良い部分に触れてみたいと思う。

EAは企業全体のウォーターフォール開発

EAは理想であって実際に適用するのは難しい。しかしながら、世界でも有数の天才たちが考え抜いた結晶だけあって、やはり有用な部分は多数ある。というより、いまでもなおIT開発の教科書としてこれ以上のものはないのではないだろうか。

とりわけ有用なのは「EAフレームワーク」だ。これを知っているだけでも違う。

EAでは、最上流フレームワークとして、複雑系である「業務とIT」を4つのレイヤで表現している。結構シンプルだ。各レイヤの詳細だったり具体的な成果物だったりは参考書籍をみたりググったりしてみればよいが端的には下記の通り。

#レイヤ代表的成果物
1業務 Business Architectureミッション、業務一覧、業務フロー
2データ Data ArchitectureERD/CRUD、データディクショナリ、コード表
3機能 Application Architecture機能マップ、機能要件、IT間連携
4技術 Technology Architecture非機能要件、採用プロダクト標準

業務プロセスを整理し、扱うデータを決め、機能要件や非機能要件を定義する。

こう書いてみると「普通の考え方」じゃん?と思うかもしれない。

そう、普通の考え方だ。

EAの基本的な立て付けは、個別IT開発における「普通の考え方」を会社全体のレベルにまで拡張し、複数ITが混在する環境においても適用してやろうぜ、ということだ。僕の理解では、EAは企業全体のウォーターフォール開発と解釈している。

EAは桃源郷を語る

さて、この「普通の考え方」というのがとても重要だ。

実際のところ、あなたの会社は普通でないことになっている。

たとえば、あなたの会社に「唯一の業務一覧ドキュメント」はあるだろうか。営業・開発・生産・調達・運用・人事・総務などたくさんの業務機能について、すべての業務フローを一元的に集約管理し、誰でも参照可能にしているだろうか。他部署の工夫を自部署に取り入れて組織力をあげる仕組みがあるだろうか。

たとえば、あなたの会社に「唯一のデータモデル(ERD/CRUD)」はあるだろうか。業務の変更にあわせてリアルタイムに更新しているだろうか。「顧客ID」と「お客様番号」と「得意先コード」が混在してたりはしないだろうか。

たとえば、あなたの会社では複数のITの画面構成は一定のルールに基づいているだろうか。あるITではメニューが横にあったり、他のITではメニューが縦にあったりしないだろうか。

データ可視化ツール(Tableau, PowerBI, QlikSenseなど)を無秩序に導入していないだろうか。Java, C#, Pythonなどプログラミング言語に採用基準はあるだろうか。Oracle, MySQL, MS SQL ServerなどをSIerのいいなりで導入していないだろうか。Zabbix, JP1, OpenView, Systemwakerなどが乱立していないだろうか。

 

もしも、だ。

企業全体で、業務・データ・機能・技術を一元的に統制管理できたらどうだろうか。

誰でも適切な業務ができるし、ITの画面ポリシーはすべて同じで使い勝手が良い。開発工数も少ないし、集中購買によって調達価格を下げるとこともできる。運用面で見ても扱うミドルウェアが少なければ効率的だし、ナレッジが溜まりやすいので人材育成も容易だろう。その結果、企業全体として品質・費用・納期ともに大きく改善するのではないだろうか。

EAはこうした桃源郷を語る。

経営層がコンサルに説得されるのも無理もないだろう。

たしかにこの「普通の考え方」が実現できるなら、業務とITのムリ・ムダ・ムラがなくなる。ムダな業務フローはなくなり、法外なIT開発費を支払わずに済む。それはすなわち、莫大な利益を目論むことができる。

まあ、すなわちウォーターフォール開発だ。

もしユーザニーズや市場動向などが変わらず、完全に数年後の未来予知ができて、ユーザが未来の業務プロセスをキッチリ決められるなら。そんな仮定が成立すれば、言うまでもなくウォーターフォール開発は理想的な開発手法だ。それと同じように、EAもやはり理想的な業務とITの最適化方法なのだ。

 

そしてDXにもつながる重要な点は、このレイヤの順番にある。

ちょっと長くなったので別エントリで話そう。

つづく。

好きなことだけして生きてくと決めたの

42歳のリーマンに刺さった漫画・アニメを紹介しよう。

40歳は不惑の年と言われる。不惑とは「人生の方向性が定まり迷いがなくなる」ということらしい。つまり、40歳になったら人生の迷いがなくなるとのことだ。

え、いや、全くそんなコトなく、毎日「さて、これからどうやって生きていこうか・・・」なんて考えふけってしまうのだが、僕は異端なのだろうか。。。

まあ、なんにしろ世知辛い世の中だ。

DXだのデジタル化だのいわれるが、結局、会社に行って給与を貰わないと生きていけない。これだけ機械化とか人工知能化とかが進んでいるのなら、そろそろ全人類が「労働」から開放されてもいいんじゃないの?仕事なんてエンタメだけでいいんじゃないの?と思うが、全然そんなことにはならない。むしろ、残業は増え、税金は上がり、牛丼は高くなり、ポリコネで言いたいことも言えない世の中だ。

そんな荒廃した気分のときには、ガブリールドロップアウトをみると癒やされる。

alu.jp

ガブリールドロップアウトは、天使がネトゲにはまってしまい、堕天使ではなく「駄」天使になる話だ。このダメダメな感じが「あー、一年中寝てたいわー」なんて思っている僕と妙にシンクロする。

この作品の魅力は、ただダメなだけではなく、元々は最優秀の天使という点だろう。ホントはできるのに、ホントはすごいのに、でもダメになって好きなことだけして生きていく。

そこが、なんというか。少年時代に思い描いていた全能感。自分はホントはすごいんだ、この世界の主人公なんだというヒロイズム。それが歳を追うごとに「結局、何者にもなれない」を自覚していく感じ。そんな全能感が絶望感に上書きされていく感覚を薄めてくれるのに、この作品は役に立つ。

不惑とはすなわち、自分は何者にもなれないと納得することなのだろう。

そんな不惑に折り合いのつかないときはこの作品を観るのがいい。漫画もアニメもあるが、OP/EDが秀逸なのでアニメがよいだろう。僕はU-NEXTで見ている。
U-NEXT (31日間無料)

「あー、ネトゲだけしてたいわー♪あー、人類滅びないかなー♪」

おわり。

パワポは世界を変える

はてなブログで「タグ機能」がリリースされたそうな。タグ機能というと、Noteみたいな感じを目指しているのだろうか。だとすれば、近い将来、同じタグをつけている記事を自動でリコメンドする機能などもきっと実装されるのだろう。はてなブログは記事と記事との間のリンクがあまりなく、はてな内を周遊することがほとんどないので、今回の機能拡張はいい感じだなと思う。

さて、そんなタグ機能で初回のお題がいくつか出されている。

そこで今回は「#エンジニアのキャリア」について書いてみようと思う。

結論から言えば、パワポエンジニアはオススメだよ。という感じである。

つまみ食いのエンジニアキャリア

まず僕のエンジニアのキャリアを話したいと思う。

最初のエンジニアライフは学生時代。C++をイジって、電磁場シミュレーションやデータ圧縮アルゴリズムの符号化効率などの数値計算をしていた。泣きながらC++をデバックしてたときに「ああ、プログラミングで食べていくのは無理だな」と感じたので、ガチなプログラマではなく適当な企業の技術職として就職することになる。

就職後、いろいろな仕事をした。一番長かったのは、社内で使う業務ITの丸投げ開発で、その後、内製開発に風向きが変わり、Ruby on RailsやSalesforceあたりを導入して、プログラミングで遊んでいた。

その頃は、アジャイル開発だったりクラウド環境だったりの黎明期。ウォータフォール&オンプレミスの考え方との違いに驚き、毎日新しい発見があった。過去、稟議だの工事だのWBSだのプロジェクト計画だのいって、都合3ヶ月以上掛かけていたモノと同様のモノが、たった一日で作れるようになる楽しい時代だ。

でも、楽しい時代も長くは続かず。データ論理設計やSQLができるということから、なぜだかDBAをやらされる羽目になる。いや、僕はどちらかというとフロント寄りのエンジニアでHTML/CSS/JSをイジっているのが好きなんだけど(笑)

全然スキルセット違うだろと思いつつも、上から見たら「同じデータベースじゃん?」ということらしい。しかたなくDBAをやりつつ、インフラ系エンジニアの保守的な気風にイライラしながらも、いちおう真面目に仕事をしていた。趣味的に、Oracle Exadataを入れてみたり、MySQL InnoDB Clusterを組んでみたりもした。

んで、いまは業務部門に移り、戦略策定だったり、DX推進だったり、社内の人材育成だったりといったフワフワした仕事をしている。

振り返ってみると、オンプレとクラウド、ウォータフォールとアジャイル、丸投げと内製開発、フロントとインフラ、業務とIT、コーダーとPMと戦略屋と、つまみ食いも甚だしい。我ながらよくゲシュタルト崩壊を起こさないで済んだものだと思う(笑)

そんなキャリアの中でも一貫して有用だったのは「パワポ」だ。

パワポは世界を変える

エンジニア界隈では、コードを書かずにパワポばかり書いているエンジニアのことを「パワポエンジニア」などと揶揄する。絵だけ書いたってモノは動かねーんだよ!ってのはまったくそのとおりで反論のしようもない。

実際、僕も一時期は「このままパワポ書いてていいのかな」とか、「エンジニアはコードを書いてなんぼなんじゃ」とか思ったことはあるけど、なんかもう諦めた(笑)

しかし、諦めたあとで見えてきた世界がある。

実際のところ世の中はパワポで回っているのだ。

パワポにはコード以上の「魔法」があるのかもしれない。

何かしらのプロジェクトの前にはパワポがある。あなたがITエンジニアであれば、あなたの作っているITは、ひとつのパワポ資料から始まっている。ITエンジニアでなくても、身の回りのあらゆる商品、マウスもスマホもテレビもダンベルも冷蔵庫も食品もなにもかもパワポで企画しているのだろう。

さらにより大きなこと。国家戦略だったり都市計画だったり税制改革だったり。そしてなにより、DXなんて不可思議な言葉が一般市民でも聞いたことがあるワードになったのは経済産業省のパワポ資料が一因だ。

www.meti.go.jp

そういえばひとときパワポ排除論が巻き起こったことがある。いわく、オフィスワーカーはパワポばかり書いていて仕事をしていない。資料は出来上がっているのに、色を変えたり配置を変えたりして遊んでいるだけだ、と。その遊びでアウトプットが変わるのか、営業であれば成約の可否に関係するのか、もし関係しないなら不要な業務ではないのか。不要な業務を助長しているパワポは悪の枢軸で、社会から抹殺すべきだ。なんて感じ。

だが実際はなくなっていない。

パワポ排除の急先鋒であるAmazonですら、AWSイベントではパワポだらけだ。

結局、文章で伝えるよりも図解で伝えるほうがわかりやすいのだろう。

道路標識や信号がすべて言葉だったとしたら事故が起こるだろう。「総武線は三鷹から始まり吉祥寺を通り〜、またそれと並行して中央線が走っています。相互の乗り換えができるのは〇〇駅と○○駅となります。」とかをだらだら読むのではなく、やっぱり電車の路線図がみたい。

そんなわけで、僕はこれからもパワポを書いていくのだろう。

もしかしたらブログもパワポで書けば良いのかも。

おわり。

技術よりも人間力が大事だそうな

10月01日、東京証券取引所の株式売買システムであるarrowheadが故障し、株取引が丸一日できなくなったとのことだ。原因はストレージサーバに搭載しているメモリのハードウェア故障。本来、待機系の機械に切り替わるはずが、設定ミスにより切り替わりができなかったとのこと。

まあ、あるある。

永久に壊れない機械はないので故障は避けられない。避けられないので、壊れたら違う機械に処理を逃がす仕組みを入れている。こういった仕組みをフェイルオーバという。このフェイルオーバは、なぜだか、どれだけ試験をしてもイザというときにキチンと動かない。僕自身、それで過去に何度も痛い目にあった(笑)

 

さて、そんな東証の障害に対してどこかの議員が「サーバー型ではなくシステムのブロックチェーン化など分散化を進める必要もあると思う。」とツイートしたらしい。

ブロックチェーンとは分散管理台帳技術のひとつ。ビットコインを実現している基礎技術として有名だ。理論的にデータを改ざんすることができないことや、地球が滅びない限り、まず停止することがないといった特徴がある。

そんなツイートへの反応は予想通り炎上していた(笑)

ちょっと技術に詳しい方は知っている話だが、ブロックチェーンは性能が出ない。僕の記憶が正しければデータ更新が完了するまでに10秒くらいかかったはず。一方で、東証で必要な性能は処理あたり1ミリ秒以下だろう。大体、数万とか数十万倍くらい性能が足りないので、東証でブロックチェーンを使うのは荒唐無稽で無茶苦茶な話だ。

 

それで、国会議員に基本的な技術リテラシーが足りないのはいかがなものか、などという罵詈雑言を書き散らかしてもいいのだけれど、いい大人なのでやめておこう。どちらかというと、このエントリで言いたいことは「これは国会議員だけの話に留まらない」ということだ。

日本の商慣習として、IT開発は、ITを入れたい企業がITを作る専門企業に発注することが多い。ITを入れたい企業のことを「ユーザ企業」、ITを作る専門企業のことを「SIer」(システムインテグレーター)などと呼ぶ。代表的なSIerとしては、NTTデータ、IBM、NEC、それにarrowheadを構築した富士通などがある。

僕自身はユーザ企業に所属しているのだが、このユーザ企業の技術リテラシーは極めて低い。正確に言えば、ユーザ企業にも情報システム部門などがあり、技術リテラシーが高い方はたくさんいる。しかし、そもそも「ITを入れよう!」と企画する事業部門側は、「ブロックチェーン?なにそれ?初耳??」といった動物園状態だ。

そんな動物園状態の部門が「DXを推進するんだ!」などと叫ぶ。

まあことごとく失敗するのは明らかだろう。

じゃあ、事業部門も技術的リテラシーだったり、技術的審美感をつければいいとおもうじゃん。んで、そう言ったら、技術なんて知らなくてもよくて「人間力」が大事なんだそうな。

DXに至る道は険しい。

おわり。

EAの功罪-2 地獄への道は善意で舗装されている

昨今、DX(デジタル・トランスフォーメーション)という言葉が賑わっているが、実は過去にも似たようなデジタル化の潮流があった。いま思い出すのも恐ろしい、そして、もう二度と関わり合いたくないEA(Enterprise Architecture)である。

前回、EAというIT開発方法論の概要を述べ、砂上楼閣で対艦巨砲的なプロジェクトが何故か実施にまで進んでしまうお話をした。
EAの功罪-1 理想のIT開発論とその現実 - 新鮮?

今回はそのつづきの「EA 開始後の顛末」を話そう。

EA 開始後の顛末

さて、絵に描いた餅のEA計画にGOサインが出るとどうなるだろうか。

まず経営層からの指示にもとづき業務部門とIT部門との間で「EA推進会議(仮称)」なる定例会議が設けられる。そして、第1回EA推進会議の冒頭、IT部門より次のことが伝えられる。

  • いまのITを全面刷新する
  • いまのあなたの仕事は全然ダメなので全て見直すこと
  • いままであなたが作ったエクセルを全面廃棄すること
  • いままであなたが作った業務マニュアルを全面刷新すること
  • ローンチ後、あなたの部署の人員を半分にすること
  • 以上は社長がコミットした事項である

花形の自部署が、コストセンターのIT部門から因縁をつけられたのだ。こいつらを食わせているのは自分たちなのに、一体全体、何をトチ狂っているのか。場の空気は怒り・呆れ・哀れみ・悲しみが支配していき、ひとときの沈黙のあと「ひとまず持ち帰る」で会議は終わる。

そして第2回EA推進会議。業務部門から次の要件が出される。

  • 既存の業務フローを一切変えないITとすること
  • 新規ITの画面構成は既存ITから一切変えないこと
  • エクセルを破棄するときは、その全てをITで実現すること
  • 業務マニュアルの刷新はIT部門が全て行うこと
  • 業務部門の人員削減は一切認めない
  • 別途取りまとめる既存ITへの改修要求一式を漏れなく実施すること

さあ、楽しいデスマーチの始まりだ。

経営層からのGOが出たことを契機にホントのキーマンがアサインされる。そして、いままで理想として描いていたピカピカの業務フローの欠陥が次々と明らかになっていく。業界の商慣習・法令遵守、部門間の政治的力関係、業務部門のアウトソース戦略・中期数値目標との整合性、機器調達先との契約条件、ユーザのIT操作ロケーション。そして何より、数千人に及ぶ関係者の納得感を醸成することやカルチャー変革を促すことが困難を極めるなど。仕様変更を抑制しようにも不可避な課題がでてしまう。

しかし終わらない夜はない。

数多の仕様変更を取り込みつつもなんとか完成寸前になる。

だが終わりが見えはじめたときでさえ難関が立ちはだかる。既存ITを担当するメンバのモチベーション低下、データ品質の低さから生じるデータ移行の度重なる失敗、移行時の長期ダウンタイムの是非などを通じて、何人もの仲間が志半ばで倒れていった。

結果として、当初予算の2倍以上、2年遅れでローンチした。

IT開発では、「222の法則」とよばれる「計画の2倍の費用と2倍の期間がかかり、計画した2分の1の機能しか実現できない」という法則があるが、まさしくその通りの結果だ。

そして、このデスマーチから生まれたモノが良いモノであればまだ報われもするが、複雑化し、肥大化し、使い勝手が落ち、日々不具合や不足機能が見つかり、そしてそれらの改修にすら莫大な工数がかかる悪夢のようなITに成り下がってしまった。

地獄への道は善意で舗装されている

果たしてコレは何がダメだったのだろうか?

EAが語るIT開発論は理想的かつ常識的で、しかもDXとは異なり、教科書的なガイドライン文献も豊富に準備されていた。海外では多数の採用実績があり成功事例も数しれない。

コンサルは実に優秀で、吸収できるナレッジも多く、本気でユーザ企業を儲けさせようと考えていた。経営層はただただ「儲ける」というミッションに忠実なだけだった。業務部門は荒唐無稽な話に乗らず実利を取った。IT部門は経営層判断に従って死ぬ気で努力した。そして実際にITを開発するSIerは不眠不休で仕様変更に対処した。

誰も失敗を望んでいない。

すべてが善意である。

そう、地獄への道は善意で舗装されている。

多少思想じみていて申し訳ないが、理想の姿を追いかけて現実がダメになるのは、あたかも社会主義のオマージュだ。部署間や役職間で利害関係の不一致がある以上、現実は理想の通りにはいかない。さらに自社以外のステークホルダが絡むとなおさら不可解なことになる。さて、あなたの周りのDXはこんな感じになってないだろうか。

そんなわけでEAは二度と関わり合いたくないが、実のところ良い部分も色々あった。というかデジタル化とかDXとかの根幹に関わるような示唆もたくさんあった。さんざん貶めているような気もするので少しフォローしたいと思う。

長くなったので別エントリで。

つづく。

hiizumix.net

資産公開10/11、S&P495はTOPIXと変わらないらしい

42歳のリアルとして資産を公開してみる。

元本 : 5,369,776 (先週差分 +7,321)
資産 : 5,931,335 (先週差分 +55,114)

口座銘柄評価額評価損益
特定口座eMAXIS Slim 米国株式(S&P500)1,744,216+254,732
特定口座iFreeレバレッジ NASDAQ1003,040,689+190,689
つみたてNISAeMAXIS Slim 先進国株式インデックス644,998+76,598
つみたてNISAeMAXIS Slim 新興国株式インデックス501,432+39,540

トランプ氏のコロナ騒ぎで市場が荒れていたが落ち着きを取り戻してきたようだ。相当ハイリスクに米国インデックスに投資しているので、日本の政治以上にアメリカの政治が気になる今日このごろ。

 

そんな中、すこし衝撃的な記事を読んだので紹介しよう。

www.itmedia.co.jp

S&P500は非常に好調だが、実のところ、GAFAMを除いたS&P495の伸び率はTOPIX(東証株価指数)と殆ど変わらないのだそうだ。つまり、米国株が日本株に比べて総じて好況というわけではないとのことだ。

なるほど。

これはなかなか考えさせられる。

資金効率を考えるなら、S&P500よりもGAFAM個別株への集中投資のほうがよいのではないだろうか。

基本的に、老後資金的なS&P500と、趣味的なNASDAQ100x2でギャンブルをしているポートフォリオなわけだが、どうせギャンブルするならFANG+(Facebook, Amazon, Netflix, Google, + )にするのも面白いのではないかと思った。個別株は脳が疲れるので手を出したくないし。

とはいえ、これらIT系の業界勢力はコロコロ入れ替わる。10年前にはスマホも普及していなかったことを考えると、勢いのある企業を勝手に入れ替えてくれるNASDAQ100のままでもいいかな。まあ、この程度の資産規模なら悩むまえに種銭を増やせって言われそうだけど。笑

おわり。

体重公開10/10、痩せない豚は幻想を捨てろ

42歳のリアルとして体重を公開してみる。

今週の体重先週差分トータル
87.15kg-0.15kg-4.1kg

一時期、86kg台まで落ちたんだけど、昨日の夜あまりにストレスフルだったのでマックで気絶食いをしてしまった。反省はしてないけど、思った以上に数値として現れてビックリだ。

 

さて、いま取り組んでいるダイエット方法を共有しよう。

手法としては、テキーラ村上氏の「痩せない豚は幻想を捨てろ」という本を参考にしている。この書籍は、いままで何度もダイエットに取り組んでも、挫折し諦めてしまうデブ、いや「豚」に向けて書かれたダイエット本だ。

その内容は「確実に痩せるダイエット方法」として「糖質をとるな」と「運動してプロテインを飲め」といったことが書かれているだけで、突飛な方法は一切語られていない。ぶっちゃけただの根性論だ。

だがそこが他のダイエット本とは明らかに一線を画している。サプリで簡単に痩せるとか、ダイエット器具で簡単に痩せるとか、部分痩せができるとか、そういった新しい切り口の話は一切ない。というよりも、そういった甘言に踊らされて、挫折し、お金と時間だけがなくなり、その結果、いまもデブのままなのだろう?と問いかける。

いいだろうか、「ダイエットメソッドはいままでの常識を覆す、新しい切り口で、魔法のようで、そして斬新でなければ読む価値はない」と思っているデブを極めし者こそ、その本を読むべきだ。

 

「こうしたらよい」と主張することは簡単だ。だけど「だからダメなんだ」という示唆を与えてくれる本は少ない。なぜなら人間は誰しも自分が大好きで、自分の考えは正しいと思っている。いままでやってきたことを否定されたくない。うるさい、聞きたくない。そんな主張をする書籍はいらない。商業的に難しいのだろう。

だが、著者は「テキ村式ダイエット ビフォーアフター」で検索してみろと説く。そこにはダイエットに成功した人たちの写真が並ぶ。そして「オレをお前達をこうしたいんだ!」という著者の想いがビシビシと伝わってくる。

ダイエットに必要なのは方法ではなくマインド。そんなことをドSな文体で、デブ、いや豚に刺さる言葉で厳しく教えてくれる本だ。

 

えっと、とりあえずマック食べて反省してます。申し訳ありません。。。

おわり。

EAの功罪-1 理想のIT開発論とその現実

すこし昔の話をしよう。

昨今、DX(デジタル・トランスフォーメーション)という言葉が賑わっているが、実は過去にも似たようなデジタル化の潮流があった。いま思い出すのも恐ろしい、そして、もう二度と関わり合いたくないEA(Enterprise Architecture)である。

EAとはなにか

EAとは「業務とITの最適化」を目指し、企業内のすべての業務とITについて、数年後の「理想姿」をあらかじめ計画したうえでIT化を進めていくべきだ、という考え方である。代表的な適用事例としては米国財務省や国防総省、そして日本の電子政府構築などがある。ある程度の大企業では一度は取り組んだ方法論だろう。

業務のムリ・ムダ・ムラを廃絶し理想的な全社業務フローを描いたうえで、その業務フローに必要十分なITを用意していく。その言葉だけだといい方法論に感じる方もいると思う。むしろ「それが普通なんじゃない?」という感覚だろう。誰でも無駄なものは持ちたくない。加えて言えばIT開発は決して安くない。意外と知られていないのだが、大企業にもなると数十億円・数百億円規模のIT開発プロジェクトも珍しくなかったりする。

そして実際、数年前にEAが流行り(というかコンサルが流行らせ)、「業務のデジタル化を成し遂げ、さらに超絶クソ高いIT開発を必要最小限にできる米国発の方法論」だとの甘言にそそのかされ、トップダウンで導入が推進されていた。

その結果、日本企業でEAが上手くいった事例を僕はほとんど知らない。儲かったのは上手く逃げ切ったコンサルとパッケージベンダだけである。

IT開発の理想と現実

なぜうまくいかないのか。僕の経験で話そう。

まず、IT利用企業は業務とITの理想像を作ることができない。なぜかというと、理想像を描くためには全部署からキーマンを招集する必要があるが、この時点ですでに無理ゲーだ。キーマンは当然のことながら多忙で招集するのは難しいし、仮に招集できたとしてもEA活動に稼働を割くことはできない。すると、なんでこいつ?という方々が集まる。

とはいえ会社からの至上命令なのでそのメンツで計画を練り始めるわけだが、そこはまるで動物園の様相を呈することになる。ゴリラが「こういうフローになったらウチが困る」といえば、ライオンが「そもそもお前の部署の業務品質がゴミだ」といい、キリンが「あのシステムのこの画面が使いづらいんだよねー」という。

そんな楽しいショーが半年ほど続いたあと、コンサルが綺麗なキングファイルを作り上げて経営層に提出する。紋切り型の市場動向・ポジショニング・経営課題を枕詞にして「EA活動により素晴らしい計画ができました。これに従えば○○億円儲かります。」と言葉を添えて。もちろんそのキングファイルには、半年におよぶ議論の内容はほとんど盛り込まれない。実施に向けての継続検討課題一覧が小さい文字で羅列されるだけだ。

動き出した船は止まらない

では、このEA計画は実行されるのだろうか。

実行されないと思うのではないだろうか。

だが困ったことに実行されてしまう。

経営層から見れば、社内の人間は信用できないが社外の人間は信用できる。お高いコンサルができると言っているし、儲かるとも言っている。そしてキレイな資料で自分の悩み事(デジタル化が進まない、IT開発が法外に高い)が見事に表現されている。そこに拒否する理由は一切ない。ん?IT部門が出来ないと言っている?それはオマエラの予算が減るのが怖いだけだろう?

業務部門の部長たちから見れば、プロジェクトに人を出した以上、失敗するとは言えない。仮に失敗したとしてもシステム部門の責任に転嫁できる。EAは素晴らしい成果です。ぜひとも一丸となって推進しましょう!多少の課題はありますが皆で力を合わせて乗り越えていきましょう!私達にはそれができるはずです!

そして悲劇が始まる。

長くなるので一旦切ろう。僕はEAに懐疑的なスタンスだが実は良い部分もある。そしてそれはEA以外のプロジェクトにも使える話になる。DXが喧伝され、今後多数の方がDXに関わっていくだろう。似たような話であるEAについて、その功罪までお話しできればと思う。

つづく。

hiizumix.net