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

 
筆者はアスペアの公式ブログを書かせて頂いていますが、他のメンバーに依頼してもほぼ原稿を書いてもらえない...
良くも?悪くも、自分自身の文章の出来が、そのままブログの性格と質になっている...
 
不安を抱えつつ、全然自信がないままに書き続け、既に不安にマヒしかかっている自分を感じていた。
これを機会に、ワークを含めて学び、何とか改善したい・少しでも自信を持ちたいと考えて参加しました。
(このセミナーを受講して来た割には、"校正が甘い!" とお叱りを受けるかも知れませんが...)
 
参加コンテンツ名/講師/機関
 
 「現役編集者による 人に伝わるライティング入門」~第1回分科会 本とITを研究する会セミナー~
  三津田 治夫 氏(Softbank:出版・IT情報メディア系、プロデューサー/コンサルタント)
  本とITを研究する会
 
実施日時
 2017/12/11(月)-19:30~21:30
 
実施場所
 東京都千代田区神田須田町2-2-2 神田須田町ビル ビリーブロード株式会社 9F会議室
 
満足度
 85点
  (0~100点満点、時間分の価値がどうにか有った=60点、概ね満足=80点)
  ・主題が、紙媒体を中心に据えたモノか?も危惧したが、杞憂だった。
  ・スライド公開が無い割には情報量が豊富&有益だった。
  ・書籍にも有りそうな内容だったが、意外と今回のような網羅的・概観的なモノは少ないらしい。
  ・体系的に知ることが出来、ワークで体感も出来た。
  ・少人数での実施な上に、講師が柔和なので質問も投げ易かった。(比較的活発な質疑が有った)
 
概要・所感
  要点と思われた部分(と言うより、聞きながらのメモそのまま?)を下記に抜き書きします。
  (恐らく、端々に私個人の解釈が含まれてしまっていると思いますがご容赦下さい...)
 
  ・予約枠は10名だったが、欠席者無く全員が出席していた模様。
  ・今回が第1回目と言うことで、前提・基本姿勢・標準的な内容だった。
  ・応用編は、基礎編からは大幅に広がるとのことで、"編集者の領域"と表現されていた。
  ・陥りがちなパターン、心掛ける基本パターンや、ブレない基本思想が必要など実践的な内容だった。
 
  ・ワークは2つ。隣の席の人とワークの成果物を交換し合って講評し合うという形。
    ・3名以上のグループ・ワークではなかったので、思っていたよりは負担が軽かった...。
 
  ・講師の人柄・印象で、セッションの展開も随分と違ってくる(良い意味で)ものだなあ、と感心。
  ・参加者の自己紹介などは無かったが、隣の席の女性は "IT企業・事務職"、"日本の文化・歴史・自然が好き" 系だった。
    ・ワーク時に、自分から相手に質問した。ワークのアウトプットの意図が捉えられなかったので。
    ・"意図的な駄文の例に対して、適切なタイトルを付ける" ワークでは、自分に無い視点を相手の方が持っていたので新鮮。
    ・自分は、駄文の迷彩度に目が眩んでしまい、かなりキツイタイトルを考えた...
    ・"文章の趣旨は、通常は最後に書かれるべき"、なので、最後の段落を読めば大体わかるはず、とのこと...
      ・それでも、例文は酷過ぎて理解不能だった...(著名な方のWeb上の文章らしい)
 
  ・スライド情報が豊富だったが、印刷は無し、公開もしないとのこと。
    ・撮影して画像情報として持ち帰ることが、実質的に必須だったと思う。
      ・"後日公開します"、と言いつつ放置されるセミナーも有るので、保険として撮影は必須だと思う。
    ・結構読み上げてくれたので、録音でも不可能ではないだろうが...後でのテープ起こしは時間効率が悪い。
    ・ズームが効くカメラが必携だと思う。端の席に座ると画像が歪むし焦点がボケ易いので要注意。
    ・シャッター音がうるさかった。マナー違反者が多い!
 
ナレッジ
  ・先ずは "自分が与えたいこと" を徹底的にあぶり出す!;="自身のブランディング" でもある!
    ⇒次に、読み手にとっての価値・実現/成功可能性との表にマッピングして、"書く"ものを決める。
    ↑自身の掘り下げ大切!;1人合宿で籠っても良いくらい...
    ↑自身の軸を定める!;ブレさせないことが大切!
 
  ・マーケティング系の準備も必要だが、↑よりも先にやらないこと!
    ↑先ずは "自分が何を与えたいのか?" をジックリ掘り下げることが先決。でないと外部要因でブレる。
    ↑"ペルソナ" 設定は、ここでも有効なんだな!
 
  ・PC画面での校正はダメ!、フリッカーがノイズになってまともな判断が出来ない(医学的にも証明されている)。
 
  ・他人の意見は大切 ⇒ 意見を求められる人間関係を構築していくことも重要なステップ!
    ↑家族・友人、誰でも良い
    ↑一生懸命な姿勢を示せば、協力してくれる人は結構いるものだ...
 
  ・言いたいことを"言語化する"のは、結構難しい。
    ⇒昔の書籍、外国の書籍などに触れるのも、パターンを増やす糧になる。
 
  ・伝えたい内容に拠るが、"中高校生が読めるか?" を基準にする場合も有る
    ↑これを満たせば、幅広い層の誰でも読める
 
  ・"読み手の気分を想像しながら校正する"(視点を変えながら何度も)。相手に"痛み"を感じさせないか?、等
    ↑"痛み"=心理的なストレス;酷い文章なども含む
 
  ・"文章は読まれない!" (←元も子もない発言だな...)
    ↑媒体に関わらず、改行が増えて、文字数が減っている。
    ↑それでも読者を惹き付ける魅力(セルフブランディング)を出来れば、読まれる
 
質疑応答・他
  Q. モチベーションの維持に、何かお勧めの具体策は?
  A. ブログを書く場合でも、チームを組むとか。相互に目的を合わせ、議論し、チェックし合う。
      心を良い状態に保つことが大切!;悩みとか抱えていたら、まともに書けない
 
  Q. 校正を学ぶのにお勧めの書籍など有るか?
  A. 「校正必携」=校正系の専門書:日本エディタースクール=編集者の養成所
      ↑但し、古い!;勉強にはなる!;余程興味のある人でないと極めてつまらない本だが..
 
  Q. "他人の意見を聞く" ことが大切とあるが、そもそも読者がいないので反応を掴みようがないのだが?
  A. 友人知人・家族、誰でも良い。セミナーの機会などでグループ作っちゃうとか(今回とか)。
      ↑講師もグループに加わっても良いよ!
      ↑人間関係を構築していくこと自体も必要なステップ
 
  Q. 書き手と、読者として想定する相手との年代差が大きい。留意すべきことは?
  A. "言語空間を共有する" は確かに大切 (世代により知らない事象・熟語・漢字)。
      若者用語とか使うことはない (迎合する必要は無い)
      対象者群の共通の趣味・経験、その他etc.を考慮することは必要。相手をじっくり想定して校正する。
 
  Q. 面白いと感じる文章を読んだ後で文章を書くと、文体が似てしまう。どうしたものか?
  A. それ自体は当然だし、むしろ一時的には良いこと。
     ・好きな作家などいる場合、"写経"もアリ!
       ↑プロの作家でも結構やっている。
       ↑一旦自分の文体として習得し、自分流に崩して自分の形に昇華させていく。
 
  ・医師・大学教授などの行動な専門家は、まともな(一般の人が読める)文章を書けない!
    ↑他人から批判されることが無い;専門用語びっしり;論文形式とか
 
その他・資料
  ・ブログ:http://tech-dialoge.hatenablog.com
