開発プロジェクトの立ち上がりではなく、途中から参加することはどれくらいの頻度であるでしょうか？
また、それはどのあたりから参加することが多いでしょうか？

開発プロセスがウォーターフォールの場合、要件定義、基本設計の立ち上がりの時期に参加したプロジェクトと、より後の工程で参加したプロジェクトを比較した場合、自分なりに上手くいったのは前者が多かったように感じます。
後者のように、詳細設計や実装の途中工程から入った場合にいくつか困ったことがありました。

前工程での決まり事にどこまで首を突っ込んで良いか分からない

「あぁこの前工程で決めた内容だと問題があるかもしれないな。別の案も提案して一緒に考えた方が後々良いかもしれないな…」と思ったことがありました。
このような考えが浮かんで来た時に、前工程までの前提知識やそれまでの培ってきたお客様との関係をなかなか感じ取ることができず、提案した方が良いか悩んだことがありました。

特にお客様が遠方で同じ場所にいなかったり、自分自身がお客様との打合せに出ていないことで、お客様個人個人との関係性が築けていなかったり、性格などをわかっていなかったりするとなかなか効良いアクションができませんでした。
その結果、冒頭のような、もしかしたらプロジェクトの結果をより良くするアイデアや考えが浮かんでもそれを活かせないことがありました。

心理的に焦る

自分がそのプロジェクトに入るということは、何からの期待、果たしてほしいミッションがあります。

その期待を出すために、早くキャッチアップしようと過去の経緯や現状の作戦の背景などを知りたくても、プロジェクトのキーマンは多忙で聞けないこともありました。
キーマンはチームのリーダーやお客様です。

そうこうしているうちに時間が過ぎて、期待されたアウトプットは出ないし、追いつけない焦りも生まれてしまい、中途半端な情報の理解のまま仕事をして手戻りが出るという悪循環に入っていきました。

キーマンが多忙な程、プロジェクトのこれまでの経緯や情報がまとまっておらず、新しく入ったメンバーのパフォーマンスがあがらない、またキーマンに質問が集中することでキーマンがさらに多忙になっていくといった良くないパターンも見受けられます。

ではどうすればよいか？

自分や後から入って来る誰かが、これまで書いたことのように感じるのはチームビルディングの観点からもったいないですし、不安のためなかなか自分から考えてアクションをしにくくなります。
こうなると指示待ちになり、プロジェクトに対しての自分事感も低くなってしまいます。

これはプロジェクトの目的を成し遂げ、目標をたどり着く上で、損失となります。

こうならないために、ベタな方法ですがこまめなコミュニケーションを増やすことが大事だと思います。
多忙なキーマンだと、まとまった時間をなかなか取ることが難しいので、毎日30分でも良いので、毎日の朝会、頻繁なふりかえり、チームで行くランチMTGなどまずは細切れでもコミュニケーションの量を増やすようにします。
そういう細切れの時間の中で得た情報から、少しずつ不安を取り除き、また「わかっていないことがどこか？」をわかることでよりうまく情報を集めることができるようになります。
早めに不安を取り除くことは「こういうことも聞いて/提案して良いんだ」という信頼関係を作ることにもなります。

いずれにせよ、チームを新しく作る、後から加わったメンバーが期待するパフォーマンスが出るまでには、相応の時間的なコストがかかることを意識したプロジェクト運営が必要になってきます。

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

Photo via VisualHunt

先日、社内で「インセプチョンデッキ」のワークショップをやってみました。
社内SNSでの募集期間が1週間も無かったのですが、10人強の方が参加してくれました。参加者の皆様、ありがとうございました。

インセプションデッキとは？

詳しくは「アジャイルサムライ」や色々なブログで紹介されていますので、そちらを。

ワークショップの内容

定時後に約2時間で行いました。

インセプションデッキの説明を行った後、提示する架空のシステムについてグループワークを行いました。
グループは3つに別れ、「やならないことはなにか？」と「トレードオフスライダー」を話し合って、発表してもらいました。

休憩を挟んで個人ワークです。
それぞれの（今or過去の)プロジェクトのインセプションデッキを作ってもらうことにしました。
主に「パッケージデザイン」と「エレベータピッチ」を作って発表してもらいました。

