どんな仕事を？、どのようにしたいですか？

IT業界未経験の方は、タイトルのように質問されても困る事でしょう。
業界経験のある方でも、ITの対象業種・業態・その他要素によって様々でしょう。
ここでは、アスペアの現状の視点を中心としてお話をさせて頂きます。

現在のアスペアでの働き方って？

現状（2018/07/19）では、概ね下記のパターンに収まります。
・パターン1：顧客先案件に参画・全て顧客先で業務。（月1回の定例会でアスペアに帰社）
・パターン2：顧客先案件に参画・殆どは自社内で業務。（顧客先にブリッジ役メンバーがいる）
・パターン3：顧客と協業で展開しているサービスを・殆どは自社内で業務。
・パターン4：例外的な臨時稼働（養育や体調に伴う...）

現在のアスペアが／メンバーが担っているプロジェクト内での役割って？

・プロジェクトマネージャとリーダー、品質担保の推進役のスーパーマルチ（遊撃部隊？）
・運用しつつ障害対応、調査（ホワイトボックス的、RDBMS・データ含む）、設計・製造レビュワー兼務
・関連チケット群の担当（要件の詰め・調整・確認、既存調査、実装、デザインやテストチーム連携）
・町田部隊とのブリッジ役（兼務・交代・分担）
・顧客側の新人さん育成支援、非技術系プロマネのサポート、その他諸々．．．
・チケット単位で担当（OJT兼用・2017年の社会人中途入社．．．）
・顧客先のグロースハック部隊であれやこれや（詳しくは書けませんが...）

現在のプロジェクト／プロダクトでの働き方って？

・正社員として、主に顧客先でフルタイム（通常は180h/月以内・緊急時のみ調整：ピークは1～2ヶ月）
　中途入社者を含めて後輩のOJT／キャリア的な支援・育成等も適宜で分担する。
・正社員として、町田本社でラボ作業。顧客先作業のチケットを分担するか、顧客とのコラボ展開
　サービスの対応各種。基本はフルタイムだが家族状況（現状では主に育児）等により適宜で調整。
　中途入社者を含めて後輩の自社内での初期教育・立上げ・初期OJT等も行う。
・パート形態で、稼働日・時間制限しながらチケット単位で担当。
　時として、中途入社者の初期教育の支援を行うこともある。
・各物理的な場所での集合チーム毎に、アスペア社内的なグループ長（或いは必要に応じて福グループ長
　も設定）を兼任し、人事考課時の主面接者となる。

他にもやり方は有るだろう？と思う．．．

・現時点では、明示的な、俗に言う ”開発プロセス” を明示して運用しているプロジェクトは存在しない。
・スクラム的に2週を単位として幾つかのプラクティスを取り入れているケースはある。
・実態的に "1週間の反復" で、仮説・データ収集・分析・検証サイクルで稼働しているケースもある。

自社内でアンケートを採ってみました！

・詳細までは書きませんが、結構ビジネス側への関心を持つメンバーの数と要求度が高い。
・技術から完全には離れなくないメンバーが殆ど！（と言うかゼロ？：これは現実的に望ましい事です）
・自社企画サービスを打ち出すことへの各人の関与要求は、メンバーにより差が大きい。
　（この点では、全員が同じ要望を持つ必要は無いと思っています）
・前者の回答に紐づく？点もあるのか、意外と "アジャイル開発プロセス" への関心が薄いメンバーが多め
　　・この点でも個人差が結構大きい！
　　・特に自社サービス展開するなら、当然セットで必須だろ！？と考えるメンバーもいる。(一安心...)
　　・混沌の現場で揉まれているメンバーに、アジャイルへの拒否感？が感じられるような．．．
　　　アジャイルは ”行き当たりバッタリ” では無いのだが、政治的な不合理や既存資産による負債や、
　　　ビジネス要求の多さ・重さ・成長度に押されている現実が関係しているのかも．．．

"技術者" という表現が良くない！．．．のでは？

・勿論、特定の重要領域の技術で深く知識や練度を高める選択肢はあると思います。
・"技術" という言葉の対象幅が広過ぎ。と言うか、"ビジネス" を除こうとする表現に聞こえる。
・実現したい・伸ばしたいビジネスが有って、それを実現するサービス（顧客体験の提供）が必要。
　　・そのサービスは顧客第一（UX最優先！・負の体験回避を含む）であるべき！
　　・"技術" は、その ↑ 実現の為に有効だから使う・使われるモノ。（時間が経てば変わって行く...）

本当にユーザーに喜ばれる・役に立つサービスを！

・ビジネスとして成立・改善・成長させつつも、良い技術・良いチームで支えていきたい！
・その為に必要な技術は、適宜で見極めながら自分達で判断・実験しつつ取り入れていきたい！
・全員で一気には踏み出せない...。誰かが先陣を切って行く！、具体的な形は様々だけど。

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

"ペルソナ"設定ワーク（後半戦）

前回の（＝3月の）全社定例会では、"ペルソナ設定ワーク"を（全社的には）初めて行いました。

2名が実際の顧客先で、お客様側のステークホルダの方々と一緒に「ペルソナ設計」を行い、
それを元にサービスの見直し・施策の検討などを行った経験が有りますが、
「経験豊富」と表現するにはまだまだ勉強・経験・改善を繰り返して学んでいく必要がありそうです。

前回は時間枠として50分しか取れなかったので、翌月に延長実施することにしていました。
しかも90分も確保するという思い切り！？

はじめに：
概要：
　必要に応じて、前々回の記事をご覧下さい。
　同じ事を2度書いても仕方がありませんので。

実際の進行：
　前回は出席していて、今回は欠席のメンバーが1名。
　逆に、前回は出られなかったが今回は出席出来たメンバー（ママさん技術者2人＋業務都合の男性）が3名。

　 前提として「前回からの続き」なのですが、
　前回参加できなかった3名の為に、軽くワークを実施する目的や進め方の大枠を説明しました。
　前回から約1ヶ月経っているので、全員が思い出すのも兼ねて。

　で、早速チーム分けを実施しました（参加メンバーの意志任せで、私は敢えて仕切りませんでした）。

　基本は前回チームが継承されましたが、歩調を合わせる為に、未経験メンバー3名が1チームを構成する結果となりました。
　なるほど。

　「対象とするサービス案」は何にするか？
　前回は3チームで2案に分かれたので、参加メンバーの1人から
　「前回1チームだけが対象にしたサービスがあるから、それを選べば結果比較が2組出来るね」との発案。
　で、そのように対象とするサービス選定が行われました。

　今回は時間もたっぷりで余裕。
　ワイワイとじっくり話し合いながら、グループ毎に考えてもらいました。
　（A2の画用紙を台紙にして、大き目の強接着力の付箋に、ペルソナ属性を書き込みながら張っていきます）

　基本属性10種が決まったら、「現在のペルソナが置かれた状況や思っていることを文章化」して、
　サービスとの接点を探って行けるるようにします。

　で、制限時間になった時点で「相互に見せ合う」アクションに移行しました。

　ですが、ここで既に計算外が1つ。
　今回のゴールは前述の通り「現在のペルソナが置かれた状況や思っていることを文章化」するところまで。
　これを出来ていたのが1グループのみ。
　何で？

　ゴールの認識共有が甘かったか？！
　白板に書くか、ワーク告知の社内サイトに明示・最新化しておくべきだった！

振返り：
　・Keep
　　　・数字があると分かりやすくイメージし易い。グループ間でも会話が盛り上がる。

　・Problem
　　　・今回のワークは前回とそれほど変わらなかった。
　　　　　・より深く設定したものや、次につながる展開が欲しかった。
　　　・同じサービスに対するペルソナ設定ペアが２つ出来たのに、的(マト)に絞らないのか。
　　　　　・手順を経験することに意味があるとしたら、手順に沿えるように運用していくべきでは。
　　　　　　　⇒確かに：今回は事前想定とは展開が違ったが、動的にワークの構成を変えれば良かった。[進行役]
　　　　　　　⇒前回は「初体験なので、各人が興味の強いテーマで自由に設定して欲しい」を重視した。

　・Try
　　　・次回以降のワークの流れ・目的の説明を加えて、先々を見通せるようにする。
　　　・無理のない範囲で、なるべく数値化していく。

所感：
　・折角、長い時間枠を確保したにも関わらず、企画・進行役（筆者）が動的・柔軟な判断をしなかった為に、
　　　　ワークをより有意義にする・参加者間で影響し合って得られるはずの進行が出来なかった。
　・初回（先月）で時間不足だった点は「案の定」だったのだが、結果的にママさんエンジニアにも参加してもらう
　　　　ことが出来た点は良かった。
　・進行が拙かった点は確かにあるが、「こうした方が良い！」といった意見が口々に出たのは嬉しいし良いことだ。

次回の予定は？：
　・次回はカスタマージャーニーマップ。ユーザーのサービス利用体験を想定・設計する。
　・続いてユーザーストーリーマッピング。
　　　・必要な機能の洗い出しとMVPとして実装する機能の絞り込み＆概算見積（工数）までワークしたい。

「カスタマージャーニーマップ」は、筆者もワークすら行ったことがありません。

メンバーの中には実務での経験者もいるので、出来れば企画補佐と進行を任せたいのだが．．．。

いろいろと事情もあるので難しいかなあ．．．どうだろう？

まあ、多少、いや結構マズイ進行をしても何とかワークとして成立させてくれるメンバー達だから、何とかなるか？！

いやいや、メンバーに甘えてどうする！？
と、自問自答しつつ時は刻々と過ぎて行くのでありました。

勉強します。

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

「名付けのススメ」について

恐らくはアジャイル辺りで特に盛んに言及されるようになったと認識しているのですが、

「プロジェクトや、成功・失敗パターン等にまで名前を付ける」、「その名前で対象を共有し扱う・対処する」って多いなあ、と。

友人とか親しい人にも、名前ではなくニックネームを付けたり、既に決まったものが有ればそれで呼んだり。

（まあこれは、「短縮化する」って意味もあるのでしょうけど...）

「外人さん（主に米国人？）って、あだ名付けるの好きだよなあ」程度の感覚でした。正直を言って。

でも確かに、対象（特に「事象」という形の無いもの）に名付けようとすると、それに付いて考えるし、

名が付くことで実態化する・感覚共有の糸口が掴めるみたいな部分は大きいと思うようになって来ました。

ソフトウェア開発に於ける「UML」みたいな効果もあるのかなあ、と。

現在、たまたま、書籍：「影響力の武器」（第三版）を読んでいるのですが、

「対象に対して自らの意志と思考・選択で名付けることにより、自らの意志で関り続ける」っていうコミットを

したことになるんじゃないかな！、と思うに至りました。

チームの皆で話し合って決めれば、「チームとしてコミットした」ことになる（認識を共有できる）。

だからこそ、コミットした意志と選択を維持しようとする無意識の力が働いて「能動的に関わり続ける」力に

なるのだと考えられます。

他人事ではなく、「チームの全員・各人が、自分のこととして真剣に考えて論じ合う」姿勢と行動に繋がるのかなあ、と。

とすると、「外人さん、あだ名付けるの好きだよなあ」は、とてつもなく見当外れで間抜けな認識であることに

気付かされます。

名付ける＝コミット、ですものね。

能動的で合意済みのコミットの力は絶大です！（書籍の受け売りですが(笑)）。

日本人（少なくとも現代人）には余り無い習慣なので気恥ずかしい気もしますが、結構大切な行動かも。

せめて自社内だけででも、一度習慣化してしまえば恥ずかしいもクソも無くなるでしょう。

当たり前の習慣になり、風土になっていく。

うん、やって行きたい！

実態としては、アスペア社内で不定期開催している「Developer's Night」（通称 "デブナイ"）も、メンバー達が名付けた名前ですね（このブログにも書いてきましたが）。

"でぶない"って響きが何だか滑稽なようで、「好きなこと好きにやろうぜ！」感が満載でイイ感じだなあと思います。

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

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

前回の（＝先月の）全社定例会では、"リーンキャンバス作成ワーク"を行いました。

で、今回の定例会では、"ペルソナ設定ワーク"を行ってみました。

はじめに：

　サービスを新規立ち上げする、或いはユーザー数を伸ばすなどの施策を打つ場合において、
　"何らかのサービス価値を提供する相手"（の一定以上の規模の集合）の存在が不可欠です（当たり前ですね）。

　前回行ったリーンキャンバスで、先ずは形にする意義が有るか？・ビジネスになり得るか？、の仮説検証ワークを行いました。
　相前後しての実施になるのかな？、と思いますが、
　サービス提供の対象となるユーザーの仮想モデル（ペルソナ）を極力具体的に設定します。

　なお、今回のワークに際しては、下記のWebサイトを参考にさせて頂きました。

　・概説
　　　https://mtame.jp/article/2016/09/14/66#n03

　・サンプル（ページ下の方）

　　　https://digital-marketing.jp/marketing-general/persona-setting/#i-7

概要：

　仮想モデルが"共感"してくれるサービスであるか？
　そもそも、仮想モデルは現実としてのターゲット層を代表するモデルになっているのか？
　提供しようとしているサービスに合せて、都合の良いモデルを妄想で作り出しているのではないか？

　そういった危険性を少しでも抑える為には、ペルソナ設定以前に行っておくべき下調べ（市場調査、インタビュー、
　既に存在するデータの分析など...）を行っておくべきですが、
　今回は、"先ずは一通りのプロセス／ツールを実体験する"のが目的のワークショップですので、
　その辺の前提は敢えてすっ飛ばしました。
　（"本来ならば.."の話として、最初に話題として触れておきました）

　今回の定例会の出席者の中で、ペルソナ設定の経験者は2名。
　経験回数も1回のみと、まあ、殆ど無いようなものかも知れません。

　ワークのタイムテーブルは、↓こんな感じの想定で進めました。
　（定例会の後に、新人の歓迎会が控えているので、今日は短縮版です．．．。時間が足りなそう．．．）

　・[08] 概説・サンプル（左端の数字は予定時間・単位＝分）
　・[02] グループ分け
　・[30] 考えよう...(1人以上を設定)
　・[15] 発表＆的に絞込み

実際の進行：

　先ずはペルソナ設定の考え方、必要性、設定手順などの話を軽くしてから（以前にも別メンバーから話題に出されているので）
　チーム分けを実施。

　1人で1人分のペルソナを作るには経験不足＆偏りが大き過ぎになりそう。迷いが大きく不安が膨らみそう。
　全員で1人のペルソナを設定すると、"誰でもない凡庸な誰か"になってしまうか、或いは全然決まらなくなりそう。

　．．．ということで、2～3名の小さなチームを組んでもらい、B3の画用紙に10の属性を中心に設定します。
　設定は付箋に書いてもらい、画用紙は付箋を貼る為の台紙として使います。

　前提とするサービスは、前回の定例会で行った "リーンキャンバス作成ワーク" でディスカッションしたモノを
　中心とする方向で。
　ただし、"ぜひこれで進めてみたい！" ってのがあれば、それで進めてもらうことにしました。
　（結果的には、やはり前回話題にしたサービスから選択された）

　今回は全部で3チーム（参加者率が低めだったので）。

　 同じサービスを対象に選んだグループが有れば、"どちらがサービスに対するメインユーザー像に近いか?" を

　ディスカッションしてみよう。
　で、"Joy,Inc."（書籍）に出て来る "メンロー・テクノロジーズ" の手法を真似てみようかと思っていましたが、
　そもそもが（やはりと言うべきか）時間が足りずに、ペルソナが形を成す段階まで進められませんでした。