Dsc00423
.
.開始前の室内。
少人数だったので、質問もし易かった。.
.
.
.
感想
  ・振返ってみると1000回以上もブログを書いて来たが、ただ、ダラダラと書き流して来た感じだった。
  ・1つのアプローチとして、今回教わった方法の主なモノは一通り試してみたい。
  ・校正が甘いことは自覚していたが、改めて反省させられた&改めて恥ずかしい...
  ・自分の文章作成上のクセ・悪習慣を改めて自覚した。
  ・"他人の意見を聞く" を、現実的に難しいと決めつけていたが、何とか実践してみるぞ!と決めた。
    ↑ああ、自分の息子でも良いんだな!、と気付かせてくれたのは有り難かった!
  ・読書は好きだが、今まで以上にジャンルを意識的に広げようと思った。
    ⇒図書館に行って、いつも通り過ぎる/足を踏み入れない書架で、あまり考えずに手に取ってみようと思う。
 


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

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

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

 
今回はセミナーなので、ワークは無しです(ちょっと気がラク...)。
自社と顧客とのコラボで展開している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の取り込みの敷居は大変低くなっているでしょ!?(使えば良いってもんじゃないが)
    ・使った方が良さそうなら、尻込みしてないで使えばよい!
 
  ・現在のレベル・状態を認識することが大切!(7段階の成熟度
    ・何で扱うかはともかく、数値を使う意味を理解して、使っているか?
    ・成熟度が上がらないと高度な施策は打てない!・思いつかない;段階的に上がっていくようにコンサルしている
    ・中間段階を飛ばしてのレベルアップは不可能!
    ・ツールが有ってもナレッジが無いと無理;自力で出来るようになってから、ツール利用や自動化が可能になる!
 
  ・エクスペリエンス・マップを使う!
    ・ペルソナ想定して、当てはめながら検証を繰り返す(ペルソナへの感情移入が必要になる..)
    ・ペルソナの属性をどれだけ用意するか?;用意できるか?;検証の為に必要な属性を見付ける(←検証と実験で分かって来ることも有る)
    ・少な過ぎは論外だが、多過ぎも本質を見失う(そもそも収集にコストが掛かるし、件数が減ったり、対象者が
     疲労して回答がいい加減になったり、主催者側に気を使ったり...)
    ・分析結果から ⇒ 新たに提供したいコンテンツをどうやって用意するの?;結構大変!
 
  ・ペルソナ;感情移入できない場合が厳しい!
    ・例=乳がん保険;本物の該当者を集めて入って貰う;出来ればワークショップをやる!
      =グループインタビューになる!
  ・インタビュー:ネガティブな要素を引っ張り出す;←要改善点=ペインポイント(痛点)を見付ける
    ↑ 言葉の表層に飛び付かず、相手の背景状況なども聞取り(或いは推測し)、深層心理を探る;
      ・何が解決されればペイン(痛み)が改善できるのか?
  ・ルールベース(プログラム固定ロジック等)では効果は限定的 ⇒ 例えばAIを利用する、とか
    ・AIはあくまでツール
    ・テクノロジードリブンじゃダメだよ、と
    ・技術を主張してはダメ!;"使いこなせない方が悪い" などは最低!(ユーザー軽視のビジネスなど有り得ない)
      ・ユーザーが快適に感じるかどうか?、ポイント
 
ナレッジ
 ・ぶっちゃけ、"データドリブンのUXデザイン" は全部重要!
   ・結局、新規ビジネスや施策への着手前に、仮説設定・分析、調査(データ収集)・検証は必須ってことだ。
   ・今回のセミナーでは、リーンスタートアップよりもデータに比重を置いて、具体的な進め方や指標を教わったということ。
 ・"UX" は "UI/UX" とかって並べて書かれていたりするけど、意味の広さ・抽象度・視点とか全く違う!
   ・("UI"はアプリ視点)
   ・"UX"は直訳では"顧客体験"だが、ユーザー視点で、サービスによって波及的に得られる、アプリ外でのアナログ/
    心理的/対人的な体験とか全て含む。
   ・(UXを語るケース・主体により意味の範囲が大きく変わる)
     ・今回のセミナーでは最も広い範囲の定義を聞いた。データ分析(心理分析まで含む)、マーケティング、サービス設計、
      Webデザインまで含む。
     ・(例えばWebデザイナーがクリエイター目線で語る場合なら、アプリ、心理(喜び)、ユニバーサル、辺りまでか?)
 
質疑応答
 Q. ログインを伴わない場合の分析として、どんなアプローチが有るか?
 A. IPアドレスから場所を推定して反応を変えたりとか;その地域でユーザーが望む情報を提示したり..
   簡単な質問を1つだけするとか;1回限りのおもてなしを最大限に行う;ツールが意外と安価に有るよー
   性別の登録が無くても、推測する場合も
   Rtoaster;タグで何となく自動連携してくれるツール
 
 Q. 実際にデータ分析の知見も無い企業に対して、どのようにコンサルしていくのか?
 A. 当然ながらケースバイケースだが、
   例)先ずはチームを構成してもらう ⇒ チームに加わって一緒に活動する:適宜でメンバーにヒアリング→指導 ⇒ (進行)
   例)コンサル側でチームを組んで具体的にやって見せたり ⇒ 段々と顧客企業側に渡していく、とか..
   少し理解できると、興味を示すようになってくる;顧客内で議論が進んだり;、熱を帯びるようになる
   適宜で望ましい疑問を投げてあげる ⇒ 考える道筋を導く;概ね半年くらい掛かるかな..
 
その他資料
 
Dsc00286 会場の様子。
セミナー開始前なので、未だ人が少ないですが。
電源は床に所々アリ。 Wi-Fiは無し。
.
.
.
 
感想
 ・今回も、貴重な学びの機会を頂き、有難う御座いました。
 ・正直のところ、思った以上に対象のスコープが広く、未だ何が分かって・何が分かっていないのか?
   それ自体が自覚できていないような有様ですが、こうして資料を見直し、少しづつ整理をしながら、ほんの少しづつですが
   理解が進んでいるような...気がします。


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

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

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万円/月
   ・余りに安いと、"粗悪なサービスじゃないの?" と思い込まれてしまう危険性がある、失敗だったかも...
 
補足:及部さん
 ・楽天さんなので、今回登壇した中で最大手企業
 ・大企業としての問題・難しさが主に語られている印象...(中小・零細でも共通する中身も有りますが)
 
ナレッジ
 ・ちょっと整理に時間が必要.....(工事中ってことで...)
 ・間違いなく言えるのは、"価値探索・検証は絶対に必要!" ということ。
   ・何度も繰り返さないと、実戦的に活かすのは難しいかも。
   ・アーリーアダプターへのアプローチと同時並行して、アーリーマジョリティへのスケールアップをどうするか?も考える。
   ・スケールさせる仕組みも考えておかないと、意外と立上りが早かった場合などに、一旦不評を買うと顧客は戻って来ない。
 
質疑応答
 ・評価系の話を聞いてみたかった:(話し手からQ)
   ・市谷:評価なんて上手く行った試しがない;これから変えようとしている;"目標とかいいから、やったらプラス!"
   ・失敗多いけど、プロセスは良い場合とかどう評価するか? ⇒ プロセスも貯金になるよね
   ・社員数20名;評価制度無し;企画を多く出した者勝ち;社内風土化させてる
 
 ・企業文化:(話し手からQ)
   ・モブ・プログラミングで人材採用;これからやろうと思ってる;文化の合う人を採用する
 
 ・開発者が"作る"事にしか関心が向かないケースが多くて困っている
   ・自社の課題とか、見える化してる;議事に話題に出したり;効果出てない...
 
 ・新規企画・開発の期間割合の目安とか有る?
   ・一般論での正解なんて無いだろう;自分達で繰返すしかなかろう;自分達の答えを探す
   ・全体=短期の方が良いかも;基本、新規ビジネスなんて余計なもの的な位置づけだったり?!;
   ・上の人に提案するときは数字を示す;天からの声の場合は検証して回答する
 
実例様々..
 ・新規事業のチームメンバーが如何にも寄せ集め;人材の掃き溜めになってたりする;
 ・どうやってもスピード感出ない
   ・大企業のあるあるだね(手続き・始める前に成功を示せ!的な);企業側の期待と違っているのだろう;回るはず無い;
   ・奇人・変人・暇人、が集められる ⇒ 後者の2種類はいずれいなくなる
 ・メンバーには若くて染まる子を選ぶ;技術レベルとか必ずしも関係ない
 ・小さい会社で人選の余地が無い;POの熱量で決まる;求心力を如何に保つか;若い子の方が良い(信じ易い)
 
その他資料
 Dsc00120 会場の様子:休憩時間に撮影:実際にはこれより更に後ろに椅子だけが並べられた席が有ります(そこも満杯)。
 ざっと見た感じ、8割以上の人がMac派でした...;筆者はメモ用に旧式VAIO-X;
 
電源は提供されました(Wi-Fiは無し)
 
 
感想
 ・本当に貴重な機会を戴けて、ひたすら感謝・感謝です!
 ・"失敗は学びの機会だ!、後悔や挫折する暇があったら学べ!" ってのがヒシヒシと伝わりました。
 ・とは言え、人間だから落ち込むし、組織だからお金を出すのに慎重になるのは避けられない。
 ・そのまま潰れてしまわないように、失敗を共有して学習の機会も共有しよう!ってのは素晴らしいです。
 ・日曜日にも関わらず、様々な準備と後処理を含めて多大な時間と手間を掛けて頂いた関係者の皆様方には、本当に感謝です。
  有難う御座いました。
 


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

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

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

 
以下に、メモ形式で恐縮ですが、要点のみ記載させて頂きます。
もし万が一、参加された方、関係者の方がご覧になり、"違うよ!"など有りましたら、ご指摘頂ければ幸いです。
 
