ソフトウェア開発の現場にいるベテランには、他の人の手本となるような達人もいるけれど、その一方で見習ってはいけない悪い見本の人も少なからずいる。その一例。 開発資料を作らない「ソースコードを読めば分かる」「資料を書くのは労力の無駄」と豪語して…

ソフトウェア開発の実体はなかなか見えにくい。部外者からの「あいつら何をやっているのか？」という冷たい視線を感じることもあるし、隣の開発者の作業内容すら理解していないことも多い。仕様書の山やソースコードのリポジトリを参照すればそれなりに成果…

新人君が配属されたので、ソフトウェア開発現場でどのような形で作業を行っているのか説明するために、昨年の開発プロジェクトで実際に使用したTracを使ってみた。普通はプロジェクト完了報告書などの資料を参照するのかも知れないけれど、これはあくまでも…

ゲーム開発について書かれているけれど、ソフトウェア開発全般に有益な本として「ゲームコーディング・コンプリート」を紹介したい。著者はウルティマシリーズのプログラマであるマイク・マクシャフリー氏。ゲーム作成に直結するノウハウはもちろんのこと、…

ソフトウェア開発の現場では、不思議なことに互いに助け合わないことが多い。例えば、隣の作業が遅延しているならヘルプに回る、必要な知識が不足しているのなら勉強会を開く、自分のノウハウを出してグループ内で情報共有を図る、なんて言う前向きな姿勢が…

一昨日(6/18)は「派生開発カンファレンス2010」へ参加してきた。個々の講演内容は参加者のみに開示されているので、勝手に公開するのはダメというお達しが出ていたので、差し障りのない範囲で感想を中心に書き連ねてみる。 「派生開発カンファレンス2010」開…

ソフトウェア開発の現場では、仕様書、報告書、企画書、提案書、障害レポートなど実務的な文章を書く機会が多い。実用一点張りの文章でも良いから、読み手にとって分かりやすく、誤解を生じさせることなく、必要最低限の書き方で意図が確実に伝わって欲しい…

社外の勉強会やイベントに参加することがある。そんなところに来る人は、会社の命令で来ている一部を除き、たぶん自発的に何かを求めて来ているはずだし、自分のプライベートな時間を割いて来るくらいだからモチベーションが高くやる気もあるはずだ。そんな…

ソフトウェアの問題点を調査していたら、一つの関数で1000行を超えるものに出くわしたことがある。そんな長い関数を作るからバグが生まれるのだよと思いつつ処理内容をチェックしてみるが、24インチのモニタに表示させても全体像がサッパリ分からない。仕方…

ソフトウェア開発の現場で良く耳にする言葉の一つに「汎用性」なるものがある。例えば、下記のような文句を聞いたことは一度や二度では無いはずだ。 このソフトは他でも使えるように汎用性を持って欲しい。 このモジュールは次の案件でも流用出来るように汎…

テスト駆動開発やJUnitを使い始めた頃に読んだ本。手元の本は2004年5月発行の初版なので、もう6年（！）も前の本になる。JUnit自体は（やや乱暴な言い方かも知れないけど）Assertによる検証をシステマティックに行うものであり、特に難しいものではない。例…

失敗知識データベースというサイトがある。モノ作りで発生した事故や問題の事例を集め、その分析を行い教訓として生かしましょうというのが主旨だ。例えば、2002年に起きた「みずほフィナンシャルグループ大規模システム障害」といった事例も載っており、問…

昨日は、SEA関西プロセス分科会「40回超」記念セミナーに参加してきた。本当は40回記念のはずだったけれど、大人の事情により40回を超えての記念イベントになったとのこと。30人足らずのこぢんまりとしたセミナーだったけれど、中身は濃くて充実度は高かった…

Googleの検索は便利だ。他に誰か知っているとは思えないようなマイナーな用語でもまず間違いなくヒットするし、しかもその情報は全世界から集めてきてくれる。こんな情報探索ツールの存在が有ったからこそインターネットは発展してきたのだろうと思う。もは…

書店に行くと様々な英会話の書籍が並んでいる。本を読むだけで語学を習得できるのなら、誰でもペラペラに英語を話せてしまうはずだが、もちろんそんなことは不可能だ。本を読んでもなかなか習得出来ないのが当たり前だし、自分で思い通りに使えるようになる…

