進捗会議はなかなか進まない - rabbit2goのブログ
進捗会議と称する打合せに参加すると、その開発チームの状況がよく分かる。「分かる」と言ってもその報告内容ではない。チームの実情をよく示しているのは、むしろ、その打合せの進め方だったりする。 例えば、状況が宜しくなく、課題山積みのチームで良く見かける光景はこんなものだ。 リーダがチーム全体の状況を把握しておらず、打合せの場で初めて状況を理解している。 やたらと会議の時間が長い割に、発言する人は限られている。 当事者間でしか分からない個々の問題に関する議論が延々と続いてしまう。 問題の事後対応の報告ばかりが続き、事前対策等の前向きな話が全く出てこない。 先週の打合せで出たアクションアイテムをフォローしないし、そもそも誰も覚えていない。 今後の工程、予定、展望についてリーダの発言が無く、チームが進む方向性が見えない。 議事録の記載内容がお粗末なので、参加者以外には内容が全く理解出来ない。 会議が終
ボトルネックは開発リーダ - rabbit2goのブログ
チーム内の作業が上手く回っていないという開発の様子を観察すると、なかなか興味深いものがある。 リーダはなぜか常に忙しい 夜遅くまで残って残業するほど忙しいようなのだが、その忙しさの原因を聞いても本人の口からまともな説明は返ってこない。つまり、何が原因で忙しく、今後の見通しはどうなっているのか、本人自身が分かっていないのだ。自分自身の忙しさに酔いしれているリーダは、とにかく忙しいことが嬉しいらしい。 問題の全貌が見えない プロジェクトのヒアリングを進めると、アレも有ってコレも有ってと次々と問題が出てくるものの、その総数が不明で、現在どの段階まで達しているのか不明だ。問題が残っているという点だけは同意だけど、それに勝るとも劣らず解決済みの問題も多数存在するはずであり、その日々の変化を追跡していけば最後の着地点が見えてくるはずだ。それなのに、同じ問題を何度も繰り返し取り上げて堂々巡りの議論を続け
孤独なソフトウェアエンジニアの味方です - rabbit2goのブログ
好きでやっているソフトウェア開発の仕事だけど、周囲を見渡すと実はこんな仕事は好きではないと言い切る人が多くて驚いたことがある。与えられた仕事だけをやっておけば万事OK、チーム全体のレベル向上やプロセス改善、新しい創意工夫なんて自分には関係ないことだし、そもそも仕事に関係しない余計なことに巻き込まないで欲しいと、面と向かって言われたこともある。会社で働く人の目的は実に様々なのだ。 このような開発者が増えてくると、チーム全体としての品質・生産性向上なんて見込めなくなるし、投資対効果を求める会社としては「スキルなんか要らないから人月単価の安い人が欲しい」と外部の会社に求めるようになってくる。一部のやる気とスキルのある人たちが方針と手順を決めて、残りの人はそのルールに従うのみという「ソフトウェア工場」が出来上がるわけだ。 ソフトウェアエンジニアとそれを取り巻く不幸な環境は、長い年月に渡って形成され
無知なリーダーがもたらす災厄 - rabbit2goのブログ
隣のチームの仕事ぶりを知ると、自チームで当たり前に出来ていることが全然出来ていなかったり、或いはその逆のケースも有ったりして興味深い。ペアプログラミングなんて言う言葉があるけれど、チームリーダは隣のリーダと一緒に働いて互いの働き方から学ぶべきではないかと思ったりする。リーダーがペアでマネジメントを行えば、もう少しマトモになるチームも多いのではないだろうか。 以前に見たある開発チームでは、ソースコードのコミットの度にその旨を通知するメールをメンバー全員に手作業で送っていた。もちろん、手作業だから忘れることもあるし、必要な情報が欠落していたり、誤記が有ったりする。そんな面倒で、しかも不確実な作業をなぜ繰り返し行なっているのか担当者に聞いてみたら「それが決まりだから」という返事しか返ってこなかった。 ルールであることは分かっている。知りたいのは「何のためにそのようなルールがあり、メール送ることが
技術を知っているという思い込みが怖い - rabbit2goのブログ
ソフトウェアの開発現場には様々な人がいて、コードをガンガン書き続ける開発者がいる一方で、協力会社向けの仕様書を書き続ける人や、ひたすら打ち合わせを続けて「仕様調整」「工程管理」「障害対策」に励む人もいる。毎年新入社員が入ってくると聞かれるFAQの一つに「ソースコードを書かない開発者は一体何をしているのか？」というものが有るけれど、そんな開発現場の実態も学校の授業ではなかなか教えてくれないことなのだろう。 実際のところ「開発部門に所属しながらソースコードを書いたことがない（書けない）」人も全然珍しくなくて、開発のスキルと管理のスキルは異なったりするから、それはそれで業務分担として構わないのものの、厄介なのはそのような人に限って「自分は技術を分かっていると心の底から信じ込んでいる」点だと思う。 日々、ソースコードを相手に格闘している開発者だと、そもそも「ある環境（プラットフォーム、仕組み）で実
勉強しない技術者 - rabbit2goのブログ
職場の雑談で、週末に読んだ技術書の話をしたことがある。特に難しい本でもないし、気軽に読めるものだったのだけど、その時の相手の反応は「休みの日に本なんか読んで勉強しているのですか？」だった。自分では本を読むことくらいアタリマエの事であり、特に勉強という意識を持っていなかったのだけど、彼にとっては家で仕事に関する書物を読むなんてトンデモナイことだったらしい。勉強するから偉いなんて言うつもりはないけど、会社の外でスキルアップの努力をしない開発者の行く末は見えているような気がする。 学生時代は勉強していた人も、社会人になって勉強の習慣を無くしてしまうのは不思議なことだ。会社の仕事を言われた通りにこなしているだけでは、多数の中の一人に終わってしまう。多数の中に埋もれない自分だけのブランドを確立するには、それなりの努力が必要だろう。会社の上司が週末のゴルフの自慢話をするからと言って、わざわざ自分もレベ
コーディング規約を考える前に - rabbit2goのブログ
開発プロジェクトのコーディング規約をどうすべきか相談を受けることがある。コーディング規約なんて探せばいろいろ出回っているし、自分たちでゼロから作っても良いとは思うけど、この数年はいつも下記のように答えることにしている。 「Code Completeを読め。この内容を全て実践してもまだ問題が残るのなら、改めて相談に乗る」 この本にはコーディング規約だけではなく、基本的な設計手法、適切な関数の行数、変数の命名規則、複雑化するソフトへの対処、バグを出さないための考え方など豊富な指針が大変細かく記載されており、ソフトウェア開発者のバイブルと言っても良い本だ。ソフトウェア開発者ならこの本に書かれている程度の事は理解していて欲しいし、理解しておくべきだと思う。上下巻に載っている情報量は膨大なものがあるけど、開発者にとっては全て重要なガイドラインであり、不可欠の内容と言っても過言ではない。 使用する開発
仕様書をSubversionとTracで管理する - rabbit2goのブログ
議事録をTracへ載せる話は「議事録はTracへ」に書いたけれど、今度は仕様書の話。ソフトウェア開発の構成管理にはSubversionを使っており、その中にはソースコードだけではなく、WordやExcelで作った資料も入れるようにしている。以前はサーバの共有フォルダに入れていたけれど、色々な面で問題が有ったのでSubversionとTracを使うようにした。目的は下記の通り。 仕様変更の確実な履歴管理 Wordファイル自体に変更履歴を管理する機能はあるけれど、ファイルを開いてみなければ分からないし、必ず履歴が残っているという保証も無い（誰かが変更箇所を承認してしまった等）ので、あまり使える機能ではない。確かに、短期的に変更点を知ってもらうには分かりやすくて便利なのだけど、長期的な保存に耐えうる機能ではないと思う。そこで構成管理へ入れるようにすれば、遙か昔の履歴も確実に残るので安心だ。 ソー
クローズ処理で例外は発生するのか？ - rabbit2goのブログ
昔から疑問に思っているのだけど、ファイルやストリームでのclose処理ではどんな条件の時に例外（エラー）が発生するのだろうか？例えば、open処理ならファイルが存在しないと直ぐに例外が発生するし、write処理はディスク容量が無いとか書き込み権限がないと例外が発生する。read処理もネットワークでの読み込み時に接続が切れたりすると例外が発生しやすい。しかし、経験的に言ってclose処理ではなかなか例外が起こらないようだ。 例えば、JavaのInputStream#close()ではJavaDocに下記の説明が記載されている。仕様として「入出力エラー」が発生する可能性は確かに存在するらしい。 例外: IOException - 入出力エラーが発生した場合 Oracle Technology Network for Java Developers | Oracle Technology Net
失敗事例からノウハウを学ぶ - rabbit2goのブログ
失敗知識データベースというサイトがある。モノ作りで発生した事故や問題の事例を集め、その分析を行い教訓として生かしましょうというのが主旨だ。例えば、2002年に起きた「みずほフィナンシャルグループ大規模システム障害」といった事例も載っており、問題発生時の状況や原因分析が簡潔にまとめられているので参考にある。今でこそ、こんな問題が有ったねぇと読み返せるけど、当時の関係者はかなり大変だっただろうと思う。他人の不幸は蜜の味なんて言ってはいけない。明日は我が身に起こりえることなのだから。 http://shippai.jst.go.jp/fkd/Search このサイトにヒントを得て、バグ事例をグループ内に集めて示したことがある。例えば、nullアクセスが起こりソフトが異常終了したという事例を載せ、問題が発生した状況や対策案などを並べてみた。問題を引き起こした担当者は「nullチェックが漏れていまし
JUnitの使いこなし方を学ぶ本「JUnitイン・アクション」 - rabbit2goのブログ
テスト駆動開発やJUnitを使い始めた頃に読んだ本。手元の本は2004年5月発行の初版なので、もう6年（！）も前の本になる。JUnit自体は（やや乱暴な言い方かも知れないけど）Assertによる検証をシステマティックに行うものであり、特に難しいものではない。例えば、「1+1の演算結果」が「期待通りの値である2になるか？」を確認するというという基本的なサンプルがよく紹介されているし、使い方としてはこれに尽きると思う。 むしろ難しいのは、ソフトウェアの設計として「いかにテストしやすい形の構成にするか？」という点だろう。仕様書通りに組み上げたソフトウェアでは残念ながら粒度が荒すぎるし、テスト対象も広過ぎる。様々なしがらみが付いて回るので、検証のためにはダミーデータを準備しておく必要があるかも知れない。だから、コードの設計を少し変えて、検証しやすい形態にする方がずっと重要なのだ。これらの考え方を総
全ての仕様にURLを付けたらどうか？ - rabbit2goのブログ
tracの障害チケットに目を通していたら、該当する仕様としてこんな記載が載っていた。 ○×仕様書の□ページの上から△行目に記載されている〜について... 大きな偏見だと思うけど、Word等で記載されたダラダラとした文章が並ぶ仕様書を見ると「これは要注意」という黄色いランプが点滅してしまう。複数のセンテンスから成る文章全体で一つの仕様が構成されるという趣旨は分かるけれど、そもそも「どこからどこまでが一つの完結した仕様」なのか分からないし、他の資料との紐付けがやりにくい。例えば、上記のような書き方では、資料に追記・削除が行われたらレイアウトが崩れ、意味を成さない記述になってしまうので、後から見た人は関連する箇所を辿れないことになる。 仕様書は小説でもエッセイでもないのだから凝った表現は不要であり、もっと形式的な書き方に力を注ぐべきではないかと思う。だから仕様書の記載では章立てを確実に行い、個々
開発環境の逆転現象 - rabbit2goのブログ
ソフトウェア開発を行う企業の規模は様々だけど、大きな会社と小さな会社（特にIT系のベンチャー企業）で異なるのは、開発環境ではないだろうか？よく見聞きする事例として、こんなものが有る。 大企業：一昔前のパソコンと小さなモニタという貧相な開発環境を使っている。固定資産の関係や社内規定のルールが厳しいため新しい環境には直ぐに買い換えられず、買い替えの要望を出すと「贅沢を言うな」「経費の無駄使い」と怒られる。 ベンチャー企業：常に最新のパソコンと大型液晶モニタが社員に与えられており、開発の作業効率が高い。パソコンのスペックに五月蝿い開発者も多いため、その点に配慮した導入も考慮されている。 大企業：ノートパソコンの社外持ち出しが禁止されているため、社外での打ち合わせ時にはノートとペンが欠かせない。また、自宅への持ち帰りもご法度なので、家で仕事をすることが出来ない。 ベンチャー企業：最新の携帯用パソコ
開発現場の不満を取り除くのがリーダの仕事 - rabbit2goのブログ
ソフトウェア開発現場に種々の不満は尽きないけれど、そんな担当者の不平、不満、要望、要求を一つ一つ取り上げて対処し、決して無視しないのがリーダの大切な仕事ではないかと思う。担当者が快適に、しかも気分良く仕事を進められるからこそ、チームとしての力が発揮できるのであり、成果物のQCDにも繋がるのだろう。チーム管理というとメンバに対して「あれをやれ」「これをやれ」と指図することが仕事だと思われがちだけど、同じくらいに大切なのはその仕事がスムーズに進められるようにお膳立てをすることだと思う。 優れたプロジェクトリーダは、メンバとの話の中から種々の問題を確実に捉え、解決に向かって努力することが多い。仕事の進め方、作業方法、工夫など、仕事に直結することから間接的なことまで、チームや開発者の個人レベルで改善出来る問題は少なくないはずだ。「チームとしてここまでは改善出来る、これは理由があって対処できない、こ
設計書が必要な理由 - rabbit2goのブログ
「ソースコードが設計書。だから別の設計資料なんか要らない」と言っている人がいた。Webでも同じような見解を見ることがあるし、こんな運用ルールで事足りる開発現場も有るのだろう。確かにこれはこれで一理あると思う。私だって個人的に作っているソフトに、必ずしも設計書を作っているわけではない。 しかし、100万行単位のレベルで組織的にソフトウェア開発を行っている現場（うちのことだ）では、こんなやり方は通用しない。理由は下記の通り。 ある機能が100万行のソースコードの何処に入っているか分からない。 そもそも、ある機能が100万行のコードの中に含まれているのか分からない。 機能追加・変更・修正に伴う影響範囲が、100万行のコードの何処まで及ぶのか分からない。 例えば、開発現場に入ってきたばかりの協力会社の人に応援を頼む場合、100万行というコードの海を直ぐに泳げと言うのは、無理な相談だろう。そこで作業
やっぱりベテランは使えない - rabbit2goのブログ
ソフトウェア開発の現場にいるベテランには、他の人の手本となるような達人もいるけれど、その一方で見習ってはいけない悪い見本の人も少なからずいる。その一例。 開発資料を作らない 「ソースコードを読めば分かる」「資料を書くのは労力の無駄」と豪語して資料を何も作らない。後からフォローする人は、そもそも何をやっているコードなのか？などコードの設計思想や背景を読み取れないので苦労する。 自分の立場を分かっていない 開発チームを良い方向へ導くとか、若手の指導を行うという積極的な態度に欠ける。チームへの協力的な姿勢が無く、組織のあり方とか、ビジネスの方向性といった視点を持っていない。 知識を共有しない 「自分の持っている知識は大したことない」と謙遜するそぶりを見せながらも、自分からは決して情報発信を行わない。他人の情報には文句を付けるのに、自分からは何も出そうとしない。 新しい技術に挑戦しない 歳をとって
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
