山本ゆうごブログ

山本ゆうごの仕事メモ

検索エンジン攻防

ロボット型検索エンジンは、Google以前にもあった。Altavistaや千里眼など実際に使われてはいた。

ただ、ノイズが多く、Yahoo!などのディレクトリ型のポータルがよく使われていた。

ディレクトリ型ポータルサイトはすべてのページを網羅するわけではないが、技術情報ならその技術情報がやりとりされている掲示板の中で検索すれば良い。「過去ログを検索するのがネチケット」「半年ROMってろ」というのが、「ググれカス」が一般的になる前の初心者罵倒ワードだった。

Google他にも、Infoseek、Lycos、excite、Goo、MSNなどの検索エンジンがポータルとして登場した。Yahoo!もディレクトリ型からロボット型にロジックを変えた。

日本で検索エンジンとして残ってるのは、Google,Yahoo!,Bing(マイクロソフト)の3つで、Yahoo!の検索エンジンはGoogleを使ってるので、ほぼGoogleの寡占状態で落ち着いてしまった。

botの登場

インターネットビジネスをしている人にとっては「bot」「ボット」は馴染みのある言葉だろう。改めてここでbotの解説をする。

語源はロボットである。最も有名なbotは、Googlebotだろう。私達が検索エンジンとしてGoogleに訪問して検索をする。検索結果に大量のWebサイトの情報が一覧で表示されるが、リアルタイムに探しているわけではない。予めGooglebotというロボットが、世界中のWebサイトを巡回してデータを取得しているのである。

ロボットと言っても物理的なロボットではない。あくまでただのソフトウェアである。パソコンではなくサーバーと呼ぶ大きくてデータセンターの中にあるコンピューター上で、誰かの指示を受けることなく自律的に各サイトを這うように情報を取得する。この「這うように」というのがポイントで、取捨選択せず「すべてのデータを一旦取得する」というのが特徴だ。「這う」という意味で「クローラー」と呼ばれている。

私達がWebサイトの必要な部分だけ取捨選択しながら読むのに対して、クローラーはすべて読む。機械だから疲れることなくたくさん読める。

Googleのbotがあまりに有名で、botといえばWebサイトのクローラーをイメージする人も多い。

他のbotの事例では「チャットbot」などがある。チャットの対話の相手が人間ではなくシステムが相手となっている。チャットbotに関しては、別の章で解説したい。

機械が読むということ

機械が読むということを整理したい。

デジタル化ということは、本来機械が読めるようになるということでもあるのだが、実際には渡したちは一向に読むことから開放されてない。紙の本からPC、スマホになっているが、むしろ読む量は増えているのではないか。

もちろん、デジタル化が「人と人とのコミュニケーションを活性化させる手段」といして発達しているのだから、そもそも機械に読んで欲しいわけではない。

この文章だって人間が読むための文章であって、機械が読むために書いているわけではない。

ただ、検索エンジンにとって読みやすい必要はあるとは思っている。だからのこのブログにもカテゴリを設定して、複数の記事を巡回安くしている。検索エンジンはあくまで人間にとって勝ちのある記事をより検索しやすくしているだけだが、人間にとって価値が低くても、検索エンジンにだけ気に入られればいいという発想もある。

逆に人間だけ読めれば良くて、検索エンジンには見つけてほしくないというケースもある。謝罪文が画像で表示されるケースなどは、機械に読んでほしくないケースだろう。

デジタル化された情報が、「人間が読む」「機械が読む」ことのせめぎあいは常に起こっており、今後も続く。私が今している仕事の大半は、「人間が読むことを前提にしたデータを機械が読む」ということが主な価値となっている。

こうしてプログラマーになりました

プログラミングをやってみようと思った時のことを書いておく。大学3年から4年でほぼ全て詰まってる。

大学の授業ではピンと来てなかった

大学でもプログラミングの授業はあったがピンときてなかった。メーンフレーム上でFORTRANを書くという課題だった。何がOSのコマンドで何がプログラミング言語かの区別がついてなかった。FACOMかACOSかどっちかだったと思う。

