先日、コデアルさんのインタビューで「受託開発から自社サービス開発に転換できた」話を取り上げていただいた旨を書きましたが、受託開発って本当にうまくいかないんですよね。

先日も、旭川医大とNTT東さんの裁判の件は、IT業界では話題になってましたね。

失敗の全責任はユーザー側に、旭川医大とNTT東の裁判で逆転判決

http://itpro.nikkeibp.co.jp/atcl/column/14/346926/092501136/?rt=nocnt

 

旭川医大だけにかかわらず、受託開発にまつわる大体の問題が、「仕様変更」によるものなのですが、これに対する解決ってないんですよね。

発注側：「ちょっとのことなんでしょ？なんでやってくれないの」

この繰り返しなんですよね。

あと、発注側が完璧を求めすぎる。

プログラムの世界には完璧はないんですよ。

この点が、なかなか理解して頂けないんですが。

 

どうも、プログラマーの仕事を職人の手仕事と同じようにみられているように思いますが

「プログラマーが手を抜かずにちゃんとやれば、完璧にできるはず。だから、バグは手抜きとか力不足が理由。」

という理屈が発注側さんに往々にしてありますね。

そうではないんですよ。

 

プログラムという製品が複雑すぎるのです。

「いや、簡単でしょ。もし〇〇したら〇〇するって書いていけばいいんでしょ」

っていう人がいます。

いやいやいや。

 

まー、問題をシンプルにするために、仮に

「もし〇〇したら〇〇する」

だけがプログラミングだけだとしよう。

例えば

「もしメールが届いたら自動返信する」

とかだったら、簡単かもしれない。

しかし、それだけのプログラムは何の役にも立たない。

 

現実世界で起こるような複雑な処理をしてるわけです。

例えば、朝起きてから会社に行ってお昼ご飯までの

「もし〇〇したら〇〇」

という分岐をすべて書いてみてください。下記のような感じです。

「朝7時半に目覚ましがなって起床

↓

（目覚ましが鳴った時）　　　　　　　　　　　　　（鳴らなかった時）

↓　　　　　　　　　　　　　　　　　　　　　　　　　　　　　↓

7:35 　パンがあるかないか調べる　　　　　　　　　寝ている
（パンがある）　　　　（パンがない）　　　　　　　　　　    ↓

↓　　　　　　　　　　　　　　　↓　　　　　　　　　　　　　↓

7:45　パンを食べる　　　ご飯があるか調べる　　　　　　寝ている

この後延々といろいろと続く…

」

とっても複雑になってしまいますよね。

で、それを確認して、

「もう間違いない？これで大丈夫？」

と何度もテストしてみます。

 

仕様変更というのは、そのあとで

「んー、7時半に起きるとやっぱり眠いから、7時45分に起きることにしよう」

と変更が重なっていくという感じです。

すると、上記の分岐のタイムラインをほぼ書き直さないといけない。やることも時間がかかることをやめないといけない。

ぐちゃぐちゃになっちゃうわけですよね。

 

もちろん、これはわかりやすくシンプルに伝えたかったサンプルなので、実際はこんなんではありません。

if文だけでこれなんで、実際はもっと複雑なんです。

 

「でも、それって自社サービスでも受託でも一緒でしょ」

って声があるかもしれませんが、これは90度ぐらい違います。

受託だと、否応なしに天の声として降ってくる。

自社サービスだと、そこはコントロール可能な範囲で、理由も飲み込める。

なので、自社サービスのほうがずっと楽なのです。

 

こんなひどいコードを書いたのは、どこのどいつだーい？？(-_-メ)

あたしだよっ！3年前のね！！！（懐かしの、にしおかすみこ風に）

…

…

自社サービスを継続して続けていると、どうしてもレガシーコードと向き合わなければいけません。

そして向き合う過去の貧弱な自分やサービス、DB構造などレガシーな遺産たちともね…。

 

さて、話は前後しますが、先週の日曜日、PHPカンファレンスに行ってまいりました！

三連休の中日（ちゅうにち　じゃなくて　なかび　だよ）という超非リア向けイベントでしたけどね！！

よく晴れた日でしたねヾ(´ω｀○). 　こんな日は本当は山にでも行きたいとは思いました。心の底から！！！

 

…次の3講演をお聞きしました。以下、私が印象的に感じたことを述べておきます。

①Cygames グラブルの運用