これは社内ということもあり、包み隠さず良い感じの発表が続いたように思いました。
この辺は(部門は違えど)コンテキストが共有できている部分もある点かな？と感じました。

自分なりに考えたインセプションデッキの気づき

何度か作ってみたり、今回のワークショップにあたって思ったことです。
読み返してみるとこちらのエントリで書いたこととほぼ同じだったのですが…

ウォータフォール開発でも使える

「インセプションデッキ」は「アジャイル開発」の文脈で語られる/使われることが多いと思います。
しかし、アジャイルな開発以外でも、十分適用できるものだと思っています。
例えば、弊社でも「プロジェクト計画書」「プロジェクト憲章」を作りますが、それとインセプションデッキは(表現の仕方は違いますが)同じようなことを伝えてようとしていると感じるためです。

意外と(自分もチームも)分かっていない

実際に(自分の取り組んでいるPJについて)作ろうと、いくつかの質問に取りかかると「あれ？これってどうなんだろう？？」と思うことがあります。
特に途中参加したり、大きなPJだったりすると余計に顕著かもしれません。
チーム全員が同じような答えになるかと言うとそうでもなく、(エレベータピッチなどを書くと)少しずつ違った形になったりして、それぞれの想いが見えてきます。

10個もできないよ！！

インセプションデッキは10個の質問で構成されています。
「全て」をチーム「全員」でやろうとするとやはり時間がかかります。
そのような場合、2、3つを選んでやっても良いと思っています。
もちろん全てを関係者全員で出来るのが理想ですが。

今のところのオススメだと思うのは…
・エレベータピッチを作る
・何を諦めるのかはっきりさせる(トレードオフスライダー)
…辺りです。

またプロジェクトの途中では…
・やらないことリストを作る
・夜も眠れなくなる問題はなんだろう？
…あたりも良いと思います。

大事なのはインセプションデッキは1回作って終わりでは無いと思います。

継続的に、PJの状況が変化したら、インセプションデッキを確認して更新することで、より「PJの認識を合わせ、何を期待するか？」という点で効果があるように思います。
そのためにも(壁に張り出すなど、手段は色々ですが)「あぁ自分達はこのために、こんな方法で、このPJを進めているんだ」を意識するのが大事かと思います。

ロッカーの奥深くのキングファイルに入れてまま、とか、ファイルサーバの奥深いフォルダで、最終更新日がPJの開始日･･･なんてことのないようにしたいです。

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

Photo on Visualhunt

(時期を逃した感がありますが)、新しくできたグループなど、あまり知らない人同士が集まった宴会で使えるアクティビティです。

「Q&Aビンゴ」

ビンゴの数字を(「くじ」ではなく)「質問に該当する人」で決めていくものです。

お勧め参加人数

15人～50人位まで。

準備するもの

1：ビンゴ用紙
人数に合わせて3×3～5×5マスのビンゴ用紙。
市販されている「数字が印刷されている」ビンゴ用紙だとできないので、数字を自分で書き込めることができるタイプのやつがいいです。

2：ペン
3：(自己紹介を織り交ぜるなら)自己紹介テンプレ(使い方は後述)を書いておく大きめの画用紙

ビンゴのやり方

1：ビンゴに数字を書き込む
各自、0～参加人数の数字を(重複しないように)に埋めていきます。
例えば参加者が15人なら0～15までを書きます。
5×5なら真ん中はフリーの方が楽しめると思います。

2：ビンゴの数字を決めていく
任意に質問者を決めます。
質問者は「転職経験のある方！」「三度のメシよりプログラミングが好きって人！」「スマートフォンを3台以上持ってる人！」というような質問をします。
その質問に該当する人は手を挙げてもらい、手が上がった人数がビンゴの数字になります。

例えば、「社外勉強に行ったことがある人！」という質問に(15人の参加者のうち)9人が手を挙げたとします。すると「9」を書いたマスをチェックします。

これを繰り返していきます。
こうやってビンゴを作っていきます。

自己紹介のやり方

自己紹介をするなら、質問者は質問を言う前のタイミングが良いです。
ここではリズム良く行きたいので、用意しておいた自己紹介テンプレを使います。
以下は、新しい部門やグループのキックオフ宴会を例にしたものです。