はじめに
 ・"OKR"をPOStudyで扱うのは初めて!;基本的に組織論である;社員のモチベーションに影響する
 ・今回は緩い段階をゴール地点にしている
 ・参加者のレベルやタイプが様々だから(通常は同一会社の人を集め、事前理解が必須)...;
 ・とりあえず全員が全力出してワークしてね!
 
OKR認定試験・某社で行っている
 =OKR Japan;資料が優れているので今回のワークで(改変しているが)使わせてもらう
 PDFダウンロードできる
   ↑このスライド最後のページにPDFリンクが有る(できるOKR_v1_1.pdf)
 
当日の資料について
 ・設定テーマ(紙の資料)は、別セッションを手伝って貰っている各社(2社)社員に作成してもらった;
 
-----[以降、概ねスライドの順に進行]--------
(話の内容は、結構スライドと違っていたりした...)
 
>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)、資料を見つつネットを調べつつ、怪しい記憶も手繰りつつ復習しています。
何らかの形で、社内で必要な:関心のあるメンバーと共有しようと思っています。
 
20171108114058 あ、コンデジも持ち込んだのですが、撮影している余裕が有りませんでした...。
 
ただ、入室・登録確認時に、"POStudy"シール(3cm四方くらい)を1枚頂いたんですけど...
これって何に使えば良いのだろう??
名刺の裏にでも貼れってことか知らん?
NotePCにペタペタとシールを沢山貼る人がいますが、そんな感じにしろと?
まあ、お好きにお使い下さいって事なのでしょうが、特に何の説明も有りませんでしたね...。


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

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

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

自社内でもワークショップやハンズオン、勉強会などを企画・実施していますが、
やっぱり社外の人と接する機会は大切です!
 
ワークにしてもセミナーにしても、やはり場数を踏んだ著名な方が実施するコンテンツは、質の次元が違う!
ということも実質的にありますし。
 
と言うことで、社内コミュニケーションを中心としたslack(有料コース)運用の中で、
社外セミナーなどの紹介チャネルを設けてます。
(特定個人にお勧めのコンテンツの場合には、slackDMで個人宛に連絡してます)
 
slack上で紹介・広報したセミナー類は、別途Googleスプレッドシートにも情報集約しておき、
広報範囲・連絡先(DM連絡の場合)、参加意思の表明者、実際に参加した人、の情報を記録しています。
 
.....が、
参加者少ないっ!
 
いても、同じようなメンバーが参加し続けてるし、
これじゃあ何の為にわざわざ外部セミナー告知してるんだか分からない!!
 
告知する時は、
どんな人に推奨したいか、費用が掛かる場合は会社負担するケースを増やし、内容の重要度によっては
業務時間扱いにするから!と付け加えたりしてますが、
応募少ない.....
 
このまま勝手にセミナー告知を続けていても仕方が無いので、一度、定例会で出席者達にリアルタイムで聞いてみたことが有ります。
 
以下、その時の意見。
・常連が出席していそうで、場違いになりそうで不安。
・人見知りなので1人では行き辛い。
・意識高い系の人ばかり集まりそうで、自分の不見識が恥ずかしくなりそう。
・時間帯が合わない、予定が立たない(育児の都合で無理な女性エンジニアもいる...)
 
あーーーーーーー........
 
気持ちは分かる。
 
分かるけど、そのままで良いの?
それに、そんなに、もの凄い人ばっかりが参加するわけじゃないよ(企画による差は大きいのでしょうけれど)。
 
ワークショップやハンズオンだと、"恥をかく"(?)ってシーンも有るかもだけど、
セミナー形式だったら関係ないでしょ??
 
筆者(50歳オーバーです...)も、そんなに多数のイベントに参加して来たわけではありませんが、
SCRUM系の終日イベントに参加して、全コンテンツがワーク形式でへとへとになったり(でも超面白かった!)、
特定技術や開発プロセス系のセミナーやワークに参加したりして、自社内で情報共有をしたりして来ました。
 
自分自身の経験の中で、社外イベントに参加して最も有意義だと思えるのは、
やはり "社外の方たちと一緒に小さなチームを組んでワークをすると、いろいろととっても刺激的!"
ということです!
 
これは、どんなに頑張って自社内に情報だけ持ち帰って、対面での共有の機会を持っても(イベント時と同じように、
ワークショップの形を模して実施したとしても)得られない体験感覚です。
 
"1人だと行き辛い.."って人の為に、
"気になったイベント"が有ったら、slackの機能で絵文字を付加できる(facebookの「いいね」ボタンが複数から選べるみたいに)
ので、注目顔のアイコンを付けるようにして、2人以上のマッチングを誘発するようにルール付けしたりとか...
.....しましたが、数ヶ月やってもマッチングは成功せず、
そもそも注目アイコンを付けてくれた人が僅少であるとか、
もう止めるか?  要らないか?  意味無いか、全然ダメか??
 
...と自問自答しましたが、
"当日に行けなくても、開催後にスライド情報や関連記事が公開されるので、追って見ている"って人もいたりして。
 
うーーーーーーーーーーーーん.........
 
自分が出ればいいんだよ!
 
そう。 前から思ってたけど、告知ばかりして、現場業務で多忙で疲れているメンバー達に一方的に参加を求めるよりも、
先ずは自分が参加すべきと思った企画に、自分が参加すればいいじゃん!
(体調の関係で見送ってたんですが、少し良くなって来たし、動かなきゃ変わらないし...)
 
と言うことで、
先ず近々では、
 
 
 
...の2つに申し込みました。(勿論、slackチャネルにも告知済み)
 
ついでに、
"こんなイベントに参加するから、何か質問してみたいこととか有ったら連絡頂戴ねー"と書き込んでおいて、
Googleスプレッドシートに書き込んでもらえるようにしておきました。
 
イベント内容に関しても、主催者側のOKを戴ける範囲で、このブログ上でも共有させて頂こうかな、と思っています。


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

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

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

筆者は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 形式のデータを、ホイホイと操作できる開発者は滅多にいません...)
 
意外と身近なところ(既にライセンスを所有していて、利用もしているツール)に、有用な機能があったりするものですね!
 
ケースバイケースではあるでしょうが、とりあえずの選択肢が増えることで、開発者もデザイナーさんも、少しだけ幸せになれるツール・機能は
本当に有り難いです!


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

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

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

いろいろな企業で有償の各種セミナーを企画・開催しています。
 
アスペアでも、以前はいろいろな有償セミナー(個別だったり、比較的軽量なコースが多数セットになっていたり...)に
参加して来ました(コース紹介の社内通知・配信は筆者が行いましたが、参加は各人の自由意志です)。
 
しかし、どうも内容的に余りパッとしない...。
わざわざ参加する時間を取るなら、その分を自己学習に充てた方が効率的だったり・意義が有ったり、参加価値は微妙?...というケースが多々...。
 
それよりも、DoorKeeperやPOStudy、関連情報に敏い人をtwitter上でフォローして情報を追っていくと、
有益な無償セミナーが多いことに驚かされます("ハズレ"も有りますが...)。
(特にDevLOVE関西など、西日本の動きがとても活発なのには羨ましさを感じますが...)
 
開催時刻も、就業後でも参加可能なように配慮され、19時以降の開始だったり(終了も21時以降になりますが)、
場所的にも23区中心部付近が多く、移動も概ね顧客先から近いです。
 
"これはお勧めだな!"、"あいつとか、あの子辺りには参加して欲しいな..." などと思うコースを、
slack上の"出ようぜ!社外セミナー!!"のチャネル(←名前はウソですが..)に紹介します。
 
・どんな人におススメか?、
・概略どんな内容か?(コース名のイメージが、実質的な内容を反映しない場合が有るので)、
・"業務扱いでOKだよー!"(月報に"勤務"時間として計上して良いよ!)とか、
・参加費用が掛かる場合、"先着何名までは会社負担にするよー!"とか、
いろいろ情報流して参加を促してます。
 
自社内でも、定例会の場を利用してセミナーやワークをしたりしますが、やっぱり同業他社のエンジニア・他ロールの人との交流も
とても刺激的だし重要だと思ってます。
 
現在の業務に必要なもの、これからの数年で確実に押さえておかないと拙いもの、
トレンドになるかは分からんけど楽しそうなもの、
バリバリの技術系、開発プロセス系、ビジネス立上げ系、
色々と、敢えて傾向を分散させてます(メンバーの関心も様々ですからね)。
 
ですが、全員がWeb/インターネットの仕組みを前提としたビジネス開発に関わっている(社内外を問わず)ので、
どこのプロジェクト/プロダクトも多忙です...。
 
