時が止まったシステムを考える～プロになるためのWeb技術入門を読んで思ったこと～

AI、IoT、FinTech、ブロックチェーンなどなど、、

新しい技術、仕組みがどんどん出現している。そのスピードも二次関数的に早くなっている。あるシンクタンク曰く、1億人のユーザを獲得するまでに、

• 電話は75年
• Pockemon Goは1ヵ月

と、900倍早くなった。このデジタルスピードに乗り遅れないために「スピード感を持った経営活動が最重要」であると解説していた。

【図解】コレ1枚でわかる最新ITトレンド [増強改訂版]

その一方で、こんなに技術の進歩が著しいのにシステム開発の現場では、2000年ぐらいから時が止まっているケースが多々ある。

　＜時が止まっていると感じる例＞

• Webサイトはperl
• ジョブはcron管理
• コマンド実行による保守運用
• バージョン管理がエクセル
• Windows XPが現役　etcetc

ここで面白いのが「古いは悪」とは限らないことである。

例えば、売り上げの8割が「実演販売に伴う注文」、残りの2割が「Webページからの注文」の会社があったとする。会社の方針としても、今後も実演販売に注力する予定であり、Web販売にシフトする気はない。ただ、少ないとは言えWeb販売は売り上げの2割を占めているため、おいそれと撤退はできない。

そして、システムのEOLを迎えた。お金が潤沢にあればシステムのリニューアルもできるが、そんな予算はない。経営目線ではいかにお金、時間をかけずにEOLを乗り切るかを考える。その結果、OSやMWをバージョンアップさせ最低限のセキュリティ対策のみをし、システムのつくりはそのまま、ってなるのが至極当然の判断となる。(古いは良のケース)

この場合、ハードウェア観点だとAWSなどのクラウドサービスを利用することで運用保守の効率化、コスト削減が比較的簡単に実現できたりする。問題はソフトウェア観点。例でいうとWeb販売のシステムである。仮にPerlで作られていたとしても、ソースがスパゲッティーだとしても、作り変える予算はないので、OS／各種MWをバージョンアップさせ最低限の動作確認、修正をして「はい、おしまい。」ってなる。時が止まったシステムの完成である。

遠回りしてしまったが、ここで問題提起したいのは「ITの進化のスピードが速すぎて勉強する意味を感じられず、基礎的なことを疎かにしている人が多いこと」である。「時が止まったシステム」は少なくとも向こう20年はなくならないと考えている。そのため「HTTPとは何か、Cookieとは何か、サーブレットとは何か」等の根幹の部分がわかっていないと、障害が発生したらあたふたするし、一部の技術者にずっと頼り続けなければならなくなる。

特に管理業務メインのSEはただただ邪魔な存在になってしまう。有事の際は、上司への報告だけを気にし、まだ原因はまだわからないのか！！一次報告はまだか！！などなど技術者の足を引っ張ることしかできなくなる。たまに気を利かせて「手伝えることはありますか？」って言ってくれる人もいるが、技術力もなければ、知識もないので気持ちだけしか受け取れないケースが多々ある。個人的にはうるさい上位層を黙らせ、技術者が腰を据えて作業ができる環境を作ることが管理SEの最重要任務だと思っているが、、、

一部の技術者に頼らずに、自分でも手を動かせるようにするためにも、Web技術の原理原則はWebシステムに携わる人は理解しておくべきである。（そういった知識を独学で学ばざるを得ないの現状も変えないといけないのだが、、）個人的には「Webを支える技術(山本陽平著／技術評論社)」が学ぶには一番良い本だと思っていた。

Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESS plus)

ネットワークスペシャリストの勉強のために、参考書を探していたら

「プロになるためのWeb技術入門～なぜ、あなたはWebシステムを開発できないのか」って本を見つけた。

「プロになるためのWeb技術入門」 ――なぜ、あなたはWebシステムを開発できないのか

副題が上から目線でかなりイラっとしたが、amazonとかの評価がやたら高いので、買ってみることに。（中古はamazonよりヤフオクの方が安かった）

いざ読んでみると、Web技術の原理原則がわかり易く解説されており、自分自身もかなりいい復習ができた。完全な初心者むけではなく、ある程度Webシステム開発に携わっている人向けになっていて、読んでいて飽きがなかった。

少し長くなってしまったので、具体的にどの辺が良いか、何故良書と思ったのかは次回紹介する。

（副題がもうちょいよかったら、もっと売れる本と思うのは僕だけだろうか・・・）

「プロになるためのWeb技術入門」 ――なぜ、あなたはWebシステムを開発できないのか

【コラム】Fintechとソーシャルレンディング～やらないと損？みんなやってる？～

ここ2~３年「Fintech」って言葉をよく耳にする。「IT×金融」を表しているとのことだが、IT関連業務に従事している身からすると特段目新しいものでもない。はるか昔から金融とITは密接な繋がりがあるからだ。周りの人もIT関連のひとばっかりなので、「Fintech」って言葉がどのくらい流行っているのかがわからないのが残念。。。

FinTechの衝撃

何故「Fintech」に言及したかというと「ソーシャルレンディング」って言葉が自分の中で今ホットであるからだ。実際世に出始めたのは数年前であり、知っている人からすると何を今更と思うかもしれないが。。。（細かい説明はググればたくさんでてくるので割愛するが、ソーシャルレンディングはFintechの一環？とされている。）

余剰資金の投資先としてソーシャルレンディング投資を始めるから自分の中ではアツイ。超低金利の昨今、年利3%以上で運用できるの魅力的。利回りがいい投資先としてJ-reitもあるが、ソーシャルレンディングは価格変動がない商品がほとんどのため、一回投資したら放置できるのもメリットだと思っている。もちろん元本割れのリスクはある。。

