« 2015年4月 | トップページ | 2015年6月 »

2015年5月の記事

即興ディスカッション(お試し)

全社定例会では、出来る限り、ナレッジの共有(暗黙知・実務の例など)や勉強会(ワークショップやハンズオン)、ディスカッションを行うようにしています。

まあ、必然的に、事前にお題を決めてタイムテーブル組んで社内専用サイトにアップ&「アップしたよー」と全員に告知メールを出します。

お題は、メンバー各位から関心のあるモノとして提案が有れば(合理性に納得できれば)載せますし(誰が仕切るのか?が問題になったりしますが)、
定例会コーディネーター?(私)が社内専用サイトに挙がる情報や、個別に対面で聞取った話、チャットツール上で話題になった話を元に、話題の発信者である人物にコンテンツ展開を依頼したりします

或いは、今現在&今後必須となるであろうスキル要素として必要な勉強会を設定したりします。
これは、社内に実務経験者がいれば依頼・調整するんですが、いない場合には仕方が無いので私が企画・運営を試みます

何れにしても、事前にお題と予定時間枠を見込んでタイムテーブルを作成するわけです。

が、しかし!
「各人が所属するプロジェクトの今!」の中で気になっている「あれやこれや」を話題にする機会が無い。
「じゃあ次回定例会でやりましょうか」だと、1ヶ月の遅延が発生する。
「何か気になった事があったんだけど、何だったっけ??」となる(「疑問」はナレッジへの重要な入口です!)。

今、メンバーが集まってるんだから、今話題にしちゃいましょうよ!
.....という事で、定例会の中で毎回、「今、気になっているあれこれ!」を挙げあって、アットランダムにディスカッションしましょう!
という事が前回定例会で決まりました

が、その趣旨が共有されてなかった!?...
って言うか、言い出しっぺの本人すら「これって何だったっけ?」とか言ってるし!?

うーん、そもそも、このような展開になり得ることを予測して、事前の周知メールなり何なりで参加メンバー達に可能な範囲での準備・心づもりをしておいてもらうように(定例会の企画・運営側として)下準備をしておくべきだった...のだろうな...。
「任せる」のと「放置する」は違うもんな...)

Pict2720とりあえず、前回のディスカッション(私が事情が有って欠席せざるを得なかった回)で出た発言の中に既にネタが有ったので、先ずはそいつから片付けないかい?
...と話を振ってディスカッション開始!

ネタは、入社して丸1年になる速形さんの発言が元で、「検索:欲しい情報の見つけ方」のあれこれナレッジが有ったら知りたい!、というものでした.....。

けれども、出席している殆どのメンバーからすれば、「大体みんな、各々に合った方法で工夫してるでしょ?」という雰囲気が充満。

Pict2722Pict2724それでも、とりあえず色々な側面から発言してくれるメンバー達には、本当に感謝・感謝です。
「あ、そういうアプローチも有るのね」というTipsレベルの共有は出来たんじゃないかな、と。

ですが、さすがに充実した展開・ナレッジ共有の場にはなり辛いので、
「とりあえず次回も継続してみる」・「時間枠は20分で十分」(今回は、前回ディスカッション時と同じ60分に設定していた)、「お題が出ない・盛上らないなら即終了」と、大幅に時間枠を縮めることにして終了。

で、その余った時間を、前回の記事で挙げた「インセプションデッキ・ワークショップ」に加えました。
(結果は、それでも通常の定例会の総時間枠を30分以上オーバーしてしまったのですが...)

終了後は、皆クタクタ(空気がドヨーンとしていた)。

そりゃそうでしょうね、お腹も空いているでしょうし(20時過ぎですから)。