業務時間数が必ずしも長くなくても、頻繁な要求・仕様の変更、各種の調整(結果がすぐに出るとは限らない)、緊急対応などで
かなり密度が高く&タスクスイッチが多い・並行度の高い時間を過ごしています。
当然ながら、疲労しますね。
 
やっぱり、現実的に時間的・心身的に幾らかでも余裕が無いと、社外セミナー、とくにワークショップやハンズオンなどは、
面白いけれど消耗も激しいので、意識として参加の敷居が高いのも理解できます。
 
.....このところ、参加率が低い.....
 
うーーーーーん、仕方が無い。
メンバーに対して、無責任に?紹介ばかりしていても埒が明かない。
自分自身が参加できるものは、出来るだけ自分(筆者)が参加しよう!(...健康上の都合もあるのですが...)
 
という事で、早速行って来ました!
 
 
ギルドワークス株式会社・代表取締役・市谷 聡啓 氏が講師として登壇されました。
 
目黒の(株)アカツキの会場はとても広く、カーペット敷きの床には多数の円形クッションが。
後ろの方に椅子も1列並んでいました。
 
筆者は近視なので(度の強い眼鏡を掛けたくない)、スクリーンが見易いように、クッションエリアの中程に陣取りました(靴は部屋の入口に有った靴箱に脱いできた)。
 
同氏はtwitter上でもフォローさせて頂いてますし、同社のWebサイトも拝見していたので、大体の話の流れとしては意外な点は有りませんでした。
 
同氏からのお話は小一時間程度で、後は質疑タイム。
 
内容的には、少なくとも表面的には理解できるけど、"本質的な部分は実践して痛い目見ないと分からんな..." と感じました。
それにしても、質問の中身が濃いのに驚きます。
 
セミナー中でも言われましたが、"自分(達)が、何を分かっていて、何を分かっていないのか?" を知ることが重要!、と。
 
これ、自己矛盾なんですよね...。
CMMIのレベル5(最高レベル)とかでも、"未経験の事象に対しても既知のメタ的な方法論からアプローチし、問題解決が可能" と
定義されていたりしますが、まあ、それと同様じゃないかと思います。
 
で、具体策の1つとして、"ギルドワークスが支援するプログラムが有る"というご紹介。
うんうん、もっともです。
 
いや、一緒にやらせて頂いたとしても、今のアスペアの最高のメンバー集めて対応しないと、吸収効率が悪いと思います。
って言うか、実戦的な要素が何も身に付かない危険性すらありますね。
 
そもそも、アスペア内の現有メンバーが、本当の所どんなことを・どんなふうにしたいのか?
本音の本音を改めて、個別に聞いてみないと分からない気もします。
(今回のお話は、"価値0(ゼロ)→1にしていく" が中心ですから)
 
会社的に、「こうしたい!」、「これが出来ないと生き残れない!」って言ったとしても、
各個人の腑に落ちていないと・インセンティブやモチベーションに結び付いていないとダメでしょう。
 
次回の定例会(9/22)で、ちょっと長めに時間枠を取って、筆者からの話もしつつ、皆から色々と話を聞いてみたいと思ってます。
 


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

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

ヘッドレスブラウザとSelenium3

今回もQiitaネタです。
 
 
そして、今回も社内(協力して頂いているパートナー会社の方とか、フリーランスの方を含む)コミュニケーションツールとして
利用しているslack上で呟いてみました。
 
 筆者 [14:42]
 ▼UI含めたテストでは今後の必須知識!、なのかな...(headless Browser)
 レンダリング無しならテスト速いんだろうなあ...
 (上記URLを貼り付け)
 
 ○○○ [14:42]
 現場(客先)のslackにも全く同じ記事が貼られてた。
 
おおー!、見事に社外にいるメンバーからの即時応答!(DM:DirectMessageじゃないのに...)
 
やっぱり自動テストには関心が行きますよね。
レスの有った"○○○"さんは、自社企画・展開のサービスを開発してビジネスを立上げ中の顧客先で開発作業を支援してるメンバーです。
 
UIの自動テストは、従来だとWebブラウザを起動して画面操作のイベントを起こさせて...と、フツーにWebブラウザの画面が
勝手に(=指定通りに)起動されてパラパラと画面遷移していきます...
が、実画面を表示する時間もかかるので、レンダリング時間も自動テストの中に含まれてしまいます。
 
結果、CI・自動テストは良いんだけど、"とにかく実行に時間が掛かる"のがネックでした...。
実行時間のコストを考えて(勿論、UIテストコード作成・メンテの必要性・メンテコスト・適用価値の総合判断もしますが)
画面展開を伴うテストは範囲を限定しようという現実的な制約というか、技術的な圧力が掛かってしまうケースも多々あったかと思います。
 
UIの自動テストを行うPCのグラフィックス系ハードウェアも高性能なパーツにしたりとか...
でも、ヘッドレスブラウザなら格段に効率が上がるだろうと思われます。
(実証していないので断言できないところが、情けないと言うか申し訳ない所ですが...)
Selenium3も、是非使ってみたい!
 
変更や、様々な部分での"必要と判断される変更"を、躊躇せずに行える(少なくとも自動テストの所要時間を余り気にせず)
状態に置くべきですよね。
(勿論、開発対象の各種特性によって判断や基準は違ってくるとは思いますが)
 
まあ、ヘッドレスブラウザも人間(組織)が作ったモノなので、何処まで信頼できるかは分かりません。
 
しかし、存在を知りながら手も出さず・評価もせず、では、改善の可能性にも至りません。
 
小さなチケットを切ってでも、簡易評価をして環境構築・テスト・評価をしてみるべきだよねーと思います。
勿論、得られたナレッジはslack上(&その他の社内的な手段を使って)で共有します。
 
その為には、評価してもらう時に、メモでも良いから必ず要点を残してもらうこと!、ですよね。
チケットなら、それに紐付いて残るし、別枠でナレッジ集約のページなど(プロジェクト/プロダクト横断的なナレッジ集約ページ)
にも掲載していけますし。
 


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

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

AWS認定試験を受けよう!

Qiita(キータ)
 
IT業界、特にコードを現役で書いている人で、知らない日本人はいないんじゃないか?
と言えるくらい、著名で有用なWebサイトですよね。
 
 
アスペア内でも、IT系の各種認定試験、他に簿記や色彩検定なども報奨金の支給対象にしています(適宜で対象や報奨金額の見直しもしてます)。
受験料も、同一試験に対して最大2回までは会社負担としています。
 
認定試験にパスする:合格するという点そのものには、大した意義は無いと思います。
目的は、"基礎から思想を含めて体系的な理解をする" こと。
 
枝葉末節な "操作の断片の幾つか" を知っているだけではダメで、
体系的な理解をしていることの客観的な証明指標として、"認定試験に合格する" という基準を利用しよう、という事です。
 
認定に合格した後も、2年に1度の更新受験が必須になってますね。
どんどん拡張や仕様変更の為されていくものなので、当然でしょう。
 
現在のアスペア内のメンバーは、現状で一般的に求められる:習得済み・経験済みが望ましいクラウド系の知識が全般的に不足しています。
 
"今さらかよっ?!"、と思われる方も多いでしょうね。
 
今さらなんです.....。
既に遅きに失している感も有るのですが、放置も出来ません。
クラウド系サービスは、大手に限らず様々なサービスが展開されていますが、市場占有率が極めて高いままに堅調で、
かつ弱まるスキが見えないAWSは、必須前提で押さえておきたいベンダー/技術要素です。
 
先ずは試しに、社内のコミュニケーションツールの1つ:slack上で呟いてみました。
 
 筆者 [10:38]
 ▼これは、受験費用も報奨金も会社で出したい、って言うか出すべきだな!
 2017年度・最大のおススメだと思う!
 
 ○○○ [10:41]
 えー!こんなのあるんですね。やってみたいです!
 LPICと同じぐらい役に立ちそう
 受験するか?はさておき、対策本を会社で買っていただいてもいいですか?
 
 筆者 [10:44]
 勿論、OKですよー! "書籍買い放題"制度の対象として、立替宜しく・後日清算・当面は個人保管(=利用)、のパターンでOKです!
 
で、早速、現時点での報奨金水準を直近で一通り見直してくれたグループ長さんにお願いをしました。
 
 筆者 [10:59]
 @◇◇◇ 済みません、お願いが1つ。
 報奨金制度に、「AWS 認定」を是非加えたいですー!
 受験費用だけでなく、報奨金も是非出したい!(現状のアスペアでは出すべき!)
 最低でも2017年度内は、特別推奨で+αで上積みしたいくらい!(って言うか、マジで上積み交渉したい⇒○○(←社長の名前)さんへ)
 <お願い> ◇◇◇さんの方で報奨金見直しをして頂きましたが、同じ尺度で、こちらもザっと見て頂いて、大体の報償金額を出して頂けませんか?
 急ぎません。 宜しく、お願い致しますー
 
 ◇◇◇ [11:55]
 わかりました。
 
