朝(というか3時半)に散歩しながら思ったことを雑に書く
Agileの考え方の特徴の1つに「あらゆるものは変わり続ける」というのがあると感じる。「”変わらないものはない”ということだけは変わらない」みたいな(もちろんその”変わる”頻度、度合い、間隔は様々)。
んで、人は本能的に、変わりたくない生き物っぽく、不安定を嫌い、安定していたい。
それに対して「あらゆるものは変わり続ける」ということを前提に置くのがAgileの特徴の1つ。
それって、大げさに言うと「人の本能に抗おう」としているようにも思える(そんな要素はないけど、そんな構図になってそう)。
だからこそ、もう1つの人の本能的なものである”楽しさ”や”自分事”みたいな個人のモチベーションに関係ある要素もAgileの特徴にあるんじゃないかなと思う。
不安(不快なレベルな時もあるだろう)に感じることが多い”変わり続ける”ことに向き合っていく時に、楽しく感じられないと続けられないことが多いんじゃないかなと。
もしかしたら自分自身も「楽しい」と思い込むことで、この変わり続けることに向き合えているのかもしれないなぁと感じた。
ふと週末に近所を散歩していたら、クラブ活動中の母校(中学校)の学生を見かけて思い出したことです。
これまで自分が出会ったリーダーで、強く印象に残っている一人が中学校時代の先輩でした。
＃中学時代のことなので美化されているとは思いますが…
この2つ上の女性の先輩(以下、Fさん)は、知り合った当時、生徒会の会長をやっていました。
このFさんの代の生徒会がやろうとしていたことに校則の改正がありました。
今、思えば自由で緩やかな校風で校則もそれほどとは思わなかったですが、当時の自分達には「こっちの方がいいな」とか「これは今に合っていないかも」と感じるものがあり、それを変えるための「校則の改正」でした。
(自分は色々あって他の生徒達より)これらの活動を間近で見聞きすることができました。
Fさんの進め方は、(この年代にありがちな)ガキ大将的な「とにかく自分についてこい！」的なリーダーシップではありませんでした。
「自分達はどこに向かおうとしているのか？そうなったらどんな風になるのか？」といったビジョンを示す、伝えることをすごく大事にしているようでした。
「今はこういう所にいて、こんなことになっているんですよ。で、それをこういう風にしてみようと思うんです。もし、そんな風になったら(あなたは)どう思います？どう感じます？」といった感じで、ちゃんとそれぞれが考えることができる…少なくとも感想を持つ…ようなメッセージを出すようにふるまっていました。
しかもそれを教師、生徒、保護者それぞれの関心事や心配事に合わせるような形でどこを強調するか使い分けていました。
この年代は「どうしてダメなんだ！」「頭の固い先生や親はこれだから！」と何かと正論を正面からぶつけ、お互いにとって良い結果にならないことが多いと思うのですが、Fさんの進め方ではそういう衝突が起こりませんでした。
もちろん教師、保護者のキーマンに根回しをしていたかもしれませんが、このような進め方もあってか驚くほどスムーズにことが運んでいました。
(今でもまだまだできていませんが)20代の頃はFさんとは真反対のふるまいをしていました。
所属組織やクライアントの課題に対して、自分の視点からのみの正論を相手に投げていくスタイルでした。
中には受け入れてもらったものもありましたが、無用な衝突なども多かったように思います。
Fさんの進め方や考え方を深く理解して取り入れることができていれば変わったかもなぁ…と思いを馳せていました。
先日のDevLOVE関西「勉強会勉強会」のビアバッシュでの話です。
20人位の組織にいる人で「どうやって社内勉強会を始めて良いか分からない」という課題を持っていました。さらに聞いてみると以下の2つのことを強く気にしているようでした。
1：人が集まらなかったらどうしよう？
2：講師出来るほど教えることもないので、どうしよう？
「(自分以外に)もう1人いたらやってみる」
「勉強会勉強会」でもお話しましたが、自分以外にもう1人いれば、それは「勉強会」だと思っています。
2人以上いれば勉強会と呼べば良くて、呼び名や定義は些末なことかと。
2人でそのテーマについてお互いの知見や考えを話し合い、共有することで、それぞれが持っていた暗黙知が、2人にとっての形式知となりお互い勉強になります。
仮に新しい知識そのものに出会わなくても、自分とは異なる考え方を知るというのはそれだけで十分な価値があります。
特に小さな組織の場合、2，3人でも何かやっていたりすると「なにやっているんだろう？」と目に止まったりします。そういう興味を持っていそうな人も、勉強会をやっている人から見つけやすくなり、「一緒にどうですか？」と巻き込みやすくなります。
その相談してきた人は、アイデアとしてお茶の時間に休憩スペースにお菓子を用意して、そこでまずは始めということで軽くに30分程度でやってみようと話をしていました。
「みんなで考えて、教え合えば良い」
誰か1人が参加者の中で一番そのテーマについて知っている講師である必要はどこにもないと思います。
もちろんテーマによっては、有識者がいる方が進めやすいというのもありますが、それこそみんなが持っている知識を持ち寄ることで解決できることもあります。
またそういう解決できない問題が実際に出てから、それを解決できる有識者を見つけに行っても良いと思います。
その相談してきた人は「【勉強】会」という名前からか、ロールとして「講師」「生徒」なイメージを持っている感じでした。
「自分はこう思うけど、みんなの考えはどう？」「ここのコードがわからなかったから、一緒に読み解いてみない？」と一緒に考えれば良いと思いました。
エンジニアの現場で出会う課題は、ほとんどが唯一の正解があるわけではなく、むしろそのコンテキストに応じた「より正しいと思われる選択を見つけに行く」必要があります。
なので、自分ともう1人が興味あることを見つけて、軽くやってみるのがまずは第一歩だと思ったわけです。
※注意：この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。
Photo via Lindsay Henwood via VisualHunt.com
DevLOVE Advent Calendar 2012 “Professional”に投稿しました。
私が考えているProfessionalの定義は以下の3つをやっている、もしくは、やろうとしている人です。
それは「Whyを考え続ける」「厳しいことを言える」「ベストを尽くす」です。
続きはDevLOVE Advent Calendar 2012 “Professional”のエントリでお読みください。
私以外にも多くの方が「自分にとってのProfessional」というテーマで書いています(し、これからも書いてくれるでしょう)。
何が正解･･･というのはありませんが、それぞれの考え方にふれることで何か新しい発見があるかもしれません。
※注意：この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。
Photo via Visual Hunt
先日「AgileTourOsaka2012 in Minoh」に参加してきました。
箕面という珍しい土地も楽しめましたし、スピーカー3人ともあまり関西ではお話されない方なので、お話が聴けて良かったです。
最初に質問や興味があることを付箋に書いて、それも絡めながら進めていくスタイルはオーガナイザーのtetsu_mさんだからこそと思いました。
＃お話していただいたスピーカー、スタッフ皆さん、楽しい時間をありがとうございました！
一番、印象に残ったのは藤原大(@daipresents)さんの話でした。
＃@daipresentsさんのエントリはこちら→解説！地図を捨ててコンパスを頼りに未来へ進め！ Agile Tour Osaka 2012資料公開
そんな「AgileTourOsaka2012 in Minoh」のテーマは【チェンジ】でした。
その【チェンジ】について思ったことです。
「いつか変わらないといけないと思うんですよ。でも～」
こういう会話を耳にする度に…
「いつかやる」っていう、その「いつか」はいつまでも来ないんだよ
— yoh nakamuraさん (@yohhatu) 2012年11月5日
…と思います。
「何かを変える/変わる」ことを”チェンジ”とした場合、自分がチェンジしようとする際に気をつけているコツみたいなものを書いてみます。
意外と始める前の手順が煩雑だったり、用意する物が多かったりする方法を選んでいることも見聞きします。
だいたい、揃えるまでに力尽きるか、揃えた時点で満足してしまったりするので、まずはすぐに始めることができる方法を選びます。
どうしても準備に時間をかけないといけないのであれば、準備をすること自体を「最初のゴール(あくまでマイルストーン)」に置くことも1つの選択です。
チャレンジの内容によりますが、「これは(自分には)向いていないかも」「この方法では難しいかも」と思ったらサッと止めて、方向転換できることもコツの1つです。
ただ、サッと止めることができるとは言え、判断は急がないこともあります。
AgileTourOsaka2012の中で藤原さんも言っていた気がしますが、自分もある程度の期間は様子を見ることもあります。チェンジにはそれ相応の時間がかかり「最初は違和感があっても、ある時期を越えるとプラスに変わる」というパターンもあります。
もう1つ気をつけることは、自分だけでなく周囲も一緒にやっているチェンジの場合、理由と共に「止める宣言」をすることです。
この止める宣言がないと、気まぐれな印象に見えますし、再びなにか行う時に「前も勝手に止めて…」と不要な抵抗を受けることもあります。
「2：簡単に止めることができること」の真逆ですが、これが有効な場合もあります
それなりに準備に手間暇かかっていたりすると「ここで止めるとこれまでの分がムダになる」と心理的なブレーキがかかって(ベストな状態では無いにしても)続けたりできます。
そして続けているうちに目的のチェンジができることもあります。
＃ただ、意固地になって止め時を見誤るというリスクもありますが･･･
似たような話で「チェンジしたいことを周りに宣言する」というのもあります。
私は、宣言だけでなく、自分や周囲の人が見える場所にチェンジしたい内容を貼り出していたりしました。
チェンジに向かって動き始めた時は不安がけっこうあります。
なので、大きくなくてもかまわないので本当にちょっとした、自分達が成し遂げた成果とその成功体験が大事です。
不思議なことにそういう成功体験を得ることで、その後、何度か失敗しても「成功体験」があるため「今回はうまくいかなかったけど次は…」となり、続けやすい状態になります。
もちろん同じ失敗をしないようにふりかえりなどの対策は必要です。
周囲に同じようにチェンジをしたい人がいれば、その人と一緒にやってみるのも1つのコツです。
もし社内にいなくても、外を見渡せばそういう人々がゴロゴロいますし、出会う機会もゴロゴロあります。
「変わらない」という選択肢もありますが、せっかく「変わりたいなぁ」と思っているなら、【チェンジ】の一歩を踏み出してみてはいかがでしょう？
※注意：この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。
Photo credit: nattu via Visualhunt.com / CC BY
ずいぶん前に書いたまま放置していたのを(ちょっと書き足して)アップします。
組織において「えらくなっていきたいか？」という話です。
一時期「昇格/昇級したいか？」という問いにNoと答えていました。
なぜなら「上の人が楽しそうに、やりがいを持って仕事をしているように思えなかった」からです。
自分がやりたい仕事でないのか、責任やプレッシャーの割に(評価された結果の)給料が低いのか分かりません。
が、目を輝かせて「今の自分の仕事が楽しい/やりがいがある！」と伝える(伝えなくても態度で示す)人が少なかったように思います。
恵まれたことに(一番お世話になった)直属のボスは上記に当てはまらない人でした。
(現場や若手から見て)管理職や上司が魅力的に見えない組織は、新しい力も出てこなく、新陳代謝も起きず、 新しい変化にも対応できず、結果として若く有望な方は出て行ってしまうし･･･で、良いことは何もありません。
最近(※2011年の冬頃)は少し変わってきていて「その組織で自分がしたいことをやりやすく、横槍を入れられずにやる(＝自分でハンドルを握る)には、えらくなって上に行くのが一番の近道」と思うようになっていました。
この話の前提には「その組織で頑張るなら」がありますが。
えらくなることを目的としてとらえると(魅力が無いように映っているので)イマイチ前向きになれませんが、「自分がやりたいことするため」の手段として見ると、そう悪い話では無いと感じたからです。
それからしばらくして、ハンドルを握るまでの時間の長さに待ちきれずに移る※ことになったのですが。
※[仕事]会社を移ることになりました
※注意：この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。
Photo on Visual Hunt
今のチームで仕事をやり始めて2ヶ月半が過ぎました。
その2ヶ月半で、業務の引継ぎや情報の伝達について、ふと思ったことがあったのでつらつらと書いてみます。
中途入社でしたので、チームが携わっていた業務、またその業務に関するプロダクトへの知識は低い状態でした。
チーム自体はあまりメンバーは出入りせず、しばらくの間、この業務、プロダクトに関わっている状態でした。
職位としては上長にあたる立場で、期待されている役割としては引っ張っていくことが存在していましいた。
この2つの自分の状況が良いように影響し、うまく情報の伝達ができました。さらに改善できそうなプロセスやよりうまくやるためのボトルネックまで見つけることができました。
私に情報や状況を伝えてくれる当初からいるメンバーの視座で見てみます。
日常的に忙しいと、後から入ってきたメンバー(今回の場合だと私)に業務や決まり事などを説明する時間が十分確保できないことがあります。
十分確保できないと「ここにあるから後は見ておいて」と、伝達を端折ってしまい、相手の理解度が不十分なまま日常の業務を進めることになります。
不十分なまま業務を進めると、アウトプットの質が十分でなく手戻りが起きることも多くあります。
今回の状況では、伝える相手は職位が上ということもあり「この人、わかっていないなぁ」と思いながらも丁寧に伝えようとしてくれました。
#もちろん「上長だから」丁寧に伝えてもらえるというわけではなく、聞き手の態度や姿勢なども関係しているとは思います。
この時間をとって、より丁寧に伝えようとすると、伝える側もあまり意識していなかった暗黙知が表出化してくることもあります。
この表出化の過程で、これまでなんとなく続けてやっていたけど、面倒、複雑なやり方であることに気づくこともあります。面倒や複雑なプロセスはムダやムリがあることも多くあり、改善するポイントでもあります。
「伝える」という行為を通じてこのような改善するポイントが見えることもメリットの1つだと感じました。
本来であれば相手が誰であれ、そのような暗黙知やムダなプロセスが明確になれば嬉しいのですが、なかなかうまくいかない経験をした方も多いと思います。
伝えてくれる相手が職位的に上の場合だと、説明されている内容に違和感を覚えてもなかなかしつこく質問して聞けないこともあります。
またその業務やプロダクトに対する聴く側の経験が浅かったりすると、そもそもそのような質問を思い至らないかもしれません。
今回の場合、私が業務、プロダクトそのものの経験は少なくても、エンジニアとしての経験はそれなりにあったので、その経験と照らし合わせた上で伝えられた内容に対して質問や疑問を持って話をすることができました。
結果として、聴く側の動きによっても、先に書いたように暗黙知やムダなプロセスが明確になりました。
聴く側としては「聞くのが恥ずかしい」「こんなこと聞いたらバカにされるのでは？」といった自分をよく見せようとする気持ちが強くあると、知ったかぶりな態度を取ったり、表面的なことのみでわかった気になったりして、うまく情報を伝達できないということもあります。
※注意：この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。
Photo credit: davis.steve32 via Visualhunt.com / CC BY
開発プロジェクトの立ち上がりではなく、途中から参加することはどれくらいの頻度であるでしょうか？
また、それはどのあたりから参加することが多いでしょうか？
開発プロセスがウォーターフォールの場合、要件定義、基本設計の立ち上がりの時期に参加したプロジェクトと、より後の工程で参加したプロジェクトを比較した場合、自分なりに上手くいったのは前者が多かったように感じます。
後者のように、詳細設計や実装の途中工程から入った場合にいくつか困ったことがありました。
「あぁこの前工程で決めた内容だと問題があるかもしれないな。別の案も提案して一緒に考えた方が後々良いかもしれないな…」と思ったことがありました。
このような考えが浮かんで来た時に、前工程までの前提知識やそれまでの培ってきたお客様との関係をなかなか感じ取ることができず、提案した方が良いか悩んだことがありました。
特にお客様が遠方で同じ場所にいなかったり、自分自身がお客様との打合せに出ていないことで、お客様個人個人との関係性が築けていなかったり、性格などをわかっていなかったりするとなかなか効良いアクションができませんでした。
その結果、冒頭のような、もしかしたらプロジェクトの結果をより良くするアイデアや考えが浮かんでもそれを活かせないことがありました。
自分がそのプロジェクトに入るということは、何からの期待、果たしてほしいミッションがあります。
その期待を出すために、早くキャッチアップしようと過去の経緯や現状の作戦の背景などを知りたくても、プロジェクトのキーマンは多忙で聞けないこともありました。
キーマンはチームのリーダーやお客様です。
そうこうしているうちに時間が過ぎて、期待されたアウトプットは出ないし、追いつけない焦りも生まれてしまい、中途半端な情報の理解のまま仕事をして手戻りが出るという悪循環に入っていきました。
キーマンが多忙な程、プロジェクトのこれまでの経緯や情報がまとまっておらず、新しく入ったメンバーのパフォーマンスがあがらない、またキーマンに質問が集中することでキーマンがさらに多忙になっていくといった良くないパターンも見受けられます。
自分や後から入って来る誰かが、これまで書いたことのように感じるのはチームビルディングの観点からもったいないですし、不安のためなかなか自分から考えてアクションをしにくくなります。
こうなると指示待ちになり、プロジェクトに対しての自分事感も低くなってしまいます。
これはプロジェクトの目的を成し遂げ、目標をたどり着く上で、損失となります。
こうならないために、ベタな方法ですがこまめなコミュニケーションを増やすことが大事だと思います。
多忙なキーマンだと、まとまった時間をなかなか取ることが難しいので、毎日30分でも良いので、毎日の朝会、頻繁なふりかえり、チームで行くランチMTGなどまずは細切れでもコミュニケーションの量を増やすようにします。
そういう細切れの時間の中で得た情報から、少しずつ不安を取り除き、また「わかっていないことがどこか？」をわかることでよりうまく情報を集めることができるようになります。
早めに不安を取り除くことは「こういうことも聞いて/提案して良いんだ」という信頼関係を作ることにもなります。
いずれにせよ、チームを新しく作る、後から加わったメンバーが期待するパフォーマンスが出るまでには、相応の時間的なコストがかかることを意識したプロジェクト運営が必要になってきます。
※注意：この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。
Photo via VisualHunt
主に月末/月初に「退職します(した)」エントリ、「入社します(した)」エントリやつぶやきがちょくちょく見受けられます。
弊社からも新天地へ行った方もたくさんいて、中には「おぉ、あの人もいなくなるのか…寂しいなぁ」という方もいます。
ただ、たいがいそういう人とはTwitterやFacebookなどでつながっていたり、ブログを読んでいるので「元気にやっているなぁ」と分かります。
そしてそれを励みに「自分も…」と思ったりします。
ふと「同じ会社に所属していても、部署が変われば、日常的に言葉を交わすことは少なくなることがある。それって会社を移るのとそれほど変わらないのでは？」と思ったりしました。
部署の異動以外でも、「自社での開発」から「お客様常駐(そのまま数ヶ月帰ってこない)」のパターンだと(同じ部署でも)言葉を交わすことは少なくなります。
ただ、食堂で見かけたり、エレベータで乗り合わせたりしたら「久しぶり。最近どうよ？」てな感じで言葉を交わします。
で、それは冒頭に書いたように(会社を移った人が)TwitterやFacebookで興味深い事をつぶやいていたり、書いているのを見かけたら「久しぶり。最近どうよ？」と声をかけるのと感覚的には一緒だったりします。
部署異動したり、プロジェクトを移ると、(会社的に共通な)お作法以外に、ローカルルールや独自のやり方があり、けっこう覚えることもそれなりにあります。
時にはそれまでのお作法が「間違い」と言われることもあったり(苦笑)
また「知った顔」という意味でも、(プロジェクトによっては)ほとんど初対面ということもあり、結局(あまり価値の高くない)「まずはお互い知る」というチームビルディングにパワーが必要な状況も多くあります。
組織としての成熟が足りないとも言えますが、そこそこ普通な光景だと思ったりします。
「会社を移るとそれまでの人脈が…」という方もいますが、お互いが必要と思っていれば会社を移っても情報交換やディスカッションは続けます。
むしろ、違うフィールドで新しい情報や視点を持ってディスカッションできるようになるので、刺激になります。
「会社」という共通項以外でやり取りできないのであれば、あまり太い関係でもないと思いますし。
こういう感覚は、どの程度「会社」「部署」などの組織を拠り所としているか…によりますが、自分の場合はこんな感じだなぁと思ったわけです。
※注意：この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。
Photo on Visualhunt.com
ここ1年ほどいくつかの勉強会に参加して、時にはスタッフだったり、スピーカーをさせてもらったりした中で「仕事と勉強会の源泉の関係」について感じたことです。
「今日の勉強会でエネルギーをもらったので、明日からまた現場で頑張れます！」という声を時々聞きます。
(スタッフだったりすると)そういう声は嬉しいのですが、一方で【うまく行っていないのに変化しようとしない現場やデスマの現場でエネルギーが切れる(心が折れる)】→【勉強会でエネルギーを補給】→【また日々のしんどい現場で…】→【エネルギー切れたら勉強会へ】という(改善ではない)ループにハマっている感じがする時もあります。
「(しんどい)仕事をやり切るために勉強会へ参加する」みたいな。
もちろんこういう方は少ないよ！ってのであれば嬉しいことですが…。
一方、自分はどうだろうか？と考えてみました。「勉強会で話したいために仕事で(改善も含めて)楽しんでガンバル」が自分のスタイルかなぁと。
自分にとって(会社での)仕事で改善を意識し続けてやっている源泉の1つに「(自分が経験して学んだ)アウトプットを話したい」というのがあります。
もっと言うと、それを伝えた人からの(良い悪い関係なく)フィードバックを得て、もっと良いモノにしていきたいです(そして、それを共有したい)。
さらにさらに言うと、自分と同じようなことに(不必要に)悩まず、はまらず、本来やりたいことにリソースを集中して、より良い仕事ができるようになれば…と思っています。
そのためには、(当たり前ですが)上っ面をなぞるようなことでなく、自分が腹落ちしていることを言いたいわけです。
腹落ちしていなくて、自分が悩んでいてもっと意見を聞きたい場合は、正直に伝えるようにしています。
(自分で腹落ちするために)漠然とするのでなく、工夫や改善を意識して、「何か伝えるエッセンスがないか？」ということも意識しながらやっているわけです(いつもってわけではないですが)。
勉強会やセミナーなどでよく話されるスピーカーの皆さんの(話す)源泉ってどんなんだろうって気になります。
※注意：この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。
Photo on Visual Hunt
同僚がチームが直面した課題、その課題へ工夫したことを事例紹介として、勉強会で発表することになりました。
この同僚は社外の勉強会では初めて発表するというこもあってか「ほとんどの聴き手が『そんなん知ってるわ！』と思ったらどうしよう…」と不安がっていました。
この話を聞いた自分なりの考えを書いています。
＃この同僚には伝えたことでもあります。
100人の参加者がいたとして、全員が満足するような話は難しいです。ただその100人のうちひとりが「新しい知識、考えを知ることができた。今日は来て良かった」と思ってもらえれば、それで話し手としては十分です
発表に慣れないうちは、聴き手のことをあまり深く考え過ぎず、まずは「発表してみよう」という姿勢、そして実際に発表するアクションが大切なことだと考えています。
貴重な時間やお金を使って勉強会にやって来ている「聴き手のことを考える必要がない」というわけではありません。ただ、それを考えすぎる余り「発表する」ことそのものを躊躇するのはもったいないことです。
発表したことが、理解を少し誤解していた、もっとベストな方法があった場合、聴き手にいる有識者からアドバイスをもらうこともできます。また同じような境遇の人と話しあうこともできます。こんな風にフィードバックをもらうこともできます
技術的な検証、自分の考えや話に矛盾がないかはある程度事前に確認は必要ですが「話す内容が完璧な正解でないといけない」「ベストな方法でないといけない」わけでもありません。
そして、発表することで得られたフィードバックを、その勉強会で参加者にも共有したり、後日にブログなどで発信できれば十分です。
この同僚の発表は、勉強会、その後の懇親会でも多くの聴き手の興味をとてもひいたようで、いろいろな良いフィードバックを受けていた様子でした。
※この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。
Photo credit: tobiastoft via VisualHunt / CC BY
お客様や同僚から言われる「この仕様をドキュメントにまとめてもらえますか？急いでいないので、”ゆっくり”で良いですよ」という言葉。
よくある会話ですが、この「ゆっくり」の捉え方によっては、ちょっと痛い目を見るかも知れません。
「ゆっくり」が具体的な時間、日にちでどれくらいなのかはその人、背景や依頼内容といった状況によって違ってきます。
その中で、依頼を受けた側は「ゆっくり」を”4日間”と思い込み、依頼を出した側は”今日中じゃなくても良いけど、明日くらい(2日間)”と考えていたとします。
この場合、2日後に依頼者は「ゆっくりとは言ったものの、ちょっと遅いなぁ」と気になり始めます。ゆっくりと依頼したため、「まだですか？」と催促しづらく、ひとりイライラすることもあるでしょう。
一方、依頼された側は、3日後に依頼を終えて返事をしたとします。その時、少しイライラして不満顔の依頼者を見て「あれ？ゆっくりで良かったんだよね？」とモヤモヤとした気分になります。
＃また逆に、「あれ、そんなに早くなくて良かったのに…」と言われ、別の意味でモヤモヤすることもあるでしょう。
人や状況によって違う「ゆっくり」という相対的な物差しを、「○日の△時」という絶対的な物差しにすれば良いだけです。
文字にすると単純なことですが、話の流れ、場の雰囲気によっては、何となく流してしまったり、聞くことができず、そのままになりがちです。それを放置していると、冒頭のようなすれ違いが起きてしまいます。
絶対的な物差しにする際、「いつまでですか！？」と反射的に尋ねるのではなく「○日までに返事しますが、問題無いですか？」と自分なりの見解を伝える工夫をします。
こうすると依頼した相手も「ちゃんと考えてくれている」と信頼し、安心することができます。
ちょっとした(心遣いまではいかない)工夫で、少しでも円滑に回れば嬉しいものです。
※この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。
Photo credit: malias via Visual hunt / CC BY
あるエンジニアと話した時に「雛鳥が親鳥からエサをもらうように口を開けて待っているだけでなく、一歩進んで、アクションを起こしてみてはどうか？」と思うことがあります。
「これからどんな仕事に携わったみたい？どういうことをやってみたい？」と質問を投げた時の反応は様々です。
「平穏にサラリーマンできればいいです」という声もあれば、「プロジェクトマネージャーになって大きなプロジェクトを回してみたい」「アーキテクトになって技術でリードしたい」「もっとお客様に提案したい」「今はJavaだけど、これからはRubyでプログラミングしたい」など、様々なやりたいこと、ありたい姿、キャリアプランなどその人の想いが出てきます。
このようなやりたいことは、何もせず待っているだけで実現することは稀なことであり、実現するためには「私はこれをしたい！」と周囲に知らせる、発信する必要があります。定期的にあるフォーマルな評価面談から、呑み会やちょっとした日常会話でのインフォーマルな場まで色々機会があります。
＃自分の経験で、ポロッと社内SNSで呟いたことが、関係者の目に止まってやりたかったことができるようになった話もあります。
このような発信を受け取った上司は「自分からやろうとしていることをなんとか実現してあげたい」という心境になるのが大半かと思います。
そこで「それをやるために、今まで何をしてきた？」「Rubyがしたい？ならサンプルで書いてみてどうだった？」「プロジェクトマネージャーになりたい？今一緒にやっているプロジェクトマネージャーから何を学んだ？」と”やりたいことに近づくアクション”の話になると、本人は途端にトーンダウンしまうことがあります。
「そこまではやる時間がなくて(ゴニョゴニョ)」「実際に使うプロジェクトに入るのが決まってから勉強しようかと(ゴニョゴニョ)」といった様子です。
今の自分が「できること」と「実際にしたいこと」にはギャップがあります。そのギャップを埋めるのは自分です。誰かが埋めやすくなるように手伝ってくれることはありますが、最後は自分で行動して埋めるしかありません。
こういう発信を受け取った上司はこのようなアクションをしているか？そのアクションのアウトプットはチャレンジしてもらっても大丈夫そうか？という視点でも見ています。
雛鳥が親鳥からエサをもらう時のように口を開けて待っているだけでなく、一歩進んで、アクションを起こしてみてはいかがでしょうか？
Photo credit: coniferconifer via Visualhunt.com / CC BY
※この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。
@kuranukiさんの「モチベーションの源泉：何のために働くのか、転職か起業か」(「Social Change!」より)を読んで…
「サポータータイプ」：7「クラフトマンタイプ」：3かな、私は。RT: モチベーションの源泉：何のために働くのか、転職か起業か http://t.co/peVEqyo via @kuranuki
— yoh nakamura (@yohhatu) 2011年7月8日
と言いました。
で、もう少し考えてみました。
その昔…前の前の会社にいた頃…「アントレプレナー」タイプの側面は(10のうち)1くらいはありました。
「開発者がもっと楽しく、自分の腕を活かして仕事ができる組織・環境を作る」という想いでした。
若かったもので、想いだけはたくさんありました。
今でも「開発者にとって…」の想いは持っていますが、それを自分が実現するという気持ちではないかなぁと感じています。
「アントレプレナー」タイプの夢を実現するために磨いていたスキルがスライドして「クラフトマン」タイプの源泉になっている感じです。それが、ファシリテーション、チームビルディング、Agile開発だったり…。これらのことに携われるからモチベーション高く維持できるのは確かです。
なので、やっぱり3～4くらいです。
@kuranukiさんのエントリの文脈では「技術的スキル」(RailsのプログラミングスキルやOSSへの貢献だったり)にフォーカスしているように思えます。それならば、私の「クラフトマン」タイプの割合は0～1になります。技術的なことは好きですが、『自らの腕を磨いて「俺ってすげー」感を味わうことが幸せです』まではいけないなぁと。
よくよく考えると2つの意味で持ち得る(こともある)と思いました。
1つは「評価が金でしか分からない」場にいる場合です。この時は1～3程度になります。
「あなた達の仕事っぷりに感謝したい」という声が届きにくい環境にいると、評価される側は金でしか評価が分かりません。
もう1つはダークサイドに落ちそうになっている場合です。
凹むような出来事…たいがいは、(組織など)何かに対する失望がその原因…があった場合に、モチベーション、情熱が一時的に冷え込み、「もらっている金額分、働きます(だけどそれ以上は自分のためだけに使う)」な気持ちになる場合です。
こういう時も1～3程度になります。
「誰と（誰に）仕事をするか」は大きな割合…4～6くらい…で、あります。
自分のパフォーマンスを振り返ると、(自分基準で)「良い」と思えるお客様/上司/ボス/リーダーの時ほど、そのパフォーマンスが良かったように思います。
「このお客様の問題を解決したい(で、笑顔になって欲しい)」「このボスの目標を実現して欲しい(のために、手伝いたい)」が源泉になっています。
ありがたいことに、今のチームでも「この方達のために…」という想いが強くあります。
その状況でなくなれば、「別の誰かのために…」という想いで動くこともあるかもしれません。
・アントレプレナー：0
・クラフトマン：(Javaなどの技術だけでなく、広い意味で捉えるなら)3～4
・サラリーマン：(普段は)0
・サポーター：6～7
年齢や経験で変わってその割合は変わってくるでしょうし、他の方から見ると(自分のそれと)違うかもしれません。
チームのふりかえりで(少しお酒でも入って)リラックスしながら、ディスカッションするとお互い気づきがあって面白いと思います。
※注意：この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。
Photo on VisualHunt
社内研修における受講者、講師について思ったことです。
社内研修には(自分から手を挙げる以外に)「3年目だから」や「主任だから」というキャリアによって必須のもの、また部長などが推薦するものがります。
いわば「自分の意志とは無関係」な研修です。
そのような研修で時々気になる光景、雰囲気があります。
「なぜ研修を受けているのか？」「研修で何を学ぼうとしているのか？」を持っておらず、「指名されたから…」「仕方ないから…」その場にいる…というものです。
その状態では「研修」自体の費用対効果は低いままです。
必須の研修でないなら、自分なりに考えてみて「その研修を受けない(辞退する)」選択をしても良い(むしろ…した方が良い)と思います。
(ほぼ全ての)研修に対して、評価、コメントを付けることができ、それが全体に公開されています。ですので、事前に研修の評価や内容を知ることができます。
一方、社内研修の講師側も「それはどうだろう？」と思うこともあります。
テキスト、スライドを読み上げるだけだったり、古い情報のままで更新されていない内容だったりすることもあります。
たまに「この資料は自分が作ったのでは無いので…」と言い訳する講師もいますが、論外です。
また「受講者に○○を身につけて現場に役立てて欲しい！」という想いが伝わってくる方はほとんどいません。
「受講者のやる気がないから…」等と言うのであれば、講師側が「やる気」を引き出す取り組みをする必要があると思います(研修本編か前準備かは色々ありますが)。
なので、講師は受講者に対し「(内容が)役に立たないと判断したら、途中退席もOK(もちろん社内的にペナルティなし)」と言える(少なくとも自分にとって)「良質」な研修を作り上げる必要があると思います。
社外勉強会やセミナーとの比較をすると、やっぱり受講者も講師も気持ちの入り方が違うためか、そんな光景はあまり見ません。
せっかく組織の力を上げることを目的としている「社内研修」なので、もっと「価値」を出せるようにしていきたいです。
※注意：この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。
Photo by Anosmia on Visual hunt / CC BY
以前エントリ「自分のテンションを維持する方法」で「朝早く出社する」ことを書きました。
これを少し詳しく自分なりに考えてみました。
まずはやはり朝早くの時間帯は静かで本当に集中できます。電話ももちろん話し声や人の気配もありません。
今いるフロアは次の人が結構遅いので、この時間を多く保つことができます。
この時間をより活用するように行動を変えてみました。
具体的には、『会社に着いて』やることを考えるのではなく、『通勤途中』できれば『前日の帰り』にやることをリストアップするようになりました。
前日に「やること」リストをアウトプットした上で、一晩過ごすと時々いくつかの考えが浮かんできます。
例えば「そのやることは(代替案がある/優先度が低いなどの理由で)今しなくていいのでは？」という考えで、それがYesであれば、不要な時間を使わずに済みます。
「やること」に関連して「これをやるということは、関係するこっちも…」と出てきます。これでタスクの漏れを防ぐことができます。
さらに退社時点で「明日のやること」ができあがっていると、行き帰りの時間で(ボンヤリとでも)タスク自体の段取りも考えることができます。そして、朝早くの時間をより効率的に使うことができます。
人それぞれのリズムがありますが、こういうアクションはお金をかけずに(自分の心持ち次第で)できる生産性の向上だと思います。
自分一人では朝起きるのはしんどい…というのであれば、チームなどで仲間を見つけてやってみると良いかもしれません。
※注意：この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。
Photo credit: Maarten Takens via Visualhunt.com / CC BY-SA
サービス業を中心として「おもてなし」「ホスピタリティ」という言葉があります。
ホスピタリティ→お互いを思いやり、手厚くもてなすこと。または歓待をすること。
一方、IT業界では「建設業」や「製造業」と比較されることは多くあります。
それは、大手コンサルやSIerを頂点とする多重下請け構造、ピラミッド構造やWBS、品質保証などのプロジェクト管理の考え方などです。
それ以外にも(専門的な技術用語以外の)用語や考え方も、けっこうそれらの業界を起源とするようなのもあります。
そういうIT業界ですが、お客様から(明示/暗黙を問わず)求められていることや、普段の行動やマインドはむしろ「サービス業」のそれである方が、良い仕事ができるのでは？と思います。
お客様自身にとっても明確になっていないお客様の求めていることを、会話など色々な方法で読み取り、それを提案する行為しかり。またプロジェクトの途中でも要望が変わる、追加されたりすることをその真意を理解し、敵対関係にあるのではなく、お互い良い関係になるように進めていく行為しかり。
では、実際にはどうなのか？ですが、IT業界が産業としてある程度成熟し始めてから、まだそれ程年月が経っていないこともあり、また、それなりのえらい人達は、他の業界…特に製造業など…などやって来た人が多いのか、どうもそこに「おもてなし」や「ホスピタリティ」という「サービス業」の概念を取り入れることにはあまり関心を払っていないように思えます。
最近は、最初からこの業界だった人(変な言い方ですが…)もえらくなって来たのか「そういうマインドがSIer、システム開発にも必要だよね」という声が上がっているようです。
＃旧価値観と新しい価値観の衝突が発生している箇所でもあるのですが。
※注意：この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。
Photo by twosheffs on Visualhunt.com / CC BY
人によってその会社を去る理由は色々あると思います。
(所属組織、他の組織問わず)辞める(た)理由を直接/間接的に聞いた時に思ったことです。
例えですが、あるサッカー選手が「自分はもっと華麗なパスサッカーでポゼッションを強みとするチームに行きたい。ここはカテナチオで守ってカウンターで点を取るチームだ」という理由で移籍しようとします。
で、その組織の経営陣や幹部も「確かにうちはカウンターのチームだ。パスサッカーのチームではない。仕方がない。今回は縁が無かったが、今後の活躍を期待しているよ」というものだったら双方にとって良いと思います。
＃具体的には「今の組織はコンサルや上流工程を極める人には向いているが、自分は技術を極めたいんだ！」な感じです。
ですが、組織の経営陣や幹部が「自分達の強みはパスサッカーだ」と思っている所に、前述のような理由をぶつけられると、その組織の強みを否定されることになります。
こういうことが何度かあって組織が「これではいかん！(自分達が)強みと思っているモノはなんだったんだ！？」となれば良いのですが、そうでなければ沈んでいくんだろうなぁと思います。
全てがそう単純化できる話ではないと思いますが、翻って自分が所属する組織ってどうだろうなぁ？と考えたわけです。
※注意：この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。
Photo on VisualHunt.com
組織の目標とは別に、個人も目標を立てて、定期的…半期に1度など…にそれを評価する仕組みになっています。
目標の例として「○○PJのリリース日を遅延しない」「情報処理試験に合格する」や「○○という技術について習熟し、チームに横展開する」などです。
一般に個人の目標は、当人と上司以外にはほぼオープンにされません。
この個人の目標は、私は(少なくとも)一緒のチームメンバーにはオープンにしても良いと思います。
チームメンバーにオープンにすることで「お、あいつは【あの目標】だから、こういう風にがんばっているんだな。」と行動の根拠が分かったりします。
また「○○を習得する」という目標を立てているメンバーには、チームの有識者が声をかけ、協力して目標達成を目指すということもできます。
そういう形を通じて、お互いの理解も深まるでしょうし、チームの一体感も強化されるかもしれません。
また、目標を立てた側も、周囲に宣言することで「やらなくっちゃ」という気持ちも強くなり、良い意味の相互監視的な面で、お互いのレベルアップができるかもしれません。
チーム力を上げるのは、なかなか難しいテーマの1つだと思います。
その点で、チーム力強化の1つのアプローチとして、相互理解を進めるこういうきっかけもありかもしれません。
※注意：この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。
Photo via Visualhunt.com
危機意識を持って…もしくは思いつきで…、トップダウンの形で「組織風土を改善し、より強固にしよう」とか「ノウハウを共有して、ビジネスの力にしよう」という話が降りてくることがあります。
(トップから命令された)実行チームは、この話に対して(ディテールは違うにせよ)、社内SNSやWikiなど情報を集積できる場を設けて、そこに投稿してもらう(そして利用者はそれを見る)という手段を取ることが多いと思います。
こういう場合のたいがいのパターンは…
1：最初は(トップから指名された実行チームが投稿するので)ちょっとだけ活発になる。
↓
2：けれど、それ以外に投稿が少なく、実行チームもそこまで推進力、継続力がなく閑古鳥が鳴いている。
…となります。
こういう話に対する現場の反応は「忙しいから無理！」というのが大半です(おおっぴらに言うかは別として)。
ただ、「ノウハウ共有、良いじゃない！いっぱいノウハウ提供するよ」という人も、それ程多くありませんが、一定の割合でいます。
なので、こういう試みのポイントは、上に書いた1の状態から2の状態になるまでの間に、その人達が継続的にアクションをする(しやすい)状態を作れるか…だと思います。
が、往々にしてそこまで気が回されていなかったりします。
例えば…
1：社内SNSにせっせと投稿する。
↓
2：それを上司から「あいつ、暇やねんな。仕事していないな」と評価される。
…とか…
1：社内規約を(ちょっと解釈を広げて)工夫するノウハウXXを投稿する。
↓
2：(その社内規約の管理側から)「そういうXXはN条では認められていない！！けしからん！！」という重箱の隅をつつく指摘があったり。
…とか…
1：社内SNSにせっせと投稿する。この人は情報を知らせたいだけで、それをどう使うかはそれぞれと思っている。
↓
2：「じゃあ、君がその情報をより広めるような役割をしてくれ」と予想外の役割を押しつけられる。
…というようなことが、あったりします。
そして、それに対して実行チームやトップからのフォローもなかったりすると、そういう人達も「雉も鳴かずば打たれまい」と考えてアクションを止めてしまいます。
人間学とか行動学なんて難しいものではなく、ちょっとした想像力を持ってそれを活動に組み込めば、もっとうまく行くのに…と残念に思います。
＃本来、トップダウンでなく、現場から自然発生的に産まれ、それをトップ層がフォロー(正しく評価するとか、環境を整備するとか)して大きくするのが良いとは思いますが…。
※注意：この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。
Photo credit: Chairman of the Joint Chiefs of Staff via Visualhunt.com / CC BY