カテゴリー「定例会、勉強会など」の303件の記事

最悪トラベル・ワークショップ。

9月の定例会では、「最悪トラベル・ワークショップ」を行いました。

筆者の記憶では、かなり前?に社内で実施した記憶がある(筆者の進行ではなかった)のですが...
開始前に出席者に聞いてみると、「知らない」・「聞いたこと無い」・「勿論、経験も無い」。

まあ、「あーあれねー.....」みたいな辛い反応が返って来るよりは良かった。

はじめに:
 ワークショップシリーズとして、新規事業立ち上げの為の一連のワークをして来ているのですが、
 ここ数ヶ月の間、アスペア内の最大のグループが繁忙期が続いて定例会の人数が集まりません...。
 
 これで無理にシリーズワークをしても仕方が無いか...という訳で、
 今回は業務やビジネスとは直接的には全く関係のないワークにしました!
 
 結構昔から存在するワークで、「最悪トラベル」というものがあります。
 今回は、書籍:「情報デザインのワークショップ」にある記載内容を元に実施しました。
 
 目的の主たるものとして「一見悪いアイデアであっても、発想を転換することで、魅力的なアイデアへと
 発展させられることを体感し、自由なアイデア発想を行いやすい環境や態度を作る」と書かれています。

概要:
 下記のようなタイムテーブルを想定してスタートしました。

 1. 最悪な旅行【20分】
  1) 発散[15分]
  2) 収束[5分]
   ・各グループでブレインストーミングを行い、史上最悪の旅行はどのような旅行になるかを発想する。
   ・マインドマップとふせんを使って発想すると取組みやすい。
   ・どんな状況で、誰が誰と、どんなときに、どこで、など具体的にしていく。
 2. グループ間での相互発表【8分】
  ・グループの代表者1名が隣のグループに移動し、グループで考えた最悪な旅行のストーリーを発表する。
  ・残りのメンバーは、別のグループの代表者が発表するストーリーを聞いて理解する。
  ・発表するときは最悪ポイントをまとめたA3の紙を見せながら発表し、発表後はその紙を相手のグループに渡す。

 3. 最高の旅行への転換【23分】★(重要)
  1) 発散[14分]
   ・各グループでブレインストーミングを行い、相手のグループから示された「最悪ポイント」をそのまま受け入れつつ、
    最悪の状況を最高に変えるアイデアを発想する。
  2) 収束[9分]
   ・最高の旅行のストーリーを作る。
   ・そのストーリのような最高の旅行をサービスとして提供する旅行会社になったつもりで、旅行のアピールポイントをまとめる。
   ・最悪ポイントを最高に変換する体験とサービスの流れ、実現するのに必要な仕組みなど、なるべく具体的に考える。
 4. 最高の旅行プランの全体発表【1チーム5分程度】
  ・プレゼンテーションの最初には、相手のグループから示された最悪ポイントを説明する。
  ・発想した最高の旅行のストーリーをサービスプランとしてストーリーテリングで発表する。
   ・テレビ通販の紹介のようなプレゼンテーションで、最高の旅行のストーリーを語るとよい。
   ・発表では、心理・精神状態を行動として表現すると分かりやすい。
  ・発表後は、最悪ポイントを考えたグループの代表者がどれくらい最高なアイデアへと変換できたかコメントする。

実際の進行:
Dsc00847  Dsc00846 先ずチーム分け。
未経験の中途採用者も2名いるので、一緒にならないように、不断顔を合わせる機会の多いメンバーとは
 組まないように、など条件を付けつつ...
 実際にどうチーム分けするかはメンバー任せ。

 制約条件に引っかかったら適宜で入替え...のつもりだったんだろうな。

 とにかく、何だかいつもより、皆がハイな気がする...気のせいだろうか??

Dsc00849  Dsc00848 実は今回は参加者が超少なくて、通常なら定例会の開催を中止するレベルだったのですが、2ヵ月連続で開催無しは辛い!
 6人以上いれば2チームが構成できるので、ワークの実施可能!
 まさにそのパターンで動きました! あははははは。
 (ワークの終了間際に、1人遅れて帰社しましたが...)

Dsc00854 Dsc00853  Dsc00850 それにしても、ワークの各ステップとして設定した時間を、メンバー達がことごとく短縮して進行していきます!
 何だか知らないが、盛り上がってる! 作業速い!!



 当初の目的の一つに、「業務時間内に、通常業務から外れた頭の使い方をしてリフレッシュする」・「新人を含めたワークの場を
 設定して動きを見たい」ってのもありました。

 どちらも成功だったようで安心しました。

振返り:
 ・Keep(?)
   ・熱中して我を忘れた
   ・ワークとしての進行から外れていたかも...
   ・業務要件の間を突く?ような感じ?、面白そうだった(ほぼワーク終了時刻に帰社したメンバーより)
   ・「最悪の想定をする」って非日常的で面白い!
 ・Problem
   ・進行役が、実は大切な前提となる制約条件を説明し忘れていた。
    ⇒まあ、その分で更に盛り上がったし、今回は結果オーライか?!
 ・Try
   ・(機会を見て再度実施しても良いかも知れない...)

所感:
Dsc00855  Dsc00852 ・実は、今回のワークの前に、全社内的な「疲労蓄積度チェックリスト」(Googleアンケート方式)の調査を済ませてました。
 ・研修が始まって間が無い2名はともかく、それ以外のメンバー達に(程度の差はあれ)閉塞感のようなものを感じていました。
 ・無策のまま放置している訳でもないのですが、効果が出るまでに時間を要するものが多く...せめて何か気分転換を!
   ・グループワークのような、時間制限を伴う、一種の競争のような状況を楽しめないか?、と思っていました。
 ・形式知や暗黙知といった面では、特に役立つワークではなかったと思います。
   ・が、人間ですから。お互いに少し羽目をはずし合って、ストレスを少しでも軽減できたとすれば、良い機会になったのではと思っています。


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

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