という事で、実際には筆者と社長で話をして、具体化に向けて進んでいるところです!。
 


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

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

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

以前の全社定例会の中で、書籍「Joy, Inc.」の紹介をしました。
 
その後、暫くして、情報収集用に持っているtwitterアカウント上でフォローしている方を通して、
「Joy,Inc.」で描かれているメンローイノベーションズ社に、実際に見学ツアーに行った人のレポート(長文・写真多数)
の存在を知りました。(記事)
 
感じたこと:
 ・書籍ではモノクロ写真のみだったので分かり難かったが、カラーだと臨場感ある!
 ・入社の浅い人でも案内役として活動するって本当なんだな!
 ・"Chief Motivation Officer" なる役割が有るらしい、面白いな。
   ・想像するに、役割が先に出来たんじゃなく、能動的に実績を積んでいた人に周囲が役割名を付けたんだろうなあ...
   ・犬が2頭いる...、ネコを執務室に入れている企業をWebサイトで見たことも有るが、さすがに猫はリスキーな気がする...
 ・"素早く失敗して、学びを得ていく" は、しつこく教えないとなかなかできない!、んだそうだ。(そうだろうなあ...)
 ・"通常20-30%ほどのリソースを安全余裕をとっておく" が、顧客にも見える化しているんだそううだ。凄い!
   ・下手をしたら、"どうせ結構なバッファ取ってるんでしょ!?、だったらこれもやってよ!" 的な話になりそう..
   ・↑:勿論、そこも上手く出来ているってことだろう。
   ・"20~30%"って具体的な数字は書籍の方には書かれていなかったので、ほうほう、と思った。
 ・ペアプロ、隣のペアとの距離近い!、これで隣の会話が邪魔にならないって、凄い集中力だなあ...
 ・人材管理的なボードがあるとは!
   ・中身は頻繁に、皆で話し合って決めているそうな。
   ↑これは納得。年に2~3回とかの考課で処理するのは無理。忘れてしまう。
   ・プロジェクト完了時とか、より短いスパンで見直した方が現実を望ましい形で反映できると思う。
 ・離職率は米国平均値である、という点はちょっと意外かな。もっと低いのかと思った。
   ・米国内のIT系人材の流動速度はかなり早いと聞いているので、まあ、メンロー在籍も経験値の内の1つと割り切っているのだろう。
   ・戻って来る人材も、推奨してるしそれなりにいる様子。ウチは今現在は1人だけだな...
   ・"小さな失敗をより早く行い、より多くを学ぶ"、はコストを伴うはず。
     ・まあ、ペアで業務を行う(役割に関係なく?)ので、ナレッジが一気に消えることは無い、のだろう。
     ・その意味でも、"ペア前提"文化はリスクヘッジ・投資効果の逸失を抑えているんだな。
 ・余りにも当然の前提だけど、英語で質疑できる人のレポートである...
 
書籍に書ききれなかっただけなのか、原書の執筆以降に"実験"して"運用されるようになった"ことなのか?
 
後者もいろいろと有りそうな気がする、と言うか、そう思わずにはいられない。
どんどん変化し、成長し続けているのだろう。
 
自分達なりにも、出来る部分は見習いたい、実験・実践して行ければ!という気持ちが湧き上がるけど...
 
1人で盛り上がっていてもどうにもならないので、皆が(顧客も、エンドユーザーも、各技術者も、技術者の家族も...)
喜びを感じる・幸せになるように、
どうステップしていけば良いのか?、目標を粒度と時間軸で細分化して、小さなこと・出来ることから
先ずは自分が動いていくしか無いよね。
(機会を伺いつつ、巻込めそうな人・時間を取り込んでいけるように様子を伺いつつ...)


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

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

Mr.山下のUI講座(React.js+)

9月の全社定例会では、山下さんが React.js & MetalUI の補完的な技術説明を行ってくれました。
 
"補完的な"ってのはどういう意味か?と言うと、
実は前回(8月)の定例会でも説明してくれたんですが、質疑が多く、定例会自体の時間枠を超えても収まりそうになかったので
9月に延長・第2回目、として実施してくれたわけです。
 
現状のアスペアのメンバーでは、Webフロントエンド周りのトレンド近辺の技術は弱めです...
残念ながら...
 
自社内には、デザイナー兼プロダクション、ディレクション的な、要は要件側とサーバーサイド開発側の
橋渡しを行いつつ全体進行を促す・UI側タスクの配分調整なども行えるメンバーが1人(女性)います。
 
Webフロント周りで比較的強いのは、山下さんを含めても2名だけ。
フロント・デザインが出来るのは1名だけという、何とも心許ない体制です.....
 
F1000165 あ、話がずれましたが、React.js 関連の解説・質疑は、今回も予定時間を順調にオーバーしました。
 
山下さんに拠れば、要点は
コンポーネント指向である、"state, props, context" を押さえれば大丈夫・それ自体は難しいものじゃない。
 
言うまでもなく、Rect.jsはSPA(Single Page Application)の為のJSライブラリであり、ページ遷移はそれ自体ではサポートしていない。
(ページ遷移を伴うなら react-router を使おう、という話)
 
見てくれをどうこうしてくれる訳ではないので、別にライブラリ(山下さんの実務例で行くと MetalUI)を組み合わせる。
 
質疑で時間オーバーする位なので、参加者の関心は高いと思うのですが、実務で利用しない状況だと
&業務負荷が量的に・或いは質的に重いと、なかなか独習・習得までは手が回りませんね...
 
技術的なトレンドを追いさえすれば良い、という訳ではありませんが、旧技術のままに埋もれてしまってはIT業界の中では生き残れません。
 
スキルの要素・キャリア的な各人の指向性を考慮しつつ、強みを強化する、必須要素内に凹みは作らないよう
案件の確保(表現はアレですが案件の選別)や人の配置・ロールの割り当てをしていかないといけません。
 
各個人として見た場合に、"同業他社で、多くの会社から欲しがられる"(十分通用する)人材であって欲しいと思います。


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

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

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

前回の定例会の中で、山内さん自ら立候補した上でのコンテンツ。
 
"書籍紹介" ということだけは、事前に分かっていました、が.....
果たして何を、どんな理由で取り上げるのだろう??
 
F1000155_2 フタを開けてみると.....
対象書籍はリーダブルコード

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

 
業界内では著名な書籍で、多くの方に読まれていることと察しますが、
"より良いコードを書くためのシンプルで実践的なテクニック" を集めたものです。
 
Amazonのサイト上で見ても、とても高評価!(低い評価がごく僅かの割合しかない!、というのも珍しいです)
 
お勧めなのは分かる!
 
分かるけど、敢えて定例会で取り上げたいってのはどうして??...と思ってましたが...
 
Book2Book3Book4Book5 何と、"解説"を紹介するという!
 
「実際にやるとぶつかること」の部分が必読だよ!
是非、先に解説(ココ↑)を読んでから本文を読んだ方が良いよ!、というのが趣旨でした。
 
"読んだだけでは綺麗なコードを書けるようにはならない"
 "そもそも、どこが直すべき箇所かわからない"
...という当たり前の事が書かれている。
 
"まずは何をすればいいの?" ⇒ "実際にやる!"
具体的には、何をどうすれば良いのか?、に関しても、解説に書いてあるよ!、と。
 
それを先に読んでから、本文を、各人の関心のある部分から(考えながら)読む方が良い、ということでした。
(その方が、時間の有効活用度が高くなる:同書籍をより深く活用したことになる)
 
小説などの創作物の場合だったら、解説から読んでしまったらつまらない。
(でも、そういう方もいるのでしょうね。解説内に敢えて"先ずは本文を先にお読み下さい"と書かれている場合もありますね)
 
技術書の場合なら、
"こういう視点で考えながら読むといいよ"的なことは、出来れば"まえがき"とかに書いてあると有難いですが、
そうとも限りません。
 
増してや、ネット上で高評価の書籍だったりすると、普通に先頭から読んでしまうのが人情です。
普段なら目次の構成やまえがき、解説などから慎重に読み進め(品定め)してから入手する人でも、です。
 
なるほど、こういう書籍紹介のパターンもアリなんだなあ...とも感じさせられました。
面白いです。
 


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

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

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

今年4月の頭から、第二新卒的に転職・入社して来た新人君の社内研修が、7月初旬で一旦終了しました。
 
新人研修と知っても、言うまでも無く、その人の知識・経験値に応じて研修の実施内容やペースが必然的に違ってきます。
 
漏れなく、無駄なく、が原則ですが、
そもそも入社時点での練度によって、研修期間終了時の目標到達状態・レベルなどの設定も違ってきます。
 