・いかに10億PV/日をさばくか

・DBサーバー300台以上をシャーディングして水平分割

・時間がかかっているAPIを特定し、処理を見直す

New RelicとXHprofで時間のかかっている処理を特定

・Memcachedを活用

→キーの持ち方に気を付ける

→データが取れない場合は再度計算してMemcachedにのせる

→重い処理はとにかくCacheを使用

→マスターデータが更新されたらキャッシュを削除する

・KVSはローカルごとに利用

→redisは複数行を一度に処理するのに向いている

・プランナーが入力しやすいように、マスターデータはCSVを取り込んでいる。（へぇぇ）

 

②弁護士.com

 

ここは弊社とかなりポジションが似ていると思います。

自社サービスをやってく、ゲームなどではないという意味でですね。

なお、2013年までまったくの赤字だったそうで。

近年急成長したそうです。

 

赤字の場合は、サービスをとにかく顧客志向で。

→しかし、黒字になってきてからは運用が大切になってきた

→カウボーイ的開発をスクラム開発に変更

マイクロサービス化

→LikerDを利用している

→優先順位をつけてやらないことを決める

CircleCI、NewRelicを使用

 

開発には終わりがないのが終わり　とおっしゃっていたのが印象的でした。

 

③GREE

 

第一声が、

「みなさん　Greeって知ってますか？」

だったのは衝撃でしたがｗ

 

数千台のオンプレミスのサーバーをAWSに移行

→しかもPHP5.2だったので、まずは5.5に移行

→50%ロードアベレージが減らせた

→移行の際は、Direct Connectを使ってMySQLのレプリカをAWS上に作ったりした

 

現在、PHP7への移行を進めている

 

---

全部、内部の話をさらけ出して頂いて、大変に勉強になる話で、有難うございました。m(_ _)m

 

で、話が冒頭の話に戻りますが、受託開発で作って終わりのシステムを作っている人たちを除けば、レガシーな開発の遺産にどうやって向き合うのか、は非常に難しい問題です。

以上の3講演を選んだ理由は、これに対する答えを多少なりとも教えてくれそうだったから。

1年もたてば、古くなるし、当初想定していなかったバグも発生する。

アクセスが増えて、DBの処理が追い付かないとか、プログラムの構造変えなきゃとか、サーバー移行しなきゃとかなる。

想定していなかったような利用方法が出てきて、DBの構造変えないとダメ。

とかエトセトラですね！

 

弁護士.comの市橋立CTOに、懇親会で話を伺ったのですが

「すべてをやることはできないので、優先順位をつけてやるべし」

と言われていました。

 

なるほど！その通りですね！

しかし、これが経験された方の話と、経験されていない人の話では天地の差があります。

ありがとうございます。

 

なんかね、新しい技術を追いかけたいという気持ちもありつつ、常に新しいこともできない、というジレンマがあります。

弊社でもよく議論になりますが

「あれも　これも　それも　どれも　よくないから変えよう！！！」

じゃ無理なんです。

一歩一歩、一番重要なことからやっていかないと。

弊社の社訓の一番にもしてますが、

FOCUS ON IMPACT！ （大事なことを一番にやる）

 

これが重要ですね。

 

この日はこれに出かけようと急いでいて、マンションの階段で転んでアゴを強打するというヘマをする＆洗濯物に白いものと赤いものを混ぜて洗ってお気に入りの白シャツが台無しになるという悲しい事件もありましたが（つД｀)

また、懇親会LTやりたい！と実はスライドまで用意していたのですが、枠が埋まってしまい、ダメでしたね…。

私はMapboxの話をしようと思ってたんですが。

弊社スタッフにも

「節子！それはPHPやない、Javascriptや！」

とも言われちゃいましたしｗｗ　やらなくてよかったのかな…。ハハハ（・∀・）

 

で、最初は文句などを言っていましたが、行ってとてもよかったです。

例年、そう思ってますｗ

大変勉強になったし、一番の効果は、こういう純粋に技術を突きつめよう！という開発者が集まる場に行くと、自然とモチベーションがアップされます⊂(^-^)⊃

なんか、皆さん目がキラキラしてるんだよな～。(^。☆)キラーン

プログラミングって楽しい、技術って楽しい！と思えるそんな時間でした。ヾ(´ω｀○).

ボランティアスタッフの皆さんにも感謝感謝です。