　なので、進行想定の最後のステップと考えていた "発表＆的に絞込み" は、
　"出来た部分までのペルソナを相互に見せ合って、後で振返りで意見を言う" 形にしました。

振返り：

　定例会全体と合わせて、ワークの振返りも行いました。

　・Keep
　　　・ワークは面白かった！（確かに、全グループがワイワイと楽しく活発に意見を出し合ってました）
　　　・ワーク中にユーザーイメージが構築出来てくる点が面白い！
　・Problem
　　　・企画したサービスに合わせてペルソナを想定してしまう
　　　　　↑企画ベースでペルソナ設定すると陥りがち：顧客の実例も見て来た（という意見あり）
　・Try
　　　・Problem:"企画に沿ったペルソナ設定してしまう"に対し、他メンバー交え複数モデルを設定することで回避。
　　　・リーンキャンバスとの間で検証を回してみるのが良さそう。
　・気付き
　　　・同じサービスをテーマとしても、グループ：人に拠り設定されるペルソナが真逆の人格・性格だったりする！

所感：

　前述のKeepにもあった通り、全グループがとにかく楽しそうでした。

　"自社サービスの企画・立上げ" に対しては、実際の所、社内的な温度差が結構あります（アンケートで判明してます）。

　自社サービス・オンリーにしていくという方向性ではないのですが、余りに意識がばらつくのも宜しくない。
　ワークを通じて、"楽しめる要素"（ワクワク感）を共有出来た点だけでも良かったかな、と、客観的には能天気かも知れない
　ことも考えています。

次回の予定は？：

　さて、"サービス立上げの手順概要をお試し体験してみよう" シリーズのワークを続けて来ている訳ですが、
　次の段階としては、"カスタマージャーニーマップを作成してみよう" を考えています。

　ので、"ペルソナ設定" が中途半端のままでは、次のステップもグダグダになってしまう．．．．．
　参加メンバーの意見により、次回定例会では "ペルソナ設定の延長：後半戦" を行うことにしました。
　（体験共有が目的なので、現時点ではスピード感は余り重視していません）

さて、次回の定例会は、小さなお子さんの子育て中ママさんエンジニアも参加できるよう、午前中の開催です。

途中参加になるメンバーが混じりますが、今回の "ペルソナ設定" の続きを行います。

果たしてどのような展開を見せるか？

今から楽しみです！

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

"リーンキャンバス"をネタにワークをやってみた！

2月の全社定例会は2/16に実施しました。

ここ最近は、ママさんエンジニアの参加率向上の為に午前中開催を続けて来ましたが、
今回は定例会の終了後に "Developer's Night 2018/02" を実施する ＆ 所要時間が読めないため、
通常パターンでの夕方から（17:00～）の開催としました。

毎度書いていますが、アスペアの定例会は勉強会・ワークショップやディスカッション、ナレッジ共有系の
コンテンツ展開が中心になっています。

この↑点では、今回のテーマは"リーンキャンバスを書く＆皆で揉んでみよう！"でした。

事前に、全社員から "各人が100個を目標に、サービスのアイデアを挙げてみよう！" ということで、
Googleスプレッドシートでフォームを提供・共有すると共に、
シートを各人で増やして（同一ファイルを共有したままで）、キャンバスを書いてみる。

．．．という形で準備しておきました。
（リーンキャンバスに関しては、実際の顧客ビジネスを例として事前に定例会コンテンツとして展開済みです）
（...ので、基本的な書き方は、その際の定例会議事メモを見れば大体分かる、という仕掛けになってます）

さて、事前に（パート勤務のママさんエンジニアも含めて）全員にキャンバスを書いてもらいました。
（今回の目的の１つが "とりあえず全員が、迷いながらでも一度は自力で書いてみる" でしたので）

取り上げるサービス案は、各々が自由に選択可能としました。
自分で既に挙げたもの、他メンバーが挙げて"面白そう"と感じたもの、既存のサービス、その他何でもOK。

じゃあ、具体的に、定例会の中で誰のキャンバスを元にディスカッションするか？
どうやって決めれば良いか？

実は、この間に並行して、全員にアンケートに回答してもらっていました。

"自社サービス"・"スタートアップ" に対して、自分の中にどの程度の熱量があるのか？
（関連して、実質的にセットで必要となって来るはずの"アジャイル系"の認識などもサンプリングしました）

今回のディスカッションで取り上げるキャンバスは、上記のアンケートの結果を見て "熱量が比較的高いかな"、と
見られるメンバーが作成してくれた物を取り上げることにしました。
（実際、内容を見ても興味深いものだと感じたので）

リーンキャンバスの作成・ワークショップ等は、企画・開催している筆者自身も初めてですし、
実務で作成した経験者も（正直を言えば）現時点では社内にはいません。

出来れば経験豊富な方を外部から招いてでもワークショップを開催すべきだったのでしょうが．．．
まあ、とにかく出来る範囲で進めてみます。

"果たして、活発な論議に至るのだろうか？"、"盛り下がったままで終わったらどうしよう" とか、
いろいろと悶々としましたが、"考えるより動いてみろ！（失うものより学ぶことの方が大きい！）"。

結果的には、進行役（出来ればファシリテーターとして動きたい）である筆者が発言する必要性は殆ど無く、
最初のとっかかり部分のみ（前述の部分）で、後はもうどんどん意見が出て勝手に進んでいく！

筆者がやったのは、ディスカッションの進行に追い付くために必要な資料の表示（プロジェクターへ）とか、
時間枠を大幅に過ぎたので、頃合いを見て今回の締めに移行した位でした。

"リーンキャンバスを使って行うべき、想定ビジネスの考証" という点では明確な（中間）結論にも至りませんでしたが、
"リーンキャンバス" というツールを使って、
・それまでに必ずしもメンバー間で共有されていなかった知識やナレッジの共有、
・視点が違うメンバー間のディスカッション、
・話し合う中で生まれ出て来るアイデアの交換と、そこからの話題の展開、
・或いは外国籍のメンバーの意見・見識も交えてビジネス的視点からの価値を考えられたこと、

．．．いろいろと成果は有ったのではないかと思います。

"これでリーンキャンバスがバッチリ使いこなせる！" なんてことは有り得ませんし、
そもそも仮説検証・思考実験の方法は様々にありますし、それらを駆使したからと言って経験値に乏しい我々だけで
現実のスタートアップを成功させられる可能性は、正直を言えば少ないでしょう。

しかし、各人が従来よりもビジネス寄りの視点を持つ機会、ツールを幾らかでも使った経験、
ディスカッションで盛り上がれる面白さを体感した、
というだけでも、とりあえず今回の企画意図としては、どうにか目的を達成したと言えると思っています。

さて、次回の機会では "ペルソナ設定" を想定しています。
今回ディスカッションしたリーンキャンバスから設定を試みようと思っています。

そして、その次は "カスタマージャーニーマップ"。
直前回で設定したペルソナを利用するつもり。

更に次は、"ユーザーストーリーマッピング"。
次に、"ユーザーインタビューの設計"。

月に1回のペースなので決して早い学習とは言えないのですが、会社として予算をプールするにも時間が要ります。
外部の協力者を要請する為にも予算が必要ですし。

外部の協力を得るにしても、一通りのツールの運用の仕方・考え方・触り程度であれ実体験をしておいても、
決して損は無いと考えています。

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

ユーザーストーリーマッピングのワークに参加して来た！

1/24(水)の夜に、ユーザーストーリーマッピングの公開ワークショップに参加して来ました。

自社サービス／顧客とコラボしてのサービス展開などの際に必要なツールの1つとして、社内的な知識の共有と、

実戦で使うためのナレッジを得たい！・社内でワークショップをやりたい！

．．．ので参加させて頂いた次第です。

ファシリテーターはギルドワークスの中村 洋 氏。

twitterではフォローさせて頂いていますが、ご本人にお目通りする？のは、これが初めてです！

当日は、大変お世話になりました。

下記のレポートは、筆者自身の言葉への置き換えやメモが含まれていたりしますのでご了承下さい。
また、認識齟齬・誤植などありましたら、ご指摘頂ければ幸いです。

参加コンテンツ名／講師／機関

　ユーザーストーリーマッピングを使って、要求の全体像を把握しよう
　　ギルドワークス：中村 洋 氏 （大阪高知のご出身で通常は関西方面でご活動）

　　参考URL：
　　　・簡単！楽しい！5分でわかるユーザーストーリーマッピング(User Story Mapping) - Qiita
　　　・ユーザーストーリーマッピングをやってみました | eureka tech blog

実施日時

　2018-01-24（水） 19:30 - 21:30

実施場所

　合同会社ねこもり 秋葉原オフィス
　　　東京都千代田区外神田2丁目15-8 長坂第三ビル 3F

満足度

　95点～
　　(0～100点満点、時間分の価値がどうにか有った＝60点、概ね満足＝80点)
　　内容は、各IT企業にコーチングやファシリテータ、コンサルとして現役であり、講演や執筆も数多くこなす方だけに申し分ない。
　　"もの凄い" と感じさせずに、着実に参加者が結果を出せるように企画準備・臨機応変に方向転換・褒める ⇒ 本人達もびっくりの結果が出た。

概要・所感

　10名枠に、結果的に8名参加。
　　・キャンセルの嵐で、キャンセル待ちの方々への連絡するも10名全ては来ず。
　　・開始時刻を5分遅らせて、更に数分の遅刻者若干名で、4+4名の2チーム構成でワーク。
　　・最初に、講師から参加者の実務ロールや、今回参加の目的・期待などを聞かれる。
　　・ユーザーストーリー・マッピングの実務での作成経験者はゼロ。
　　・開発者(一番多い)、デザイナー、学びの場の提供者(＝今回会場の提供者)、私、に分類される。（年齢層：20代～40歳前後？、私(57)）
　　・前回は、"ユーザーストーリーの抽出" だったらしい（連続で参加している人に聞いた）
　　・私が1番最初に会場入りしたが、関係者間の雑談(主催者側の経験)が面白かった。

.

.

.

　スライドでざっと説明

　　ユーザーストーリー・マッピングの主要目的
　　　・プロダクトの設計
　　　・ユーザーのワークフロー
　　　・リリース計画
　　（Jeff Patton 氏が考案した手法）

　殆どの時間を占めるワーク

　　"DoorKeeper"（学習コンテンツ･サイト）のユーザーストーリー・マッピングを作ってみよう！
　　　・出来たものは、そのままカンバンボードとして使える＝通常
　　　　・開発の済んだものにマーク付けしたり　←(進捗見える化)
　　　・今回は上段から順に作成した；下段に行くに従って、上段の不足に気が付く場合も；"行ったり来たりが当たり前"
　　　　・各段を終える毎に、2グループ間で見せ合う。

　　通常なら半日で "相対見積まで完了" する場合が多い。
　　　・見積：各機能毎に、相対ポイントで表す。最大の場合、最少の場合、両方の数値を出しておく。（表形式でOK）
　　　・実際に開発を回し、ベロシティ（生産性：1反復で何ポイントの開発を完了させられるか？）を計測　⇒　計画を見直し
　　　・ベロシティ自体が不安定な場合は、別の話題へ...

　　全体を通して："各人が勝手に付箋を書く" シーンが無い
　　　・必ず話し合いながら、付箋を紡ぎ出していく感じ。（全付箋に全員がコミットしてる感じ）

　振返り

　　各チームで軽く発表。

　　個人的には、頭の回転速度が追い付かず、手も余り動かせずで申し訳ない限り．．．

　　しかし、どうにか社内ワークショップを行うための最低限の体験・知見は得られたのでは？、と思います。

　　他の方がKeepとして仰ってましたが、"設問設定が良かったのでアウトプットし易かった"点も大きい。

　　恐らくワーク中の自分達には計り知れない、中村氏の経験・知見・暗黙知が総動員されてこその

　　ワークショップ成功なのだと考えます。

　　果たして、社内で実施して、参加メンバーにどれだけ好感触を持って貰えるか？．．．

　　とりあえず頑張ります！　先ずはやってみなくちゃ！

ナレッジ

　・先ずはミニマムな（＝基本・ノーマルケース）行動セットで考え始める方が良い。
　　　・いきなり詳細から掘り始めると、進まない。完結出来ない。時間の無駄。"全体を押さえたい"目的に反する。
　　　・たまたま思い付いた、細かいけど重要そうな事項は、とりあえず付箋に書いといて後で何処かに配置する・或いは色を変えて／表現し直して利用する、かも。
　　　　　・"それは後にしよう" で書かないと忘れ去られる...

　・大きなボードが必要！
　　　・今回も、1チームは長机2つでほぼ一杯（3.5m位？）、1チームは壁を利用（3m位？）

　・通常は対象ユーザーや、サービスの運営に関わる人達に事前インタビューする（どんな使い方しますか？／してますか？、とか...）
　　　・特に、開発者オンリー、1～2人で作るといきなり小機能レベルのキーワード／話題になったりし安い
　　　・利用者の目線ではなく、システム目線に陥りがち。

　・参加メンバーの選定は重要！
　　　・当該サービスで実際に役割を担う関係者(若しくは同部署の人間とか..)が参加すると、現実からの乖離を防ぎやすい。

　・付箋に書くのは、"人間の行動"・"人間が受け取る何か"（或いはシステムの粒度の大きな挙動）
　　　・"～する"・"～できる" の動詞で書く；"◯◯機能" とか書くのは良くない（特に上段では絶対ダメ！）

　・出来たマップを検証する
　　　・頭から順番に見直して、最後まで行き着くか？　途中で当該機能が無かったり、論理的破綻してないか？

　・出来たマップから、"MVP"(Minimum Viable Product) 的な選択をする（スタートアップのシミュレーション）。
　　　・現実なら、前提基準として共有しておくべき事項を "インセプションデッキ" などの形にしておく。
　　　・"大きな目的"・"そもそも論" から離れてしまわないように；手段が目的化してしまわないように

　・付箋の色変え：
　　　・画面系／バッチ／操作に対するシステム挙動...などは、色を変えた方が分かり易い。（或いは、付箋の隅に色違いのマークを貼り付けるとか．．．）

　・マップに "漏れ・抜け"(或いはダブり)は付き物。
　　　・元々が "全体を俯瞰視する"・"先ず始める為のモノ" である。
　　　・開発に入って 2～3週で、マップを見直す（問題に気付いたら適宜？！）。
　　　・マップの見直しは繰返し行うこと（成果物と乖離するとか、既に破綻してる証拠）　[重要]

　・マネージャとか役員に説明し易い；って言うか、これ見てね！で済む。
　　　・（"間に合いそうなのか？" とかは別の資料が必要になるが...）

　・マップ上の空白部分；何で空白なのか説明が付くか？...など、見えて来る。

　・付箋に書く文言の粒度・用語の認識共有の問題
　　　・表現の揺らぎは危ない；統一する
　　　　　・（用語とか、定義を付箋で別枠に貼っておくべきかも）
　　　・逆に言えば、認識合せのチャンスにもなる（認識齟齬の部分が明らかになる）　←(実際に結構多い)

アンチパターン

　・バッチ処理・移行の際に、顧客が "それ必要だから残して！"
　　　マップ内に存在する？；入る必然性が有る？　⇒　無かったら、"要らない機能ってことですよね？" と言えるかも。

　・1人でずっとマップの作成・保守を行う
　　　現実と乖離したまま気付かずに先に進んでしまいがち

　・付箋の書き出しを書く個人の判断で行う
　　　時間はかかるが、話し合いをしながら1枚づつ書込み・貼り出す。（前述）