一つの思考実験として考えてみる。完了した開発プロジェクトのアウトプットを消去して、同じプロジェクトに同じ開発者が再度取り組んでみるとする。開発者の頭の中に様々な情報（記憶）は有るので、開発プロセスへのフィードバック結果やエンジニアリングの…

セミナーや人の話を聞いて新しい知識を学んだ時には、その感想とかコメントを簡単にまとめて記録に残すようにしている（ブログに載せている情報もその一例だ）。また、会議や講演のように後から情報を読み直せないものは、話の内容を延々とメモした上で、そ…

クローズできないチケットの続き。チケットをクローズ出来ないとマイルストーンもクローズ出来ないので、この状態が続く限りソフトウェアのリリースが不可能になってしまう。「事情があって未解決のチケットは残るけど、開発作業は全て終了しました」と言う…

ソフトウェア開発者の仕事は、もちろん納期通りに要求されたソフトウェアを開発することだけど、それだけではない。成果物に対する説明責任も伴うはずだ。 どのようなアーキテクチャ、デザインパターンを採用しているのか？ モジュール構成、クラス構成はど…

3月末が期限だったtracのマイルストーンをクローズする。「チケットキーパーという存在」として、未解決のチケットについてはマイルストーンの変更（要するに先送りだ）や、担当者にチケット更新の催促を行う。幾つかのチケットはクローズ出来たものの、中に…

モデル駆動開発(MDD)について知人と話をしていて議論が微妙に噛み合わなかったので、よくよく話を聞いてみたら、ソースコードの自動生成など高機能なツールの存在を知らなかったのが原因だった。確かに、モデル駆動開発と一言で言っても対象が幅広いし、それ…

ソフトウェア開発に関連して、気になるイベントがいろいろ有るのでチェックする。 日経コンピュータセミナー「東京証券取引所に学ぶ、発注力強化の勘所」 「トレーサビリティを追求した開発」の詳細が聞けるかも知れない。優れた方法なら是非とも取り入れた…

ソフトウェア開発の現場で良く聞く発言。 「仕様書をキッチリ書こう」 「きちんとした仕様書を書ける人が欲しい」 「仕様書に記載漏れが無いようにしてくれ」 仕様書とは、完成した文書が一つ有れば全てが片付くような性質のものではなく、何をどう作るかと…

日経コンピュータの記事に、東証の新しい売買システム「arrowhead」の解説が載っていた。金融システムなんて門外漢なので評価できる立場には無いけれど、東証のシステムと言えば以前に受験した技術士試験第二次試験にも出てきた話題*1なので、一体どんなシス…

ヒマだったので情報収集を兼ねてネットサーフィン（死語）で時間を潰す。以前のソフトウェア開発で障害対応に困りやっつけ仕事で対応した箇所について、上手いこと対応しているソースコード情報を見つけたので、ブックマークに放り込んでおく。関連するtrac…

tracの障害チケットに目を通していたら、該当する仕様としてこんな記載が載っていた。 ○×仕様書の□ページの上から△行目に記載されている〜について... 大きな偏見だと思うけど、Word等で記載されたダラダラとした文章が並ぶ仕様書を見ると「これは要注意」と…

開発プロジェクトの現場では可能な限り更新情報を集めて、その日のまとめをTracのWikiに載せるようにしている。メールで文章を流しても良いのだけど、プロジェクトへ直接的に関わらない人も「必要なら見ておいて」というスタンスなので、誰でも参照できる社…

フレデリック・ブルックスの名著「人月の神話」を題材に、ソフトウェア特有の規模の問題、あるいはその複雑性が、人間世界と実世界、そしてコンピュータ世界という3つの世界で密接に絡み合っている実情が説明されている。そんな本質的な部分を見せつけられる…

昨日はXP祭り関西2010に参加してきた。たくさんの人が集まっていたので少々驚く。時代の流れはアジャイルなのだろうか？XPやチケット駆動開発の講演より参考になった点を抜粋。 倉貫義人さん Social Change! ソニックガーデン SonicGarden 倉貫義人のブログ …

景気づけなのか、やる気のあるところを見せるつもりなのか、なぜかソフトウェア開発の現場では「ドンドン作ろう」といった類の勇ましい言葉を聞くことが少なくない。 仕様をドンドン決めていきましょう ソフトをドンドン作りましょう テストをドンドン進めま…