お客様や同僚から言われる「この仕様をドキュメントにまとめてもらえますか？急いでいないので、”ゆっくり”で良いですよ」という言葉。
よくある会話ですが、この「ゆっくり」の捉え方によっては、ちょっと痛い目を見るかも知れません。

「ゆっくり」の違い

「ゆっくり」が具体的な時間、日にちでどれくらいなのかはその人、背景や依頼内容といった状況によって違ってきます。

その中で、依頼を受けた側は「ゆっくり」を”4日間”と思い込み、依頼を出した側は”今日中じゃなくても良いけど、明日くらい(2日間)”と考えていたとします。

この場合、2日後に依頼者は「ゆっくりとは言ったものの、ちょっと遅いなぁ」と気になり始めます。ゆっくりと依頼したため、「まだですか？」と催促しづらく、ひとりイライラすることもあるでしょう。

一方、依頼された側は、3日後に依頼を終えて返事をしたとします。その時、少しイライラして不満顔の依頼者を見て「あれ？ゆっくりで良かったんだよね？」とモヤモヤとした気分になります。
＃また逆に、「あれ、そんなに早くなくて良かったのに…」と言われ、別の意味でモヤモヤすることもあるでしょう。

絶対的な物差しにする

人や状況によって違う「ゆっくり」という相対的な物差しを、「○日の△時」という絶対的な物差しにすれば良いだけです。

文字にすると単純なことですが、話の流れ、場の雰囲気によっては、何となく流してしまったり、聞くことができず、そのままになりがちです。それを放置していると、冒頭のようなすれ違いが起きてしまいます。

絶対的な物差しにする際、「いつまでですか！？」と反射的に尋ねるのではなく「○日までに返事しますが、問題無いですか？」と自分なりの見解を伝える工夫をします。
こうすると依頼した相手も「ちゃんと考えてくれている」と信頼し、安心することができます。

ちょっとした(心遣いまではいかない)工夫で、少しでも円滑に回れば嬉しいものです。

※この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。

Photo credit: malias via Visual hunt / CC BY

あるエンジニアと話した時に「雛鳥が親鳥からエサをもらうように口を開けて待っているだけでなく、一歩進んで、アクションを起こしてみてはどうか？」と思うことがあります。

やりたいことを周囲に伝えていますか？

「これからどんな仕事に携わったみたい？どういうことをやってみたい？」と質問を投げた時の反応は様々です。

「平穏にサラリーマンできればいいです」という声もあれば、「プロジェクトマネージャーになって大きなプロジェクトを回してみたい」「アーキテクトになって技術でリードしたい」「もっとお客様に提案したい」「今はJavaだけど、これからはRubyでプログラミングしたい」など、様々なやりたいこと、ありたい姿、キャリアプランなどその人の想いが出てきます。

このようなやりたいことは、何もせず待っているだけで実現することは稀なことであり、実現するためには「私はこれをしたい！」と周囲に知らせる、発信する必要があります。定期的にあるフォーマルな評価面談から、呑み会やちょっとした日常会話でのインフォーマルな場まで色々機会があります。
＃自分の経験で、ポロッと社内SNSで呟いたことが、関係者の目に止まってやりたかったことができるようになった話もあります。

このような発信を受け取った上司は「自分からやろうとしていることをなんとか実現してあげたい」という心境になるのが大半かと思います。

やりたいことを実現するために何かしていますか？

そこで「それをやるために、今まで何をしてきた？」「Rubyがしたい？ならサンプルで書いてみてどうだった？」「プロジェクトマネージャーになりたい？今一緒にやっているプロジェクトマネージャーから何を学んだ？」と”やりたいことに近づくアクション”の話になると、本人は途端にトーンダウンしまうことがあります。
「そこまではやる時間がなくて(ゴニョゴニョ)」「実際に使うプロジェクトに入るのが決まってから勉強しようかと(ゴニョゴニョ)」といった様子です。

今の自分が「できること」と「実際にしたいこと」にはギャップがあります。そのギャップを埋めるのは自分です。誰かが埋めやすくなるように手伝ってくれることはありますが、最後は自分で行動して埋めるしかありません。

