ninjinkun's diary

ninjinkunの日記

戦争と平和を読んだ

昨年からぼちぼち読んでいて、先日読み終わった。どういう話か知らずに読み始めたのだけど、ナポレオンのロシア遠征を題材に、史実の人物とオリジナルキャラクターを混ぜて作ったフィクションとノンフィクションの間みたいな小説だった。物語の中に戦争の時期と平和の時期があるだけで、特に反戦とかそういう内容ではない。

岩波文庫の新訳がとても読みやすく、また訳者によるロシアの風俗や戦争の話が途中にコラムとして挟まっていて、内容を補完してくれて楽しめるようになっている。

簡潔で気の利いた文章

読んでいると、うまいこと言うなーという箇所がいくつもある。文読む月日とかを書くだけあって、トルストイは簡潔で気の利いた文章に執着があるのかもしれない。以下にいくつか抜粋。

「うん、すばらしい、すばらしい子どもたちだよ」なんでもすばらしいと考えることで、自分には手の負えない問題をいつも解決してきた伯爵が相を打った。

1巻。ロストフ老伯爵という、好人物だが実務能力ゼロという人間を描写した一文。

ニコライは底意地の悪い目でピエールを見ていた。それは、第一に、軽騎兵流の彼の目から見ると、ピエールが文民の金持であり、美人の夫であり、要するに女の腐ったやつだったからだった。

2巻。ピエールは主人公の一人。いきなり莫大な遺産が転がり込んできたというチートキャラ。読んでいると、チートキャラだけど彼なりの辛さも抱えているしな…と感情移入しそうなっているところにこの一節。やっぱりピエールは女の腐ったやつだったのかと胸が空くようなニコライの批評。原文がなんなのか気になるけれど、とりあえずこの訳はとても気持ち良く決まっている。

彼は自分でも気づかないうちに、大きな口に酒を何杯かあおって、体にこころよい暖かさを感じ、近くの者みんなにやさしい愛情を感じ、ありとあらゆる考えに対して、その本質を掘り下げずに、表面的に応答する気になったときにはじめて、完全にいい気分になるのだった。

3巻。酒飲みの思考をトレースしている。

死と戦っている十万を超える人間を、一人の人間が指揮できないことを、彼は長年の戦争の経験で知っており、老人の知恵で悟っていたし、戦闘の運命を決するのは総司令官の指図でもなく、各部隊が占めている位置でもなく、大砲や死者の数でもなく、部隊の士気と呼ばれている、とらえがたい力だということを知っていた。

4巻。マネージャーは無力。

何かを望んでいる人間は、望んでいるものをあたかも裏書きするように、すべての情報をまとめる傾向のあることを知っていた。また、そういう場合、矛盾するものはすべて進んで見逃してしまうことも知っていた

5巻。バイアスについての考察。

以前、彼はいい人間だが、不幸な感じだった。そのため、自然に人は彼を避けていた。今では生の喜びの微笑がたえず口のまわりに漂っており、目には人に対する関心がみんな自分と同じように満足しているだろうか? という問いがかがやいていた。そのため、人は彼といっしょにいるのが楽しかった。

6巻。ピエールが様々な経験を積んで内面が変化した後、人々に受け入れられていく場面。

最終巻になぜか付いている訳者のQ&Aも面白い。

Q 第四巻二二九ページのコラム「貴族の荘園」を読んで、ちょっと寂しくなりました。こんな恵まれた人の書いた小説を、私のようなせせこましい生活をしている人間が理解できるのかと。

A いや、大丈夫ですよ。人間の問題はたいてい時空を越えているでしょう。それに、今の日本人の充足感と空虚感は、ロシア貴族に近いかもしれません。逆に、当時の庶民の重労働や飢餓感を想像することの方が難しいでしょう

著者語る

内容はロマンスありの戦記ものという体裁なので、ぐいぐい読んでしまえる。しかし途中に作者が自分の歴史観を開陳する部分が挿入されていて、これが結構曲者だった。

物語の途中に挿入されている部分は短くてまだよかったのだけど、最後の巻にあるエピローグに文庫の半分のページ数を使ってさらに濃密な語りが入っていて、これがなかなか辛い。物語が終わってからそのまま読み始めたら、全然終わらないし内容は哲学的で小説みたいにテンポよく読めないしで、「俺は早く終わらせて物語の余韻に浸りたいんだよ!」と自分は一人でキレていた。

