３５歳定年説。 - The Dragon Scroll
伝説の「エンジニアの３５歳定年説」について、ついこの前、人材コンサルをやっているエージェントに、彼の意見を聞いてみた。 ちなみに、私は、３５歳で何が終わるのだろうと思っているクチです。 確かに、漫然と、年齢を重ねるだけでは、その頃に、後悔することが 出てくるだろうとは思いますが。 「３５歳定年なんて、無いよ。」 ああ、やはり、そうか。 「延々と、こちょこちょと技術をやっているのであれば、しんどいけどね。」 「J2EEとか、なんとかっていう、業界の技術なんて、凄い狭い世界だけの 話なんですよ。一般人からすれば、そんなもん、どうでもいいんですよ。」 それはそうだ。 「だから、３５歳の人が、『私、凄い技術を持っていて〜』って言ったって、 次はないですけどね。次がある人は、４０でも転職ができる。」 狭い世界で通じる話ができなくなるということなんだろう。 当然、ある年齢に達した時、求められるものが変
私にとって最後のデブサミ。 - The Dragon Scroll
デブサミ2014で「越境する開発」という話をしました。発表時に使用した背景画像はslideshareに置いてあります。こうして読み返すと、デブサミで伝えたかったことは、このスライド自体には無いように感じます。伝えたかったことは、あの日の雅叙園のあの場所に置いてこれたのだと思います。 越境する開発 -Final Bordar- from toshihiro ichitani デブサミ2014のテーマは、「Story」だったので全編自分の物語を話しました。自分自身の話をするのだから、所属ではなく自分の身一つで話そうと思い、今回は「所属無し」で発表者情報を事務局に出していました。ところが、当日の発表5分前、壇上にあがって、気が変わりました。急いで、袖にいた方に伝えました。 「所属は、永和システムマネジメントとしてください。」 この物語は、私が永和システムマネジメントに居たからこそ紡げたものでした
時を超えた共に開発する者への思い。 - The Dragon Scroll
2009年ごろ、所属していた海外沿いのSIerにて、社内の組織を超えた繋がりを作る目的で、社内イベントを開催していた。この開催の後に、自分が残してたエントリを覗いてみて驚いた。 このイベントに込めた思いが、この会社が続く限り、 生きていて欲しいと願う。 これを読むと、すでに自分がこの回で社内イベントの開催を最後にするつもりだったのが伺い知れる。この社内イベントは、100名くらいが参加する、手作りのカンファレンスで、もともとデブサミに触発されて始めたものだ。社内にデブサミのような、自分たちの技術や知識や経験、そして熱さを存分に語る機会を設けようという思いから始めて、この2009年で第3回目を迎えていた。 2008年にはenterprisezineに取り上げてもらった。 身近な仲間と繋がり、刺激を与えあう「社内デブサミ」はいかにして生まれたか 実際のところ、2009年以降社内版デブサミが開かれ
ソフトウェア開発の現場パターン -アジャイル型開発におけるプラクティス活用事例調査- - The Dragon Scroll
Agile2012に行って帰ってきて、結果として3つのことをやろうと思った。最初から考えていたわけではなく、今から考えると、3つあったんだということ。1つは、Agile2012のように活動家たちが集まれる場を作ること。これは、UltimateAgilistTokyoというカタチになった(「日本にも10年かけて育ってきた、"Agile"がある。)。Agile2012で海外のAgileの片鱗を垣間見ることが出来た。次は、日本の現場を訪ねてみたいと思った。日本の現場で育まれているであろう、様々なAgileのカタチを見てみたかった。海外と日本、それぞれから感じるものとその違いを確かめたくなった。これが、もう1つのやりたいことだった(残りのもう1つについてはまたの機会に)。 とてもタイミング良く、IPAで国内のアジャイル開発におけるプラクティス活用事例をまとめたいという事案が上がり、先のような個人的
自分流モデリング探しの旅(2)〜T字形ER データベース設計技法 - The Dragon Scroll
T字形ER データベース設計技法 作者: 佐藤正美出版社/メーカー: ソフトリサーチセンター発売日: 1999/01メディア: 単行本購入: 2人 クリック: 36回この商品を含むブログ (10件) を見るこの書籍は、初版が1998年10月です。実に、8年前のものです。 1998年と言えば、私はまだ大学生でした。 なお、本書の続編が最近発刊されています。 私が、この本とであったのは、新人の頃。 日経ソフトウェアの上流工程を学ぼうという特集で紹介されていたのを 見て、購入しました。 しかし、買ってはみたものの、難しくよく分からない。 随分長い間、放置していたのを覚えています。 T字形ER手法とは何か？ データ設計技法ではなく、ビジネスを解析するための技法であると定義 されています。DOAの思想を根底に持っています。 T字形ER手法を構成するものは次のとおり。 ５つの技法 identifier
学びのプラクティスマップ - The Dragon Scroll
先日、とある集まりで出会った方と 「ダイアログは確かに良いものだけど、なかなか次の行動に繋がらないのでは。」 という話をしたところ、確かにそういう面はあるかもしれないとして、なので、 「体験することで、行動に繋がることもあるかもしれない。」 という言葉を返してもらった。 ああ、なるほど、それは昨今よく開かれている「ブートキャンプ」*1を指すの かもしれないな、と思い、自分たちがどうやって学んでいるのか、 整理したくなった。 幸いにして、コミュニティの運営に長く携わっているので、その切り口だと 考え易い。 結果、こういうイメージになった。 インプットと、アウトプット。机上でやること、実地にやること。 この4つのパラメータの度合いに基づく、4象限で整理してみる。 すると、まず、インプット・アウトプットどちらの面も持ち合わせる ものがあり、これをインアウトとしてプロットした。 図のとおり、「机上
永和システムマネジメントに入社しました。 - The Dragon Scroll
via kakutani 永和システムマネジメントに入社した経緯は140文字では足りないし、それが1200文字になっても 足りなさそうなので、まずは、このあたりでお茶を濁しときます。 大事なことは、私にとってこれから上野で仕事をすることはとてもウキウキで、もう週明けが楽しみ だってことさ。
「なんでみんなブログ書かないんだ。」 - The Dragon Scroll
先日、就職先をきめた大ちゃんと仲間何人かで飲んでいて、彼の 「なんでみんなブログ書かないんだ。」 という一言を受けて、そういえばブログを書く習慣が無くなって、久しいことに 気づいた。ブログを書かない代わりに、twitterやfacebookで何かを書く欲を 消費している。 Google Readerで、ときどき他の方のブログは見ているのだけども、一頃に 比べると未読の数があまりたまらなくなった。 1週間も放置すると、爆発的にたまっていた未読が今は1ヶ月でも読める程度に しかたまらない。 確実に皆、書く量は減っているよね。まーいいじゃない、twitterとかあればさ。 なんて、大ちゃんに言おうとしたら、彼は 「友人知人の近況とか何考えているか知りたいからね。」 だから皆ブログ書こうよ、と言う。 なるほど、確かに、twitterやfacebookでは見逃していることの方が多いからなぁ。 それに
アジャイルプラクティスは2回、奇跡を起こす。 - The Dragon Scroll
東京に出てきて、初めて参加したXP祭り2006。 そもそも、私は、XPというのは、開発者の自己満足だと思っていた。 開発を楽しいものとしたいのは分かる。そうありたいと思う。 しかし、それだけでは何か置き去りにしてはいないかと感じていた。 最初、XP祭り2006は、私のその思いを拭い去るどころか その疑念を助長させた。 流れるような関西弁を操る、fkinoさんの話を聞くまでは。 fkinoさんは、 「開発者が楽しいだけでは、ＸＰごっご」、 そして「顧客重要」と言った。 この日、直接会話することはなかったが、fkinoという名前は 深く脳裏に刻まれることになった。 やがて、私は、XPJUGの門を叩くことになる。 2007年2月15日。 この日が、自分にとっては何の日だったか。 思えば、この日こそが、この日以降の自分の行動の原点となったんだ。 私の大切なデブサミを台無しにしてくれた、セッション、
この業界が変わるわけがないと、言う人はまだいるだろうか。 - The Dragon Scroll
社内で、アジャイルプラクティスの読書会を開いている。 今日は、その第四回。 アジャイルプラクティスをみんなで読んでいて、感じるのは、 現場には現場のプラクティスが既にあるということ。 その知恵を共有することで、新たな気づきを生むことができる。 Aという現場で抱えている問題は、すでにBという現場で解決を している。でも、それをシェアするようなタイミングも場も 無いから、同じような問題をそれぞれが解決している。 もっと、もっと、組織の壁は越えていい。 さて、この視点を広げてみたらどうだろうと思った。 つまり、社内でやっただけでも、我々は、前進することが できた。 では、会社の壁を越えて、そんな場を作り出すことができたら、どうか。 AというSIerとBというSIerは同じ悩みを抱えているかもしれない。 しかし、CというSIerはそれを既に解決しているかもしれない。 会社という壁を乗り越えたとき、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
