nDiki : プロダクトバックログ

スクラムプロダクトバックログ (Product Backlog)

フィーチャー・不具合・技術的な作業など、プロダクトに必要でプロダクトオーナーから見て価値のあるものが優先順位付けされて並べられたリスト。

2017年2月23日 (木)

「Inspired 入門」 (第1回)

Inspired: 顧客の心を捉える製品の創り方

プロダクトオーナーやプロダクトマネージャー(PdM)の必読書と言われているらしい「Inspired: 顧客の心を捉える製品の創り方」の内容を理解し、実践・共有することで力をつけていきましょうという「Inspired 入門」勉強会に参加してきました。今日が第1回。渋谷界隈でネットサービスを行っている4社から参加者が集まりました。

各社ネットサービスを展開していますが、お互いにビジネス領域が被らないためざっくばらんに話ができそうです。企業毎に組織体制や文化が異なり、プロダクトマネージャーの仕事・役割もそれぞれ違うよねということをあらためて感じました。取り組みや課題などをお互いに情報交換することで、いろいろ学びがありそうです。CS 部門経験者の方も何名かいて、ぐっと親近感がわきました。

今回は幹事役をしてくれた方が資料を用意してくださっていてそれを使いながらファシリテーションしてくれました。感謝。

話題から

ある方のところでは、ユーザーに影響のある施策についてはコンセプトシートを書くとおっしゃっていました。他の方はリーンキャンバスを作るようにしているとのこと。自分のチームではプロダクトバックログ上にストーリーを書いて済ませることも多いのですが、少し大きいサイズのものはこういったものを書いた方が良いなと今回感じました。

PdM という役職・肩書のある会社はというお題については、ほとんどの方がないということでした。

それからユーザーストーリーマッピングを1日かけたという話をしてくれた方は「エンジニアも一緒に参加することで、作る側の納得感が出て良かった」とおっしゃってました。なるほどです。

Inspired より

今回は1章から3章がトピックだったので以下個人的なメモ

第1部は「ソフトウェア製品の開発に関わる人たち」。人・プロセス・製品という3領域の中の「人」。その役割と責任について。

第1章: 製品開発の鍵を握る担当者とその役割

まずは役割の説明。プロダクトマネージャーのやることとして以下を挙げています。

プロダクトマネージャーの主な任務としては2つある。製品の市場性を評価することと、開発すべき製品を定義することである。

プロダクトマーケティングも兼務になっていることが多々あるがまったく別の技能が必要なので、兼務は非常に難しいとしています。この点は第2章で詳しく取り上げられています。プロダクトマーケティングが分離されていると助かります。

プロダクトマネージャーは5〜10人のエンジニアに対して1人必要とのこと。スクラムチームの人数ともだいたい同じ規模感。

第2章: プロダクトマネジメントとプロダクトマーケティング

「プロダクトマネジメントとプロダクトマーケティングをそれぞれしっかり」「製品の最終責任者を明確に」「プロダクトマネジメントは専任で」

プロダクトマネージャーの役割とプロダクトマーケティングの役割をきちんと区別するのが大切。

第3章: プロダクトマネジメントとプロジェクトマネジメント

ここではさらにプロダクトマネジメントとプロジェクトマネジメントを区別しましょうという話。

スポンサード リンク
[ 2月23日全て ]

2017年2月28日 (火)

第17回 エッセンシャル スクラムを読む会

エッセンシャル スクラム: アジャイル開発に関わるすべての人のための完全攻略ガイド

社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会の17回目。今日は第17章 エンビジョニング (プロダクトプランニング)。

「エンビジョニング」という言葉に馴染みがなかったので「プロダクトプランニング」の方がわかりやすいよなーと最初は思ったのですが、慣れてくればエンビジョニングでも「ビジョン」に意識が向いていい気がしました。

エンビジョニングのタイミング

何度も繰り返すアクティビティであり、一度やってそれで終わりではない。

これ系のアクティビティはどうしても半期毎のサイクルになってしまいがちなのですが、アジャイル的にはもっと早いサイクルにやった方が良いということですね。

エンビジョニングをやりすぎないようにエンビジョニングの完了予定日を設定しておくのは確かに必要だなと感じました。やろうと思えばいくらでもやれてしまうものなので期日を明確にした方が経済的でしょう。

エンビジョニングの参加者

