こんなエントリを書いて早4ヶ月。 なんでアジャイルに取り組みたいか - kaji_3's blog BtoBで対価を頂いてアジャイル開発として遂行した案件が先日終わったのでKPT形式でふりかえります。 前提 期間一ヶ月半 Scrumを参考にしてプロジェクト運用 イベント用WEBアプリケーション 案件の内容をぼかして書いているので、一部整合性の合わない記述があるかも知れませんがご了承ください。 Keep 高い顧客満足度 プロダクトオーナーから「自分たちの意志が反映できた物を作ることができた」とコメントを頂きました。フィードバックから実際のものができるまでのスプリントという考えについても好評でした。顧客の社風として良い物を最後まで模索するという考えがあるとのことで、仕様凍結後の変化は、仕様変更として好まれないウォーターフォールには不満があったとのことでした。 育つシステム 当初想定されていたシ

なんかFizzBuzzが書けないPGがどーとか定期的に話題になってるけど、私に言わせれば説明の仕方が悪い。 こうすれば誰でも書ける。 これだから最近の若いもんは……。 GoogleDocsのスプレッドシート、方眼紙作るのに向いてませんね……。

ソフトウェア開発プロジェクトをとりまく６つの誤解〜プログラミングを経験しないとわからないこと こちらの記事が、ただのエンジニア側のあるあるネタで終わってしまうのは本意ではないので、この記事で少し補足しようと思います。 まず結論から。ソフトウェア開発の関係者がプログラミング経験がないからといって、無駄な作業や無茶な計画が立てられるのは双方にとって不幸なので、プログラミング経験のある本当のプロならば、その特性について、きちんと説明をして、そもそもから理解をしてもらい、お互いにとってハッピーなソフトウェア開発をしましょう。ということです。 ソフトウェア開発の世界において、関係者のソフトウェアの特性に対する理解が足りなかったり、間違った認識があったりすることで、そのプロジェクトの誰もが不幸になったり、無駄なことをしてしまったり、ということが起きているように感じています。 その例えば、を書いたのが、

続きを書きました　→　伝えなければ伝わらないという当たり前の話 ソフトウェア開発に関する相談を受ける中で、どうもソフトウェアというものの特性について誤解をされているな、という思いを持つことがあります。 そうした場合、聞いてみるとプログラミングの経験が無かったり、殆どプログラミングには携わったことがないという方が多いです。 ソフトウェアを開発しようとするならば、ソフトウェアという特性をよく知った上で、プロジェクトは運営した方が良いし、うまくいくはずです。そしてソフトウェアならではの特徴を知るのに、プログラミングの経験はとても重要です。 この記事では、プログラミング経験の無い方が陥ってしまいがちな、ソフトウェア開発にまつわる誤解について考えてみました。 Harry Potter is Ready for Divination / weekbeforenext 誤解：既にあるソフトウェアを流用し

先月で転職してから1年がたった。 振り返りの意味を込めて、職場を変えて1年間で実感したこと書く。 僕は元COBOLer（もっと正確に言うとNATURALという言語で開発をしていた）から特定の業者さんが使用するWebサービスをASP提供する会社に移った。 COBOLerがWebサービスに移ったらという苦労話も需要が多いかもしれないけど、具体的にどのような技術や知識を必要としたか、というのは書かない。 強いて言えば、JavaでもPHPでもRailsでもGrailsでもよいから、Linux上でWebアプリを1つでも完成させた経験があると良いのじゃないかと思う。 というか、そういう経験がなかったので、死にかけた。僕は。 ともあれ、おかげさまで、今の職場は楽しいし、やり甲斐のある仕事を楽しんでいる。 ◯業務知識重要 転職して一番苦労し、今も悩ましいのは自分の業務知識のなさだ。 業務知識を持たずに仕事

あまり技術力もない、口も下手で、日々のシステム開発を大きな不具合がないように先回りをしながら大きな苦難の無いように仕事をしているプログラマーよりのエンジニアによる感想です。 何回か転職をしてきて、エンジニアの採用面接は非常に不思議だと思うようになってきました。 その思いを完成させてくれたのはJunichiItoさんによる このたびソニックガーデンの7人目のメンバーになりました でした。 自分が不思議と思ったことを5つほど挙げたいと思います。 システム開発の判らない人が評価をするのですか？ 最初に不思議に思ったのは面接を人事の方がすることが多いことでした。 システム開発をしたことがない、することのない人が面接官をして、 エンジニアが自分がどれだけ優れているのかを面接でお話をする。 エンジニア同士ですら、昨今の技術は多岐にわたっており、自分の専門としていない分野に関しては評価ができないような状