友達がポケコンでプログラミングしてもピンと来なかった

ポケコンという電卓のおばけみたいなのがあったけど、その上で同級生がテトリスを作ってたりもしたがピンと来なかった。

PC上でのC言語は楽しかった

PC上でC言語のコンパイラを使って文字列操作をするというだけの課題があったがそれは面白かった。何よりもパソコン上でソフトウェアが作れるのだというところの面白み。特にPCに関しては情報もたくさんあったので片っ端から試した。この頃はまだ自分のパソコンを持ってない。しかし計算機センターにいくと、PC-98が大量にあったので、そこでフロッピーに入れた一太郎を持ち込んでサークルで使うレジュメを15インチのインパクトプリンタで印刷しまくった。プログラミグというよりもPCが面白かった。

念願の自分のPCを買った

コンパックショックというフレーズがあった。当時はNECのPC98シリーズかMacという高価なものしかなかったが、20万を切るという価格破壊を外資メーカーがやってくれた。そこで自分のお金でやっとPCを買うことができた。ちゃんとプログラミングもするんだろうなぁと思っていたから、MacじゃなくてDOS/Vにした。当時そのことをMacユーザの先輩に話すとものすごいで剣幕でまくしたてられた。そんなに宗教的な発想がコンピュータの世界にあるとは思わず、ただMacユーザ怖いとしか思わなかった。

最初はVBをやってみた

当時は無料でプログラミングということ自体が難しかったから、これもまたお金をためてVBを買った。VisualがついてもまぁBASICだから無難だろうと選んだ。

チュートリアルはサッカーゲーム

本に載ってるサッカーゲームを作ってみた。本格的なのではなく、タイマーイベントでボールが動いて、ゴールキーパーを動かして衝突判定。ところがゲーム自体にはあまり興味はなく。とは言え「タイマーイベント」という目に見えないコントロールがあって、イベントドリブンなんだなというのはわかった。

次に作ったのは自動スクロール

次に作ったのは、任意のウィンドウをスクロールするとうプログラム。機能はシンプルで。以下のような処理

  • 現在アクティブなウィンドウを見つける
  • そのウィンドウに対して1秒に一回 下矢印キーを送る

5行くらいのプログラム。このアプリのおかげで、ご飯を食べながら長い文章を読める。一時停止したかったら、そのウィンドウからフォーカスを外せばいい。これだけのことで、生活が豊かになった。

次に作ったのはモンテカルロ法によるπの計算

理系少年だったので、πの計算をやってみたいという野望はあった。もちろん代数的には解けない。どこまで言っても近似だ。ただ、近似を出す計算って、紙と鉛筆ではやりずらい。ところがコンピュータを使えば、ちょっとしたシミューレーションができる。モンテカルロ法によるπの計算とはこういう理屈。

  • 正方形の中に接する形で円を描く
  • 正方形の中にランダムに砂を振りまく
  • 正方形の中に入った砂の量:円の中に入った砂の量=正方形の面積:円の面積

ということで、πが含まれる比率を、実際の砂の量で近似できる。

凝った計算は全然せずに、代数的にときづらい計算でも、「ざっくり試す」ということができる。これはすごく感動して、「あー、コンピュータってのは人間が面倒なことをやってくれる機械なんだなぁ」ってことを痛感する。この時点でゲームプログラマーにはならないことが見えている。その後も新しいプログラミング言語を触る度に、モンテカルロ法でπの計算をさせている。

ちなみに、モンテカルロ法はすぐに近似はでるが、たくさん計算してもそんなに精度は上がらない。そういうのもかわいい。

秀丸エディタとの出会い

理系学生だったので、なんとなくTeXは触れてた方がいいんだろうなぁとは思っていた。TeXの関数を全部覚えるのは大変だなぁと思っていたら、秀丸エディタでTeXが記述しやすいとあった。これはいいと、試しに使い始めたのが、テキストエディタとの出会い。

