どうもです。
ギリギです。
ここ3～4週間ほどずっと家にこもって仕事と勉強の繰り返しで、忙しいです。
今の仕事はJavaScriptを多用するのに、オレはプロトタイプ言語でのプログラミングを全然知らない。
こりゃーいかんということで、プロトタイププログラミングを学びつつ
オブジェクト指向デザインも本を読みながら本格的に勉強中。
英語の勉強は、IELTSのサンプル問題を解きながらボキャブラリを鍛えています。
オーストラリアと日本、何が違うのか
さて今日はソフトウェア開発の話。
オレは、今年の8月末からオーストラリアの大学で、ソフトウェア開発者として働いています。
今日は、日本でオレが経験したソフトウェア開発と、オーストラリアでの開発の違いを見てみようと思います。
ちなみに日本では、一般的なIT企業で使い捨ての兵隊プログラマとして働いていました。
いまは、大学でオープンソースのWebアプリを開発している最中。
働き始めたばっかで、2ヶ月ちょいくらいしか経験ないです。
企業で働く時に求められるものと、大学で働く時に求められるものは違うので、
ちょっと比較しづらいですが・・・話をしてみようと思います。
開発手法
日本：ウォーターフォールのみ
現在：アジャイルのみ
日本ではウォーターフォールモデルでの開発しか経験しませんでした。
自社の社員だけと仕事したこともあえば、他社のプロジェクトに参加して仕事したこともあったけど、
その中ではアジャイルのアの字もありませんでした。
自分の周りでアジャイルの話をする人は一切おらず、
今思えば、まるでウォーターフォール以外の開発手法は無いかのような感じでした。
まだアジャイルが広まっていない時期だったせいもあるのかな。
一方現在では、アジャイルが主流。
というか、ウォーターフォールを選ぶ理由がない。
今の自分の職場は教授やPhDの学生など、仕事以外のことをしているプロジェクトメンバーがほとんど。
突然学生の世話をしなきゃいけなくなったり、論文書いたり、
国外でセミナーするから1～2ヶ月いなくなったりと、状況がコロコロ変わるのが日常茶飯事。
だから、アジャイルのような柔軟な対応が取れる開発手法でないと管理できません。
オーストラリアの一般企業でもアジャイルでの開発はごく一般的。
仕事の求人を見ても、アジャイル開発での経験の有無を問うものが多いです。
個人的には、アジャイルの方が自由度が高くてやりやすいと感じます。
ただしウォーターフォールのようなきっちりした設計書がないぶん、システムの質がコミュニケーションや個人の力量に依存するから、その辺きっちりしておかないととんでもない時間の無駄になったりするかなあと。
いまはリサーチをしつつ新しいものを作るという、企業とはちょっと違う状況での開発。
自分たちで考えながら、相談しながら、新しいものを作っているので、
一般企業で働いたら違う答えになるのかも。
ちなみに、大学で勉強していたときは、ウォーターフォールについては昔のやり方のように紹介されていました。
テクノロジーの選定方法
日本：過去の実績重視。また、社員の知る技術（たいてい古い）でどうにかしようとすることが多かった。
現在：開発する内容により変わるが、基本的には最新の技術を使う。その技術に詳しい人を新たに雇って開発をすることもある。
たとえば言語やフレームワークの選定では、
社員が知っているから、今まで何度か使ったことがあるからという理由で
時代遅れのものを使ったり、古いバージョンのものを使ったりすることが多かったです。
どの技術がどのくらい有益かを合理的に考えている気配はほとんどなかったなあ。
あと、新しい技術を取り入れることを積極的に避けていた傾向もありました。
自社では、新しい技術＝実績がない、何かあると助けが求めづらい（ググってもでてこない、コミュニティがないなど）って理由で１～２世代古い技術や言語を使っていました。
とにかく安定、保守思考。
オレの働いていた会社のように、保守的で、かつ高いレベルの技術者がいない企業は
こういう選び方をしてるんじゃないかなあ。
大企業のプロジェクトだと最新技術使ってた気がするな。
企業規模が小さいほど保守的だったと思う。
こちらでは、どの大学でも基本的に最新の開発技術や手法を使って勉強し、そこで得た知識を活かして実際の現場での技術選定をしています。
（システムの深い部分、根本部分を知るような授業ではCとかC++使ったりする）
GitHubやTravis CI、Jenkinsと言った流行りで最新の開発補助ツールも積極的に使います。
言語やフレームワークの選定も、それぞれの技術の長短を比較した上で選定。
これが本来踏むべきステップなんだろうけど
日本では経験したことなかったので、なんだかちゃんとしてるなあなんて思ってしまう（笑）
コーディングスキル
これはまだ比べられないのが正直なところ。
ただ、職歴がない人や浅い人たちを比べると、こちらの人たちのほうがレベルが高い気がします。
ソフトウェア開発やデザインについてきっちり勉強してるし、それから仕事を始めてるせいか
まだ職歴がない人でもいろいろ知ってるし論理的だし、思考も速いし正確。
使う言語についてすでに知っていることが多いから、コーディングの速度も速い。
企業で働く人たちの平均レベルはこっちのほうが高いんじゃないかなあ。
テスト
これについてもまだ何ともいえないです。こちらではまだテストの経験がないので。
単体テストよりも実装の方が先に求められるので、
見た目上動いてるっぽいし平気だよね、くらいの、簡単なチェックしかしてません。
大学のプロジェクトなので、既存機能の品質よりも新しいものを生み出すことの方に重きが置かれてるようです。
自分としてはすごく嫌なんだよねこれ。
バグってるかもしれない機能の上に更に機能を作っていくって、気持ち悪くてしょうがない。
だからたまに黙って既存バグ直したりしてる（笑）
日本では試験表を作って、単体、結合、総合試験と順に実施、その最中にバグがでれば直して・・・というごく一般的な流れを経験。
うちの会社は単体試験にも試験表を作って、デバッグモードでコードをステップ実行し、
試験表通り実行されることを確認してました。
JUnitとか、その当時でもすでに単体試験ツールはけっこう世にでてたけど、
誰も取り上げる人はおらず。
単体試験とその結果が納品物に含まれてて、そのせいでJUnitが納品しづらいとかいって選ばなかったのかも。
よくわからん。未だに不明です。
他の企業ではツール使って試験してると思うんだけどなあ。
こちらでは単体試験はツールを使って実施することがごく一般的。
試験の実施は、自動ビルドや自動ユニットテスト実行環境を使うことが多いようです。
例えばGitHubを使う場合はTravis CIなどと連携して、ソースがリポジトリにプッシュされるとTravis上で自動でフルビルドと単体テストを実行、試験の実施忘れを防ぐとともに品質を維持。
Travis上で試験が実行できない場合はビルドを実施して、エラーがない状態を確認するなどの仕組みを作っています。
情報の機密保持とかで、日本の企業はこういうオンラインのツールとか使ってなさそうだなあ。
オーストラリアの企業もそうなんだろうか。
まとめ
自分の日本での経験と比較すると、開発手法からして違うオーストラリアのソフトウェア開発。
いまは大学という、リサーチ結果をもとに常に新しいものを生み出すことが求められる環境でのソフトウェア開発なので、企業とのやり方とは違うと思います。
しかし、それでも日本とオーストラリアでは違いがたくさん見られるのは間違いないでしょう。
企業で働いている人がいたら、ぜひ違いを聞かせてほしいです。
では！
私はメルボルンの地元の小さい製造業の会社で社内向けのソフトやウェブのプログラミングを長年書いています。私は日本での開発経験がないので日本とオーストラリアを比べる事はできないしIT企業で働いている訳ではないので私の経験は参考にならないと思いますが。。。私の会社でも近年(ゆるい)WaterfallからAgile方式に変えました。理由はやはりInstant Feedbackとスピードでした。会社開発なのでソフトとビジネスプロセスが密着しているため、Agileでステークホルダーのfeedbackを聞きながら開発を進める方が良いという経験からでした。あとは開発スピードが早く開発中でもMDやstakeholdersから次々と出てくるアイデアをどう形にしていくかを考えた時にやはりAgileだとなりました。テストも私は一応Unit TestやIntegration Testなど教科書に出てくるようなものに基づいてやっていますが、結局小規模の自社ソフトなので最後のEnd user Acceptance Testくらいしか重視されません。まさに実装でちゃんと動いていれば良いという世界です。ただしテストがいい加減なのでdeployment後にバグや不具合が見つかる事もありますが。。。
一つだけ日本との違いで絶対的だと思うのはこちらでは未経験のプログラマは職を得にくいという事です。結局実践で素早くコードをかける即戦力になれなければ中々就職は難しいと思います。
Toppoさん
コメントありがとうございます。
たとえIT企業でなくても、やってることは同じソフトウェア開発なので、十分参考になります。
実際ソフトウェアってのは、実物を見てやっぱやめたーとかこれがいいーとか言い出すものですからね。変化を歓迎するAgileの方が断然いいと思います。
顧客にとっては嬉しいし、開発者側にとっても、変化が当たり前という前提で働くので精神衛生上いいと思います(笑)
Integration Testは試験表（テストケースリスト？）を作ってやってるんですか？
大学でAgile開発学んだときは、テストの具体的なやり方を学ばず、未だに実践でどうやってるのか謎です。
そうですね、日本では文系とか、理系でもコンピュータ科学とは全く関係ない生徒が普通にIT企業でプログラマとして働いてるけど、こちらでは基本大学で習ったことがそのまま仕事になるって感じですよね。
即戦力にはなりづらい新卒はみんな仕事取るのに苦労してます。
こういうときはコネがモノを言うようで、強力なネットワークがあるインド人は学生のうちにさっさと仕事を見つけて就職してる人もいるくらいです。
特にインド人は英語レベルが高いので言語障壁がないし、よくしゃべるのでこちらの人たちとよりうまくやっていってる気がします。
日本人には不利です(笑)
私は日本に居たころ結構大きめの企業でソフトウェア開発に携わっていました。今はブリスベンの政府系企業でソリューションアーキテクトしてます。日本にでは主に大学病院向けの医療システムを開発していました。分野がニッチですがご参考まで。
日本では、所属していた企業が古い体質というのもありますが、社内で開発されたフレームワークやツールを使用して品質を保つような仕組みがありました。これはグループ企業間でも開発者の質とその技術の共有に役に立っていたと思います。ただ、社内製のフレームワークなのでアーキテクチャが古い場合が多く、新しい技術に対応するのが送れるという事もありました。だた、大企業の特性か、失敗しない、成功した方法論だけを採用するというような文化があったように思います。製品開発でもっともやっかいだったのが、仕様の整合性でした。これは病院関係だけなのかも知れませんが、政治的な理由での仕様変更が多く、その影響がアーキテクチャにまで波及する事がありました。また、仕様が曖昧であったり、他のファンクションとの整合性がとれていないまま開発におりてくることも多く、開発者は上とお客さんとの板挟みに合う事ともしばしばでした。日本にはスキルのあるマネージャとアナリストがあまり育っていないことも問題だと感じました。
オーストラリアでは、社内フレームワーク的なものもありましたが、製品の仕様が最優先されるため仕様に合わなければ必要なフレームワーク、ツールを外部から調達してきます。製品の仕様に関しても、まずはビジネスアーキテクチャのデザインからテクノロジーアーキテクチャに落とし込んで行くので、仕様の整合性と製品のビジネスバリューが担保されているように思います。アジャイルとウォーターフォールの使い分けも、やはり、製品の仕様と開発規模、また顧客のリソースによって、その都度ビジネスが判断します。プロジェクトを回すプロマネの質は日本とは比べるまでもなく高いです。これは、日本が年功序列的にプロマネになることが多いのに比べ、こちらは専門として訓練された人がそのロールにつく事によると思います。開発のリソースは今は外部のソフトウェア会社を利用する事が多いですが、そのスキルは人によってまちまちでしょうか。当然、スキルの高い人材はコストも高いですが、日本と比べると汎用的なスキルを持つ人が多いように思います。日本よりスキルが高いかと言うと、そう言う訳でもなく、やはりスキルの高い人はどちらでもいます。ただ、スキルの高い人材はオーストラリアの方が幸せになれるとは思います。テクニカルリソースとしての寿命も、日本はある程度の年齢になると捨てられる傾向にありますが、こちらは高い経験を評価されて技術屋のまま引退まで続けられる環境があるので、そういう意味でも幸せでしょうね。
テストに関して、日本はまだその方法論が貧弱だと感じます。オーストラリアではテストは専門職として、高いスキルと方法論を駆使して製品の品質を高めてくれます。また、テスターには高いアナリストスキルも求められ、仕様の策定段階から整合性に関する助言を行う事も良くあります。日本ではまだテストは開発者の作業と思われている部分があるので、この辺りはかなり遅れているのではないでしょうか。
色々と思った事を書きましたが、正直日本を離れて結構たっているので、今の日本の開発現場とはかけ離れているかもしれません。参考程度にと考えて頂けたら幸いです。
ハズ＆ワイフさん
コメントありがとうございます。
コメントを読み進めるごとに頷いてしまうことばかりです。
特にその通りと思ったのは、
＞日本が年功序列的にプロマネになることが多いのに比べ、こちらは専門として訓練された人がそのロールにつく事によると思います。
このの部分。
オレの勤めていた会社でもありましたが、経験積んできたからできるっしょ、というだけの非論理的な理由でほぼ自動的にプロジェクトリーダーになったり、いつの間にか部下を持つようになったりしてました。何の教育も受けてないのに突然放り込まれてやってみろってのはホントにおかしな話です。
あとテストについても全く同意です。こちらで初めてテスターのロールで求人があるのを見たときはびっくりしました。効率的・効果的なテストの方法、ぜひ学んでみたいものです。開発に役立てられそうです。
Hello. Self-same cool blog!! Man .. Excellent .. Superb .. I will bookmark your web place and obtain the feeds al82o#8&30;I&#s217;m pleased to attain numerous helpful data here surrounded by the send. Recognition for sharing.
経歴が浅いということはあると思いますが、
日本：ウォーターフォールのみ
は間違い情報です。
私もそれほど長くはないですが、SEとして11年目となります。
現在の日本では、ウォーターフォールより、アジャイル傾向があるのではないかと思います。
匿名さん
この記事は、自分の経験したことについて書いているので、日本全体がそうだという意味ではありません。
記事上でその点が明確になっていないかもしれません。
スクラムを始めとするアジャイル手法を、日本の企業が取り入れているのはブログなどで見ていて知っています。
オレが日本で働いていた2012年時点では、アジャイルを使っているプロジェクトをまわりで聞いたことなかったですが、いまはおそらく増えていると思います。
ちなみにこんな記事があります。
https://enterprisepathtoagility.com/scrum-does-not-work-here-in-asia-72d7bccccb4d
このとおりだと思います（日本で使われているかどうかは別として）。