スベリミナル効果

技術的なことを書こうと思ってたけど何でも書くことにします


通常用
ふざけ用		 何でもコメントください。誤り指摘コメントなどには「コメン（ゴメン）」ト誤ります（１スベリ）
ダジャレ好きの方はこちらにどうぞ（更新してないけど）→スベリブログ2.0

オープンセミナー岡山に参加してきました #oso2017

テクノロジー カンファレンス・セミナー

オープンセミナー2017@岡山に参加してきました。さすがに神奈川からは遠いので迷いはしたんですが

  • 「レガシーとたたかう」というテーマが今の自分の苦悩にかなり刺さった
  • @t_wadaさんとか、@naoya_itoさんなど、業界有名人をあまり知らない私でも知っている登壇者のお名前が連なっている
  • しかも無料なんですってよ奥さん

ということで、仕事終わりでそのまま新幹線に飛び乗って前乗り参加しました。そんなこんなで聴かせて頂いた内容について、いつものようにつらつら書かせて頂きたいと思います。また、長文になってしまった…

発表一覧・資料については、以下に上がっていくようです。

レガシーコードの触り方

登壇者　：和田 卓人(@t_wada)さん (タワーズ・クエスト株式会社)
スライド：レガシーコードの触り方 / Working Effectively with Legacy Code // Speaker Deck
定義　　：レガシーコード＝テストの無いコード


まず、自己紹介として、t_wadaさんのスタンド「ワイルド・サバンナ」が登場です。テスト書かなきゃ…

　　　　 ,、,,,、,,, 
　　　 _,,;' '" '' ;;,, 
　　（rヽ,;''""''゛゛;,ﾉｒ）　　　　 
　　 ,; i ___　、___iヽ゛;,　　テスト書いてないとかお前それ@t_wadaの前でも同じ事言えんの？
　 ,;'''|ヽ・〉〈・ノ |ﾞ ';, 
　 ,;''"|　 　▼　　 |ﾞ゛';, 
　 ,;''　ヽ ＿人＿  /　,;'_ 
 ／ｼ、    ヽ  ⌒⌒  /　 ﾘ　＼ 
|　　 "ｒ,,｀"'''ﾞ´　　,,ﾐ| 
|　　 　 ﾘ、　　　　,ﾘ　　 | 
|　　i 　゛ｒ、ﾉ,,ｒ" i _ | 
|　　｀ー――-----------┴ ⌒´ ） 
（ヽ  _____________ ,, ＿´） 
 （_⌒_______________ ,, ィ 
     T                 |
     |                 |


「あえて抽象度を下げた実際にコードとたたかう話」ということで、非常に具体的な内容をデモも交えてご説明いただきました。

弊社では2年前に大きな品質問題を出してしまってから、自動テストを徐々に拡充していこうという取り組みをしており、発表内容についてはウンウンとうなずけました。この辺はワイルド・サバンナもニッコリして頂けるかなと思いました。

ただ、実際にやってみると、

  • 最初から全部やろうとしない
  • 網羅性にこだわらない

っていうところにこだわりすぎてしまったり、

  • 設計の可動域を確保する
  • 接合部の検討と吟味

などは、ケースによってうーむ…と悩んでしまう部分ではないかと思います。テスト対象のレガシー具合や、どういう機能であるかにもよると思うので。後者の方は、やはり様々なケースでテスト作ってみて経験を積まないと、なかなか上手くいかない部分なのかなとも思いました。
デモでも（ダジャレじゃない）、「標準出力奪ってdiff取る」ってのがありましたが、あれもなかなか思いつかない(思いついてもできない)策じゃないかなと思いました。


こんなdiffもrpmbuildの接合部と言える?し、現状の動作から変更が無いことを確認できると思います(t_wadaさんからいいねされた、やったね！)。このへん、多分ケースバイケースなことが多く、今回のデモのような内容は非常に貴重で、正直もっと長く見ていたかったです。

あと、テストのトリアージについては、明確にやっていなかったので今後の参考にしたいです。（『リーン開発の現場』も積読のままだなので読まなきゃ…）

ミーハー的には、t_wadaさんの発表聞けたの初めてだったので嬉しかったです。

レガシーを解決する開発プロセス

登壇者　：角(すみ) 俊和 さん (NHNテコラス株式会社)
スライド：レガシーを解決する開発プロセス

「新技術を使っていい感じのサービスを立ち上げること」という無謀なお題に対してたたかうお話。
肝としては、キックオフと同時に仕様決め合宿を関係者全員集めてやり抜いて、ありがちな手戻りやリソース問題などを徹底的に潰した、ってことだと理解してます。逆に言うと、やるべきことをしっかりやりさえすれば上手くいく、とも言えるのかなと。
この事例はあくまで「社内システム＝関係者が全員社内」だったからこそ「全員集めて徹底的に」ができたということもあったと思いますが、それでも、全員が納得できる合意にまとめあげることって、そう簡単じゃないと思うんですよね。5日間缶詰でそれが終わり、その後のちゃぶ台返しがほとんど発生しなかった、という点が本当の肝なのかも、と思ったりしました。要は、その5日間の合宿のやり方に秘訣があるのではと。この辺質問すればよかったな…

