サクサク読めて、アプリ限定の機能も多数！
トップへ戻る
ブラックフライデー
note.com/suthio
「Slackで何を言いたいのかわからない」「ドキュメントを書くのに異常に時間がかかる」 こういった人は組織に一人はいないだろうか。 マネージャーとして「言語化能力を鍛えてほしい」と思うことは多いとは思います。また、LLMを利用して業務を行う際には言語化能力が非常に重要となると考えております。 ですが、正直なところ、できていない人に対して、トレーニングでなんとかなるのか疑問に感じることもあるのではないでしょうか。 僕は23歳の頃、会社の先輩に「お前、何言ってるかわからないから話すのやめるわ」と言われたことがあります。かなりショックだったのですが、それ以来、「どう伝えればわかってもらえるか」を強く意識するようになりました。 その結果、今では言語化能力が高いと言われることもあります。（このようなnoteを書いていると言語化してもらうの助かるとも言われます。） このような経験から言語化能力は天性の
AIでコードを書く人も増えた。 AIでブログを書く人も増えた。 AIで画像を生成してSNSに上げる人も増えた。 AIにより、アウトプットを手軽にできるようになった一方、下記記事に記載があるようにクオリティの低下も見られるようになっています。 業務でコードレビューをしていても、明らかにAIが書いていて、不自然な実装になっているのにも関わらず、レビュー依頼をしてくるケースも若干ですが、観測しております。 LLM登場以前よりもそれっぽいアウトプットになっているので確認するコストも高くて困りがちです。 このnoteで僕が言いたいことはAIを使って出したものも、あなたのアウトプットということです。 AIを使ってなくても使ったとしてもアウトプットの質が高ければ評価されるし、質が低ければ評価されない。 下記のQiitaもAIを一切使ってないかもしれないし、AIを使ったかもしれないけど内容を見て評価を受け
プロジェクトがうまくいかない原因の多くは、技術的な問題ではなくて、 プロジェクトの進行管理ができていないことだと思ってます。 もう少し具体的にすると、「どこで想定外のことが発生しそうか？」ということを事前に予測できているかどうかが、プロジェクトの成否を分けます。 飲み会の幹事を任せてみると、その人のプロジェクトマネジメント能力がよくわかるなと思って、書いてみます。 「飲み会やります」と言うのは簡単です。でも実際にやるとなると、こんな工程があります。 これを見て「大したことないでしょ」と思う人と、「いろいろ考えることあるな」と思う人がいますが、前者は幹事をやったことがないか、よほど素晴らしい環境でしか幹事をやったことないのではないかと思う。 飲み会で起きるトラブルを想像できるか飲み会の幹事をやったことがある人なら、こんなトラブルを経験したことがあると思う。 日程調整のトラブル候補日を出したの
ソフトウェア開発の見積もりというのはそもそも難しい。 要件の曖昧さ、技術的な不確実性、メンバーのスキル差。様々な要因で、見積もりは常に外れやすかった。 過去の類似機能を参考にしたり、経験を積んでも、「だいたいこのぐらいだろう」という予測は完全に当てれるわけでもない。 それでも、従来は少なくとも「どういう要因で外れるか」はある程度予測できていました。技術的な難しさ、要件の曖昧さ、既存システムとの絡みなどの変数は、経験によって少しずつ読めるようになってきました。 ところが、Claude CodeやCodexのようなコーディングエージェントを使い始めてから、状況が一変しています。 ある日、既存のパターンに沿った画面の追加が「これは5日ぐらいで終わるだろうな」と思ったのですがClaude Codeに渡したら数時間で、ある程度のものが出来上がってきて、そこから調整などを加えたら合計2日ぐらいで機能が
「言ったのに伝わってなかった」という経験は誰にでもあると思います。 ミーティングで説明した。Slackでも伝えた。ドキュメントにも書いた。それでもメンバーが理解していなかったり、優先順位を間違えていたりすることは多くの方が経験されているのではないでしょうか。 「なぜ伝わらないんだろう」と思うかもしれないのですが、伝える側が工夫することで伝わりやすくすることはできると僕は考えています。 本記事では、伝える側を「発信者」、伝えられる側を「受信者」として表現します。 伝わらない理由人は一度では覚えられないいくら大事なことでもポロッと1度言われただけで覚えられるはずがない。ミーティングで聞いた話、Slackで流れてきたメッセージ、ドキュメントに書かれた方針。全てを同じ重要度で記憶することはできません。 毎日、様々な情報が飛び交う中で一言一句、全てを覚えることは不可能です。 なのにもかかわらず、発信
与えられた報酬分だけ仕事をするという考え方もあります。 でも、期待値をちゃんと超えるということをやることで信用に繋がったり、未来の仕事に繋がったりしていることを実感しています。 なので、毎回期待値を越えようとすることは自分のために非常に大事だと思う。 また、依頼者側の視点としては、なにかを依頼した際に相手が期待値を越えようとしてくれてるだけでも嬉しいものです。 なぜ期待値を超えるべきなのか僕の経験では、期待値を超える仕事を継続的にやっていると、明らかに機会が増えます。 新しいプロジェクトに声をかけられる頻度が上がったり、より重要な判断を任されるようになったり、重要なポジションに抜擢されたりする。 これは単純に「いい人だから」ではなく、「この人に任せれば想定以上の成果が期待できる」という信用を積み重ねた結果です。 実際に、僕が過去に関わったプロジェクトで期待値を超える成果を出した結果、次のフ
エンジニアとしてプロダクトデザイナーと関わることがよくありました。 そんな中、エンジニアとして一番困るのは、デザインが"ポン"と出されるだけの状態です。 "ポン"と出されるのはよく遭遇します。デザイナーから「このデザインで実装してください」とFigmaが共有される。見た目は綺麗だし、UIの細部まで丁寧に作り込まれている。でも、配置や構成が「ユーザー体験上クリティカルなのか、ただ雰囲気で置かれたのか」が分からない。 エンジニアとしては「ここは手間に応じて調整していいのか、それとも厳密に守るべきなのか」判断に毎回迷う。デザイナーに相談すると「あ、それは気づかなかった。調整してもらって大丈夫です」という回答が返ってくる。 別の機会で勝手に調整した場合は「デザイン通りにやってもらいたいです」と言われる場合もある。 こういったことが積み重なると、エンジニアは実装時に「ここは厳密に守るべきか、調整して
あえて、「このアプローチはAとB、どっちのアプローチにしましょうか」と選択肢を提示することがあります。 僕の中では「この方法しかないよな…」と思っていても、あえて複数案を出して説明することにしています。 今回は知っていると便利なハック的なものを紹介します。 なぜ一択にしないのか例えば、新しいサービスの技術選定で「TypeScriptを使うか、JavaScriptのままでいくか」という議論があったとする。僕の中では明らかにTypeScriptを選ぶべきだと確信しているのですが 相談されたときは必ず下記のように答えます。 「TypeScriptとJavaScriptの2つの選択肢がありますね。それぞれのメリット・デメリットを整理してみましょう」 そして両方の特徴を丁寧に説明する。TypeScriptは型安全性があってエラーも気づきやすい。開発してて明らかに恩恵は大きいです。一方でJavaScr
個人としては合理的な判断が組織として見た場合に非合理な判断となり、事業を圧迫する結果になるという話を書きます。 質問箱にて元々『「月間2.5億PVの時点でサーバー費用は月15万円+メール送信費用で月15万円で計30万円」だったのに 引き継いだら、インフラだけで毎月50万円近い赤字となっていた』という話は 僕にも似たような相談を受けることが多く どうしてこういったことが起こってしまうのか書こうと思い、筆を取っております。 皆様には混乱をお招きしましたこと謹んでお詫び申し上げます。 現状、インフラ費用だけで毎月50万円近い赤字が出ている状況ですので、まずはインフラの最適化や非効率なコードの見直しを早急に行う必要がある状況です。 （その状態でもなんとか運営を続けられていた元会社さんを尊敬です） (2/3) — 【公式】Peing-質問箱- (@Peing_net) August 23, 2025
最近、キャリア初期（20代）の方から「ワークライフバランスを意識したい」「フルリモートで働きたい」「残業の少ない会社で働きたい」という相談をよく受けます。 確かに気持ちはわかります。プライベートの時間も大切にしたいし、柔軟な働き方ができればそれに越したことはありません。 結論から言うと、僕としてはオススメできません。 もちろん、ワークライフバランスを取ること自体は自由です。ただ、20代で時間を投資して能力を高めることが、30代以降の経済的自由や本当の意味でのワークライフバランスにつながると思っています。 ワークライフバランスを意識してプライベートの時間を充実させる働き方は、中長期にはプライベートを充実させる結果になりません。 ただし、これから話す内容には重要な前提があります。まずそこから書いていきます。 最も重要な前提： 健康が第一この記事を読む前に、絶対に理解してほしいことがあります。
プロダクト開発をしている際に 「この機能の優先度はどうしますか？」 「高でお願いします」 「じゃあ、これも高で」 「こっちも重要なので高で」 気がつけば優先度「高」のタスクだらけになっていることってよくありませんか？ 僕は優先度という言葉は明確に避けていて、 優先順位という言葉を使うようにしています。 優先度と優先順位の決定的な違い優先度、優先順位の違い優先度は「高・中・低」のようなカテゴリ分けです。一方、優先順位は「1位、2位、3位」という明確な順番を示します。 僕の経験では、優先度で管理すると必ず問題が起きます。なぜなら、複数のタスクが同じ優先度になることを許してしまうからです。 優先度「高」が10個あったとき、どれから手をつければいいのか。結局そこでまた議論が必要になります。 なぜ優先順位が重要なのか開発リソースは有限です。同時に全てをやることはできません。 優先順位をつけるというこ
ここ1年~2年でエンジニアやプロダクトマネージャーにおける仕事の進め方、考え方が大きく変わったように思います。 そんな中、「プロダクトマネージャーはエンジニアリングをどこまで理解すべきか？」という相談を受ける機会が増えてきました。 このnoteでは「AI時代のプロダクトマネージャーはエンジニアリングについてどこまで理解しておくと良いか？」を僕自身の主観で書いていきます。 結論僕の答えは「コードは書けなくても良いが、AIがどこまでやれるか試すことができたり、サービスの運用やコードベースを理解した上でエンジニアが詰まるポイントは理解すべき」です。 プロダクトマネージャーとは利益（ユーザー価値 x 事業性）と投資コスト（開発・運用コスト） を考慮した上でプロダクトに関する意思決定をしていくことがプロダクト価値を最大化するために必要だと考えています。 その上で、投資コストの解像度が低い状態での意思
リモートワークは通勤時間もないし、集中した時間を確保できるので個人としてはとても良いと思っています。 ただし、マネージャーや同僚から「ちゃんと働いてるのかな？」と疑われる可能性は常にあるという話を書きます。 「疑われている」と書くと信用されていないのでは？ と思っていまいますが、受け入れるべき前提だと僕は思っています。 オフィスなら椅子に座ってるだけで「働いてる感」が伝わる。でもリモートでは、見えない。 だからこそ「見えること」を意識して作らないと信頼関係は簡単に崩れてしまいます。 リモートワークは、意図的に見える情報を作ることが重要なんです。 見えないことの不安Slackの返事が数時間ないだけで「作業中」から「サボってる？」に変わる。Pull Requestにコメントがついても翌日まで無反応だと「気づいてないのか、無視してるのか」と思われる。 人は見えないとき、悪い方のシナリオを想像しや
「どんな機能が欲しいですか？」 この質問、プロダクト開発をしているとプロダクトマネージャーやエンジニアが聞いているのを良く耳にします。 お客さんに質問してしまっているケースもよく見ます。でも僕は、この質問は意味はなく、無駄だと考えています。 なぜ「欲しい機能」を聞くのが悪手なのか聞かれたら何か答えなきゃいけない心理ユーザーインタビューで「欲しい機能ありますか？」と聞かれたら、ユーザーは何か答えなきゃいけないと思ってしまいます。 実際、僕も他社のサービスについてインタビューを受けた時、同じ経験をしたことがあります。特に困ってないけど、聞かれたから「あったら便利かも」程度のことを答えてしまう。でも、それにお金を払うかと言われたら、絶対に払いません。 この「聞かれたから答える」という機能要望は、本当のニーズとは全く違うものです。 ユーザーは自分が欲しいものを知らない「もし顧客に望むものを聞いてい
「優秀なエンジニアを採用したい」という相談をよく受けます。 「技術的負債を解消していった方が採用力はあがりますよ」という話をするのですが技術的負債が採用に与える影響について、僕が考えていることを書きます。 エンジニアは何を求めて会社に入るのか優秀なエンジニアほど「事業に貢献したい」という想いを持って会社を選びます。 エンジニアは単に技術を使いたいわけではなくて、自分の技術力を使って、事業を成長させたいと思っています。 価値を生み出し、自分自身も成長したいと思っています。 技術的負債は「成長の阻害要因」である技術的負債があるということは、開発速度が著しく低下している状態を意味します。 新機能を1つ追加するのに、本来なら1週間で済むところが1ヶ月かかる。バグ修正に追われて、新しい価値提供ができない。 技術的負債によって、事業の成長速度そのものが低下しているのです。 「伸びない会社」に入りたい人
エンジニアリングのバックグラウンドを持っていない経営者に向けて書いています。 そのため、正確性や網羅性が乏しい箇所がありますのでご容赦いただけると幸いです。 はじめに前提としては僕は技術的負債があること自体を悪いとは思っていないです。 企業経営において、借金は必ずしも悪ではないように適切に管理された負債は、成長のためのレバレッジとなります。スタートアップが資金調達をするのも、大企業が社債を発行するのも、将来の成長のために今、資金を使うという判断となります。 技術的負債も同じで市場投入を優先して「とりあえず動く」実装を選ぶことは、ビジネス的には正しい判断であることが多い。 問題は、その負債を「管理していない」ことにあります。金利を把握せず、返済計画もなく、ただ借金を積み上げていくから破綻するのです。 重要なのは、技術的負債を「ゼロにする」ことではなくて、 「適切に管理する」こと。 経営者の方
この記事のターゲット快適な開発環境のメリットを知らない経営者やエンジニアの方々に向けて書いています。 この記事の目的Claude CodeなどのAIを活用したコーディングエージェントを最大限活用するには、まず「快適な開発環境」という土台が必要です。その重要性と構築方法をお伝えします。 この記事を書いた背景最近、いろいろな会社のプロダクトの状況を見る機会が増えています。 とりあえず一旦見てほしいみたいなものや技術顧問、アドバイザー的な立場で関わることもあるのですが「非常にもったいないな」と思うことが多いです。 色々な会社を見ていると、 テストが書かれている、CIが回っている、デプロイが自動化されている みたいなプロダクトは実は少数派で テストはない。CIが常に壊れている。デプロイは手動でやっている みたいなプロダクトが多いことにびっくりしてる — すてぃお (@suthio_) August
プロダクト開発をしていると、ユーザーや社内から改善要望をもらうことがよくある。でも、その要望の多くが「How」しか書かれていなくて、本当に必要な「Why」が書かれていない。 例えば、よくあるものだと 「ユーザー一覧をCSVでダウンロードできるようにしてほしい」 「検索結果を50件ずつ表示してほしい」 「削除ボタンを赤色にしてほしい」 といったものだったりします。 社内の人には「HowはあってもなくてもいいのでWhyを書いてください」と言っているんだけど、実際にWhyが書かれているケースは少ない。 テンプレートみたいなものを用意してもひどいケースだと「◯◯機能がほしいので◯◯機能を作ってください」みたいなことが書かれている。 どうしてWhyが重要かというと、"最適な解決策を見つけつつ、将来の拡張性も考慮した設計にしたい"からです。 このnoteではなぜ、要望にはWhyが重要でHowが重要では
最近、Claude Codeを使っている人から「レビューが追いつかない」という相談をよく受ける。これは偶然ではなく、必然的に起きる現象だと考えています。 このnoteでは どうしてClaude Codeによる生産性向上の限界が訪れるのか どうすれば、全体の生産性が向上するのか Claude Codeを利用した場合にレビュープロセスでのボトルネックをどのように解消させていくか の3つを書いていきます。 プロダクト開発の典型的なワークフローまず、多くのチームで採用されている機能追加のワークフローを整理してみる。 ※あくまで一般例なので、チームにより変更があると考えています 機能追加のワークフローこの流れ自体は理にかなっていると思っています。 問題は各プロセスの処理速度のバランスです。 ボトルネック理論で考える開発プロセス生産管理の世界には「制約理論（TOC: Theory of Constra
スタートアップのCTOをやった中で機能削除を積極的に行ったことはすごくメリットが大きくて、他もどうしてやらないんだろうという思うのですが やれていないという人たちがすごく多そうなので書いています。 CTOを6年ぐらいやったんだけどCTOとしてとても意識して取り組んだことは"機能削除をちゃんとやる"ということだったと思う。 機能削除ってどうしてもエンジニアからは言いづらいし、他からもあまり意識されないけど地味に機能があるだけでコストがかかり続けるので 経営上の意思決定として削除してた — すてぃお (@suthio_) July 15, 2025 なぜ機能削除ができないか僕の経験では、機能削除ができない理由は下記の3つある 1つ目は「機能の多さ＝価値」という誤解。特に新規セールスの場面で「うちのプロダクトは◯◯も△△もできます」とアピールしやすい。 2つ目は既存ユーザーへの配慮。月に10人し
直近に何度か、「社内にエンジニアがいないので受託で新規プロダクトを作っていこうと思うんですけど、どう思いますか？」という相談を何度か受けたので書いてみる。 僕の回答は「ビジネスの難易度を圧倒的に上げる意思決定なのでやめたほうがいい」です。 なぜ受託開発でプロダクト開発は難しいのか僕も過去に何度か受託開発の現場を見てきたし、実際に関わったこともある。その経験から言えるのは、受託開発と自社でのプロダクト開発は根本的に異なるということ。 受託開発にて受託側は納品したらゴールだが、発注側にとってはそこからがスタートになる。 この違いは想像以上に大きい。 インセンティブの問題まず、受託開発会社は契約通りの機能を作ることにフォーカスする。それ以上でもそれ以下でもない。ユーザーフィードバックを受けて素早く改善したいと思っても、それは「追加開発」として別途見積もりが必要になる。 受託開発のエンジニアにとっ
経営者から「AIを使った開発をうちの開発チームにもやってほしいんだけどうまく活用できていないようなので、うまく活用できるようにしたい」と相談を受けます。 僕も下記のような記事を書いているのですが、そもそも使い倒すためには前提条件があるので説明するためにこのnoteを書いています。 （ついでにエンジニアがこの記事を使って経営層に説明しやすくなると良いなと思ってます） 前提 エンジニアとしても生産性の向上するような施策はぜひやりたいと思っていて、Claude Codeなどのコーディングエージェントも活用してうまくやれるなら活用したいと思っている（はず。今回は現場のエンジニアも活用したいと思っている前提で進めます） エンジニアとしては活用したいが活用できないというジレンマが存在しています。 今回、掲載する画像は下記のような簡易的なツールから生成しているので 経営層に説明する際にエンジニアの皆様は
この度、2025年6月30日付けでidentify株式会社の取締役CTOを退任することになりました。2019年7月からなので丸6年の期間、CTOを務めました。 6年間の振り返り僕がidentifyに入った2019年7月はショート動画という言葉もまだ認知度が低く、TikTokが日本でも使われ始めてなかった時代です。 ショート動画という言葉すら知らなかったのですが「縦型の動画素材が市場で不足する未来が必ず来る」と代表の鬼山が言っていて「可能性はかなり高いし、そこまで遠くないだろうな…」と思ってたので僕も一緒に取り組むことにしたのでした。 結果として今では、ショート動画市場でかなりのシェアを獲得するまでに成長しました。特に最近のプレスリリースにもあるように、事業は順調に拡大しています。 ここまで成長したことは、本当に感慨深いものがあります。 CTOとして学んだことこの6年間で最も強く実感したのは
僕は食べ放題だとついつい食べ過ぎちゃうし、Netflixなども見放題だと永遠と見ちゃいます。 なんだか◯◯放題って使わないと損って思っちゃう派です。 Claude MAXも同様で、定額課金（しかも20xだと月200ドル）だと使わないと損って思ってしまいます。 使い倒した結果がこちらです Claude Codeを使い倒したいときに下記2つの問題があります。 Claude Codeに渡すタスクを作るのが大変でなかなかClaude Codeに渡せない Claude Codeが実装してくれた内容をレビューするのが遅れて、次のタスクが渡せない つまり、下記のような作業フローになっており、自分自身がボトルネックになってしまうのです。 これでは本当はもっとClaude Codeを使い倒したいのに使い倒せないのです。 できれば常にClaude Codeを立ち上げてなにかをやらせておきたいところです。 なの
Claude Codeが変えた開発の風景Claude Codeを使い始めて約1ヶ月経ちますが「Claude Codeを使ってから、開発の概念が根本的に変わった」と僕は思ってる。 ClineやCursor Agentの登場でもでも相当変わったと思う。でもClaude Codeはそれ以上の変化だと僕は感じている。何が根本的に違うのか。 自走力の高いClaude Code - ファイルを読み、修正し、テストを実行し、エラーを解決する。まるでペアプロしているような体験。 コードを書く能力が高いClaude 4 Opus - 複雑なロジックも正確に実装できる圧倒的なコード生成能力。 Claude MAXでの定額化 - API料金を気にせず使い倒せる。この「料金を気にしなくていい」という心理的な解放が、開発のアプローチを根本から変える。 従量課金のメンタルモデルから定額使い放題のメンタルモデルへという
エンジニアとして活動してきて、技術にコミットするエンジニアもいいのだけど事業成長にコミットすることで自分の価値を最大化できると思って僕は働いています。 20代の頃はOSSコミッターとか著名なエンジニアになりたいなと思ってたけど結局はなれませんでした。僕に才能ややる気がなかったのかそれ以外かもしれないですが理由はわかってません。 でも技術にコミットする中で技術力があってもあまり価値が出せないケースが多々あることを知ることができました。例えば現在だれも使っていないOSSをメンテナンスできたとしても価値を出せず、稼げることもありません。 それよりも◯◯というアプリを作ったエンジニアとか10億の売上を作るプロダクトエンジニアだと、他の人から見た際に価値がわかりやすいです。 技術にコミットするエンジニアもいいと思いつつも事業成長にコミットするエンジニアもいいぞという話です。 技術と事業成長の関係性テ
はじめに2024年、AIの進化は目覚ましく、特にソフトウェア開発の分野では革命的な変化が起きていると考えています。 CursorやClineも皆が注目している技術だと考えていますが僕個人として注目しているのが自律型AIソフトウェアエンジニア「Devin」です。 人間や機械からの指示に基づいて計画から実装、デバッグ、デプロイまでできるのが魅力的です。 しかしあんまり運用する際の知見がインターネットやX（twitter）上に落ちていないので僕がしっかり書いておこうと思った次第です。 「Devinは使えない」と言っている人も居ますが、僕は「Devinは運用に使える」と非常に思っているので運用に使うための知識を書いていこうと思います。 ではここからが本編です Devinの得意なこと・苦手なことを理解するDevinの基本的な位置づけDevinを効果的に活用するための最も重要なポイントは、Devinを
概要ClineやCursor、Devinによってソフトウェア開発のやり方が変わっていくと確信をしています。基本は下記の記事に書いてある通りなのですが、僕はClineだけに限った話ではなく、Cursor、Devinでも実現できるし、将来的には似たようなソリューションや更に優れたものがたくさん生み出されると考えています。 将来的にはAIを使って、特定のタスクにおいて、10倍やそれ以上早くなるというのは全然ありえて、 また、従来のソフトウェア開発は将来、「昔は人間の力だけでプログラミングしてたんだよ」と笑い話として話されると思ってます。現代の感覚としては「洗濯板で洗濯をしている」、「薪を焚べて火起こしをしている」に近いです。 AI時代になることでどう変わるのか僕が経験してきたWebベンチャーやスタートアップにおいて、ソフトウェア開発は下記の工程があると考えております。 アイデア・仮説立案: 課題
元々はJebbrains製のIDE（Goland、Webstorm）を利用していたのですがCursorを使い始めて数ヶ月経ちます。 Cusorを使い始める前よりもだいぶ早く実装できるようになったと感じます。 Cursorベストプラクティス ・Claude Sonnet 3.7を使え ・Project Rules（.cursor/rules）を使え ・ビルド、lint、テストなどで高速にフィードバックさせろ ・1セッションあたりで依頼することはできるだけ少なくしろ ・よく使うコマンドやライブラリはチートシート作れ — 今別府すてぃお (@suthio_) March 3, 2025 このプラクティスはCursor Agentに限ったものではなく、ClineやDevinを利用する際に活きてくることが非常に多いです。 Claude Sonnet 3.7を使えClaude Sonnet 3.7で解
次のページ
このページを最初にブックマークしてみませんか？
『すてぃお｜note』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