"ペルソナ"設定ワーク(後半戦)

前回の(=3月の)全社定例会では、"ペルソナ設定ワーク"を(全社的には)初めて行いました。
 
2名が実際の顧客先で、お客様側のステークホルダの方々と一緒に「ペルソナ設計」を行い、
それを元にサービスの見直し・施策の検討などを行った経験が有りますが、
「経験豊富」と表現するにはまだまだ勉強・経験・改善を繰り返して学んでいく必要がありそうです。
 
前回は時間枠として50分しか取れなかったので、翌月に延長実施することにしていました。
しかも90分も確保するという思い切り!?
 
はじめに:
概要:

 必要に応じて、前々回の記事をご覧下さい。
 同じ事を2度書いても仕方がありませんので。
 
実際の進行:
 前回は出席していて、今回は欠席のメンバーが1名。
 逆に、前回は出られなかったが今回は出席出来たメンバー(ママさん技術者2人+業務都合の男性)が3名。
 
Dsc00813Dsc00818  Dsc00812 前提として「前回からの続き」なのですが、
 前回参加できなかった3名の為に、軽くワークを実施する目的や進め方の大枠を説明しました。
 前回から約1ヶ月経っているので、全員が思い出すのも兼ねて。
 
 で、早速チーム分けを実施しました(参加メンバーの意志任せで、私は敢えて仕切りませんでした)。
 
 基本は前回チームが継承されましたが、歩調を合わせる為に、未経験メンバー3名が1チームを構成する結果となりました。
 なるほど。
 
Dsc00822 Dsc00821Dsc00820  「対象とするサービス案」は何にするか?
 前回は3チームで2案に分かれたので、参加メンバーの1人から
 「前回1チームだけが対象にしたサービスがあるから、それを選べば結果比較が2組出来るね」との発案。
 で、そのように対象とするサービス選定が行われました。
 
 今回は時間もたっぷりで余裕。
 ワイワイとじっくり話し合いながら、グループ毎に考えてもらいました。
 (A2の画用紙を台紙にして、大き目の強接着力の付箋に、ペルソナ属性を書き込みながら張っていきます)
 
Dsc00828Dsc00829Dsc00832Dsc00834  基本属性10種が決まったら、「現在のペルソナが置かれた状況や思っていることを文章化」して、
 サービスとの接点を探って行けるるようにします。
 
 で、制限時間になった時点で「相互に見せ合う」アクションに移行しました。
 
 ですが、ここで既に計算外が1つ。
 今回のゴールは前述の通り「現在のペルソナが置かれた状況や思っていることを文章化」するところまで。
 これを出来ていたのが1グループのみ。
 何で?
 
 ゴールの認識共有が甘かったか?!
 白板に書くか、ワーク告知の社内サイトに明示・最新化しておくべきだった!
 
振返り:
 ・Keep
   ・数字があると分かりやすくイメージし易い。グループ間でも会話が盛り上がる。
 
 ・Problem
   ・今回のワークは前回とそれほど変わらなかった。
     ・より深く設定したものや、次につながる展開が欲しかった。
   ・同じサービスに対するペルソナ設定ペアが2つ出来たのに、的(マト)に絞らないのか。
     ・手順を経験することに意味があるとしたら、手順に沿えるように運用していくべきでは。
       ⇒確かに:今回は事前想定とは展開が違ったが、動的にワークの構成を変えれば良かった。[進行役]
       ⇒前回は「初体験なので、各人が興味の強いテーマで自由に設定して欲しい」を重視した。
 
 ・Try
   ・次回以降のワークの流れ・目的の説明を加えて、先々を見通せるようにする。
   ・無理のない範囲で、なるべく数値化していく。
 
所感:
 ・折角、長い時間枠を確保したにも関わらず、企画・進行役(筆者)が動的・柔軟な判断をしなかった為に、
    ワークをより有意義にする・参加者間で影響し合って得られるはずの進行が出来なかった。
 ・初回(先月)で時間不足だった点は「案の定」だったのだが、結果的にママさんエンジニアにも参加してもらう
    ことが出来た点は良かった。
 ・進行が拙かった点は確かにあるが、「こうした方が良い!」といった意見が口々に出たのは嬉しいし良いことだ。
 
次回の予定は?:
 ・次回はカスタマージャーニーマップ。ユーザーのサービス利用体験を想定・設計する。
 ・続いてユーザーストーリーマッピング。
   ・必要な機能の洗い出しとMVPとして実装する機能の絞り込み&概算見積(工数)までワークしたい。
 
「カスタマージャーニーマップ」は、筆者もワークすら行ったことがありません。
 
メンバーの中には実務での経験者もいるので、出来れば企画補佐と進行を任せたいのだが...。
 
いろいろと事情もあるので難しいかなあ...どうだろう?
 
まあ、多少、いや結構マズイ進行をしても何とかワークとして成立させてくれるメンバー達だから、何とかなるか?!
 
いやいや、メンバーに甘えてどうする!?
と、自問自答しつつ時は刻々と過ぎて行くのでありました。
 
勉強します。


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

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

"ペルソナ"設定ワークをやってみた!

前回の(=先月の)全社定例会では、"リーンキャンバス作成ワーク"を行いました。
 
で、今回の定例会では、"ペルソナ設定ワーク"を行ってみました。
 
