転職して感じたウォーターフォール文化とアジャイル文化の違いについて - 達人プログラマーを目指して
今月から新しい会社に転職して、あっという間に半月が過ぎてしまいました。いろいろな会社の規則や、開発環境、フレームワーク、仕事の進め方など、とにかくたくさんのことを短期間で詰め込む必要があり、もともと想定していたことではありますが自分としてはかなりたいへんでした。 やはり、自分としては、外資系の会社で英語でのコミュニケーションが必要となるということが、最も気がかりなことでした。実際、初日の歓迎ランチはいきなり名前もわからない多くの外国人に囲まれる状況でしたし、電話会議を使って中国やアメリカのチームと一緒に行う日々の進捗ミーティングも英語で行われています。自分としては、特に、リスニングが苦手ということもあり、いまだに完全に会話についていくのが困難なところはありますが、同僚やマネージャーもみんなすごく親切に教えてくれるので安心しました。私は新しい環境に慣れるのに結構時間がかかる方なので、まだまだ
アマゾンにおけるソフトウェア開発の仕事について感じたこと - 達人プログラマーを目指して
ちょうど、先日アマゾンのオープンハウスというイベントでお話をさせていただく機会があったのですが、開発者向けの20日のセクションだけで90名近くの方々にご参加いただきました。平日にもかかわらず、多数の方々にご参加いただき、どうもありがとうございました。 私自身は、昨年秋にSIerからアマゾンに転職してまだ半年ですが、この機会にアマゾンにおけるソフトウェア開発の文化や考え方について、ブログでご紹介できる範囲でまとめてみたいと思います。 私は、ずっとブログに書いてきたようにSI業界からの転職だったのですが、一般的なSIerにおけるソフトウェア開発の考え方や手法といろいろな面で違っているということは予想していたというか、もともと覚悟の上での転職でした。それでもやはり最初のうちはあまりにも大きな変化に自分の仕事のスタイルを合わせるのにいろいろと苦労しました。基本的には転職したての頃に抱いた感想（転職
Javaの型パラメーターに対してstaticメソッドを呼び出した場合の挙動 - 達人プログラマーを目指して
以前にJavaの配列関連で調べたことがあったのですが、Javaの総称型は型消去によって直感的でない挙動をする場合があります。 Java言語のClassクラスが持つちょっと不思議な性質について - 達人プログラマーを目指して Java5の型システムを理解するにはリフレクションAPIを使ってみるのが最短の近道になる - 達人プログラマーを目指して 特に、総称型の型パラメーターTについては以下はコンパイルできないという制約があります。 new T() new T[配列サイズ] catch (T ... extends T T.class instanceof T また、staticメソッドやstatic初期化ブロック内でクラスの型パラメータを使えないという制約もあります。 AngelikaLanger.com - Java Generics FAQs - Type Parameters - An
日本のユーザー企業は忍者のようなプログラマーをもっと登用して重用すべきでは - 達人プログラマーを目指して
あの記事から一年、ひがやすを氏が以下のエントリーで、プログラマーとして、新しいサービスを作ることの難しさについて書かれています。 僕と君とSIerの生きる道 - yvsu pron. yas 確かに私自身は、サービスを作る側に回った(まだISIDにいるけど、ベンチャーで働いているようなものです)のですが、身を持って面白いサービスを作る難しさも経験しました。 面白いサービスを作るのはほんとうに難しい。その後、マネタイズにも成功するのはさらに難しい。サービスを作る側に回って成功するのはほんの人握りの人なんです。 もともと一年前におっしゃっていたことは、SIerのビジネスに将来性はないから優秀なプログラマーは自分でサービスを作る側に回らなくてはならないし、単によいコードを作れるだけでなくて、自分からアイデアを考えられるようにならなくてはならないということだったかと思います。一年前この記事を読んだ
エンタープライズ開発者が負け組として軽蔑される日本のSI業界って - 達人プログラマーを目指して
本ブログの記事に対して多くの皆さんからいただいた意見を総合すると、技術力のあるトッププログラマーにとって現状の日本のSI業界での仕事というのは、働き甲斐のない、魅力の少ない仕事として認識されているという残念な事実を思い知らされます。 オブジェクト指向の基本すらいまだにきちんと使いこなせない開発の現場 技術について勉強した知識をほとんど活用できないし評価もされない 無駄なドキュメント作成などに対する膨大な単純作業を強いられる いわゆる3K職場と言われるような過酷な労働と低い賃金 20年以上も前の仕事の進め方からあまり進歩が見られない 多重下請け構造によりユーザーに直接価値を提案するような仕事が難しい 多くの業務アプリケーション開発現場における体験を通して、以上のようなことが語られているということを考えれば、「業務アプリケーションのプログラマーは負け組だ」という意見が出てくることも当然のことか
ソフトウェアアーキテクトほど魅力的な職業はない！？（アメリカでは） - 達人プログラマーを目指して
ちょっと興味深い記事を見つけました。 大きく違う日米でのSEに対するイメージ | 日経 xTECH（クロステック） アメリカでは人気投票でバービー人形の新しい職業にITエンジニアが選ばれたり（プログラマーのバービー）*1、ソフトウェアアーキテクトがアンケートによるランキングでももっとも人気の高い職業となっているとの事です。（Best Jobs in America 2010 - Top 100 - Money Magazine on CNNMoney.com）*2つまり、子供にとっても実際に働いている大人にとっても、IT技術者は人気の高い職業となっているみたいです。アメリカでは日本と違ってIT技術者の地位が高いという話は以前からなんとなく聞いていたのですが、実際に職業の人気度がここまで正反対であるとはちょっと驚きました。平均年収は1000万程度らしいので、年収だけからするとそれほど極端にセ
ソフトウェア技術者軽視のシステム開発を続けるのはもう限界かもしれない - 達人プログラマーを目指して
つい先日、富士通がグループで抱える3万人ものSEを再教育して、職務転換を行う計画であるというニュースを知りました。 富士通の3万人SE職務転換大作戦は成功するのか？ - GoTheDistance 一つのシステムを複数の企業などが利用するクラウドサービスがこのまま普及すれば、顧客の要望を聞いて個別システムを作り込むＳＥは仕事がなくなり、余剰人員問題が顕在化するからだ。 クラウドの普及により、オーダーメイドでシステムをゼロから構築する必要がなくなり、そもそも顧客からの要件をまとめてシステムを設計するSEの仕事が不要になったり、基盤を構築、運用するエンジニアが不要になるということは、最近になってよく言われることであり、特に新しいことではありません。もちろん、クラウドの普及によって、これらの伝統的なSEの仕事が少なくなり、人員が余るという議論は間違いではないと思います。 ただし、一方でより本質的
開発コストや技術リスクを考えない「上流設計」がシステムの複雑化と大規模な障害の原因となっているのでは？ - 達人プログラマーを目指して
皆さん、明けましておめでとうございます。昨年の後半は私自身SI業界からWeb業界へ転職したことなど仕事環境の変化があり、ブログの更新頻度も鈍りがちになってしまっていましたが、本年もどうぞよろしくお願いいたします。 さて、ちょうど、一年前のお正月にはグルーポンのおせち料理事件が話題になっていましたが、私はおせち料理の品質とIT業界における品質の問題を絡めて、以下の記事を書きました。 グルーポンのおせち事件を受けてSI業界が本当に教訓とすべきこと - 達人プログラマーを目指して この記事では、一般にSIerによって開発される日本のシステムはあの事件のおせち料理のように、低い品質に甘んじているが、多くの場合、社内システムなどではそういった品質の問題が公に明らかにされることが少ないのではということを指摘しました。ただ、その時は私の希望も込めて 最近はOSSやクラウドなどの影響で社内システムもどんど
Javaのクラスとオブジェクトについて再度解説を試みる - 達人プログラマーを目指して
オブジェクト指向プログラミングの考え方については、今までこのブログでも何度か取り上げてきました。 [オブジェクト指向] - 達人プログラマーを目指して オブジェクト指向プログラミングはプログラミング技法のすべてではないとはいえ、Javaのようなオブジェクト指向言語で本格的なプログラムを作るには理解を避けて通ることができませんし、また、関数型言語など他のパラダイムの言語を利用するにしても、オブジェクト指向の考え方をまったく理解しないまま使いこなすということは困難でしょう。オブジェクト指向の考え方はデータ構造やアルゴリズムといったことと同様に、プロフェッショナルなプログラマーが理解しておくべき基本的な素養といってもよいと思います。実際、海外では募集要項でオブジェクト指向の理解を前提とすると書かれていることが普通ですし、プログラマーの面接試験で、アルゴリズムと並んでオブジェクト指向プログラミング
ここぞというときの集中力Upのために、ヘッドフォンで音楽を聴きながらプログラミングしましょう - 達人プログラマーを目指して
仕事や趣味でプログラミングしたり技術書を読みながら勉強したりする際には、言うまでもなく集中力を高めて維持することが大切ですね。職業プログラマーに必要な集中力ということには少なくとも二つの意味があるとは思いますが、 単純に正確に繰り返しキーをタイプしたり、Excelシートをひたすら埋めるような単純作業を一定時間以上継続する 新しいアルゴリズムの設計やリファクタリングのアイデアを構想する いずれにしても、自分の場合は寝不足だったり、周りの雑音で気が散ったりしてコンディションが悪い時にはあまり集中できずに、圧倒的に作業効率が下がってしまいます。逆に、調子よく集中できた時には時間がたつのも忘れて一気に仕事を片付けることができます。 もちろん、プログラミングで集中力を高めるためには、日頃から規則正しい睡眠や食事などが欠かせませんが、ここぞという時に一人で集中するにはヘッドフォンで音楽を聴くのが個人的
すでに定年を過ぎていますが、Amazonで引き続き達人プログラマーを目指すことになりました。 - 達人プログラマーを目指して
このたび9月末日をもってオージス総研を退職し、10月よりアマゾンジャパン株式会社に入社しました。今後はSoftware Development Engineerとして、日本をはじめ世界各国のAmazonのモバイルWebアプリケーションの開発を担当することになる予定です。 およそ7年間にわたり、前職のオージス総研ではソフトウェアアーキテクトとして、SOAやEAといった全社的なシステムのアーキテクチャから、上流のモデリング、Java EEを使ったアプリケーションの開発など、技術者として様々な経験を積ませていただきました。私自身はこのブログでも何度も取り上げてきたように、モデリングやオブジェクト指向といった技術を用いて、実際の基幹業務システムの設計などに活用することで、高品質で保守性の高いシステムの構築に貢献したいという思いがありました。そのようなシステムを構築、維持するためには高品質なアーキテ
SIerにはコード記述の自動化からビルド・デリバリの自動化へのトレンドの変化を理解してほしい - 達人プログラマーを目指して
ちょっと前にTogetterで作成したまとめに対して大きな反響をいただきました。 SIerは自動化する対象が違っているのでは？ - Togetter これは、私が Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation (Addison-Wesley Signature Series (Fowler)) 作者: Jez Humble,David Farley出版社/メーカー: Addison-Wesley Professional発売日: 2010/07/27メディア: ハードカバー購入: 3人 クリック: 141回この商品を含むブログ (23件) を見るを読み始めて、ふとつぶやいた をきっかけに始まったTL上での議論をまとめたものです。この本は、7月に行わ
JPAを使ったデータアクセスでポイントとなる永続コンテキストについて - 達人プログラマーを目指して
先週書いたエントリJava EE6標準の範囲でフルスタックのWebアプリケーションが簡単に作成できることを確かめてみました。 - 達人プログラマーを目指してで、Java EE6の標準仕様を使うだけで、かなりシンプルにデータのCRUD処理を行うアプリケーションが作成できることを紹介しました。ただし、前回は全体のアプリケーションを紹介しただけなので、細かい仕掛けについては解説しきれませんでした。今回は、前回に引き続き特にJPAを使ったデータベースアクセスの部分がどうなっているのかをもう少し掘り下げて解説してみたいと思います。 なお、この場で宣伝ですが、8月10日（水）にGlassfishユーザーグループの勉強会にてお話をさせていただくことになりました。 GlassFish Japan Users Group 勉強会 2011 Summer : ATND 私はJava EE6を使った開発について
Java EE6で単体テストや結合テストを自動化する方法について - 達人プログラマーを目指して
今週水曜日に、オラクル青山センターで行われたGlassfish Japanユーザーグループの勉強会でJava EE6のお話をさせていただきました。勉強会のスライドとビデオは以下のリンク先にあります。 Glassfish勉強会（JavaEE6について） View more presentations from Ryo Asai http://www.ustream.tv/recorded/16552906 今回は基本的に私がこのブログで書いてきたJava EE6関連の情報について紹介させていただきました。欲張って少し内容を詰め込み過ぎたところがあったかもしれませんが、Java EE6を使った単体試験や結合試験の自動化については、説明をスキップしてしまい、ちょっとわかりにくくなってしまいました。ここで、あらためてJava EE6上のアプリケーションのテスト自動化について簡単に補足させていただき
staticおじさん達に伝えたい、手続き指向とオブジェクト指向の再利用の考え方の違いについて - 達人プログラマーを目指して
何が良いプログラムかという点はもちろん人やコンテキストによって異なりますが、少なくともプログラマーとしての私の信念としては、 機能拡張や変更が容易なプログラム 単体試験によって正しく動作することの検証が容易なプログラム どういった内容が記述されているか理解しやすいプログラム といったものこそ、「品質の高い」プログラムが持つべき性質として、まず真っ先に挙げるべき事項であると考えています。もちろん、前提として顧客の要件に従うということは大切なことです。しかし、一般に要件は長期にわたって変更されるものですし、使い捨てのプログラムを除けば、プログラムを長期にわたって保守するコストという点も見過ごすべきではありません。したがって、ユーザーの目には触れない上記の性質をもっと重視すべきだと思うのです。 DRYの原理 上記のような性質を満たすプログラムを作る上で大切になってくる原理として、DRYの原理とい
Clojure言語基本の「き」（その２） - 達人プログラマーを目指して
前回Clojure言語基本の「き」 - 達人プログラマーを目指してに引き続き、Clojure言語を新しく覚える際にポイントとなる事柄をまとめていきたいと思います。 逐次実行 (do 式1 式2 ... 式n)の形式を使うことで、処理を逐次実行させることができます。最終的に一番右側の式の結果が全体的な式の結果となります。この方法は副作用の存在を前提としているため、純粋な関数型のプログラムに対する手続き型プログラミングへの抜け道となる危険性がありますが、ClojureからJavaを呼び出す場合などに便利な場合があります。 user=> (do (println "Hello") (println "World") (+ 1 2)) Hello World 3 また、doと似た構造は、（後から説明するように）letやwhenなどClojureプログラムのさまざまな場面で暗黙的に表れるという点も重
汎用のフレームワークがあれば業務アプリ実装にオブジェクト指向は不要という考え方は適切でないと思う - 達人プログラマーを目指して
前回のエントリいまさらですが、職業Javaプログラマーなら理解しておいてほしい「継承」の意味についてのブクマのコメントで、 すごく今さら感がｗ 最近の開発はフレームワーク使うことが多いようだから知らなくても作れちゃうと思ってたけど違うのかなあ。 という感想をいただきました。実際に、SI業界で多くの方々、特に、アプリケーション開発の下流工程を担当しない層の方でこのように考えている方はほんとうに多いのではないかと思います。確かに最近ではSalesforceなどの製品もありますし、CRUD処理を行うような見栄えの良い業務アプリケーションは非常に簡単に開発できるようになっているということはあります。また、Visual BasicやMS Accessなど気軽にアプリケーションを開発できるツール類は昔からありました。そして、業界構造などの理由からやむを得ない側面があるとはいえ、SIerの提供する多くの
やはり、私は今後もSI業界で達人プログラマーを目指したい - 達人プログラマーを目指して
SI業界（日本）のJavaプログラマーにはオブジェクト指向より忍耐力が求められている？に対して、実に多くの方々からコメントやトラックバックをいただきました。中でも、id:higayasuoさんのSI業界からはさっさと抜けだしたほうがいいの記事は、私としては非常にセンセーショナルかつショッキングな内容でした。私の頭の中の時計が2年前の状態で止まっていたというところあるかと思いますが、id:higayasuoさんは大手SIerにいながらSeasar2などのすばらしいフレームワークを開発され、業界でも珍しい私の憧れのプログラマー、理想像に近い仕事をされている方のように考えていたため、余計に衝撃が大きかったのだと思います。 もっといえば、プログラマも良いコードを書いていればいいという時代は終わった。これからは、プログラムをいかに金に変えるかどうかをプログラマが真剣に考える時代です。 新しいビジネス
いまさらですが、職業Javaプログラマーなら理解しておいてほしい「継承」の意味について - 達人プログラマーを目指して
正しく意味を理解している方にとっては、まったく常識レベルの話であり、何をいまさらと思われる方々も多いかと思いますが、大規模案件のレガシーコードなど、私が仕事で見かけるJavaのコードを読むと、「このコードを書いたSEやPGの方々は、はたして継承の意味を正しく理解していないのではないか」と思われる設計のコードに出会うことが少なからずあります。現在では改良されましたが（Javaプログラミング能力認定試験の問題がかなり改善されていました - 達人プログラマーを目指して）、以前のJavaプログラム認定試験の問題は、そうした不適切な設計がされている典型的な例となっていたのですが、実際、SI業界ではあのような品質のコードのシステムが今でも現役で多数稼動しているというだけでなく、現在でも新たに生み出されているというのは残念ながら紛れもない事実のようなのです。 確かに新人研修で「哺乳類を継承して犬クラスと
普通の業務系PGには意外と知られていないJavaとJavaScriptの相違点10選 - 達人プログラマーを目指して
以前はJava EEの普通のWebアプリケーションで、JavaScriptはあくまでも利便性のために補助的に使うものという認識がありましたが、さすがに最近では普通の業務系のSI案件でもテーブル表示や入力補助などで高度なAjaxライブラリーの使用が当たり前のように求められるようになりつつあります。サーバーサイドのJavaScript技術といったものもありますが、そういった新しい技術を使わないまでも、ごく普通にある程度大きなJavaScriptの作成が必要になってきているということです。 もちろん、JavaとJavaScriptはその名前にかかわらず、本来全く別の言語です。しかし、意図的に似た構文でロジックが書ける*1ため、兄弟の言語として認識している人も意外に多いのではないかと思います。しかし、使用できるライブラリーに違いがあるという点が一見してわかる最も大きな違いですが、基本的な言語の文法
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
