自社開発案件のフロントのアーキとしてやれたこと、やれなかったこと
最近自社の受託の開発案件のフロント側のアーキみたいなことをやっていた。
アーキにはもう一人できる先輩が入って、その人はサーバ側も見ていた。僕はフロントしかやっていない。なので僕はフロントしか語れない。
アーキといっても普段僕(とできる先輩)は客先常駐の案件でお客様の現場に出ているので、常にプロジェクトを見れていたわけではない。
最初に基盤を作って、あとはちょくちょくリモートワーク。実作業の大半は社内にいる開発メンバーに任せた感じ。
その中でやってよかったこともあったし、反省すべきところもあった。
やってよかったこととか、やれなかったこととかまとめてみる。
構成
メンバー
- 要件持ってくる人 2人(PMO?とか言うのでしょうか)
- PM 1人(開発経験あってコード書ける人)
- アーキテクト 2人(できる先輩 + 残念な僕)
- 開発メンバー 2人(開発歴1年未満)
アーキテクチャ
- HTML5 + JavaScript
- AngularJS
- Bootstrap
使ったツールとかサービスとか
- Grunt
- Bower
- idobata
- GitBucket
- SVN(ほんとは使いたくなかった…)
やってよかったこと
AngularJSの採用
うちの会社はJavaエンジニアが多くて、フロントの技術で言えば、「JSPハァハァ」とか「tymeleafサイコー!」みたいな人は結構いる。(僕が話題に付いていける気がしないので、自発的にサーバサイドのテンプレートエンジンの話題を振ったことはない。なので実際は分からない。けど多分いる。)
だけどフロントのモダンな開発環境とか、クライアントサイドMVCとかに興味がある人はあまりいない。(少なくとも僕は聞いたことない。)
もちろんAngularJSなんて実績がないので、そもそも経営陣のオッケーが出るか微妙だったし、開発メンバーの学習コストがかかってしまうのも懸念だった。
しかし、結果的にそれらは杞憂だった。(と思うけど、実際に開発メンバーに聞いたら怒られるかもしれない。)
後で人づてで聞いた話によると、要件持ってくる人(部長)が開発者(僕たち)の想いを汲んで、経営陣へ伝えてくれていたらしい。 それが説得というコンテキストだったのか、あるいは経営陣が開発者の想いに理解を示したからなのかはそこまで聞いていないので分からないが、とにかく何事もなくAngularJSは採用された。(飲み会のときに直接聞けば良かった。。今度聞いてみよう!)
会社として実績がないことでも、チャレンジさせてもらえたのはありがたいことだ。
AngularJSに関しては、想定していたより随分学習コストは低かったと思う。
最初に開発メンバーに僕が理解できている範囲で、基本的な概念は伝えた。
他の実装の細かい部分に関しては、都度聞かれたことに答える程度で済んでしまった。
もちろん開発者が有望だっただけなのかも知れないけど、これはうれしい誤算だった。
AngularJSの良いところはいっぱいあるけど、コードのメンテナンス性という観点においては、その仕組みに従って作っていくだけで未熟な開発者であってもある程度きれいな構成に仕上がるのが良いところだと思う。
具体的には、以下の2点を守ればそこまで大変なことにはならない。
- controllerでは絶対にDOMの操作をしない。(それはdirectiveのお仕事。)
- controllerにコードを書こうとした時に、一度directiveやfilterでそれが実現できないかを考える。なるべくcontrollerにはコードを書かない。(fat controllerにしない。)
この2点を意識しておくと、自然とモジュール分割されて、見通しは良くなり、後でリファクタがしやすくなる。
Gruntによるフロント開発ワークフローの整備
普段からフロントでバリバリやっている人にとっては、Gruntは当たり前のツールだ。
なのだけど、AngularJSのところで述べたとおり、うちの会社のフロントエンドの開発文化はまだまだ洗練されていない。
そこにGruntを導入したのだけど、これは上手く浸透した。
普通のというか、yeomanで最初に作ってくれるタスクをほとんどそのまま使ってた。
追加したのはサーバで返すレスポンスをモックしたぐらい。(stubbyを使った。)
一覧にしてみる。
- Gruntで開発用サーバを立てる。
- サーバで返すレスポンスをモックする。
- コード修正時には、livereloadでリアルタイムにブラウザに反映させる。
- livereloadのついでにlintやspecも走る。
- デプロイ時にはminifyする。
従来よりストレスレスな開発は実感してもらえたんじゃないかなーと思う。
bootstrapの採用
開発者がデザインを担当するということは、bootstrapの登場によって大分現実的になった。
(最近読んだこの記事面白かった。ウェブサービス開発の現場におけるデザイナー不要論と5〜10年後の生存戦略 - 情報建築家 石橋秀仁)
このプロジェクトにデザイナーはいないし(ていうか会社にいない!)、僕らは自分でデザインを書く必要があった。そこでbootstrap先生に頼った。
やはりbootstrapは偉大だった。
しかし、どうしてもbootstrapのデフォルトスタイルをカスタマイズしないといけないみたいな場面はあった。
そして今回はbootstrap.cssを直接読み込む形で使っていた。
bootstrap.cssをリポジトリに持ってきてメンテナンスしていくみたいな形にするのは、「ツラ過ぎ、ワロえない。。」な未来しか見えなかったので、その都度独自のルールセットを作っていく道を選んだ。
次はbootstrap-sassとか使って、前提からメンテナブルな土俵で戦うべきだと感じた。
もっと情熱があれば、レスポンシブだけ採用して、スタイルは独自で作っていくという道も面白いかもしれない。(命名規則はBEMにしたい。)
idobataの採用
最近は開発フローの中で、チャットの重要性はどんどん増している。
slackが超バズってたりする。
うちの会社はチャットツールに何を使うかは模索中みたいな感じで、チャットワーク使ってたりするチームもあるみたい。
そんな中、このプロジェクトではidobataを使った。
idobataは使い勝手がかなり良い。シンプルなUIで、かつ必要とされる機能に不足はない。
アイコンが表示される時点でhipchatより良い。(冗談です。)
個人的にはすごく好きで、社内のPJでもっと使っていって欲しいなー、と思ってるけど、どうなるんだろうなー。
(現在はβ版で、当面の間無料だそうです。試すなら今のうちです。)
やれなかったこと
スタイルガイドを作ってない
最初はアーキの2人だけでモックを作っていた。
必要なところはidobataで話し合えたし、その時はまだbootstrapのデフォルトスタイルだけでなんとかなったし、何より2人だけだし、ってな感じでスタイルガイドを作る必要性を感じられなかった。
なので放置した。そして、いざ開発メンバーが入って本格的にソースいじり始めたら一気にカオスになった。(特にCSSが。)
スタイルガイドは最初から作っておくべきだった。
特にCSSは名前空間や修飾子でスコープ区切ったりできないので、見通しをよくすることはすごく重要。
ジェネレータはstyledoccoを使おうと思う。
あと命名規則はBEM使う。(2回目)
SASSを使うべきだった
CSSをメンテナブルに保ちたければ、SASSを使うべきだ。かつ普通にCSSが書ければ、学習コストは少ししかかからない。
ということがこのプロジェクトに着手し始めの僕にはあまりに理解できていなかった。
次は使うと心に決めた。
チャットを開発フローに組み込めなかった
このプロジェクトではチャットを開発フローに組み込むというところまで環境を整備できなかった。
チャットは情報共有のツールにしかできなかった。
最近ではチャット駆動開発なんて言葉も聞くぐらい、チャットを開発に組み込むことによる利点は大きい。
この記事とかすごく憧れる。
インフラの継続的デリバリー - naoyaのはてなダイアリー
ここまでいかずとも、コミットログや、push時にlintやspecを走らせて結果を通知したりするだけでも開発ワークフローは随分良好になる。
今までlintやspecをあまり意識していないメンバーも、ちゃんとやるようになる。(僕がそうでした。)
整備できなかった原因はいくつかあるけど、アーキテクトメンバーの作業がほとんどリモートだったことが大きいと思う。
CIといえばイントラにjenkins立てて環境整備していくという道がまず思い浮かぶ。
しかし0からこれをやっていくのは、リモートワーカにはハードルが高かった。
SaaSなサービスを使えばどうだろう、とも考えた。
しかし使いたいサービスが無料じゃなければ、当然ながら経営陣を説得するというプロセスが発生する。
既に期限付きで走り出しているプロジェクトに、そのプロセスは辛い。
現在β版で無料のwerckerを使えてればやりやすかったと思うけど、うちの会社はGitHubもBitbucketも使っていない。
今回はGitBucketを使った。
GitBucketはGitHubクローンのプロジェクトで、イントラにGitサーバを立てられる。
これは素晴らしいプロジェクトで、GitHubのプライベートリポジトリ使いたい!とかなかなか経営陣を説得するのが難しい状況では非常にありがたい。ほんとにありがたい。最高!
けど残念ながらwerckerは使えない。お金を出して、CircleCIにしてももちろん使えない。
イントラにjenkinsという道でも、作業を洗い出して、開発者に振れれば何とかなったかもしれない。
これは課題だ。だけど憧れの世界が目の前にあるのでモチベーションは高い。
大変だったところ
社内の開発環境と自分の開発環境の差異の吸収
アーキテクトは自宅のMacで、社内の開発メンバーは社内のWindowsで開発してた。
この開発環境の違いは様々な問題を引き起こした。
Gruntタスクに組み込んだproxyの設定が動かなかったりした。
なぜかHTMLにBOMが付与されておかしくなったりした。(これはWindowsの問題じゃないのかも?原因はよく分からなかった)
WindowsでGitを使えるようにする時点で既に一手間なのはつらい。
というかWindowsなんて開発に使うべきじゃ(rya
さりとて「Mac買って♥︎」ってねだってもさすがに「ダメ♥︎」って言われるだけだし、ひとまずVirtualBoxでUbuntuで開発とか、そういう世界が現実的だろうか。
(でもそもそも開発者にWindows使いたいって言われたらつらい。。)
リモートと開発現場との情報共有
これはやっぱり限界があって、何か問題があれば業後とかに自社に帰って血の涙を流しながらデバッグとかした。
自宅で調査して、コミットしときましたー程度で済むならまだいいけど、開発環境の違いで発現する現象とかだとつらい。だからWindowsなんて使うべきじゃ(rya
あと質問に電話で答えるとかつらい。会話の途中でステータスコード400とか返して電話を切りたくなる。(これは僕の理解力と、説明力にも問題ある。)
リモートワークの問題というか、もっと根本的なところを見直すべきだったと思うけど、どうすればいいのか僕の中で答えは出ていない。
残念なところ
gitからsvnに退化してしまった
最初は前述の通りGitBucket使って開発してたんだけど、途中でsvnになってしまった。
PMがそっちにしたいって言ったのだけど、よく理由が思い出せない。管理が楽だからとか言われたような気がする。
その当時は大体基盤を作り終わって、作業のほとんどは社内の開発メンバーに任せていたこともあって、多分その話に脳みそのリソースの半分も割いていなかった。
今考えればせっかくgitで作っていたプロジェクトを、滅び行く運命のsvnに移行するなんて、開発者目線からするとあり得ない。
でも実開発メンバーから不満も上がらなかったのであれば、そこまでgitが良いと思われていなかったのかも知れない。
開発メンバーは前述の通り開発経験はまだあまりない(1年未満)ので、そう思われてしまったのであれば伝えきれなかった僕らの責任だと思う。
色々大変なので、svnを使う世界は排除したい。
PMが開発してた
そもそも開発のリソースが足りていない問題。
幸か不幸か、PMは頭が良くて開発経験もあってコードもバリバリ書ける人なのであった。
個人的にプレイングマネージャが悪いことだとは思わないし、できるならやればいいと思うけど、このプロジェクトではあまり良いことではなかったと思う。
というのも社内の複数PJを見なければいけない立場の人だったのだ。
大変そうだった。
チームとして自己組織化できてなかった
リソースがそもそも足りていないこともあって、開発メンバーは日々のタスクに追われていた。
その結果、自己組織化は出来ていなかったように思う。
CIをちゃんとまわそうとか、ビルド周り整理しなきゃ、とかそういうタスクが現場から上がることは残念ながらなくて、その辺はPMが困った時に相談に来るみたいな感じだった。
(もちろんアーキテクトの僕らがそこまで整備して渡せていれば良かったのだけど。)
もっと開発メンバーとコミュニケーションを取ることに注力するべきだったかも知れない。
開発メンバーにlintやspecを実行する習慣を根付かせられなかった
自宅で作業しようと思ってソースコードを最新にして、lintチェックかけたら100個ぐらいエラーが出るとか、うんざりしてしまうことがよくあった。
これは前述の通り、CIをちゃんとやれていなくて、チャットにlintの結果を通知したりもできていなかったのが大きい。
そこまでできていれば、きっと良い方向に向かっていたはず。
反省。
他に次回のPJで挑戦したいこと
- TypeScript
- チャット駆動開発
終わりに
思いつくままに書いたら長くなってしまった。
僕自身アーキテクトとしての経験はあまりなくて、振り返ってみれば反省はかなりあった。
だけど色々考えるのは楽しい。
次回に活かしていきたい。