私が持ってるPCってスペック的にはギリギリで一太郎が起動するまでも時間がかかったのだけれど、秀丸エディタは快適に動いた。エディタにはマクロがあるらしいということがわかり、さらにヘルプに構文が全部書いてある。シェアウェアとは言え有償コンパイラに比べればめちゃくちゃ安い。そこから自分が便利だと思うものを片っ端から秀丸エディタとVBの組み合わせで作っていった。学生とは言えこれは4000円払う価値があると、すぐに秀丸エディアにお金を払った。

秀丸エディタで就活管理

就職活動はまぁまぁの緊張だったので、各企業の状況を頭に入れるのが大変だった。当時は電話主体の就活だったので、企業側から電話がかかってきたときに、何の会社でどこまで進んでいたかがわからなくなる。そこですぐにジャンプできるようにして、ステータス管理をするという秀丸マクロを作っていた。今思えばテキストエディタのタグジャンプ機能でしかないのだが、そういうのを時前で作っていた。さらにエディタ上の電話番号をクリックすると、電話をかける機能も作ったし、FAXも送れるようにした。やたらとFAXを送ってくる学生はたぶん気持ち悪かったと思う。

そんな感じで地続き

あくまで自分の例でしかないし、今は時代が違いのかも知れないが、「手に職を!」とか「フリーランスで一発逆転!」という発想ではない。触っていって、自分が億劫だったことをどんどんやらせていった。それが私がプログラマーになった瞬間。

「料理ができるようになりたい」というときに、まずは自炊の料理を工夫するというところからスタートするのに近い。家で料理をしたことないのに料理教室に行くというのは飛び過ぎだとおもう。

私はよく「プロダクトの前にまかない飯から」と言ってる。自分や身の周りの人が食べて美味しいと思えるものを作るというのがチャレンジしやすくて評価もしやすい。仕事ということになるとやれマーケティングだのやれ競合だの売上だのということが発生する。プログラミングの本質じゃないところで手間を取る。まずはまかない飯から作りましょうよというのが持論。

Web系のツヨミとツラミ

別のブログで、SIerのツヨミとツラミを書いた。 SIerのツラミとツヨミ - 山本ゆうごブログ

ここではWeb系エンジニアのツヨミとツラミを書く。

「SIerからWeb系への転職」というようなワードをみる。まるで良いことのように語られる。

定義は曖昧だがWeb系とはこういう業態のことを指していると思う。

  • 開発したシステムを納品するのではなく、自社でそのシステムを運用する
  • システムはWebサイトが多く、使用料とか広告モデルとか稼ぐ
  • サービス育成にあわせて常にシステムはブラッシュアップする

Web系のツヨミ

合理的につくれる

SIerのツラミは、変な仕様でも仕様に従って作らねばならないというのがある。ところがWeb系は自社でのビジネスはきまっているが、作り方は「最も合理的な方法」をとるしかないので、クラウドを使った仕組みなど合理性優先で構築できる。

開発効率という観点でも合理的に作ることができる。テストも自動化しちゃえる。

自分で事業を作ってる感がある

ソーシャルゲームをつくるエンジニアは、まさにゲームビジネスの中の人だ。自分がリリースしたガチャがどれくらい稼いでいるかを肌感覚で掴める。

システムの育成に立ち会える

受託で作ると構築した人と保守する人は別れることが多い。しかしWeb系は自社ですぐそこで動き続けるので、構築メンバーと育成メンバーはあまり変わらない。

(場合によっては) 会社の価値の向上が自分の資産になる

もはやエンジニアとしてではなく、「株主として」という話になるが、自分でコードを書いて自分でサービスも運営して会社の株も持ってるというのが最強。Web系ベンチャーではそれがある。給与とかそういう待遇とか超越したリターンが得られる。

Web 系のツラミ

実は新規サービスをどんどん作れるわけではない