最初のエンビジョニングで必須なのはプロダクトオーナー。いったんプロダクトの開発が動き出して以降のエンビジョニングにはスクラムチーム全体が参加すべき。概要レベルのプロダクトバックログの作成でストーリー記述する際もスクラムチームメンバ全員が関わった方が良いと言っています。

このあたり結構孤独にやっちゃうことも多いんじゃないかと思うですが、やはりチームでやった方が良いようです。

価値のカテゴリ

図17.3 で「ステークホルダーが得る価値の分野」としてカテゴリ分けされているのは地味に便利ですね。

  • 参入条件
    • ハードルをクリアする
    • リリース可能な最小限のフィーチャーをデリバリーする
    • SOX、FDA、HIPAAなどに準拠する
  • 使用可能性
    • 新たなマーケットを対象とする
    • 他のプロダクトやサービスを販売できるようにする
  • 差別化要因
    • 競合他社と差別化する
    • 顧客を喜ばせる
  • 妨害
    • 競合他社の差別化要因を無力化する
    • ハードルを上げる
    • 市場での注目先を変えることで、ゲームのルールを変える
  • コスト削減
    • 市場に投入する時期を早める
    • 開発工数や投入する要員を減らす
    • 利益を増やす
    • プログラミングの技術を高める

自分が取り組んできたものだと「顧客を喜ばせる」「要員を減らす」とかが多かったですが、製品・市場によっては確かに妨害とかもあるのでしょうね。

今日は参加者少なめで5人。23章までいれるとあと6回のところまできました。

[ 2月28日全て ]

2017年3月8日 (水)

複数スクラムチームでのプロダクトバックログ振り分け

今まで3つのスクラムチームで別々のプロダクトバックログをもっていたのですが、より大きい視点で優先度を考えつつ優先度の高いフィーチャーから集中的に取り組めるようにしたいと考えるようになりました。

このためしばらく前にいったんプロダクトバックログを1つにまとめました。

人数が多くてプロダクトバックログリファインメントがうまくいかず

プロダクトバックログを1本化してから3回ほど合同でプロダクトバックログリファインメントをしてみたのですが、これはあまりうまくいきませんでした。やはり人数が多いと議論が進まなかったり、人によっては自分ごとに考えにくくなったりしたようです。

プロダクトバックログアイテムの振り分け方法が決まっていない

またどのチームがどのプロダクトバックログアイテムを担当するかも決めていなかったので、先にスプリントプランニングに入ったチームからやれるものを順番に取っていくかたちになっているという課題もありました。

今回合同プロダクトバックログリファインメントと振り分けはうまくいきませんでしたが、これもまた一つの良い学習だったと思っています。

チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します。 -- アジャイル宣言の背後にある原則

LeSS

やはり複数スクラムチームで仕事を進める場合は代表者を立てる進め方が良いのでしょうか。LeSS (Large-Scale Scrum) のやり方をまず部分的に取り入れてみることにしました。

各チームの代表者が集まって Overall Product Backlog Refinement と Sprint Planning One にあたるアクティビティでスクラムチーム別に振り分けを行い、その後各チーム別にプロダクトバックログリファインメントやスプリントプランニングを実施するようにしてみたいなと。

取り急ぎ今日からのスプリントに入れるように急遽集まって振り分けを行いました。スプリントレビューやふりかえりについてはまた別途考えていきたいなと思ってます。

[ 3月8日全て ]

2017年3月14日 (火)

第19回 エッセンシャル スクラムを読む会

エッセンシャル スクラム: アジャイル開発に関わるすべての人のための完全攻略ガイド

社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会の19回目。今日は第19章 スプリントプランニング。ここから「第IV部 スプリント」。スクラムチームにとって馴染みがあるパートです。

スプリントを回すにあたり第19章はすでに何度か先読みしているところですが、あらためて書籍にあたり気付きを得て実践していきたいところです。

タイミングと時間と参加者

スプリントプランニングはスプリントを開始するときに行います。2週間から1カ月のスプリントで4〜8時間ということなので、単純に計算すると1週間スプリントでは2時間程度でしょうか。

今は1週間/2週間スプリントのチームで賞味30分から45分ぐらいしかやっていません。実際時間不足を感じています。

  • チームメンバが2時間のプランニングミーティングに耐えられない。きちんとスプリントプランニングするメリットを感じられていない。
  • 3チームのプロダクトオーナー(自分)が時間を確保できない。

