現地企業で働き始めて三ヶ月。日本と比較してみる その1

どうもです。

ギリギリです。

 

ブリスベンへの飛行機通学がようやく終わりました。

いまはインターン期間。といっても普通に働くだけで特別なことしない。

今の仕事がインターンの代わりだからOK。

 

今週はシドニーで開催中のNDC(http://ndcsydney.com/)に参加中。

仕事の一環で来ていて、水曜~金曜までひたすらトークを聞きます。

C#やNet Coreなど、マイクロソフトの製品や技術に関するものが多く、他にはAngularやReact、BigQueryなどいま流行りの技術に関するトークも多いです。

有名な人も多く来ていて、興味深いトークがいっぱい。

参加費が3日間で3600ドルと、とても個人では出せないような額なので、この貴重な機会を無駄にしないよう眠い目をこすりながら朝9時からがんばってます。

 

ちなみに費用は全て会社もち。

カンファレンス参加費も宿泊費用も食費も全部(飲みに行くのはさすがに自分持ち)

火曜の夜にシドニーについて、使ったのは電車代6ドルと新しく買った靴140ドルだけ。

 

カンファレンスの会場はヒルトンホテルで、宿泊先もヒルトンホテル。

一人280ドルくらい。会社割引がきいとるみたい。

普通だと1泊550ドルくらいするみたい。たかすぎ笑

 

ちなみに人生初のヒルトン。

ベッドがでかすぎて対角線上に寝ても余裕。

 

ここで一生暮らしたい笑

 

 

 

 

 

現地企業で働き始めて三ヶ月

さて、5月上旬から今の会社で働き始めて約3ヶ月。

こちらでの仕事は、日本でSEとして働いとったころとは全く違います。

 

今日は日本での経験とこちらでの経験をまとめてみます。

 

 

プロジェクトの管理と体制

日本ではウォーターフォールでのプロジェクト管理しか経験しませんでした。

それ以外の開発方法をそもそも知らんかった笑

 

体制は、プロジェクトリーダー、サブリーダーとその他使い捨ての兵隊たち全員。

リーダー、サブリーダー、その上(マネージャー=特に何もしない上の地位におる人たち)が話し合い、彼らが決めたことにその他全員が従って働くという構図。

 

 

リーダーは基本すべての工程にガッツリ食い込んでいる人。設計、ドキュメントの作成、コーディング、テストも担当/しきったり、顧客とミーティングしたり、もちろんプロジェクトの進捗状況の確認、問題やリスクへの対応と、とにかくなんでもするというめちゃくちゃな役割。

当然のごとくリーダーに過剰な負担がかかり、それが当たり前という状態が普通。

 

 

オーストラリア(今の会社)では、アジャイルの概念に則ってプロジェクト管理をします。

うちの会社ではスクラムを使って管理中。

ほぼスクラムの概念に沿っとると思う。スクラムマスター=チームリーダーかな、うちの体制だと。

 

メンバーは、スクラムマスター、プロダクトオーナー、他のチームメンバー。

 

スクラムを知ってる人ならわかると思いますが、

チームが主体なのでリーダーに過剰な負担がかかることがないです。

スクラムでは、チームメンバー一人ひとりが自分で考え、コミュニケーションを取り、みんなで協力し合いながらそれぞれが自分の力量でできることを1つずつ片付けていきます。

 

基本的にチームが決定権をもってるから、リーダーがすべてを決めるということがない。

リーダーはチームの目標や目的を定め、そこに最短でたどり着けるよう取り計らう役目を担っている。

 

メンバー同士で決めきれないときはリーダーまたはプロダクトオーナーが決断を下します。

 

このやり方、進めやすいと思う。オレはこの方が好きだな。

 

 

開発メンバーは、シニアエンジニア、エンジニア、ジュニアエンジニアがいて、それぞれ担当する作業が違う。難易度が高いものは当然シニアエンジニアが担当。

うちのチームは大きくフロントエンド/バックエンド担当と役割がわかれていて(コレは日本でもよくある)、それぞれのエンドにシニアエンジニアが最低一人いて、全体をみています。

他のメンバーは、アーキテクト(バックエンド)、ビジネスアナリスト、(シニア)テストエンジニア、DevOps エンジニア、プロジェクトマネージャー。

 

ちなみにオレはちょっと特殊な立ち位置にいて、フロントエンドとバックエンド両方担当。

メインはフロントエンドで、バックエンドの一部も担当。

どっちもできるから、両方に手入れが必要な場合でも全部一人でできることがよくあるから嬉しい。

 

 

体制に関して日本と決定的に違うのは、とにかく一人ひとりの役割がはっきりしていること。

特にいいなと思うのは、顧客のビジネスフローやビジネス要件を調査、分析、解釈してそれをエンジニアに正しく”翻訳”して伝える専門家たちがいること。

 

日本ではマネージャーやリーダー(ほぼリーダー)がこの役割を兼ねていました。

 

 

いまの体制では一人一役が基本だから、作業に集中しやすい。

 

もちろんオーストラリアでも小さな会社ではこんなに細かく別れてなくて、一人で数役こなすようなところもあります。

でも基本的にはどの会社でも役割を明確に分けて、それぞれのポジションごとに人を雇います。

実際、こちらの求人の要項にはその役割に必要なスキルが明示されてます。使用する言語、フレームワーク、DB、バージョン管理ツールなどとともに、これらを使った何年以上の開発経験があること、って感じで書いてあります。

求人のタイトルにもポジションが明記されてます。テストエンジニア、シニアエンジニア、フルスタックエンジニア、チームリーダー、その他もろもろ。

 

 

 

開発の進め方

これは日本とオーストラリアというよりは、ウォーターフォールとアジャイルの違いというべきもの。

 

アジャイルとウォーターフォールが何かよくわからない人は、このページを見ると理解できるはずです。

http://www.nec-solutioninnovators.co.jp/column/01_agile.html

 

ウォーターフォールは知っての通り、各工程を完了させて初めて次の工程に進むのが通例。

 

でもうまくいくことなんてないから、単体テストは抜きで結合からやろうとか、ドキュメントの完成は終わってからでいいとか、そういうのが日常茶飯事。

 

設計段階では当然、すべてを完全にミスなく設計することなんて不可能。

だからコーディングが始まると不都合がぼろぼろ出てきて、設計し直し、ドキュメント修正、コーディング再開、また不都合や漏れを見つける、設計の見直し・・・と、この繰り返し。

 

ウォーターフォールは基本変更を嫌うから、途中で仕様変更が入ると本当に面倒。

 

客が、一度確定した仕様を開発開始後に平気で覆してきたり、仕様変更をタダで求めてきたりすることもあった。

でも営業が弱いと、客からの信頼がほしいから無理な注文にもYESと言ってしまう。

結局苦しむのは開発者。

変更した分工数が増えるけど、リリース日は変わらない(変えようとしない)からね。

 

 

設計漏れやミスで予定より工数が増えるケースがほとんどんだったな、残業の原因は。

でも当然リリース日は動かない(設計漏れでは動かせない)から残業が増え、時間がないからコードレビューや単体テストをすっとばすして、結局それが悪影響を及ぼし、低品質のシステムができあがる。

 

日本ではこの繰り返しが多かった。

 

 

 

でもウォーターフォールも悪いところばっかじゃない。

基本的に仕様はすべてドキュメント化されているので、それに従って黙々と作業すればいい。

だからある意味簡単。ただ従えばいいだけだから。

よく設計されたシステムで、かつよく準備、計画されたプロジェクトだとけっこうラク。

 

でもリーダーとしては最悪の開発手法やと思う笑

 

 

一方アジャイルはインクリメンタルかつイテレティブな開発をする。

例えると、小さい雪のたまを作って、それをコロコロ転がしてだんだん大きくし、最終的に作りたいもの=雪だるまを完成させる感じ。

詳しくは上に載せたリンクにて。

 

スプリントという2週間単位の区切りで、タスクを終わらせていきます。

スプリントのはじめに2週間でできることを決め(基本ビジネスアナリスト(BA)やリーダーなどが決める)、終わったら反省会(レトロスペクティブ)で良かった点悪かった点をだし、それを次に反映していく。

 

各タスクは半日~数日の期間のものが大半。たまに1週間くらいのタスクも。

基本、自分のレベルに合ったタスクを自分もしくはシニアエンジニアの指示の下選ぶので、タスクをこなしやすい。

自分一人ではできないときは誰かに助けを求めてもOK。

 

 

でも最近は、アジャイルの良くないところも見えてきた。

アジャイルというよりチームの悪いところというべきかな。

仕様が口頭で伝えられるし、ドキュメント化しないから、前した議論を何度もしたり、

開発が進むに連れてある機能が何度も修正、変更されるせいで、それに依存する機能が何度も修正を強いられたり。

もっと効率のいいやり方をして、できるだけ手戻りが少ないようにしないと同じようなことを何度もすることになる。

あとは、他のタスクにブロックされて自分のタスクができないとか。

段取りがわるいと生産性がすごく悪くなる。

コレはウォーターフォールではあまり起きないと思う。Gantt chartとか使ってスケジュールが事前にきっちり組まれるから。

 

 

 

ドキュメント

日本でかかわった殆どのプロジェクトでは、ドキュメントが納品物に含まれていました。

誰も読まない基本設計書や画面設計書、DB設計書、詳細設計書などをひたすら書いてはなおし、書いては直ししたり、または全てが終わったあとに後付けで慌てて書いたりする。

コードと仕様書に食い違いがあったり、間違ってたり、漏れてたりすることが多いので、基本ドキュメントは信用しなかった。

 

 

アジャイルでは、納品物の完成に力を入れ、それ以外のことは極力しないのが基本。

だから、納品物ではないドキュメントの作成はほとんどしないです。特に開発者は。

 

ドキュメントはパワポで作った内部資料が大半で、これらはほぼ仕様書。

設計書はないです。画面設計書も基本設計書も詳細設計書もない。

JIRAを使ってタスクを管理しているので、JIRAのタスク(チケット)に概要やユーザーストーリーを書いて、設計書はなし。開発者がBAやリーダーと話しをしたり、図を書いたりして画面や細かい使用を決めていきます。

 

画面はUX/UIデザイナーがBAやリーダーと話し合ってたたき台(=モック)を作り、

デザインが確定したらそれをHTML&CSSで実際につくり、デベロパーに提供。

デベロパーはシニアエンジニアを中心に、画面をみながら他のメンバーと話し合いながらシステムの構造を決めて、実装を開始する。

途中ホワイトボードとかに書いたりはするけど、設計書は一切作りません。

 

設計書かかなくていいから開発がほんとにラク。

 

ありがちなWeb APIの仕様書もないです。その代わりにSwagger使ってます。

今の会社に来てSwaggerの存在を初めて知った。これほんといい。

コードを編集すればSwaggerライブラリが上のリンクにあるようなページを自動生成してくれるから仕様書書かなくてもいいし、使う人はSwaggerで使い方わかるし、いいこといっぱい。開発がビビるくらいはかどる。

 

 

もちろん必要に応じてドキュメントは残します。

例えばコーディングルールとか。といってもネットにあるものをコピーして一部書き換えるだけだけど。

あとはシステムの構造を図解したものとか、大事なディスカッションの経緯と結論とか。

うちの会社だと、AngularかReactかどちらを使うかで火花が散っていたそうです(結局Angularを選んだ)。

 

 

テスト

日本でオレが働いていた会社は単体テストのやり方がほんと酷かった。

オレのいた会社では単体テストケースをエクセルに書いて、それをVisual StudioやEclipseでステップ実行してテストをするという恐ろしく非効率なことをしていました。

 

受注元の会社がテストのカバレッジを気にするので、ロジックのない単なるコンストラクタや幾つかのメソッドを呼ぶだけのメソッドなども含めてすべて網羅しなければならなかった。

当時はそれが当然だと思ってやっていたけど、今思うと無駄にしか思えない。

カバレッジはテストの質とは関係ないんだし。

 

 

バグの件数も帳尻合わせしていた気がする。

単体であんまりバグがなくて、結合で予定より多く出るとテストちゃんとしてねーとか文句言われるのがいやで、単体試験のバグ表に適当にバグ書いたりしたこともあった。

社内外で決められた指標値にさえ合致すればOKみたいな考えで、疑いを持たずやっていたと思う。

 

 

今の会社では、ユニットテストで最低限の品質を保証。結合試験は今のところ不明。未実施。

うちではTeamCityを使ってビルド、テスト、デプロイメントを自動化してます。

 

開発者はリポジトリにプッシュする前にかならずユニットテストがすべてパスすることを確認する義務あり。

フロントエンド、バックエンドともにユニットテストコードを書くから

途中で何処かが壊れるとすぐに分かる。

この当たり前のことを日本ではやれなかったから嬉しい。

 

今後、シニアテストエンジニアとのからみが出てくると、さらにテストが充実すると思う。

 

日本ではテストを専門にする技術者にあったことがなくて、テストの質は開発者とリーダーの知識に完全に依存していました。

いま思えば、結合試験を一番重要視していて、単体試験はまともにやってないことが多かったし、やってもその質をいちいちチェックする人はいなかったな。

 

 

 

 

まとめ

日本での経験とオーストラリアでの経験は、何から何まで全然違います。

どちらがいいかと聞かれたら言うまでもないです。

 

はっきりいって、いまの職場が劣る要素が皆無。

 

 

 

次回は給料や有給日数、その他待遇などに触れていきます。

 

この記事が気に入ったらシェア!
Share on Facebook0Tweet about this on TwitterShare on Google+0Share on Tumblr0Pin on Pinterest0

コメントを残す

メールアドレスが公開されることはありません。