はじめに:
 サービスを新規立ち上げする、或いはユーザー数を伸ばすなどの施策を打つ場合において、
 "何らかのサービス価値を提供する相手"(の一定以上の規模の集合)の存在が不可欠です(当たり前ですね)。
 
 前回行ったリーンキャンバスで、先ずは形にする意義が有るか?・ビジネスになり得るか?、の仮説検証ワークを行いました。
 相前後しての実施になるのかな?、と思いますが、
 サービス提供の対象となるユーザーの仮想モデル(ペルソナ)を極力具体的に設定します。
 
 なお、今回のワークに際しては、下記のWebサイトを参考にさせて頂きました。
 
 ・サンプル(ページ下の方)
 
概要:
 仮想モデルが"共感"してくれるサービスであるか?
 そもそも、仮想モデルは現実としてのターゲット層を代表するモデルになっているのか?
 提供しようとしているサービスに合せて、都合の良いモデルを妄想で作り出しているのではないか?
 
 そういった危険性を少しでも抑える為には、ペルソナ設定以前に行っておくべき下調べ(市場調査、インタビュー、
 既に存在するデータの分析など...)を行っておくべきですが、
 今回は、"先ずは一通りのプロセス/ツールを実体験する"のが目的のワークショップですので、
 その辺の前提は敢えてすっ飛ばしました。
 ("本来ならば.."の話として、最初に話題として触れておきました)
 
 今回の定例会の出席者の中で、ペルソナ設定の経験者は2名。
 経験回数も1回のみと、まあ、殆ど無いようなものかも知れません。
 
 ワークのタイムテーブルは、↓こんな感じの想定で進めました。
 (定例会の後に、新人の歓迎会が控えているので、今日は短縮版です...。時間が足りなそう...)
 
 ・[08] 概説・サンプル(左端の数字は予定時間・単位=分)
 ・[02] グループ分け
 ・[30] 考えよう...(1人以上を設定)
 ・[15] 発表&的に絞込み
 
実際の進行:
 先ずはペルソナ設定の考え方、必要性、設定手順などの話を軽くしてから(以前にも別メンバーから話題に出されているので)
 チーム分けを実施。
 
Dsc00655Dsc00661Dsc00659  1人で1人分のペルソナを作るには経験不足&偏りが大き過ぎになりそう。迷いが大きく不安が膨らみそう。
 全員で1人のペルソナを設定すると、"誰でもない凡庸な誰か"になってしまうか、或いは全然決まらなくなりそう。
 
 ...ということで、2~3名の小さなチームを組んでもらい、B3の画用紙に10の属性を中心に設定します。
 設定は付箋に書いてもらい、画用紙は付箋を貼る為の台紙として使います。
 
 前提とするサービスは、前回の定例会で行った "リーンキャンバス作成ワーク" でディスカッションしたモノを
 中心とする方向で。
 ただし、"ぜひこれで進めてみたい!" ってのがあれば、それで進めてもらうことにしました。
 (結果的には、やはり前回話題にしたサービスから選択された)
 
 今回は全部で3チーム(参加者率が低めだったので)。
 
 Dsc00663 同じサービスを対象に選んだグループが有れば、"どちらがサービスに対するメインユーザー像に近いか?" を
 ディスカッションしてみよう。
 で、"Joy,Inc."(書籍)に出て来る "メンロー・テクノロジーズ" の手法を真似てみようかと思っていましたが、
 そもそもが(やはりと言うべきか)時間が足りずに、ペルソナが形を成す段階まで進められませんでした。
 
 なので、進行想定の最後のステップと考えていた "発表&的に絞込み" は、
 "出来た部分までのペルソナを相互に見せ合って、後で振返りで意見を言う" 形にしました。
 
Dsc00666Dsc00669 振返り:
 定例会全体と合わせて、ワークの振返りも行いました。
 
 ・Keep
   ・ワークは面白かった!(確かに、全グループがワイワイと楽しく活発に意見を出し合ってました)
   ・ワーク中にユーザーイメージが構築出来てくる点が面白い!
 ・Problem
   ・企画したサービスに合わせてペルソナを想定してしまう
     ↑企画ベースでペルソナ設定すると陥りがち:顧客の実例も見て来た(という意見あり)
 ・Try
   ・Problem:"企画に沿ったペルソナ設定してしまう"に対し、他メンバー交え複数モデルを設定することで回避。
   ・リーンキャンバスとの間で検証を回してみるのが良さそう。
 ・気付き
   ・同じサービスをテーマとしても、グループ:人に拠り設定されるペルソナが真逆の人格・性格だったりする!
 
Dsc00670Dsc00673 所感:
 前述のKeepにもあった通り、全グループがとにかく楽しそうでした。
 
 "自社サービスの企画・立上げ" に対しては、実際の所、社内的な温度差が結構あります(アンケートで判明してます)。
 
 自社サービス・オンリーにしていくという方向性ではないのですが、余りに意識がばらつくのも宜しくない。
 ワークを通じて、"楽しめる要素"(ワクワク感)を共有出来た点だけでも良かったかな、と、客観的には能天気かも知れない
 ことも考えています。
 
Dsc00677 次回の予定は?:
 
 さて、"サービス立上げの手順概要をお試し体験してみよう" シリーズのワークを続けて来ている訳ですが、
 次の段階としては、"カスタマージャーニーマップを作成してみよう" を考えています。
 
 ので、"ペルソナ設定" が中途半端のままでは、次のステップもグダグダになってしまう.....
 参加メンバーの意見により、次回定例会では "ペルソナ設定の延長:後半戦" を行うことにしました。
 (体験共有が目的なので、現時点ではスピード感は余り重視していません)
 