後日日を空けてから読んだら、歴史と個人の関係を真摯に考察していて面白い文章として読めたので、時間を開けて読むのがいいのかもしれない。

とりあえず今は長い小説を読み終わったあとの満足感に満たされている。

戦争と平和 (一) (岩波文庫)

戦争と平和 (一) (岩波文庫)

DroidKaigiの発表を募集しています(11/30締め切り)#droidkaigi

droidkaigi.github.io

4月に行われたAndroidエンジニアのお祭り、DroidKaigiの第2回が2016年の2/18、2/19開催予定で、現在発表を絶賛募集中です。自分は今回もスタッフとしてお手伝いさせて頂いています。

自分は前回発表したのですが、その後「資料見ました」と言ってくださった方が入社したので、直接のコンバージョンかはわからないですが、採用実績も1あります。

また、初心者向けセッションも要望が多いので、そういった発表もお待ちしています。2016年にAndoidを始めるのに一番近道な方法まとめ とか、とても喜ばれそうです。

技術を深掘りしたい方、裾野を広げたい方、採用に繋げたい方、DroidKaigiはあなたの発表をお待ちしています!

情報共有ツールお悩みNight #1に参加してきた

実は既に今日#2があるのだけど、#1に参加して感想を書いていなかったので、メモを引っぱり出して書く。

Qiita::TeamのIncrements社が主催の情報共有ツールお悩みNight #1に参加してきた。他社の事例とかを聞いてみたかったので。

内容

  • ワークショップx2
    • 事前に募集した情報共有のお悩み(架空のものという設定)に大してチーム毎にブレスト、発表する
    • 自分のチームのお題は「投稿しても見てくれない人が居る」「ツール導入の効果を計測しろと言われた」というものだった
  • LT
  • 懇親会

ワークショップのファシリテーターを任されていたので、聞き役に回って少し突っ込みを入れる役をやった(その割に結構喋ってしまった)。

感想

他社の話を聞いてみて、FablicはQiita::TeamやSlackをそこそこうまく使っている方なのかもしれないと思った(事例)。日報をGoogle+に移したのも、自分は当時あんまりよく思っていなかったけど、結果的にはその後濃いエントリが増えて正解だったと思う。

他社の抱える悩みとしては以下のものがある感じだった。

  • 開発チームだけで使っているけど全社に広がらない
  • 導入してみたけど盛り下がっている
  • 日報の滝
  • カジュアルなエントリばかりになってこれ意味あるの?
  • 一方でカジュアルなエントリももっと増えても良いんじゃないの

イベントの設計も面白くて、事前にイベント用のQiita::Teamが作成されて全員の自己紹介とリアルなお悩みの募集が行われた。この募集されたお悩みがワークショップのお題になっていて、よくデザインされたイベントだなと感心した。

今後も継続して行われるとのことなので、興味がある人は参加してみると面白いかもしれません。

追記

情報共有ツールお悩みNightは情報会議に名前が変わったそうです

コンサートに行ったのだけど、途中から誰か入ってきたなと思ったら皇后の人で、さすがにびっくりした。周りの人たちも「ほう…」という感じで目を細めながら拍手していた。

皇后さま、内田光子さんのピアノ鑑賞:朝日新聞デジタル

家カンバン

会社でホワイトボードを使ってカンバン形式でタスク管理をしているのだけど*1、ホワイトボードと付箋の組み合わせが好きなので家でも使っている。

f:id:ninjinkun:20151014003030j:plain

貼っているのは読んでいる本とブログのネタ、あとはたまに進める自分のプロジェクト。週末に途中まで何かやって忘れることが多いのでそれを管理するのと、一度にたくさんのことを始めないように制御する役割がある。また、Doneに一個でも移せたら、その週はなんかがんばったという感じが出る。

実はこれはドアである。

f:id:ninjinkun:20151014003059j:plain

吸着タイプのホワイトボードをドア(木製)に貼って使っていて、とても調子が良い。コクヨの技術はすごい。

コクヨ ホワイトボード ピタボ 吸着シートタイプ 無地 FB-P152W

コクヨ ホワイトボード ピタボ 吸着シートタイプ 無地 FB-P152W