いろいろ調べた結果、SBIが運営しているSBI Social Lendingを使用することに。（大手だから安心の理論が通じるかは正直わからないorz....）9月の中旬ごろから年利6.5%の「SBISL不動産バイヤーズローンファンド」が始まるとのことでビビりながら少しだけ投資をすることにした。

前回は初日に投資額に達したらしいので、通勤時間を使って申し込みをしてみることに。9:00申し込み開始であったが、少し出遅れて9:20から申し込み手続きをしたところ、

　サイトが重い、つながらない・・・・・・

まじか。自分が思っている以上にソーシャルレンディングをやっている人がいるのか？？何回かリトライしたけどダメ。気が付いたら募集額の達して申し込みができなくなった。申し込み開始してからわずか1時間の出来事。(;´Д｀)

申し込みできなかったことは残念であったが、わずか1時間で「9億円の資金調達」が完了したことに非常に驚いた。「Fintech」を実感した瞬間であった。今まで、銀行などの金融機関が間に入って資金調達がなされていたが、この仕組みが一企業まで浸透したら、銀行が不要になりそうである。もちろん銀行も黙っていない。仮想通貨を始めたりと取り残されないように新しいことに取り組んでいる。

直近２～３年はそこまでお金の仕組みは変わらなそうであるが、20年後ぐらいにはお金の概念ががらっと変わっているかも。。。

お金の概念が変わったとしてもIT技術の大切さは変わらないはず？だから勉強勉強勉強勉強、、、、利回りの計算しているよりITの勉強した方が投資対効果が良かったりして・・( ﾟДﾟ)( ﾟДﾟ)( ﾟДﾟ)( ﾟДﾟ)( ﾟДﾟ)( ﾟДﾟ)( ﾟДﾟ)( ﾟДﾟ)( ﾟДﾟ)

みんなと幸せになるお金の使い方 「ソーシャルレンディング」という新しい投資のカタチ (角川フォレスタ)

【コラム】システム投資と効果測定～なぜ技術者のモチベーションは上がらないのか～

私の周りだけ？だと思うが、技術者のモチベーション低下が著しい。

建築／製造業の技術者の位置づけがいまいち把握できていないが、IT業界では技術者がいなければ何も始まらない。。。調整役としてのSEは仕様を決めるだけで、その作り手(技術者)がいなければ絵にかいた餅で終わる。

モチベーション3.0 持続する「やる気!」をいかに引き出すか (講談社+α文庫)

作り手のモチベーションが低いと、やらされ仕事になり言われたことしかやらなくなる。明らかに間違った動きだったとしても「そう言われたからやりました。」って平然と言ってのける。逆にモチベーションが高いと、自分の役割を超えて手広くやってくれたりする。（手広くやり過ぎるのは良くないことであるが、、、）

品質強化の手法は多数世の中に存在しているが、個人的には「作り手のモチベーションを上げること」に尽きると考えている。

最近よく聞く不平不満は、

• 自分では全く納得していない不便な仕様を実装しなければならない
• 変なところでケチられていいものが作れない
• 利用されていないのに無駄にメンテナンスする（公共システムで多いパターン）

である。当事者意識を持って仕事をしたとしても、エンドユーザーに還元されるわけでもなく、目標／目的が見いだせないのである。

少しずれているかもしれないが、ぐだぐだなシステムを生み出す一つの要因として「効果測定が十分にできていないこと」があると考えている。

企画フェーズ、RFP作成段階だと投資対効果、数年先の収益などの「予想」を結構パワーを使って考える。どの様にユーザーが増えていくのか、どんなプロモーションをやっていくのかを会社のエース級がひたすら考える。その時に「予想すること」に注力し過ぎて「予想したことが予想通りになっているかを検証する術」の検討が疎かになっていることが多いと感じている。（PDCAのPに注力しすぎて、CのCheckが十分できない状態である。）

Checkが十分に機能しないと効果的なシステム投資ができず、誰かの思い付きのような機能追加、改修をしなければならなくなる。不思議とこのようなシステムは「システムが使われていないことをシステム化して補おうとする」傾向がある。（予算取り／組織内の政治も要因であったりするが。。。）負のスパイラルである。変なシステムもやる気がない技術者が作るので、余計変なシステムができるのである。

効果測定がちゃんとできていれば、

・機能追加ではなくCM／キャンペーンを打ってユーザー数を増やす

　→システム化以外の方法で利用率を上げる。

・ある画面の離脱率だけが高いからその画面だけユーザビリティ―を向上させる

　→ピンポイントで開発する。

・使われていない機能を廃止する（これができていないところがほんとに多い・・）

　→さっさと撤退。メンテナンス費を削減する。

・他のサービスと連携して認知度を向上させる。

　→自前でどうにかするのではなく、他に任せる。

などなど、いろんな選択ができるようになる。

企画時のメンバはサービスインするといなくなることが多い。（悪く言うとやり逃げ）効果測定の方法が十分に検討されないまま、システムを維持するメンバに引き継がれると「これやる意味あるんだっけ？」状態になりモチベーションが上がらない。そうなると考えることを放棄するので、いいものができなくなる。

いろいろ書いたらごちゃごちゃに散らかってしまったが、、、

メンバの仕事に対するモチベーションが上がらなくて困っている人がいたら、「効果測定」ってキーワードで振り返ってみるのはアリ？？？

【新版】動機づける力―モチベーションの理論と実践 (Harvard Business Review Anthology)