サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
衆院選
keisyuogasawara.wordpress.com
先日、 QAをやっている方でJunitテストを書きながらレガシーコードを改善しつつ品質を高めたい方などいらっしゃいませんかー? 現状、Javaのコードが読めなくても、書けなくても、Junitを使ったことがなくても、やってみたいという方はいらっしゃいませんかー?— おっぴー || ぴーおつ (@_oppy) November 15, 2012 というつぶやきをしたら多数のひとにリツイートしてもらったので、なぜ、あんなつぶやきをしたのかもう少し書いてみたい。 なぜ、あんなつぶやきをしたのか、それは僕達のチームが技術的負債という痛みを抱えているからだ。 そして、技術的負債を解消しつづけるために、ともに開発現場にいてくれるエンジニアをチームが求めているからだ。 技術的な負債が生み出される原因は、エンジニアの技術もさることながら、負債を抱えたプロダクトを産み出すことを許す開発プロセスがあり、さらに
先月で転職してから1年がたった。 振り返りの意味を込めて、職場を変えて1年間で実感したこと書く。 僕は元COBOLer(もっと正確に言うとNATURALという言語で開発をしていた)から特定の業者さんが使用するWebサービスをASP提供する会社に移った。 COBOLerがWebサービスに移ったらという苦労話も需要が多いかもしれないけど、具体的にどのような技術や知識を必要としたか、というのは書かない。 強いて言えば、JavaでもPHPでもRailsでもGrailsでもよいから、Linux上でWebアプリを1つでも完成させた経験があると良いのじゃないかと思う。 というか、そういう経験がなかったので、死にかけた。僕は。 ともあれ、おかげさまで、今の職場は楽しいし、やり甲斐のある仕事を楽しんでいる。 ◯業務知識重要 転職して一番苦労し、今も悩ましいのは自分の業務知識のなさだ。 業務知識を持たずに仕事
2012/07/29に行われたJenkinsユーザーカンファレンスに参加してきた。 1000人以上の参加登録が行われ、国内で行われるIT系のカンファレンスとしては有数な大きな規模で盛り上がったようだ。 大きなカンファレンスが有志で行われることは、Jenkinsが多くのエンジニアにとって有用なツールであり、また、多くのエンジニアに愛されていることの証拠だろう。 ◯優れたツールをつくるコミュニティには貢献の意識が中心にある 川口さんの基調講演ではJenkinsの現状やこれからの取り組みについて聴いた。 話を聞いて考えたのは、 なぜJenkinsが多くのエンジニアに愛されているか なぜJenkisnのコミュニティは活性化しているのか ということだ。 この答えは非常に単純で、 エンジニアたちへの貢献を一番に考えた取り組みがなされているから だろう。 Jenkinsの取り組みとして – よくある作業
1ヶ月に聞いたjonathan rasmussonの話で印象に残ったことを書いておこうと思う。 僕が彼からうけた教えは非常にシンプルで、 ルール1: 価値のあるフィーチャーを確実にリリースして信頼を築け ルール2: その信頼を決して裏切るな という2つのルールだけだ。 アジャイルにやる目的というのは究極、価値のあるフィーチャの定期的なリリースだ。 もちろん、アジャイル開発を発祥とするプラクティスを上手く取り入れることは、開発現場が楽しくなったり、良い開発者を育てることができるようになったり、という効果もあるかもしれない。 とはいえ、それらは手段であって目的ではない。 楽しい開発現場は開発に携わる人の士気をあげる。 人が育てられる開発現場はチームのハネムーンナンバーを増やせるし、チームの能力を高められる。 だが、それは価値のあるフィーチャを継続的に生み出し続け、ビジネスとして成功する、という
先日12日(土)にDevLOVE&yass合同勉強会「自力で海図を描きだせ!!」に参加した。 http://togetter.com/li/214190 http://kokucheese.com/event/index/19568/ 講師の倉貫さん、梅野さんにお話を頂いたあと、「自分たちの10年後の明るい未来」というテーマでディスカッションを行った。 その際にエンジニアと経営者との視点や行動の違いが印象に残ったので、下記にまとめる。 ディスカッションで印象に残った指摘として、「エンジニアは自分を中心に将来を考え、経営者は外側にどのように影響を及ぼすかで将来を考える」というものがあった。 10年後の未来を考えるときエンジニアは「自分はアーキテクトになって」とか「プログラマとして現役でいたい」などのように、「自分がどうなっているか」を中心に未来を考えている。 一方で、経営者は「社会をこのよう
最近、Lightning Talks(以下、LTと書く)という催しで話す機会があった。 きっかけは、僕が裏方を務めた勉強会でLTのトーカーを募集したところ、トーカーが集まらなかったことだ。 自分が言いだしっぺの企画の勉強会のコンテンツが成り立たないのは困る。 なにより「人に話してくれ」と図々しくもお願いしているのだから、自分もその輪に加わらないのは無責任すぎる、と考えてやることにした。 それまでは、普段からLTの誘いを受けても「人前で話すのは苦手なので」と断っていたので、僕は多くの人前ではじめてLTをやることになった。 その準備は結構、大変なものだった。 エンジニアという職種でなくても、見栄えの良いスライドを作り、中身のある話を、多くの人の前で、聞き取りやすい言葉と声で話す、という経験は稀有だ。 僕の作ったスライドはすべてが文字の簡単なものだったけど、内容を考えることをふくめてスライド作り
ふと思い立ったので、今まで読んできた本で印象に残っているものをまとめてみた。 別に体系だてておもいだしたわけでもなく、まとめたわけでもないので、「なんであの本がないのか?」みたいな意見があるかもしれない。 そんな時はコメントをしてもらえるとうれしい。 すでに読んだ本でも、新たな本でも、手によって読む機会になるので。 ちなみにシステム関連の本が多いのは読んでいる比率の問題であって、システム関連の良書を紹介しようという主旨ではない。 ◯UMLモデリングレッスン UML記法によるデータモデリング学ぶのに最適な1冊。 これ以前に、『UMLモデリング入門』(以下、『入門』と略す)などで、UMLおよびデータモデリングの考え方に親しんでおく必要があるかもしれない。 とはいえ、UMLをつかいながら業務分析をしたり、システムについてコミュニケーションをとったりするための基礎を身につけるのに最適な1冊。 『入
6月30日(木)をもって現在の会社を去ることにした。 新卒で入社して5年間、大変のお世話になった会社で、ビジネスパーソンやエンジニアとしての良識と習慣を身につけることができた。 会社で学んだことは、別の機会に書くとして、今回は転職活動そのものについてメモがてら書いてみたい。 自分のためのものなので、だらだらと書く。 きっかけ もともと転職願望があった、というか、今の会社で働き続けるということに現実味がなかった。 もちろん、5年で辞めること言うこと考えていたわけではなかったが、定年まで1つの会社で働き続けられるとは思っていなかった。 また、入社時にも、「いつでも、どこへでも行けるように、自分を鍛えておきなさい」と言われていたため、「いつかは別の会社に行くかもな」という漠然とした意識を持っていた。 本当に転職活動に携わり始めたのは、今年の1月にはいってからだ。 僕自身は、今の会社の仕事を楽しん
先々週のことになるだろうか、アジャイルチームビルディングというイベントに参加してきた。 無料で行われたイベントとしては大変、豪華で、ジョハンナ・ロスマンやエスター・ダービー、角征典さん、平鍋健児さんと日本のアジャイル界隈の人間なら知らぬ人はいない人たちが参加したイベントだった。 そもそも、良い仕事は優秀なチームによって行われる、というのは、開発手法はもとより業界の別を問わない考え方だ。 むしろ共通的な思想と言っていい。 そして、「どうやって優秀で素晴らしいチームを作るか」というのもまた、業界の別を問わない永遠に取り組むべき問題の1つだ。 今回のイベントの名前はアジャイルチームビルディングとなっているが、 講演者の話は、良い仕事をするために、「どのようにしたら良いチームが作れるか?」という疑問に答えようとするものだったと思う。 ジョハンナ・ロスマンは、個人の能力をどのように評価するか、すなわ
2011/01/13(木)にイノベーション・スプリントというイベントに参加した。 このイベントはAgile、とりわけScrumに取り組もうとしている人間にとっては意義深いイベントだった。 Scrumというソフトウェア開発手法の開祖の1人であるジェフ・サザーランド。 そして、そのScrumの考えの源となった『NewNewProductDevelopmentGame』という論文を発表した1人、野中郁次郎。 その両者が同じ場で話をする、というものだったからだ。 野中郁次郎は、当時、優れた製品を生み出す企業を研究し、知と思想を体系化した。 そして、ジェフ・サザーランドは野中郁次郎の知と思想を実践し、その経験を通じてScrumという知と思想を生み出した。 優れた企業のなかに暗黙化されていた知を野中郁次郎が形式知化し、野中郁次郎によって形式知化されて知を用いたジェフ・サザーランドは行動という暗黙知を経
今年の最後のエントリだけれども、「です・ます」調をやめてエントリを書きたい。 結構、長い間ブログを書いてきたけれど、やはり違和感があるからだ。 普段の話し言葉が「です・ます」調なら良いのだけれど、そんな丁寧な話し方はしない。 そのため、「です・ます」調の文章を書いていると素直に思ったことは書けないと感じている。 今回は、特に自分の思ったことを素直に書きたいと思ったので、タイミングとしては中途半端だけれども、「です・ます」調をやめてエントリを書こうと思う。 最近、優れたプログラマになるにはどうしたら良いか、ということを考えるようになった。 きっかけは単純で、仕事でスキルチェンジを迫られたことだ。 僕は、つい半年ぐらい前まで、仕事では汎用機でCOBOLを書いていた。 それが、今年の7月からJavaやらCentOSやらEclipseやら、俗にオープン系という技術を仕事で触るようになってきた。 現
最近、slim3というGoogleAppEngine/Java上で使用できるフレームワークを触り始めました。 http://sites.google.com/site/slim3documentja/ 一言で言ってこれはすごい。 Eclipseと連動させたら、苦もなくテストライクな環境で開発ができるようになります。 チュートリアルも丁寧に作られています。 MVCモデル、TDDの要素をしっかりと盛り込んで、フレームワークの使用方法が説明されます。 ちょっと開発に携わったことのある人であれば、 “Creating a Slim3 application is easy, and only takes a few minutes” (Slim3のアプリケーションを作るのは簡単、数分しかかかりません。) という言葉に偽りなし、と実感できるでしょう。 webサービスで儲けようと思ったら、早
私の周辺では、勉強会が盛んに行われています。 私も参加しますし、一部ではスタッフとして活動してもいます。 しかし、最近は仕事の場が変わった都合もあるのですが、参加の頻度は少なくなっています。 おそらく、勉強会に参加することだけに、それほどの価値を感じることがなくなったからだと思います。 勉強会自体は価値のあるものですし、楽しいものです。 日々の問題意識や悩みが相談でき、問題が解決できたり、悩みが解消できたりします。 会社や業種の枠を超えて、問題意識や興味に共通点がある人々が集まれる場は素晴らしいものです。 しかし、単に勉強会に参加すること、情報をインプットすることには意味がほとんどありません。 情報をインプットすることの価値は、良質なアウトプットにより支えられているからです。 極論をいってしまえば、良質なアウトプットが可能であればインプットする必要がないのです。 良質なアウトプットがないの
どうも。 1年ぶりのブログ更新。 それもこれも、すべてはDevLOVE Advent Calenderのため。 本エントリーは、DevloveAdventCalender7日目のエントリーでございます。 昨日のぽざうねさん、 5年前からすこしずつ成長された結果が大きなdiffとして現在、実っておられるようです。 そういえば私事だけど、ちょうど1年前ぐらいに転職をした。 前職ではWeb広告系のシステムのおもに保守と開発、運用をしていた。 再度、「人の役に立つ」という視点でしっかりとしたシステムを作りたい、と思い、ふたたびSI業界に出戻った。 いわゆるWebのベンチャー企業とは180度異なる環境に再度身を起き始めたので、やはり苦戦する部分があった。 そんなときに、自分を奮い立たせるためにできること、それが、過去の自分とのdiffを取ることだ。 具体的には、毎週KPTやYWTをおこなって、過去の
メディアマーカー用に文章を書いていたのですが、悪い癖で長い文章になってしまいました。 ということで、その文章をブログにしようと思います。 取り上げたい本は、ジェラルド・M・ワインバーグ氏の『パーフェクトソフトウェア』です。 私は、とくに以下の文章には感銘をうけました。 良いテストにするためには、リスクを軽減したいという要求と、過剰に情報を集めようとするリスクのバランスをとることだ。(p.6) 一般的にテストと呼ばれるものは、「品質を作り込む」ものではなく「品質を確認する」ものなのです。 テストをするだけでは、ソフトウェアの品質は上がらりません。 当間ですが、テストの結果を受け、ソフトウェアを修正しなければならないのです。 テストは、どこを修正すべきか、どのように修正すべきか、そして、その製品は出荷されるべきか、という判断のための情報を収集するための活動なのです。 ビジネスアプリケーションを
先日、2010/06/08(火)にAgileJapan2010基調講演の再演イベントに参加してきました。 AgileJapanで基調講演を行ったのは、野中郁次郎さんという方で、ScrumというAgile開発の手法には浅からぬ縁のある方です。 というのは、Scrumという開発手法の名前こそが、野中さんの論文の一文からとられているからです。 再演イベントは、その野中さんのお話を、チェンジビジョンの平鍋さんが記憶の限りお話してくれる、という聞き逃した身としてはとてもありがたい、イベントでありました。 以下にその感想をまとめたいと思います。 ちなみに、野中さんが発表に使用されたスライドは、以下で見られます。 http://www.slideshare.net/hiranabe/agilejapan2010-keynote-by-ikujiro-nonaka-phronetic-leadership
2010/1/14(木)に、「Agile2.0 ~ アジャイルなチームで何を提供する?」という勉強会に参加してきました。 実はこの日は、純粋な飲み会としての新年会を開催予定でした。 が、その会をほぼ無理やり「勉強会に参加する新年会」と内容を変更して、参加してしまいました。 参加予定だった方には、少々、申し訳ないことしてしまったと思います。 しかし、この会に参加して、わたしが、なぜスクラムマスターになりたい、と考えていたのかがはっきりしました。 それは、スクラムなどアジャイルという開発手法が、 開発者と顧客をつなげることで楽しく良いシステムがつくれる と感じたからだったのです。 <顧客不在の開発現場> 私の周囲には、コーディングが好きな方とても多いです。 それは老いも若きも関係ありません。 なかには、60代になってもコーディングが好きで、現役でコードを書く方々がいます。 そうしたコードを書く
このページを最初にブックマークしてみませんか?
『エンピツとキーボード | アートと書評、ときどきシステム. 最近は、システムの話に...』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く