*1:Pivotal Tracker、Trello、HuBoardと来て今はアナログに落ち着いている。個人的には手を動かして付箋に字を書く作業が好き

Making It Right: Product Management For A Startup World を読んだ

Rebuild: 98で紹介されていたので、英語だけどがんばって読んでみた。Inspiredと同じ方向性のプロダクトマネジメント本。違う人が同じ事柄について書いているという印象。しかし少しずつ違う視点が入っていて、プロダクトマネージャーの役割が立体的に見えるという意味で両方読む価値はあると思う(もう読んでしまったのでこう言うしかない)。

英語はかなり平易。使われている語彙がだいぶ簡単なので、他の英語の本に比べて読みやすいと感じる。それでも自分はちまちま読んで一ヶ月くらいかかった。

話題が割と新しめ。Google Buzzと写真共有アプリのColor(懐かしい!)が失敗した話が導入部分。

またInspiredに比べてスタートアップの文脈が強かったり、初期のビジネス的成功という点に重点が置かれている気がする。

以下、自分が線を引いた部分とコメント。引用の下の日本語は拙訳。

Chapter 1: Role And Resoponsibility Of The Product Manager

余談だけど今まで読んだPM本、だいたいPMの定義から入る傾向にある。

The only thing that matters is getting to product/market fit. Product/market fit means being in a good market with a product that can satisfy that market.

最も大事な事柄は、製品/市場フィットに達することだ。製品/市場フィットとは、その市場を満足させることができる製品を伴う、良い市場という意味だ。

The product manager’s mission is to achieve business success by meeting user needs through the continuous planning and execution of digital product solutions.

プロダクトマネージャーのミッションとは、デジタルプロダクトソリューションの継続的な計画と実行を通してユーザーのニーズを満たし、ビジネスを成功させることである。

It is vastly easier to identify market problems and solve them with technology than it is to find buyers for your existing technology.

手持ちの技術を買う人を探すのに比べれば、問題がある市場を探して技術で解決するする方が遥かに易しい。

First, they need to have their heads in the clouds. PMs need to be leaders who can look into the future and think strategically. They need to be able to develop a vision for where a product should go — and they need to be able to communicate that vision effectively. Further, PMs need to show their teams how they plan to get to that vision. And I do mean show — through sketches, prototypes, storyboards, or whatever it takes to get the message across.

まず、彼らは頭を雲の中に突っこむ必要がある。PMは未来を見通して戦略的に考えるリーダーである必要がある。製品はどこに向かうべきなのかというビジョンを生み出す必要がある。そしてそのビジョンを効果的に伝える必要がある。さらに、PMはビジョンを達成するためにどう計画を立てるかチームに示す必要がある。スケッチ、プロトタイプ、ストーリーボード、メッセージを行き渡らせる方法なら何でも使って。

Good PMs are also able to remain flexible and change course when needed, perhaps when there is a big shift in market needs or expectations, or a great business opportunity presents itself.

良いPMは、必要なときには、そして恐らく特に市場ニーズや期待、偉大なビジネスの機会が存在するときには、柔軟さを保持したまま進路を変更することができる。

Consensus cultures often produce watered down, unexciting products.

合意の文化はしばしば骨抜きの、ありきたりな製品を生み出す。

It was a passing comment and I didn’t really think much of it at the time, but since then I keep going back to that conversation, and the importance of fairness in the product management profession. All the characteristics I just talked about are great, but above all, fairness is the one that a PM simply cannot do without.

これは口をついて出てた言葉で、そのときは深く考えていなかった。しかし私はそのときの会話と、プロダクトマネジメント職においての公平さの重要性に立ち戻り続けている。私が語ってきた全ての特徴は素晴らしい。しかし公平さこそ、PMがこれ抜きには何もできないものだ。

Chapter 2: Uncovering Needs

また製品は以下の3つのニーズを満たさなければならないとして話が進む。

  • User needs
  • Buisiness needs
  • Technical needs

この中でTechinal needsの中には技術的負債なども含まれて居る。PMにとっては技術的負債もマネジメント対象である。

So, user needs research is always the first place to look for how the product can make money.

ユーザーニーズのリサーチは、製品がどのようにお金を生み出すかを探し出す際に、常に出発点となる。