イケてるWeb系事業ほど「長いこと古い仕組みを育て続ける」必要がある。Yahoo!はずっとYahoo!だし、zozotown はずっとzozotownだ。ゼロから作る機会などほとんどない。「サービス名考えると同時にドメインのアキも探さないとなぁ」なんてことが ほとんどない。

Web系だから新規のサービスを作れるかというとそうではなく、やっぱり「金を稼いでいるサービスの育成」に当たる方が合理的だ。

本当に新しいことを覚え続けないと死ぬ

iOSやAndroidの新しい作りを知っておかないとサービスのアップデートさえできない。どんどんOSのバージョンも変わる。つらい。

待遇がよいわけではない

SIerは「お金を持ってるけど技術がない会社に技術を売る」という商売だが、Web系の場合は技術があるのは当たり前で、その上でサービスが金を稼いで初めて組織に金が入ってくる。これは結構ドキドキもので、この世には金を稼がないWebサービスが山程ある。ここ数年のAppStoreのランキングを見れば分かる。LINE、ツムツム、グラブル、FGO、モンスト、パズドラ、この辺が全然落ちない。しかし、めちゃくちゃスマホ向けにはアプリはリリースされてるの。でも誰の目にも止まらず、消えていってるの。めちゃくちゃ技術的にはすごい人が作っていても、ランキングに入らないの。その場合は会社ごと消える。

反対にSIerに目を向けてみると、あのマイナンバーの仕組みでも100億を超える入札単価だ。 tech.nikkeibp.co.jp

SIerがしぶしぶやって100億。それをアプリで作るのはかなり厳しい。ただスマホゲームで当てると年間1000億くらい売り上げるからそれくらいの夢があるとも言える。ただほんの一部だ。

割とあっさり追い越される

SIerだと存在した経験値の差によるマウンティングが通用しない。この道10年のSwiftエンジニアは居ない。この道5年のVueエンジニアは居ない。定期的にゲームがリセットされるので、アドバンテージがすぐに消える。勢いのある若手と張り合い続けるのがまぁ大変。特にフロントエンドは移り変わりが激しい。

SIerのツラミとツヨミ

Web上のエンジニアの愚痴をみていると、SIerに対する嫌悪感が多い。かくいう私もSIerの硬直化した組織はやりづらいとは思ってる。

一口にSIerと言ってるが、定義としては以下のように絞られるだろう。

  • 自社サービスを持つのではなく、クライアント企業の依頼を受けて動く
  • 割と大規模(だからこそクライアント企業の中の人間ではできない)
  • ビジネスモデルとしては受託(業務委託契約)
  • 納品ベースでお金が動くので、仕様書が契約書に近い効力を持つ

以上の切り口そのものに、何ら問題はない。

SIerと対比される業態に「Web系」とか「自社サービス」などという表現もある。

Web系も定義がはっきりしないが、整理をすると、Web系とはこういうことだろう。

  • 開発費をもらうのではなく完成したシステム自体が稼ぐ
  • 広告費や月額使用料で稼ぐモデルなので、インターネットビジネスが比較的多い
  • 自社で要件定義をするので、常に仕様はアップデートされていく

Web系のツラミとツヨミは別のところで解説するとして、ここではSIerに絞って説明する。

まずツラミ

硬めのクライアントが多い

SIerにとって太い客といのが、官公庁や銀行などだ。多くのSIerが銀行の子会社からスタートしている。だからどうしてもクライアントのカルチャーに引っ張られる。金融系のSIを担当するということは、ソフトウェアビジネスではなく金融ビジネスをしているのに近い。だからスーツだ。自社の新人研修でSIerがやってるプログラミング研修にやると、「机の上にペットボトルがあると叱られた」と帰ってきた。そういう研修をお願いした覚えはないのだが、1文化とも思わず、社会人エンジニアとしての常識ということなんだろう。

