最近の開発現場はギャグとしか思えない - rabbit2goのブログ
知人とコソコソと世間話。最近の開発現場は面白いことが多過ぎるという点で意見が一致してしまう。その一例。 人の入れ替わりが激しくて技術やノウハウが蓄積しない。忙しくなるとスキルよりも経験よりも頭数を揃えることを主目的にやたらと人を集めるものの、プロジェクトが終わると直ぐさま関係を切ってしまうので継続的な蓄積が何も残らない。 コンプライアンスの掛け声の下、関係者以外にも情報が見えてしまうホワイトボードやRedmineによる情報共有はご法度。セキュリティ対策も厳しくなる一方なので、ソフトをダウンロードしてパソコンに入れるだけで、正義感の塊のような監視委員から直ぐさま電話がかかってくる。 行き当たりばったりの対策を取り続けているので、何か問題が有ってもブレーンストーミングで出てきたようなアイデア案ばかりが続く。根本原因を探ることをしないし、そもそもそんな追求を行うスキルすら無い。 人月単価に惹かれ
仕様変更を言い出すのは誰か？ - rabbit2goのブログ
ソフトウェア開発時の仕様変更は頭が痛い問題だ。限られた時間とリソースの中で開発を進めているのに、仕様変更に伴う追加作業は「既存工程の中で吸収する」なんて言う、いかにも日本人的な対処を余儀なくされることが多い。工程が延びても、コードを書き上げテストを行って動作確認までした成果物に再び手を入れなければならないという精神的なダメージも大きいと思う。 「お客さんの要望だから仕方ない」という理由は分かるし、「仕様変更しなければ製品が売れない」という理屈も納得できる。それは正論だ。しかし、だからと言って、何度も仕様変更を続けて、開発現場に負荷をかけるやり方が正しいとは到底思えないような気がする。モノには限度というものがあり、それを越えた仕様変更は然るべき理由と共に拒否するのが当然ではないかと思う。 そんな度重なる仕様変更に腹を立てて、仕様変更の要求が来る度にTracのチケットを起票したことがある。記載
ボトルネックは開発リーダ - rabbit2goのブログ
チーム内の作業が上手く回っていないという開発の様子を観察すると、なかなか興味深いものがある。 リーダはなぜか常に忙しい 夜遅くまで残って残業するほど忙しいようなのだが、その忙しさの原因を聞いても本人の口からまともな説明は返ってこない。つまり、何が原因で忙しく、今後の見通しはどうなっているのか、本人自身が分かっていないのだ。自分自身の忙しさに酔いしれているリーダは、とにかく忙しいことが嬉しいらしい。 問題の全貌が見えない プロジェクトのヒアリングを進めると、アレも有ってコレも有ってと次々と問題が出てくるものの、その総数が不明で、現在どの段階まで達しているのか不明だ。問題が残っているという点だけは同意だけど、それに勝るとも劣らず解決済みの問題も多数存在するはずであり、その日々の変化を追跡していけば最後の着地点が見えてくるはずだ。それなのに、同じ問題を何度も繰り返し取り上げて堂々巡りの議論を続け
無知なリーダーがもたらす災厄 - rabbit2goのブログ
隣のチームの仕事ぶりを知ると、自チームで当たり前に出来ていることが全然出来ていなかったり、或いはその逆のケースも有ったりして興味深い。ペアプログラミングなんて言う言葉があるけれど、チームリーダは隣のリーダと一緒に働いて互いの働き方から学ぶべきではないかと思ったりする。リーダーがペアでマネジメントを行えば、もう少しマトモになるチームも多いのではないだろうか。 以前に見たある開発チームでは、ソースコードのコミットの度にその旨を通知するメールをメンバー全員に手作業で送っていた。もちろん、手作業だから忘れることもあるし、必要な情報が欠落していたり、誤記が有ったりする。そんな面倒で、しかも不確実な作業をなぜ繰り返し行なっているのか担当者に聞いてみたら「それが決まりだから」という返事しか返ってこなかった。 ルールであることは分かっている。知りたいのは「何のためにそのようなルールがあり、メール送ることが
去りゆく技術者 - rabbit2goのブログ
会社で仕事をしていて辛く感じることの一つに、長年一緒に仕事をしてきた仲間の離職がある。個人や家庭の事情などいろいろ理由はあるようだけど、個人的に話を聞いてみると、技術者として会社の置かれている状況や自分の立場を分析して苦渋の結論を下していることが多い。もちろん「給料を上げて欲しい」という要望を受けても私にはどうすることも出来ないけれど、お金に対する不満を言う開発者は意外にもほとんどいない。 むしろ、「コロコロと変わる経営方針に愛想が尽きた」「成果主義と言いつつ成果を出した人が報われていない」「技術的にやり甲斐がある仕事を任せてもらえない」等々、技術者へ確固たる方針と青写真を示せていないマネジメントへの不満が大きいようだ。「この環境では自分の技術力を磨けない」と言うくらいの覇気のある人なら、次の環境で頑張れと笑顔で送り出せるけれど、組織の問題を訴える人に対して現場の人間に出来ることはあまり無
私家版テスト駆動開発 - rabbit2goのブログ
テスト駆動開発(TDD)をやってみたいけど最初の一歩がなかなか踏み出せないという人が少なくないようだ。あまり形式張らずに出来るところから少しずつでも挑んでいくのがコツだと思うのだけど、教科書に出てくる「正しいやり方」に躊躇してしまうケースがあるらしい。そんな訳で、今回は我流のテスト駆動開発方法を紹介してみたい。 テスト戦略を決める 制限のある開発期間内に効率的にテストコードを作る必要がある以上、何を目標として何処までをテストすべきか目標を決めておくことは欠かせない。もちろん、カバレッジ100%のコード作成は望ましいものの、異常系を含めてそこまでの網羅率を実現するのは難しいことが多いし、GUI処理は時間をかけてマクロを作るより人間が目視で確認した方が手っ取り早かったりする。費用対効果を考えて、もっとも効果の大きい箇所を重点的にテストコードでカバーすることを考えたい。 テストコードは後付け 由
社外コミュニティとの温度差 - rabbit2goのブログ
社外の勉強会やイベントに参加することがある。そんなところに来る人は、会社の命令で来ている一部を除き、たぶん自発的に何かを求めて来ているはずだし、自分のプライベートな時間を割いて来るくらいだからモチベーションが高くやる気もあるはずだ。そんな人たちと話をしていると自分の方にも意欲が湧き出てくるし、負けずに頑張らねばと思ってしまう。 しかしながら、会社へ戻ると必ずしも意欲の高い人たちばかりではない。ソフトウェア開発が好きという人ばかりではないし、仕事だから言われたことをやるだけですと割り切っている人も珍しくない。全員が前向きな意欲を持って仕事をしているとは限らないのだ。そんな人たちに向かって、「これをやりましょう」「あれを改善しましょう」「新しいやり方を取り入れましょう」と言ってみても、空回りすることが少なくない。熱き思いを持つ社外のコミュニティと、冷めた社内の開発者の間に、これほどまでの温度差
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