さて、次回の定例会は、小さなお子さんの子育て中ママさんエンジニアも参加できるよう、午前中の開催です。
途中参加になるメンバーが混じりますが、今回の "ペルソナ設定" の続きを行います。
 
果たしてどのような展開を見せるか?
 
今から楽しみです!


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

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

OKRワークをやってみた!

昨年の暮れ、11月に "プロダクトオーナーのためのOKR/KPIワークショップ #0" に参加しました。
その際のレポートも、こちらのブログに挙げさせて頂いています。
 
さて、"これは、何れ自社でやらなければいけないな..." と考えていたのですが、
なかなか構想がまとまらない.....
 
色々な視点から、様々な課題が絡み合ってしまう...
考えれば考えるほど、"やる意味無いんじゃないか?" と思えたり、
"いや!課題が山ほどあり過ぎて焦点を絞り切れないんじゃないか?"、でもそこは工夫次第なんだし、
放置する方が拙いだろう!?、とも考えられる。
 
散々悩みましたが、やるだけやってみよう!、と結論付けて2018年・年明け早々の定例会コンテンツとして
社内SNSの"定例会ページ:予定スケジュール" に予告しました。
 
さて、1/12(金)の午前中に定例会開催!
(ちなみに、午前中に実施しているのは、子育てで忙しく夜の開催だと参加できないメンバーが複数名いる
 為、"夕方⇒午前" に変更した結果です)
 
下手をすると全然盛り上がらないかな?、という危惧を他所に、
 
...盛り上がりました
 
.....と言うか、率直に表現すれば大炎上しました。
 
まあ、特に温度が上がったのは一部のメンバーと、一番冷静でなければいけない進行役である筆者でしたが...。
 
"OKR" の "O" はObjective
話題の対象として設定する最上位の目標です(1つ)。
 
"KR" は "KeyResult"。
"目標を達成したことを示す主要な結果状態"(1つ以上)です。
 
で、KeyResult を挙げ易くする為にも、目標自体の妥当性(内容と表現・意味解釈)を追検証する為にも、
"現在の状態" を挙げる必要が有ります。
 
今年度初めに社長から発表されていた中長期経営計画を絡めて展開したのですが、全体が小さな会社ですし、
ほぼ全社員が集まった状態でのディスカッションにこそ意味があると判断しました。
 
グループ長や役員を含んだ会議体、採用に関わる主管メンバーと技術者達、対外的な採用活動を主管する若干名、
それそれで、
良く言えば分担して具体的な対策と行動を進めて来た。
悪く言えば、方向転換などの際には共有不十分なまま走っていないか?と不安を感じたり...
 
同じ活動を行っているはずが、前提認識などのズレが生じていないか?、という懸念もあり。
 
多少ずれながらも走るだけ走って、結果が出た時点で認識ズレが有ったら、結果に合せて対応すればいいじゃないか!
...的な意識の者がいないか?
 
まあ、そういう動き方が正当化されるシーンも有るのかも知れません。
が、制御可能なはずのリスクを、手放しにして膨張させている気がしてならない...
 
実のところ、熱量の高い発言が有ったのは、途中経過まで含めて、比較的情報の共有度が高かったメンバーでした。
"何をいまさら!!?"
...という不満に火を点けたのかも知れません。
 
その強い発言に対して、進行役がツッコミ掛けたり、
拙いと思い方向修正しようとしてして返って迷走したり...
 
議論の途中で予定時間枠を過ぎてしまいましたが、メンバーの方から、
"ここまで突っ込んだ話をしたんだから、具体的なアクションまで落とし込みたい!" と言ってくれて、
結局は当日の他の予定コンテンツは全て無し!、ディスカッションを続けました。
 
最終的には、中間ゴールに対しての施策:具体的なアクション群と、各々の方向性や期待成果、
主管担当などを具体化し、全て白板に記載出来ました
(同内容は、議事メモとして社員専用SNS上にも残しますし、白板の写真も同一ページに上げました)
 
最終ゴールに対してのアプローチも、幾つかの選択肢の内、"これが有力なのでは!?" というものを
共有することが出来ました。
 
そして、最後の振返りの結果をご紹介しましょう。
 
Keep
 ・一時、場の雰囲気が悪くなる部分もあったが、最終的には建設的な話で盛り上がって終わって良かった。
 ・ディスカッションで、アウトプットが出たのが良かった。
  ⇒時間なので終わろうとしたところで、続けよう! という意見が出たのが良かった。
 
Problem
 ・司会の問いかけが決めつけ的:異論を言い出しにくい。
  ・オープン質問にしてほしい。
  ・雰囲気を読んでしまう…。
 
Try
 ・今後やるべきことで名前が出てきたメンバは、MBO等も含めて、成果を上げ再現可能なように意識して記録を残すこと。
 ・人材採用について、担当者達は合否基準とレベル感を合わせること。
 ・デブナイ楽しみ!
 ・司会役は十分に留意して精進する事!([○]済みません、論戦に冷静さを失いました。御免なさい)
 
Dsc005032_2 Problemは、進行役=筆者に対するモノのみでした...
 
面目ないです。 言い訳無用です。
 
進行役が、メンバーと論戦した、"問いかけ"の形式を取りながら実質的に参加メンバーの心理的安全性を脅かす言動を
とったのは、どう見ても最悪・言語道断でした。
 
にも拘らず、しっかり成果を出してくれたメンバーには感謝してもし尽せません。
進行役にもしっかりと指摘をしてくれた点も、本当に有難いことです。


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

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

SESだけどリーンキャンバスで顧客のビジネスを分析してみた!

12/8(金)の午前中に、2017年最後の全社定例会を行いました。
 
今回も、子育て中エンジニアであるメンバー達にも参加してもらえるよう、午前中の開催です。
 