今やほぼ週1の更新さえもおっくうになりつつあるのが危険だと思いつつ。 書くネタはたまに思いつくけれど文章に起こすとなるとそれなりに時間かかるのでなかなか…。 最近は色んなことをインプットする時間がなかなか取れずに、ちょっと焦ったりしている。いちおう技術者の端くれとして生きているので、新しいネタなどは仕入れていかないと、どんどんついていけなくなるのでそういう時間を作りたいとは思っているものの、その気がある時は時間がない、時間がある時は気が乗らないという感じで日々過ぎているのがマズイなあと。 特に仕事面だと、毎日長時間会社に拘束されるような仕事の仕方は良くない。火消しだのデスマだのに突っ込まれたり遭遇したりすることが多いけど、そればかりやってると本当に自分の生活って何よ、って気になってくる。 30代になると今までの経験とかノウハウを切り売りして、インプットを怠ってもある程度までは仕事は回してい

777ブログウェイ「つくるための三種の神器」というテーマで、 本日はカヤック京都支社の技術部アルバイトで働いている高江洲（たかえす）がご紹介します。 エンジニアとして働く上で、大切だなぁと思う以下３つのことについて自分が利用している(利用し始めた、今後も継続したい)ことを３つ取り上げてみたいと思います。 1. 情報収集 2. タスク管理 3. テスト駆動開発 １．情報収集 情報収集手段といえば、はてブの人気エントリーやヤフーのトップニュース、RSSリーダーなど様々な手段がありますが、最近はもっぱらGunosy（グノシー）を使っています。 TwitterやFaceBookでログインすると、興味のある分野についてのおすすめ記事のまとめを1日1回メールで受け取る事ができます。大手のニュースサイトから個人のブログまでの幅広く、僕は朝の通勤中にひと通り目を通す感じで使っています。 使い始めて2ヶ月く

やる気が出ないとき、「いまの自分はOK」から始めよう：心の健康を保つために（9）（1/2 ページ） 「やる気が出ない」の原因は 相談を受ける中で、最近多いなと感じるのは、「やる気が出ない」という内容です。具体的には、「朝、仕事のことを考えると気持ちがなえてしまい、起き上がれない」「営業でお客さんを回らなければならないのに、体が重く感じてついつい休憩してしまう」などです。 「そんなのみんなあるでしょ？」という声が聞こえてきそうですね。確かに、毎日「さあ、やるぞ！」と思える人はそれほど多くないでしょう。「しょうがない、まあやるか……」と重たい腰を上げることもあると思います。 しかし、前述のような気が重い状態が何日も続き、「なんとかしなくては……」と思っているのに動けないともなると、大きな問題です。気持ちが追いつめられ、焦りばかりが募り、できない自分を責め、毎日が苦痛になってしまいます。 今回は

最近とにかく、移動が多いので、その中でちょいちょい考えたことをまとめておきます。まずは仕様の理解の仕方とか、業務例外とか、押さえておきましょうという視点から。別にこれが正解で必須というわけではないので、あくまで個人の経験をまとめただけです。 モデリングとか、なんというかそういう高尚な話ではなくて、実際に仕様をまとめるときに、現実的に落ちる穴を、経験的に書きます。大抵のプロジェクトでは、仕様が固まらずに、または手戻りが発生して酷くコストが膨らむということがやはり多いわけで。理屈はともかく自分の経験的な対策案です。 （なんというか、開発方法論や手法・ドキュメントのまとめ方は、なんとかBOKから始まって、アジャイルや押しくらまんじゅうやらでいくらでもであるのですが、その一方で丁寧な要求定義や設計それ自体ができる人材は、むしろ急激に減っているような印象すら受けます。海外からの翻訳や輸入はやたらと多

まず超個人的な見解です。あとWeb系の人は関係ないので、そういう人は読んでも無駄です。ここでいう業務系エンジニアというのは、主にSI屋で特定企業向けのシステムを構築しているエンジニアの人たちをさします。 まず、非常に難しい時代になったと思います。 端的に、ちゃんとしたSIをやることが難しくなりました。まず、技術的には面倒なことが増えた、というかできるオプションが制御できないくらいに増えているので、うまく制限をしないとコードや仕組みが劣化する一方になりました。エンジニアリングに自由を！というのは聞こえはいいのですが、チームプレーをするのに、いちいち約束事決めないと回らないようになっているような気がします。それも毎回。始めるたびに。 別段、いきなりチームメンバーの能力があがったり、さがったりするわけではないのですが、なぜか外すと酷いことになる振れ幅が増大したような気がします。ルール決めをいちい

いままで勉強会に顔を出し、すばらしいエンジニアと数多く会うことができた。そして、スーパーエンジニアと共に仕事をすることもできたし、できている。そんなスーパーエンジニア達が持っていた習慣を僕の経験と視点からまとめてみる。 自分が使う道具を厳選して選んで手入れをしているエンジニアでいえばエディタやツールなど。皆が使っているIDEやエディタを何も考えずに使い始めたりしない。 厳選したエディタやツールを使って、手になじませるのである。手になじませるというのは、2つの意味がある。 1つは操作性に慣れること。呼吸をするように自然に、キーボードの上を駆け回る心地よいリズムを奏でるエディタを選ぶ。 2つめは、自分に合わせて拡張しているということ。プラグインのON/OFFだけではなく、オリジナルのショートカットを設定し、適切なハイライト、シンタックスのチェック、コーディングルールのチェック、様々な言語への対