もちろん長ければ良いというものでもありませんが、もし不足だとしたらこのあたりが適切な時間をかけられていない障壁かなと。前者はチームが成長することで解消される気がします。後者は LeSS (Large-Scale Scrum) の2段階のスプリントプランニングにしてチーム別のにはプロダクトオーナーは出ないという形式にするという解決案も思い浮かぶのですが、参加しないデメリットを考えると躊躇してしまいます。

プロダクトバックログアイテムにかけるキャパシティ

完成させる自信のある計画を行うにはキャパシティの把握が不可欠になります。

 スプリントのキャパシティ
   = PBI にかけるキャパシティ + スプリントバッファ + それ以外

予定している休暇があるのにスプリントプランニングの際に宣言しないのは不誠実だということになるでしょう(休んではいけないということではなく、わかっているのに共有しないということが問題。体調不良等による突発的な休みももちろん別の話)。

今のところ自分たちのチームではベロシティ(ストーリーポイント)でなんとなくキャパシティがこれぐらいかなといった感じでしか考えられていませんが、次のスプリント期間をまず見通すことも必要だなと感じました。

作業時間を使ったキャパシティも紹介されていますが、実際ここまで精緻に管理したいと思うことはあまりないんじゃないかなという印象です。

プロダクトバックログアイテムの選択

基本優先順位順ですがスプリントゴールを示している場合はその限りではなく、またスキルの問題などでコミットできないプロダクトバックログアイテムはスキップするという選択も考える必要があります。

完成できそうにないプロダクトバックログアイテムを選択してはならない。プロダクトバックログアイテムが大きすぎて完成できそうにない場合は、顧客にとって価値のあるアイテムに分割するか、完成できそうな別のアイテムに着手する。(中略)未完成のアイテムを次のスプリントに繰り越していくと、スプリントの終了時に出荷判断可能なプロダクトインクリメントを手に入れるという目標がいつまで経っても達成できない。

ここがいつもスプリントプランニングでぶちあたるところです。プロダクトバックログリファインメントがしっかりできていないんですね。プロダクトバックログリファインメントは最重要レベルのアクティビティなんだなと。

タスク分解と作業時間見積もり

自信の獲得のためにタスク分解と作業時間の見積もりをまずしましょうとあるのですが、タスク分解と見積もりの方法については触れられていません。ここは自分たちで考えて頑張れという感じなんですかね。一般論にはできない部分だとは思いますが、ここは大ハマリするところなので参考になる話があると嬉しいなと思ってます。

スプリントプランニングでタスクを個人に割り当てるのは有害だというバッドプラクティスが挙げられていますが、ここは次の「スプリントの実施」で語られるところのようです。

[ 3月14日全て ]

2017年3月28日 (火)

第21回 エッセンシャル スクラムを読む会

エッセンシャル スクラム: アジャイル開発に関わるすべての人のための完全攻略ガイド

社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会の21回目。第21章 スプリントレビュー。スプリントの中でいちばんうまく出来ていないスプリントレビューの話です。

スプリントレビュー

スプリントレビューは作業結果(出荷判断可能なプロダクトインクリメント)の検査と適応をするアクティビティです。

不都合な真実も含めて、現在のプロダクトの状況を透明に見せてくれる。

という、ちょっと最初は勇気が必要なアクティビティです。

この章によるとスプリントレビューはスクラムチームがスクラムチーム外の人に説明しフィードバックを得るための機会なのです。しかしながらついチーム内の確認の場になりがちで、チーム外の人からきちんとフィードバックを得られていないと反省しています。

スケジュールの調整

スクラムチーム外の参加者が最も多く、スクラムのアクティビティの中では最もスケジュールの調整が難しいと述べられています。たしかに。ステークホルダーのスケジュールに合わせてスプリントレビューのスケジュールを決め、それに合わせて他のアクティビティを合わせるのが現実的とのことでした。

スプリントレビューに参加してくれないようなら、それは開発する価値のないプロダクトということである。したがって、プロダクト開発を注視すべきだろう。

きちんと参加者が集まらない場合は同時並行の作業が多すぎないかも見直すべきなのかもしれません。

スプリントレビューのアウトプット

リファインメント(グルーミング)したプロダクトバックログと更新したリリースプランがスプリントレビューのアウトプットだと書かれています。