このブログを読んで頂いている方は恐らく同業の方が多いだろうと思いますが、
新しいビジネスを始める際、或いは展開中のビジネスの見直しや施策を打つ場合などにも利用される
リーンキャンバスに付いてはご存知かと思います。
 
今回の定例会の中では、
SES形態で顧客先で開発・保守業務を行っているメンバーが、
顧客のビジネスを理解・分析する為にリーンキャンバスを使ってみた!

というお話です。
 
以上。
 
あ、いや、そういう訳には行きませんね。
 
とは言え、具体的な詳細を書くことも出来ません。
話題に出しておきながら、真に申し訳ないです。
 
現状のアスペアでは、顧客とコラボしてWebサイト展開・運用をしているサービスも有りますが、
売上げの殆どを占めているのはSES形態での受注・開発業務です(2次請け・3次請け~などの階層受注はゼロです!)。
 
では、リーンキャンバスなど殆ど縁が無いのか?
 
何れは自社サービスを展開したい、或いは顧客とコラボしたサービスを増やして行きたい!
 
リーンキャンバスやインセプションデッキ、伴って必要なペルソナ設定・検証、
ユーザーストーリーマッピング、カスタマージャーニーマップ、インタビューの設計と実施などなど...
 
望ましいツール/活用スキルは山ほどあります。
 
全てを自社で学習しながら身に付ける、というのも現実的じゃないかも知れません。
しかし、何が必要なのか?、特に重要な考え方・実践する為のツールはどれ?、どうやって使う・運用するのか?
 
リーンキャンバスは中核をなすツールだと思います。
これを活用するスキルは必須です!
 
Dsc00403 SES契約という契約/稼働形態の中であっても、リーンキャンバスを視点として顧客のビジネスを分析する
という使い方が有ります!
勿論、見える情報範囲には限界がありますが、アスペアで開発・保守・運用サポートをさせて頂いているのは
全てBtoCのビジネス/サービスです(勿論、フロントのみならず、バックヤードも含みます)。
 
内側から知ることが出来る情報も有りますが、外側から見える情報もある。
外側を見ている人達の認識とか利用法・感想なども参考に出来ます。
 
この↑視点でリーンキャンバスを作成してみると、それまでに意識が薄かったビジネス視点での気付きを得たり、
各種施策の意義・考え方を(幾分かは)理解出来たりします。
 
つまり、リーンキャンバスというツールで思考するストレッチになる!
 
自身が関わっているサービスへの、従来とは違った角度から理解を深めることにも役立ちます。
 
Dsc00404 以降での開発での要求事項が、何処から生じたものなのか?
ダイレクトな情報は得られないかも知れませんが、自然と関心を持てる、ビジネス視点で考察してみることが習慣付きます。
"なぜ、これを作るのか?"、"どんな顧客体験をして欲しいのか" を理解した上で開発をした方が、楽しいに決まってます!
何もしないで、"いつか、何かオリジナルのサービス作るぞー" とか言っててもしょうがない。
 
既に自社サービスを何本も立ち上げてウハウハの企業/所属エンジニアから見たら、"なーに言ってんだ?!"って感じでしょうが、
出来る準備は、色々な角度から進めて行こうと考えています。
 
顧客のビジネスをより深く体系的に理解することは、インセプションデッキを作成する場合でも活きると思いますし。
(開発側にとって都合の良いデッキばかりを作成しても、良いプロダクトは出来ないでしょうから)


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

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

スクラムマスターロールプレイ。

筆者がtwitter上でフォローしている方の中に、吉羽龍太郎氏がいます。
 
氏のtwitter上での呟きで、スクラムマスターロールプレイなるスライドが公開されていました。
 
内容を拝見してみると、まあ表題の通り、開発スタイルとしてスクラムを適用していることが前提にはなっている
のですが、必ずしも限定しなくても実務ケースでのシミュレーションとして使えるのでは?
 
.....と考えて、6月の定例会の中で60分ほど枠を取って実施してみました
(これまでにスクラム/アジャイル関係の勉強会やワークショップなど、幾つかやって来てましたし...)
 
ちなみに、同日の出席者の中で、スクラムを実務で適用していた経験者は1人のみでした。
 

研修中の新人(第二新卒的な人)もいるので、
同じく吉羽氏の作成されたスクラム概説図を使わせて戴き、用語などの要点のみ"おさらい"を最初に行いました。
 
60分の枠の中で、最初の数分を上記のおさらいに充て、残りをディスカッション形式にしてみました。
 
保険として?、反応が悪い場合に備えて、自分でもどんな回答が考えられるか?、を
可能な限り挙げておいてみました。
場が余りにも展開しないようなら、"例えば"という形で小出しにしてみようかな?、というつもりで.....
 
結果、話題に挙げられたのは最初のスライドから3つ。
 
スライドの p.5:"常態的にスプリントバックログが消化し切れない、何故か?、どうする?" に対しては、
おおよそ下記のような発言がありました。
 
スプリントの振返りの場で、全員で考える。
"完了"としているストーリーの精度も疑問がある。完成の判定基準に問題が有るのでは?
各ストーリー/タスクに対しての見積が甘く、しかも学習&改善がなされていない。
他プロジェクト等からの頻繁な割込みが有るのかも?
 ⇒割込みを抑えられえるなら抑える
 ⇒割込み対応要員を分けてしまう。←の人数は、チームメンバー数としてカウントしない。
  ⇒残業対応で賄うことはしない!
   ⇒プロダクトバックログの全数消化は無理になる、或いはプロジェクト終了日の延期の了承をもらう。
スプリントバックログの各々の単位が大き過ぎるのでは?、見積精度が下がるのを避けられない
 ⇒粒度を小さく、分割する