Chapter 6: User-Centered Design And Workflows

三つのA

AARRRみたいなやつ

  • Acquisition 獲得: 新しいユーザーがサインアップした
  • Activation 利用開始: 獲得したユーザーが最初の購入をした
  • Activity 活発さ: 最初に購入したユーザーが戻ってきてさらに活動した

It won’t always be easy, but every UCD project should be measurable in terms of its impact on the business; tying it to one of the three ‘A’s is a good structured way of anchoring all design changes in business goals and, ultimately, revenue.

いつも簡単ではないけれど、すべてのUCD(User Centered Design)プロジェクトはビジネスのインパクトとして計測できるものであるべきだ。三つのAはデザインの変更がビジネスのゴール、つまるところレベニューに結びつけるための構造化された良い手法である。

Chapter 7: Specifications

I always think about error handling as the bastard child of user experience design. No one thinks about it until it’s too late, and then they try to sweep it under the rug.

私は常々エラーハンドリングはユーザー体験デザインの庶子であると考えている。手遅れになるまで誰もエラーについては考えず、そのときには敷物の下に追いやろうとする。

The prototype is often the part of the spec that’s most referenced by developers, since it’s the most useful.

プロトタイプは一番実用的なので、よく開発者から最も参照される仕様のひとつになる。

Chapter 8: Build and Release

個人的にはエンジニアとデザイナーのコミュニケーションにも触れているのが面白かった。

The main issue is that designers and developers approach their respective crafts from very different perspectives. Design is about composition — how to put hundreds of tiny elements together so that the whole makes sense. Development is about deconstruction — how to break down the whole into pieces that can be implemented effectively.

問題は、デザイナーと開発者がそれぞれ違った観点でもの作りにアプローチしているということだ。デザインとは構成すること、つまり数百の小さな要素を集めて理解しやすいように組み立てることである。開発は脱構築すること、つまり効率良く実装できる要素に分解することである。

Chapter 9: Assess and Iterate

Research triangulation — also known as mixed method research — is a helpful methodology to keep in mind here.

混合研究法として知られるリサーチの三角測量は、ここで覚えてくと助けになる手法だ。

という話から、以下の3つの手法をそれぞれ補完的に使うという話が語られる。

A/B testing shouldn’t be used on its own to make decisions — it should always be used in conjunction with other research methods, both qualitative (such as usability testing and ethnography) and quantitative (such as desirability studies).

A/Bテストはそれ自身を決定に使ってはならない。質的(ユーザビリティテストやエスノグラフィーのような)と量的(望ましさの調査のような)両方を含む他のリサーチ手法と組み合わせて使うべきである。

Since every research and testing method comes with its own limitations, a combination of methods is the only way to get the full picture and make the right decisions.

全てのリサーチとテストの手法はそれぞれ限界が伴うので、全体像を把握し、正しい決断を行うためには複数手法を組み合わせて使うことが唯一の道である。

おわりに

最初にも書いたけれど、プロダクトマネージャーの役割が立体的に見えるという意味で良い本だと思う。ぜひ日本語版も出て欲しい。まだ誰も手を付けていないなら翻訳か監訳かやりたいという気持ちがあるのだけど、どういう手順で進めれば良いのかわからない(出版社を通して翻訳権を取得する必要がある?)。どなたかその辺りの知見やツテなどあれば教えて頂けるとありがたいです。

Making It Right: Product Management For A Startup World (English Edition)

Making It Right: Product Management For A Startup World (English Edition)

追記

同僚から指摘をもらって、この本は0→1の事業立ち上げフェーズにフォーカスしている本だと思うようになった。Inspiredはどちらかというと1→100の成長フェーズの話が中心に思える。立ち上げ期と成長期ではプロダクトマネージャーの役割は違った物になりそうである。

正しい製品を作る / 製品を正しく作る

Inspired: 顧客の心を捉える製品の創り方を読み返していて、「第7章: プロダクトマネージャーを管理する」の一節

エンジニアリング部門というのは、基本的に、正しい製品を作ることではなく、製品を正しく作ることに専念することになっているからだ。

というところが引っかかったので、思うところを書いてみる。ちなみに「第5章: プロダクトマネジメントとエンジニアリング(実装)」にも「正しい製品を作るのか、それとも、製品を正しく作るのか」というタイトルの章がある。