F1000150 今回の場合は、1年間の社会人経験は有りますので、マナー研修など個別には設定せず。
専門学校を出て来ているので、"コンピューターが動く仕組み"やら、"プログラムを書いてコンピューターを動かすこととは?"、"処理の手順を組み上げる"、etc.の基礎は不要です。
 
が、"アプリケーションやシステムの開発は初めて"、なので、"DBもWebも知識が無い"状態。
前職で、ツールとしてPythonは少し触ったことがある。
 
ということなので、研修の要素群と到達レベルの設定からして、模擬開発を含めて3ヵ月間を想定しました。
 
少し実戦向けの補完カリキュラムなどを足しながら、7月上旬には入社時研修は完了しています。
 
その後の最初の定例会が7月度(7/21)になりましたので、そこで研修レポートを発表して貰いました。
 
研修レポートは、研修者本人と研修内容・メンターによってレポート内容や方向性が違ってきます。
"必ずこの形!"というのは決めていませんし、決め打ちできるもの・すべきものでもありません。
 
今回の研修では、言語・フレームワーク的には Ruby on Rails だったのですが、諸事情があって、メンターが途中で入替ってしまいました。
特に、最後の模擬開発のメンターは RoR 未経験だったので、研修者本人にはちょっと申し訳ない対応になってしまいました...。
 
窮余の一策として、RoR実務経験のあるメンターがオンライン(slack)でサポートするという一幕も有りましたが、やはり効率は良いとは言えないですね...。
(ソースレビューもオンラインで行ってくれた)
まあ、全く無いよりは格段に良かったと思いますし、オンラインでサポートしてくれた側にも負担が掛かったので、
申し訳ない&とっても感謝していることに変わりはないのですが...
 
レポート当日は、パワポを元に報告してくれました。
模擬開発で作成した小さなアプリの動きも披露しつつ、です。
 
この記事に、本人が作ったパワポのページを画像化して貼ります(自己紹介ページだけは省きました)。
 
Repo01Repo03Repo04Repo05 最終段階でのメンターが、何度もレポートの練習・指導をしていたのが印象的でしたが、
結構良い形・内容になってるんじゃないかと思います。
 
模擬開発に関しては、方針的に悩ましいところも有るのですが、
実務の一部:実際に顧客に納品されるコードを書く方がモチベーションが上がるのではないか?、とか。
 
Repo06Repo07Repo08Repo09 しかし、メンターが張り付いていたとしても、慣れない人間が納品用コードを書くことに対しての不安感は
相当のものだと思います。
 
それに、実際のシステムの一部で研修を行う場合、全体仕様が見え辛いと思います。
仮にも"実際に使われるアプリやシステムの一部分"なので、結局、自分がどんなプロダクトに対して、
何処でどう動く何を作ったのか?、どう貢献しているのか?、見え辛いのでは意味が乏しかろう?、と。
 
Repo10Repo11 それよりは、顧客に使われることは無いとは言え、仕様は事前に決まっている、機能も構成もモジュール構成まで全体が見えるし、自分で作る。
機能追加や改修課題、リファクタリングなども、自分でこなす経験をさせる方がベターだと考えています。
 
色々と悩む機会・要素が増える面もありますが、"どうしてこうなんだろう?"、"もっと良くならないんだろうか?"、いろいろと悩んで欲しいと思います。
 
当面はメンターは継続担当しますし、先に担当したメンターもオンラインや定例会の時などに対面でフォロー
してくれています。
と言うか、熱い質問を投げ続ける新人君を見ていると、"ああ、嬉しいなあ"と思いますね。
 
"自律的に考える"⇒"疑問・質問が生じる" のは、とっても良いことですから!
 


★クリック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)

スパルタンレース参戦!&高尾山...

アスペアでは、顧客先での開発業務と、自社内(町田事務所)での開発業務が有ります。
 
2月半ばのある日、とある顧客先(アスペアから社員が5名、パートナーさんやフリーランス(←どちらも元・アスペア社員ですが)2名が業務中)
で、プロパーの方から"スパルタンレース"参加のお誘いを受けたとのこと。
 
"参加者を待ち受けるのは火、泥、水、有刺鉄線、さらには地獄のような障害物の数々。スパルタンレースは参加者の肉体的・精神的限界を試します。"(主催者Webサイトから抜粋
...ってことで、生半可な気持ちで参加すると、ちょっとヤバいことになりそうです。
 
弊社社員で、PM補佐的な役割をさせて頂いている(と言うか、遊撃部隊的にやるべきこと、気が付いたことは
何でも言って・調整して、プロジェクトが現場で現実に回るようするぜ!的な立ち位置のようですが...)
2名が参加了承!
顧客先のプロパーの方、他社の方、4名と一緒にチーム参加と相成りました!
 
自主的に筋トレやランニングで基礎体力作りに精を出す日々。
(業務の方も、特にロールが重い&多岐に渡るので日々の疲労も結構なものだと思うのですが...。凄い。)
 
18670884_1995891537300959_28174979718740161_1995891433967636_586335761 5月27日・土曜日。当日は快晴!
 
弊社側メンバーが2名、参加者の奥さん2名が応援&見学に現地(神奈川県内の元米軍基地の広大な敷地)入り。
 
チームとしては脱落者なしに、全員がゴール出来たようです。
 
擦り傷、打撲は数々あれども、大きなケガや故障が無くてホッとしました。
 
18813418_1995891397300973_380081859 楽々制覇!、には程遠かったようですが、事前にトレーニングをしておいたおかげで
それ程の筋肉痛でもなかった。.....とは本人たちの弁です。
 
感想としてはどうだったのかなー、と思いましたが...
"楽しかった!"、"次(10月)までにトレーニングに励む!" と、もう参加することが前提の勢い!
 
若いよなー!!
.....と言いたいところですが、ウチから参加した2名とも40歳オーバーです。
で、応援だけに行ったメンバーは30代後半.....
 
気力の問題ですね! ガッツです!
 
"楽しそうだから、やってみよう!"、これですよ!
 
Dsc_0103 で、話変わって、翌日の日曜日には"高尾山登山"イベント。 本日も快晴!
あ、こちら↑は、アスペア内の別メンバーの企画です。
 
アスペア社員:男女数名と、子供連れで参加したメンバーもいました。
で.....、昨日のスパルタンレースに参加したメンバーの内の1人が、こちらにも参戦!
 
さきほど、"それ程の筋肉痛でもなかった" と書きはしましたが、
高尾山と言えども山登りであることに変わりはなく。
さすがに、ちょっと辛かったようです。
 
アスペアでは、特に"全社員・強制参加!"、みたいな企画(風土)は一切無いのですが、
"楽しいことで羽目を外そう" 的な企画はたまにあり、参加したい・出来る人が参加して、
楽しい・嬉しい時間を共有してます。
 
と、その辺のことも社員専用Webサイト上の週報の中だったり(←他メンバーから"ステキ!"マークがカウントアップしますね)、
slack上とかに、様々な文章や写真が共有されてます(あくまで自然発生的に、です)。
 


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

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

ただいま研修中:タスクの粒度は?

4月頭に中途入社した新人さんが、絶賛・研修中です。
 
予定・進捗などは、執務室の壁(真っ白です)を"かんばんボード"として利用し、
研修内のタスクを付箋で表してます。
 
マグネットシートを任意に切り貼りして、エリアの名称を書き込んだり、エリアの境界線を作ったり。
ちなみに、朝会は町田事務所にいる全員が(関与しているプロジェクトが別でも)一緒に、立って行ってます
研修中の彼も、当然、一緒に参加します
進行役は日単位で持ち回り。忘れないように、"朝会当番"と書いた小さな立て札をその人の席に置いておき、当番の人はこの立札を持って進行をするルールです
 
で、"かんばん"の写真は、slack上の研修用チャネルに挙げてもらってます。
社員専用のWebサイトに簡易なフォームで日報をアップすると共に、上記の"かんばん"の写真へのリンクを貼ってもらってます
 
20170524 社外で作業をしているメンバーでも、slackからかんばんを確認する方が楽チンです。
コメントを入れるのも、スマートデバイスから簡単に行えます。
 
さて、ここ最近は Ruby on Rails のチュートリアルを実施中
毎日のかんばんに変化が無くなりました.....
 
うーん.......どうしたんだ?、でも日報の文章を読むと進捗はある様子。
でも、かんばんボードの方を見ても......つまらない
 
付箋を見ると、予定工数が37.5時間になってる.....sign03
 
デカ過ぎるやん sign02  1週間もかかるやんか!?
 
これは、研修を行っている本人も、1日単位での"進んだ感"(達成感)が得られなくて辛いのではないかな?
まあ、プロジェクト/プロダクトやロールによってタスクの管理上の粒度基準ってのは違うとは思います。
 
でも、"人間がチームを組んで楽しく'見える化'と共有の運用ができる"
 = 小さな達成感を積み上げることが出来て、
 + ストレスが幾分かでも緩和でき、
 + 疲労度も減り、
 + 生産性・品質の向上にも役立つ...はず。
という効果も狙うのであれば、
"毎日、最低でも1枚くらいの付箋は、'Done' に移したい!"。
 
この達成感がクセになる!というメンバーが多い(人間なら当然だと思う...)ですし、
1日の区切りにもなります(多少なりとも、気持ち良く帰宅できます)
 
なので、1タスクの時間数は最大でも7h程度、出来れば4h程度を上限基準にしたいところです。
チケット管理ソフトで言うところの、子チケットに相当するような考え・管理でOKだと思います。
 
20170525_2 本人に聞いてみると、"何か全然進んでない感じがする..."
 
これ↑、メッチャ拙いです!bomb
 
なので、チュートリアルの章毎にタスク化し、親付箋の脇に Doing 付箋をペタっと貼る感じに変更
(実務だったら、親付箋の下端に貼る感じでしょうかね...)
親付箋のタスクが全部終わると、Done のエリアに縦に幾分か長くなった付箋群が出来上がる...という具合に
 
早速、メンター担当が対処してくれました。
当日の日報に上がったかんばん写真に変化が現れてますね!
 
良かったー!


★クリック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)