—————
元気よく名前を！
これまでやってきたことは？
これからやりたいことは？
次の質問をどうぞ！
—————

この自己紹介テンプレを見えるようにしておけば割とリズムに乗って言いやすいと思います。

次の質問者の決め方

「質問したい人」と呼びかけて進行役が当ててもいいですし、質問者が次に指名しても良いです。

やってみて

(時間の関係もありますが)30人強の人数ならリズム良く、自己紹介+質問を繰り返した方が良いと思います。
人数が少ないなら、質問と質問の間に5分ほど間を設けて、質問に関すること…「へぇ～そうやったんやぁ」的なノリで…を話す時間を作れば、よりお互いを知るきっかけになると思います。

出た質問とその人数を画用紙に書いておけば、ビンゴが終わってからの会話のネタにもなると思います。

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

Photo by elizaIO on Visual Hunt / CC BY-SA

先日、チームのフリカエリをして、その時の(自分の)ネタに半年前から付けている「ニコニコカレンダー」を見てました。
「ニコニコカレンダー」の説明はこちらで。

私の今の使い方はデスクの卓上カレンダーにちょっとした一言と一緒に書いています。
ただ、ここ1ヶ月程は(チームで使っている)Redmineにニコニコカレンダーのプラグインを入れて、そちらも使っています。

で、その卓上カレンダーのニコニコカレンダーをそのまま公開しようとしましたが、仕事のメモ書きもあったので、集計結果だけ。

こうして並べてみると、毎月の様子がなんとなく分かります。
3ヶ月目、6ヶ月目が他の月に比べ、「良い」が少ない(特に3ヶ月目)のは、リリース前でバタバタしていたせいです。
6ヶ月目はその反省も踏まえ、多少改善されていますが。

半年付けていて思ったことの1つは、あまりロジカルな基準を設けない方が良いということです。

人間なので昨日と今日では同じ出来事があっても感じ方が違うこともあります。
ある日は「良い」でも、また1週間後に同じようなことがあってとしても「普通」を付けても良いと思います。
「なぜ今日、これを『良い』と感じたのか？」とその自分の感覚を深掘りできれば、何か見つかるかも？と思いました。

また「今日は開発が進んだ！良かった！」と思って「良い」と付けたとして、それが(例えば)1週間続いたとすると、その進捗のパフォーマンスや「良かった」という感覚が慣れて「当たり前」になって「普通」を付けていたこともありました。
これはある種、自分のレベル(基準)が上がっているを示しており、「では自分が『良い』と思えるのはどんな価値を出した時か？」という切り口で考えみると面白いかもしれません。
やり過ぎると疲弊したりするので、あくまで持続可能なペースでレベルを上げていくと良いと思います。

日々のタスクが忙しいとなかなか付ける余裕が無いと思いますが、帰り際の数分、もしくは朝の数分をニコニコカレンダー(を使ったフリカエリ)を続けると、数ヶ月には何か見えてくると思います。

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

先日、所属組織の忘年会でちょっとしたイベント？ゲーム？をしたので紹介します。
メンバーによりますが、2時間ダラダラ話したり、若手が(半ば押し付けられる形で)芸をしてお茶を濁すような宴会は、あまり好きではないので、こういう何かをやってみようと思うわけです。

「今年の漢字は？来年の漢字は？」

毎年、この時期に京都の清水寺で「今年の漢字」が発表されます。
※Wikipediaよる解説はこちら。
2010年は「暑」だったそうです。

それを真似て、それぞれにとっての「今年の漢字」を書いて発表してもらいました。
忘年会ですから、今年をふりかえるだけでも良いのですが、せっかくなので「来年はこんな感じの漢字にしたい！」と目標、決意表明的なものもやってみましょうということでやってみました。

準備するもの

B5～A4サイズの人数分の厚紙とペン。
厚紙は色紙などの方が雰囲気が出て良いです。

やり方

簡単です。厚紙を半分に区切ってそれぞれ一文字書いて、みんな順番に発表していくだけです。
書かずに発表するだけでも良いですが、厚紙に書いてジャン！と、それを掲げながら発表する方が演出効果があると思います。

やってみて