あと、単純に、こういう風にマネジメントしてもらえるの、正直うらやましいっす。

50年間の流通業の変化と、未来づくりのためのイノベーション

登壇者　　　：中山 博光さん (株式会社リゾーム 代表取締役社長)
ホームページ：リゾームとは | 経営分析、顧客分析システム、売上分析、デベロッパーマネジメントシステム：株式会社リゾーム

60名の社員で、主にショッピングセンターを対象とした幅広いサービスを行っている株式会社リゾームのお話でした。
全国のショッピングセンター 2000/3300 施設と何かしらの関連を持っているということで、凄いノウハウ持ってそうな雰囲気を感じました。それだけに、色々なありがたいお言葉を聞けた気がします。

  • やってみないと分からない 失敗はつきものだが、お客様目線があれば大きな失敗にはならない、失敗するときは欲を出しすぎたとき
  • 「現場に任せる」　結果バグも減りいい関係が築けた
  • 無人化AIの方が好みに合うかも (若干意訳したかもしれません)

といった話は心に響きました。地方活性化のために商業施設は必要不可欠なので、こういった所からの変革は重要だと改めて思いました。

最新ツールでレガシーをぶっ飛ばせ

登壇者：山本 裕介さん(株式会社サムライズム)

これはよい宣伝。
www.xlsoft.com

GitHub上のコードレビュー、当然のように行っている所が多いと思いますが、この作業自体が実はレガシーでは、という触れ込みから、Upsourceの実演、10名までは商用利用でも無料、ということで会場から歓声が。

でもスミマセン、うち、bazaarなんですわ…(個人で使えよ)

データベースリファクタリング

登壇者　：曽根 壮大(たけとも、通称そーだい)さん (株式会社はてな)
スライド：DataBase Refactoring // Speaker Deck

アプリケーションよりも長寿なDBのリファクタリングについて、絶版の『データベースリファクタリング』から最初の一歩をお伝えします！という熱い想いが伝わってくるお話でした。

  • モニタリングする
  • コツコツと長いスパンで
  • DBの機能を活用する

といった点が重要だと思いました（書いてあるまんまやん…）。いや、正直、DBについては定義されたものを使うだけ、そして大きな変更はずっと無い、というぬるま湯に浸かりっぱなしなので耳が痛かったです…　「問題は小さなうちに」そのとおりです…　手を動かせるよう頑張ります。

どうでもいいコメントしてスミマセンでした。


技術的負債と向き合う

登壇者　：伊藤 直也さん(株式会社一休)
スライド：技術的負債と向き合う // Speaker Deck
関連記事：伊藤直也氏が語る、マネジメントで本当に大事なのは「問題にフォーカスする」である理由｜CodeIQ MAGAZINE


rebuild.fmリスナーとして、単純にミーハーな感じで聴きにきた感があったのですが、震える内容でした。本当、岡山まで来てよかったと。前日あたりに丁度バズった記事と内容が半分くらいかぶった、とのことでしたが、生で聴くことに意義があったと思います。一休での技術顧問二年間と、CTO着任後の一年間の2章+ラスボスという構成のお話でした（本当か？）。

技術顧問編では、外から来た事情の分からない人間として、問題を整理し継続的に取り組むことのきっかけとして上手く作用できたのではないかと。学ぶべき点としては、リスペクトすべきレガシーを否定するような取り組み方はダメで、レガシーはそりゃあるよ、じゃあなんでこうなってるんだろう、という考え方をしなければならないと。
もうこの時点でウンウンうなずきまくってましたが、ただ、やっぱこの部分だけでも、そう簡単に進むものではないと思うんですよね。当然、技術的課題を理解して整理できる能力があって、かつ、ある程度の信頼感がなければ諸々の改善って進まないと思うんです。だからこそnaoyaさんが招聘されているわけだと思いますが。この話を自身の現場で活かすとなると…　って考えると、やっぱりそれなりにデキる人呼んでくるしか無いのかなあ…などと考えていました。

で、CTO着任編。何だかんだ進捗したけど、人間の本能的に目をそらしてきた大きな問題に着手していくと。ここで、改めて問題を整理し、説明できるレベルの資料に落としていった、というのが凄いのかなと。この成果物が整理・展開され、方針として降りてくる。そりゃ現場も納得するし、目的が明確だからきっとスムーズに作業が進むんだろうなと。さらに「背中を押す」といったところまでケアされてめでたしめでたし…