メンバー間の繋がりが弱いのでは?
 ⇒"個人の集まり"ではなく、"チーム"としてスプリントの完遂を担保する意識を共有できるように
勤怠が悪いのでは?
 
上記に出なかったもので、筆者の方で想定していたのは下記のようなものでした。
 
ストーリーの仕様が不明確(確認に時間が掛かる・矛盾が見付かる等)、プロダクトのinputとして不適切?
メンバー構成が拙い(スキル問題)?
スクラムの各種プラクティスの理解不足?、或いは手段が目的化している?
メンバー中の何名かが?プロジェクトを掛け持ちしている?
タスクへの分解の仕方、タスクの取り方が拙い?
 ⇒複数タスクが同時にDoing(仕掛り中)になると、生産性・品質は低下する。
 
これら↑に関しても、軽く触れてみました。
 
で、3つの課題に関してディスカッションした後に、今回のセッションに関しての振返りを行ってみました。
 
Problem:
スクラムに関して(自分達が)実戦的な理解が無さ過ぎてイメージが湧かない。分からない。
やっぱり回答例(スクラム的に望ましい現実的な例)が欲しい!
Try:
出題されたPOが余りに無能過ぎるので、そのPOのペルソナを作ってみたい。(恐らく半分以上は怒りか?)
スクラム経験者のワークを見学してみたい。
POとしての社内的な教育機会が有るべきでは?!
 
Keepに分類できそうな発言は残念ながら無かったのですが、
スクラムの実務経験が無いメンバーが殆どだった割には、ある程度のディスカッションにはなったように
思うのだけれど...手前みそでしょうかね...。
 
なお、当"ロールプレイ"を実施してみよう!、と判断した筆者の反省としては、
案の定ではあったが、実戦経験が圧倒的に足りない...
 ⇒機会が有れば、請負・自社内で作業がほぼ完結する案件で実践してみたい...
せめて事前にお題を公開しておくべきだった、かも...(タイトルしか事前告知していなかった)
 
最後に、これは言い訳がましくなるのですが、
今回の定例会には、技術メンバーの半数未満しか出席していませんでした。
(繁忙期の大所帯プロジェクトが複数、ピーク状態だったため)
 
先月も同様の状態で、5月度は定例会自体を開催中止にしたんです。
 
さすがに2ヵ月連続で中止はしたくなかったので、コンテンツを少人数でも展開できそうなモノに入れ替えて実施しました。
("実プロジェクトで利用した技術ベースでのUI・UXデモ"も予定していたのですが、勿体ないので次月に繰り越してもらいました...)
 
7月度の出席者は改善されるはず。
...と言うより、改善すべく、"定例会自体の開催時間帯を見直すべき!"、との案が出されました。
小さなお子さんの子育て中のお母さんエンジニアが何名かいて、常態的に出席出来ていないという問題点への改善も必要という事です。
 
現在、Googleフォームベースでのアンケートを配信し終わり、回答待ちの状態です。
 


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

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

"Joy, Inc." & "多動力" だあ。

6月の全社定例会議では、たまたま書籍紹介的なコンテンツが2つ重なりました。
 
1つ目は、
 
 
これは、筆者からの紹介。簡単にスライドに要約してデモりました。
 
当初は個人的に図書館で借りて読んだのですが、予想に反して余りにも面白い!
と言うか、いろいろと刺激的!
 
そのまま、あれやこれやを真似することは出来ませんが、
自社や、顧客との関係など、今のままで問題無いとは到底思えない。
小さなことから実験して、早く間違えて、早く学習することを積み上げる。共有する。
上長とかリーダーとか顧客とかに、"依存"しない。自身に問う。自分の考えを持ち、議論する。
"こうしたらどうだろう?" という仮説が非常識なものだったとしても、先ずは小さく試してみる。
・(その他諸々...)
 
色々な書籍やネット上の情報、セミナーやワークに参加してきた内容とかが、現実的に "ああ、こう活かせば良いのか" と
腑に落ちた感がありました
 
これは、この感覚を忘れてしまわない/時の中に埋もれさせてしまわない為に、是非とも書籍を買おう!
会社で買って、皆に紹介しよう!
折に触れて話題に出し続けて行こう!、と思い至りました。
 
と、読んで感化された本人は熱くなっている訳ですが、
要約だけを聞かされても、恐らくは余りピンと来ないだろうな...と思ってました。
 
Slide0609 作成したスライドの最初でも、
"出来ない、やらない、必要ない、の理由付けばかりを探さないで下さい" と敢えて書いておいたのですが、
話し終えた後の反応も概ね冷めた感じのものでした。
(これ↑は、大いに筆者の力不足によるところが大きいのだろうと思いますが)
 
まあ、とにかく部分的にでも、1人でも多くのメンバーに読んでみて欲しい。
筆者自身が、機会を探しながら試せることを1つづつでも試して行ければと思ってます。
 
さて、もう1冊の紹介は、IT-Tips(10分枠)の中で小障子さんが紹介してくれたモノ。
 
"多動力"
堀江貴文(著)
 
F1000143 自身のヒューマン/ビジネススキルを見直し補完する上でも、あれこれと書籍を当たっている中での1冊のようです。
 
アスペアには、"書籍買い放題"制度が有ります(社費で購入して、保管は個人が行う&書き込みもOK)。
が、この本に関しては自己投資として敢えて自腹で購入したとのこと。
 
気持ちの持ち方次第なので、要は有効に活かせれば良いと思います。
 
さて、たまたま書籍紹介的なコンテンツが2つになった今回の全社定例会。
 