ほとんどのチームはスプリントレビューでグルーミングをしている。関係者全員が開発の現状と今後を理解して、新しいPBIを作成したり、既存のPBIの優先順位を変えたり、不要なものを削除したりする。

これも全然意識できていないところ。今はコメントをもらって終わりになっています。きちんと対話をしプロダクトの適応をするところまで実現できていないなと。

デモ

デモが難しいからといって、それはデモをしない理由にはならない。

プロダクトオーナー側でも「まぁいいか」と思ってしまうの良くないですね。反省。

スプリントレビューはスクラムマスターと協力してきちんと設営していく必要があるなと感じました。

[ 3月28日全て ]

2017年4月14日 (金)

第23回 エッセンシャル スクラムを読む会 (最終回)

rimage:/nDiki/2017/04/14/2017-04-14-092915-nDiki-800x1200.jpg

社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会の23回目。第23章 未来へ。ついに最後の章です。

スクラムは継続的な改善の一形態なのだからこれが最終形態というものは無いし、どのチームをとっても同じというものは無い。プラクティスはあってもベストプラクティスはチームによって違う。準備ができていないからスクラムを始められないというのはそもそも原則に反するので、まずやって学ぼう。現状を変えるよりもスクラムを無視したりスクラムを変更したりすることの方が簡単だけれど、組織を変するために協力しあいながら確固たる信念をもって立ち向かおう。

そんなメッセージを本章から受け取りました。

第1章の「スクラムは役に立つか?」で出た通り全ての領域でスクラムが適しているわけではないので、盲目的に導入すれば良いというものではなく、領域が変わった場合はスクラムを続けるか続けないかの判断が必要になるのでしょう。もし取り組む領域が「複雑な領域」であるならばスクラムフレームワークはとても強力だということは間違いありません。

「エッセンシャル スクラム」と「エッセンシャル スクラムを読む会」そしてなによりこの半年のスクラム開発経験でスクラムについて多くを学ぶことができました。「エッセンシャル スクラム」は「スクラムガイド」を読んだだけでは得られない広範囲な知識やノウハウが詰まった良い一冊でした。

エッセンシャル スクラムを読む会ふりかえり

エッセンシャル スクラムを読む会を終えたあとは、オフィスのコラボスペースでビールを飲みながらお疲れさま会。参加の皆さんお疲れさまでした。この回を始めてくれたはらかち氏に感謝。休まず毎回参加してディスカッションしたことでいろいろな学びを得ることができました。嬉しい限りなので珍しく私もビールで乾杯しました。いっしょに全回参加した2人のうちの1人である RabbitFake 氏も特にお疲れさまでした。

ふりかえって出てきた話題としては

  • 取り組む領域がクネビンフレームワーク(第1章)のどの領域なのかを見てスクラムを採用するかどうか考えたい。
  • チームメンバでエッセンシャル スクラムを読むことで「PBI」などの同じ理解で使える言葉が増えた。チームの共通言語作りに貢献できた。
  • 原則大事(第3章・第14章など)。
  • WIP を下げる重要性をあらためて学んだ。
  • 準備完了の定義・受け入れ条件が重要。

などが上がりました。

また実際に読む会と並行してスクラムを行ってきた中で

  • プロダクトバックログリファインメントで1スプリントにおさまるように適切にプロダクトバックログアイテムを分割するの大変だよね。
  • スクラムマスターと開発チームメンバ(エンジニア)との兼任が難しかった。
  • スクラムマスターであると同時に組織図上のリーダーという立場でいると、自発的行動を促すのとある程度指示的に動かすのとの兼ね合いが悩ましかった。
  • 困った状態であることにメンバが気がつくのを3カ月待った上で物理かんばんを導入してみた(すごい)。

などの話が出ました。

スクラム実践についての「検査と適応」をタイムリーに勉強会をしながら進められて学びの多い半年間でした。

全23回

エッセンシャル スクラム: アジャイル開発に関わるすべての人のための完全攻略ガイド

[ 4月14日全て ]

2017年8月1日 (火)

メンテナンスフェーズに入ってきたプロダクトの保守とスクラム

メンテナンスフェーズに入ってきたプロダクトを保守しているスクラムチームのプロダクトバックログが枯渇してきました。無理に新しいことを絞り出して手を入れ続けるのが得策ではない感じに。

