サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
掃除・片付け
blog.shibayu36.org
最近以下のような記事や本を読み読書法を変えてみたところ、知識の吸収速度・引き出し速度が上がったと感じるので紹介。 kentarokuribayashi.com 知的戦闘力を高める 独学の技法 作者:山口周ダイヤモンド社Amazon やり方 以下のような流れで読書している。 学びたいと思った知識が書いてありそうな本を2~5冊選ぶ 1冊ずつざっくり読みながら、面白かった部分・気になった部分はKindleで黄色にハイライトしておく 全冊読み終わったら、ハイライトした部分だけ眺めて、やっぱり面白いと思ったところは赤のハイライトを付け直す 赤のハイライトを眺めて、読書ノートに転記する 特に面白い部分については、自分の知見まとめノートにカテゴリごとに整理する 学びたいと思った知識が書いてありそうな本を2~5冊選ぶ 自分の中で学びたいテーマがあって本を読むはずなので、そのテーマについて書いてありそうな本
【2016/03/04追記】以前まとめたこのMVACという名前の設計は既に古くなっており、今はこのようなアーキテクチャで設計していません。 こんにちは。最近ははてなでMVACというアーキテクチャに則って開発をしているのですが、ようやく意味を理解できてきました。そこで今回は「Web Applicationを綺麗に設計するためのMVACという考え方」について、サンプルを交えながら説明していこうと思います。かなり長くなってしまったので、時間があるときにでもどうぞ。 MVACって? データソースやロジックを扱う「Model」、表示・出力を管理する「View」、複数のModelとControllerをつなぐApplication、ユーザのリクエストなどを受け取りViewやApplicationを制御する「Controller」の4つの要素を組み合わせてシステムを実装する方式。MVCをさらに抽象化した
いつもはこのブログでは、技術系の話しかしていないのですが、今回はちょっと変わって、今話題になっている原子力発電所の話を書きたいと思ってます。自分で調べてみると「高速増殖炉もんじゅって危ないな」ってことに気づきました。福島原発も難しいことになっていますが、もんじゅも現在も危険な状態になっています。それについてまとめてみました。 非常に長文になりましたので、時間があるときに読んでいただけるとありがたいです。特に福井県の方には自分たちの県のことなので読んでもらえたらと思います。 前置き まずこの内容について書きたくなった理由です。僕は福井県勝山市の出身で、福井県には多数の原子力発電所があります。これまでは原子力発電所については全く知識がなかったのですが、今回の福島原発での事故をきっかけに、やはり原発はある程度の危険性があるということに改めて気づき、原子力発電所について調べてみることにしました。そ
これまで僕は締切がかなり厳しいプロジェクトを数回経験してきた。その経験から、締切が厳しいという特性を持ったプロジェクトの初期にまずこれだけはやったほうが良いということがいくつか見つかったので、今回はそれらを紹介していこうと思う。 前提となるプロジェクト 今回紹介する方法は、次のような特性を持ったプロジェクトを前提とする。 細かい仕様は決まっていないが、作るものの要件はある程度明確である アジャイルの定義におけるスコープ・コスト・品質・スケジュールの中で、スケジュールを特に優先したい(スケジュールを変えられないなど) 数ヶ月以上のプロジェクトである 短いスパンでリリースしてユーザーの様子を見てその後のプロダクトバックログの優先度を変えるような性質のプロジェクトでは、別のやり方を取る必要があると思う。そこは注意してほしい。 プロジェクト初期にやっておきたいことは何か 上記のようなプロジェクトの
はてなのチーム横断のエンジニアメンター制度 - Hatena Developer Blog で紹介していますが、はてなにはチーム横断のエンジニアメンター制度があります。僕も最近までメンターとして5~6人ほどのメンティーを持っていました(今は事情があってメンターをやっていないのですが)。 メンターとして1on1をする時には1on1ミーティングに備えるアンケート - しるろぐを参考にし、事前にメンティーに面談シートを書いてきてもらうという工夫をしていました。その面談シートは改善を少しずつ加えながら運用していたのですが、一度知見共有も兼ねて最近使っていた面談シートテンプレートを公開してみようと思います。 面談シートテンプレート 以下のようなフォーマットで書いてもらっています。1on1の前にメンティーに1on1用Google Docsに追記していってもらっています。1on1用Google Docs
いろいろあって今の家から引っ越すことになった。 良い物件どうやって探したらいいか分からなかったので、適当にググって http://nanapi.jp/286/ を実践してみたら、結果的にうまく行ったので経験をメモ。 結論 良い物件を探すのではなく、良い不動産屋を探すという方法にしたところ、僕の性格としては上手く行った 今回の流れ suumoやhomesで住みたい場所の物件を眺める 希望条件をまとめる 不動産屋を選んでメールしまくる 良さげなところを数社に絞って、さらに送られた物件見ながら返信してみる 一番いい感じに返答してくれた雰囲気の店に行って相談 suumoやhomesで住みたい場所の物件を眺める http://nanapi.jp/286/ とやってることは一緒なので割愛 希望条件をまとめる http://nanapi.jp/286/ とやってることは一緒なので割愛 不動産屋を選んでメ
最近タスクがどのくらいで終わるか見積もることが多いんだけど、そのたびにうまく見積もりができてなかったり、思ったより長引いてしまってすごく忙しくなってしまったり、といったことが何度かあった。このままじゃ良くないなーと思って、「アジャイルな見積りと計画づくり」を読んだ。 アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~ 作者:Mike Cohn,マイク コーン毎日コミュニケーションズAmazon 実際読んでみると今の状況に非常にぴったりで良い本だった。この本を読んでいくと、最初から正確な見積りをするのは不可能で、作業をしながら見積りの精度をあげるといったり、変更やリスクに強いスケジュールをうまく作るということをしていく必要があるということが分かる。なんとなく自分がタスク管理をしないといけなくなったけど、なんかうまくいかないと思っている人には非常に参考になると思う。あと
最近MySQLの勉強をしていました。実践ハイパフォーマンスMySQLを読むべきという話を聞いていたのですが、かなり網羅的に書かれていて、今の知識ではどれが重要なのかわからない状態でした。そこで色々調べてみて、参考になる記事をいくつか見つけたので、少しまとめてみようと思います。 今回まとめた記事を読んで、大体以下のことが理解できました。 インデックスの使われ方とその構造(MyISAMとInnoDB) EXPLAINの詳しい使い方、見方 InnoDBの特性 ALTER TABLEの特性 レプリ遅延 まず最初に Webエンジニアのための データベース技術[実践]入門 (Software Design plus)posted with amazlet at 12.06.02松信 嘉範 技術評論社 売り上げランキング: 9767 Amazon.co.jp で詳細を見る 松信さんの書いた「Webエンジ
社内ではこういうおすすめをしてますね(文字数多いのでスクショで...) pic.twitter.com/uzqCh6zubs— 柴崎優季 (@shiba_yu36) 2020年7月7日 こういうツイートして、そういえば社内でメンターを初めて経験する人にオススメしている書籍たちを外部に公開してないなと思ったので紹介してみます。 メンタリングのスキルを学習する時のキーワードは「コーチング」と考えていて、以下の書籍を推薦しています。上から順におすすめ順になっています。この推薦は網羅的にコーチングを学べると言うより、初めての人でもとっつきやすく読みやすいものであることを意識して選んでいます。また、メンタリングを始めるだけなら、書籍の全部分を読む必要はなく、どこまで読んでおくと良いかも書いています。 エンジニアリング組織論への招待 ザ・コーチ コーチングの基本 新1分間マネジャー エンジニアリング組
以前 ゴールを決め目標を決める・解決案ではなく質問する - コーチングの学習で学んだこと - $shibayu36->blog; で、「ゴールを決め、現在位置とのギャップを考え、目標を決める」と良いということをまとめた。イメージとしては以下の図の通り。 しかし、前回の記事だと具体的にどのようにエンジニアの目標設定を行うかイメージが湧かない。そこで、もう少し具体的に最近どのようにやっていたかを書いてみたいと思う。 僕がメンティーと目標設定を行うときは、以下のフローを辿っている。 なんでも良いのでゴールのイメージを明確にする 現在の自分とゴールのイメージのギャップを考える ギャップを埋める目標を考え、アクションを定める ちなみに今回は、チームの成果達成のために個人の目標を決めるのではなく、エンジニアのスキル向上の目標を立てるという前提で書いていく。 なんでも良いのでゴールのイメージを明確にする
最近また英語の勉強をしている。僕自身は全く英語の勉強が続いたためしがなくて、毎回はじめてから1~2ヶ月くらいたつと英語の勉強に飽き、挫折してしまう。けれど今回は何とかして続けたいと思って、いつもとは全く違うアプローチで英語の勉強を続けたところ、今のところ6ヶ月くらい英語を続けられている。 今日はどんな感じで英語勉強してきたか軽く書いてみたい。 挫折しないために決めた方針 これまでは毎回英単語を勉強したり、英語の本を読んだり、英語のニュースを聞いてリスニングの勉強をしたり、といういわゆる英語の勉強をやってきた。でもこれだと自分は挫折するということが分かった。 今回は海外の人と友だちになれればモチベーション維持できるのではと考えて 海外の人と友だちになってチャットしたり会話したりを勉強の中心にする チャットや会話を円滑にするための勉強をする という方向性でやってみた。 効果的だったもの 効果的
最近golangでCLIツールを作っていたのだけど、Linuxのお作法とかいまいち分かっていなかった。そこでそのあたりのことが学べそうな「ふつうのLinuxプログラミング」を読んだ。 ふつうのLinuxプログラミング 第2版 Linuxの仕組みから学べるgccプログラミングの王道 作者:青木 峰郎SBクリエイティブAmazon この本はLinuxにおいてC言語でプログラミングする方法を、Linuxでの重要な概念も含めて教えてくれる本。この本を読めばとりあえずC言語を使ってLinux用のプログラムを書き始めることが出来るようになりそうだった。 それでC言語を使わない場合でも役に立つの?ということだけど、非常に役立ちそうで面白かった。なぜなら、単なるプログラミングの方法を教えてくれるだけではなくて、 Linuxの重要な考え方をファイルシステム・プロセス・ストリームという概念にまとめて教えてくれ
Code Completeの上下巻を読んだ。 CODE COMPLETE 第2版 上 完全なプログラミングを目指して 作者:スティーブ マコネル日経BPAmazonCODE COMPLETE 第2版 下 完全なプログラミングを目指して 作者:スティーブ マコネル日経BPAmazon 読んだ感想としては、職業プログラマーなら必ず読むべき本だなと感じた。 この本ではソフトウェアコンストラクションに関する話題を扱っている。この本の中でソフトウェアコンストラクションとは、詳細設計、コーディングやデバッグ、単体テストなどなど、要求定義が終わった後、ソフトウェア製作に必要なプロセス全般のことを指している。 主なテーマとして、どうやってソフトウェアにおける複雑さを減らすことが出来るのか、について書かれている。そのテーマをいろいろな観点から説明されている。例えば以下の様な観点がある。 上流工程の欠陥による
先日、ioドメインの障害があったのだけど、自分がDNSの仕組みをよく分かっていないせいで、いまいちどういうことが起こっていたのか把握できなかった。そこで、DNSの仕組みについて軽く勉強したので、そのメモを残しておく。内容は間違っているかもしれないので、その場合は指摘してください。 DNSについて学んだこと Software Design 2015/4のDNSの教科書が非常に勉強になった。また、 インターネット10分講座:DNSキャッシュ - JPNICも参考になる。 権威サーバとフルリゾルバ まず、DNSサーバには権威サーバとフルリゾルバの二つの種類が存在する。 権威サーバ ドメインの情報を管理し、自分の管理しているゾーンの情報を提供するだけのサーバ 問い合わせたドメインが自分のゾーンの管理下ではない場合、別の権威サーバへ委任するという情報を返す コンテンツサーバとも言われる? 例) co
最近メンタリング制度のことや、技術組織のことについて興味がある。最近「エンジニアリング組織論への招待」という本が出版されて話題になっていたので読んでみた。 エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング 作者:広木 大地技術評論社Amazon この本は、エンジニアリングで重要なのは「どうしたら効率よく不確実性を減らしていけるのか」ということと述べている。その考え方に従って、思考方法、メンタリング、チーム運営、組織運営といったプログラミング以外でのやるべきことについて、様々な背景も含めて教えてくれる。 全部読んでみたところ本当に良い本であった。メンタリングや組織運営といった、なかなか汎用化や言語化がしにくい分野を、納得のできる形で言語化されていて本当にすごい。僕は最近はメンタリング制度について考えているので、特にChapter2のメンタリングの技術の章が一番
最近は読書のやり方を変えてみたら知識の吸収速度・引き出し速度が上がった話 - $shibayu36->blog;に書いているやり方で読書をしている。こういう流れだ。 (1)学びたいと思った知識が書いてありそうな本を2~5冊選ぶ (2)1冊ずつざっくり読みながら、面白かった部分・気になった部分はKindleで黄色にハイライトしておく (3)全冊読み終わったら、ハイライトした部分だけ眺めて、やっぱりおもしろいと思ったところは赤のハイライトを付け直す (4)赤のハイライトを眺めて、読書ノートに転記する (5)とくにおもしろい部分については、自分の知見まとめノートにカテゴリごとに整理する しばらくこれを続けて感じたのは、結局のところ(4)〜(5)に至るまで書籍の内容が全然頭に入っていないということだ。(4)(5)の時に、はじめて「書いている内容が言いたかったのはこういうことだったのか」と頭が急に理
ディレクター時代に仕事でプロジェクトを受け持つ時にどうやったら成功させることが出来るのかについていろいろ考えていた。僕は開発フローをいろいろ考えるのが好きなのだけど、実際に自分がリーダーシップを取ってプロジェクトを進めることを経験すると、そもそもその前に考える・決めるべきことがたくさんあるということが分かったので、ブログに書いておこうと思う。 ここで言うプロジェクトとはサービスを一から作ったり、サービスの一機能を作ったり、受託案件一つだったりを指す。特に開発プロジェクトに限定するものでもない。 プロジェクトを成功に近づけるためには、まずプロジェクトの開始時に、プロジェクトの5W1Hを明確にし、個々のメンバーの責任範囲を決め、それらを一つの場所にまとめておくということをしておくと良いと考えている。 5W1Hを決める すごい基本的なことだけど、プロジェクトをやる上でやはり5W1Hは大事である。
僕は学習をする際には書籍を参考にするのが好きだ。なぜネットとかではなくて書籍を参考にするかというと、書籍のほうが学びたい事柄についてネット情報や人から教わるのと比べて、どちらかというと体系的にまとめられていると思っているためだ。 ただし書籍を参考にしている時によく陥りがちなのが、「学習する」という目的を忘れて、「本を読み切る」という事自体が目的化してしまうことだ。こうならないため、僕はこの書籍を読む目的をはっきり決めるようにしている。その目的が大体3つくらいの種類に分類されてきたので、今回はそれについてまとめてみようと思う。 三つの目的のどれかを選ぶ 僕の中で学習目的で書籍を読むときは以下の三つの目的のどれかに絞っている。 これからの課題を解決する方法を見つけるための読書 これまでうまくいったことの言語化を行うための読書 視野を広げるための読書 この三つのどの目的で本を読むか、自分の中で明
エッセンシャル思考 最少の時間で成果を最大にする 作者:グレッグ・マキューンかんき出版Amazon 自分がなんでもやりたいタイプなので、この本に書いてあることは中々刺さった。幸福になるには「より少なく、しかしより良く」を追求すべきという本。プライベートや仕事でとにかく忙しく時間がないと思っている人は読んでみると良い。 印象に残ったのは次のことだ。 現代人の最優先課題は、優先順位づけの能力をキープすること 睡眠不足では一番最初にそこが減ってしまうのでダメ 一流のバイオリニストは1日平均8.6時間の睡眠 & 週平均2.8時間の昼寝。睡眠による並外れた集中力で、1時間あたりの練習効果を最大限にする もっとも厳しい基準でやることを決める 「絶対やりたい」「やらない」の2択にする。やろうかな程度なら却下、イエスと言うのは絶対やるしかないと確信した時だけ 自分の中で最重要基準をひとつ用意し、100点満
マネジャーをやっていると、1on1でいろいろな困りごとを相談されたり、雰囲気を感じ取ったりで、部下が困っていることがよく見える。その時「頑張ってマネジャーの自分が解決しないと!」と思い、全部自分で解決してしまうことがある。しかしこのようなやり方は正直デメリットが多く、やめたほうが良いと考えている。 これを続けていると、例えば 部下が問題はマネジャーが解決してくれるものと思いすぎてしまう可能性がある。するとこの仕事はマネジャー、この仕事はエンジニアと過度にカテゴリー分けがなされることがある 部下の問題解決能力、相談能力などの向上機会を奪ってしまう 細かい問題を解決しているだけで時間がなくなってしまう 結果的にスケールもせず、解決に取り組めない問題が増えていく 本当に解決すべき重大なチーム課題に取り組む時間がなくなる などといったことが起こりうる。こうなると実際には自分が色々問題を解決できてい
今日会社の開発サーバでhitode君と遊んでて、動いているプロセスを調べていたのでメモ。 動いているプロセスを知りたい 基本的。 ps ax ps auxとかすると、メモリ使用量とかいろいろ見れる。 動いているプロセスの関係も含めて知りたい pstreeコマンドでできる。とりあえずどんな感じに実行されているかサマリーを知りたい時は以下のコマンド。 pstree いろいろ折りたたまれているので、それを展開したい時は-cをつける。 pstree -c コマンドの引数とかも表示したい時は-aつける pstree -ac pidを知りたい時は-pつける pstree -acp 表示してみると{}で囲まれているやつがあるけど、これは多分threadなんだろうと思う。linuxではthreadのidはpidのように管理されているみたい。 メモリやCPUを消費しているプロセスを知る topとかでいろいろ
自分の置かれた環境で問題意識を感じることってありますよね。例えば 上司全然ちゃんとやってくれないじゃん!最悪! 会社にこういう問題あるじゃん!なんで直らないの!最悪! みたいな感じ。 昔はこういう問題意識を持った時、自分で「良い状況に変える」ことに苦労をしていました。しかし、最近は自分の意識を変えることで「効率的に良い状況に変える」ことをしやすくなったなと感じています。そこで今回は、どのように自分が意識を変えたかということと、問題意識を感じた時に最近試しているアクションについて書いてみようと思います。 昔に自分がよくやっていたアクション 問題意識を感じた時、昔に自分がよくやってしまっていたのは 飲み会の場で愚痴る 上司に詰め寄る 問題意識だけを提起する というようなアクションです。このようなアクションをした時、良い上司はちゃんと話を聞いてくれて、実際に問題が解決することも多くありました。
評価制度などの仕組みを考えるにあたり、一度人事関連の教科書を読んで全容を知らないといけないなと思ったので、おすすめされていた「人事管理入門」を読んだ。 マネジメント・テキスト 人事管理入門<第2版> 作者:今野 浩一郎,佐藤 博樹日本経済新聞出版Amazon とにかく面白く、教科書的に体系的にまとめられているのに関わらず分かりやすく、読んで非常に参考になった。この本を読むと、人事とはどういう役割なのか、グレード制度とは何か、人事評価とはどういう目的で行われるのかなど、人事にまつわる知識が体系的に身につけられる。そのため、人事部に所属している人にはとにかくおすすめだし、人事に関わってなくとも組織に興味があるならおすすめ。人事に関わる制度を考えるときには何度も読み返したい本だなと思った。 今の自分だと、「第1章 人事管理のとらえ方」「第2章 戦略・組織と人事管理」「第3章 社員区分制度と社員格
【2016/09/10追記】 勉強しなおして、Elasticsearchの知識についてさらにまとめた記事を書いたので、そちらを参照してもらうと良さそうです。 blog.shibayu36.org 最近Elasticsearchの勉強をした。ただ、入門のためどのような資料が適しているかを知るのが大変だった。そこでどのように勉強したかについてメモをしておく。少しまとめエントリー的なノリになりそう。 Elasticsearchの概念を知る 全文検索技術の基本を知る Elasticsearchのドキュメントのたどり方を知る の順に学習を進めていった。 Elasticsearchの概念を知る Elasticsearchの学習を始めようとした時に、まずは基本からということで以下の本を読んでいた。 高速スケーラブル検索エンジン ElasticSearch Server (アスキー書籍) 作者:Rafal
先日飲み会で技術的負債についての雑談をしていた。結構いろいろな側面の話をしていたのだけど、技術的負債って一括りにしているのが今はあんまり良くなくて、負債の性質によって技術的奨学金、技術的FX、技術的年金などと言葉を変えると良いのではみたいな半分冗談で会話をしていた。 いろんな問題が技術的負債という一言にまとめられてしまっているので、負債の性質に合わせて、技術的奨学金、技術的FX、技術的年金、など用語を分けると良いのではないか、という話をした— 趣味はマリンスポーツです (@hitode909) 2018年3月27日 技術的負債について - hitode909の日記 それで技術的負債のパターンを見つけて、それによりどういう悪影響があるか、それがなぜ起こるのか、どう返却するかについて考えておくと良いのではと思ったので、今日思いついた3つのパターンをメモしておく。 思いついたパターンは3つ。 変
僕は自分がやったこと・勉強したこと・気づいたことなどはどんなにちょっとしたことでも、公開の場のブログに書くようにしている。その内容はある程度雑でも良いので、とにかく公開の場に書くようにしている。それによって、結構良いことが起こっているというのを社内の日記に書いていたのだけど、これも公開の場に書いておいても良いかと思ったので書く。 これまでの経験だと、次のような良いことが起こっている。 最低限未来の自分に理解できる程度まで記事にまとめることで、知識が頭の中で言語化され、定着する 時々他の人からフィードバックを受けて、さらに学習が進むことがある 「あれ昔なんか勉強したけど覚えてないな」という時に自分のブログ見たらすぐ思い出す 分からないことを調べようとググったら自分のブログが出てきてすぐ思い出す 初めからブログに書くつもりでインプットすると、自然と体系化・汎化しながらインプットできるようになる
育児していて時間があまり取れない状況下で継続的に学習するために色々な方法を取り入れているんだけど、その中で最近めちゃくちゃ効いた3つのやり方を紹介。 やりたいことリストを作っておく 今日のTODOリストを作る 2分間コーディング やりたいことリストを作っておく 自分が学習したいことの一覧があると、優先度を決めやすくなり、またやりたいことが1つ終わった後すぐに次に取り組むこともできる。そこで僕はTrelloでリストを作り、とにかく少しでもやってみたいと思った開発や、読みたいと思った本などがあれば追加している。 今日のTODOリストを作る 時間が空いてから「今日はこれから何をやろうかな?」と考えていると、途端にやる気がなくなってダラダラしてしまう。そこで先に今日のTODOリストを作っておくということをやっておく。ポイントとしては 細かい家事やプライベートでやること、勉強すること全て含めて同じリ
最近TypeScriptが好きで勉強していっている。しかしなかなか型定義周りが手に馴染まず、少し複雑な型定義を読んだり、自分でユーティリティ型を定義したりすることが難しかった。 そこで型を手に馴染ませるために色々学習をしてみたので、やっていることをメモしておく。 まずざっとTypeScriptの型概要を学ぶ まずTypeScriptでの型を簡単に学ぶには以下の2つの資料がわかりやすかった。 TypeScriptの型入門 - Qiita TypeScriptの型初級 - Qiita ひたすら型演習をする 資料を読むだけでは全く手に馴染まないと思ったので、その後ひたすら型演習をしている。 まずは TypeScriptの型演習 - Qiita 。これは先程の型初級、型入門の記事を書いた人が演習問題を作っているため同じ流れで学習でき、さらに解説編も充実しているので、手を動かしながら学ぶのに最適であ
id:antipopさんやid:studio3104さんに機会をもらえて、CROSS 2021に参加させてもらい、はてなでのレビューの話を軽くさせてもらった。はてなからは僕とid:hakobe932さんとで参加した。 http://blog.kentarok.org/entry/2014/01/18/204552 2014/1/17 #cross2014 コードレビューCROSS 〜ぶつかり稽古 2014初場所〜 - Togetter それで、今回参加して他の会社の人のレビューの話も聞いて、あーそれはあるあるとか、そういう問題解決するためにこういうことしてますとか、他の会社ではこういう時どうしているんだろとか、幾つかおもうところがあったので、もう少しレビューのことについて書いてみる。 レビューと関係性問題 レビュアーとレビュイーの関係に関して - 職質アンチパターン コードレビューと関係性
次のページ
このページを最初にブックマークしてみませんか?
『$shibayu36->blog;』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く