"こういう事で時間枠が欲しいと要求するのはアリですか?" と問うてきたのは山内さん。
"是非!" と答えると、"それでは次回に30分欲しい!" と、次回コンテンツが1つ即決しました!
 
自発的なコンテンツは大歓迎です。
 


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

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

Mr.當山、研修中ですっ!

先月(4月)の頭に、同業・他分野から転職・入社してきた當山(とおやま)さん
 
アスペアで行っている、Web系(フロントからバックオフィスまで含む)開発系の技術、関連ツールやら
プロセスやら、そもそもコードのデザインとかお作法とかから社内研修を行ってます
(アスペアは基本的に必ず社内研修です。新卒の方を採用した場合に、マナー研修などを外部の合同研修などに依頼してきたことはありますが、その点だけが例外です)
 
社会人・1年経過の状態で、役割も開発の中心部にいた訳ではないので、ほぼ新卒新人と同様に研修期間は
3ヵ月間で計画を組んでます。
(主たる言語・環境は、Ruby on Rails。ある程度実戦を意識した模擬開発演習も含んでます)
 
IT系の専門学校を出ているので、基礎の基礎はOK。
 
とは言え、連日新しい学習内容の連続で、更にそれらを関連付けて理解し思考して行かないと中間課題も消化できない。
難しいです。
特に、Web系は機能を実現する上での物理層・論理層・プロトコルやら概念なども多く、言語やツール・その他周辺知識も
派生して多くなる
ので、頭の中で統合的に理解するのは、なかなかに苦労すると思います。
 
さて、そんな苦労しつつも楽しい(!?)毎日の中で、
"4/21の全社定例会で何か発表してみようか!" という、メンター役の渡辺さんからの暖かくも劇的なお言葉。
 
2017042102 自己紹介も兼ねて、早々に人前で発表するという機会を設けた方が良い!、という暖かーい親心!
素晴らしいですね!!  ステキ!
"鉄は熱いうちに打て!"とも言いますし。
 
で、全社定例会の当日での登場は、"LT(Lightning Talk) 又は IT-Tips"コーナー(質疑を含めて10分枠)
発表してくれたのは、"ATOMエディターの紹介"でした。
 
業界内の方ならご存知の方も多いかと思いますが、
オープンソースのテキストエディタで、Linux, MacOS X, Windows 上で動作する。
プラグイン拡張が容易で、多数のパッケージが公開されている。
デフォルトは英語ですが、日本語化パッケージを導入すればベタな日本人でもOKっ!です。
 
ライセンスフリーのエディタとしては、Microsoft の Visual Studio Code が存在感を増しつつありますが、
さすがの多機能・Visual Studio のノウハウを詰め込んであるだけに、ちょっと遅い...という声も有りますね...。
 
ATOMより軽量のエディタも有るようですが、オープンソースでマルチプラットフォーム対応、拡張パッケージが豊富な点などから
ATOMを選んだようです。
 
HTMLの基本構文の理解と演習の際に、構文に応じたハイライト表示や、入力時のオートコンプリート機能などが
学習効率を上げてくれる!(タグの閉じ忘れなどもある程度防止できる)、ということで、便利・便利!
 
"便利"が過ぎると学習効果が損なわれる場合も有りますが、余りに単純な部分に手こずって時間を潰すのは
勿体ないですし、"生産性が低い状態に慣れてしまう" のも絶対に避けたい点です!
 
トツトツとした當山さんの進行と語り。
緊張している様子は感じられないのですが、当然ながら慣れている訳でもなく...
 
それでも、質疑を含めて、予定時間枠の10分にジャストで収まりました!
おお!、素晴らしい! (←定例会の最後の振返りで、Keepとして他メンバーが挙げてくれました!)
 
多少の苦労をしてでも、なるべく社会人経験の少ない内に、いろいろと経験しておくのは良いことです。
 
勿論、オーバーフローで心身の調子を崩すようなことは避けるべく、メンター&周囲のバックアップを含めて
声掛けしたり、お昼時の雑談などでフォローしてくれています。
 
さてさて、入社1年後にどんな活躍を見せてくれるか?
活躍できる機会を設定できるのか?、とも言えますね
今から楽しみです。
 


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

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

2016年度:"ステキ!" 大賞は??

弊社:アスペアの期は3月始まりです。
 
さて、他社の多くがそうでしょうが、アスペアも自社社員専用のWebサイトがあります。
某CMSを利用していますが、プラグインを自社開発して、他メンバーの書込みに"ステキ!"を投票出来るようになってます
 
で、年度を通じて"ステキ!"獲得数の多い順に、金・銀・銅メダルを授与してます!
(これは2014年度から始めたので、2016年度(~2016/02末)で3回目となります)
ちなみに、賞金とかは有りませんが...(名誉こそが最大の懸賞ですよねっ!!?)
 
2016年度の金賞は忠さん
("忠さん"ってのは、社内で同じ姓の人が4人もいるので紛らわしい!ってんで、名の頭文字を呼称にしているのです)
 
獲得票数、175票。
 
投票者は社内の人間だけで20名そこそこですから、結構な数です。
 
CMSに全社員が書き込むのは、主に週報
1人・1年間に50回ちょいですね。
 
アスペアでは、週報は"上長に出す"モノではなく、"全社員に共有するモノ"なんです(ブログ機能で、即時共有されます)。
 
なので、日々の業務で得られたTipsとか、状況判断・行動・結果とか工夫とか(痛い目を見たとか)...
 
顧客の守秘義務に触れるような情報は勿論書きませんが、普遍的なこと、特定顧客やプロダクト/プロジェクトに
依存しない事などは共有します。
 