エンジニアは製品を正しく作る

エンジニアは製品をリリースする責任があるので、不確定要素を減らして正しいスケジュールでリリースすることにモチベーションがある。このために、開発が進むほどにエンジニアは保守的になっていく。企画段階では和気藹々とブレストしてアイデアを出していても、最後のリリース前にはしぶい顔で実装を拒んだりする。

エンジニアとしてこの動きは自然だと思うし、正しく作られていない製品をリリースすることは結果的にユーザー体験を損なうので、職業上必要な振る舞いでもある(そして製品を「正しく」作るのはとても難しい)。

この場合に「正しい製品」の方を引き受けて開発チームを引っ張るのがプロダクトマネージャの仕事で、「正しく作る」方のエンジニアとバランスを取ることが必要、というのが本書(特に5章)の趣旨である*1

コードを書きながら「正しい製品」を作るには

しかしここで自分が気になるのは、プロダクトマネージャーがエンジニアも兼ねていて、実装もしている場合はどうするのかということだ。というのは今の自分がそういう立場だからなのだけど、所謂プレイングマネージャがこのバランスをどう取るのかということに関心がある。

突然自分語りになるけれど、自分が意識しているのは以下のことである(意識しているだけで、できていると言うつもりはないです…)。

  • コードを書き始めるとバイアスがかかることを認識する
  • コードを書く前の時間を大切にする
  • 客観的な意見を求める

コードを書き始めるとバイアスがかかることを認識する

私がエンジニアとして働き始めたころに学んだ教訓は、客観的な判断は、コードの1行目を書くまでしかできないということだった。その後のすべての決断は感情的になる。

Hard Things 「第3章 直感を信じる」より

自分もコードを書き始めると思考がどんどん保守的な方に向くという経験を何度もしたので、このバイアスをできるだけ把握したいと常々思っている。実装期間には気分転換に散歩に行ったり、ランニングをしたりして冷静に振り返る時間を設けたりしているけど、うまく行っているかはよくわからない。

コードを書く前の時間を大切にする

そういった経緯から、実装に入る前の調査、ブレスト、ユーザーインタビュー、ペーパープロトタイピングといった段階を重視するようになった(要するにデザイン思考的なメソッドを勉強した)。自分は例えプロトタイプでもコードを書いてしまうとバイアスが入ってしまう方なので、コードを書かない助走期間というのをできるだけ確保するようにしている*2

客観的な意見を求める

自分からお願いして、事業責任者と毎週の1 on 1ミーティングを設定して、そこで意見を求めるようにしている。特に自分が今取り組んでいることをペンディングして別のことやるという判断をするときは、大抵1 on 1がきっかけになっている。要するに自分のマネジメントを手伝ってもらっているのだけど、実装に入っている段階ではこの時間が大変ありがたい。

おわりに

自分はエンジニアが「正しい製品」を作ることは可能だと信じているけれど、実装者が両立させるのが難しい仕事であるのは事実だと思う。

プレイングマネージャーに固執しているわけではないけれど、正しい製品を作りたいし、コードを書くのも楽しいし、両方うまいことやりたいという、シンプルな(そしてたぶん欲張りな)欲求を持っている。

追記

ここまで書いてきて何だけど、もちろん実装を通して着想が得られることはよくあると思う。しかしそのときにそれが「正しい製品」のためのものなのかを判断できるのか。今まで書いたコードを捨てる決断を自分でできるのか。そう考え出すと、やはり一度実装を始めると自分でフェーズを巻き戻すのは難しいように思う。

追記2

この文章を社内で見てもらったところ、エンジニアの先輩から同じようなことを感じてきたという意見を頂いた。先輩はプロダクトマネジメントと実装を両方やるときは、日や週を分けて対応するようにしているとのこと。

そうした意見から、このバイアスとの戦いはエンジニアがプロダクトマネージャーになるための成長痛なのかもしれないと思うようになった。バイアスとうまく付き合う方法を見つけた人が、コードを書くプロダクトマネージャーとして残っていくのだろうか。

*1:この後にエンジニアはぜひプロダクトマネージメントに挑戦してみるべきだという主張が続くのでそちらも面白い