　・マップ作製のメンバーのロールを固定する（ロール分布の狭い状態で）
　　　参加できないメンバーでも、チェックを頼むとか必要。

　・議論が白熱して、1ヵ所を深堀しまくって、全体が進まない
　　　完璧を求めない；絶対無理と割り切る；振返る機会を持ち続ける（前述）

　・上段の議論中に、いきなり機能名が出て来る

　・組織の偉い人が参加する
　　　心理的安全(圧力)が無い状態でないと、あるべきマップにならない。

　・マップをコミット扱いにしてしまう；されてしまう
　　　"始める為のモノで、不完全だよ！" を十分に周知する
　　　ウォーターフォールの見積用に使うなど、言語道断！

　・不必要なデバイス利用を想定内に入れてしまう
　　　スマフォだけ対応すれば良いはずのサービスに、PC版の機能を計画：膨大な工数食って無駄死にしたり...

質疑応答

　Q.カスタマー・ジャーニーマップは完全に時間軸に沿って書くが、ユーザーストーリー・マッピングはどの程度時間軸に従う？
　A.目的が"要求の整理"・"開発に入る為のモノ"なので、ユーザーストーリー・マッピングは完全時間順ではない。
　　カスタマー・ジャーニーマップはUX設計の一環で行われるが、ユーザーストーリーでは人間の感覚・体験は考慮しない（行動は対象に含む）。
　　システム側で機能を伴わない "人間の行動" も書いて良い（システム側は"何もしない"ことを明示できるから）。

　Q.漏れ・抜けが心配
　A.完璧を目指さない；"抜けは必ず有る" 前提でチェックのタイミングを事前計画に入れる

　Q.非機能要件とかは？
　A.このマップでは直接的には出て来ない。が、考える元ネタとしては使える。
　　非機能要件を考えるのは、別の切り口で、別の機会を設ける。

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

イノベーション系セミナーに参加した！

1/17(水)の夜に、セミナーに参加して来ました。
編集系の話題が含まれているにも拘らず、編集レベルが限りなく低い記事で大変恐縮なのですが、
巧遅よりも拙速を以て良しとする．．．と勝手に決め付けてアップさせて頂きます。

三津田氏のパートは、先日受講させて頂いた内容のダイジェストでしたので、記載は少ないです。

小関氏のパートでは、非常に同感できる部分が多かった！
ここ2ヶ月ほど考え・悩んできた結果の自分なりの結論と、理論的にも共感もできる内容でした。
また、実践しよう！・試してみよう！と思うことが多く、素晴らしい内容でした！

講師のお2人とも、良い機会・気付きと喜びの時を戴き、本当に有難う御座いました！

下記のレポートは、筆者自身の言葉への置き換えやメモが含まれていたりしますのでご了承下さい。
また、認識齟齬・誤植などありましたら、ご指摘頂ければ幸いです。

参加コンテンツ名／講師／機関

　伝える力がイノベーションを起こす、ビジネスと人材を変革する言葉のマネジメント入門」～第2回分科会：本とITを研究する会セミナー～
　小関 伸明 氏 (ビリーブロード株式会社)／三津田 治夫 氏 (「本とITを研究する会」代表)

実施日時
　2018/01/17(水)-19:00～21:00(～21:15)

実施場所
　ビリーブロード株式会社：オフィス（9F）（岩本町）

満足度
　98点
　　(0～100点満点、時間分の価値がどうにか有った＝60点、概ね満足＝80点)

概要・所感
　・前半が小関氏による、イノベーション系（ビジネスと人材を変革する）のお話
　・後半が三津田氏による、言葉のマネジメント入門のお話（以前に受講した内容の要約版）

　・小関氏のパート
　　・知識に関しては殆ど知らない事ばかり、と言っても良いくらい。納得性の背景固めになった。
　　　・VUCA；世界中同時の状況；"長期予測は意味が無い"
　　　・起業の失敗：コミュニケーションエラーが多い（言葉の定義付けが個人によって違う・間違った伝わり方をしてしまう）

　　・ナレッジに関しては、ワールドカフェ法（事業開発の前半で必ずやる！）に強く惹かれた！
　　　・イノベーションを起こすのには対話が重要！；現場主導がイノベーションのカギ
　　　　・Visionなども、皆で作ると良い；後々で齟齬が起きにくい；共有・共感され実行され続ける

　　　・自分らしく活躍する人材を育成する、に強く惹かれた！
　　　・やりたいことは個人別に違う！

　　　・同じビジョンでも、インセンティブは個人別に違う！
　　　　・原体験が違う；共感できるか否か！・大きなキーになる！
　　　　　・↑各人が意識したほうが良い；視点の違い＝気付きの違い　⇒社の総合力のUP！
　　　　　・＝"多様性"は強い！（活かすべき）
　　　　　・未経験新人とか、下手に染まらないほうが良いね！（入社後の最初に伝えるべきだな！）

　　　・1on1；徹底的に何でも話してもらう（傾聴）；生い立ちとか何でも；話者自身が気付くのを誘発する
　　　　⇒小関氏は殆どこれ！

　　　・バリュー（行動レベルの共有基準）：そこらじゅうで見えるようにする（アナログ・デジタル何でも使う）
　　　・有言実行；Vision等に紐付かないことはしない・評価しない、というやり方もある...
　　　　・紐付く事をやたら繰り返す！・推進役が自ら実行して見せる

　　　・SECIモデル
　　　　・暗黙値が腑に落ちるか？（暗黙知(in)⇒暗黙知(out)）；そこで回らなくなる；共感がキーになる

　　　・小さく早く失敗するのが、育成に繋がる！（人もプロダクトも！）
　　　　・失敗からこそ学べる！；↑は色々な人から異口同音で聞く！

　　　・感情が動いたときにメモを残している
　　　　・意識しなかった何かが隠れている！
　　　　・ビジネスネタになったりする！

　・三津田氏のパート
　　・"書く" と "メンタル" は深い繋がりがある
　　・いま、編集の時代；経営者とかミッションとか言葉にして表現するしか無い！
　　　・編集力＝言葉と人間を動かす；今でこそ重要！

　　・Webサイト・ブログなどの編集者になりますよ！、というのが三津田氏のソリューション
　　　・適宜で小関氏と連携していく

ナレッジ
　（まとめきれない...；上記を繰返し見直しつつ、適宜で再度の気付きを得る；⇒実行する！）

質疑応答・他
　Q.Visionなどに全ての人を完全従属させるのか？、個人否定と受け取られるケースが生じないか？
　A.個人の価値観はまちまち；心理的安全性も必要じゃないのかな？！
　　対話；自己内部でも；
　　共通部分を探す；相反部分に拘らない；

　Q.本セミナーのナレッジなどを自社に持ち帰ったときに、周りの人間が同意しない場合はどうしたら良い？
　A.結局は経営トップが腹をくくって真剣にならないと。
　　小関氏が提供可能なソリューション；業務研修的に一定期間を設定し、メソッドを実行している；
　　合宿して作る企業の実例は多い

　Q.ターゲッティング：自分にとって未知の世界の住人が相手の場合にどうする？
　A.先ずは当事者に会いに行く；話をする；コミュニティに参加したり；大将の人種に"なりきって"編集をする
　　競合に調査とかもするけれど...

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

OKRワークをやってみた！

昨年の暮れ、11月に "プロダクトオーナーのためのOKR/KPIワークショップ #0" に参加しました。
その際のレポートも、こちらのブログに挙げさせて頂いています。

さて、"これは、何れ自社でやらなければいけないな..." と考えていたのですが、
なかなか構想がまとまらない．．．．．

色々な視点から、様々な課題が絡み合ってしまう．．．
考えれば考えるほど、"やる意味無いんじゃないか？" と思えたり、
"いや！課題が山ほどあり過ぎて焦点を絞り切れないんじゃないか？"、でもそこは工夫次第なんだし、
放置する方が拙いだろう！？、とも考えられる。

散々悩みましたが、やるだけやってみよう！、と結論付けて2018年・年明け早々の定例会コンテンツとして
社内SNSの"定例会ページ：予定スケジュール" に予告しました。

さて、1/12(金)の午前中に定例会開催！
（ちなみに、午前中に実施しているのは、子育てで忙しく夜の開催だと参加できないメンバーが複数名いる
　為、"夕方⇒午前" に変更した結果です）

下手をすると全然盛り上がらないかな？、という危惧を他所に、

．．．盛り上がりました。

．．．．．と言うか、率直に表現すれば大炎上しました。

まあ、特に温度が上がったのは一部のメンバーと、一番冷静でなければいけない進行役である筆者でしたが．．．。

"OKR" の "O" はObjective。
話題の対象として設定する最上位の目標です（１つ）。

"KR" は "KeyResult"。
"目標を達成したことを示す主要な結果状態"（1つ以上）です。

で、KeyResult を挙げ易くする為にも、目標自体の妥当性（内容と表現・意味解釈）を追検証する為にも、
"現在の状態" を挙げる必要が有ります。

今年度初めに社長から発表されていた中長期経営計画を絡めて展開したのですが、全体が小さな会社ですし、
ほぼ全社員が集まった状態でのディスカッションにこそ意味があると判断しました。

グループ長や役員を含んだ会議体、採用に関わる主管メンバーと技術者達、対外的な採用活動を主管する若干名、
それそれで、
良く言えば分担して具体的な対策と行動を進めて来た。
悪く言えば、方向転換などの際には共有不十分なまま走っていないか？と不安を感じたり．．．

同じ活動を行っているはずが、前提認識などのズレが生じていないか？、という懸念もあり。

多少ずれながらも走るだけ走って、結果が出た時点で認識ズレが有ったら、結果に合せて対応すればいいじゃないか！
．．．的な意識の者がいないか？

まあ、そういう動き方が正当化されるシーンも有るのかも知れません。
が、制御可能なはずのリスクを、手放しにして膨張させている気がしてならない．．．

実のところ、熱量の高い発言が有ったのは、途中経過まで含めて、比較的情報の共有度が高かったメンバーでした。
"何をいまさら！！？"
．．．という不満に火を点けたのかも知れません。

その強い発言に対して、進行役がツッコミ掛けたり、
拙いと思い方向修正しようとしてして返って迷走したり．．．

議論の途中で予定時間枠を過ぎてしまいましたが、メンバーの方から、
"ここまで突っ込んだ話をしたんだから、具体的なアクションまで落とし込みたい！" と言ってくれて、
結局は当日の他の予定コンテンツは全て無し！、ディスカッションを続けました。

最終的には、中間ゴールに対しての施策：具体的なアクション群と、各々の方向性や期待成果、
主管担当などを具体化し、全て白板に記載出来ました！
（同内容は、議事メモとして社員専用SNS上にも残しますし、白板の写真も同一ページに上げました）

最終ゴールに対してのアプローチも、幾つかの選択肢の内、"これが有力なのでは！？" というものを
共有することが出来ました。

そして、最後の振返りの結果をご紹介しましょう。

・Keep
　・一時、場の雰囲気が悪くなる部分もあったが、最終的には建設的な話で盛り上がって終わって良かった。
　・ディスカッションで、アウトプットが出たのが良かった。
　　⇒時間なので終わろうとしたところで、続けよう！　という意見が出たのが良かった。

・Problem
　・司会の問いかけが決めつけ的：異論を言い出しにくい。
　　・オープン質問にしてほしい。
　　・雰囲気を読んでしまう…。

・Try
　・今後やるべきことで名前が出てきたメンバは、MBO等も含めて、成果を上げ再現可能なように意識して記録を残すこと。
　・人材採用について、担当者達は合否基準とレベル感を合わせること。
　・デブナイ楽しみ！
　・司会役は十分に留意して精進する事！([○]済みません、論戦に冷静さを失いました。御免なさい)

Problemは、進行役＝筆者に対するモノのみでした．．．

面目ないです。　言い訳無用です。

進行役が、メンバーと論戦した、"問いかけ"の形式を取りながら実質的に参加メンバーの心理的安全性を脅かす言動を
とったのは、どう見ても最悪・言語道断でした。

にも拘らず、しっかり成果を出してくれたメンバーには感謝してもし尽せません。
進行役にもしっかりと指摘をしてくれた点も、本当に有難いことです。

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

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

12/8(金)の午前中に、2017年最後の全社定例会を行いました。

今回も、子育て中エンジニアであるメンバー達にも参加してもらえるよう、午前中の開催です。

このブログを読んで頂いている方は恐らく同業の方が多いだろうと思いますが、
新しいビジネスを始める際、或いは展開中のビジネスの見直しや施策を打つ場合などにも利用される

リーンキャンバスに付いてはご存知かと思います。

今回の定例会の中では、
SES形態で顧客先で開発・保守業務を行っているメンバーが、
顧客のビジネスを理解・分析する為にリーンキャンバスを使ってみた！
というお話です。

以上。

あ、いや、そういう訳には行きませんね。

とは言え、具体的な詳細を書くことも出来ません。
話題に出しておきながら、真に申し訳ないです。

現状のアスペアでは、顧客とコラボしてWebサイト展開・運用をしているサービスも有りますが、
売上げの殆どを占めているのはSES形態での受注・開発業務です（2次請け・3次請け～などの階層受注はゼロです！）。

では、リーンキャンバスなど殆ど縁が無いのか？

何れは自社サービスを展開したい、或いは顧客とコラボしたサービスを増やして行きたい！

リーンキャンバスやインセプションデッキ、伴って必要なペルソナ設定・検証、
ユーザーストーリーマッピング、カスタマージャーニーマップ、インタビューの設計と実施などなど．．．

望ましいツール／活用スキルは山ほどあります。

全てを自社で学習しながら身に付ける、というのも現実的じゃないかも知れません。
しかし、何が必要なのか？、特に重要な考え方・実践する為のツールはどれ？、どうやって使う・運用するのか？

リーンキャンバスは中核をなすツールだと思います。
これを活用するスキルは必須です！

SES契約という契約／稼働形態の中であっても、リーンキャンバスを視点として顧客のビジネスを分析する
という使い方が有ります！
勿論、見える情報範囲には限界がありますが、アスペアで開発・保守・運用サポートをさせて頂いているのは
全てBtoCのビジネス／サービスです（勿論、フロントのみならず、バックヤードも含みます）。

内側から知ることが出来る情報も有りますが、外側から見える情報もある。
外側を見ている人達の認識とか利用法・感想なども参考に出来ます。

この↑視点でリーンキャンバスを作成してみると、それまでに意識が薄かったビジネス視点での気付きを得たり、
各種施策の意義・考え方を（幾分かは）理解出来たりします。

つまり、リーンキャンバスというツールで思考するストレッチになる！

自身が関わっているサービスへの、従来とは違った角度から理解を深めることにも役立ちます。

以降での開発での要求事項が、何処から生じたものなのか？
ダイレクトな情報は得られないかも知れませんが、自然と関心を持てる、ビジネス視点で考察してみることが習慣付きます。
"なぜ、これを作るのか？"、"どんな顧客体験をして欲しいのか" を理解した上で開発をした方が、楽しいに決まってます！

何もしないで、"いつか、何かオリジナルのサービス作るぞー" とか言っててもしょうがない。

既に自社サービスを何本も立ち上げてウハウハの企業／所属エンジニアから見たら、"なーに言ってんだ？！"って感じでしょうが、
出来る準備は、色々な角度から進めて行こうと考えています。