硬いこと自体は悪くないのだが、何かとマナーにうるさい。さらに根回しの世界。太鼓持ちを仕事にしたくなくて技術者になったのに、なんでご機嫌を伺うことが最優先になるんだろうという矛盾。

仕様書の通りに作ることが仕事

仕様書どおりに作って納品するというのがビジネスなので、仕様書にかかれていることがどんなに使いづらくともその通りに作らないといけない。逆に仕様書に書かれてないことは作っちゃいけない。そして厄介なのは、その仕様書を作ってるのが、「UIの専門家でもなければコンピュータの専門家でもない人」が作っているというのが辛いポイント。だいたい間違ってる。間違ってる仕様書の通りに作らないといけない。

そしてどんなにクレームが来ても仕様書の通りなら「それは仕様です」と言って突っぱねるのが大事な仕事になる。

技術に疎いクライアントが相手

クライアントが技術に疎いからこそ、外注をしている。先の仕様書の間違いも指摘するのは苦労をする。レクチャーにかかるコストはお金にならない。

新しい技術は使えない(使っちゃいけない)

メーンフレームCOBOLという組み合わせはまだまだ多い。せっかくだから新しい技術も使いたいかもしれないが、年金のシステムは向こう50年は動いてもらわないといけない。毎年変わるアーキテクチャは使えない。

本当に新しい技術が使われているなら、銀行の口座番号なんて、664289d2-dc45-44b8-8b00-c5a20d789e50 となっていてもいいはずだ。ところが、2019年時点の三菱銀行では三和銀行の口座番号とIDとパスワードがそのまま使える。これは技術では解決しない。

ツヨミ

逆にいえば、上記のツラミがあったにせよ、ビジネスとして成功しているからこそ存在しているのがSIerだ。しっかり稼げてうらやましけしからん。

待遇がいい

自社サービスだと自社のサービスの売上が分母となって、従業員に賃金が支払われる。儲かってないWebサイトのエンジニアの給与はそれなりだ。ところがSIerだと客が太いから会社そのものもまぁまぁ潤ってる。そこでのエンジニアの給与も高い。

ホワイト

仕様書の通りに作るというのは一見ホスピタリティは悪いが、仕様変更にいちいち付き合ったのではいくら時間があっても足りない。仕様書通りに作るというのは自分たちを守るための手段でもある。また、SIerからも下請けにながす。本当に労働環境としても辛いのは、二次受け三次受けだ。

業務には強い(これが一番言いたいこと)

例えば、会社のビジネスが変わって、会計システムを入れ替えたいという話がある。クライアント企業の担当は会計システムを入れ替えた経験など、ほぼない。ところが、SIer側はそんなことばっかりやってる。だから会計システムの入れ替えの時の「あるある」がめちゃくちゃ溜まってる。他の会社の事例をしっている。守秘義務があるにせよ、競合他社含めてのバックオフィスの知識と経験は、喉から手が出るほど欲しい。クライアント企業も仕様書をいきなり作るのではなく、RFPという形で、「SIerからの提案募集」をすることもある。

逆にここが強すぎて、入札には手を上げないというケースも発生する。マイナンバーのシステムとかは、入札段階で「あー、これやんない方がいいやつだわー」とSIer個別には手をあげなかった。実際にはSIerの合同で仕方なく国に付き合うという形で落ち着いたが、実際にリリースされたものをみると、確かに国がやりたいことと手段がミスマッチだ。SIerの人たち賢いね。

この「業務に強い」は、SIerの中では常識で、PG→SE→PMという形で出世するというコースが描かれている。「出世したらコーディングできなくなっちゃうよ」という恨み節も聞こえてくるが、SEの市場価値なめんなよと。「ECの倉庫のシステムを構築したことあります。」というのは、「Railsでサクサクサイト作れます」とは別次元の価値がある。

欲を言えば、「業務に強い」のその業務によって当たり外れがあるということ。先に挙げた「ECの倉庫システム」はとても今求められている。「店舗のポイントカードの仕組みとECの在庫の仕組みの両方経験あります」だとさらに価値が高まる。