Pict2747Pict2748Pict2749そこで、今月のお誕生日の人のお祝いへとシフトしましたー!(甘いものが食べられるぞー!

5月生まれは池田さん!!

何故かスマフォを構えた数名(私を含め)に包囲されて、さながら撮影会の様相!!

なんで??

先月の誕生日だったのだけれど、定例会が終わってから到着した(「デブナイ」だけでも参加する為に帰社した)徳田さんも一緒にケーキを食べられましたー。
(写真は、ケーキに乗っていた「さくらんぼ」に噛り付いているところ、でしょうか?)

何やかやと、とりあえず「楽しくやる」ことは大切ですよね!

(「段取り」と「充実感の共有」も重要ですけど...(反省))


★クリック1つでブログランキングにご協力戴けます! m(_ _)m

| | コメント (0) | トラックバック (0)

ワークの案件設定を公開します。

前回の記事で、「インセプションデッキ・ワークショップ」を行ったというお話をしました。

その中で「仮想案件を設定して進めた」旨の記載をしたんですが、その案件の具体的な内容は書きませんでした。
理由は簡単で、「長ったらしくなり過ぎるから」です。

が、もしかして、このブログを見て戴いた方で「ウチでもやってみっか!?」と思って戴いた方もおられるかも知れない...。

「仮想案件」と言っても、簡単そうで意外と設定が結構・面倒臭い(←ぶっちゃけの話)

実際に関わっているメンバーがいる案件では、現実の様々な不可避の条件に縛られたり、事前情報・条件認識に差が出てしまいます。

かと言って、まるで荒唐無稽の設定では話にならない。
メンバー達が経験したことも無い、想像すら難しいような設定ではワークショップとして盛上れない。

ほぼ全員が(余程の新人は別としても)、設定内容を聞いて「ああー、なるほどな...」と肌で?感じ取れる内容
それでいて、結果が「誰が考えても、これしか答えは無いでしょ?」となるような設定でもつまらない。

ワークの後で、各チームからデッキの発表を行ってもらう訳ですが、
その時に「あー、うちらのチームも似たようなもんだー」じゃ盛上らない...。

「え?、何でそうなるの?」
「ああ、そう来たわけね!」、「じゃあ、この点はどう考えるの?」
...とか、各人の経験や判断・価値観の差異が出るようにしたい。

そこから、形式知や暗黙知がいろいろと出て来るはず。

そこを共有していくのも重要な目的の1つですから!

という事で、今回、我々が設定した仮想案件を原文のまま紹介させて戴きますー。
(もし宜しければ、ワークの設定の叩き台としてでも利用して戴ければ幸いです)
(その場合[↑]は、このブログに簡単にでもコメント戴けたら感謝・感激です!)

★仮想案件の設定

・既存の不動産系のBtoCサイト/サービスが有る (同様サービスの中ではトップグループのシェアを持つ)
・画面の遷移的に、導線が遠い、分かり辛い、操作しにくい、見た目は悪くないが実態は如何にも旧式のUIだ
  ・最近流行の、動的反応のある、アクセスして楽しいUI・UXにしたい
  ・導線を短くし、成約に近付けたい (画面遷移・機能配置・操作性なども要見直し)
・ソースコードも品質が低く、メンテナンス・コストが上昇する一方でそろそろ限界。不具合も出易い(増加傾向)。
  ・セキュリティ面も怪しい...(事故が明確化した事例は未だ無いが)
バックオフィス系も同様(同上)、機能的にも弱く運用コストがかかっている(改善余地が多分にある)
全体を一新したい! (フロント&バックオフィス)
  ・殆ど全て作り直すしかないだろうと考えている
  ・幾つかの古くなった機能のカットや代替機能の追加等も含めたい
  ・スマートデバイス対応にしたい
  ・幾つかの外部サービスやサイトとの連携機能を組み入れたい
  ・性能的な課題は特に無い
・競合サイト/サービス等も有るので、早くリリースしたい
  ・既存サイトは同業界内では比較的先行しシェアも握っているが、後発の競合サイトにシェアを取られつつある
  ・3~4ヶ月後を目途にリリースしたい! (←あくまで顧客要望)
  ・画面数は60程度、バッチは各種30本ほど
  ・既存仕様は完全にはドキュメント化されていないが、全てを認識している運用担当者がいる。
  ・内部設計に関するドキュメントは当てにならない。
・運用は顧客内のチームが担っている (開発的なモノは適宜で外出しして来た)
・現行のデータの移行も必要 (ほぼ全てRDB内)
  ・データベースは約100テーブル
  ・最大件数は100万件(レコード)程度
・システムの想定寿命は、(保守開発など含めて)8年程度?(業務処理部分はもう少し長い?;UIは寿命が短いと考えている)
・アクセスの時間帯的な集中度はそれほど高くない
・既存の他システムとの密連携は無いものとする(並行開発システムなども無い)

.....これだけです。

今回のワークではデッキは2つ(詳細は前回分の記事を参照願います)しか作りませんでしたので、これ以上の設定は邪魔でしか無いとの判断です。

敢えて「完全新規案件」に設定しなかったのは、「何とかなるんじゃね?」と思わせつつ、「いやいやいや、無理難題でリスクまみれだろう!」と悩んで欲しかったのが1つ

あとは、現実的に大抵の顧客は既に何らかのシステムやサービスを持っていて、改修や機能拡張、UI・UX強化(ユーザーから見ればイメージ刷新!)を行いたいというケースが多いから(これは弊社の受注ベースでのお話にはなりますが)です。

自社企画プロダクトの設定にしなかったのは、現時点では未だアスペアの収益の多くが「顧客からの開発要望に応える」に寄っているからです。

出来れば週明けからでも(ワーク実施は金曜日だったので)、現実の現場でアプローチしてみて欲しい!
せめて、現在仕掛っているプロジェクトで「デッキがあるとしたら、どんな内容になっているんだろう?」・「どうあるべきだろう?」は、ワーク当日の帰宅の移動中にでも考えてみて欲しかった

さて、どうでしょう?

何らかの変化が見られるのはいつの日か?、どんな形でなのか?
それとも変化としては認識できないまま時間が過ぎて行ってしまうんだろうか?

.....等と想いつつ、次回の想定時期や内容を考えていたりします。


★クリック1つでブログランキングにご協力戴けます! m(_ _)m

| | コメント (0) | トラックバック (0)

インセプションデッキ・ワークショップをやってみた!

5月の全社定例会の中で、「インセプションデッキ・ワークショップ」をやってみました!

「インセプションデッキ」は、アジャイル系の開発プロセスの中で提唱されているツール(ソフトウェアじゃありません)ですが、別にアジャイルでないと使えない訳ではありません

「インセプションデッキ」の概要は、こちら[↓]を参照して戴いた方が良いと思います。
http://keisuke8.hatenablog.com/entry/2012/11/16/131825

プロジェクトの全体像(目的、背景、優先順位、方向性等)をわかりやすく伝えるためのドキュメント、ということになっています。

また、関連事項として「期待マネジメント」ということにも直結するとのことです[↓]
http://blog.guildworks.jp/2014/09/17/devsumi2014kansai_story/?utm_content=buffer62176&utm_medium=social&utm_source=twitter.com&utm_campaign=buffer

PMBOKで言うところの「プロジェクト憲章」に相当する、と考えれば良いのでしょうかね。

で、定例会当日(欠席者は3名のみ)、全員に聞いてみました。

「インセプションデッキって、聞いたことある?」
.....これには、「聞いたような気がするけど...」という人がちらほらいた程度。

インセプションデッキの概要を説明してから、「このようなものが、一部であれ、何と呼ばれていようと関係なく、現場で共有されていたプロジェクトを経験したことのある人は?」という問いに対しては、誰も手が挙がりませんでした...。

Twitterでフォローしている、アジャイル系開発プロセスを積極的に取り入れている人達の間では「常識・大前提でしょ!」って感じ
実際にどのように運用されているのか?、詳細は当然のことながら?記載が有りません。
(プロジェクトの中身をさらけ出すってのは、一般的なプロダクトでは不可能でしょうから)
よく探せば見付かるのかも知れませんが、今のところは実戦上の具体的な情報は見付けていません。

しかし、「顧客の要求や制約条件・プロジェクトの向く方向を決める」などの点で、メンテナンスと共有をプロジェクト終了まで(運用フェーズでも?)継続するということは触れられている。

是非、社内でワークショップやりたい!
重要性は多分理解してくれるだろうけど、実用性・実体験を少しでもしてみて欲しい!

...と言っている自分自身も経験が無いんだけど先ずはやってみるしか無い!

という事で、やってみました。

タイムテーブルはこんな感じ。(頭の"[]"で括られた数字は、想定時間(分)←無理に押し込んだ)

[07] インセプションデッキの説明
  概説...リンク資料の中身を見て貰い(読み)ながら
    期待マネジメント (スライド:p.22~29)
      http://blog.guildworks.jp/2014/09/17/devsumi2014kansai_story/?utm_content=buffer62176&utm_medium=social&utm_source=twitter.com&utm_campaign=buffer
    概要説明
      http://keisuke8.hatenablog.com/entry/2012/11/16/131825
    トレードオフスライダー
      http://qiita.com/shibacow/items/b6462d54eba4fdd4e61b

[03] 企画の意図
  なぜ?、今回のワークショップを企画したか?
  ・開発プロセス/プロジェクトに関わらず、必要な前提事項だから!
  ・選択権が有るなら作りたい; 参画案件で最初に確認したい; 無いなら(可能な範囲で)設定(提案)したい
    ↑:この知識・認識を共有して、行動に反映して欲しい! (実践してる人は継続)
    ↑:「木」の担当者であっても、常に「森」を意識すべき!
    ↑:「振られたタスクの視野で見る・考えるだけで良い」とは考えたくない!!
  ・自分が「途中で参画した」時のことを想像して、「こんな前提でPJが動いていたらどうだろう?」って想像してみて。
    ↑:※無いとしたら、※有った(ちゃんと共有・理解・承認・メンテされている)としたら?...

[01] 今日の進め方
  ・3~4人程度のチームに分割
  ・仮想案件を元に、デッキの2つばかりをチーム毎に考えて貰う
  ・発表&質疑
  ・振り返り

[08] 仮想案件の説明

[07] お題の説明・成果物を明示
  ・模造紙:3枚、マーカー、付箋
  ・何を諦めるのか?: (トレードオフスライダー)
    ・最低限の要素(上記のサンプルを最低限の要素とする)
    ・スライダー(要素)を加えても良い
    ・スライダーの絵を描いてね (ゼロサムが原則;「夢」(全部叶える!!とか)を描かないで!)
  ・やらないことリスト:
    ・要素を付箋紙に書き出す (全員でバンバン;重複も構わず)
  選択(「やる」は挙げなくて良い;選択の結果が「やらない」になったら付箋を移動するだけ)
    ↑:模造紙を2分(「やる」「やらない」の線を中央に引く)して、付箋を付ける位置で分ける
  <別の模造紙> 「不明の前提」事項、「未定事項」、ワークショップの設定や進行への問題提起、などなど

[02] チーム分け
  (実際には3~4人を1チームとして、3チーム出来ました)

[30] ワーク
 (↓:実施要領の参考)
  ・仮想案件の理解、特徴(留意点)・問題点の抽出(付箋で、皆・同時に、お互いの出方を待たない!)
  ・整理(優先順位付け(仮)、不明点、保留点などに分類...)
  ・トレードオフスライダーを作成
    ・案件理解から、ポリシーが見えて来るはず...
  ・やらないことリストを作成
    ・「(いずれ)やること」(スコープとか工程とか...)やを荒く(付箋で)挙げてから評価の優先順位を決める
    ・優先順に「(いずれ)やること」を分解(細か過ぎないように!)
    ・「やる」「やらない」を、スライダーのポリシーに従って分けて行く(「?」は分ける)

[16] 各チームから発表

[06] 振り返り

"想定時間" は、別コンテンツとの兼ね合いで、準備段階ではどうしても枠が80分程度しか取れない...。

ので、無理やりに詰め込んで実施してみたんですが.....

 

全然、収まりませんでした。

実は最初の想定は100分だったんですが、結果を見れば110分を更にオーバー。

数が多いのですが、ワーク中の写真も掲載させて戴きます。
何となく眺めていると、少しづつ進んでいくのが分かるんじゃないかと思います。

Pict2725Pict2726Pict2727Pict2728Pict2729Pict2730Pict2731Pict2732Pict2733Pict2734Pict2735Pict2736Pict2737Pict2739Pict2740Pict2741Pict2742Pict2743Pict2744Pict2745Pict2746


ワーク自体は、みな頑張って想定時間内で仕上げてくれたんですが、最後の振返りで意見百出!!
最後の振返りの議事録(メモ)を転載します(全ての意見は書ききれてませんが...)。

Keep
  ・発表は敢えてチーム内で最も経年の浅い者が担当するのが良い!
    (↑:今回も全チームが行っていた!。何の意識合わせもしていなかったのに...
Problem
  ・制限時間が短く、経験の少ない者の発言機会を十分に確保できなかった
    ・時間内で一通りの結果を出す為に、リーディングを強くしてしまった
  ・フェーズを区切って開発を行う想定とした場合に、「全体」(前提)と「初期フェーズ」を別に書けない
  ・スライダーの共有対象者が不明(顧客まで含めない方が良いのでは?)
    ・顧客との間では別の表現で共有すべき。今回のデッキは開発側だけのポリシーとすべきでは?
    ⇒顧客次第の面もあるが、可能な限り「本音と建前」のような別文書での管理は避けたい...
  ・スライダーの要素は増やしてもよい
  ・リーダ級の人はファシリテーターに務めるべき?、相対的に経験の浅いメンバーに考える機会を提供すべきでは?
Try
  ・ユーザ役が欲しかった(質問をしたかった)
  ・新人は自分の言葉で発表できるよう理解に努める!

少なくとも、「インセプションデッキを考えて(作って)みる」という機会を設けたこと自体は、
良い機会として認識してくれたようです。

 

仮想案件の条件設定を変えて、デッキの項目も変えて、また実施してみたいな...。

今回は顧客からの依頼案件、という設定でしたが、
「自社企画プロダクト」の想定で是非ともやってみたい!

デッキの要素数をフルセットの10要素にしてしまったら、恐らく1日(7.5時間)でも足りなくなるだろうな...。

でも、何回か繰り返して実施していきたいと思います(数か月間隔ででも)。


★クリック1つでブログランキングにご協力戴けます! m(_ _)m

| | コメント (0) | トラックバック (0)

デブナイ(2015春)

4/17は全社定例会だったのですが、その後にデブナイDevelopers Night)が行われました!

...という事を前回も書いたのですが、仕切り役を買って出てくれた蓑方さんから当日の様子をインタビューしましたので、ここにアップしておきます(ちなみに、写真は有りませんー)。

そもそもの始まりは「良い名前を付けようじゃないかっ!」の回で書きましたが、
http://aspire.way-nifty.com/majime/2015/02/post-0dd2.html
定例会の枠内で収束させるのは無理じゃろ?
でも、これはやっときたいね!(そういった意見が元で議題にし始めたんだから)
...ということで、デブナイ開催のきっかけとなったのでした

メイン・コンテンツを先に実施、ということで、「ネーミング規約」(今回はメソッド名を中心に)から着手
参加者は、仕切り役の蓑方さん、三文字さん、青柳さん、山内さん、小障子さん、徳田さん、山下さん、速形さん、忠さん、とみー の10名でした(現在のアスペア社内技術者の約2/3が参加してくれました!、凄い!)。

事前に、仕切り役の蓑方さんの方から「決めておきたい、迷うことの多いメソッドの機能」をGoogleDocsのスプレッドシートに挙げておいてもらうよう皆に周知し、事前に集約。

当日は、codichttp://codic.jp/)(IT技術者のためのネーミング辞書;日本語用語に対して候補となる英単語群が示される)を参考にしつつ、現実的にどの名前が良いか?(これは無いだろう!、とか)を1つ1つ絞り込んで行ったそうです。

結果は、上記でまとめたGoogleDocsそのものを、今後の社内標準として採用・共有することになりました!
成果物が出来て良かったです!!
(プロセス自体に意味がある!って場合も有りますけれど...)

で、24:30~25:30位の間で、終電で帰宅するメンバーは引けて、残るは数名。

休憩時間の間は、各人が普段時間が取れなくて調べることが出来ていないことなどの調査とか、普段はリモートでコラボしているメンバー間で対面打合せとかで過ごしていたとのこと。

その後はカードゲーム大会でメンバー間の交流。

プロジェクターを使っての上映会(「変態仮面」!?)、食事、仮眠など、
まあグダグダと過ごしたそうです。
今回仕切り役の蓑方さん曰く、「デブナイは、このグダグダ感が真情です!」

という訳で、何名かは始発まで事務所に残っていたようです。

お疲れ様でしたー。


★クリック1つでブログランキングにご協力戴けます! m(_ _)m

| | コメント (0) | トラックバック (0)

デブナイと4月の誕生祝と...

ゴールデンウィークを挟んでしまったので、何だか随分と昔の話になってしまったような気がしますが...。

4月の定例会の直後にはデブナイ(「Developers Night 2015」)が実施されました!

呼び名の通り「開発者の夜」ですが、勤務時間外なのでコンテンツは参加者により自主的に企画・実施されます。
事務所の場所や設備を自由に使って頂戴!(勿論、「一定の節度を持って」ですけどね)ということです。

内容の制約は有りません
法的に問題無く、周囲にも迷惑が掛からなければ何でもOK!(「開発」に関わらないものでも?!)って感じです。

ちなみに、前回のデブナイは.....約3年半前に行ってますね!
http://aspire.way-nifty.com/majime/2011/11/developer-night.html

いつの間にか随分と間が空いてしまいましたが、特に定期的に行う事を前提にしている訳ではありません。
自然発生的に場が盛り上がって、何らかの方向性が出て来た時に行うイベントパターンの1つです。

Pict2718実施は定例会の終了(大体19:30)後、
大抵は各人・エネルギー補給を行ってからの開始となります。
数名グループで食事をしたり、コンビニ弁当だったり、ピザの注文を取ったり...。

写真は、定例会終了後 ~ デブナイ開始前の一時

定例会の最後に、毎月の誕生日の人の為に小さなホールケーキを用意しておき、
照明をカットして全員で「♪ハッピバースデイ、トゥーユー♪」と合唱します!
(ちょっと気恥ずかしいですが、ここは思い切って大きな声を出せばOKですっ!)

Pict27194月の誕生日の人の内の一人、三文字さんでーす!(このブログではよく登場しますが; アーキテクトであり、優秀なプログラマーでもあります!)
もう1人の誕生日な人、徳田さんは定例会には間に合わず。
でも、デブナイには間に合ったそうです(なので、「ケーキは取っておいて下さい!」とのリクエストが有ったそうな)。

さてさて、私は体力的に付いていけないので、前述の歌を歌い終えて&写真を撮って帰宅してしまいました.....。

果たしてデブナイで何が行われたのか?
漏れ聞いたところによると、夜明けまで残っていたメンバーもいたとか...

実は未だに「何が行われたのか?」を確認してません!
(業務ではないので、議事録とか何も記録の類は残ってません。参加者達の頭の中に有るのみです(多分))

余り時間が過ぎない内に、基本的な進行役を務めた蓑方さんにインタビューしようと思ってます

ここに書けるような内容だったら(?)、改めてアップさせて戴きます!

乞うご期待!??


★クリック1つでブログランキングにご協力戴けます! m(_ _)m

| | コメント (0) | トラックバック (0)

英語漬けだよ!

社内でのコミュニケーション、ドキュメンテーションは全て英語に統一するっ!

.....というお客様が、徐々にですが増えて来ていますね

とは言え、ある程度の企業規模になると、さすがに一気に、全部署で均等に移行!という訳にはいかないようです。

Pict2711ですが、長部さんの業務先部署は最も英語化が進んでいる方のようで、「英語しか話せない(或いは他の外国語も話せる)日本人以外の人達」人が、どんどん増える一方

更に、所属部署では基本的な開発プロセスとしてスクラムを採用しています。
で、長部さんの所属チームのスクラムマスターは「英語ネイティブ(日本語まるでダメ)」!

アスペアの中では、比較的・英語との実戦的な付き合いの長い長部さんですが、「読み・書きは大丈夫だけど、聞く・話すは苦手...」とのこと(ちなみに、以前は「InfoQ」記事の翻訳副業もやっていたそうです)。

長時間の会議で、資料よりは口頭のやり取りが重要な場で、しかも長時間に及ぶような会議は結構辛いそうです...。
「みんながドッと笑うような場面では、苦笑いするしかないですね...」とも。

そんな長部さんが気を付けていること、体得した経験則をまとめてみました

・スクラムマスターに英語で伝える・会話する必要アリ。
  ⇒口頭ベースが苦手なので、文字ベースを併用する方向...
  ⇒HipChatで最初にテーマを書いて共有してから、会話しに行っている

・とにかくおかしな英語でも、日本語を混ぜてでも構わずに話す。
  ⇒躊躇せずに、とにかく吐き出すことが大事。

・会話が過熱(高速化)してきたら、
  ⇒翻訳できる人を介して話す。
  ⇒途中で会話を止めて、文字で整理してから、再度・会話を続ける

・日本語ででも、最初に概要を出してから声をかけるのはよいやり方。

Pict2712「もう、言わないでもいいか...」という選択肢は無い!

会話して、事実や認識を出来る限り共有する。

知っていること、持っているアイデアは絶対にぶつける。

既にベテランの域に入っている長部さんですが(見た目はスゲー若い!)、年齢や経験年数に関係なく皆とコミュニケーションを取り、チームの雰囲気を良くすることが得意(大好き!)。

とは言え、英会話は苦手でも、文字ベースを含め何としてもコミュニケーションを必要十分に取ることで、プロジェクトを成功に導きたいというプロ意識も強い!

柔和だけど筋は通すぜ!
...と、そんな長部さんの人柄を示すエピソードでもあったと思います。


★クリック1つでブログランキングにご協力戴けます! m(_ _)m

| | コメント (0) | トラックバック (0)

« 2015年4月 | トップページ | 2015年6月 »