別の場所で業務をしているメンバーであっても、ある程度の情報を共有し、間接体験をすることが出来ます
興味を惹かれれば、コメント機能で質問したり、フォロー発言したりもOK
 
他にも、体調&モチベーションを数値表現します(1~5で、大きい数ほどGood!状態を表す:ニコマーク付き)、
業務とは全く関係のない事も書いてOK!(SNS的な要素とも言えますが)
 
ここに、この1週間で読んで面白かった本とか、参加したイベントとか旅行先とか、
独習・検定試験向けの学習状況を申告して自分自身を追い込んだりとか、
家族(お子さんとか)の何気ない事を書き添えたり...
 
週報としての基本の項目セットが有るのですが、書きたいことが書けるように改訂されてきました。
 
チャットツールとしてはslackを利用してます(Standardコース)し、大変に便利!なのは確かですが、
CMS、電子メール、それぞれの特性があるので、
要は使い分けだと思います。
 
で、話を戻すと、2016年度の金賞の忠さん。
2014年度は銅、2015年度は銀、そして次は金!と、着実に獲得票数を伸ばして来ました!
凄い!
 
本人の弁護の為に書いておきますが、決して業務が暇なわけじゃありません。
それどころか、ロールの数も多いし、重いロールも複数抱えている。
タスクの数たるや、半端じゃありません!!
 
稼働時間制限をかけながらの業務とは言え、定時帰宅ではないし、時間密度は恐ろしく濃いはずなのに...
 
最近では、簿記2級の受験準備、スパルタンレースの参加準備などが熱い話題です!
(プロジェクト的にも熱くなってきているようですが...←こちらは心配...)
 
さて、2017年度はどうなるのだろう?
 


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

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

帰って来た "偏愛マップ"!

4月の全社定例会は、4/21(金)。
 
通常は毎月・第2週を目途に開催しているのですが、数ヶ月間・定常的に毎月-第2週の金曜が
都合がつかない(定例会に参加できない)メンバーが発生したので、その間は開催タイミングを1週間ずらすことにしてます。
 
さて、4月に入って、中途採用者が1名パート契約のママさんエンジニアが1名入社しました。
 
「それじゃあ、久々にやってみるか!」ってことで、やってみました。
『帰って来た、偏愛マップ』ワークショップ
 
前回実施したのは2年前(2015年)の9月ですので、1年7ヵ月振りです。
http://aspire.way-nifty.com/majime/2015/09/post-a423.html
 
"偏愛マップ"は、特にアジャイルな開発プロセスなどには限定されず適用可能なアプローチで、
主にチームビルディング初期に行うと効果的、なものです。
 
が、今回のように新規参画者がいるときにも、手っ取り早くお互いのコミュニケーションを
自然で滑らかなものにしたい場合などにも良い
と思います。
 
ここ数年、IT業界関連で盛んに話題にされるようになった"心理的安全の確保"の為にも、
自社内にどんなメンバーがいるのか?
業務以外のことでも気軽に話題にすることが出来れば、余分な緊張感も減りますし、
心理的な障壁も低くなるはず
ですね。
 
前回のワークに参加したメンバーも、既に19ヵ月も経っているので内容のバージョンアップ?が可能なはずだし、
そもそも前回のワークに参加できなかったメンバーも数名います。
ちょうど良いタイミングでしょう。
 
ってことで、一応、"偏愛マップ"の実施目的・内容・進め方などを一通り説明してから、ワーク開始!
 
20170421042017042105 2017042103
2017042106"書きたくても漢字が思い浮かばない..."という職業病者が続出していたり(⇒ネット検索しまくり)、
"前回の内容から変わってないから、前回のを見ながら描く!"なんてメンバーもいれば、
"絵を描いてみたけど、サイトで確認したら全然違ってたよ"、とか、
"アレは封じる!"、とか、怪しげな発言が飛び交ったりもしてました。
 
なお、前回のワークでの問題点として、
"用紙がB3ではちょっと小さ過ぎた"、
"コピー用紙を使った為に、裏写りした(水性マーカーだったので机の汚れは残りませんでしたが)"、
...などが有ったので、今回は大き目の用紙で、材質も画用紙にしました。
 
絵を描けるように、マーカーもなるべく多色を用意しましたが、ちょっと時間が足りなかったか...
(そもそも、絵心のあるメンツが少ないってのも有るのかも知れません)
 
2017042107201704210820170421092017042110 ネット上では、このような[↓]サンプルも紹介されていますが、とてもここまでは描けないな...
http://tamkaism.com/2014/06/henai-map/
https://note.mu/tamkai/m/m719115669c6b
 
ちなみに、今回の定例会後に、中途入社・新規パート契約の方の歓迎会を行いました
ので、定例会自体が短縮バージョン
 
加えて、前年度・新年度以降の方針・計画などの話が役員から展開されたので、ワークに割り当てられる時間枠が少なかった...。
なかなか難しいです。
 
2017042111 まあ、それでも、最後の振返りで"新規採用者が入った時には必ず偏愛マップやりたい!"とのKeepの声が聞けました!
 
この後の歓迎会でも、話題の繋ぎとして有効に作用した様子だったので、実施して良かったと思います。
 
前回のワークで作成したマップは、社員用Webサイトの"社員名簿"からリンクさせてますが、
今回作成した分で更新・登録しておこうと思います。
 
これは余談ですが、同ワークの司会・進行・撮影は筆者が行ってます。
ので、自分の分の偏愛マップは未だ1回も作成されてません.....
 
"見たい!、書いて下さい!"と具体的にリクエストされてしまったので、後日・自分の分も
(ワークの時と同じ時間制限で)作成して、社内公開しようと思ってます。 あはは.....
 


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

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

より以前の記事一覧