もはやスクラム開発には適さない領域に入ってきたのかもしれません。一段上のレベルに戻ってプランニングするのが良さそう。

[ 8月1日全て ]

2017年8月2日 (水)

何もコミットしないスプリントで各自好きなことをする

インクリメントの完成に高いコミット意識をもって毎スプリント取り組んできている CS 開発チームがいくつか大きなリリースを終えたので、スクラムマスターと相談して今日からの1週間スプリントは「プロダクトバックログアイテムについては何もコミットしない」で各自好きなことをして良いことにしました。

リファクタリング・技術的負債の返済・開発環境の整備や、調査・学習・ドキュメントの整理など、いつものスプリント中にはなかなかできないことを各自でしてよい1週間です。

普段から持続可能なペースを意識してスプリントプランニングしていますが、それでも頑張り続ければストレスも溜まってくるでしょう。適切なタイミングでブレイクを挟むことで、バーンアウトを防ぎ長期的にデリバリーし続けられるチームでいられればと思っています。

ちなみにこの取り組みは去年別のチームが unwinding period と呼んでやっていたのを真似てみたものです。

今回スプリントがどういう感じだったのかは、いつも通りスプリントレトロスペクティブでふりかえってみます。


[ スクラム ]

[ 8月2日全て ]

2017年8月6日 (日)

仕事に追われない仕事術 マニャーナの法則 完全版

仕事に追われない仕事術 マニャーナの法則 完全版

タスク管理の記事を読んでいると「マニャーナの法則」というキーワードがよく出てきます。今までスルーしていたのですがここ最近クローズリストの考え方を取り入れてみているので、その辺りの話が書かれている「仕事に追われない仕事術 マニャーナの法則 完全版 (Do It Tomorrow and Other Secrets of Time Management)」を読んでみました。

マニャーナの法則

まずマニャーナの法則ですが

  • 原則1 新しい仕事は「明日やる」を基本にする
  • 原則2 クローズリストを使う

という2つの原則のこととあります。日本語ではマニャーナの法則と訳されていますが the mañana principle なので「(行動)原則」の方が適切に感じました。

すぐやる」ことの弊害

すぐやると「忙しいだけの仕事」ばかりが進み「本当の仕事」が進まないと指摘しています。新しくきた仕事にすぐとりかかってしまうのではなく、既存の仕事より価値があるかをまず考える必要があると説いています。

すぐやる」は自分の行動原則の一つなのでショッキングな指摘です。言われてみれば主体的な仕事よりも反応的な仕事に時間を使いがちです。

ただ「すぐやる」については

  • 「後回しにしてチャンスを逃す」ことのないようにする。
  • 先送りすることで増大するコストを最小化する。

というメリットがあるのも事実。このあたりは本書で言うところの「緊急レベルの判断」とバランスを取っていく感じなのでしょう。

全員がマニャーナの法則をやるとどうなるか?

個人個人がマニャーナの法則に従ってバッファリングすると組織全体のリードタイムが伸びるのではという懸念を持ちました。個人の稼働が最適化されるかわりに、作業の手待ち(idle work)が多く発生することになるからです。

このあたり要注意に思われます。

緊急レベルを判断する

入ってきた仕事はまず緊急レベルを判断するというのが本書の考え方です。

  • 緊急レベル1「今すぐ」
  • 緊急レベル2「今日中に」
  • 緊急レベル3「明日やる」(ベスト)

本書では「明日やる」がベスト。

これはすでに2週間前からRemember The Milk の優先度設定に取り入れてみています。

WILL DO リスト

その日にやるとコミットしたタスクを入れておくクローズリスト。自分は Remember The Milk でタスクの優先度を1にすることでリスト化しています。

処理する順番はファースト・タスクが最初で「明日のリスト作成」が最後です。それ以外はまったく自由。

1日の最後に何をおいても明日の WILL DO リストは作成することが必須とあります。仕事については実践していますが、プライベートでは翌日の WILL DO リストを夜に作るのがまだ習慣にしきれていません。

ちなみに本書ではタスクにかかる時間の見積もりについてはほとんど触れられていません。翌日時間が足りず WILL DO リストを完了できそうもない場合もいつもどおりリストを作成し翌日は「できるとこまでやる」「完了できない日が続くなら対策をとる」という感じになっています。

