nDiki : 勉強会
勉強会 - study session
- 社内 Perl 勉強会
- 2006年4月21日から9月11日にかけて実施
2017年2月23日 (木)
「Inspired 入門」 (第1回)
プロダクトオーナーやプロダクトマネージャー(PdM)の必読書と言われているらしい「Inspired: 顧客の心を捉える製品の創り方」の内容を理解し、実践・共有することで力をつけていきましょうという「Inspired 入門」勉強会に参加してきました。今日が第1回。渋谷界隈でネットサービスを行っている4社から参加者が集まりました。
各社ネットサービスを展開していますが、お互いにビジネス領域が被らないためざっくばらんに話ができそうです。企業毎に組織体制や文化が異なり、プロダクトマネージャーの仕事・役割もそれぞれ違うよねということをあらためて感じました。取り組みや課題などをお互いに情報交換することで、いろいろ学びがありそうです。CS 部門経験者の方も何名かいて、ぐっと親近感がわきました。
今回は幹事役をしてくれた方が資料を用意してくださっていてそれを使いながらファシリテーションしてくれました。感謝。
話題から
ある方のところでは、ユーザーに影響のある施策についてはコンセプトシートを書くとおっしゃっていました。他の方はリーンキャンバスを作るようにしているとのこと。自分のチームではプロダクトバックログ上にストーリーを書いて済ませることも多いのですが、少し大きいサイズのものはこういったものを書いた方が良いなと今回感じました。
PdM という役職・肩書のある会社はというお題については、ほとんどの方がないということでした。
それからユーザーストーリーマッピングを1日かけたという話をしてくれた方は「エンジニアも一緒に参加することで、作る側の納得感が出て良かった」とおっしゃってました。なるほどです。
Inspired より
今回は1章から3章がトピックだったので以下個人的なメモ。
第1部は「ソフトウェア製品の開発に関わる人たち」。人・プロセス・製品という3領域の中の「人」。その役割と責任について。
第1章: 製品開発の鍵を握る担当者とその役割
まずは役割の説明。プロダクトマネージャーのやることとして以下を挙げています。
プロダクトマネージャーの主な任務としては2つある。製品の市場性を評価することと、開発すべき製品を定義することである。
プロダクトマーケティングも兼務になっていることが多々あるがまったく別の技能が必要なので、兼務は非常に難しいとしています。この点は第2章で詳しく取り上げられています。プロダクトマーケティングが分離されていると助かります。
プロダクトマネージャーは5〜10人のエンジニアに対して1人必要とのこと。スクラムチームの人数ともだいたい同じ規模感。
第2章: プロダクトマネジメントとプロダクトマーケティング
「プロダクトマネジメントとプロダクトマーケティングをそれぞれしっかり」「製品の最終責任者を明確に」「プロダクトマネジメントは専任で」
プロダクトマネージャーの役割とプロダクトマーケティングの役割をきちんと区別するのが大切。
第3章: プロダクトマネジメントとプロジェクトマネジメント
ここではさらにプロダクトマネジメントとプロジェクトマネジメントを区別しましょうという話。
2017年2月28日 (火)
第17回 エッセンシャル スクラムを読む会
社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会の17回目。今日は第17章 エンビジョニング (プロダクトプランニング)。
「エンビジョニング」という言葉に馴染みがなかったので「プロダクトプランニング」の方がわかりやすいよなーと最初は思ったのですが、慣れてくればエンビジョニングでも「ビジョン」に意識が向いていい気がしました。
エンビジョニングのタイミング
何度も繰り返すアクティビティであり、一度やってそれで終わりではない。
これ系のアクティビティはどうしても半期毎のサイクルになってしまいがちなのですが、アジャイル的にはもっと早いサイクルにやった方が良いということですね。
エンビジョニングをやりすぎないようにエンビジョニングの完了予定日を設定しておくのは確かに必要だなと感じました。やろうと思えばいくらでもやれてしまうものなので期日を明確にした方が経済的でしょう。
エンビジョニングの参加者
最初のエンビジョニングで必須なのはプロダクトオーナー。いったんプロダクトの開発が動き出して以降のエンビジョニングにはスクラムチーム全体が参加すべき。概要レベルのプロダクトバックログの作成でストーリー記述する際もスクラムチームメンバ全員が関わった方が良いと言っています。
このあたり結構孤独にやっちゃうことも多いんじゃないかと思うですが、やはりチームでやった方が良いようです。
価値のカテゴリ
図17.3 で「ステークホルダーが得る価値の分野」としてカテゴリ分けされているのは地味に便利ですね。
- 参入条件
- ハードルをクリアする
- リリース可能な最小限のフィーチャーをデリバリーする
- SOX、FDA、HIPAAなどに準拠する
- 使用可能性
- 新たなマーケットを対象とする
- 他のプロダクトやサービスを販売できるようにする
- 差別化要因
- 競合他社と差別化する
- 顧客を喜ばせる
- 妨害
- 競合他社の差別化要因を無力化する
- ハードルを上げる
- 市場での注目先を変えることで、ゲームのルールを変える
- コスト削減
- 市場に投入する時期を早める
- 開発工数や投入する要員を減らす
- 利益を増やす
- プログラミングの技術を高める
自分が取り組んできたものだと「顧客を喜ばせる」「要員を減らす」とかが多かったですが、製品・市場によっては確かに妨害とかもあるのでしょうね。
今日は参加者少なめで5人。23章までいれるとあと6回のところまできました。
2017年3月2日 (木)
渋谷 PdM ランチ会 Vol.1
先週参加した Inspired 入門勉強会グループメンバで都合のつく人で交流ランチ。第1回の勉強会のふりかえりや次回の進め方などの話をしつつ、カジュアルにプロダクトマネージャー業の情報交換となりました。
私のグループのチームは今はスクラムで開発していますという話をしたところ、他の3名のところではスクラムを導入していない/できていないとのことでした。
私もスクラムは学びながらやっていて「エッセンシャル スクラムを読む会」という社内勉強会に参加している最中です。
1週1章1時間、(参加者がその回の章を読んできている前提として)その日の当番の人がサマリを発表、流れで随時「ここ良くわからなかったのですけれどどう思います?」とか「私たちの組織・やり方だとここが当てはまっている・違っている」とかそういう会話をする流れでやってます。
といった感じで進めていますと紹介しました。
さっそく戻って読み合わせやろうという話になっているというコメントをもらって、皆さんスピード感があってさすがだなぁと。
2017年3月7日 (火)
第18回 エッセンシャル スクラムを読む会
社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会の18回目。今日は第18章 リリースプランニング (長期計画)。
今日は7人参加。
タイミング
リリースプランニングは一度限りのものではなく、スプリントごと行うアクティビティだ。
他のプランニング同様リリースプランニングも一度限りのものではないと明言されています。章の後半で説明される進捗の把握をしながら、スプリント毎に見直されていきます。
ポートフォリオプランニングでは「終わることのない作業」、エンビジョニング(プロダクトプランニング)では「一度やってそれで終わりではない」とそれぞれここまでの章で書かれています。全てのレベルにおいて継続が求められます。
ただスプリントプランニングをスプリントごとにやるとすると、どの程度時間を使うことになるのかが気になるところです。1週間スプリントの場合だと、さっと済ませるか何回かに1回にするのかが現実的なところでしょうか。
プロセス
各リリースには、明確に定義されたリリース可能な最小限のフィーチャー(MRF)がなければならない。(中略)顧客視点で、実用最小限の製品となっていることを確かめるのだ。
今の仕事は「フィーチャーごとにリリース」という方針でやっています。1スプリントで完成できるように例えばバックエンドという PBI にして先に完成させデプロイしておくというのをやったりしています。しかしバックエンドだけではここでいう MRF ではないですね。
いまチームではこのデプロイもリリースと呼んでいますが、エッセンシャル スクラム的に考えるとそれはリリースではないと考えた方が良いのかもしれません。
「各スプリントで価値を届ける」ことと「各スプリントでデプロイする」は同義でないと考え直した方が良いようです。
「いくつかのスプリントの成果物をひとまとめにしてリリースする」というプランニングの場合もあるのですから、毎スプリント必ずリリースするということに無理にこだわらなくてもということでしょうか。スプリントが終わった時点で常にリリース可能な状態になっていることが重要ということでしょうか。
リリース制約
気がつくと「スコープを固定」と無意識にしてしまいがち。ステークホルダーに期日を約束していないと、ずるずるとリリースを延期してしまいがち。
「スコープを固定」になる原因は、全体的なスコープがあまりにも大きすぎることであることが多い。
とあり、ここでもできるだけ小さくというのが推奨されています。MRF をいかに小さく定義しておけるかがポイント。18.4 節では「常にMRFを調整し続ける。」と書かれていて、MRF も適宜見直していくべきです。
期日を固定する方式がスクラムの原則にうまく当てはまるということなのでリリースプランニングの際にきちんと意識できるようにしたいです。
スプリントマッピング
主に複数チームで協調してスプリントを進めていくための話。ここは困ることが起きた場合にまた読み返したい部分です。
2017年3月14日 (火)
第19回 エッセンシャル スクラムを読む会
社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会の19回目。今日は第19章 スプリントプランニング。ここから「第IV部 スプリント」。スクラムチームにとって馴染みがあるパートです。
スプリントを回すにあたり第19章はすでに何度か先読みしているところですが、あらためて書籍にあたり気付きを得て実践していきたいところです。
タイミングと時間と参加者
スプリントプランニングはスプリントを開始するときに行います。2週間から1カ月のスプリントで4〜8時間ということなので、単純に計算すると1週間スプリントでは2時間程度でしょうか。
今は1週間/2週間スプリントのチームで賞味30分から45分ぐらいしかやっていません。実際時間不足を感じています。
もちろん長ければ良いというものでもありませんが、もし不足だとしたらこのあたりが適切な時間をかけられていない障壁かなと。前者はチームが成長することで解消される気がします。後者は LeSS (Large-Scale Scrum) の2段階のスプリントプランニングにしてチーム別のにはプロダクトオーナーは出ないという形式にするという解決案も思い浮かぶのですが、参加しないデメリットを考えると躊躇してしまいます。
プロダクトバックログアイテムにかけるキャパシティ
完成させる自信のある計画を行うにはキャパシティの把握が不可欠になります。
スプリントのキャパシティ = PBI にかけるキャパシティ + スプリントバッファ + それ以外
予定している休暇があるのにスプリントプランニングの際に宣言しないのは不誠実だということになるでしょう(休んではいけないということではなく、わかっているのに共有しないということが問題。体調不良等による突発的な休みももちろん別の話)。
今のところ自分たちのチームではベロシティ(ストーリーポイント)でなんとなくキャパシティがこれぐらいかなといった感じでしか考えられていませんが、次のスプリント期間をまず見通すことも必要だなと感じました。
作業時間を使ったキャパシティも紹介されていますが、実際ここまで精緻に管理したいと思うことはあまりないんじゃないかなという印象です。
プロダクトバックログアイテムの選択
基本優先順位順ですがスプリントゴールを示している場合はその限りではなく、またスキルの問題などでコミットできないプロダクトバックログアイテムはスキップするという選択も考える必要があります。
完成できそうにないプロダクトバックログアイテムを選択してはならない。プロダクトバックログアイテムが大きすぎて完成できそうにない場合は、顧客にとって価値のあるアイテムに分割するか、完成できそうな別のアイテムに着手する。(中略)未完成のアイテムを次のスプリントに繰り越していくと、スプリントの終了時に出荷判断可能なプロダクトインクリメントを手に入れるという目標がいつまで経っても達成できない。
ここがいつもスプリントプランニングでぶちあたるところです。プロダクトバックログリファインメントがしっかりできていないんですね。プロダクトバックログリファインメントは最重要レベルのアクティビティなんだなと。
タスク分解と作業時間見積もり
自信の獲得のためにタスク分解と作業時間の見積もりをまずしましょうとあるのですが、タスク分解と見積もりの方法については触れられていません。ここは自分たちで考えて頑張れという感じなんですかね。一般論にはできない部分だとは思いますが、ここは大ハマリするところなので参考になる話があると嬉しいなと思ってます。
スプリントプランニングでタスクを個人に割り当てるのは有害だというバッドプラクティスが挙げられていますが、ここは次の「スプリントの実施」で語られるところのようです。
2017年3月21日 (火)
第20回 エッセンシャル スクラムを読む会
社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会の20回目。今日は第20章 スプリントの実施。すでに前の章で説明されていることもまた出てきて、そのあたりはおさらいとしてさらりと読むことができました。
誰がどの作業から始めてどの作業から完成させていくか
誰がどのタスクの作業をするのかはチームメンバの共同責任。どの作業から始めるか開発チームに選択する能力が必要。どの作業から完成させていくかはチームが決めること。開発チーム自身が考えてねという感じです。がんばれ開発チーム。
実際に作業を完成させていくにあたっては「スウォーミング」という聞きなれない言葉が出てきました。
新しいアイテムに着手する前にキャパシティのあるチームメンバが集まって、すでに誰かが着手したアイテムを完成させること。
ということで、動けるメンバで順にアイテムを完成させていきましょうと書かれています。ただ完全にシングルタスクで進めていけばいいかというとそうでもなく「すべてのチームメンバーが同時にひとつのアイテムに取り掛かるのは危険だ。」と書かれており、いい感じに絞ってやりましょうということでした。
ちなみに巻末でのスウォーミングの説明には
ある程度のゆとりと適切なスキルを持ったチームメンバーが集まって、ある項目に対して共同作業(スウォーミング)を行い、新しい項目に着手する前に、すでに進行中の作業を完了させること。
と一見 GNU 的な説明になってました。
デイリースクラム
デイリースクラムのところには
チームメンバーの最適な作業配分についてみんなで理解する
とありました。「昨日やったこと・今日やること・困っていること」という型ついなぞるだけになりがちですが、きちんとチームとして誰が何をどうやっていくかを共通のものにすることを意識していくことが大切ですね。
2017年3月28日 (火)
第21回 エッセンシャル スクラムを読む会
社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会の21回目。第21章 スプリントレビュー。スプリントの中でいちばんうまく出来ていないスプリントレビューの話です。
スプリントレビュー
スプリントレビューは作業結果(出荷判断可能なプロダクトインクリメント)の検査と適応をするアクティビティです。
不都合な真実も含めて、現在のプロダクトの状況を透明に見せてくれる。
という、ちょっと最初は勇気が必要なアクティビティです。
この章によるとスプリントレビューはスクラムチームがスクラムチーム外の人に説明しフィードバックを得るための機会なのです。しかしながらついチーム内の確認の場になりがちで、チーム外の人からきちんとフィードバックを得られていないと反省しています。
スケジュールの調整
スクラムチーム外の参加者が最も多く、スクラムのアクティビティの中では最もスケジュールの調整が難しいと述べられています。たしかに。ステークホルダーのスケジュールに合わせてスプリントレビューのスケジュールを決め、それに合わせて他のアクティビティを合わせるのが現実的とのことでした。
スプリントレビューに参加してくれないようなら、それは開発する価値のないプロダクトということである。したがって、プロダクト開発を注視すべきだろう。
きちんと参加者が集まらない場合は同時並行の作業が多すぎないかも見直すべきなのかもしれません。
スプリントレビューのアウトプット
リファインメント(グルーミング)したプロダクトバックログと更新したリリースプランがスプリントレビューのアウトプットだと書かれています。
ほとんどのチームはスプリントレビューでグルーミングをしている。関係者全員が開発の現状と今後を理解して、新しいPBIを作成したり、既存のPBIの優先順位を変えたり、不要なものを削除したりする。
これも全然意識できていないところ。今はコメントをもらって終わりになっています。きちんと対話をしプロダクトの適応をするところまで実現できていないなと。
デモ
デモが難しいからといって、それはデモをしない理由にはならない。
プロダクトオーナー側でも「まぁいいか」と思ってしまうの良くないですね。反省。
2017年4月4日 (火)
第22回 エッセンシャル スクラムを読む会
社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会の22回目。第22章 スプリントレトロスペクティブ。
プロセスをスクラムチームが調査するためのものだ。
2月の第15章 さまざまなプランニング以来、4回目の発表担当です。
半年前に今のチームにスクラムを導入した当初に CSM に「まずはふりかえりをきちんとできるようにしたい」と言われてから、スプリントレトロスペクティブについては結構意識してきたので、あらためてふりかえりのふりかえりという気持ちで読みました。
事前準備
本章の中で事前準備についてけっこう書かれています。ふりかえのために全く事前準備していないので、その利点についてなるほどと感じました。ただ実際のところそこまで時間を費やさなくてもという思いもあります。大きな課題があってそれにフォーカスしたふりかえりをする場合は準備するというようになるかもしれません。
スプリントレトロスペクティブに使う時間
と書かれていますが、勉強会で皆の実態を聞いてみると1週間/2週間スプリントで30分から45分ぐらいというのが中心でした。プロセスの改善だけに時間を使いすぎるのに抵抗があるのかもしれません。
インサイトバックログ
付箋紙を使っているとインサイトバックログを残そうとあまり思わないなと。一方 Trello などのデジタルツールを使っている場合は残すという運用をするかもといったぐらい。
アクションの決定
ふりかえり時間・実行できるアクションのキャパシティを考えると、インサイトが多く集まった時は何について議論するかをきちんと絞る必要が出てきます。ここは結構ファシリテーターの腕の見せ所。紹介されているドット投票で機械的に決め手しまうのもさくっと進んで良さそうなので取り入れたいです。
アクションはスプリントバックログへ
改善アクションを扱う最も簡単な方法は、アクションに関連するタスクをスプリントバックログに追加して、新しい機能よりも優先順位を高くすることである。(中略) 改善アクションを実施したいのであれば、分離してはならない。統合すべきである!
なるほど。今は個人に委ねて次回確認ぐらいとなっているのですが、チームで可視化しフォローしていけるようにすべきですね。
2017年4月14日 (金)
第23回 エッセンシャル スクラムを読む会 (最終回)
社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会の23回目。第23章 未来へ。ついに最後の章です。
スクラムは継続的な改善の一形態なのだからこれが最終形態というものは無いし、どのチームをとっても同じというものは無い。プラクティスはあってもベストプラクティスはチームによって違う。準備ができていないからスクラムを始められないというのはそもそも原則に反するので、まずやって学ぼう。現状を変えるよりもスクラムを無視したりスクラムを変更したりすることの方が簡単だけれど、組織を変革するために協力しあいながら確固たる信念をもって立ち向かおう。
そんなメッセージを本章から受け取りました。
第1章の「スクラムは役に立つか?」で出た通り全ての領域でスクラムが適しているわけではないので、盲目的に導入すれば良いというものではなく、領域が変わった場合はスクラムを続けるか続けないかの判断が必要になるのでしょう。もし取り組む領域が「複雑な領域」であるならばスクラムフレームワークはとても強力だということは間違いありません。
「エッセンシャル スクラム」と「エッセンシャル スクラムを読む会」そしてなによりこの半年のスクラム開発経験でスクラムについて多くを学ぶことができました。「エッセンシャル スクラム」は「スクラムガイド」を読んだだけでは得られない広範囲な知識やノウハウが詰まった良い一冊でした。
エッセンシャル スクラムを読む会のふりかえり
エッセンシャル スクラムを読む会を終えたあとは、オフィスのコラボスペースでビールを飲みながらお疲れさま会。参加の皆さんお疲れさまでした。この回を始めてくれたはらかち氏に感謝。休まず毎回参加してディスカッションしたことでいろいろな学びを得ることができました。嬉しい限りなので珍しく私もビールで乾杯しました。いっしょに全回参加した2人のうちの1人である RabbitFake 氏も特にお疲れさまでした。
ふりかえって出てきた話題としては
- 取り組む領域がクネビンフレームワーク(第1章)のどの領域なのかを見てスクラムを採用するかどうか考えたい。
- チームメンバでエッセンシャル スクラムを読むことで「PBI」などの同じ理解で使える言葉が増えた。チームの共通言語作りに貢献できた。
- 原則大事(第3章・第14章など)。
- WIP を下げる重要性をあらためて学んだ。
- 準備完了の定義・受け入れ条件が重要。
などが上がりました。
また実際に読む会と並行してスクラムを行ってきた中で
- プロダクトバックログリファインメントで1スプリントにおさまるように適切にプロダクトバックログアイテムを分割するの大変だよね。
- スクラムマスターと開発チームメンバ(エンジニア)との兼任が難しかった。
- スクラムマスターであると同時に組織図上のリーダーという立場でいると、自発的行動を促すのとある程度指示的に動かすのとの兼ね合いが悩ましかった。
- 困った状態であることにメンバが気がつくのを3カ月待った上で物理かんばんを導入してみた(すごい)。
などの話が出ました。
スクラム実践についての「検査と適応」をタイムリーに勉強会をしながら進められて学びの多い半年間でした。
全23回
- 2016年10月25日 第1回 第1章 イントロダクション
- 2016年11月01日 第2回 第2章 スクラムフレームワーク
- 2016年11月08日 第3回 第3章 アジャイルの原則
- 2016年11月15日 第4回 第4章 スプリント
- 2016年11月22日 第5回 第5章 要件とユーザーストーリー
- 2016年11月29日 第6回 第6章 プロダクトバックログ
- 2016年12月06日 第7回 第7章 見積もりとベロシティ
- 2016年12月13日 第8回 第8章 技術的負債
- 2016年12月20日 第9回 第9章 プロダクトオーナー
- 2017年01月10日 第10回 第10章 スクラムマスター
- 2017年01月17日 第11回 第11章 開発チーム
- 2017年01月24日 第12回 第12章 スクラムチームの構成
- 2017年01月31日 第13回 第13章 マネージャー
- 2017年02月07日 第14回 第14章 スクラムのプランニングの原則
- 2017年02月14日 第15回 第15章 さまざまなプランニング
- 2017年02月21日 第16回 第16章 ポートフォリオプランニング
- 2017年02月28日 第17回 第17章 エンビジョニング (プロダクトプランニング)
- 2017年03月07日 第18回 第18章 リリースプランニング (長期計画)
- 2017年03月14日 第19回 第19章 スプリントプランニング
- 2017年03月21日 第20回 第20章 スプリントの実施
- 2017年03月28日 第21回 第21章 スプリントレビュー
- 2017年04月04日 第22回 第22章 スプリントレトロスペクティブ
- 2017年04月14日 第23回 第23章 未来へ
2018年2月15日 (木)
今日のさえずり: ファシリテーターローテーションマーカーに AWS Cloud Ninja フィギュアが起用された
2018年02月15日
- 08:40 暖かくなるということで、さすがに今日からマスクをして外に出ることにした。
- 09:32 朝からすでに、ダウンジャケットでは暑かった。
- 09:39 “マイネットグループのゲームサービス事業会社4社が合併しマイネットゲームスに。「ゲームサービス圧倒的No.1」を目指す | 株式会社マイネット” http://bit.ly/2o1DYzP
- 09:42 ゲーム終了の経緯。 / “mobageで運営していたゲームを終了させた” http://bit.ly/2o1rJ6e
- 09:55 Trello に絵文字リアクション機能が追加されたので早速。選べるのは今は12絵文字だけっぽい。 http://bit.ly/2BZOTTa
- 13:15 朝のミーティングのファシリテーターローテーションマーカーに AWS Cloud Ninja フィギュアが起用された。
- 15:12 RT @masutaro: 今日とあるきっかけで10年ぶりくらいにペアプロしたんだけど、職種を問わず他人の仕事ぶりを口頭解説つきで見学させてもらうってすごく得るものが多い気がする。
- 15:15 エンジニアが主役の Android カンファレンス。2日間で1000名以上が参加。 / “【DroidKaigi 2018】ミクシィグループのエンジニアが登壇しました｜ミクシル” http://bit.ly/2BuW0BW
- 17:15 DSC-RX0 はやはりビジュアル・ブックマーク機サイバーショットUの再来なのか。 / “子どもの日常記録に「RX0」を使い始めたらとても楽しい” http://bit.ly/2Buzjhg
- 17:18 Naney の日記: Buffer を Awesome Plan にアップグレードして予約投稿しておける数を10件から100件に増やした。これだけあればずいぶん先まで予約できちゃう(そこまでしないけれど)。… https://twitter.com/...
- 17:21 ミキサー車。 PowerShot G9 X Mark II https://t.co/vU69jFFNsA
- 19:50 Markdown でプレゼンテーションスライドを書ける Deckset for Mac を久しぶりに使った。社内勉強会のスライド作る時とかサクッと楽に書けて良い。
- 23:30 “[mixi] ベビースター×mixiコラボキャンペーン！” http://bit.ly/2Bt9zSm
About Me
Naney (なにい)です。株式会社ミクシィで SNS 事業の部長をしています。
nDiki は1999年1月に始めたコンピュータ日誌を前身とする Naney の Web 日記(兼パーソナルナレッジベース)です。ちょっとしたノートは nNote にあります。
※内容は個人的見解であり所属組織とは関係ありません。
nDiki by WATANABE Yoshimasa (Naney, Google profile)
Powered by DiKicker