10人近くで、2文字ずつの計20文字書いたのですが、被った漢字は1つだけでした。
年齢やチームがだいぶ違うとは言え、それぞれ感じ方が違うなぁという感じで、発表を聞いてさらに「へぇ～そうだったんだぁ」と思うことも多々ありました。

ちなみに私は今年は「龍」で来年は「親」でした。

新年会でも使えるアクティビティですので試してみてはいかがでしょうか？

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

Photo by Prayitno / Thank you for (12 millions +) view on Visual hunt / CC BY

少し前、グループでフリカエリとこれからの活動について、半日時間を取って、しっかり議論しました。

夜は、(それまでの活動が一区切り付いたこともあって)打ち上げをしたのですが、そこでちょっとしたアクティビティをやったので紹介します。

元ネタ

書籍「アジャイルレトロスペクティブズ　強いチームを育てる「ふりかえり」の手引き」にあった【感謝(Appreciations)】と、社内SNSのエントリからいただきました。
※社内SNSでは「プラスのストローク」という名前で紹介していました。

「感謝の言葉を伝える」(プラスのストローク)

・アジャイルレトロスペクティブの１つ
・成長や良い点…プラスのストロークを周囲からもらうことができる。
・お互いの成長を確かめ合うことができる。(※今回はここまではできませんでした)

準備するもの

B5～A4サイズの人数分の厚紙とペン。
厚紙は色紙などでも良いです。

やり方

まずは準備です。
1：厚紙とペンを全員に配ります。
2：それぞれ厚紙が(自分のモノであると分かるよう)左上に自分の名前を書きます。
　リーダーは、自分の名前ではなく、「チーム」と書いても良いと思います。
3：最後に厚紙に、そこにいる「人数-1」人分の線を書いて区切ります。
　(例えば7人なら6等分にします。)
　他の方がコメントを書けるようにするということです。

これで準備完了です。
1：準備ができたら、右/左周りどちらでも良いので、全員同じ方向に厚紙を回します。
2：自分のところに回ってきた厚紙の左上に名前の人の…
「この１年で成長したと思うところ」
「素晴らしいと思うところ」
「感謝の気持ち」
　…を書いていきます。そのコメントには、書いた方の名前をつけておきます。
3：全員書き終わったら、また1に戻って厚紙を回して同じことをします。
4：これを繰り返し、1周回って自分の所に厚紙が戻ってきた時には、そこにはチームみんなからの言葉が書かれているというわけです。

やってみて

事前に「こういうアクティビティをしますよ～」と伝えた時には、(褒める/られることに慣れていないからか)少し気恥ずかしそうでした。が、実際にやると、(お酒も手伝ってか)積極的に一生懸命考えて、良い言葉を厚紙に綴っていたようです。

できあがった自分への言葉が書かれた厚紙をみんな嬉しそうに、見ていたのが印象的でした。
もちろん自分も嬉しかったのですが、(やる前のイメージより)「ここまで嬉しいものなんだ～」と強く思いました。

一歩発展して…

ちなみに前述の書籍や社内SNSのエントリでは、その先があります。
それは、みんなの厚紙を発表…「○○さんから、～という言葉を頂きました。ありがとうございます！」…するというものです。
こうすることで、良い所、感謝の言葉/気持ちがさらに広がっていきます。

ポイントは反省会ではなく「良いと思うところを褒める/伝える」というものです。

今回は年齢、キャリア的に中堅以上が多かったのですが、若手がいるチームですると(その若手にとって)大きな自信になるかもしれないと思います。
＃よくKPTを使ったフリカエリなどで、あるアクションやプロセスに対する「良かった」点などを挙げますが、こういう個人に対する「良かった」点のフィードバックというのも大事なものです。

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

※アイキャッチ画像：https://www.flickr.com/photos/stevendepolo/4582437563

システム開発プロジェクト…特にユーザテストなど終盤…で、ユーザから届くイヤな声の1つに「○○機能が想定と違います。Aという動きではなく、Bが(想定される)正しい動きです」というのがあります。
＃ここでは仕様書に「○○機能の動きはAである」と記述されている前提です。

こんな時に、やってはいけない行動の1つが(理由も聞かず、検討もせず)「仕様書には【○○機能の動きはAである】と書いてあり、お客様にも承認をもらっています。それをBにするには別途費用と期間がかかります」なんていうことです。