顧客のビジネスをより深く体系的に理解することは、インセプションデッキを作成する場合でも活きると思いますし。
（開発側にとって都合の良いデッキばかりを作成しても、良いプロダクトは出来ないでしょうから）

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

"現役編集者による-人に伝わるライティング入門"に参加した！

役編集者による 人に伝わるライティング入門（セミナー＆ワークショップ）  に参加して来ました。

筆者はアスペアの公式ブログを書かせて頂いていますが、他のメンバーに依頼してもほぼ原稿を書いてもらえない...
良くも？悪くも、自分自身の文章の出来が、そのままブログの性格と質になっている...

不安を抱えつつ、全然自信がないままに書き続け、既に不安にマヒしかかっている自分を感じていた。
これを機会に、ワークを含めて学び、何とか改善したい・少しでも自信を持ちたいと考えて参加しました。

（このセミナーを受講して来た割には、"校正が甘い！" とお叱りを受けるかも知れませんが．．．）

参加コンテンツ名／講師／機関

　「現役編集者による 人に伝わるライティング入門」～第1回分科会 本とITを研究する会セミナー～
　　三津田 治夫 氏（Softbank：出版･IT情報メディア系、プロデューサー／コンサルタント）
　　本とITを研究する会

実施日時

　2017/12/11(月)-19:30～21:30

実施場所

　東京都千代田区神田須田町2-2-2 神田須田町ビル ビリーブロード株式会社　9F会議室

満足度

　85点
　　(0～100点満点、時間分の価値がどうにか有った＝60点、概ね満足＝80点)
　　・主題が、紙媒体を中心に据えたモノか？も危惧したが、杞憂だった。
　　・スライド公開が無い割には情報量が豊富＆有益だった。
　　・書籍にも有りそうな内容だったが、意外と今回のような網羅的･概観的なモノは少ないらしい。
　　・体系的に知ることが出来、ワークで体感も出来た。
　　・少人数での実施な上に、講師が柔和なので質問も投げ易かった。（比較的活発な質疑が有った）

概要・所感

　　要点と思われた部分（と言うより、聞きながらのメモそのまま？）を下記に抜き書きします。
　　（恐らく、端々に私個人の解釈が含まれてしまっていると思いますがご容赦下さい...）

　　・予約枠は10名だったが、欠席者無く全員が出席していた模様。

　　・今回が第１回目と言うことで、前提･基本姿勢･標準的な内容だった。

　　・応用編は、基礎編からは大幅に広がるとのことで、"編集者の領域"と表現されていた。

　　・陥りがちなパターン、心掛ける基本パターンや、ブレない基本思想が必要など実践的な内容だった。

　　・ワークは２つ。隣の席の人とワークの成果物を交換し合って講評し合うという形。
　　　　・3名以上のグループ･ワークではなかったので、思っていたよりは負担が軽かった...。

　　・講師の人柄･印象で、セッションの展開も随分と違ってくる（良い意味で）ものだなあ、と感心。

　　・参加者の自己紹介などは無かったが、隣の席の女性は "IT企業･事務職"、"日本の文化･歴史･自然が好き" 系だった。
　　　　・ワーク時に、自分から相手に質問した。ワークのアウトプットの意図が捉えられなかったので。
　　　　・"意図的な駄文の例に対して、適切なタイトルを付ける" ワークでは、自分に無い視点を相手の方が持っていたので新鮮。
　　　　・自分は、駄文の迷彩度に目が眩んでしまい、かなりキツイタイトルを考えた...
　　　　・"文章の趣旨は、通常は最後に書かれるべき"、なので、最後の段落を読めば大体わかるはず、とのこと...
　　　　　　・それでも、例文は酷過ぎて理解不能だった...（著名な方のWeb上の文章らしい）

　　・スライド情報が豊富だったが、印刷は無し、公開もしないとのこと。
　　　　・撮影して画像情報として持ち帰ることが、実質的に必須だったと思う。
　　　　　　・"後日公開します"、と言いつつ放置されるセミナーも有るので、保険として撮影は必須だと思う。
　　　　・結構読み上げてくれたので、録音でも不可能ではないだろうが...後でのテープ起こしは時間効率が悪い。
　　　　・ズームが効くカメラが必携だと思う。端の席に座ると画像が歪むし焦点がボケ易いので要注意。
　　　　・シャッター音がうるさかった。マナー違反者が多い！

ナレッジ
　　・先ずは "自分が与えたいこと" を徹底的にあぶり出す！；＝"自身のブランディング" でもある！

　　　　⇒次に、読み手にとっての価値･実現/成功可能性との表にマッピングして、"書く"ものを決める。
　　　　↑自身の掘り下げ大切！；1人合宿で籠っても良いくらい...
　　　　↑自身の軸を定める！；ブレさせないことが大切！

　　・マーケティング系の準備も必要だが、↑よりも先にやらないこと！
　　　　↑先ずは "自分が何を与えたいのか？" をジックリ掘り下げることが先決。でないと外部要因でブレる。
　　　　↑"ペルソナ" 設定は、ここでも有効なんだな！

　　・PC画面での校正はダメ！、フリッカーがノイズになってまともな判断が出来ない(医学的にも証明されている)。

　　・他人の意見は大切 ⇒ 意見を求められる人間関係を構築していくことも重要なステップ！
　　　　↑家族・友人、誰でも良い
　　　　↑一生懸命な姿勢を示せば、協力してくれる人は結構いるものだ...

　　・言いたいことを"言語化する"のは、結構難しい。
　　　　⇒昔の書籍、外国の書籍などに触れるのも、パターンを増やす糧になる。

　　・伝えたい内容に拠るが、"中高校生が読めるか？" を基準にする場合も有る
　　　　↑これを満たせば、幅広い層の誰でも読める

　　・"読み手の気分を想像しながら校正する"(視点を変えながら何度も)。相手に"痛み"を感じさせないか？、等
　　　　↑"痛み"＝心理的なストレス；酷い文章なども含む

　　・"文章は読まれない！" (←元も子もない発言だな...)
　　　　↑媒体に関わらず、改行が増えて、文字数が減っている。
　　　　↑それでも読者を惹き付ける魅力(セルフブランディング)を出来れば、読まれる

質疑応答・他
　　Q. モチベーションの維持に、何かお勧めの具体策は？
　　A. ブログを書く場合でも、チームを組むとか。相互に目的を合わせ、議論し、チェックし合う。
　　　　　 心を良い状態に保つことが大切！；悩みとか抱えていたら、まともに書けない

　　Q. 校正を学ぶのにお勧めの書籍など有るか？
　　A. ｢校正必携｣＝校正系の専門書：日本エディタースクール＝編集者の養成所
　　　　　 ↑但し、古い！；勉強にはなる！；余程興味のある人でないと極めてつまらない本だが..

　　Q. "他人の意見を聞く" ことが大切とあるが、そもそも読者がいないので反応を掴みようがないのだが？
　　A. 友人知人･家族、誰でも良い。セミナーの機会などでグループ作っちゃうとか(今回とか)。
　　　　　 ↑講師もグループに加わっても良いよ！
　　　　　 ↑人間関係を構築していくこと自体も必要なステップ

　　Q. 書き手と、読者として想定する相手との年代差が大きい。留意すべきことは？
　　A. "言語空間を共有する" は確かに大切 (世代により知らない事象･熟語･漢字)。
　　　　　 若者用語とか使うことはない (迎合する必要は無い)
　　　　　 対象者群の共通の趣味･経験、その他etc.を考慮することは必要。相手をじっくり想定して校正する。

　　Q. 面白いと感じる文章を読んだ後で文章を書くと、文体が似てしまう。どうしたものか？
　　A. それ自体は当然だし、むしろ一時的には良いこと。
　　　　　・好きな作家などいる場合、"写経"もアリ！
　　　　　　　↑プロの作家でも結構やっている。
　　　　　　　↑一旦自分の文体として習得し、自分流に崩して自分の形に昇華させていく。

　　・医師･大学教授などの行動な専門家は、まともな(一般の人が読める)文章を書けない！
　　　　↑他人から批判されることが無い；専門用語びっしり；論文形式とか

その他･資料

　　・ブログ：http://tech-dialoge.hatenablog.com

.

.開始前の室内。

少人数だったので、質問もし易かった。.

.

.

.

感想
　　・振返ってみると1000回以上もブログを書いて来たが、ただ、ダラダラと書き流して来た感じだった。
　　・1つのアプローチとして、今回教わった方法の主なモノは一通り試してみたい。
　　・校正が甘いことは自覚していたが、改めて反省させられた＆改めて恥ずかしい...
　　・自分の文章作成上のクセ・悪習慣を改めて自覚した。

　　・"他人の意見を聞く" を、現実的に難しいと決めつけていたが、何とか実践してみるぞ！と決めた。
　　　　↑ああ、自分の息子でも良いんだな！、と気付かせてくれたのは有り難かった！

　　・読書は好きだが、今まで以上にジャンルを意識的に広げようと思った。
　　　　⇒図書館に行って、いつも通り過ぎる／足を踏み入れない書架で、あまり考えずに手に取ってみようと思う。

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

POStudy："データドリブンのUXデザイン" に参加した

"データドリブンのUXデザイン ～データを活用したプロダクト開発/Webデザイン～" に参加して来ました。

今回はセミナーなので、ワークは無しです（ちょっと気がラク．．．）。

自社と顧客とのコラボで展開しているWebサイトも有りますし、今後のWebサービス･ビジネスの展開も考えていく必要があるので、

出来る限りの情報を持ち帰って社内共有する必要があります！

当日も、コンデジ、メモ用のPC、眼鏡を揃えて、いざセミナーの始まりです！

以降に、レポート（と言うかメモの転載？）をさせて頂きます。

誤解・理解不足・誤字脱字など有りましたら、お知らせ頂ければ幸いです。

参加コンテンツ名／講師／機関

　[UXアカデミー共催] データドリブンのUXデザイン ～データを活用したプロダクト開発/Webデザイン～

　　POStudy-アジャイル・プロダクト・マネジメント研究会
　　　関 満徳 氏（POStudy 主宰）

　　・『ユーザーインサイト発掘の重要性と手法』 (20分)
　　　　鈴木 郁斗 氏（UXアカデミー創業者/ディレクター）

　　・『データドリブンのUXデザイン ～データを活用したプロダクト開発/Webデザイン～』 (60分)
　　　　泉 浩人 氏（株式会社ルグラン共同CEO）

実施日時

　2017/11/27(月)　19:30～21:30

実施場所