Mr. 速形、ブチかます!(ラムダ式)

3/17が3月の全社定例会の日でした。
 
この日は、個人的な事情でアスペアを卒業することになった速形さんから、
事前には予定の無かった "IT-Tipsを是非やりたい!、10分枠をくれ!" との嬉しい飛び込み発言があり、
当日に急遽、枠を設けました
(ちなみに、同日の定例会終了後に彼の送別会を行う予定だったので、定例会は短縮バージョンで行ってます)。
 
2017031704 どんな内容かなー?、と思っていたら、タイトルは...
"わかる!ラムダ式"
 
技術のトレンド系・最先端と言うより現実的に身に迫って来ているけど、
実案件では意外と導入が遅れていたりする要素を積極的にフォローアップしている速形さんらしい出し物設定と言えそうです。
 
あ、ちなみに、
なぜ、急に "全社定例会の枠を設けてくれ" と自ら要求してくれたのか?に付いては、
"定例会の場で、皆の前で話すのが楽しかったし、色々と突っ込んでくれるのも面白かったので、退職する前に
是非もう一度やっておきたかった!"
と言ってくれました。
(嬉しいです! もの凄く....(涙))
 
実際のコンテンツは、Qiitaサービス上で作成し、スライドとしてデモで見せてくれました。
WebページをPDF化&圧縮したファイルを掲載させて頂きます:勿論、本人の承諾済み)
↑分り易さ優先の資料のため、技術的な問題点など余り突っ込まないで下さい;ご教示頂ける点は有り難く伺います...
 
2017031702 言語的にはJavaScriptで実例を追う形
Javaより簡単に書ける
Javaと構文が似ている(現時点のアスペア内ではJavaが最も共通知識となっているので)
すぐに動かして確かめられる
...という理由からの選択です。
 
サンプルとして、"或る処理ロジックをJavaで書いたもの" をJavaScriptのラムダ式に書き換えていく
という形で展開されました。
 
高階関数+ラムダ式を使用して、
より簡潔に短く、処理の意図が伝わる、コードが書けることを順を追って説明してくれました。
 
と、このブログ原稿を書いている筆者自身の理解が追い付かない点が情けないのですが、
出席していた技術部メンバー達には理解・納得できたようです。
確かに、"ゴチャットした制御構造を読み解かないと仕様・意図が分からない" 状態から、
"意図した仕様が箇条書き的に、一読で読み取れるようになった" ことは私にも理解できました!
 
端的な例とは言えるのでしょうが、
メンバー全員が理解して、ガイドラインなどを設けて&共有して&納得した上で活用したら、
開発者の皆が(今と比較して)幸せになれる可能性を感じ取れました。
 
資料も説明も、今までの速形さんのコンテンツの中で最も完成されたデモだったと思います!
いろいろと周りにも刺激を与えてくれてありがとう!
 
次の職場でも、きっと様々に活躍されることと確信してます。


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

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

古いツールでも光るヤツも有るんだぜ!

2月の全社定例会は、2/17でした。
 
コンテンツは、企画モノ(非レギュラー)は、
仕掛り中のプロダクト/サービスからのDevOps的視点からの実例共有&相互質疑
セキュリティ系の昨今の事例共有&相互質疑
その他、労務的なこと、社内的なスキル評価体系的な話題など...
...でしたので、
ちょっとここには書けない内容ばかりでした。
 
ただ共通して言えるのは、作業をしている場所・顧客、仕掛りプロジェクト/プロダクトに関わらず、
オンラインだけでなく対面でも実例・事象を共有して、相互に質問し合う、
お互いの間接経験となるように活かす、という視点&行動
です。
 
また、共有が比較的(かなり?)難しい "暗黙知" に関してですが、
これを共有するには、現実的な話として "一緒に作業しながら伝え合っていくしかない" 面が多分にあります...。
...と言っていても、なかなか現実は先に進めない=勿体ないので、
出来る限りハンズオンやワークショップなどの形態を採るようにしています。
 
準備・仕込みに時間・手間がかかるので、肝心の"暗黙知を持っている本人"の調整が難しいですし、
いかにワーク実施時に"持っている側から見せられるか"、"持っていない側が部分的にでも体感できるか"も
悩ましい所です。
 
とは言え、これが出来ることが"その会社に属している・仲間との間に妙な制約を設けずに済む"大きなメリットですから
活かしていかなければ!
 
さて、具体的な内容が無いと寂しいので、同日のレギュラーコンテンツの方から紹介を1つさせて頂きます。
 
毎回、"IT-Tips 又は LT(ライトニング・トーク)"を行ってます。
 
2月の回では、蓑方さんが発表してくれました。
 
ちなみに、蓑方さんは "自身の公的なロールに捉われず、なるべくプロダクト/サービスの全容を把握し、
機会があれば可能な限りの外部仕様・内部構造も把握しつつ、俯瞰的な視点で理解をして設計や製造にも
反映できる&メンバー間で共有も進めていける" 人物です。
 
多くのプロジェクトに関わって来ましたが、"いつの間にか、設計や仕様・要件の中心に関わっている" 人です。
 
2017021701 さて、そんな蓑方さんが今回お話してくれたのは、
自身がかなり以前から使っている "自分のメモを構造的に集約するツール" についてでした。
("ウェアラブル EXPO" 参加レポートを発表!...と思ったけど行けなかった、というフェイント付きでした...)
 
Nami2000
http://www.geocities.jp/my_ultraseven/mozart/_start.htm
 
既に世に出てから17年を超えるフリーソフトウェアです。
分類的には、"アウトラインプロセッサ"。
 
最近は余り耳にしない用語かも分かりませんが、
要は、情報を構造的・階層的に構築・集約していくツール、です。
 
それ自体をそのままで、多くの他者と共有・運用することには向きません。
基本はあくまで、個人の情報を、個人の基準で構造決め・メンテをして成長させていく(或いは適宜で掃除する)ものです。
 
今なら、例えばGoogleDriveやDropBox、SkyDriveなどに置いておけば、物理PCに限定されずに利用できますね。
 
2017021702 自分でカテゴリー分けをしながら、大体3階層くらいまでで済んでいるとのこと。
検索機能も当然有りますが、"何処にどんなモノを入れているかは大体頭に入っているので、検索は余り使わない"そうです。
 
このツールに、
自身で得たTips的な知識、ちょっとした(しかし重要な)スクリプトとか、
日々のToDoリスト的なメモの保存とかから週報を起して効率的に進められるとか、振返りに使ったりとか...
 
で、今回の蓑方さんからのツール紹介を受けて、
"早速インストして利用します!" という反応もありました
 
新しいばかりが良い、と限った話ではありませんよね。


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

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

Mr. 三文字、踏ん張る!

1月の全社定例会にて、アーキテクトでもある三文字さんから、プロジェクト/サービスの事例発表がありました。
 
Web上で展開されている各種サービスを実現するために、それらを支えている様々な要素があります。
 
2017011301 サービスが大きく成長し(ユーザー数を増やし、継続的な収益と成長を持続させる)、機能拡充と共に、
ユーザビリティの改善や、顧客内の他のサービスとの連携・API化の流れ(マイクロサービス・アーキテクチャ)、
様々な側面からメンテナンスの必要性が生じて来ます。
 
