  |
はてなキーワード: スケジューリングとは
第1章 プログラミング概念入門 1.1 計算器 1.2 変数 1.3 関数 1.4 リスト 1.5 リストについての関数 1.6 プログラムの正しさ 1.7 計算量 1.8 遅延計算 1.9 高階プログラミング 1.10 並列性 1.11 データフロー 1.12 明示的状態 1.13 オブジェクト 1.14 クラス 1.15 非決定性と時間 1.16 原子性 1.17 ここからどこへ行くのか？ 1.18 練習問題 第1部 一般的計算モデル 第2章 宣言的計算モデル 2.1 実用的プログラミング言語の定義 2.1.1 言語の構文 2.1.2 言語の意味 2.2 単一代入格納域 2.2.1 宣言的変数 2.2.2 値格納域 2.2.3 値生成 2.2.4 変数識別子 2.2.5 識別子を使う値生成 2.2.6 部分値 2.2.7 変数の，変数への束縛 2.2.8 データフロー変数 2.3 核言語 2.3.1 構文 2.3.2 値と型 2.3.3 基本型 2.3.4 レコードと手続き 2.3.5 基本操作 2.4 核言語の意味 2.4.1 基本概念 2.4.2 抽象マシン 2.4.3 待機不能な文 2.4.4 待機可能な文 2.4.5 基本概念再訪 2.5 メモリ管理 2.5.1 末尾呼び出し最適化 2.5.2 メモリライフサイクル 2.5.3 ガーベッジコレクション 2.5.4 ガーベッジコレクションは魔術ではない 2.5.5 Mozartのガーベッジコレクタ 2.6 核言語から実用的言語へ 2.6.1 構文上の便宜 2.6.2 関数(fun文) 2.6.3 対話的インターフェース(declare文) 2.7 例外 2.7.1 動機と基本概念 2.7.2 例外を持つ宣言的モデル 2.7.3 親言語の構文 2.7.4 システム例外 2.8 進んだ話題 2.8.1 関数型プログラミング言語 2.8.2 単一化と内含(entailment) 2.8.3 動的型付けと静的型付け 2.9 練習問題 第3章 宣言的プログラミング技法 3.1 宣言的とはどういうことか？ 3.1.1 宣言的プログラムの分類 3.1.2 仕様記述言語 3.1.3 宣言的モデルにおいてコンポーネントを実装すること 3.2 反復計算 3.2.1 一般的図式 3.2.2 数についての反復 3.2.3 局所的手続きを使うこと 3.2.4 一般的図式から制御抽象へ 3.3 再帰計算 3.3.1 スタックの大きさの増加 3.3.2 代入ベースの抽象マシン 3.3.3 再帰計算を反復計算に変換すること 3.4 再帰を用いるプログラミング 3.4.1 型の記法 3.4.2 リストについてのプログラミング 3.4.3 アキュムレータ 3.4.4 差分リスト 3.4.5 キュー 3.4.6 木 3.4.7 木を描画すること 3.4.8 構文解析 3.5 時間効率と空間効率 3.5.1 実行時間 3.5.2 メモリ使用量 3.5.3 償却的計算量 3.5.4 性能についての考察 3.6 高階プログラミング 3.6.1 基本操作 3.6.2 ループ抽象 3.6.3 ループの言語的支援 3.6.4 データ駆動技法 3.6.5 明示的遅延計算 3.6.6 カリー化 3.7 抽象データ型 3.7.1 宣言的スタック 3.7.2 宣言的辞書 3.7.3 単語出現頻度アプリケーション 3.7.4 安全な抽象データ型 3.7.5 安全な型を備えた宣言的モデル 3.7.6 安全な宣言的辞書 3.7.7 資格とセキュリティ 3.8 宣言的でない必要物 3.8.1 ファイルを伴うテキスト入出力 3.8.2 グラフィカルユーザインタフェースを伴うテキスト入出力 3.8.3 ファイルとの状態なしデータI/O 3.9 小規模プログラム設計 3.9.1 設計方法 3.9.2 プログラム設計の例 3.9.3 ソフトウェアコンポーネント 3.9.4 スタンドアロンプログラムの例 3.10 練習問題 第4章 宣言的並列性 4.1 データ駆動並列モデル 4.1.1 基本概念 4.1.2 スレッドの意味 4.1.3 実行列 4.1.4 宣言的並列性とは何か？ 4.2 スレッドプログラミングの基本的技法 4.2.1 スレッドを生成すること 4.2.2 スレッドとブラウザ 4.2.3 スレッドを使うデータフロー計算 4.2.4 スレッドのスケジューリング 4.2.5 協調的並列性と競合的並列性 4.2.6 スレッド操作 4.3 ストリーム 4.3.1 基本的生産者／消費者 4.3.2 変換器とパイプライン 4.3.3 資源を管理し，処理能力を改善すること 4.3.4 ストリームオブジェクト 4.3.5 ディジタル論理のシミュレーション 4.4 宣言的並列モデルを直接使うこと 4.4.1 順序決定並列性 4.4.2 コルーチン 4.4.3 並列的合成 4.5 遅延実行 4.5.1 要求駆動並列モデル 4.5.2 宣言的計算モデル 4.5.3 遅延ストリーム 4.5.4 有界バッファ 4.5.5 ファイルを遅延的に読み込むこと 4.5.6 ハミング問題 4.5.7 遅延リスト操作 4.5.8 永続的キューとアルゴリズム設計 4.5.9 リスト内包表記 4.6 甘いリアルタイムプログラミング 4.6.1 基本操作 4.6.2 ティッキング(ticking) 4.7 Haskell言語 4.7.1 計算モデル 4.7.2 遅延計算 4.7.3 カリー化 4.7.4 多態型 4.7.5 型クラス 4.8 宣言的プログラムの限界と拡張 4.8.1 効率性 4.8.2 モジュラ性 4.8.3 非決定性 4.8.4 現実世界 4.8.5 正しいモデルを選ぶこと 4.8.6 拡張されたモデル 4.8.7 異なるモデルを一緒に使うこと 4.9 進んだ話題 4.9.1 例外を持つ宣言的並列モデル 4.9.2 さらに遅延実行について 4.9.3 通信チャンネルとしてのデータフロー変数 4.9.4 さらに同期について 4.9.5 データフロー変数の有用性 4.10 歴史に関する注記 4.11 練習問題 第5章 メッセージ伝達並列性 5.1 メッセージ伝達並列モデル 5.1.1 ポート 5.1.2 ポートの意味 5.2 ポートオブジェクト 5.2.1 NewPortObject抽象 5.2.2 例 5.2.3 ポートオブジェクトに関する議論 5.3 簡単なメッセージプロトコル 5.3.1 RMI(遠隔メソッド起動) 5.3.2 非同期RMI 5.3.3 コールバックのあるRMI(スレッド使用) 5.3.4 コールバックのあるRMI(継続のためのレコード使用) 5.3.5 コールバックのあるRMI(継続のための手続き使用) 5.3.6 エラー報告 5.3.7 コールバックのある非同期RMI 5.3.8 二重コールバック 5.4 並列性のためのプログラム設計 5.4.1 並列コンポーネントを使うプログラミング 5.4.2 設計方法 5.4.3 並列性パターンとしての機能的構成要素 5.5 リフト制御システム 5.5.1 状態遷移図 5.5.2 実装 5.5.3 リフト制御システムの改良 5.6 メソッド伝達モデルを直接使用すること 5.6.1 1つのスレッドを共有する複数のポートオブジェクト 5.6.2 ポートを使う並列キュー 5.6.3 終点検出を行うスレッド抽象 5.6.4 直列依存関係の除去 5.7 Erlang言語 5.7.1 計算モデル 5.7.2 Erlangプログラミング入門 5.7.3 receive操作 5.8 進んだ話題 5.8.1 非決定性並列モデル 5.9 練習問題 第6章 明示的状態 6.1 状態とは何か？ 6.1.1 暗黙的(宣言的)状態 6.1.2 明示的状態 6.2 状態とシステム構築 6.2.1 システムの性質 6.2.2 コンポーネントベースプログラミング 6.2.3 オブジェクト指向プログラミング 6.3 明示的状態を持つ宣言的モデル 6.3.1 セル 6.3.2 セルの意味 6.3.3 宣言的プログラミングとの関係 6.3.4 共有と同等 6.4 データ抽象 6.4.1 データ抽象を組織する8つの方法 6.4.2 スタックの変種 6.4.3 多態性 6.4.4 引数受け渡し 6.4.5 取り消し可能資格 6.5 状態ありコレクション 6.5.1 インデックス付きコレクション 6.5.2 インデックス付きコレクションを選ぶこと 6.5.3 その他のコレクション 6.6 状態に関する推論 6.6.1 不変表明 6.6.2 例 6.6.3 表明 6.6.4 証明規則 6.6.5 正常終了 6.7 大規模プログラムの設計 6.7.1 設計方法 6.7.2 階層的システム構造 6.7.3 保守性 6.7.4 将来の発展 6.7.5 さらに深く知るために 6.8 ケーススタディ 6.8.1 遷移的閉包 6.8.2 単語出現頻度(状態あり辞書を使用する) 6.8.3 乱数を生成すること 6.8.4 口コミシミュレーション 6.9 進んだ話題 6.9.1 状態ありプログラミングの限界 6.9.2 メモリ管理と外部参照 6.10 練習問題 第7章 オブジェクト指向プログラミング 7.1 継承 7.2 完全なデータ抽象としてのクラス 7.2.1 例 7.2.2 この例の意味 7.2.3 クラスとオブジェクトを定義すること 7.2.4 クラスメンバ 7.2.5 属性を初期化すること 7.2.6 第1級メッセージ 7.2.7 第1級の属性 7.2.8 プログラミング技法 7.3 漸増的データ抽象としてのクラス 7.3.1 継承グラフ 7.3.2 メソッドアクセス制御(静的束縛と動的束縛) 7.3.3 カプセル化制御 7.3.4 転嫁と委任 7.3.5 内省 7.4 継承を使うプログラミング 7.4.1 継承の正しい使い方 7.4.2 型に従って階層を構成すること 7.4.3 汎用クラス 7.4.4 多重継承 7.4.5 多重継承に関するおおざっぱな指針 7.4.6 クラス図の目的 7.4.7 デザインパターン 7.5 他の計算モデルとの関係 7.5.1 オブジェクトベースプログラミングとコンポーネントベースプログラミング 7.5.2 高階プログラミング 7.5.3 関数分解と型分解 7.5.4 すべてをオブジェクトにすべきか？ 7.6 オブジェクトシステムを実装すること 7.6.1 抽象図 7.6.2 クラスを実装すること 7.6.3 オブジェクトの実装 7.6.4 継承の実装 7.7 Java言語(直列部分) 7.7.1 計算モデル 7.7.2 Javaプログラミング入門 7.8 能動的オブジェクト 7.8.1 例 7.8.2 NewActive抽象 7.8.3 フラウィウス・ヨセフスの問題 7.8.4 その他の能動的オブジェクト抽象 7.8.5 能動的オブジェクトを使うイベントマネージャ 7.9 練習問題 第8章 状態共有並列性 8.1 状態共有並列モデル 8.2 並列性を持つプログラミング 8.2.1 さまざまな手法の概観 8.2.2 状態共有並列モデルを直接使うこと 8.2.3 原子的アクションを使うプログラミング 8.2.4 さらに読むべき本 8.3 ロック 8.3.1 状態あり並列データ抽象を構築すること 8.3.2 タプル空間(Linda) 8.3.3 ロックを実装すること 8.4 モニタ 8.4.1 定義 8.4.2 有界バッファ 8.4.3 モニタを使うプログラミング 8.4.4 モニタを実装すること 8.4.5 モニタの別の意味 8.5 トランザクション 8.5.1 並列性制御 8.5.2 簡易トランザクションマネージャ 8.5.3 セルについてのトランザクション 8.5.4 セルについてのトランザクションを実装すること 8.5.5 トランザクションについてさらに 8.6 Java言語(並列部分) 8.6.1 ロック 8.6.2 モニタ 8.7 練習問題 第9章 関係プログラミング 9.1 関係計算モデル 9.1.1 choice文とfail文 9.1.2 探索木 9.1.3 カプセル化された 9.1.4 Solve関数 9.2 別の例 9.2.1 数値例 9.2.2 パズルとnクイーン問題 9.3 論理型プログラミングとの関係 9.3.1 論理と論理型プログラミング 9.3.2 操作的意味と論理的意味 9.3.3 非決定性論理型プログラミング 9.3.4 純粋Prologとの関係 9.3.5 他のモデルにおける論理型プログラミング 9.4 自然言語構文解析 9.4.1 簡単な文法 9.4.2 この文法に従う構文解析 9.4.3 構文木を生成すること 9.4.4 限定記号を生成すること 9.4.5 パーサを走らせること 9.4.6 パーサを「逆向きに(backward)」走らせること 9.4.7 単一化文法 9.5 文法インタプリタ 9.5.1 簡単な文法 9.5.2 文法のコード化 9.5.3 文法インタプリタを走らせること 9.5.4 文法インタプリタを実装すること 9.6 データベース 9.6.1 関係を定義すること 9.6.2 関係を使って計算すること 9.6.3 関係を実装すること 9.7 Prolog言語 9.7.1 計算モデル 9.7.2 Prologプログラミング入門 9.7.3 Prologプログラムを関係プログラムに翻訳すること 9.8 練習問題 第2部 特殊化された計算モデル 第10章 グラフィカルユーザインタフェースプログラミング 10.1 宣言的／手続き的方法 10.2 宣言的／手続き的方法を使うこと 10.2.1 基本的ユーザインタフェースの要素 10.2.2 GUIを構築すること 10.2.3 宣言的座標 10.2.4 リサイズ時の宣言的振る舞い 10.2.5 ウィジェットの動的振る舞い 10.3 対話的学習ツールPrototyper 10.4 ケーススタディ 10.4.1 簡単なプログレスモニタ 10.4.2 簡単なカレンダウィジェット 10.4.3 ユーザインタフェースの動的生成 10.4.4 状況順応時計 10.5 GUIツールを実装すること 10.6 練習問題 第11章 分散プログラミング 11.1 分散システムの分類 11.2 分散モデル 11.3 宣言的データの分散 11.3.1 オープン分散と大域的ネーミング 11.3.2 宣言的データを共有すること 11.3.3 チケット配布 11.3.4 ストリーム通信 11.4 状態の分散 11.4.1 単純状態共有 11.4.2 分散字句的スコープ 11.5 ネットワークアウェアネス 11.6 共通分散プログラミングパターン 11.6.1 静的オブジェクトとモバイルオブジェクト 11.6.2 非同期的オブジェクトとデータフロー 11.6.3 サーバ 11.6.4 クローズド分散 11.7 分散プロトコル 11.7.1 言語実体 11.7.2 モバイル状態プロトコル 11.7.3 分散束縛プロトコル 11.7.4 メモリ管理 11.8 部分的失敗 11.8.1 失敗モデル 11.8.2 失敗処理の簡単な場合 11.8.3 回復可能サーバ 11.8.4 アクティブフォールトトレランス 11.9 セキュリティ 11.10 アプリケーションを構築すること 11.10.1 まずは集中，後に分散 11.10.2 部分的失敗に対処すること 11.10.3 分散コンポーネント 11.11 練習問題 第12章 制約プログラミング 12.1 伝播・探索法 12.1.1 基本的考え方 12.1.2 部分情報を使って計算すること 12.1.3 例 12.1.4 この例を実行すること 12.1.5 まとめ 12.2 プログラミング技法 12.2.1 覆面算 12.2.2 回文積再訪 12.3 制約ベース計算モデル 12.3.1 基本的制約と伝播子 12.3.2 計算空間の探索をプログラムすること 12.4 計算空間を定義し，使うこと 12.4.1 深さ優先探索エンジン 12.4.2 検索エンジンの実行例 12.4.3 計算空間の生成 12.4.4 空間の実行 12.4.5 制約の登録 12.4.6 並列的伝播 12.4.7 分配(探索準備) 12.4.8 空間の状態 12.4.9 空間のクローン 12.4.10 選択肢を先に任せること 12.4.11 空間をマージすること 12.4.12 空間失敗 12.4.13 空間に計算を注入すること 12.5 関係計算モデルを実装すること 12.5.1 choice文 12.5.2 Solve関数 12.6 練習問題 第3部 意味 第13章 言語意味 13.1 一般的計算モデル 13.1.1 格納域 13.1.2 単一代入(制約)格納域 13.1.3 抽象構文 13.1.4 構造的規則 13.1.5 直列実行と並列実行 13.1.6 抽象マシンの意味との比較 13.1.7 変数導入 13.1.8 同等性の強制(tell) 13.1.9 条件文(ask) 13.1.10 名前 13.1.11 手続き抽象 13.1.12 明示的状態 13.1.13 by-need同期 13.1.14 読み出し専用変数 13.1.15 例外処理 13.1.16 失敗値 13.1.17 変数置き換え 13.2 宣言的並列性 13.2.1 部分停止と全体停止 13.2.2 論理的同値 13.2.3 宣言的並列性の形式的定義 13.2.4 合流性 13.3 8つの計算モデル 13.4 よくある抽象の意味 13.5 歴史に関する注記 13.6 練習問題
木曜の時点で月曜に結合テストしてくださいってお願いしてたのに、朝から始まる予定が始まったのが夕方。
で、ダラダラなかなか終わらず１８時過ぎ。
その時点でこっちは出向で１８時以降残りたくないのに、その日中に結合テストが無事終わるのを確認する必要があったんで待たされる。
で、ようやく始まったかと思ったら、別の不具合見つけて「確認して～」指摘してきて、結合テストを放置。
この時点で優先度考えてないバカっぷりにイライラ。今日中にテスト終わらす気あるん？こっちは待っとるんやぞ？終わるの。
で、調べたけどデータがおかしいし、再現性ないし、しょーもない現象見つけますね。
「それは今関係ないんでテスト進めてください」って言ったら「なんで逃げるん？」って。
そっちの問題は今優先度高くないやろがっ！問題が見つかるたびにテスト中断しとったら今日中におわらんやろがっ！考えろや！
で、まだテストは終わらず、別の作業して待ってたら話かけてきたから「早く結合終わるのを待ってます」って言ったら「でもやることあるやろ？」って。
あほか。やることあったらなんぼでも残業させるんか。残業代でない社員ならまだしもこっちは出向やぞ、金銭感覚無いんか？
んで、ようやく終わりそうってことで「iphone対応した？こんなひねくれた見方すんなって？（笑）」って。
あきれるわ。
ひねくれたもなにも、それが仕様なんやろが！ひねくれもくそもあるかぁっ！
そうゆう漏れがないか確認するために、テストやろうが！！というかそもそも、設計レビューもしてテスト仕様書も確認してって言うて漏れとるやんけボケがぁ！さっさと指摘せんかいや！２２時過ぎて「今から修正できる？」とかふざけんなボケが。
スケジューリングできない
金銭感覚が無い
リスクヘッジができない
イライラさせる
そら下が続かんわ。
原文： http://sites.google.com/site/ytpartnercommunications/Announcements/youtubelive
パートナーのみなさん。
すでに最近のブログのポストをお読みになられたかもしれませんが、本日私たちは自前で運営するライブストリーミングのプラットフォームのベータバージョンを、アカウントの状態が良好（著作権に違反していない）なパートナーに段階的に公開を始めました。このベータ版を使えばパートナーの方はご自身のチャンネルから好きなときにいつでも生配信をはじめたり、あるいは事前にスケジューリングすることで購読者に放送の開始をお知らせすることができます。生配信視聴の素晴らしい体験を保証するために、この機能の提供は少しづつ進めていくつもりです。もしあなたのアカウントが生配信が可能になったならば、あなたがログインしチャンネルページをみたときに、その旨が表示されます。
多くのパートナーがYoutube上での生配信に興奮していることでしょう。もし、あなたのアカウントがまだ有効になってないのなら、あなたの熱意は心から歓迎するところですが、どうか辛抱なさってくださいませ。アカウントを生配信が可能にするためにリクエスト出せるような仕組みはありません。ただ、あなたのアカウントの状態を良好に保ち、Youtubeコミュニティーガイドラインをリスペクトするアクティブな動画投稿者で居続けてください。我々は、２０１１年のあいだ中、可能な限り多くのパートナーに対してこの機能を有効にするよう努力を続けています。
皆様の熱意と忍耐とご理解予め感謝を述べさせていただきます。もしあなたが有効化されたパートナーで何かこの製品に質問がございましたら、どうぞ、ヘルプセンターかライブストリーミングフォーラムを訪れてください。
最期にホント、わがまま言っていいのなら学校には以下のことをお願いしたいです。
http://anond.hatelabo.jp/20101023073241の続き。
3年生は本当に弱点だらけです、社会に出て行ってちゃんとできるという保証は私取れません。
だから、メンタルヘルスマネジメント（III種)と秘書検定ぐらいは必須にして良いのではないかと思います。
クラスメートと言う視点で見て残念ながら就職・進学どちらにも脆弱性が見えますから。
7・5・3現象と言うのが有ります。これは中卒で7割、高卒で5割、大卒で3割の3年以内の離職率と言われています。
そもそも今大学も殆どが赤字で、学生の心の問題なんて見る余裕が無いと思います。
この国は急速なグローバル化、長期安定雇用型社会から成果主義への急速な社会変化で物凄く高卒者には苦しい時代の上に、1回ドロップアウトしたら這い上がりにくい状況が有ります。
だから、みんなには私のように心の病気での休職→解雇→長期の心の病気の治療による社会離脱を経験して欲しくないし
マナーなんて今の時代｢持っていて当たり前｣と言う状態で昔のように会社が教えてくれるわけでは有りません。
だからしっかり学校で学ばせる必要性が有ると私は痛切に感じております。
本当はクラスメート一人一人に言いたいことが有りますが、さくっと。
Nさん、よくノートを貸していただきました。貴方のノートはきれいにまとまっていて努力家であるのが良くわかりました。
貴方の誠実でまじめで努力家と言うのは本当にすばらしい才能です。
自分ではよく否定しておりましたよね。でもそれは物凄くいい点なので誇りを持っていってください。
努力家であるこれが生きていくうえでとてもとても大切なことです。
Tへ、リスカはやめなさい。歌・音楽の才能を折角持ってるのにもったいない。後ダイエットは20歳から。
20歳になったらプロテインダイエットとかをしながら運動をしていくと良いと思うよ。
あとZを殴るのは控えめに。Mに殴られたら｢嫌だ｣とちゃんといいましょう。
大切な友人とはいえ言わないと分かり合えないのが人間です。｢人間はエスパーではないのですから｣
Mへ、貴方には大変きついことを言います。
後ラケットなどで人を殴るのはやめなさい。せめて殴るなら手のひらにしなさい、自分にも痛みが返ってくるから。
でも殴られた方はそれ以上の体と心の痛みを感じてるってのは覚えておいて欲しいです。
そして、かかわりたくないといってもああするほか無かったのはTが｢自殺方法を私に聞いてきたこと｣を隠すためでした。
私正直、このことを貴方に1：1でつたえれなあったのが重たくて苦しかったです。
Tが死んでから遅いのです。
友が死んだ後、自責の念で苦しむのは自殺のSOSを聞いた人なのです。
TやZはもちろん他の人を殴るのはやめてください。
絵がうまいのは本当のことなのですが、私からあれこれ言う必要はないと思うので。
Sへ、自分が知的障害とか言うのはやめなさい。たとえ他の人がそう思っていても努力家であるのは私は見てますよ。
できないと思わないでやってみて欲しいです、若いから多少の失敗はまだリカバリーできるから。
Zへ、理数系滅茶苦茶強いしコンピューター関連は間違いない進路と思います。だけどはだしは寒いから冬はやめましょう(^^；
ゲーム業界に働くといっても流石に女子高の廊下をはだしで颯爽と走ると言う過去を持った人は居ないとおもいます。
(トカゲソを食べて野生化するという伝説をもってる人は実際にいますが、それも漫画上のネタですから)
Kへ、Zを支えてやってください。TはZをなぐるしMもなので…
KぐらいしかZを殴らないで守ってくれる人が見つかりません。重たいでしょうがよろしくお願いいたします。
慢研部長へ。
部活の計画を先ず立ててあげてください。
後輩が苦労します。
イベント等に参加するときはちゃんとスケジューリングをすること。
確か古い記憶だけれども、太陽・光栄辺りはそういうのがあったはず。
後神奈川の猫のしっぽなども対応できる筈なので相談してみてください。
文芸部へ
原稿出せなくてすいません、うまく副部長として立ち回れなくてすいません。
そして2年間大変な学年のまとめを担任として行っていただいたのは感謝致します。
そして3年担任へ。
決して貴方のクラス運営がうまくいかなかったわけでは有りません。
１～２年担任のクラス運営の問題でも有りません。
ひとえに私の力不足です。
大人としての責務を果たせなかった自分の問題です。
あと、これを読んでる（とくに）女性の皆さんへ。
性犯罪被害にあったらちゃんと話しましょう。
いのちの電話でも、公的機関でもいいのです。女性が相談に乗ってくれるところへ。
後、即時にアフターピルをもらいに産婦人科に行ってください。判らなければ119でも良いと思う。
犯人を許せなくて苦しむでしょう。
でも貴方は悪くない。
私のような苦しみは味わってはいけないのですから。
研究者の理想的な1日の過ごし方を模索していきたいです。以下たたき台。ご意見いただければ嬉しいです。
・最もやりたくない仕事に手をつける（5分で良い）
・一人のうちに執筆活動を行う
・メールが来たら2分以内に返信
・科学雑誌、論文が届いたらすぐに目を通し、文献リストへ追加する
・査読が返ってきたら結果を共著者に即メールして方向性を決める
・院生とは、必ず週1回は1対1で話をする時間をとる（5分の進捗報告でよし）
・出来れば外国語担当教員と友達になって週1回はランチを一緒にとる（おごる）
・アイデアは、EvernoteかICレコーダに逐一記録。再利用できるようにしておく。
・長期の予定に目を通す
・文献を読む時間にあてる
効率よい研究生活をするための雛形が作れればと思います。
ご意見を受けて修正していきます。
博士課程の学生だけど、お酒飲んでテンション上がってますわ！もう、バカになろう！
どーも、地方国立大の情報工学関連の大学院生（博士後期課程）の増田です。
今月、英語のプレゼンと国内学会のプロシーディング×２、国内学会誌論文の締切りを抱えているのに、全く進んでいなくて、どう考えても間に合うスケジューリングが思い浮かばず、軽く鬱っぽくなっています。もう開き直らないとやってられませんわー
5月、6月とサボっていたツケが今になって非常に困る状況になっただけなんです。もう一分一秒も惜しいとは思うのですが全くやる気がでなくて、先週の週末なんかは寝て起きて食べる以外のことはほとんどしていません。やらなくちゃ、論文書かなくちゃ、研究室内のミーティング資料を作らなくちゃ、と、やらないといけないことはポンポンと浮かぶのに、全くやる気がでないという、非常にこまった状況にあります。そして、普段から朝方の生活というよりも、お昼くらいに大学に行き、深夜まで作業をしているという生活をしていて、非常に生活リズムの狂った生活をしております。生産性が良いとは微塵も思いません。
正直、「あー、うわー、俺のバカ、俺なんか氏ねばいいのに」と、どうしようもない気持ちだったので、週末は彼女と一緒にいました。彼女といると、気持ちが紛れるんですが、、、、その自分自身の体型のこともありまして、暴飲暴食は良くないと感じさせるわけで、大好きなお酒はたらふく飲めないなぁなんて思いながら、少しだけビール（もちろん、ビール種別でなくリキュール類）飲んだりしましたけど物足りない。・・・だから、月曜日に頑張って引き籠もらずに、大学に行ったというこで（近くに彼女いないので）っ好きなだけ今飲んでいます。テンション上がってます。
と言うわけで、酔った勢いで思ったことがあります。
正直、「バカ」になった方が楽になるし、生産性が上がるのではないか、ということです。
ここで、「バカ」というのは、
「先のこと先のこと、、、、」と考えずにとりあえず、とにかく「今思っていることをアウトプットする」
という行動をする人のことです。下らないギャグでも、
にあるようなググったコードでも構わないのです。今こんなことを見つけたよ！！これってこの間考えた○○に使えませんかねぇ・・・、という某140字に収まる内容でも構わないのです。
とにかくアウトプットを続ける。そして、先のことはあんまり考えていないので、「それは、あなたが今抱えているプロジェクトにとって全く関係ない！けしからん！」「でも、この部分はおもしろいね」なんて言われても、いやいやそこまで考えていなかったので、よかった部分については今後に活かしますよ、という話になる。もし「こんなもの参考にするなんて・・・・センスないんじゃない？」と言われたら、「では、次回参考にしたいので、おすすめの事例・研究・文献・アルゴリズムはありますか？」ということになる。センスは「ある・なし」の「 1 or 0 」じゃなくて、磨くものです。誰にでもセンスはあります。
「重要そうなコメントは重く受け止める」なんてナンセンスですよ。仕事とか研究とかはもっと表面的な付き合いでおkですわ。自分が大変だった仕事に対して、もっと機械学習的に、なんか良さそう意見は良い！悪いもんは、ごめんなさい次回に期待してください、じゃぁ次はどうしましょ？的にドライに考えて、バカになった方が生産性が上がるんですよ！
ここ3年くらいずっっっっっっっっっっっっっっと思ってたんですが、実際、実行に移すのはしんどいです。でも、自分にとっても、先輩もしくはボスにとっても、研究はドライに考えることは精神衛生上とても楽になるんですよ！！！！！！！！！１１１１
とにかく、計画性を重んじるということはあると思うのですが、開き直ってバカになった方が楽です。鬱な気分にもならないし、徹夜もしなくなるでしょう。
明日の自分への戒めみたいなものです。頼むから忘れないでね、俺！！
ということで、こんな日記を書くぐらいなら論文書けって思いますよね。その通りでございます。サーセン！
おやすみなさい
それがね、もう２日に１度以上の確率で遅延するの
５分とか１０分とかは可愛いほうで、たまに１５分や２０分遅れる
もちろん、
アナウンスで言うのは「混雑の影響で」なのね
あのな、朝の通勤電車なんか混雑するのが当然だろ
毎朝同じ量の混雑をしてるだろ
そんな理由で納期をランダムに遅らせていいなら仕事なんか楽しくてしょうがねえよ
今日は「○○駅で車両接続に手間取りました関係で遅れが出ております」だってさ
「混雑の影響で」ってのはさりげなく乗客に責任押し付けてるわけだからさ
結局、京急の職員、現場かシステム作ってるやつか知らんけど、京急の職員が、
そうやって細かい不手際をほぼ２日に１ぺん以上の頻度で
とやってるわけですよ
全ッ然改まらないし頻度が減らないのは京急も職員もそれでいいと思ってるからでしょ
これやっぱり乗客が物分り良すぎて上品過ぎるからじゃないのかなあ
災害による遅延で交通機関の職員に食って掛かってる下品なオジサンが良く顰蹙の対象になるけど、
京急みたいに災害でもなんでもなく常態的にダラダラ遅れるような交通機関の職員には
そういう下品なオッサンがガウガウ言ってくれたほうが皆のためになるんじゃないのかな
ガウガウの直接的対象になる職員がその事態に責任を持つかはわからないし、無関係のことも多いと思うけど
そういうことをやってれば「頻繁に遅れちゃいかん」「だらけちゃいかん」ていう空気は作られるでしょ
何の世界でも、文句や叱責が無さすぎる職場が緩まないことなんてないんだから
朝の時間を頻繁にランダムに１０分２０分削られたら出社時間の調整もスケジューリングもありゃしない
「混雑の影響で～」というアナウンスが流れるたび、
目を血走らせた下品なオッサンが運転席や車掌席の壁をガンガン蹴っててくれればいいのにな
と思う
8 仕様書無しさん :2010/01/26(火) 09:03:13
「年末までには納品する。」
「年末までに必ず納品日を決める。最後は私が決める。」
「納品日をしばらくスケジューリングしないことを決めた。」
「信じてください」
「お客様には了承いただけていると思う。」
「5月までには必ず納品したいという思いがある。」
「まだ開発を始めてたった2年ですよ。まだ始まったばかりです。」
「5月までには何としても納品したい。」
「詳細設計期間が終わりました。これから本気で開発に挑みたいと思います。」
「お客様からのクレームは、叱咤激励として受け止め、今後も頑張って開発を続けたい。」
「年末に納品しなくて良かった。急いで納品していたら問題が起きていた。」
「5月では間に合わない可能性がある。」
ついつい失笑してしまったので。
上司 「何故進捗50%なんて嘘をついていたんだ！！まだ30%程度じゃないか！！」 ＰＧ 「進捗率というものが、どういうものなのかよくわからない」
「年末までには納品する。」 「年末までに必ず納品日を決める。最後は私が決める。」 「納品日をしばらくスケジューリングしないことを決めた。」 「信じてください」 「お客様には了承いただけていると思う。」 「5月までには必ず納品したいという思いがある。」 「まだ開発を始めてたった2年ですよ。まだ始まったばかりです。」 「5月までには何としても納品したい。」 「詳細設計期間が終わりました。これから本気で開発に挑みたいと思います。」 「お客様からのクレームは、叱咤激励として受け止め、今後も頑張って開発を続けたい。」 「年末に納品しなくて良かった。急いで納品していたら問題が起きていた。」 「5月では間に合わない可能性がある。」
麻生の場合 「アッフロード完了しました」 『アッフってなんだ。アップロードだろうが。』 「あっ、間違えました、すみません。」 『まぁアップロードは出来ているからいいけど、なんで君はいつも単語を間違えるんだ』 「申し訳ありません、次回から気もつけます」 『それを言うなら気をつけます、だろうが！まったく！！』 鳩山の場合 「アップロードしたいという思いがある」 『いや、しろよ』 「いつかやらなければいけない、とずっと前から思っていた」 『だから早くしろよ。みんな待ってるんだよ』 「そんなに急ぐことはない、と皆が言っていると信じている」 『俺は急げと言っているんだが。なんで君はいつも空気が読めないんだ』 「トラスト・ミー！」 『訳わからんことばっか言ってないで、さっさと仕事しろ！！！』
レスに際してはてな記法がよくわからんので適当引用で失礼しますｗ
＞ http://anond.hatelabo.jp/20100114074057
逆なのではない？
そういう人間だから～
その線も半分くらいあるは思います。
あと市峰自身が、他人の問題ごとに首を突っ込む(or相談を持ちかけられる)ことが多くて
そこで多分、人間の醜悪な部分を相当見たんだと思う。んでもって
『なんで俺はこんなに正しいことをしてるのに他人に伝わらないんだ！』
という葛藤に苛(さいな)まれたんじゃないかなー。
＞ http://anond.hatelabo.jp/20100114074057
違います。振った結果は1％でも100％でもぶっちゃけどうでもいいですｗ
仕事を振ってしばらくしてから帰ってくる
『こないだ手伝ってやったんだから今度はお前の番な』みたいな"暗黙の強要"が怖いんです。
!--ここから愚痴--
特に今は仕事を振るどころか振られることの方が多くて、
俺が抱えてる俺の仕事は特殊技能系の業務だから俺にしかできないけど、
って言いたくなりつつ日々を過ごしてます。
自分の本来の仕事(特殊技能系の業務)は消化できず、残業ばかりが増えていくorz
（最近、幹部会議で俺のタスクがアホみたいに多いからどうにかしようという会議があって、
そこで俺には当面大きいタスクを振ることはせず、それでもなお大きい案件が出た場合は、
再スケジューリングを施すよ、という決定が下ったらしい。
ありがたい事ではあるんだけど、幹部会議に出席してない人たちは
相変わらず俺に小さいタスクをポンポン投げてきてるんですがどうすんのよ。
できるかっていう確認の電話がかかってきたぞ。
そん時は『向こう半年はスケジュールが埋まってるから無理』と言ったけど、
二つ返事でOKしてたら絶対にリスケ無しでGOだったよ･･･）
!--愚痴ここまで--
あと書いてて思い出したけど、今の自分の状態、
19話最後のチェンシンとの会話「みんなでお見舞いを送ってやったのに！」→「送って『やった』？押し付けの友情ならいらねぇよ！」とか、
22話最後のシーンで大事な話を隠されてい点や、
『孤独も、苦痛も、不安も、後悔も！もったいなくってなぁ！テメーなんかにやれるかよぉ！！』
なんて心情も今は物凄いしっくり来ます。
ああ、残念ながら現実では今んとこ"港"は無いようですｗ
＞ http://anond.hatelabo.jp/20100114074057
紹介されたブログをザッと見る限りだと、
自分に当てはまる症状はそこそこ多いなーと思います、自己嫌悪からつながった罪悪感ありますよ今。
まぁまず今日は自分を労うため、１ヶ月ぶりに定時で帰ってきて、まったりとこの日記を書いてます。
明日はおそらく残業だろうけども、土日は久々に何も予定を入れてないので
近所のスーパー銭湯あたりでゆっくり骨休めをしますね。
他人の悪意ある発言はどうだろうなぁ、今んとこ無さそうなので大丈夫ですが、
今後は気を付けておきます。
http://anond.hatelabo.jp/20090917201807
ってのを見た。
未だにVistaがオフィスに入らない理由としては、重いとかではない。
実際、Vista Ult（32bit→64bit）を、それなりにリソースたっぷり（Core i7）のPCで使い続けてみたけど、XPと比較して、OSのせいで処理が遅くなるとと感じるケースはあまりない。（但し後述で一部訂正する）
ビジネスで使われるPCってのは、今まで何とかPCで仕事をこなせる程度の、一般的なPCスキルの持ち主を想定しなければならない。
この層が、Vistaや7を使いづらいと感じてしまうのであれば、それは抵抗されるに決まってるわけで。
１）UACの問題。いちいちダイアログが出るようでは、OSの事など知ったこっちゃ無いユーザーには恐怖しか与えない。（Win7では改善される）
２）XPであれば周りに操作を聞いたり相談したり、Tipsを交換しあえるのに、そんな中でVista渡されたら、こんなのどう使うのって怒られる。間違いなく。
３）勝手にタスクで色々管理する。デフラグがデフォルトでスケジューリングされてるとか、何なの一体。（Win7でも改善されない）
４）見た目が変わる。いや、冗談ではなく、それだけで嫌がる人はいるんです。（Win7はもっと酷くなる）
次にリソースの問題。
一般的な職場を見渡せば判ると思うけど、基本的に職場で使われるPCってのは、5年程度使われるモノ。（リース契約とか使ってね）
2年前のPCなら、まず基本状態でVistaは稼動するだろう。けど、それ以前のPCはどう？といわれれば…ね。
さらに、環境の問題。
XPとVistaが混在している環境なんか、管理側からしたって想像したくない。
そして管理Server自体が2003Serverだったら。
いきなりVistaをクライアントとして放り込むわけにも行かず、かといって2008Serverにリプレースするなんて、面倒でしょうがない。
結局、職場でVista（Windows7も同じだけど）を導入するってことになれば、基本的に部署単位より大きな単位で、一括でごっそりやるしかないわけで。
PCの価格は下がってるし、一括導入をするコストは確かに安くなってはいるけれども、「今の状態を維持」するコストが、「Vista/7を導入して出てくるメリット」を凌駕するとはとても思えないんだよね。
さらに言えば、職場でPCを大量に導入する場合は、環境を色々同一にしなければいけない（職場毎の基本カスタマイズが必要）なのだけれども、Vistaを導入する場合、やることが多すぎる。管理者側からして、2003ServerとVista（または2008ServerR2とWin7）との連携を勉強しなおさなきゃいけない。
これらを踏まえて、たとえばPCを職場で大量にWin7で置き換えると考えてみよう。
導入までに掛かるコストの割合は、
・PCリース契約のやり直しと新規契約（OS代はここに含まれてしまう。） 30%程度
・運用管理用Server（Domain管理／FileServer／その他色々）の新規購入orリプレース 30%程度
こんな割合になるんじゃないだろうか。
だから、いくらWin7の価格を安くしようが、PCを安くしようが、屁のツッパリにもならんくらいしか、全体のコストは下がらない。
更に、ネットワーク構成の見直しやら旧環境との相互運用なんてものまで考えだしたら、運用側としては逃げ出したくなるね。
こういう風に、職場にVistaや7を入れるには、掛かるヒューマンコストが半端でないってことを、きちんと説明しているIT系サイトが少なすぎるよなー、と感じる次第。
結局、Windows7が出荷されたとしても、XPのサポートが切れるとか、リース契約が終了するとか、運用管理サーバを何かのきっかけでリプレースするとか、そういう事が無い限り、各現場がWindows7をバンバン入れるなんて幸せな路線は、ありえないという、お話。
個人的には、XPのサポートが切れたとしても、サードメーカーが「ウチがXPの面倒みまっせ」と手を上げて、そのサービスが大人気…なんて商売がなりたつんじゃないかと思う。致命的なセキュリティバグが出ない限りにおいて、だけども。IPv4の限界に達するまでは、おそらく職場ではXPの天下が続くんじゃないかな。いや、それですら逃げ道はあるんだけども。
追記：Vista/7に関しては、その利用に関して2点「直接的な問題」もある。
1つ目は、バックグラウンドで動いているサービスが多すぎること。（Windows7では少し減ったみたいだけど）
処理に関してどれだけ性能の高いPCを使っていても、正直言えばXPや2000の軽さは望めない。1つのプロセスの処理時間そのものは変わらなくても、どこと無くもっさり感を感じてしまう…という体験からは、逃れられない。
とはいっても、XPも登場当時はこれで散々叩かれたわけで、慣れの問題かな。
2つ目は、同時に導入されるであろうMS-Office2007。これは家庭向けPCではあまり気がつかない（導入されていないケースが多いから）、最悪の問題だ。UIへの戸惑いは、PCスキルが無い人にとって致命的過ぎる。Win7ではこのUIがアクセサリまで進出してるって？どんだけ。
追記の追記：最後に忘れてた。Office2007に入ってるIME2007！一番操作感を左右するであろう文字入力変換で、こんなバカ重いソフトなんか使わせたら、絶対クレームモノだ。とっとと窓から投げ捨てろ。どんだけ性能高いPC使ってても、これだけは導入禁止。
Webアナリストになりたいんです！っていう人が出てくるほど、Webアナリストという職が世の中に浸透しているとは思えませんが、なりたいって思ってる人がいるかもしれないので書いてみます。といっても、自分もまだまだWebアナリストとしてはヒヨッコなんですけどね。
めちゃくちゃ必要です。
Webアナリストは常にExcelを起動していると言っても過言でないくらい、Excelと向かい合って仕事しています。
関数は基本的なものはもちろん、マクロ・VBAに関しても使えた方が良いです。
ちなみに私はVBAは作れません。
勉強せねば・・・。
ここでは最低限押さえておいてほしい関数や機能をあげてみます。
当たり前ですが、これは必要です。
用語の意味とその数値がいいのか悪いのかを判断できるようにならないといけません。
まずは下記の用語と意味を覚えてください。意味は自分で調べてください。
Webアナリストの仕事は、解析をして、ここが悪いと指摘するだけじゃダメなんですね。具体的な改善提案を示すことが必要です。
ここで改善提案を示すのに必要になるのが、サイト制作の知識なわけです。
あえてサイト制作とばっくりとした書き方にしたのは、サイト制作がデザインとか、ユーザビリティとかそういった言葉を内包しているからです。
ここについては素養として制作の知識を持っていれば持っているほど、深みのある提案ができると思います。
私はここの知識が乏しいので、なかなか厳しいと日々感じています。
アナリストが行う分析は大きく２つに分けられます。
1つはサイト内部の分析、もう1つは集客（広告効果測定含む）の分析です。
じゃあ集客の知識って何があればいいのって話ですが、こんな知識をつけておくと役に立ちます。
数値が良くないと気づき、なんとなく打つべき施策はわかったとしても、この施策を打てば本当に現状より良くなるのか、確証が持てないことがあります。
そんなときに行うべきテストの方法を知っておくと便利です。
A/Bテストや多変量テスト、リスティングのT&Dローテーションなんかがテストの一例です。
あぁ、またこれかよ、と思われそうですが、これは主に2つの理由で結構必要だったりします。
1つは自分が3や4の知識が乏しくて改善提案を示せないときに、デザイナーやマーケ担当の人とコミュニケーションを図って糸口を見つけ出すことが必須だからです。
もう一つは自分が改善提案をしたものが裏目に出てしまった場合。
いかに角を立てずに説明できるかがポイントになったりします・・・。
当然ですが、自分が解析した知識は共有しないと全く意味がない訳で。
だって方針を決めるのはディレクターだし、手を動かすのはデザイナーやプログラマーな訳で。
で、上層部は「うちのサイトはどうなんだぁ？」というすごく抽象的な説明を投げかける訳で。
そういったキーマンたちにきっちり説明するために、プレゼンテーションの知識は必要になります。
これは6とも通じるところですね。
最後に。
アクセス解析はやろうと思えばどこまでも際限なくできてしまいます。
でも時間は有限なわけで。
どこかで線引きをしないといつまでたっても終わりません。
このときまでにここまでの数字を出そうと心に決めて、できれば手帳に書いて、仕事を進めることが
とーーーーーっても大事です。
ちなみに、本格的に勉強したいなーってひとがいたら、最近発売された
「ウェブ解析力 ROI(投資対効果)を最大化するアクセス解析の実践的ノウハウ90」
という本は一度目を通してみると良いと思います。
これだけじゃなく、アクセス解析に関する本は少ないので、一通り目を通してみても良いかもしれません。
いかがでしょうか？
頻繁に打ち合わせを行ってるなら、元々スケジューリングされてないのか？
スケジュールにない打ち合わせがあるなら、プライオリティを考えて返答する。
（何分後に参加します、でOKじゃね？）
あまりに頻繁なら、何時開始終了ってスケジュールを決める
2. 些細な別件で呼び出しておいて、そこから長時間の打ち合わせを行う、ということがある
これも多いなら何時終了決めればOK
っていうか、些細な別件ならその場で済ませばいいのであって、多分その後の件のほうが重要なんだろう。
元増田（だけ）が「些細な別件での打ち合わせ」って思ってる気がする。
何故分からないのか分からない。
現場に即した意見、情報交換なら雑談にしか「できない」のが無能なだけ。
んで、元増田が必ず記載して、「今のまとめますか？」って突っ込めばいい。
つか、キャリアが浅い奴が議事録取るのって暗黙の了解じゃないのか…
4. 話しながら考えられるので余計に苛立つ
事前にアジェンダ用意しないからそうなるわな。
決定や回答を求めるような内容だったら打ち合わせの一週間前には議題出す。
（おヒマなら前日でもいい）
5. たまに気軽そうな雰囲気を出そうとしているようだがそれが却って苛立つ
会議の効率と同列に考えたらアウト。
どうしてもなら自分が仕切れ。
意見が言える（ある）のと言えない（言わない）のは大きな違いがある。
キャリアの違いで「言っていいと思えない」という結論に達しているなら、
（最初から意見がない、言ってないなら論外。積極的に参加しましょう）
その判断はキャリアの長さだけか？
そこは積んでいく物だし、周囲から勉強すべきもの。
キャリアが浅く、現実に即してない意見しか言わない奴は白い目で見られて仕方がない。
けれど、未熟さを恥じる必要はない。
未熟なままで厚顔になるなら恥ずかしいが。
ストレスでハゲたり怒鳴る前に、できることやすべきことがまだ沢山あるんじゃないのか？
特別でもなんでもないから、がんばれると思う。
「した」と言うより「している」が正しい。
修士課程、まったくうまくいっていない。
原因は全て自分にある。
家族、尊敬している先生方、同期、先輩方に迷惑をかけてしまっていて
正直、そろそろ楽になりたい。
====
私の大学では学部3年次に研究室配属、3,4年次は大学生活の中心が研究室での過ごすことになる。
大学院に進んだきっかけは学部研究室時代にいた修士の先輩方に憧れて。
教授との議論、後輩への指導、自分も「ああなりたい」と思った。
先輩たちと過ごした夜～朝にかけての研究の時間はとても楽しかった。
けど、話は簡単には進まなかった。
学部時代にお世話になったA教授は他大に引っこ抜かれる事になり、
様々な縁があり、学部と同じ大学で、A教授の学生時代の先生のB教授の所で引き取ってもらう事になった。
でも、何もかもが空回りだった。
まずスケジューリングから失敗した。
授業：週9
ゼミ：週6
バイト：不定期
私の大学では1年が前期と後期に分かれており、
修士1年前期中に修了単位分を取ろうと思った私は授業を多く取った。
しかし、修士の授業は専門性が高く、ほぼ毎回、発表資料を作らないといけない為、
私はだんだんと、授業に追われるようになっていった。
元のAゼミに出なければいいじゃないか。と他研究室の同期に言われたが
そんな事はできなかった。
情けない話だ...
だけど、「自分なんかより努力している、苦労している大学院生はいる。」と自分に言い聞かせ
徹夜根性、土日、休日返上アタックで何とか前期は持ちこたえていた。
新しく入ったB研究室にはC先輩がいた。
B教授からとても信頼されている先輩だった。
何時の頃からか、そのC先輩に嫌われている事に気づいた。
嫌われているといっても、仲が良かった期間があったわけではない。
私の思い込みかもしれないが、業務連絡以外で私に話しかけることはなかった。
話しかけても、「ええぇ、そうですか」の二言で会話が終わってしまう。
しかし、他の後輩とは楽しく喋っている。
今までそういう経験がなかった私は非常に動揺した。
そしてB研究室の学生よりも、前のA研究室の学生達と交流する様になっていた。
元々、A研究室の後輩達は学部生の頃に共に勉強した事もあり、親しい間柄にあった。
今さら考えてみれば大失敗だった。
どんどんB研究室で浮いていった。
夏に入り、後期が始まった。
テーマすら形になっていない。何とも情けない。
そして、報連相が欠けていると注意された。
自分としては驚きだった、自身の休みを削ってでも後輩を指導できる様に努力していたつもりだった、
しかし、報連相、特に「相談」が欠けていたのは確かだった。
自分の力で何とか乗り越えようとしていた。
自分が研究室で浮いているという気持ちから報連相が疎かになっていたかもしれない。
ここら辺から徐々に大学にいるのが辛くなってきた。
11月に入って、研究室全体でOB,OGに研究を発表する機会があった。
いそいそと発表資料を作っていた私だったが、前日になって、その企画を運営している後輩から
「大学院生はA0のパネルを作って発表よろしくお願いします」と言われた。
詳しく聞いてみると私以外の先輩方は既に用意しているらしい。
正直、唖然とした。
ここら辺で何かが切れた。
「私って何の為に大学院に進学したんだっけ」と自問し、
結局その会にはバックれた。
何もかもがどうでもよくなった。
その後は引きこもり。
修士1年前期に大量に授業取っていた事と
恥ずかしい話だが、「私は心を入れ替え頑張ります」と言い努力していたが、
すぐ鬱になってしまった。
そしてそんなこんなで6月になり、
思い返せば修士2年間、何もしていない。
「修士だから何かをしなくてはならない」と思い込んでいるわけではないが
本当に何もしていない自分に嫌気がさす。
鬱という言葉を利用して逃げているだけかもしれない。
そんなこんなで私のくだらない人生はお終い。
私が偉そうに言える言葉ではありませんが、
是非、自分の将来のスケジュールをしっかりと作ってがんばってください。
こんな所で言うのもおかしな話ですが
id:next49さんのblogには何かと心の支えになりました。
ありがとうございました。
普通だ！！！！！！！！！！
http://anond.hatelabo.jp/20081220025833
上記のエントリが人気だったのが数日前。
話題がクリスマスとかM-1グランプリとかに移り変わってしまっているが、今タイミングで自身の体験談を書き記していきたい。
テクニックとかライフハックとかは私にはよく分からねえですが、誰かの役に立てればこれ幸い也だ。
会社で取らされることはほぼ無いんじゃないかと思います。
合格でいくらか一時金は出るかも分かりませんが、簿記一級が必須になるようなシーンは想像できない。
また、合格と同時に税理士挑戦権が獲得できるので、挑戦権を持ってない人がこのために勉強するパターンはあると思います。
ただやはり、なんと言っても「1級」という甘美な響きが全ての意味だと言って過言ではないでしょう。
それはもう、ええ、それはそうでございます。
あとは日経がよく読めるようになるような気がします、それは気持ちの問題です。
1級取って決算書読んで投資に生かそう！とか思わないでください？あんなんプロの殴り合いですよ？
日商簿記2級に受かったけど、1級どうするかなあって思ってる人
最初にぶつかるのは「独学」か？「スクール」か？という選択になると思う。
もっと上位資格だとノータイムでスクールに決められるのだが、さて1級だと微妙、どうするか。
費用面から言えば
独学→テキスト2,000×6冊 / 問題集2,000×6冊 / 応用問題集2,000×2 / 過去問2,000 合計30,000円
といった感じ。最終的には人によりけりっていうか塾とか予備校とかが性に合う人はスクール行ったらいいんじゃないですかしら。
独学にしても教材は必ず最新版を使用するようにしてください。
古いのを使ってしまうと、当時の会計基準と今のとで思いっきり変わっていて痛い目を見る可能性が。
私の場合は3級、2級と独学で取れてしまったので「えへー、やっぱりトレンドは1級だよね」ってことでカジュアルな気持ちで半年間独学で勉強したのですが、
いざ本試験になったら全く全然手も足も出なかったので「あかん、あかんて、こんなんちゃうねん、こんなんちゃうねんて！」と松本人志名文句を呟きながらスクールに通うことにしました。
3ヶ月で受かる！とかそういうのは頭の良い人に任せておいてですね、
社会人の人は土日使って内容を一巡するだけで5ヶ月くらいは見といた方がいいんじゃないでしょうか。
その状態で過去問を解くとサッパリ点が取れないと思うので、そこから基本問題をもう1周するなり、応用問題を解くなりで更に3ヶ月。
最後の2ヶ月は答練に通うなり過去問を解くなりで過ごしてください。
というかスクールのスケジューリングをそのまま書いてみました。
ペースメーカーとしての使い方と「周りはもう、こんなに解いている！激ヤバ！」と自身にプレッシャーを与える使い方がスクールの正しい使い方なのではないかと個人的には思います。
大体450から500時間くらいで受かったので、土日5時間ずつで1年という感じでしょうか。
日商簿記1級は「商業簿記」「会計学」「工業簿記」「原価計算」の4科目に分かれており、
それぞれの科目で10点以上、且つ、総合点で70点以上取ると合格、という試験方式になっています。
さて、点数を取るためにはどの科目に力を入れた方が良いでしょうか？
はい、もちろん苦手科目の方が点数の伸びが良いのでそれに力を入れるのが正着です。
ただ原価計算は回によって難度のばらつきが激しく、崩れるときは1問目から総崩れもあり得る恐怖の科目なので、足切りを絶対に回避しましょう。
「商業簿記」は過去問レベルの問題をいくらか解いて掴める科目。一番出題パターンが少ないので。
とりあえず連結税効果会計を後回しにせずにやっておくと自信に繋がるのでは。
「会計学」は「この単元はボリュームは少ないけど何だか面倒なことになってるし、後で覚えることにしよう」ってなところを狙って出してくるので酷いと思う。
流行の論点が出る傾向にあるとかいう話なので、工事進行基準とか狙われるんでしょうかね。
なんだかんだで満遍なくやることになる科目で、一番最後に仕上がるのはここじゃないかと。
「工業簿記」はパターンはパターンなんですが、そのパターンの分岐が多いので結局、根本的な理解が必要になってくる。仕方がないと思ってやるしかない。
「原価計算」はとにかく頑張れ。球が来るからそれを打て。
ボタンが大きくて、戻る機能が有ればいいです。
この試験は2級までと違い得点調整が行われるため、合格率は大体8から15%内で推移しています。(調整してそれかよ、という話もありますが)
合格率10%前後ということで身構える方も多いと思いますが、そんなに皆が皆真面目にやってやしませんて。
試験終了後、集められていた答案は割と白かったですよ？
ちゃんと勉強すれば、割と短期できちんと返ってくるタイプの資格だと思います。
１年半は短期ではないという向きもありますが、それはそれとして。
1級程度で調子に乗って周りに吹聴していると、税理士や○○○○士が出てきてこてんぱんにされますよ！！！！
(丸の中には勝間和代が入ります)
なるほど、スケジューリングか。。
そういえばスケジュール管理するような手帳は普段持ち歩いてないし、Googleカレンダーを中途半端に使うだけで、自分のスケジューリングを徹底するようなことは今までの人生で一切やってこなかった。思えば昔から、予定を立てずに思いつきで行動するのが好き（というか怠惰なだけ）な人間だった。
数年前までは、周りの大多数の人間と共通した締め切りにだけ間に合えば、とりあえずひどい目には合わなかったので、そのコミュニティに属していることで、何か公的な締め切りが近いことは察することができた（周りがそわそわしだすので）。そして前日か前々日あたりから準備に取り掛かり始める。結果、ぎりぎり間に合う。そんなことを繰り返してきたんだった。最近までは毎回、結局それで何とかなっていたのだが、最近はそのやり方が破たんしてきた、という認識。
（やる気のなさや怠惰といった）自分がこういう状況になったそもそもの原因は、自分のスケジューリングを他人任せにしたりする甘さ（甘え）に起因するのだと思う。気付かせてくれてありがとう。
仕事をしていく上でいくつも壁がある。それにぶつかって、乗り越えないと「頑張ってもダメ」という結果が自分に植え付けられ、結果、頑張れなくなる。こうすればいいんだ！というのが見つかれば、その壁は乗り越えられる。
壁にぶつかったら、乗り越える方法を考えるか、逃げるか、逃げる事を保留するか。
君は最後のだ。逃げる事を保留してる。
普通なら、君みたいな状況ならスケジューリング能力について悩むと思う。自分の仕事のスピードと今抱えてる仕事の量、そして締め切り、頼まれる仕事の見通し。それを全部スケジューリングして、常にボーダーラインを超えなければ仕事は廻る。
世の中にはそれをサポートする道具が山ほどある。メモ帖１つでも充分だけど、カレンダーの方がいい。
……と、ありきたりな返答をしてみたけど、元増田は拒否すると思う。これでスケジューリングするぐらいならこんな状態になってない。
ただ、スケジューリングするか、死か、そんな状況に今なりつつあるんじゃないのかな？と思い、無駄とは思いつつ、スケジューリングしなよ、と言っておきます。
実にいい記事に出会った。コンサルタントとしての基本を思い起こさせ、かつコンサルを生業としている者を奮い立たせる内容だ。
エントリに絡むはてブのごく一部に「当たり前」という趣旨の批判がある。しかしながら、こういう批判をする者は、当たり前をいかに忠実に行うかの難しさを知らない世間知らずの学生か何かなのだろう。適当に放っておいて良さそうだ。
優秀なコンサルタントは、さらに、パワポを見てみれば判別できるという話もある。
やたらオートシェイプやアニメーションをふんだんに使うスライドでプレゼンを行うコンサルの提案は、その９割方を眉唾と思ってほぼ間違いない。
対する、ウォートンやケロッグなどの著名 BS を修了したようなコンサルの作るパワポは実に美しい。
まず、ムダな虚飾がいっさいない。日本にいるあまたの外資系コンサルが、それこそ「コンサルらしい」スライド作りに腐心している姿を見るのとは雲泥の差だ。
それでもって、優秀なコンサルが作るスライドは、シンプルながらも訴える力が強く、なおかつ意思決定者に決断を迫る優れた（テキストによる）ストーリーテリングが行われている。
そして何よりも、優秀なコンサルが作るスライドは、枚数が極端に少ない。10 枚を超えることはほとんどないと言ってもよい。だいいち、30 枚も 40 枚も、あるいはそれ以上もあるプレゼンを見せられた日にはちょうどいい午睡の時間とされるのがオチだ。
あまたのコンサルたちの作るきらびやかなスライドを見終わった後のクライアントたるあなたの感想は「だから何？（So what?）」であることはほぼ間違いない。それに比べ、優秀なコンサルの作ったスライドを見終わったあなたは、プレゼン会議が終わるや否や、臨時役員会のスケジューリングを始めることだろう。
エモーショナル＝アトラクティブではないのである。少ない労力で最大の効果を得る、いや、これはちょっと違う。優秀なコンサルは、そのシンプルで美しいスライドを作るためにロジックを何度も練り直すのだ。
そうやって提供されるプレゼンテーションが成功しないことはむしろ少ない。皆さんのプレゼンが成功することを祈るばかりである。
