サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
レイングッズ
note.com/papanda0806
先日、2つのカンファレンスがあった。エンジニアリング組織に関するカンファレンスと、プロダクトマネジメントに関するカンファレンスの2つ。いずれにも登壇させて頂き、それぞれの領域での熱気を味わうことができた。 前者のカンファレンスを終えて、相談に来た人からこんな質問をもらった。 「プロダクトとして何を作るべきかを探索するために仮説検証などをやりたいが、プロダクトオーナー(プロダクトの企画者的存在)をどう促せば良いか悩んでいる」 これまでのプロダクト開発の在り方を見直したいが、いわゆる事業を預かる側に開発者としてどう関わっていけば良いのか、という内容だった。 後者のカンファレンスでも、別の質問をもらった(もちろん先の質問者の所属とは異なる)。 「プロダクトオーナーとして仮説検証を進めていきたいが、どうやって開発チームを巻き込めば良いだろうか」 こちらは逆に、プロダクトオーナー側からの相談だ。開発
なりたい自分リスト、できないことリスト 仕事が上手くいかないと、焦り、ストレスに繋がりやすい。ストレスが重なると自分はもう何も出来ないダメな子で、この目の前の仕事を回避したほうが良い(自分なんかがやってちゃダメだ)と思うようになる。真面目な人ほどそうなる。 なぜなら、真面目な人ほど理想の状態をきちんと思い描いているからだ。どうありたいか、何ができるようになるべきか、リストをつくったりする。このなりたい自分リストが思いの外、仕事の熟達を阻む。 なりたい自分よりむしろ、自分のダメな状態、苦手でよくミスすることをリストアップしている方が仕事の成果には繋がりやすいと感じる。苦手に感じる自分の姿をイメージするのは嫌な人もいると思うが、できないことリストは人に見えるところに置いておくくらいが良い。周囲の自分への理解が自ずと深まる。 ドラッカー風エクササイズ(B面) 「ドラッカー風エクササイズ」という、
仕事には見積りと計画づくりがほとんどの場合、欠かせない。ただし、「見積りは意思決定のために。計画づくりは気持ちを繋げるために」に至るまでには、いくつかの段階がある。 見積りと計画づくり1.0 仕事を始める前に緻密に見積りして、詳細な計画を立てる。勿論大変な作業になる。でも大丈夫だ、この作業をやるのは最初の1回だけだからね。というわけで、容易に計画が変わらないようにWBSなどの管理表に焼き付けておく。現実が計画から乖離し始めただって?現実を計画に合わせるために手を打つんだ。 見積りと計画づくり2.0 プロジェクトの最初に行う見積りは正確性が低いものだ、その結果、計画の通りにはいかない。…ということを受け入れて、むしろ見積りを計画づくりを頻繁に行おう。何かプロダクトを作っているならば、リリースに向けて(3ヶ月〜半年くらいか)と、一・二週間単位と、今日一日での計画づくりを行うと良い。一日の結果は
先日、また一年歳を取った。気がついてみればソフトウェア開発という世界に身をおいて、ずいぶんと歳月を重ねてきた。実に20年近い。この20年だけ取ってみても、様々な変遷を経て様変わりしたところと、大して変わらないところとがある。後者の一つが「チーム開発の難しさ」だと感じている。使う技術も、支える環境も、プロセスも勿論変わっているが、チーム開発が楽勝になったためしは未だ無い。変わらない難しさがずっとある。 思うに、人が他者との間でミッションを特定し、前提を把握し、お互いの強みと弱みを理解しあい、少しずつアウトプットを重ね、その過程で起きる不具合を適宜ふりかえりによって解消しながら、感情にも向き合いながら漸次的に物事を進め、成果を上げる...という行為がそもそもとてつもなく高度であって、上手くいかなくなる箇所がいくらでもありえる。 そうした人と人の相互作用を如何に上手く噛み合わせて、活動がなめらか
サイバーエージェントの有志の方から「正しいものを正しくつくるを、ABD(アクティブ・ブック・ダイアログ)で読んだので、見に来て欲しい」とお誘いを受け、一も二もなく行ってきた。 本を書いた人間が、発刊後最も喜びを感じるのは読んだ人との対話だと思う。苦労して書いた内容をどう受け止めてくれたのか。もちろん、良い結果を聴きたいし、疑問には出来る限り答えたいと思うのだ。 行ってみると、壁一面に要約アウトプットが張り出されていた。 圧巻。ABDのやり方は、まず本を切り刻み(ごくり)、例えば1章ずつなど範囲を決めて、範囲の中で複数人が分担してパートをその場で読む。複数人で割るので一人あたりの分量は少なくて済む。その場で読んで、何が書いてあったかを要約する。お互いに要約について発表し、他の人の読んだところ、つまり自分が読んでいない部分の内容を把握する。そうして、内容を踏まえたディスカッションを行い、学びを
講師をつとめる研修の終わりに、参加者からの質問というか相談に答えるようにしている。先日の研修で、ある受講者から「職場の開発をアジャイルにしていきたいがどうしたら良いか」というよくある相談が寄せられた。実はこの手の相談はやりとりに手間がかかる。相手の置いている前提、置かれている状況を的確に把握しなければならない。 私「なぜ、アジャイルに取り組みたいのですか」 まず、狙いを聞かねばならない。Start With Why。ここが分からないと何を聞いて答えても的外れにしかならない。ここで、いきなり「見える化から取り組むといいですよ」「もちろんスクラムですね」と、手段を提示しはじめるような相手だと、相談するのはやめたほうが良い。 受講者「スピード感のある開発をしないといけないと思っています。ユーザーの声を聞いて、それを実装していけるように」 私「なるほど、"何をつくるべきか分からない" ソフトウェア
このモデルを使って、主に仕事の上で、より効果的な経験学習「学びの密度を上げる」ためにはどういう状態を目指せば良いのか考えてみた。 具体的経験の密度を上げる 経験を増やす、つまり仕事をたくさんこなす、多くのアウトプットを出力するよう努める。この密度を突出させて上げていくと、このモデルの回転が間に合わず、多くの経験が「やっただけ」で終わる可能性が高い。 仕事であればアウトプットに伴う対価は増えるかもしれないが、やたらめったら忙しいだけで学び薄いという状況になりうる。仕事量が増えるということは、その分他のこと(内省、概念化、実験)に時間の配分ができないからだ。 この状況は危険だ。そして、私もこの5年ほどはどちらかというと「経験過多」にあった。この5年は会社の立ち上げということで、それまでの人生には無いくらい仕事を気張っていた。物理的な時間の意味でそれまでの仕事量の2〜3倍、質的な意味ではもっと何
ワークショップとは、ある意図によって進行の手順が用意された、作為的な場である。一人ひとりが個別にワークして処理にあたるのではなく、複数の人間が同期的にワークを行うことで、個別の意見や発想を反映しつつ、一人では到達できないアウトプットを生み出すことを狙いとしている(これを創発と呼ぶ)。必要な人間が集まって実施するため、その間での意思決定も早められる。 こうしたワークショップのコツには2つの観点がある。「発散と収束」そして「詳細と俯瞰」だ。 発散と収束 議論、発想を十分に発散させてから、収束をはかる。この収束の時に、大量に出てきた意見をどういう順番でまとめるかが一つ大切だ。原則は、寄せてから名前付け。近しいと感じる意見を位置的に近づけるという行為をすべての意見に対して繰り返し行い、全体を編成する。 これを先に分類するラベルを決めて、それに対して寄せるということを行ってしまうと、ラベルをつくった
組織には理念が必要で、それを組織の中に行き渡らせないといけない、ということを長らく思っていた。実際には、まず理念と呼べるものが無い組織が圧倒的に多いのではないかと思う。ここでいう組織とは、会社の場合もあるし、コミュニティの場合もある。チームにも当てはまる。 理念はどうやってできるのだろうか? 組織をリードする者が、みんなに受け入れられて、自分事にできそうな内容と表現を生み出す。あるいは、入り口だけ用意して、中身をみんなで練りながらつくっていく。いずれにしても、理念は自然発生的には形にならないので、意図をもった存在が理念づくりに必要になる。 運良く理念を手にしたとして、リーダーは次に、理念が組織のみんなの中に宿り続けるよう、働きかけるところで苦労する。組織の中の誰を取り出しても、統一見解。一糸乱れぬナントカで、行き渡っている。それが組織(会社、コミュニティ、チーム)の強さになる。…と思ってい
ある日、社内のメンバーと話していて面白いメタファを耳にした。われわれはまるで「動物園」のようだという。動物園にはお猿さんや、馬や鳥、魚類も居る。種の多様性がそこにある。会社に集まった自分たちも多様だという。確かに、プログラマーもいれば、ユーザー体験の専門家もいれば、プロジェクトマネージャーもいる。現場のコーチだって居る。職務で見ると、幅が広い。小さな動物園だけどその多様な生き物を預かる園長は大変だぞを、その時はオチにして終えた。 しばらく経ってから、自分たちのあり方としては動物園より「サファリパーク」なのではないかと思うようになった。動物園の動物たちは観客に危害が及ばないように鉄格子の檻の中に入れられている。この鉄格子はいわば組織の法だ。組織には意思疎通、相互交流を促すためのルールが必要だ。だが行き過ぎると統制された秩序のために組織や個人が存在している、ということになってしまう。 私は、い
年末年始で自分とむきあう時間が取れて、休み明けは新たな気分で日常を迎えた。自分の戦略を立て直して日々に臨み直す。今まで力を入れていたところから、これからは変える。 …と決意して、2週間ほどでも経ってみると、もうその誓いが遠い記憶であることに気づいた。気づけるならまだいい。その誓いのことを3ヶ月後、半年後に思い出すことだってあるだろう。この現象は何だろうか!考えてみると、仕事に必要な観点「詳細」と「俯瞰」にまつわる力学の存在に気がついた。 詳細とは、仕事の最前線のことだ。そこでは具体的なタスクを行う。コードを書く、資料をつくる、ミーティングを運営する。一方俯瞰とは、仕事の全体像を眺める立ち位置のこと。詳細とは真逆で、一歩離れて観察し、分析する。 そう捉えると、現場とは詳細が支配的な場所だ。何かを生み出したり、進めたり、解決するための場だから、詳細にむきあう時間が長くなる。現場は詳細を頂点とし
プロダクトづくりには2つのモードがあると思う。チームファースト(Team Fisrt)と、プロダクトファースト(Product First)。チームファーストは、チームとしての状態がより良くなることに重きを置き、その基準でプロセスや活動、評価、時間軸の最適化を行う。 一方、プロダクトファーストは、成果を重視する。具体的にはプロダクトの開発だったり、事業としての目標達成を活動の中心に据える。もちろん2モード間でゼロイチということではなくて、判断基準をチームとプロダクトのよりどちらに置くのかという考え方である。 まず一つの結論として、2つのモードの間でどちらかが正義で、一方がダメだとかそういう捉え方ではなくて、どちらも局面によって必要になる。何らかのプロダクトを軸に事業をスタートアップしようとする局面なら、まずはプロダクトが無いと始まらない、プロダクトファーストを取る場合が多いだろう。あるいは
昔に比べて、タスク管理の必要性が減っている…どころか、クライアント向けの現場仕事、経営、自社プロダクト、(別の会社の)経営、マーケティング、コミュニティ、執筆etcと、多種多様なタスクが押しよせてくる。いつまでにやるべきか、どれを先にやるべきか、カテゴリを越えて横断的に把握、判断しないといけないため、タスク管理はとても大事。 思えば、タスク管理をどうやるかという話題について、デベロッパーのアンテナは昔から高いと思う。タスク管理ツールとして何を選ぶかで、迷った経験は一度や二度ではないはずだ。新しいものが出たと聞けば試す。そうやって自分にあったものが手元に残るわけだ。私の場合は、Googleカレンダー。 なぜ、ここに行き着いたかというと、実施日問題とパーキングロット(駐車場)問題の両方が解決できたからである。タスク管理ツールは大きくわけて2種類ある。リスト型と、カンバン型だ。リスト型の代表例は
昔から、さまざまなコミュニティをつくってきた。ただ、どれも長続きはしなかった。結局、今も残っているのは一つだけ。最初は集まってきたみんなもこれから始まることに期待でいっぱい。すごい盛り上がりを見せる。ところが、たいていの場合わずか2回目の集まりを経たところで、もう衰退期に入っていく。3回目には集まる人数が激減する。ここまで2-3ヶ月程度のことだ。コミュニティは2回集まると死ぬ。 長らく、その理由が分からないでいた。どういう工夫をとっても、たいてい死んでしまう。どういう集まりだったとしても。顔ぶれが違っていても。同じ道を辿る。まるで私だけタイムリープを繰り返しているかのように。2回目で死を迎えることになれてしまっているし、特に驚きもしない。ただ無力さだけはいつも感じていた。 ある時、一つの仮説に思い当たった。ヒントはリモートワークだった。仕事として、リモートワークを基本とする日常を送り、組織
このページを最初にブックマークしてみませんか?
『市谷 聡啓 (papanda)|note』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く