*2:ペーパープロトタイピングをよく利用するのはそのため。しかしペーパープロトにも不得意な場面があるので(特にデータが重要な製品)、そういう場合は簡単なWebアプリでプロトタイプを作る

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

プロダクトマネージャーの職能+ユーザー体験設計の本です(と解釈しています)。

最近Rebuild: 98: Superhumans Wanted (Naoya Ito)エンジニアからみた良いプロダクトマネージャとは? - サンフランシスコではたらくソフトウェアエンジニア - Higepon’s blogで話題のプロダクトマネージャーに興味があって、関連しそうな本を読みたいと言っていたら、知人がこの本を紹介してくれました。

Netscapeなどでプログラマーをしていたバックグラウンドを持ち、eBayなど複数の会社でプロダクトマネージャをしていた経験を持つ著者がプロダクトマネージャーの職能について語る本で、以下のような内用が含まれています。

  • プロダクトマネージャーとは何か
  • どうやって他の職種と連携して働くか
  • どうやって製品を見つけ出すか
  • どうやってユーザー体験を作っていくか

自分にとっては、ユーザー体験をデザインするのはプロダクトマネージャーの責任であるというのを明確に定義しているところが読んで一番良かったところでした。そのためにインタラクションデザイナーと二人三脚でプロトタイプを作ったり、ユーザーテストを実施したりと様々な手法が紹介され、プロダクトマネージャーはそれを牽引する役割であると書かれています。今まで自分が興味を持っていたゴールダイレクテッドデザインやデザイン思考というのは、プロダクトマネージャの仕事だったようです。

以下、線を引いた部分の引用です。

ダメな製品が無駄に世に送り出されるいちばんの原因は、ほとんどの場合、会社の中でプロダクトマネージャーの役割が明確にされていないことと、プロダクトマネージャーとなる人に対する教育が不十分なことにある。

覚えておいてほしい。価値のある、使いやすい、実現可能な製品として作られるべき何かをプロダクトマネージャーから与えられなければ、どんなにエンジニアリング部門が優秀でも意味はない、ということを。

身につまされる…。

長い時間をかけて 1つの領域に精通してしまうと、プロダクトマネジメントのもう 1つのワナに落ちてしまうことがある。それは、自分がターゲットである顧客を代弁する人間で、実際以上に自分がターゲットである顧客に近い存在だと思い込むようになるのだ。

ユーザー目線と自分目線を混同しないようにするのは、自分で使いながら作っていると難しいことが多いです(何度もはまった罠)。

デザイナーというのは、製品開発のうんと早い段階、つまり、プロダクトマネージャーがターゲットとなる市場を把握してソリューションを考えている段階から参加してこそ、その真価を発揮できるのだ。

これはデザイナーではない自分もよく思うことです。最初からデザイナーが関わってくれないと心細い…。しかしデザイナーがプロダクトマネージャーの場合は一人で良いのだろうか。

世界で闘うプロダクトマネジャーになるための本 トップIT企業のPMとして就職する方法【委託】 - 達人出版会を読み終えたところだったので、プロダクトマネージャーの理解が深まって良い本でした*1

余談ですが、英語版は2008年の出版で、翻訳は2015年、しかもなぜかKindle版のみ(そして1200円!)という謎の本です。おそらく訳者の方々がどうしても出したかったとか、思い入れが強い本なのではないかと想像しています。

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

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

8/3追記

どうも最初は2012年にiOSアプリとして出ていたようです。最近になってKindle化されたんですね。

Inspired 日本語版 発売! | Inspired日本語版

8/3追記

8/3追記

弊社Fablicの社長 @shota もおすすめとのことです。社内チャットから転載。

ninjinkunがレビュー上げてた下記の本、自分も前に読んだんですが、非エンジニアにとってはまず用語の理解、 プロダクトマネージャー(PO)、プロジェクトマネージャー(PM)の違いなど、開発する側と対等に話すための前提知識が 詰まってたので、僕もおすすめです。 特に非エンジニア職の方。

12/1追記

弊社の人事も最近読んだようで、「開発のことが理解できて良かった」とのことです。確かに人事の人にもおすすめかもです。

*1:他にも、このInspiredを薦めてくれた知人が紹介してくれた、HARD THINGS 答えがない難問と困難にきみはどう立ち向かうか の「良い製品マネジャー、悪い製品マネジャー」という章も良かったです