と思いきや、新のボス「レガシーコード・レガシーアーキテクチャー」がまだおった、的なことに。そこで自分の工数を使い、パターンを比較対象として用いながら、課題を明確に言語化していき…　なんかもうこの辺で頭が上がらなくなってくるというか、技術者の側面とマネジメントの側面をフルに使った、言うなれば魔法戦士というか、バトルマスター賢者的にたたかいを繰り広げた感が垣間見えました（ぼくだけですかそうですか）。

自分の現環境に適用することを考えながら聞いてたんですが、まずは技術者として、課題の言語化・資料化っていうところをマネしてみたいかなと思いました。正直、マネジメントにはあまり期待できない環境だと思っている（ここも変えろという話が次にあったかもしれない）ので、ボトムアップでどう改善していくか…　ひのきのぼう と ぬののふく の ただのまちのひと がどこまでできるか分かりませんが、部分部分のエッセンスを拾って活かしてみたいなと思いました。


うまくバランス取るだけでも相当難しいと思いますけどね…

日経電子版 レガシーな基礎の上に逹つ旅館

登壇者　：武市 大志さん（株式会社日本経済新聞社）
スライド：日経電子版 レガシーな基礎の上に建つ旅館 // Speaker Deck


一緒にしたら失礼かもしれませんが、境遇的には自分と近い部分があって、最も共感が強かった発表でした。大きい企業で外注の方が主、サービスや機能を止められない、北海道で水道管工事したら沖縄で詰まる、など、あるある過ぎてつらくなりました。



まさか、こんな部分まで…　スクリプトを作らずに耐える所がダメエンジニアですが…

レガシーができあがる経緯なども、それな、という感じでしたし、降ってくる案件をそのまま受け入れてしまいがちなところもまさにという感じでした…　本当に、こういった所を見直せなければ将来は無いと思っております…

とか偉そうなことを言いつつも、自分も「それはしょうがないよ！」の精神にどっぷり浸かってしまっていることを反省しなければと思わされました。よく「歴史的経緯」で誤魔化されがちだったりしますが、じゃあどうすれば他の世界線に行けるのか常に考えないといけないなと。こういうセミナーでこういう発表を聴くことが一つの小さな対策なのかと思いました。やっぱり来てよかった。

最後は度量の違いを突きつけられて終了。精進します…

企業もインターネット中心のアーキテクチャにしよう

登壇者：長谷川 秀樹さん(ハンズラボ株式会社 代表取締役社長)

なんか、色々すごかったです（こなみ）。

本日の発表は、キラキラ系(Web系)の人たちには全く面白くないお話です、というつかみからのスタート。懇親会でもずっとWeb系＝キラキラ系が定着してました笑 そしてかなりレアと思われるAmazon Go現地の映像。話には聞いてたけど、確かに見たことなかった。トークと相まってドンドン引き込まれてしまいました。


そしてこれ。この点、何故か逆行しようとしている（？）現場の私としては公演に来てもらいたい…

ここからは怒涛のAWSへの移行、アップデート大好き、夜間バッチ止めろ、など、「つよい」内容がバシバシ飛んでました。マジで笑ったし、マジでリスペクトでした。ここまで徹底して舵をきれる人は見たこと無いです。さすがにそれは危険じゃないかなあ…なんて思う方針もありましたが、そんな矢先に
これを社長が言えるって凄すぎ。少しのクレームにも怯えて、不具合修正すらモゴモゴ遅らせてくるオッサンどもに喝を入れてもらいたいです。ある程度大袈裟な表現もあったんだろうなあと予想しますが、それにしてもつよかった…

そして、「Web系の人たちはもうちょっとドキュメントをかきなさい」で会場大爆笑。笑った。

最後は転職をオススメして終了。

正直、単純に楽しかったです。最後にこの発表っていうのが凄く良かったと思います。


ちなみに、後日談として。


懇親会

「日本一の懇親会会場」とハードルを上げてましたが、確かにそうだった。ライブやってたし。


そして、怒涛のLT大会の中、心を揺さぶられたのがこちら。
数式の書けるMastodonその名もMathtodon を作った (#OSO2017 懇親会LT) / Introduction to Mathtodon // Speaker Deck

Mathtodon(普通のマストドンじゃなくて、数学のやつね)を建てた方が発表を！そして、この開発手法がDDD(Dajare Driven Development)＝ダジャレ駆動開発ですって！　勝手に「僕も負けないぞ！」と思いました（何も作ってないけど）。しかしMathtodon凄いよね。ダジャレは世界を変えるよね（違う


ってことで、思ったより分量多くなりましたが、非常にいい経験をさせて頂きました。発表者も豪華で、内容も充実してましたし、これ本当にタダで聞いていいんですか？って感じでした。岡山・広島周辺地域の結束力みたいなものも感じたし、懇親会も凄いし、これはちょまどさんも登壇した方がいいですよ、絶対（当方、全く面識ございませんが…）。

この経験を活かし、レガシーに勝ちうるそれがしーを目指すでござる。（台無しな１スベリ）