ソフトウェア開発

仕様の表現力で発注者の力量が分かってしまう

「この位の仕様で上手く作っておいて」とひと言伝えておけば、望み通りのシステム一式が出来上がって来ると嬉しい。これなら細かい点まであれこれと指示する必要も無く手間が省けるし、期待通りのモノが期待通りの納期、品質で出来上がってくれば万々歳だ。…

デブサミ2015に参加した

先週金曜日(2015/02/20)はデブサミ2015に参加してきた。会場はいつもの目黒雅叙園で来場者も多く、活気のあるイベントだった。 様々な抵抗や障壁を乗り越えて、アクションを成功させるためには、継続と改善のプロセスが必要です。言い換えれば、継続的にアク…

デベロッパーズサミット2013に参加した

昨日(2013/02/15)は目黒雅叙園で行われていたデブサミ2013に参加してきた。今年も相変わらず参加者が多く、休憩時間に混んでいる通路を通って他の部屋に移動するのは大変だったけど、開発の最前線で闘う(あるいは現場から逃げ出してきた?)開発者の熱気を…

ET2012に参加した

先週はパシフィコ横浜で開催されていたEmbedded Technology 2012(ET2012)へ参加してきた。 http://www1.jasa.or.jp/et/ET2012/index.html 不景気な世の中だけど、会場は来場者が多くてかなり混み合っていた。もっとも、スーツ姿の人の比率が高くて、(これは…

最近の開発現場はギャグとしか思えない

知人とコソコソと世間話。最近の開発現場は面白いことが多過ぎるという点で意見が一致してしまう。その一例。 人の入れ替わりが激しくて技術やノウハウが蓄積しない。忙しくなるとスキルよりも経験よりも頭数を揃えることを主目的にやたらと人を集めるものの…

派生開発セミナー「XDDP関西勉強会」に参加してきた

先週の金曜日(2012/8/3)はXDDPの勉強会に参加してきた。得るものが多かったので、その内容を紹介したい。 http://kokucheese.com/event/index/44223/ 講師は派生開発(XDDP)でお馴染みの清水吉男氏。会場は50人近い参加者で満員の状態だった。以下、講演のメ…

チームのためにナンバー2を育てよ

開発の現場では毎日様々な問題が発生するし、対外的な打合せや非定型業務、割り込み作業も多くて、リーダと言えども、開発チームの進捗状況を必ずしも全て把握出来ているとは限らない。自分が逐次作業指示を出してメンバを動かすのが仕事とはいえ、指示を受…

リスク回避型開発の行き着くところ

開発の現場には様々なリスクが存在するから、それらに考慮した方策を取ることが必要になる。 まずはプロトタイプを作ってみて、本開発前に技術的課題を洗い出す。 難易度の高い部分から着手して、問題発生時の検討時間を確保しておく。 後工程での影響度が大…

重要ファイルはSubversionで管理する

頻繁に情報を更新するファイル(例えばソースコード)なら当然のごとくSubversion等の構成管理下に入れているけど、日常の業務で使用するファイルでも同様の利用は有効で、しかも更新頻度が低いファイルこそ実は効果が有るのではないかと思っている。頻繁に…

第3回RxTstudy勉強会に参加した