やり残しをどうするか?

WILL DO リストで完了できなかったものは、「やり残し」フォルダに放り込み、ファースト・タスクで処理しましょうとあります。

これは今週から Remember The Milk で backlog タグを付けるようにして実践中です。

ファースト・タスク

ファースト・タスクは「毎日の最初に行い、そこから1日をスタートさせるのが望ましい仕事」とのこと。毎朝最初にできる仕事は1つしかないので、常に1つ。

  • 原則1 とにかく、する (Do)
  • 原則2 一番始めに、する (First)
  • 原則3 毎日、する (Every day)

ファースト・タスクに向いている仕事は

  • 「やり残し」を片付ける
  • 仕事のシステムを修正する
  • プロジェクトを進める

です。今は「やり残し」を片付けるのに使っています。先送りし続けることが減りました。

実際のところ実際に一番最初にはやれてなくてまず「セットアップタスク」なるものをやってたりします。これらを前日に済ませるようにできれば本当のファースト・タスクにできるのかも。

ダッシュ法

ダッシュ法はポモドーロテクニックにつながるところを感じました。ちょっとマニアックでテクニカルなやり方だというのと、マルチタスク型な印象なのとで今回はスルー。

二分等法 すべての仕事を半分にする

プロジェクトをタスクに分解する方法。 GTD でプロジェクトに対して具体的な行動を設定するのと同様、本書でも具体的な行動に落とし込むよう指導しています。

その具体的なやり方として二等分法というのが紹介されていました。プロジェクトを二等分し、先にやる方をまた二等分にするというのを繰り返して「抵抗感が問題にならない状態」になるまで分割を続けるという方法です。

全てをブレークダウンすることはせず直近取り組む部分だけ具体的にするというやり方がスクラムにおけるプロダクトバックログリファインメントの考え方に似ていて気に入りました。

行動の合間に考える習慣をつける

最後の方の「考える」ということについての話で「行動の合間に考える習慣をつける」エクササイズが紹介されていました。

  • 「毎日15分」など時間を決め確保する。
  • 邪魔が入らない場所でノートと筆記用具を用意し、浮かんできたアイデアや考え方をノートに書き留める。
  • 時間の終わりに近づいたら書いたものについて考える。良いアイデアや行動が必要なことに下線を引く。

というものです。時間(期限)を決めその時間の最後まで考え抜くというのがポイントだそう。ぜひ取り組んでみたいなと思います。

冒頭にキーワードが説明されているのが良かった

最後に本書の構成について。

本書では冒頭で「本書に登場する18のキーワード」として

  • 「クローズ・リスト」「オープン・リスト」「チェック・リスト」
  • コミットメント」「本当の仕事」「忙しいだけの仕事」
  • 「バッファー・ゾーン」「マニャーナの法則
  • 「タスク」「プロジェクト」
  • 「タスク・ダイアリー」
  • 「デイリー・タスク」「ファースト・タスク」
  • 「TODOリスト」「WILL DOリスト」
  • 「ダッシュ法」「期限の効果」
  • 「ラベリング」

が列挙されてそれぞれに簡単な説明がついています。簡潔でわかりやすく、本を読み進める助けになります。

本では「はじめに」で第1章では◯◯、第2章では△△とずらずらと書かれていたりしますが、前提知識が無いとわかりにくい書き方のものが多いです。それに対して、本書ではキーワードという見出しでサマリと流れをうまく説明していて素晴らしいなと感じました(ちなみに本書も「はじめに」では構成が手短に説明されています)。


[ 読書ノート ] [ お薦めの本 ]

[ 8月6日全て ]

2017年8月15日 (火)

今日のさえずり: アイデンティティを作り上げている大好きなものを再認識できる偏愛マップ作り

2017年08月15日

[ 8月15日全て ]

About Me

Naney Naney (なにい)です。株式会社ミクシィでマネージャー・PO をしています。

nDiki1999年1月に始めたコンピュータ日誌を前身とする NaneyWeb 日記(兼パーソナルナレッジベース)です。ちょっとしたノートは nNote にあります。

follow us in feedly

※内容は個人的見解であり所属組織とは関係ありません。

月別インデックス
Process Time: 0.07677s / load averages: 0.47, 0.37, 0.31
nDiki by WATANABE Yoshimasa (Naney, Google profile)
Powered by DiKicker