特に、大規模なサービスで、かつ運用期間が長くなるほど、
顧客にとってのビジネス的な価値も大きくなるでしょうが、同時に、徐々に技術的な負の資産を膨らませてしまうことは
避けられません。
 
負債はどこかのタイミングで返済しなければならない。
負の資産は、どんどん保守・運用コストの増加という形で顧客のビジネスを圧迫していきます。
 
2017011302 三文字さんが、この"負の資産の返済"の実例実務上の中心人物として稼働してきた経験から、様々なことを共有してくれました。
 
サービスは、長期間運用して来れば(=長期間、必要とされ続けて来た)、必要とされ方・利用の仕方・求められる
サービス内容も大なり小なり変化していきます。
 
その度に "どんな課題に対し、どんな目的を持って、どう変化させるのか?" 、"結果として何がどう変わることを期待するのか"
が、事前に明確にされなければならないはず...
 
...ですが、
"どう変えれば、ビジネスの成果にどう反映されるか?"、は、やってみなければ分からない面も多分にあります。
 
開発途中で、関係者(ステークホルダ)からの要望が出たり、他のサービスから得られた分析結果を元に
施策を変えたりといったことも頻繁に発生します。
 
そんな状態の中で、これらの要求・外部仕様・対応する内部仕様が資料として確実に残されるか?
と言うと...残念ながら、不完全な場合の方が圧倒的に多いのではないでしょうか?
 
三文字さんの苦闘の中でも、
"彼自身が頑張れば何とかなる" 範囲と、
サービスの外部仕様・運用を最も知っている人達の協力を得なければどうしようもない
(現実的な時間制約やコストの範囲で収まらない)こともあります。
 
それらの判断を行い、切り分けつつ、顧客側の上位職の方々と提案・交渉などを行うことも、三文字さんの
重要な仕事の1つでした。
 
膨大な量のプログラム・コード。
品質を担保しながら、負の資産を返済する手段とステップを考え・調整する。
テストケースの設定自体も、以前に関与したメンバー達の協力を得られるように各種の調整を行い、
テスト・コストも現実的なレベルに抑えつつも、必要な品質担保の点で手抜かりは許されない。
ユーザー数の多い大きなサービスですから、フロント/バック共に性能的な低下が無いことも十分に検証しなければならない。
 
具体的なことは書けないのですが、様々な問題が発生し、1つ1つへの対処法を工夫しつつ、
クリアしながら(多くの人達と協働しながら、ですが)リリースに向けて進んで来たのですね。
 
ほぼ完了している時点で話をしてもらっているので、淡々と話すことが出来ていますが、
「これは....苦労しました」という、微妙な言い淀みや間合いに、
「大変だったんだろうなあ...」という印象を持ちました。
 
負債返却の具体的なケースと、効率的な調査方法、対処方法(政治的なモノから技術的な詳細に至るまで)など
様々な要素を惜しみなく共有してくれた三文字さん、有難う御座いました。
 


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

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

本が欲しいだあ?、買え買えーっ!!

"書籍買い放題!" の運用をスタートしましたっ!
 
今までも業務的に、或いはトレンド技術やプロセス、マネージメント系、業務系など、必要な書籍が有れば
都度の申請(職制によっては自己裁量でOK)で社費での購入はしていました。
 
しかし.....
 
"業務で必要としないと買えないのか?"とか、
"既に社内に有ったら&誰かが持ち出してたら買えないのか?"とか、
"そもそも書き込み出来ないと、実戦的に使えないじゃないか!"とか、
"あーだこーだ承認受けないと買えないのか?"とか、
 
面倒臭い.....
 
本当は関心があるんだけど、今の業務じゃ使ってないし、申請・承認だとか面倒臭いし...
...で、そのまま流れて放置されてしまうのは、余りにも勿体ない!
 
技術系の書籍は概ね高価ですし、個人で賄うのは結構厳しいものがあります。
(中には、"◯◯文庫"、と個人名で呼ばれるような書籍群を社内に貯め込んでいる猛者もいますが...)
 
そこで、改めて "書籍買い放題!" 制度を立ち上げましたー!
 
事前承認のフローは無しです(運用ルール/ガイドラインは事前に社内共有しておく(社員専用サイトなどで))。
 
これから始めるので、
こりゃー社費で買うには余りにも違うだろー?、とか、
うわあーっ!、想定を遥かに超えて予算オーバーだあーっ!、とか、
...あるかも知れません。
 
ので、3ヵ月間は先ずは試験運用。
状況を見ながらルールを見直す。
費用の累積は、ほぼリアルタイムで共有可能にする。
...などを前提としました。
 
あ、ちなみに、購入報告・支払い申請は、slackの専用チャネルから行うようにしてます。
 
1年の長期貸出しの場合、"書込みOK!"
以降も1年単位で延長更新可能にしてます。
 
フロントサイド・エンジニアの場合などは、欲しい書籍は単に技術や業務という括りに収まらないはずです。
"良いものに触れる"という点から、過去のグラフィカルな作品や意匠が掲載された書籍なども社費の対象に想定しています。
(こういう本[↑]って、特に高いんですよね...。手が出にくいです)
 
さてさて、どうなるだろう?
 
運用していく中から、面白い事例とか波及効果などありましたら、
改めてこのブログで紹介させて頂きたいと思います!


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

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

Mr.山下、暴れる!

2017年の最初の全社定例会(1/13)で、顧客先プロジェクトにアーキテクト・兼・要件定義者、
兼・実質的にリーダーとして参加している山下さんから、
顧客のビジネス概要と、特に技術面を中心に共有可能な範囲でのお話をしてもらいました。
 
2017011303 大きな開発規模ではありませんが、顧客要求がぼんやりした状態から要求定義・開発スコープの明確化と、
スケジュール立て(希望納期の提示は有ります)、適用する技術要素の選定やリスクヘッジ方針決め、
開発プロセスの方針決め・実行と、参画早々に大忙し!
 
結構短期でフルスクラッチのリリース。 如何にも今時のプロジェクトです。
 
顧客の要求を具体化していく為に、プロトタイピングを適用。
ドキュメントは、山下さん自身のメモを含めて、基本的には MarkDown 形式での記述を選択。
整形表示されて見栄えも良く&見易いですし、そのまま顧客に見せても良い。
ビューワーはWebブラウザでOK。 参照デバイスを限定されない点も便利ですね。
 
WordやPowerPointで作成するのではなく、MarkDown記法を使うという選択は、結構トレンドのような気がします(妥当性が有る、という事だと思います)。
 
業務・ビジネスに関してはここには書けませんが、技術要素だけ記載します。
 
React.js、MaterialUI、webpack
ES6(動かないWebブラウザもあるので、babel でコンパイルしてJSに変換)
(Redux(検討中))、CSS3
某・クラウド分析用DB。
開発言語としては kotlin を選択(Javaにコンパイルできる言語(=JavaVM上で動くコードを吐く))。
 つまりは、同じくJavaVM上で動く言語で書かれた資産ならば何でも利用できる!、ということです。
 当初は scala も選択肢に含めていたのですが、メンバーの経験・意見を元に切り替えたとのこと。
 アーキテクトだからと言って、好き放題に技術選択できる・すべきという訳じゃありませんよね。
 現実に関わるメンバー、メンテナンス性、コード寿命(システムの想定寿命)、その他諸々の要素を考慮して
  結論を出さなければなりません。

SpringBoot(フレームワーク)、MySQL。
ビルドツール:gradle
リポジトリ管理:gitbucket
チケット管理:Redmine
コミュニケーション:Slack
WBS管理: asana(タスク管理)、instgantt(ガントチャート(5名まで無料)。asanaと連動してくれる)
 
...などなど。
 
2017011304 聞いていたメンバー内からの質問、
「どうしてVue.jsじゃなくて、React.jsを選んだのか?」に対しては、
「トレンドだし良いものだと思うし、自分が経験したかった!」と、何とも率直なお答えでした。

顧客要求として、"リッチUI"、"SPA(Single Page App.)" を希望されている、という点が大前提です。
(他にも理由が述べられましたが、ここではちょっと割愛...)
 
以前のプロジェクトや普段からの継続的な情報収集などから、各要素を判断したとのこと。
未経験要素も多分にあるのですが、リスク・コントロールの方向性も具体的な候補を想定して決定している
という点に、(当然と言えば当然なのでしょうが)感心。
 
会議の最後の振返りの際にも、
知らないキーワードが満載だった。勉強しないといけないといかん!、と思った。
...などが挙がりました。
 
自社内相互で刺激し合うことが出来るのは良いことだし、有り難いなあとしみじみ思います。
 
また、そういった情報を惜しみなく出してくれる山下さんの人柄と姿勢にも感謝・感謝です!
 


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

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

«Amazon Dash Button を手に入れてみた!