最近行ってきたセミナーが面白かった

 あるクラウドサービスのリリースまでの話をセミナーで聞いてきた。そこで聞いた「ウォーターフォールがベストな選択肢だった」という話が、最近DevOpsを追っているぼくには膝を打つような感覚があったのでメモがてら。

 なぜアジャイルが生まれたのか。これはおそらくビジネスの状況の変化(また場合によってはクライアントの不明瞭さ)により、開発中にも仕様を変更していく必要があったためだ。一方で、サービスリリースを考えたとき、仕様がしっかり固まっているものを描けるならそれに沿ってやっていくのが実はベストなんじゃないかと。
 「設計をしっかりやったから手戻りがなかった」ということを、ウォーターフォールのメリットとしてセミナーで語っていた。設計書をしっかり練って書いて、あとはそれに沿ってクラスを書いていく。そんな工程で手戻りなく開発を進めていけたということだ。こういうことを可能にするような設計って、一般で考えればビジネスも開発も熟知していなければできない。んー、開発と同時にこういう設計できるようになりたい。
 ちなみにリリースが済んでからはアジャイルに移行していったとのこと。とても自然な形だと思う。
comment: 0

価値の流れに基づいた組織

金融機関のDevOpsの取り組み

 ロンドンで行われた金融業界のITカンファレンス。DevOpsという言葉に誘われて読んでみた。さらには金融機関での取り組みということで、これほど興味をそそるものはない。だって、日本にいると銀行って、DevOpsとは遠い開発手法とってるイメージがあるから。

 なにをした?なにを導入した?どういう目的で?といった内容か。やはりDevOpsなので、自動化して、リリースを早くといったところか。ところで目を奪われる言葉が記事中に出てきた。”価値の流れに基づいた組織”。
 以前に”ITというものの捉え方の更新を怠っていた”という記事を書いたばかり。要はITっていうのもいろいろ変わっていくよね、もうスマフォあるんだからほぼ24時間365日に近い状態でコンシューマに手を伸ばすことができるよねという状況。じゃあ今ってコンシューマにいいUXを与える技術の価値が飛躍的に高まってるんじゃないかと。そもそも技術に限ったことでもなく、価値って流動的なものなんじゃないかと。
 個人的な某所で、どう儲けるかって話を聞いていると、「開発したあそこのシステムが当たってハネてくれればサポートでうちは安泰になる」というのを繰り返し聞いている。これって価値が流動的だって考えをしていないから言えるのよね。価値は流動的、ましてやITなんてヒョイヒョイと標準が変わっていくので、IT界隈での価値の流動性は激しい。だからITやってる組織としては、市場ではなにに価値があるか、自分たちの手が届くところではどういうものが価値があるとされているか、自分たちがどういう価値を創出できるのかというのを逐一アップデートしながらやっていくべきなんじゃないかって思った。おそらく”価値の流れに基づいた組織”ってそういうことやってるんだろう。


 しかしイギリスは”英国政府、新ポータルGov.ukをクラウド、アジャイル、Rubyで開発。ソースはGithubで公開”とかやってて実験的なものを交えながらだいぶ面白いやり方を進めてるなーと。
comment: 0

ITというものの捉え方の更新を怠っていた

 会社で打ち合わせをやるとなると、たいてい上司が「資料を印刷して持ってきてくれ」と言う。それがたとえ一行のテキストだとしても。一行のテキストだとしても。一行。まがりなりにもIT企業なのにどうなってるのさ、いつになったらそこから脱却できるのさ、と思いつつも、「紙は見やすい。ノートPCやタブレットは見づらい」とか言われるともはやあきらめるしかない。一行なのに。
 そんなでもどうにかIT化で紙から電子に変えなきゃいかんなーって思っていた。そしたら日経の素晴らしい記事にどつかれた。
デジタル化は企業文化変革 負け犬にならないために
ドコモの執行役員の人が書いたそうで、それならこんなちゃんと時勢をつかんだものになるなーと感じた。

"日本企業の多くの従業員の理解は「紙の会議資料がなくなって決裁処理も電子化だな」とか「部門別管理会計では満足せずプロダクト別管理会計も導入するのかな」といったレベルだろう"
スミマセン…

"消費者と企業の接点は、店頭やマスメディアから離れ、スマートフォン上の人気サービスに移ろうとしている。消費者がどのように商品と企業ブランドを認知し、関心を持ち、購入に至るかの行程が変化している"

"米ドミノ・ピザは15年にデジタルにかじを切り、本社ビルに勤務する従業員700人のうち、300人がエンジニアとなった。注文方法充実化や発注データ解析による営業効率化を推進、売り上げはライバル企業を上回っている"

