それ本当に意味ある!?システム開発を進める上での不毛な行為

業務としてシステム開発をしていくと「それ本当に意味ある!?」とツッコミを入れたくなってしまうようなイベントが多々発生するものです。業務担当者としては「不毛だ・・」と思ってしまいがちですが、開発のルールとして定められている以上、従うしかない状況もしばしば。 今回はそんなシステム開発を進めていく上での不毛な行為について、いくつか事例を挙げながらお話していきたいと思います。 適切なバグ密度に合わせてバグ製造...

オフショア先や同じチーム内での外国人SEとの連携・付き合い方

日本国内のシステム開発であっても、開発チームが日本人SEで構成されるとは限りません。チーム内の外国人エンジニアと連携して開発を進めたり、オフショア開発であれば製造工程を海外に委託することになります。 そこで必要なのが外国人エンジニアとの連携・コミュニケーションです。日本人同士のコミュニケーションであれば、お互いに空気を読みあったり「普通こうするよね」みたいな暗黙の了解で、なんだかんだ上手く事が進むものですが、相手が外国人SEであれば日本の常識は通用しません。...

PMとして開発プロジェクトを円滑に進めるには正論だけではいけない

PMとして開発プロジェクトを進めていく際には、WBSに代表されるような工程表を用意して、各タスクに担当メンバーを割り当てて、滞りなく工程が進んでいるのかチェックしていきます。 スムーズに開発が進めばよいのですが、工程を進めていく中であらゆるトラブルが発生するのが、システム開発の常であります。 PMとしてはそうしたトラブル対応も含めて、円滑にプロジェクトを進めていく器量が求められるわけですが、今回は正論を振りかざすだけではプロジェクトは円滑には進まないという話をしていきたいと思います。 前提:ルール無用というわけではない...

顧客折衝の手引き。ユーザーを上手にコントロールするテクニック

クライアントワークとしてのシステム開発をしていると、要件定義、仕様確定、納期や予算のことなど、なにかとお客様との調整ごとが発生します。 こうした調整ごとを上手くこなせると、プロジェクトを推進する上でもスムーズに事が運びます。仕事としてSEをやっていくなら、技術面だけを磨くのではなく、顧客折衝といった面も磨いていきたいところです。 と言うわけでユーザーを上手にコントロールするテクニックについて、お話ししていきたいと思います。 顧客打合せは提案を交えることで主導権を握る...

新米プログラマーが犯しがちな読みにくいソースコードの事例

プログラミングはある種”慣れ”のようなものが大事になってきます。理論よりも経験と言うべきでしょうか、経験を積むことで、徐々に洗練された美しいソースコードが書けるようになるものです。 ですがこれからプログラマーとして働いていく上で、新米プログラマーがよくやってしまいがちな、ソースコードを読みにくくする行為も、知っておいて損にはなりません。 新人プログラマーが書く読みにくいソースコードの事例を、いくつか挙げていきたいと思います。 インデントされていないソースコード...

開発スケジュールの遅れ(工程遅延)を取り戻すためにやるべきこと

開発スケジュールは遅れるもの。という常識を持ってはいませんでしょうか? 本来スケジュールは遵守するものであり、工程遅延はあってはならないものです。 ですが悲しいかな・・遵守すべき開発スケジュールが遅れてしまうことは多々発生します(きっと現時点も日本のどこかでは工程遅延により炎上プロジェクトが生まれていることでしょう)。 ですが実際にスケジュールが遅れてしまえば、なんとかしてリカバリするしかありません。今回は工程遅れが生じた際に、SEとしてやるべきことについてご説明していきます。 残業する...