当たり前のことを、と思われるかもしれませんが、恐らくご想像されたことと少しだけ違うことを提言できるかな？と思っています。 プロジェクトが終わった後、経験したことをふりかえり、次のステップに活かせるようにしたほうが良いことは異論の無いことと思…

先日は、最初は小さく成功することが大切という話を書きましたが、その次は何に手をつけるべきでしょうか？ 必ずとまで言い切りませんが、私は「最大の課題から取り組む」ことを基本にしています。 「最大の課題」は、ステークホルダー間の利害対立、検証す…

新しくお付き合いを始める顧客との初仕事では、まず小さく成功することがとても大事だと言われます。 プロジェクトの早い時期に実らせる小さな成功は、顧客に「最低限、一緒に仕事ができそうなチームらしい」という安心を提供することができます。顧客（実は…

トラブル対応や、顧客から追加作業の依頼を受けた時などの、想定外の事態に直面した部下やチームのメンバーから 「ｘｘということが発生していて、〜して、〜するという対応をしたいと思うのですがいいですか？」 と承認を求められることが、時々あります。…

議論の結果や、報告用の資料づくりでもそうなんですが、なんかキレイにまとまることがあります。 そんな時は達成感もあって気持ちいいのですが、キレイにまとまった時は実は要注意です。 キレイにまとまった話には、何か見落としがあり、本当によくできてい…

最近、お願いした仕事がうまく進まないなあ、と感じることがあって何が問題だったのか自分なりに考えて見ました。 仕事をお願いするときに気をつけるべきポイントは ゴールをちゃんと説明したか 守ってもらいたいプロセスを説明したか プロセスが遂行されて…

ソフトウェアの設計やコーディングを進める中で、ユーザーに質問したいことはたくさんあります。もちろん、打ち合わせの場を持てるときは対面で聞くのが、認識のずれを防ぐ意味でも、ユーザーとの心理的な距離を縮めるにも、一番です。 しかし、次の打ち合わ…

私の勤める会社では時々、やたらと細かい設計書を書きたがる人達を見掛けます。そんな時、誰かれ構わず注意するわけでもありませんが自分の部下には設計書には三つの役割がある、と教えてます。その役割は (特に外部仕様を決めるステップで、)実装対象要件に…

要件定義や基本設計の工程を進めているとエンジニアとして ユーザーの希望することは出来るだけ実現してあげたいという 想いを持つのは良いことですし、また、そういう気持ちを 大事にして欲しい、とも思います。しかし後輩に任せてみると、傍目にはオーバー…

ヨソの会社ではこんなコト無いんでしょうか？ ウチの会社で私が後輩たちに教えることに 「何でもかんでも、書くんじゃない！」 というのがあります。ソフトウェアの要件定義や基本設計で、ユーザーと打ち合わせる際に ユーザーは様々な要望を伝えてくれます…

顧客との調整の中で漏れてはいけないことはたくさんあります。でも、後で揉めないために絶対に気をつけた方がいいのは 「何をしないか」に合意しておくということ。 引き受けないコト 作らないモノ 考慮の範囲外に分類するコトやモノ 顧客と揉めることと言え…

「はじめに」だけで置いとくわけにも行かないので、 いきなりで申し訳ないのですが再利用ネタから・・・(^^; ■ウォーターフォールでも使える七つのプラクティス 〜会議編〜これは、昨年のライトニングトークネタだったのですが 私がアジャイルの特徴的な考え…

以前から何か書こうかな〜と思ってたのですが、 いいテーマが思いつかず、なんとなく先延ばしに してしまっていました。先日、後輩に仕事を教えているときに、自分も いろんな人に仕事を教わり、失敗を重ねながら 工夫してきたことに気づき、これを書き留め…