"ここ最近でGEが学んだことがある。それは、20年前に多くの産業界の企業が行い、現在も続いているIT業務のアウトソーシングは、今日においては負け犬の戦略であるということだ"

 個人的にはドミノピザ本社の300/700人がエンジニアになったというのがビックリなのだが、そういえばゴールドマンサックスあたりでも似たようなことになっていると聞いた。もう、どうやって業務をITで効率化できるかってのを人を集めて開発とは別の場所で考えている時代ではなく、大量データをITドリヴンで処理して、そこから経営判断を行っていくとかって時代になっていた。そういう時代が来てるとかじゃなくてもうなっている。DevOpsとかの事例ってこういうところから来てるんだろうな。

 ぼくが高専に通っていたころ、インターネットというのが一般化した。パソコンを持っている家ではそれを使っていくらかのことができた。うちにもパソコンはあったので、ヤフオクで自分のものや友達に頼まれたものをやり取りしていた。そのころはまだ、パソコンの前に座るという手間があった。
 今はガラケーを経てスマフォ、タブレットの時代になった。もはやパソコンの前に座る必要がなく、多くの人がいつでもどこでもインターネットを使える端末を携帯している状態になった。家に帰ってからしかできなかったヤフオクがいつでもできるようになった。それだけではなくSNSも浸透した。サービスも広告もそのプラットフォームを無視できないどころか、そこを第一ターゲットに考えるべき状況になっていた。ITは消費者の家にあった時代から、もう消費者個々の手元にある。ITを駆使できれば、多くの消費者に直接リーチできる、すぐに。

 いま、サービスを考える業種というのは面白そうな気がしてきた。もう10年前よりずっと多くの人をターゲットにできるようになっている。開発側も多くの人へより洗練されたサービスを届けようと、改良の速度を高めてイテレーションする手法の事例がどんどん出てきている。うまくクラウドやツールを使うことでどんどん開発手法が加速している。そう考えると、すでにもう息切れして止まっているのはやばい。神エクセルよさようなら。
comment: 0

TDD

 一時期「TDDは死んだ」なんて記事が話題になった。
テスト駆動開発(TDD)はもう終わっているのか? Part 1
「TDD、いや、テスト自体がウチには合わない」なんて話を直接耳に入れたりもした。そういう環境ではそうなんだろうと思う。銀の弾丸はない。

 ぼくはTDDをかなり気に入っている。最初にテストを書き、それにパスするようにコードを書いていく。炎上中のプロジェクトにアサインされたときになぜだか個人的に使い始めたのだが、結果としてうっかりなミスやデグレードを防いでくれた。プロジェクトで見ればそのうっかりやデグレードが頻発していたが、ぼくの担当したところに対して差し戻しはなかったので、TDDによって品質をかなり高いところまで持っていけていたんだろう。
 はじめてのTDDを炎上中のプロジェクトへアサインされたときに実践したというのは、時間的な制約から一見無謀だと捉えられるかもしれない。けどぼくはこれが成功だったと考えている。一つの機能の実装が終わったときに自動テストが用意されていなければ、ふつうなら手動でテストを行うだろう。デグレードを考えるなら、行うべきテストは機能が増えるたびに累積されていき、後半ではテストを行うコストが無視できないほど肥大化してくる。ぼくはTDDによってテストを自動化していたために、累積されるテストコストをうまく回避できたと考えている。

 ぼくはTDDにそれほどの厳格さは適用していない。自分が自信を持てれば十分という位置づけで行っている。ユニットテストは自分が適切だと思うレベルでしか書かない。カバレッジ100%にする必要はないし、70%を切るようでも場合によっては全然かまわないと考えている。つか今趣味で開発しているものはカバレッジを参考にしていない。
 テストも機能実装中に刻々と変化する。自分が好きで作っているものにしろ、クライアントのためのものにしろ、仕様が変更されるってのは皮肉なことにしょっちゅうある。さらには、自分のものだとテストを書きながら仕様を決めることだってある。刻々と仕様が変わろうが、ぼくはあまり粒度の高いテストは書かないので、テストの変更は大したコストにならない。
 たとえば今、この自作のブログのエンジンを開発しなおしている。TDDで。最初にまずログイン機能を作ることを決め、書いたのはSeleniumを使ったテストである。テストは二つで合計20行から30行ぐらいだ。厳格にやるならログイン機能をに内包されている、トークン取得やトークン付与を単体テストで書くべきだろうか。さすがにそこまでやるのは手間だ。それらが協調して動いていることは、ログインの成功と失敗が確認できれば十分実証される。だからSeleniumでそれを行うテストを書いた。これから機能が追加されていくが、これ以降でログイン機能が正常に動くかを確認するのにかかるコストは、10秒程度の時間コストしかかからない。

 過度にカバレッジを上げたり、すべてのメソッドに対して単体テストを用意しろなんて命令が来たら賛成しかねる。でもTDDってそういうのを強制するものじゃないだろう。ただ自分の自信になる程度にテストを書き、のちのちのデグレードチェックの手間を省いたり、リファクタリングを安全に進めるための補助として役立てる。すごくいい仕組みだと考えている。銀の弾丸ではないにしろ、ぼくはこれを適用できるところには使っていくし、適用できるできないの判断をうまくできるようになっていこうと思うところ。
 
comment: 0

個人的にはExcelでドキュメント作るの勘弁してほしい

 Excelでドキュメント作るの勘弁。代替案を挙げるならマークダウン。マークダウンで書いて、バージョン管理して、閲覧はHTMLあたりに変換されてたら最高。マークダウンを覚えるコスト?その程度はコストを払えという話。
 Excelでドキュメントを作るのが気に入らないところ。
・そもそも表計算ソフトやん
・Gitとかでバージョン管理しても変更履歴追えないやん
 バージョン管理してないと、誰かが手違いの変更を手違いで保存したら面倒なことになる。
 ぼくの知っているところではある環境の設定がExcelでまとめられているんだけど…設定値のコピペがやりづらい。セルのサイズが調整してあるのかわからんので、あるセルを一目見た状態が内容をすべて表示できているのか、表示されているセルのサイズの外に内容を隠しているのか判断できん。こんなんドキュメントに向いてないわ。
 朝からくだらんものを書いた。
comment: 0