この時点で「戦いのゴング」…それもあまり勝ち目のない戦い…が鳴ることになります。

こういう仕様追加/変更はもちろんのこと技術的な課題や問題など、システム開発では様々なものが発生します。
そして、それはどれほど予想して対策を考えても完全には防ぐことはできません。
＃もちろん予想と対策が不要と言いたいわけではありません。

この原因には、様々な要因…ユーザのレビュー、想定不足もありますし、自分達SIerのドキュメントや会話の伝達能力の低さ、読みの甘さ等…があります。

原因(とその真因)を突き止めることは意味がありますが、ややすると、【お客様(ユーザ) VS 私達(SIer)】の対決構図になり、問題そのものの解決より「要はお前らが悪かったんやろ！」的に責任(非)は相手にあると認めさせることにパワーを使うパターンに陥ります。

これに対して【問題　VS　私達(SIer+ユーザ連合軍)】のように、一種の同盟関係を作ると状況は良い方向に進むものです。

この同盟関係がプロジェクト序盤～終盤まで機能していると、問題に対しても「じゃあ、これどうする？(SIerやお客様それぞれの立場で)自分達のできることって何だろう？」という感じで、プロジェクトをドライブできます。

そのために、(しょうもない心がけですが)常に「【問題　VS　私達(SIer+ユーザ連合軍)】なんですよ」と言い続け、意識してもらいます。
具体的な例では、お客様と話す言葉遣い1つにしても普段から「【私達】のプロジェクトでは…」とMeではなく、Weを使います。

打合せ等では(議題にもよりますが)、対面に座る(対決的なポジションです)のではなく、(問題や課題が見える)ホワイトボードやプロジェクターに並んで座るようにします。

SEはロジカルに仕事を進めることが多い(仕様検討などはロジカルでないと破綻しますので)です。
が、こういう「泥臭い」部分も同じかそれ以上に大事だったりします。

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

Photo via Visual hunt

最近、お客様への納品が終わったプロジェクトで採用した「プチフリカエリ」について書きます。

(私の所属企業、かつ、知っている範囲では)「フリカエリ」は(大規模プロジェクトでは)工程の終了時、(小規模プロジェクトだと)プロジェクト終了時に行うことが大半です。

それ自体は有用なのですが、時間が空くと「フリカエリ」の効果も薄くなるので、私は「プチフリカエリ」と(勝手に)名付け、毎週金曜日の朝会の一部で行っていました。

普段の朝会では「昨日やったこと」「今日やること」「(あれば)問題点」を簡潔に述べ、あまり所感などは言うことはあまりありませんが、「プチフリカエリ」では「今週のタスクから学んだこと(と、簡単な感想)」を簡単に発表します。

「プチフリカエリ」をした理由として…。

1：メンバーの構成

このプロジェクトは私を含めて4人で、(技術的に優秀ですが)もう少しアンテナを広げて欲しいと(個人的に思う)若手メンバー、新人、そして、パートナーさんという構成でした。
このパートナーさんは仕事や技術に対する姿勢から学ぶべきところが多く、そこから吸収して欲しいと期待したためです。

2：プロジェクトの特性

もう1つは(期間としては短かったですが)、要件定義を除く、外部設計からシステムテスト、そして納品までシステム開発のほぼ全工程のプロジェクトでしたので、各工程で気付くがあるだろうと(特に新人には)。

結果として、ほぼ毎週行い続けたこともあってか、各工程でそれぞれ何らかの気づきや学びがあったようです。
＃私自身も今回のプロジェクトでは学ぶことが多くありました。それはまた別エントリに書くとして。

ストレッチ的な目標として「学んだこと」から、深掘りした考察や横展開をする等して、各自の基礎能力(仕事力みたいなもの？)の底上げができれば…と期待はしていました。
本音を言うと、そこまでは至らなかったのが少し残念です。

とは言うものの、この習慣が根付いて、次やまたその次のプロジェクトは各自が一段上のレベルで仕事をしてくれれば良いなぁと思っているわけです。

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

Photo credit: -will wilson- via Visualhunt.com / CC BY-NC-ND