プロジェクト管理は決して精密な科学ではないが、これにソフトウェア開発が持つ予測が難しいという性質と組み合わせられると、大きな悲劇のレシピが生まれる。わたしは、ソフトウェア開発プロジェクトに取り組んでいるプロジェクトマネージャーがよく犯す過ちを数多く見てきた。それらの過ちの一部はソフトウェア開発に限ったことではないが、この文脈では特に頻繁に起こり、ダメージも大きい。 1．「人数を増やせばよい」という誤解 Fred Brooks氏は同氏の有名な言葉の中で、よくあるプロジェクト管理の間違いについて「ある女性が9カ月に1人子どもを産めるからといって、9人の女性がいれば1カ月に1人の子どもを産めるわけではない」と表現している。そして、この間違いは今でも頻繁に見られる。ある問題に多くの人間を割り当てれば、その問題は早く解決するという考え方だ。残念ながら、これは正しくない。 プロジェクトに人を1人投入す

本連載は、さまざまなキャリア理論を紹介する。何のため？ もちろんあなたのエンジニア人生を豊かにするために。キャリア理論には、現在のところすべての理論を統一するような大統一理論は存在しない。あなたに適した、納得できる理論を適用して、人生を設計してみようではないか。 今回は、日本のキャリア研究の第一人者として最も著名な、金井壽宏氏（神戸大学大学院経営学研究科教授）のキャリア論を紹介しましょう。金井先生は、MIT（マサチューセッツ工科大学）留学時代、第5回「シャイン博士と8つの職業人タイプ」ご紹介した、エドガー・Ｈ．シャイン博士に直接師事され、近年発刊されたシャイン氏の著作『キャリア・アンカー』の翻訳もされています。 金井先生の研究は、キャリア論だけでなく、経営・リーダーシップから、組織行動論、モチベーションまで広範囲に及び、それらの研究内容も年々深みを増しているのですが、本稿ではキャリアデザイ

雑文を書く。 ぼくはどちらかとプライドが高いほうで、単なる趣味であるところの音楽でも「下手なところは見せられない」とか、「アレを聴いてないことが恥ずかしい」みたいな気持ちを強く持ってる。なんというか、「下手なところを見せたら舐められるんじゃないか」とか「アレを聴いてないとバカにされるんじゃないか」みたいなふうに感じてしまう。 で、こういう話をしてるとよく、「プライドを捨てよ、そして楽になるがよい」みたいなことを言う人間がどこからともなく現れてOSEKKYOを始めたりするのだけれど、そういうのに対しても結構大きな違和感を持っている。こういう「舐められたくない」みたいな気持ちがないと、クオリティの低いものばかり作り出す邪悪な人間になってしまうし、プライドがあるからスキル上がって行くみたいなところはあると思う。 一方で、こういうプライドがじゃまになることもたしかにあって、馬鹿にされるのが嫌だから

先月から出稼ぎで東京に来てます。毎年、プロジェクトの特性上、３〜４月に空きが出てしまうので、仕方のないことなんですが。 で、最近ネットワーク図を書く仕事をしているのですが、ちゃんとしたネットワーク図を仕事で書くのは初めてのことでしたので、「コツ」をつかむまでだいぶ時間がかかってしまいました。 その過程で、いろいろと参考にしたサイトをまとめてみます。 書籍 ネットワーク現場の教科書　改訂版 （マイコミムック） (MYCOMムック) 作者: IDG出版社/メーカー: 毎日コミュニケーションズ発売日: 2011/03/31メディア: ムック購入: 1人 クリック: 9回この商品を含むブログ (2件) を見るこれはネットワークの教科書　改訂版 （マイコミムック） (MYCOMムック)の実践編的な内容ですが、本当に役に立ちました。ネットワーク図を書く際には、物理構成図と論理構成図をきちんと分けて書か

ご挨拶 今月の第二日曜日は3月11日でした。言わずと知れた、あの「3.11 東日本大震災」から丸一年が経過した日です。改めまして、当時亡くなられた方々のご冥福をお祈り申し上げます。また、被災され現在も不便な暮らしを強いられている大勢の方々にお見舞い申し上げます。一日も早く元通りの日常が送れるようになることを願って止みません。 3.11の14:46、オレは代休で自宅にいるところにあの大地震がやってきました。自身が立つこともままならないような衝撃の中、不安定なテレビ台とPC棚をなんとか抑えて揺れが収まるのを必死で耐えたのは、今でも鮮明に思い出すことができます。それもあって我が家の被害は全くなく、妹も職場の方の好意で車で送って貰え、日付が変わった頃に無事帰宅できました。都内では翌日昼を過ぎても帰宅できなかった人が多かった中、我々は非常に運が良かったと思います。 はじめに さて、オレにとって、この