こういう発信を受け取った上司はこのようなアクションをしているか？そのアクションのアウトプットはチャレンジしてもらっても大丈夫そうか？という視点でも見ています。

雛鳥が親鳥からエサをもらう時のように口を開けて待っているだけでなく、一歩進んで、アクションを起こしてみてはいかがでしょうか？

Photo credit: coniferconifer via Visualhunt.com / CC BY

※この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。

「外部設計はこれでOKですね？ハンコ押してください。これで仕様凍結します。これ以降は仕様変更になります」なんて会話をお客様にして、良い気持ちで押してくれるお客様なんていないよ。

— yoh nakamura (@yohhatu) 2011年8月3日

これについてグダグダと考えてみました。
このつぶやきの元になっていたWFの開発プロセスでは「工程毎にキチッと終了し、その工程は簡単に後戻りしない」という前提です。

実際のPJではプログラミングやテストでの仕様追加や変更時は、それなりに発生します。
「WFでは後戻りしないんです！」と主張してもPJが進まないわけで、どうにか取り込もうとするわけですが、たいがいそれまでWFの各工程でキッチリやっていたプロセス(管理系もそうだし、設計や影響調査なども)がおざなりになることがあります。

その後のよくあるシーンとして…
・再見積や追加見積の数字が「なんでこんな簡単な機能追加なのに、こんなにお金/時間がかかるの！？」とお客様と乖離がありすぎる
・追加/修正した機能や関連する機能にバグが混入する(設計や影響調査、テストが十分でない)
…というのがあります。
これの要因の1つは(お客様のシステム開発の知識や経験も関係しるとは思いますが)自分達開発チームが仕様追加/変更を適切に行える状態になっていないことだと考えています。

1つは、開発インフラ環境の状態です。
開発インフラの三種の神器であるSCM/ITS/CIを使って、プロダクトコードが構成管理されていてベースラインが分かり、ITSで仕様やその経緯、リポジトリとの紐付けができて、CIで自動テストがグリーンになっている、そして失敗したらすぐに分かる…という状態なら、仕様追加/変更にも品質に影響を出さず、容易く対応できると思います。
特にCI(とテストコード)が無いと、大量の再テストを手動でしたり、バグの混入に気づくのが遅れ、大きな影響が出やすくなります。

もう1つはプロダクトそのものです。
プロダクトのコードは可読性/保守性が高く、DBなど含む設計もそれなりのレベルが必要です。
スパゲッティコードや拡張ポイントがぐちゃぐちゃな設計だと、仕様追加/変更のスピード、確実性が大きく落ちるので。

この2つが成り立たないと、工程途中の仕様追加/変更で(要求側が「なんでそんなになる？」と思う)コストや期日になったり、品質の劣化が発生します。
この話はお客様が使い始めた後の機能追加/修正でも同じです。

では、こういう条件を「使うアプリはパワポとExcelばかりで、プログラミングはパートナー企業やオフショアに丸投げしている」SE(や組織)がクリアできるか？というとNoなわけです。

「Noなら、どうしようか？」となって、冒頭の「仕様凍結」という言葉で、変更を抑止したり、お客様の費用感でなく、自分達の費用感でやれる材料にする動きになると思います。
当然、こんなことではお客様に価値を提供することは難しくなります。

ちなみにお客様の費用感を受け入れた場合、PJは赤字になり、品質は劣化し、デスマーチになって行くと思います。

(要求が変わることにより)仕様追加/変更が発生するんだ…と「変化を抱擁する」ことを前提に開発プロセスを考え直すのも1つの対応方法だと思います。
ただ、「変化を抱擁する」ことができる状態…開発インフラ環境の整備とプロダクトのコード・設計レベル…が実現できない組織では絵に描いた餅に過ぎません。

なので、そういうSEが多いSIerが、これから生き残るには…
1：自分達もモノ作りができるようになる
2：従来の開発プロセスで良いとするお客様だけをターゲットにしてやる
…かじゃないと思っています。

※注意：この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。

Photo on Visualhunt