この業務に強いというのは「複数の会社の類似業務を見ていている」ということもある。これは社内エンジニアにはできない経験だ。不満をもっても何と比較して駄目なのか良いのかが分からない。

ベンチャーも習うべきところは多い

SIerにエンジニアがたくさんいるというのは、それなりのビジネス的な理由がある。とにかく金が動かないと話が始まらない。そして「人を便利にするシステム」を作るには、業務の事例をたくさん知ってるということが、市場価値を生む。

ベンチャーであっても「便利」という価値を生むなら、受託じみた形からサービスや新機能をスタートして「この領域ならクライアントより業務の知識が多いですよ」という領域ができると強い。

ITエンジニアのための謝罪メソッド

システムというのは基本的にはトラブルもの。正確には動いている時にはありがたみがなくて、トラブった時だけ注目を浴びるもの。

やれアジャイルだ、ウォーターフォールだと、開発手法に関してはいろいろ話題にはなるが、謝罪方法を語る人があまりいない。

だが謝罪にはメソッドがある。

経緯書の書き方

謝罪の経緯書はだいたいこういうフォーマット。

  • トラブルの概要
  • 時系列
  • サービスに対する影響範囲
  • 直近の対応
  • 原因
  • 根本対応
  • 組織としての対応

こんな感じ。そんなもん最初からやっておけというお叱りもあるのを承知。がんばりますという対応は駄目なんだけど、がんばりますというのがないというのも良くない。

謝罪のゴールはこちらがペースを握るということ

一番つらいのは、こちらの今後のタスクを先方に切られるというのが一番つらい。経緯書の「今後の対策」は、あくまで自分達が実行可能なタスクにすべき。やりたくないけどやるというのは良くなくて、「これあった方が絶対楽だよなぁ」と自分達でも思える対策が必要。システムトラブルに対する検知ツールのチューニングとかはあった方がいい。

時系列での報告の意味

時系列でのトラブル報告は、「どうやってトラブルが発覚したのか?」「それを伝達するルートはどうなのか?」「対応できる人までたどりついたのか?」をあとで振り返るのに有効。

発覚が自社というのが一番いいが、先方からの指摘で発覚するケースもある。その場合は窓口が動き始めるまでの初動が早いとまぁいい。実際に想定外のことが起こった場合には、回復までに時間がかかるのは仕方ない。ポイントは着手までの時間がどうかということ。

サービスに対する影響範囲

サービスダウンしてましたという場合には、その影響を数で出す。私達はサービスの重要性を分かっていますという姿勢が大事。

直近の対応

その場しのぎでサービスが継続するならいい。新しいシステムのリリースでトラブった場合には旧バージョンに切り戻しというのもありえる。原因不明でサーバが高負荷の場合にはサーバー再起動で収まるかもしれない。理想的なシステム構成は後回しでも、泥臭くともサービスを継続しようとしておりますというのは、ビジネスシーンでは大事。

原因

ここに、バグの原因と、そのバグが見つからずにリリースされた経緯などを記入する。どっかのモジュールがバージョンアップしてその影響でこんなンなっちゃいましたとか。

根本対応

システムのトラブルはシステムの改修で対応する。ログが溢れましたとかお粗末なトラブルならログローテートしますとか、ログサーバーに転送しますとかそういう改修。当然ないよりは合ったほうがいい。

あと、根本対応で駄目なのは、運用ミスでダブルでチェックしますとかレビューを徹底しますとかそういうやつ。ありがちなんだど、システムのトラブルでシステムで解消しないというのは、コンピューターリテラシーなさすぎる。

さらにもう一声

対応にもう一声あるとしたら、「類似トラブルの調査」という観点。こういうミスをやらかすんだから、類似のミスをしでかしていていもおかしくないだろうということ。システム改善のためのタスクをむこう数週間くらいギチギチに入れておく。トラブルが起こる前よりもよりスマートなシステムにする。志を高くもつ。