　グロースエクスパートナーズ株式会社 G's LounGe
　　　東京都新宿区西新宿7-21-1 (新宿ロイヤルビル3階 グロースエクスパートナーズ株式会社 G's LounGe)

満足度

　80点
　　(0～100点満点、時間分の価値がどうにか有った＝60点、概ね満足＝80点)
　　・"UX"という言葉の定義自体が（自分が全く）分かっていなかった、ことが分かった。
　　・...ので、期待・イメージしていたものとは違ったが、こちらの方が新規事業の立上げ・運用にははるかに必須な要素だ。
　　　　・スコープが広過ぎて、頭に収まらない．．．
　　・サービスの立上げ・運用に関して、整理され系列だって、成熟度の段階、具体的な指標、サービス実例等を知ることが出来たのは

　　　得難い機会だったと思う。

概要・所感

　・スライドは公開されていませんので、スライド撮影画像は自社内共有のみとさせて頂きます。
　・要点と思われた部分（と言うより、聞きながらのメモそのまま？）を下記に抜き書きします。
　　　・（恐らく、端々に個人の解釈が含まれてしまっていると思います...）

　■ユーザーインサイト発掘の重要性と手法

　　・ニーズの変化・技術の変化が激しい
　　　　⇒対応し続けないとね！

　　・ユーザが触れる技術も向上している
　　・開発側も強力なツール増えてるよね
　　・革新を起こす企業＝"ゲームチェンジャー"とも呼ばれる
　　　　・既存市場で群を抜いて成長していく；Top3とか食い込む
　　　　・決して革新的な技術を使っているわけではない
　　　　・使い勝手が良い！
　　　　・ニーズの本質を把握する ⇒ 提供するサービスに反映させる
　　　　　　＝"意味的価値の提供"

　　・現行サービスを俯瞰して分析し直すことが重要（自社製／他社製を問わず）

　　・ダウンロード自体が古い考えになりつつある
　　　　⇒ストリーミング；"持つ"必要は無い

　　・機会探索！ ⇒ 仮説検証
　　　　・（前者は今までに単語として聞いていない；忘れてるだけ？）

　　・"スープストックTokyo"
　　　　・ペルソナの設定で成功した！、として有名

　　・問題発見力を教育上でも重視するようになっている
　　　　・MBA　⇒　MFA重視
　　　　・デザイン会社の買収ケースが増加している ＝ 企業が重視している証拠

　　・正しい答え ＜ 正しい質問
　　　・"なぜ？"を考えることが重要；自分の都合で答えを決めない（仮説検証）

　　・実験的に喫茶店などで女子大生の隣に座ったり；会話を聞く；様々な話題が聞けて気付きが有る；
　　　　・高齢者、子供、接してみて初めて気づくことが出来る・"正しい疑問"を持てる

　■データドリブンのUXデザイン

　　・定量・定性データ/分析のバランスが大切（一方だけでは成り立たない）
　　・AIの取り込みの敷居は大変低くなっているでしょ！？（使えば良いってもんじゃないが）
　　　　・使った方が良さそうなら、尻込みしてないで使えばよい！

　　・現在のレベル・状態を認識することが大切！（７段階の成熟度）
　　　　・何で扱うかはともかく、数値を使う意味を理解して、使っているか？
　　　　・成熟度が上がらないと高度な施策は打てない！・思いつかない；段階的に上がっていくようにコンサルしている
　　　　・中間段階を飛ばしてのレベルアップは不可能！
　　　　・ツールが有ってもナレッジが無いと無理；自力で出来るようになってから、ツール利用や自動化が可能になる！

　　・エクスペリエンス･マップを使う！
　　　　・ペルソナ想定して、当てはめながら検証を繰り返す（ペルソナへの感情移入が必要になる..）
　　　　・ペルソナの属性をどれだけ用意するか？；用意できるか？；検証の為に必要な属性を見付ける（←検証と実験で分かって来ることも有る）
　　　　・少な過ぎは論外だが、多過ぎも本質を見失う（そもそも収集にコストが掛かるし、件数が減ったり、対象者が
　　　　　疲労して回答がいい加減になったり、主催者側に気を使ったり...）
　　　　・分析結果から ⇒ 新たに提供したいコンテンツをどうやって用意するの？；結構大変！

　　・ペルソナ；感情移入できない場合が厳しい！
　　　　・例＝乳がん保険；本物の該当者を集めて入って貰う；出来ればワークショップをやる！
　　　　　　＝グループインタビューになる！

　　・インタビュー：ネガティブな要素を引っ張り出す；←要改善点＝ペインポイント(痛点)を見付ける
　　　　↑ 言葉の表層に飛び付かず、相手の背景状況なども聞取り（或いは推測し）、深層心理を探る；

　　　　　　・何が解決されればペイン（痛み）が改善できるのか？

　　・ルールベース（プログラム固定ロジック等）では効果は限定的 ⇒ 例えばAIを利用する、とか
　　　　・AIはあくまでツール
　　　　・テクノロジードリブンじゃダメだよ、と
　　　　・技術を主張してはダメ！；"使いこなせない方が悪い" などは最低！（ユーザー軽視のビジネスなど有り得ない）
　　　　　　・ユーザーが快適に感じるかどうか？、ポイント

ナレッジ

　・ぶっちゃけ、"データドリブンのUXデザイン" は全部重要！
　　　・結局、新規ビジネスや施策への着手前に、仮説設定・分析、調査(データ収集)・検証は必須ってことだ。
　　　・今回のセミナーでは、リーンスタートアップよりもデータに比重を置いて、具体的な進め方や指標を教わったということ。

　・"UX" は "UI/UX" とかって並べて書かれていたりするけど、意味の広さ・抽象度・視点とか全く違う！
　　　・（"UI"はアプリ視点）
　　　・"UX"は直訳では"顧客体験"だが、ユーザー視点で、サービスによって波及的に得られる、アプリ外でのアナログ／

　　　　心理的／対人的な体験とか全て含む。
　　　・（UXを語るケース・主体により意味の範囲が大きく変わる）
　　　　　・今回のセミナーでは最も広い範囲の定義を聞いた。データ分析(心理分析まで含む)、マーケティング、サービス設計、

　　　　　　Webデザインまで含む。
　　　　　・（例えばWebデザイナーがクリエイター目線で語る場合なら、アプリ、心理(喜び)、ユニバーサル、辺りまでか？）

質疑応答

　Q. ログインを伴わない場合の分析として、どんなアプローチが有るか？
　A. IPアドレスから場所を推定して反応を変えたりとか；その地域でユーザーが望む情報を提示したり..
　　　簡単な質問を１つだけするとか；1回限りのおもてなしを最大限に行う；ツールが意外と安価に有るよー
　　　性別の登録が無くても、推測する場合も
　　　Rtoaster；タグで何となく自動連携してくれるツール

　Q. 実際にデータ分析の知見も無い企業に対して、どのようにコンサルしていくのか？
　A. 当然ながらケースバイケースだが、
　　　例）先ずはチームを構成してもらう ⇒ チームに加わって一緒に活動する：適宜でメンバーにヒアリング→指導 ⇒ (進行)
　　　例）コンサル側でチームを組んで具体的にやって見せたり ⇒ 段々と顧客企業側に渡していく、とか..
　　　少し理解できると、興味を示すようになってくる；顧客内で議論が進んだり；、熱を帯びるようになる
　　　適宜で望ましい疑問を投げてあげる ⇒ 考える道筋を導く；概ね半年くらい掛かるかな．．

その他資料

会場の様子。
セミナー開始前なので、未だ人が少ないですが。
電源は床に所々アリ。　Wi-Fiは無し。

.

.

.

感想

　・今回も、貴重な学びの機会を頂き、有難う御座いました。

　・正直のところ、思った以上に対象のスコープが広く、未だ何が分かって・何が分かっていないのか？

　　　それ自体が自覚できていないような有様ですが、こうして資料を見直し、少しづつ整理をしながら、ほんの少しづつですが

　　　理解が進んでいるような．．．気がします。

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

DevLOVE："リンスタ関ヶ原 ～敗軍の将、兵を語る編～" に参加

DevLOVE："リンスタ関ヶ原 ～敗軍の将、兵を語る編～" に参加して来ました。

当日の入館に関する案内メールが、前日の土曜日のお昼ごろにメール配信されていたのですが、筆者はメール確認していませんでした．．．。
結果、早めに会場に着くように出かけたにも拘らず、ウロウロと迷いつつ到着したのは開始時刻の13:00丁度。

テーブル席は最前列しか空いておらず、最後部の椅子だけ並べられた席ではPCを使い辛そうなので
気後れしながらも最前列の左端に座りました。

おっと！、話し手の方々がすぐ横に、こちら側に向いて並んで座っていらっしゃる！

うっかり居眠り．．．なんてことは、絶対に許されないなあ...などと不謹慎なことを考えつつ、セッション開始しました！

参加コンテンツ名／講師／機関

　リンスタ関ヶ原～敗軍の将、兵を語る編～／DevLOVE
　　・石原 吉浩：StartupWeekendオーガナイザーファシリ―テータ
　　　　「失敗したの？すごいじゃん！」な社会を目指して
　　・篠原 徳隆：ヴァル研究所　Business Development Dept.
　　　　門外不出！後世の歴史家が語る、42年のプロダクトの影
　　・亀田 重幸：ディップ　(諸々)
　　　　失敗を成功に近づける、アブダクションの科学
　　・進藤 圭：ディップ　(諸々)
　　　　リンスタしくじり先生?戦場の舞妓編?
　　・市谷 聡啓：ギルドワークス代表
　　　　4つの戦犯から考えるサーヒ゛スつ゛くりの失敗
　　・塩原 弘洋：アイビーアイ　システム部門リーダー
　　　　10年10本のメディア立上げを振り返る
　　・天野 充広：株式会社クレイ代表
　　　　DocBaseの開発　5つの失敗
　　・及部 敬雄：楽天　新規事業チーム・マネージャ
　　　　大きな会社で小さくはじめる
　　・竹馬 力：リブセンス　開発チームリーダー／新規事業開発
　　　　得られた学び

実施日時
　2017/11/12　13:00～17:00

実施場所
　ディップ株式会社
　　東京都港区六本木3-2-1 六本木グランドタワー 31F

満足度
　95点
　(0～100点満点、時間分の価値がどうにか有った＝60点、概ね満足＝80点)
　・もう情報密度が濃過ぎて、Inputの整理の方に遥かに時間が掛かりそう。
　・参加費1000円は、いつの間にか"要らない"ことになっていた。"集めるのが色々と面倒だから"だそうだ。色々な意味で凄い。
　・"軽食など用意します"と事前に案内が有ったが、結局無料だったんだけど水(ペット500ml)だけという微妙感。
　・参加者数、凄い。そこそこ広い会場で、3人掛けの机に基本2人が席に着く。最後尾に椅子だけ10数脚 x 2列でも満杯だった。
　・1人の話し手がお子さんの体調不良で欠席。でも、もし総勢10人だったら17時には絶対に終わらなかっただろうと思う。
　・市谷さんが司会だったが、話し手の順番決めてないとか、おーそう来るか？！といった感じ。
　・一番前の席になってしまった（入館に迷ってギリギリの時刻になったから）のに、不思議とリラックスして参加できた。
　・帰りに夜景がキレイだった（31Fだからねえ）けど、写真撮る気力が残っていなかった。

概要・所感
　・まとめ記事が、会場提供のディップさんの方で作成頂けています。
　・未だ、"スライド取り寄せ中" のコンテンツが多いですが．．．。
　・殆どの人がスライドベースで話していた＝スライド見れば大体分かる、と思います。
　・スライドに出て来なかった話を、下記に少しまとめました（テンポが速くて書き取り切れて無いかもですが...）。

補足：石原さん
　・p.5：某大手にて新規事業；
　　某超有名コンサル会社と一緒に企画した；現DeNA･南場さんと一緒だった；
　　"特定保健指導"をターゲットに選んだ；
　　　・当時＝電話と対面のみの運用だった
　　　　⇒"ネットオンリーでやれるようにしよう！"
　　　・巨額の大赤字で撤退...
　・p.6：顧客からの"いいね！"は当てにしちゃダメ；
　　売上とは全然リンクしない！

補足：天野さん
　・DocBaseは天野氏が始めたもの；
　・マークダウン形式のドキュメント共有サービス；DocBase
　・マークダウン形式なのに、非IT系の人達が意外と沢山使ってくれた！
　・1ドキュメントに、他のドキュメントを差し込める(リンクできる)
　　　↑同じことをあちこちに書いたりといった無駄が無い・コピペが無いから齟齬も出ない
　・受託開発中心；＝ "リーン的な・仮説検証法でやりますよー"と営業してる；
　・カスタマーサポートに同一ユーザーから連絡が何度も機能要求が来るので実装・リリースしたら、なんと解約されていたり...
　・ユーザー(層)だと思っていた相手(達)が、実はユーザーでないとか、あるある。
　・KPIの設定が拙かった：施策をしても結果に結び付いてるか？、さっぱり分からなかった
　　　・開発側では、DocBase＝情報共有する数を重視していた；情報提供をするユニークな人を増やしたかった
　　　⇒会社・人毎に使い方は違う！と気が付いた
　　　⇒ツールに招待された人が3週以内にリテンションするか？、を追うようにしたら実態が掴めるようになり、改善施策にも繋がった
　・課金を始めるのが怖かった；
　　　使わなくなる人も当然いたが；本当に使う人は、より真剣に使ってくれる！
　・"このサービス、使われなくなったら止めるんですよね？" と言ってくれたメンバーが社内にいた；有り難い
　　　やめ時の判断が難しい；⇒ 指標と数値を明確にした ⇒ どうにかクリア出来た！（ギリだったけど..）
　・キャンバスは見えるところに張り出す；全員が意識する
　・サービスプラン："安過ぎるんじゃないの？"と顧客からよく言われる；
　　　↑は、"サービスが無くなると顧客側が困る"から。（＝業務に必須になっているから）
　　　・100名＝2万円／月
　　　・余りに安いと、"粗悪なサービスじゃないの？" と思い込まれてしまう危険性がある、失敗だったかも...

補足：及部さん
　・楽天さんなので、今回登壇した中で最大手企業
　・大企業としての問題・難しさが主に語られている印象...（中小・零細でも共通する中身も有りますが）

ナレッジ
　・ちょっと整理に時間が必要.....（工事中ってことで...）
　・間違いなく言えるのは、"価値探索・検証は絶対に必要！" ということ。
　　　・何度も繰り返さないと、実戦的に活かすのは難しいかも。
　　　・アーリーアダプターへのアプローチと同時並行して、アーリーマジョリティへのスケールアップをどうするか？も考える。
　　　・スケールさせる仕組みも考えておかないと、意外と立上りが早かった場合などに、一旦不評を買うと顧客は戻って来ない。

質疑応答
　・評価系の話を聞いてみたかった：(話し手からＱ)
　　　・市谷：評価なんて上手く行った試しがない；これから変えようとしている；"目標とかいいから、やったらプラス！"
　　　・失敗多いけど、プロセスは良い場合とかどう評価するか？ ⇒ プロセスも貯金になるよね
　　　・社員数20名；評価制度無し；企画を多く出した者勝ち；社内風土化させてる

　・企業文化：(話し手からＱ)
　　　・モブ･プログラミングで人材採用；これからやろうと思ってる；文化の合う人を採用する

　・開発者が"作る"事にしか関心が向かないケースが多くて困っている
　　　・自社の課題とか、見える化してる；議事に話題に出したり；効果出てない．．．

　・新規企画・開発の期間割合の目安とか有る？
　　　・一般論での正解なんて無いだろう；自分達で繰返すしかなかろう；自分達の答えを探す
　　　・全体＝短期の方が良いかも；基本、新規ビジネスなんて余計なもの的な位置づけだったり？！；
　　　・上の人に提案するときは数字を示す；天からの声の場合は検証して回答する

実例様々..
　・新規事業のチームメンバーが如何にも寄せ集め；人材の掃き溜めになってたりする；
　・どうやってもスピード感出ない
　　　・大企業のあるあるだね（手続き・始める前に成功を示せ！的な）；企業側の期待と違っているのだろう；回るはず無い；
　　　・奇人・変人・暇人、が集められる ⇒ 後者の2種類はいずれいなくなる
　・メンバーには若くて染まる子を選ぶ；技術レベルとか必ずしも関係ない
　・小さい会社で人選の余地が無い；POの熱量で決まる；求心力を如何に保つか；若い子の方が良い(信じ易い)

その他資料
　 会場の様子：休憩時間に撮影：実際にはこれより更に後ろに椅子だけが並べられた席が有ります（そこも満杯）。
　ざっと見た感じ、8割以上の人がMac派でした...；筆者はメモ用に旧式VAIO-X；

電源は提供されました（Wi-Fiは無し）

感想
　・本当に貴重な機会を戴けて、ひたすら感謝・感謝です！
　・"失敗は学びの機会だ！、後悔や挫折する暇があったら学べ！" ってのがヒシヒシと伝わりました。
　・とは言え、人間だから落ち込むし、組織だからお金を出すのに慎重になるのは避けられない。
　・そのまま潰れてしまわないように、失敗を共有して学習の機会も共有しよう！ってのは素晴らしいです。
　・日曜日にも関わらず、様々な準備と後処理を含めて多大な時間と手間を掛けて頂いた関係者の皆様方には、本当に感謝です。
　　有難う御座いました。

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

OKR/KPIワークショップ #0 に参加しました。

11/6の夜、"プロダクトオーナーのためのOKR/KPIワークショップ #0" に参加して来ました。

以下に、メモ形式で恐縮ですが、要点のみ記載させて頂きます。
もし万が一、参加された方、関係者の方がご覧になり、"違うよ！"など有りましたら、ご指摘頂ければ幸いです。

はじめに
　・"OKR"をPOStudyで扱うのは初めて！；基本的に組織論である；社員のモチベーションに影響する
　・今回は緩い段階をゴール地点にしている
　・参加者のレベルやタイプが様々だから(通常は同一会社の人を集め、事前理解が必須)...；
　・とりあえず全員が全力出してワークしてね！

OKR認定試験・某社で行っている
　＝OKR Japan；資料が優れているので今回のワークで(改変しているが)使わせてもらう
　PDFダウンロードできる
　　　↑このスライド最後のページにPDFリンクが有る（できるOKR_v1_1.pdf）

当日の資料について

　・設定テーマ(紙の資料)は、別セッションを手伝って貰っている各社（２社）社員に作成してもらった；

-----[以降、概ねスライドの順に進行]--------
(話の内容は、結構スライドと違っていたりした...)

>Problem1:目標が無い

定量評価が出来る目標を設定するのが良い；成果の見える化をする
　プロダクトデザイン；5年後をゴールにしたり；間を割って目標を細分化する；
　1.リーンスタートアップ＝売るネタもこれから
　2.プロダクトアウト＝売るネタがある
　3.マーケットイン；業務の改善具合

　2と3では、出し方が全然違う！；

>Problem2:見えない

やり方が全く分からない！
　・OKR/KPI作るのは大変！
　・イノベーションを生み出す能力って、どうやって身に着けるの？
　　・日本の学校には無い；大学院博士課程後期とか...(一般には知られていない)；身の周りに滅多にいない
　　・外国では博士課程で実践する
　・プロセスも経験も無い；
　　⇒工程を言語化すると意外と単純。(実行は難しいけど...)

現状＆ゴールを言語化する；人に正確に伝わればOK！(相手に説明し返して貰うとかで確認)
　・現状←→ゴールの間の埋め方の経路は無数にある！
　　・仮定と検証をしてみる
　　　　⇒(余り離れていない)複数個所で実施
　　　　⇒間を繋ぐ経路を見付ける ← 一気にゴール間の経路を考えるより、精度が高く、リスクが低い

OKR/KPIツリー
　・どんな視点で分岐させているのか？を書く

>Problem3.動かない

・やってみたが結果が出ない；"現状のままでOK"が結論だったりとか...；
・成果はコンテンツ次第だったりもする； ←(知名度･魅力の高い素材)
・影響を受ける人は誰か？を考えておく！；社内；不利益をこうむる人とか...(人の人生を左右し兼ねない)

・★7%；組織の目標理解し、その達成に向けて活動している人の割合
　↑関さん的には、"こんなに高いか？"という数字。
　　↑企業規模にも拠るが、1%でもおかしくない..

・OKRの要素
　・何処に向かうのか？(目標の内容)；Objective
　・どうやって正しいことをチェックするのか？(具体的な結果)；KeyResult
　・どうやっていくのか？；KeyAction
　(実際の経路ステップは数千あるよー！)

・お勧め書籍(3冊)
　・リーンスタートアップ成長戦略
　・(その他は控え抜け..)

・OKRの基本構造
　⇒顧客のビジネスイメージを構造的に理解すること！
　　↑これが出来ずに受注･開発に入るとか、お客様に失礼

・OKRの例
　・全社をアメリカに進出
　・アメリカにて顧客10社と契約
　・営業を10人採用；500社のリードを得る；100社と商談する；
　　　↑<目標無しで数字だけ＝絶対に失敗するパターン>

★主語が大切
　・用語を統一する
　・役割で主語を表現すると良い！←表現粒度が粗過ぎないこと★
　　　↑ここが重要だったりする；UI/UXを変えるべき

お試しで楽天店舗開こうとすると色々見える
　↑選択条件・店舗規模に応じて、相手にビジネスイメージを確認して貰う；
　↑UI/UXを変えたりするのでは..
　↑提供機能も変わって来るだろう (数万点の出品者とか、登録･更新が大変とか..)

-----[以降、ワークショップ]-------------

スライド中にも記載の有るウォームアップを実施
　・自分自身について、何でも良いからOKRを書いてみよう！
　　↑"自身の事も書けないようではプロダクトオーナーとして失格.." 的なジョーク？を関さんから浴びせられながら開始..
　・とにかく時間が短い！
　・どうにか自身のOKRっぽいものを書いたが、"OKR"自体を理解していないまま書いてしまい他のメンバーから指摘を受ける
　　　↑(恥ずかしい...)
　・他のメンバー1人分に対して、30秒で肯定的コメントを書く。
　　　↑何とか書けた。1人の方が、"ディスカッション、意義あるなあー！"と呟いていたので嬉しい。

BtoC、BtoBの設定からどちらか一方を選択して、チームでOKR作成ワークを実施
　・Object(目標)を、"某既存大手のECサイト" が、"海外：アジア展開で売上が低い" ⇒ "同市場の売上を上げたい" に設定。
　・Objectが大き過ぎたか？、そもそも "現状はどう"、"どうしたい(目標)" 前後から先に進めず紛糾....
　・途中で関さんにアドバイスを戴いたにも関わらず、堂々巡りから抜け出せないまま終了（全体が時間延長したにも関わらず）
　・ちなみに、関さんから頂いたアドバイスは、おおよそ下記のようなもの（だったと思います...）
　　　・海外展開するなら、先ずお客様となる人達が何を欲しがるのか？を知ることが先。
　　　・先ずは手売りで、手ごまの商品の中から候補商品を選んで現地に持ち込み、試験販売する。
　　　・売れるモノの傾向を分析、それからサイトを展開すればいい。
　　　・スマフォ重視なのか？とか、現地の人達の購買行動の傾向を知った上でUI/UX設計する。

振返り
　・各人で振返り；A3画用紙に太めのサインペンで書く
　・"明日、先ずやる事" も別の紙に書く。
　・書き上がったものは、撮影されて記録される.....うーん、重ね重ね恥ずかしい...

-----[その他：筆者の感想]---------------

・数字には必ず、それを裏付ける意味がある；
　　⇒それを押さえないと意味がない！★
・キーワードに振り回されてしまう；
　　↑視線が本質から反れる；
　　⇒自分の言葉で素直に表現すればいいんじゃない？
・実際の利用者がどう動いているのか？、感じているのか？、反応するのか？、想像･仮定する。調査する。

・やはり事前勉強は最低限やっておかないと、用語解釈の段階から躓いたり、効率悪い
　　↑折角、夜遅くに集まってワークしたのに...
　　↑チーム(3人でした)の足引っ張り役になってしまった...

現場から離れて17年にもなり、60歳近い（←言い訳）くせに、事前勉強ゼロで行ったのは、"無謀だった" の
一言に尽きます。

チームで一緒だった方も、"少しは勉強しとけばよかった.." と言いつつ、議論は最後まで盛んに行えていたのは
さすがだなあ、と思った次第です。

翌日である今日（11/7）、資料を見つつネットを調べつつ、怪しい記憶も手繰りつつ復習しています。
何らかの形で、社内で必要な：関心のあるメンバーと共有しようと思っています。

あ、コンデジも持ち込んだのですが、撮影している余裕が有りませんでした...。

ただ、入室・登録確認時に、"POStudy"シール（3cm四方くらい）を1枚頂いたんですけど．．．

これって何に使えば良いのだろう？？

名刺の裏にでも貼れってことか知らん？

NotePCにペタペタとシールを沢山貼る人がいますが、そんな感じにしろと？

まあ、お好きにお使い下さいって事なのでしょうが、特に何の説明も有りませんでしたね...。

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

社外セミナーとか、参加してますか？

自社内でもワークショップやハンズオン、勉強会などを企画・実施していますが、
やっぱり社外の人と接する機会は大切です！

ワークにしてもセミナーにしても、やはり場数を踏んだ著名な方が実施するコンテンツは、質の次元が違う！

ということも実質的にありますし。

と言うことで、社内コミュニケーションを中心としたslack(有料コース)運用の中で、
社外セミナーなどの紹介チャネルを設けてます。
（特定個人にお勧めのコンテンツの場合には、slackDMで個人宛に連絡してます）

slack上で紹介・広報したセミナー類は、別途Googleスプレッドシートにも情報集約しておき、
広報範囲・連絡先（DM連絡の場合）、参加意思の表明者、実際に参加した人、の情報を記録しています。

．．．．．が、
参加者少ないっ！

いても、同じようなメンバーが参加し続けてるし、
これじゃあ何の為にわざわざ外部セミナー告知してるんだか分からない！！

告知する時は、
どんな人に推奨したいか、費用が掛かる場合は会社負担するケースを増やし、内容の重要度によっては
業務時間扱いにするから！と付け加えたりしてますが、
応募少ない．．．．．

このまま勝手にセミナー告知を続けていても仕方が無いので、一度、定例会で出席者達にリアルタイムで聞いてみたことが有ります。

以下、その時の意見。
・常連が出席していそうで、場違いになりそうで不安。
・人見知りなので１人では行き辛い。
・意識高い系の人ばかり集まりそうで、自分の不見識が恥ずかしくなりそう。
・時間帯が合わない、予定が立たない（育児の都合で無理な女性エンジニアもいる...）

あーーーーーーー．．．．．．．．

気持ちは分かる。

分かるけど、そのままで良いの？
それに、そんなに、もの凄い人ばっかりが参加するわけじゃないよ（企画による差は大きいのでしょうけれど）。

ワークショップやハンズオンだと、"恥をかく"(？)ってシーンも有るかもだけど、
セミナー形式だったら関係ないでしょ？？

筆者（50歳オーバーです...）も、そんなに多数のイベントに参加して来たわけではありませんが、
SCRUM系の終日イベントに参加して、全コンテンツがワーク形式でへとへとになったり（でも超面白かった！）、
特定技術や開発プロセス系のセミナーやワークに参加したりして、自社内で情報共有をしたりして来ました。

自分自身の経験の中で、社外イベントに参加して最も有意義だと思えるのは、
やはり "社外の方たちと一緒に小さなチームを組んでワークをすると、いろいろととっても刺激的！"
ということです！

これは、どんなに頑張って自社内に情報だけ持ち帰って、対面での共有の機会を持っても（イベント時と同じように、
ワークショップの形を模して実施したとしても）得られない体験感覚です。

"１人だと行き辛い.."って人の為に、
"気になったイベント"が有ったら、slackの機能で絵文字を付加できる（facebookの｢いいね｣ボタンが複数から選べるみたいに）
ので、注目顔のアイコンを付けるようにして、2人以上のマッチングを誘発するようにルール付けしたりとか...
．．．．．しましたが、数ヶ月やってもマッチングは成功せず、
そもそも注目アイコンを付けてくれた人が僅少であるとか、
もう止めるか？　　要らないか？　　意味無いか、全然ダメか？？

．．．と自問自答しましたが、
"当日に行けなくても、開催後にスライド情報や関連記事が公開されるので、追って見ている"って人もいたりして。

うーーーーーーーーーーーーん．．．．．．．．．

自分が出ればいいんだよ！

そう。　前から思ってたけど、告知ばかりして、現場業務で多忙で疲れているメンバー達に一方的に参加を求めるよりも、
先ずは自分が参加すべきと思った企画に、自分が参加すればいいじゃん！
（体調の関係で見送ってたんですが、少し良くなって来たし、動かなきゃ変わらないし...）

と言うことで、
先ず近々では、

・プロダクトオーナーのためのOKR/KPIワークショップ #0【2017/11/06(月)】

・リンスタ関ヶ原 ～敗軍の将、兵を語る編～　【2017-11-12（日）13:00 - 17:00】

．．．の2つに申し込みました。（勿論、slackチャネルにも告知済み）

ついでに、
"こんなイベントに参加するから、何か質問してみたいこととか有ったら連絡頂戴ねー"と書き込んでおいて、
Googleスプレッドシートに書き込んでもらえるようにしておきました。

イベント内容に関しても、主催者側のOKを戴ける範囲で、このブログ上でも共有させて頂こうかな、と思っています。

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

パワポの意外な能力を知った日。

筆者はtwitterアカウントは持っていますが、"呟き"用には全く使ってません。
専ら情報収集の為のみです。

他には、フォローしている方の発言に"ハートマーク"(いいね！相当)をクリックしたり、極たまに返信したりする程度です。

で、フォロー対象に、一応の押さえとして "Microsoft"（support.office.com） も含めています。

そのMicrosoftから、先日、"図の背景の削除 - Office サポート"という情報が流されました。

おお！、あのパワーポイントに、背景の自動削除機能が有ったとは！？
知らなかった！！

早速、手元にある画像で試してみましたが、割と単純で明確に浮き出ている画像だった為か、
見事に"ここを切り取りたい！"と思う部分だけを残して背景が消えました！
嬉しいー！！

切り取りたい対象範囲の大枠を指定してやることも出来、微妙に背景と混ざってしまっているような場合でも、結構な精度で
イイ感じに切り出してくれるようです。

社内のslack：Tipsチャネルで呟いておきました。

(筆者) [13:45]
　おおおおー！、これは知らなかったぞおお！　PowerPointでこんなイメージ処理が出来たんかっ！？
　(URL貼付け)

すると、10分と経たずに自社内で作業をしているメンバーからのslack書き込みが。

△△△△ [13:53]
　uploaded and commented on this image: ○○○○
　画像の中から文字部分だけが残るとおもったんですが、
　"〇〇〇一覧" の "覧" の文字だけの、しかも一部分だけのこりました（泣）

同日の数時間後に、結構バタバタとタスク切替の激しい顧客先にいる開発メンバーからのslack書き込みがありました。

◇◇◇◇ [18:35]
　編集すれば、大分精度を上げられますね。
　(自動に任せた処理画像：⇒あちこち残念...)
　(ある程度の認識対象を枠指定してから処理した画像：⇒少なくとも素人目には完璧！)

バナーとか、イベントやキーワードを示す文字列表示を、目立たせる為にデザイナーさんに画像で作成してもらって使用することも多いのですが、
部分的に文言を変えたい、背景画像だけ置換えたい、とかの要望が生じることが有ります。

でも、大抵、デザイナーさんは様々なリクエストや変更指示、関連打合せや作業で大忙しの引っ張りだこ状態です。

簡単な画像変更程度であれば、開発チーム側で何とかしなければならなくなる（間に合わない／デザイナーさん倒れそう...）場合も有ります。

デザイナーさんが社外にいる場合（外注さんとか）だったりすると、手続き的にも遅延が増えたりします．．．、リリースに間に合わないっ！！！

こんな時、JPEG画像になっているデータから、特定の部分だけを切り出せたら有り難いなー．．．
ってことが結構あります。
（PhotoShop や Illustrator 形式のデータを、ホイホイと操作できる開発者は滅多にいません...）

意外と身近なところ（既にライセンスを所有していて、利用もしているツール）に、有用な機能があったりするものですね！

ケースバイケースではあるでしょうが、とりあえずの選択肢が増えることで、開発者もデザイナーさんも、少しだけ幸せになれるツール・機能は

本当に有り難いです！

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

ギルドワークスのセミナーに参加してみた！

いろいろな企業で有償の各種セミナーを企画・開催しています。

アスペアでも、以前はいろいろな有償セミナー（個別だったり、比較的軽量なコースが多数セットになっていたり...）に
参加して来ました（コース紹介の社内通知・配信は筆者が行いましたが、参加は各人の自由意志です）。

しかし、どうも内容的に余りパッとしない．．．。
わざわざ参加する時間を取るなら、その分を自己学習に充てた方が効率的だったり・意義が有ったり、参加価値は微妙？...というケースが多々．．．。

それよりも、DoorKeeperやPOStudy、関連情報に敏い人をtwitter上でフォローして情報を追っていくと、
有益な無償セミナーが多いことに驚かされます（"ハズレ"も有りますが...）。
（特にDevLOVE関西など、西日本の動きがとても活発なのには羨ましさを感じますが．．．）

開催時刻も、就業後でも参加可能なように配慮され、19時以降の開始だったり（終了も21時以降になりますが）、

場所的にも23区中心部付近が多く、移動も概ね顧客先から近いです。

"これはお勧めだな！"、"あいつとか、あの子辺りには参加して欲しいな..." などと思うコースを、
slack上の"出ようぜ！社外セミナー！！"のチャネル（←名前はウソですが..）に紹介します。

・どんな人におススメか？、
・概略どんな内容か？（コース名のイメージが、実質的な内容を反映しない場合が有るので）、
・"業務扱いでOKだよー！"（月報に"勤務"時間として計上して良いよ！）とか、
・参加費用が掛かる場合、"先着何名までは会社負担にするよー！"とか、
いろいろ情報流して参加を促してます。

自社内でも、定例会の場を利用してセミナーやワークをしたりしますが、やっぱり同業他社のエンジニア・他ロールの人との交流も
とても刺激的だし重要だと思ってます。

現在の業務に必要なもの、これからの数年で確実に押さえておかないと拙いもの、
トレンドになるかは分からんけど楽しそうなもの、
バリバリの技術系、開発プロセス系、ビジネス立上げ系、
色々と、敢えて傾向を分散させてます（メンバーの関心も様々ですからね）。

ですが、全員がWeb／インターネットの仕組みを前提としたビジネス開発に関わっている（社内外を問わず）ので、
どこのプロジェクト／プロダクトも多忙です．．．。

業務時間数が必ずしも長くなくても、頻繁な要求・仕様の変更、各種の調整（結果がすぐに出るとは限らない）、緊急対応などで
かなり密度が高く＆タスクスイッチが多い・並行度の高い時間を過ごしています。
当然ながら、疲労しますね。

やっぱり、現実的に時間的・心身的に幾らかでも余裕が無いと、社外セミナー、とくにワークショップやハンズオンなどは、
面白いけれど消耗も激しいので、意識として参加の敷居が高いのも理解できます。

．．．．．このところ、参加率が低い．．．．．

うーーーーーん、仕方が無い。
メンバーに対して、無責任に？紹介ばかりしていても埒が明かない。
自分自身が参加できるものは、出来るだけ自分(筆者)が参加しよう！（...健康上の都合もあるのですが...）

という事で、早速行って来ました！

正しくないものをつくらない。 -サービスづくり7つの失敗パターン-

ギルドワークス株式会社・代表取締役・市谷 聡啓 氏が講師として登壇されました。

目黒の(株)アカツキの会場はとても広く、カーペット敷きの床には多数の円形クッションが。
後ろの方に椅子も1列並んでいました。

筆者は近視なので（度の強い眼鏡を掛けたくない）、スクリーンが見易いように、クッションエリアの中程に陣取りました（靴は部屋の入口に有った靴箱に脱いできた）。

同氏はtwitter上でもフォローさせて頂いてますし、同社のWebサイトも拝見していたので、大体の話の流れとしては意外な点は有りませんでした。

同氏からのお話は小一時間程度で、後は質疑タイム。

内容的には、少なくとも表面的には理解できるけど、"本質的な部分は実践して痛い目見ないと分からんな..." と感じました。
それにしても、質問の中身が濃いのに驚きます。

セミナー中でも言われましたが、"自分(達)が、何を分かっていて、何を分かっていないのか？" を知ることが重要！、と。

これ、自己矛盾なんですよね．．．。
CMMIのレベル５（最高レベル）とかでも、"未経験の事象に対しても既知のメタ的な方法論からアプローチし、問題解決が可能" と

定義されていたりしますが、まあ、それと同様じゃないかと思います。

で、具体策の１つとして、"ギルドワークスが支援するプログラムが有る"というご紹介。
うんうん、もっともです。

いや、一緒にやらせて頂いたとしても、今のアスペアの最高のメンバー集めて対応しないと、吸収効率が悪いと思います。
って言うか、実戦的な要素が何も身に付かない危険性すらありますね。

そもそも、アスペア内の現有メンバーが、本当の所どんなことを・どんなふうにしたいのか？
本音の本音を改めて、個別に聞いてみないと分からない気もします。
（今回のお話は、"価値０(ゼロ)→１にしていく" が中心ですから）

会社的に、「こうしたい！」、「これが出来ないと生き残れない！」って言ったとしても、
各個人の腑に落ちていないと・インセンティブやモチベーションに結び付いていないとダメでしょう。

次回の定例会（9/22）で、ちょっと長めに時間枠を取って、筆者からの話もしつつ、皆から色々と話を聞いてみたいと思ってます。

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

ヘッドレスブラウザとSelenium3

今回もQiitaネタです。

--headless時代の本命？ Chrome を Node.jsから操作するライブラリ puppeteer について．．．という記事を拝見しました。

そして、今回も社内（協力して頂いているパートナー会社の方とか、フリーランスの方を含む）コミュニケーションツールとして
利用しているslack上で呟いてみました。

　筆者 [14:42]
　▼UI含めたテストでは今後の必須知識！、なのかな．．．（headless Browser）
　レンダリング無しならテスト速いんだろうなあ．．．
　(上記URLを貼り付け)

　○○○ [14:42]
　現場(客先)のslackにも全く同じ記事が貼られてた。

おおー！、見事に社外にいるメンバーからの即時応答！（DM：ＤｉｒｅｃｔMessageじゃないのに...）

やっぱり自動テストには関心が行きますよね。
レスの有った"○○○"さんは、自社企画・展開のサービスを開発してビジネスを立上げ中の顧客先で開発作業を支援してるメンバーです。

UIの自動テストは、従来だとWebブラウザを起動して画面操作のイベントを起こさせて...と、フツーにWebブラウザの画面が
勝手に（＝指定通りに）起動されてパラパラと画面遷移していきます...
が、実画面を表示する時間もかかるので、レンダリング時間も自動テストの中に含まれてしまいます。

結果、CI・自動テストは良いんだけど、"とにかく実行に時間が掛かる"のがネックでした...。
実行時間のコストを考えて（勿論、UIテストコード作成・メンテの必要性・メンテコスト・適用価値の総合判断もしますが）
画面展開を伴うテストは範囲を限定しようという現実的な制約というか、技術的な圧力が掛かってしまうケースも多々あったかと思います。

UIの自動テストを行うPCのグラフィックス系ハードウェアも高性能なパーツにしたりとか...
でも、ヘッドレスブラウザなら格段に効率が上がるだろうと思われます。
（実証していないので断言できないところが、情けないと言うか申し訳ない所ですが...）
Selenium3も、是非使ってみたい！

変更や、様々な部分での"必要と判断される変更"を、躊躇せずに行える（少なくとも自動テストの所要時間を余り気にせず）
状態に置くべきですよね。
（勿論、開発対象の各種特性によって判断や基準は違ってくるとは思いますが）

まあ、ヘッドレスブラウザも人間（組織）が作ったモノなので、何処まで信頼できるかは分かりません。

しかし、存在を知りながら手も出さず・評価もせず、では、改善の可能性にも至りません。

小さなチケットを切ってでも、簡易評価をして環境構築・テスト・評価をしてみるべきだよねーと思います。
勿論、得られたナレッジはslack上（＆その他の社内的な手段を使って）で共有します。

その為には、評価してもらう時に、メモでも良いから必ず要点を残してもらうこと！、ですよね。
チケットなら、それに紐付いて残るし、別枠でナレッジ集約のページなど（プロジェクト／プロダクト横断的なナレッジ集約ページ）
にも掲載していけますし。

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

AWS認定試験を受けよう！

Qiita（キータ）

IT業界、特にコードを現役で書いている人で、知らない日本人はいないんじゃないか？
と言えるくらい、著名で有用なWebサイトですよね。

同サイトで、こんな記事を拝見しました。
【合格しました！】AWS 認定ソリューションアーキテクト アソシエイト 受験記

アスペア内でも、IT系の各種認定試験、他に簿記や色彩検定なども報奨金の支給対象にしています（適宜で対象や報奨金額の見直しもしてます）。
受験料も、同一試験に対して最大2回までは会社負担としています。

認定試験にパスする：合格するという点そのものには、大した意義は無いと思います。
目的は、"基礎から思想を含めて体系的な理解をする" こと。

枝葉末節な "操作の断片の幾つか" を知っているだけではダメで、
体系的な理解をしていることの客観的な証明指標として、"認定試験に合格する" という基準を利用しよう、という事です。

認定に合格した後も、2年に1度の更新受験が必須になってますね。
どんどん拡張や仕様変更の為されていくものなので、当然でしょう。

現在のアスペア内のメンバーは、現状で一般的に求められる：習得済み・経験済みが望ましいクラウド系の知識が全般的に不足しています。

"今さらかよっ？！"、と思われる方も多いでしょうね。

今さらなんです．．．．．。
既に遅きに失している感も有るのですが、放置も出来ません。

クラウド系サービスは、大手に限らず様々なサービスが展開されていますが、市場占有率が極めて高いままに堅調で、
かつ弱まるスキが見えないAWSは、必須前提で押さえておきたいベンダー／技術要素です。

先ずは試しに、社内のコミュニケーションツールの１つ：slack上で呟いてみました。

　筆者　[10:38]
　▼これは、受験費用も報奨金も会社で出したい、って言うか出すべきだな！
　2017年度・最大のおススメだと思う！

　○○○ [10:41]
　えー！こんなのあるんですね。やってみたいです！
　LPICと同じぐらい役に立ちそう
　受験するか？はさておき、対策本を会社で買っていただいてもいいですか？

　筆者 [10:44]
　勿論、OKですよー！　"書籍買い放題"制度の対象として、立替宜しく・後日清算・当面は個人保管(=利用)、のパターンでOKです！

で、早速、現時点での報奨金水準を直近で一通り見直してくれたグループ長さんにお願いをしました。

　筆者 [10:59]
　@◇◇◇ 済みません、お願いが１つ。
　報奨金制度に、｢AWS 認定｣を是非加えたいですー！
　受験費用だけでなく、報奨金も是非出したい！（現状のアスペアでは出すべき！）
　最低でも2017年度内は、特別推奨で＋αで上積みしたいくらい！（って言うか、マジで上積み交渉したい⇒○○(←社長の名前)さんへ）
　<お願い> ◇◇◇さんの方で報奨金見直しをして頂きましたが、同じ尺度で、こちらもザっと見て頂いて、大体の報償金額を出して頂けませんか？
　急ぎません。　宜しく、お願い致しますー

　◇◇◇ [11:55]
　わかりました。

という事で、実際には筆者と社長で話をして、具体化に向けて進んでいるところです！。

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

メンローイノベーションズ社を見学した方の記事...

以前の全社定例会の中で、書籍「Joy, Inc.」の紹介をしました。

その後、暫くして、情報収集用に持っているtwitterアカウント上でフォローしている方を通して、
「Joy,Inc.」で描かれているメンローイノベーションズ社に、実際に見学ツアーに行った人のレポート（長文・写真多数）
の存在を知りました。（記事）

感じたこと：

　・書籍ではモノクロ写真のみだったので分かり難かったが、カラーだと臨場感ある！

　・入社の浅い人でも案内役として活動するって本当なんだな！

　・"Chief Motivation Officer" なる役割が有るらしい、面白いな。
　　　・想像するに、役割が先に出来たんじゃなく、能動的に実績を積んでいた人に周囲が役割名を付けたんだろうなあ...
　　　・犬が2頭いる...、ネコを執務室に入れている企業をWebサイトで見たことも有るが、さすがに猫はリスキーな気がする...

　・"素早く失敗して、学びを得ていく" は、しつこく教えないとなかなかできない！、んだそうだ。（そうだろうなあ...）

　・"通常20-30%ほどのリソースを安全余裕をとっておく" が、顧客にも見える化しているんだそううだ。凄い！
　　　・下手をしたら、"どうせ結構なバッファ取ってるんでしょ！？、だったらこれもやってよ！" 的な話になりそう..
　　　・↑：勿論、そこも上手く出来ているってことだろう。
　　　・"20～30％"って具体的な数字は書籍の方には書かれていなかったので、ほうほう、と思った。

　・ペアプロ、隣のペアとの距離近い！、これで隣の会話が邪魔にならないって、凄い集中力だなあ...

　・人材管理的なボードがあるとは！
　　　・中身は頻繁に、皆で話し合って決めているそうな。
　　　↑これは納得。年に2～3回とかの考課で処理するのは無理。忘れてしまう。
　　　・プロジェクト完了時とか、より短いスパンで見直した方が現実を望ましい形で反映できると思う。

　・離職率は米国平均値である、という点はちょっと意外かな。もっと低いのかと思った。
　　　・米国内のIT系人材の流動速度はかなり早いと聞いているので、まあ、メンロー在籍も経験値の内の1つと割り切っているのだろう。
　　　・戻って来る人材も、推奨してるしそれなりにいる様子。ウチは今現在は1人だけだな...
　　　・"小さな失敗をより早く行い、より多くを学ぶ"、はコストを伴うはず。
　　　　　・まあ、ペアで業務を行う(役割に関係なく？)ので、ナレッジが一気に消えることは無い、のだろう。
　　　　　・その意味でも、"ペア前提"文化はリスクヘッジ・投資効果の逸失を抑えているんだな。

　・余りにも当然の前提だけど、英語で質疑できる人のレポートである...

書籍に書ききれなかっただけなのか、原書の執筆以降に"実験"して"運用されるようになった"ことなのか？

後者もいろいろと有りそうな気がする、と言うか、そう思わずにはいられない。
どんどん変化し、成長し続けているのだろう。

自分達なりにも、出来る部分は見習いたい、実験・実践して行ければ！という気持ちが湧き上がるけど．．．

1人で盛り上がっていてもどうにもならないので、皆が（顧客も、エンドユーザーも、各技術者も、技術者の家族も...）
喜びを感じる・幸せになるように、
どうステップしていけば良いのか？、目標を粒度と時間軸で細分化して、小さなこと・出来ることから
先ずは自分が動いていくしか無いよね。
（機会を伺いつつ、巻込めそうな人・時間を取り込んでいけるように様子を伺いつつ．．．）

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

Mr.山下のUI講座（React.js＋）

9月の全社定例会では、山下さんが React.js & MetalUI の補完的な技術説明を行ってくれました。

"補完的な"ってのはどういう意味か？と言うと、
実は前回（8月）の定例会でも説明してくれたんですが、質疑が多く、定例会自体の時間枠を超えても収まりそうになかったので
9月に延長・第2回目、として実施してくれたわけです。

現状のアスペアのメンバーでは、Webフロントエンド周りのトレンド近辺の技術は弱めです．．．
残念ながら．．．

自社内には、デザイナー兼プロダクション、ディレクション的な、要は要件側とサーバーサイド開発側の
橋渡しを行いつつ全体進行を促す・UI側タスクの配分調整なども行えるメンバーが1人（女性）います。

Webフロント周りで比較的強いのは、山下さんを含めても2名だけ。
フロント･デザインが出来るのは1名だけという、何とも心許ない体制です．．．．．

あ、話がずれましたが、React.js 関連の解説・質疑は、今回も予定時間を順調にオーバーしました。

山下さんに拠れば、要点は
コンポーネント指向である、"state, props, context" を押さえれば大丈夫・それ自体は難しいものじゃない。

言うまでもなく、Rect.jsはSPA（Single Page Application）の為のJSライブラリであり、ページ遷移はそれ自体ではサポートしていない。
（ページ遷移を伴うなら react-router を使おう、という話）

見てくれをどうこうしてくれる訳ではないので、別にライブラリ（山下さんの実務例で行くと MetalUI）を組み合わせる。

質疑で時間オーバーする位なので、参加者の関心は高いと思うのですが、実務で利用しない状況だと
＆業務負荷が量的に・或いは質的に重いと、なかなか独習・習得までは手が回りませんね．．．

技術的なトレンドを追いさえすれば良い、という訳ではありませんが、旧技術のままに埋もれてしまってはIT業界の中では生き残れません。

スキルの要素・キャリア的な各人の指向性を考慮しつつ、強みを強化する、必須要素内に凹みは作らないよう
案件の確保（表現はアレですが案件の選別）や人の配置・ロールの割り当てをしていかないといけません。

各個人として見た場合に、"同業他社で、多くの会社から欲しがられる"（十分通用する）人材であって欲しいと思います。

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

改めてお勧めアクション："リーダブルコード"

前回の定例会の中で、山内さん自ら立候補した上でのコンテンツ。

"書籍紹介" ということだけは、事前に分かっていました、が．．．．．
果たして何を、どんな理由で取り上げるのだろう？？

フタを開けてみると．．．．．
対象書籍はリーダブルコード。

社内で共有している "推薦書籍一覧" にも挙げられています。
（推薦者は、同・山内さんになってます）

業界内では著名な書籍で、多くの方に読まれていることと察しますが、
"より良いコードを書くためのシンプルで実践的なテクニック" を集めたものです。

Amazonのサイト上で見ても、とても高評価！（低い評価がごく僅かの割合しかない！、というのも珍しいです）

お勧めなのは分かる！

分かるけど、敢えて定例会で取り上げたいってのはどうして？？．．．と思ってましたが．．．

何と、"解説"を紹介するという！

「実際にやるとぶつかること」の部分が必読だよ！
是非、先に解説（ココ↑）を読んでから本文を読んだ方が良いよ！、というのが趣旨でした。

"読んだだけでは綺麗なコードを書けるようにはならない"
　"そもそも、どこが直すべき箇所かわからない"
．．．という当たり前の事が書かれている。

"まずは何をすればいいの？" ⇒ "実際にやる！"
具体的には、何をどうすれば良いのか？、に関しても、解説に書いてあるよ！、と。

それを先に読んでから、本文を、各人の関心のある部分から（考えながら）読む方が良い、ということでした。

（その方が、時間の有効活用度が高くなる：同書籍をより深く活用したことになる）

小説などの創作物の場合だったら、解説から読んでしまったらつまらない。
（でも、そういう方もいるのでしょうね。解説内に敢えて"先ずは本文を先にお読み下さい"と書かれている場合もありますね）

技術書の場合なら、
"こういう視点で考えながら読むといいよ"的なことは、出来れば"まえがき"とかに書いてあると有難いですが、

そうとも限りません。

増してや、ネット上で高評価の書籍だったりすると、普通に先頭から読んでしまうのが人情です。
普段なら目次の構成やまえがき、解説などから慎重に読み進め（品定め）してから入手する人でも、です。

なるほど、こういう書籍紹介のパターンもアリなんだなあ．．．とも感じさせられました。
面白いです。

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

新人君の、研修レポート。

今年4月の頭から、第二新卒的に転職・入社して来た新人君の社内研修が、7月初旬で一旦終了しました。

新人研修と知っても、言うまでも無く、その人の知識・経験値に応じて研修の実施内容やペースが必然的に違ってきます。

漏れなく、無駄なく、が原則ですが、
そもそも入社時点での練度によって、研修期間終了時の目標到達状態・レベルなどの設定も違ってきます。

今回の場合は、1年間の社会人経験は有りますので、マナー研修など個別には設定せず。
専門学校を出て来ているので、"コンピューターが動く仕組み"やら、"プログラムを書いてコンピューターを動かすこととは？"、"処理の手順を組み上げる"、etc.の基礎は不要です。

が、"アプリケーションやシステムの開発は初めて"、なので、"DBもWebも知識が無い"状態。
前職で、ツールとしてPythonは少し触ったことがある。

ということなので、研修の要素群と到達レベルの設定からして、模擬開発を含めて3ヵ月間を想定しました。

少し実戦向けの補完カリキュラムなどを足しながら、7月上旬には入社時研修は完了しています。

その後の最初の定例会が7月度（7/21）になりましたので、そこで研修レポートを発表して貰いました。

研修レポートは、研修者本人と研修内容・メンターによってレポート内容や方向性が違ってきます。
"必ずこの形！"というのは決めていませんし、決め打ちできるもの・すべきものでもありません。

今回の研修では、言語・フレームワーク的には Ruby on Rails だったのですが、諸事情があって、メンターが途中で入替ってしまいました。
特に、最後の模擬開発のメンターは RoR 未経験だったので、研修者本人にはちょっと申し訳ない対応になってしまいました．．．。

窮余の一策として、RoR実務経験のあるメンターがオンライン（slack）でサポートするという一幕も有りましたが、やはり効率は良いとは言えないですね...。
（ソースレビューもオンラインで行ってくれた）
まあ、全く無いよりは格段に良かったと思いますし、オンラインでサポートしてくれた側にも負担が掛かったので、
申し訳ない＆とっても感謝していることに変わりはないのですが．．．

レポート当日は、パワポを元に報告してくれました。
模擬開発で作成した小さなアプリの動きも披露しつつ、です。

この記事に、本人が作ったパワポのページを画像化して貼ります（自己紹介ページだけは省きました）。

最終段階でのメンターが、何度もレポートの練習・指導をしていたのが印象的でしたが、
結構良い形・内容になってるんじゃないかと思います。

模擬開発に関しては、方針的に悩ましいところも有るのですが、
実務の一部：実際に顧客に納品されるコードを書く方がモチベーションが上がるのではないか？、とか。

しかし、メンターが張り付いていたとしても、慣れない人間が納品用コードを書くことに対しての不安感は
相当のものだと思います。

それに、実際のシステムの一部で研修を行う場合、全体仕様が見え辛いと思います。
仮にも"実際に使われるアプリやシステムの一部分"なので、結局、自分がどんなプロダクトに対して、
何処でどう動く何を作ったのか？、どう貢献しているのか？、見え辛いのでは意味が乏しかろう？、と。

それよりは、顧客に使われることは無いとは言え、仕様は事前に決まっている、機能も構成もモジュール構成まで全体が見えるし、自分で作る。
機能追加や改修課題、リファクタリングなども、自分でこなす経験をさせる方がベターだと考えています。

色々と悩む機会・要素が増える面もありますが、"どうしてこうなんだろう？"、"もっと良くならないんだろうか？"、いろいろと悩んで欲しいと思います。

当面はメンターは継続担当しますし、先に担当したメンターもオンラインや定例会の時などに対面でフォロー
してくれています。
と言うか、熱い質問を投げ続ける新人君を見ていると、"ああ、嬉しいなあ"と思いますね。

"自律的に考える"⇒"疑問・質問が生じる" のは、とっても良いことですから！

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

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

筆者がtwitter上でフォローしている方の中に、吉羽龍太郎氏がいます。

氏のtwitter上での呟きで、スクラムマスターロールプレイなるスライドが公開されていました。

内容を拝見してみると、まあ表題の通り、開発スタイルとしてスクラムを適用していることが前提にはなっている
のですが、必ずしも限定しなくても実務ケースでのシミュレーションとして使えるのでは？

．．．．．と考えて、6月の定例会の中で60分ほど枠を取って実施してみました。
（これまでにスクラム／アジャイル関係の勉強会やワークショップなど、幾つかやって来てましたし...）

ちなみに、同日の出席者の中で、スクラムを実務で適用していた経験者は１人のみでした。

研修中の新人（第二新卒的な人）もいるので、
同じく吉羽氏の作成されたスクラム概説図を使わせて戴き、用語などの要点のみ"おさらい"を最初に行いました。

60分の枠の中で、最初の数分を上記のおさらいに充て、残りをディスカッション形式にしてみました。

保険として？、反応が悪い場合に備えて、自分でもどんな回答が考えられるか？、を
可能な限り挙げておいてみました。
場が余りにも展開しないようなら、"例えば"という形で小出しにしてみようかな？、というつもりで.....

結果、話題に挙げられたのは最初のスライドから3つ。

スライドの p.5："常態的にスプリントバックログが消化し切れない、何故か？、どうする？" に対しては、
おおよそ下記のような発言がありました。

・スプリントの振返りの場で、全員で考える。
・"完了"としているストーリーの精度も疑問がある。完成の判定基準に問題が有るのでは？
・各ストーリー／タスクに対しての見積が甘く、しかも学習＆改善がなされていない。
・他プロジェクト等からの頻繁な割込みが有るのかも？
　⇒割込みを抑えられえるなら抑える
　⇒割込み対応要員を分けてしまう。←の人数は、チームメンバー数としてカウントしない。
　　⇒残業対応で賄うことはしない！
　　　⇒プロダクトバックログの全数消化は無理になる、或いはプロジェクト終了日の延期の了承をもらう。
・スプリントバックログの各々の単位が大き過ぎるのでは？、見積精度が下がるのを避けられない
　⇒粒度を小さく、分割する
・メンバー間の繋がりが弱いのでは？
　⇒"個人の集まり"ではなく、"チーム"としてスプリントの完遂を担保する意識を共有できるように
・勤怠が悪いのでは？

上記に出なかったもので、筆者の方で想定していたのは下記のようなものでした。

・ストーリーの仕様が不明確(確認に時間が掛かる・矛盾が見付かる等)、プロダクトのinputとして不適切？
・メンバー構成が拙い(スキル問題)？
・スクラムの各種プラクティスの理解不足？、或いは手段が目的化している？
・メンバー中の何名かが？プロジェクトを掛け持ちしている？
・タスクへの分解の仕方、タスクの取り方が拙い？
　⇒複数タスクが同時にDoing(仕掛り中)になると、生産性・品質は低下する。

これら↑に関しても、軽く触れてみました。

で、3つの課題に関してディスカッションした後に、今回のセッションに関しての振返りを行ってみました。

Problem：
・スクラムに関して(自分達が)実戦的な理解が無さ過ぎてイメージが湧かない。分からない。
・やっぱり回答例（スクラム的に望ましい現実的な例）が欲しい！

Try：
・出題されたPOが余りに無能過ぎるので、そのPOのペルソナを作ってみたい。(恐らく半分以上は怒りか？)
・スクラム経験者のワークを見学してみたい。
・POとしての社内的な教育機会が有るべきでは？！

Keepに分類できそうな発言は残念ながら無かったのですが、
スクラムの実務経験が無いメンバーが殆どだった割には、ある程度のディスカッションにはなったように
思うのだけれど．．．手前みそでしょうかね．．．。

なお、当"ロールプレイ"を実施してみよう！、と判断した筆者の反省としては、
・案の定ではあったが、実戦経験が圧倒的に足りない．．．
　⇒機会が有れば、請負・自社内で作業がほぼ完結する案件で実践してみたい．．．
・せめて事前にお題を公開しておくべきだった、かも．．．（タイトルしか事前告知していなかった）

最後に、これは言い訳がましくなるのですが、
今回の定例会には、技術メンバーの半数未満しか出席していませんでした。
（繁忙期の大所帯プロジェクトが複数、ピーク状態だったため）

先月も同様の状態で、5月度は定例会自体を開催中止にしたんです。

さすがに2ヵ月連続で中止はしたくなかったので、コンテンツを少人数でも展開できそうなモノに入れ替えて実施しました。
（"実プロジェクトで利用した技術ベースでのUI･UXデモ"も予定していたのですが、勿体ないので次月に繰り越してもらいました...）

7月度の出席者は改善されるはず。
．．．と言うより、改善すべく、"定例会自体の開催時間帯を見直すべき！"、との案が出されました。

小さなお子さんの子育て中のお母さんエンジニアが何名かいて、常態的に出席出来ていないという問題点への改善も必要という事です。

現在、Googleフォームベースでのアンケートを配信し終わり、回答待ちの状態です。

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

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

6月の全社定例会議では、たまたま書籍紹介的なコンテンツが2つ重なりました。

1つ目は、

"Joy, Inc. 役職も部署もない全員主役のマネジメント"
リチャード・シェリダン(著)

これは、筆者からの紹介。簡単にスライドに要約してデモりました。

当初は個人的に図書館で借りて読んだのですが、予想に反して余りにも面白い！
と言うか、いろいろと刺激的！

そのまま、あれやこれやを真似することは出来ませんが、
・自社や、顧客との関係など、今のままで問題無いとは到底思えない。
・小さなことから実験して、早く間違えて、早く学習することを積み上げる。共有する。
・上長とかリーダーとか顧客とかに、"依存"しない。自身に問う。自分の考えを持ち、議論する。
・"こうしたらどうだろう？" という仮説が非常識なものだったとしても、先ずは小さく試してみる。
・(その他諸々...)

色々な書籍やネット上の情報、セミナーやワークに参加してきた内容とかが、現実的に "ああ、こう活かせば良いのか" と
腑に落ちた感がありました。

これは、この感覚を忘れてしまわない／時の中に埋もれさせてしまわない為に、是非とも書籍を買おう！
会社で買って、皆に紹介しよう！
折に触れて話題に出し続けて行こう！、と思い至りました。

と、読んで感化された本人は熱くなっている訳ですが、
要約だけを聞かされても、恐らくは余りピンと来ないだろうな．．．と思ってました。

作成したスライドの最初でも、
"出来ない、やらない、必要ない、の理由付けばかりを探さないで下さい" と敢えて書いておいたのですが、
話し終えた後の反応も概ね冷めた感じのものでした。
（これ↑は、大いに筆者の力不足によるところが大きいのだろうと思いますが）

まあ、とにかく部分的にでも、1人でも多くのメンバーに読んでみて欲しい。
筆者自身が、機会を探しながら試せることを1つづつでも試して行ければと思ってます。

さて、もう1冊の紹介は、IT-Tips（10分枠）の中で小障子さんが紹介してくれたモノ。

"多動力"
堀江貴文(著)

自身のヒューマン／ビジネススキルを見直し補完する上でも、あれこれと書籍を当たっている中での1冊のようです。

アスペアには、"書籍買い放題"制度が有ります（社費で購入して、保管は個人が行う＆書き込みもOK）。
が、この本に関しては自己投資として敢えて自腹で購入したとのこと。

気持ちの持ち方次第なので、要は有効に活かせれば良いと思います。

さて、たまたま書籍紹介的なコンテンツが2つになった今回の全社定例会。

"こういう事で時間枠が欲しいと要求するのはアリですか？" と問うてきたのは山内さん。
"是非！" と答えると、"それでは次回に30分欲しい！" と、次回コンテンツが1つ即決しました！

自発的なコンテンツは大歓迎です。

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

スパルタンレース参戦！＆高尾山...

アスペアでは、顧客先での開発業務と、自社内（町田事務所）での開発業務が有ります。

2月半ばのある日、とある顧客先（アスペアから社員が5名、パートナーさんやフリーランス（←どちらも元・アスペア社員ですが）2名が業務中）
で、プロパーの方から"スパルタンレース"参加のお誘いを受けたとのこと。

"参加者を待ち受けるのは火、泥、水、有刺鉄線、さらには地獄のような障害物の数々。スパルタンレースは参加者の肉体的・精神的限界を試します。"（主催者Webサイトから抜粋）
．．．ってことで、生半可な気持ちで参加すると、ちょっとヤバいことになりそうです。

弊社社員で、PM補佐的な役割をさせて頂いている（と言うか、遊撃部隊的にやるべきこと、気が付いたことは
何でも言って・調整して、プロジェクトが現場で現実に回るようするぜ！的な立ち位置のようですが...）
2名が参加了承！
顧客先のプロパーの方、他社の方、4名と一緒にチーム参加と相成りました！

自主的に筋トレやランニングで基礎体力作りに精を出す日々。
（業務の方も、特にロールが重い＆多岐に渡るので日々の疲労も結構なものだと思うのですが...。凄い。）

5月27日・土曜日。当日は快晴！

弊社側メンバーが2名、参加者の奥さん2名が応援＆見学に現地（神奈川県内の元米軍基地の広大な敷地）入り。

チームとしては脱落者なしに、全員がゴール出来たようです。

擦り傷、打撲は数々あれども、大きなケガや故障が無くてホッとしました。

楽々制覇！、には程遠かったようですが、事前にトレーニングをしておいたおかげで
それ程の筋肉痛でもなかった。．．．．．とは本人たちの弁です。

感想としてはどうだったのかなー、と思いましたが．．．
"楽しかった！"、"次（10月）までにトレーニングに励む！" と、もう参加することが前提の勢い！

若いよなー！！
．．．．．と言いたいところですが、ウチから参加した2名とも40歳オーバーです。
で、応援だけに行ったメンバーは30代後半．．．．．

気力の問題ですね！　ガッツです！

"楽しそうだから、やってみよう！"、これですよ！

で、話変わって、翌日の日曜日には"高尾山登山"イベント。　本日も快晴！
あ、こちら↑は、アスペア内の別メンバーの企画です。

アスペア社員：男女数名と、子供連れで参加したメンバーもいました。
で．．．．．、昨日のスパルタンレースに参加したメンバーの内の１人が、こちらにも参戦！

さきほど、"それ程の筋肉痛でもなかった" と書きはしましたが、
高尾山と言えども山登りであることに変わりはなく。
さすがに、ちょっと辛かったようです。

アスペアでは、特に"全社員・強制参加！"、みたいな企画（風土）は一切無いのですが、
"楽しいことで羽目を外そう" 的な企画はたまにあり、参加したい・出来る人が参加して、
楽しい・嬉しい時間を共有してます。

と、その辺のことも社員専用Webサイト上の週報の中だったり（←他メンバーから"ステキ！"マークがカウントアップしますね）、
slack上とかに、様々な文章や写真が共有されてます（あくまで自然発生的に、です）。

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