一昨日(2012/2/4)は第3回RxTstudy勉強会に参加してきた。広い会場は大勢の方が集まっていて活気があり、チケット駆動開発はメジャーな開発手法の一つとして認知されてきたようだ。以下、その感想を簡単にまとめてみたい。 「Redmineプラグインの作り方」(@a…

メールの履歴をRedmineのフォーラムに載せる

ソフトウェア開発の現場では、様々な仕様変更の依頼が頻繁に届く。曰く、お客さんからの要望が変わった、他チームで担当していた部分とのインターフェースが変更になった、割り込み作業の指示が入った等々。そんな変更管理は全てRedmineのチケットに放り込ん…

SEA関西プロセス分科会「モデリングの本質」に参加した

昨日は第46回SEA関西プロセス分科会「モデリングの本質」に参加してきた。講師は「UMLモデリングの本質第二版」の著者として有名な児玉公信氏。著書はもちろん事前に読んでいたので、どのような興味深いトピックスが飛び出してくるのかと興味津々であり、同…

Excel駆動開発は時代遅れではないか

その昔、要求仕様やら画面仕様、シーケンス図、仕様に関する問い合わせのやり取り、バグ票、工程管理のガントチャート、議事録の類を一切合切Excelのファイルで管理している開発プロジェクトを見たことがある。各分類毎にサーバの共有フォルダにズラリと並ん…

障害対応の工数は謎だらけ

開発現場では、新規の開発案件等に対して必要工数の見積もりを要求され、それはそれなりに難しいものが有るけれど、それ以上に難しいのは障害対応の工数見積もりだと思う。もちろん、内容を一目見て容易に原因と修正内容が分かるものがある一方で、原因の調…

改善活動を進めると収入が減ってしまう

ソフトウェア開発の現場では様々な作業が発生するけれど、コミット毎の自動ビルドや回帰テスト実行など、人間の手を介さずに実行できるものは出来るだけ自動化を図るようにしている。最近はJenkinsを始めとするCIツールや上手い使いこなし方などの情報も豊富…

開発者を使い捨てにする会社の話

開発に関わる種々の問題を抱えている状況はどこも似たようなものだし、開発者同士でアイデアを出し合ったり、上手くいった(行かなかった)事例を紹介すれば、互いに参考にしながら上手くやっていけそうな気もする。だから、商売云々の話は別として、開発現…

下流工程の軽視を憂う

仕事では英語のやり取りが必要なので、時々メールや資料の翻訳を頼まれることがある。もちろん、ネットでは無料の翻訳サービスが有るので、和訳の方は利用する人が多いようけれど、さすがに英訳の方は機械翻訳そのままの文章を送付することにためらいを感じ…

ボトルネックは開発リーダ

チーム内の作業が上手く回っていないという開発の様子を観察すると、なかなか興味深いものがある。 リーダはなぜか常に忙しい夜遅くまで残って残業するほど忙しいようなのだが、その忙しさの原因を聞いても本人の口からまともな説明は返ってこない。つまり、…

Agile Tour Osaka 2011に参加した

昨日(2011/10/08)は、Agile Tour Osaka 2011に参加してきた。気のせいか、参加者は昨年よりやや少ないような気がしたけど、会場は熱いマインドを持つ人が集まってきており活気あるイベントだった。 Agile Tour Osaka (Japan) | agiletour.org Agile Tourは、…

頑張らないプロジェクトの勧め

日本人はとにかく精神論が好きだから、開発プロジェクトが始まると「皆、全力で頑張ろう」という掛け声がかかるのだけど、個人的にはそのような意味の無いスローガンが出てきた時点でもう終わっていると思う。頑張って見事に成功したプロジェクトなんて見た…

孤独なソフトウェアエンジニアの味方です

好きでやっているソフトウェア開発の仕事だけど、周囲を見渡すと実はこんな仕事は好きではないと言い切る人が多くて驚いたことがある。与えられた仕事だけをやっておけば万事OK、チーム全体のレベル向上やプロセス改善、新しい創意工夫なんて自分には関係な…

「多い」「少ない」という不毛な議論

開発現場で良く聞くプロジェクト評価の表現として、こんなものがある。 バグが多い 忙しくて残業が多い レビューが少ない 経験に基づく直感というものは凄く大事(しかも意外に良く当たる)だし、当事者間で意識共有を図るには何も問題ない表現だと思うけど…

仕様変更を言い出すのは誰か?

ソフトウェア開発時の仕様変更は頭が痛い問題だ。限られた時間とリソースの中で開発を進めているのに、仕様変更に伴う追加作業は「既存工程の中で吸収する」なんて言う、いかにも日本人的な対処を余儀なくされることが多い。工程が延びても、コードを書き上…

仕様変更の影響範囲はどこまで及ぶのか?

ソフトウェアの障害管理表を見ていたら、こんな問題を見つけた。概略を簡単に示すとこのようになる。 問題:ある特定の条件下である操作を行うと、アプリケーションがエラーを起こす。 原因:仕様変更の連絡が不充分で、担当者への連絡が出来ていなかった。 …

それは大いなる勘違い

自分に与えられた仕事上の役割や役職が、あたかも自分の能力であるかの如く勘違いする人が時々いるので困ってしまう。 システム開発の上流工程を担当するようになった。 派遣社員や協力会社に指示を出すようになった。 開発担当からチームをまとめるリーダ役…

ソースコードを読みにくい理由

慣れない環境や言語で書かれたソースコードを読み解くのはなかなか大変だ。個々の処理は分かるのに、それによって実現される一連の機能を理解するには、また別の能力を必要とするのかも知れない。そんなコードの読みにくさは、こんな所に起因するのではない…

Alloyで形式手法を学ぶ本「抽象によるソフトウェア設計」

UMLの図面を描いていてもどかしく感じるのは、モデルで表現された概念が本当に矛盾・モレ無く実行可能なのか確信を持てない点だと思う。シーケンス図やステートマシン図なら動的な振る舞いを示すものなので理解しやすいし、動作をシミュレーションできるツー…

ボーダーレスな開発の時代

昔のソフトウェア開発なら、いわゆる業務系、ウェブ系、組み込み系といったカテゴリがあって、開発者はいずれかのカテゴリに属しているのが普通だったし、各々の技術者では前提となる知識が異なっていたので話が通じないことも多かった。同じ開発言語を使っ…

既知の問題を潰す方が簡単だ

ソフトウェアの開発現場では毎日様々な問題が起こるけれど、その問題は、基本的に下記のいずれかのカテゴリに分類されると思う。 未だかつて経験したことの無い未知の問題 既にどこかで経験したことの有る既知の問題 新しい種類の問題に対処するのは大変だ。…

そのチケットは保留

Tracのチケットを使ってタスクを管理していると、中には「今すぐアクションは起こせないけれど、かと言ってクローズも出来ない」という宙ぶらりんなものが出てくる。そのようなチケットの一例。 顧客からの要望事項必須の機能なら対応するのだけど、単に一件…