 
|
はてなキーワード: インタフェースとは
第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 練習問題
プラットフォーム、機能、制限事項が多すぎて分かりにくいから。
「A社からの本を読むには、本とは別に初回に○○円かかります。B社の本も読みたい？では別途、××円かかります」
「次のページへ進むには、この本ではページをつまむようにめくってください。この本ではページを指でスライドさせるようにめくってください」
「この本はページに線を引いたり、ページを切り取ってスクラップにすることはできません。この本は電波の届かないところでは見ることができません」
挙句、これらの制限事項があるにも関わらず、「普通の本と値段はあまり変わりません」
これじゃ、ユーザーは買おうという気にはならないよ。
http://anond.hatelabo.jp/20110707195830
初音ミクLAライブ、外国人の感想その５。これまで紹介した感想は「ヴァーチャル・アイドルとしての初音ミク」を論じていたが、今回はミクの本来の姿、即ち「歌声合成ソフトとしての初音ミク」に注目しているのが特徴だ。また外国における歌声合成ソフトの将来性についてかなり厳しい見方をしているが、その指摘には耳を傾けるべきところも多い。初音ミクの海外進出に関する先行きを占ううえでも目を通しておく価値はあるだろう。
urlは以下の通り。
http://lelangiric.wordpress.com/2011/07/07/i-didnt-go-to-ax-but-yeah-anyway/
ミクのイベント後にはいつもヴァーチャルスターの構成要素は何かって議論が巻き起こる。クラウドソースな人格か？ touhou［東方］っぽさ？ オリジナルのないdoujin［同人］？ それともインターネットとDTMの力に関するフリードマン風の熱狂か？
確かに日本じゃ大うけだが、アメリカではこれからどう成長するんだ？ オレは英語のVocaloid3が発売されるのを待っている。いいものであってほしい。アメリカでのボーカロイドの発展には英語Vocaloid3の性能が極めて重要なんだ。けどな、アニメ産業とボーカロイドとの結びつきについては、オレは戸惑っている。つまりAXがミクノポリス会場になったことにな。今後も長期にわたって、アメリカではボカロオンリーのイベントはないだろう。アメリカに拠点を置く企業製のボーカロイドすら未だにない。オレが知っている［英語ボカロの］２つの会社はPower FX（スウェーデン）とZero-G（英国）だ。
でもな、そこでオレは考えてみたんだ。
ボーカロイドはvst［ヴァーチャル・スタジオ・テクノロジー］（とかその他のapi［アプリケーションプログラミングインタフェース］）といくつかの重要で理論的な方法は似ているんだが、極めて重要な具体的手法は根本的に違っている、とオレは理解している。基本的に（ある人間の）音声ソースを取ってきてあらゆる音素と音程を録音し、ボイスバンクを作った後で、ヤマハのVocaloid2プログラムがボイスバンクを「読む」ことができるようアプリケーションをコードする必要がある。オレはヤマハがこの部分で相当用心していると思っている。なぜなら公式のボーカロイドは（もしオレが間違っているなら訂正してほしいが）全部ヤマハのVocaloid2エディターと一緒に販売されているからだ。この意味でvstとは根本的な差異が存在する。（１）vstは通常daw［デジタル・オーディオ・ワークステーション］と一緒に流通することはない（２）vstの開発者であるスタインバーグは、vstプラグインを規格として作成しており、従って誰もがvstプラグインを作り出せる。
http://en.wikipedia.org/wiki/Virtual_Studio_Technology
http://en.wikipedia.org/wiki/Digital_Audio_Workstation
http://en.wikipedia.org/wiki/Steinberg
つまり、誰もがボイスバンクを作れるってことだ。UTAU現象がそれを示している。UTAUは違うソフトで動くボーカロイドの単なる「代替手段」（本当の意味でではないがオレは耐えられる）のフリーウエアに過ぎない。自家製ボーカロイドが登場するには（『ファンの作ったボーカロイド』はあるが、本物の商業ベースのボーカロイドとは違う）２つの条件を満たさなければならない。ある団体が充分な資本を集めて（１）高品質のボイスバンクを作成し（２）ヤマハからそのVocaloidエディターを頒布する許諾を得ることが必要なんだ。既に言った通り、紛らわしいのはボイスバンクをプログラムに「読ませる」ためのアプリをヤマハとサードパーティのどっちがコードしているのかってこと。思うに、もしおれがAXの会場にいてこの質問をしていたら、特にヤマハからVocaloid2の許諾を得るのにいくらかかるかを聞いていたら、オレは殺されていただろうな。日本のdoujin歌手を使えば高品質なボーカルを作るのはそんなに難しくないだろう。必要なのはインターフェイスと集音マイク。ダチを作ってそいつらに作業をさせる。そしてUTAUのファンダム全体を見れば分かるが、自分自身を体現したボイスバンクを作ろうとするモチベーションの持ち主は山ほどいるぜ。
http://utau.wikia.com/wiki/UTAU_wiki
オレが何を言おうとしているか分かるだろう。つまり、アメリカ製のインディー・ボーカロイド・スタジオの実現性ってのはどのくらいあるんだ？
少なくとももっと注意深く考え抜く必要がある４つの条件があると思う。
１． アメリカのアニメ業界とボーカロイドの関係。オレが思うに、ブランドイメージと、それからボーカロイドとアニメを結び付けているメーンストリームの連中のことを考えれば、こいつは最も重要な問題だ。「アニメ」はアメリカでその「あるべきもの」（つまりdirty japanese hentai shit）より遥かに大きな概念/カテゴリーになるべきだ。でもまあオレが見てきた限り、日本のボーカロイドにも同じ混同の問題があるようだけどな。とにかく、メーンストリームが一般的にアニメをどう見ているかがボーカロイド関連商品の売れ行きに影響するってことなんだが、この問題はオレには重過ぎる。omoやalexが考えてくれんじゃねーの、多分。
http://twitter.com/#!/alexleavitt
２． 誰か英語ボーカロイド使ってるヤツいる？ 西洋ボーカロイドファンダム総体の認識として、１人だけすげえアメリカ野郎がいて、そいつがボーカロイドランキング（ニコニコのやつで毎週ボーカロイドの歌/動画をコメント/再生数/マイリストに従ってランク付けしている）に［英語ボカロを］ぶち込んだことがあった。でもそいつは突然自分の動画を全削除しちまった。この一度こっきりの出来事を除けば、ボーカロイドは完全に日本のものだ。他にも英語が母国語の作り手はいるんだが、皮肉なことに英語話者のボーカロイド製作者が基礎を置く発生核となりそうな連中の大部分は、日本語ボーカロイドにengrishをしゃべらせようとしている有様だ（大笑い）。
この問題にはさらに深い根がある。
３． そんな真面目な議論じゃないんだが、ある文化の労働的な基底はどうして特定の製品に同調し他の製品には抵抗するのかについて話がなされている。歴史的かつ社会経済的な問いだ。どうしてチリは銅を掘っているのか？ なぜならそれがくそったれなほど沢山あるからだ。結果として採鉱は（おそらく）経済的な基盤が上部構造へと波及していくのと同じように（違うか？）文化的な行為となる。なぜアメリカは基底からやって来る沢山のボーカロイド曲を持っていないのか？ その理由はもう挙げているな……（１）なぜならdirty anime hentaiだから（２）アメリカにいるデスクトップミュージック人種はテレビゲームと映像作品に集中してやがるから。
http://www.imdb.com/title/tt0132477/
http://en.wikipedia.org/wiki/Base_and_superstructure
４． ２番目に上げたデスクトップミュージックの問題は重要だぜ。もしお前が独立した作曲家としてメシを食っていきたいのなら、お前の時間と貴重な音楽的アイデアをボーカロイドのように不安で子供じみた音に賭けてみようなんて考えは二度と起こさないだろう。そいつは正直、新しすぎる。西洋諸国は上出来なデスクトップミュージックを作っている。問題は、ボーカロイドは今も、そしておそらくは長期にわたって、もしかしたら決して、独立したアーティストにとって頼れる収入源にはならないってこと。たとえそれで生計を立てる気がないとしてもだ。アメリカでボーカロイドは、他のデジタル関連のインディー業界のように花開くことはできるのか？ アメリカのボーカロイドが日本のdoujin業界のようになるにはどうしたらいいんだ？
http://anond.hatelabo.jp/20110707195830
初音ミクLAライブ、外国人感想その２「再生の約束」フリーダム訳
http://anond.hatelabo.jp/20110708223459
初音ミクLAライブ、外国人感想その３「ミクノポリスのボカレタリアートたちよ、団結せよ！」
http://anond.hatelabo.jp/20110709211718
初音ミクLAライブ、外国人感想その４「仮想の歌姫：初音ミクの人気と未来の音色」
http://anond.hatelabo.jp/20110710234300
初音ミクLAライブ、外国人感想その６「ミクノポリス：７月のクリスマスと世界征服」
http://anond.hatelabo.jp/20110712205546
初音ミクLAライブ、外国人感想その７「AX11：ミクノポリスの印象」
http://anond.hatelabo.jp/20110713211501
初音ミクLAライブ、外国人感想その８「ミクノポリス：コンサート・リポート」
http://anond.hatelabo.jp/20110714210122
初音ミクLAライブ、外国人感想その９「アニメ・エキスポ：初音ミク」
http://anond.hatelabo.jp/20110715222900
初音ミクLAライブ、外国人感想その10「アニメ・エキスポ2011（抄訳）」
http://anond.hatelabo.jp/20110716194029
初音ミクLAライブ、外国人感想その11「世界は彼女のもの：初音ミクはいかにして全てを変えたのか」
http://anond.hatelabo.jp/20110717201147
初音ミクLAライブ、外国人感想その12「アニメ・エキスポ2011でのボーカロイド体験」
http://anond.hatelabo.jp/20110719031316
初音ミクLAライブ、外国人感想その13「ミク：日本のヴァーチャル・アイドルとメディア・プラットフォーム」
なんか今日のツイッターのTLをチラ見してたらFacebookがやたらHOTになってたので一言。
なんでかって？
ミクシィ（）笑があるから。
GREE（）があるから。
なんでかって？
一部のネットジャンキーや情報強者様達は新しく生まれてくるウェブサービスやトレンドに敏感で、
それらに飛びついては居心地が良いところを探し、一定以上定着すると次を探し求めて行く。
一方で情報弱者な日本の一般ユーザは、マスメディアで取り上げられて、話題の的にされたものじゃないとまず使わない。
ツイッターも最近になりようやくマスメディアに取り上げられることも増えたけど、それでも日本でのアクティブユーザが
爆発的に増えたかというとそうでもない。そしてコア利用者層と違い、それらの人々はクライアントを使わない（クライアントの存在を知らない）
ツイッターはクライアントがあって初めて使いやすいウェブサービスとなる。正直ウェブや携帯ウェブからは使いにくい。
けれど、最近のメディアの流行に乗せられて始めたような人はウェブや携帯ウェブから利用している程度である。
日本の一般ユーザはそれを「使いづらい」ままだと認識し、しばらくすると彼らはそのまま去っていくだろう。
クレームを入れる人もいるかもしれないが、サポート画面やサポート問い合わせ先が英語となるとそこで躊躇して
送るのをやめるものもいるだろう。
先ほどのmixiやGREE、モバゲーはマスコミの力を利用しつつ、さらに日本の一般ユーザがよく利用するシーンに合わせて、それらから
より最適に使いやすいように最適化したものをサービスインタフェースとして提供している。
さらに、日本企業が経営しているので、サポートももちろん日本語、クレームも言いやすいのでバンバンクレームを入れる。
日本人の一般ユーザにまだまだIEユーザが多いように、日本人はデフォルトのまま、慣れたものを利用しようとする。
その中でさらに使いやすいものを取捨選択していくので、海外のサービスは日本の一般ユーザまでになかなか浸透しづらい。
そうすると、Facebookが日本でも流行るという流れは、ごく一部については一時的に流行るだろうが、そこまでにとどまり、
広く一般には広まらずに沈下していくのではないかなと言うのが今の考え。
そんな上司がいる。
社員同士非常に仲がよく、私の入社と同時ぐらいに第1次twitterブームが着たので、若手はすぐにそこでつながっていた。
twitterでの話題は、大学関係者とも関わることが多いので教育的な話から、コードのことであったり、最新インタフェースのことであったり、ネタやプライベートな話まで
まぁ初期ユーザに一番多い使い方をしてきたのだと思う。
一方、その上司は3、4年前から今の会社にやってきた。現在、40代前半。
上司が転職してきた直後は別のチームにいたから全く関わりがなかったが、1年前から新たなプロジェクトとして同じチームに編成された。
前いたチームの同期からの評判もよい人だった。
上司がtwitterを始めたのは、ちょうど1年前くらいのtwitterがメディアでかなり取り上げられてきた時だったので、誰かが上司さんもやってみたらいいじゃないですかーとでも言ったのだろう。
あっさりその上司はtwitterにはまり、職場の人から大学時代同期の研究者だったりをフォローして楽しんでいた。
そうすると、職場でもtwitterの話をするようになっていて、「~さんこの前twitterで言ってたあれどうなったのー?」なんてことを上司が聞いたりしていた。
それまでは職場でtwitterの話題をすることはなく、最初は私も合わせていたが、その上司にかなり気に入られたらしい私は、特にtwitterの話をされることが多く、次第にエスカレートしていった。
随分前に私が会社での飲み会について投稿したことをネタにしてきたりもした。
その飲み会には上司もいたし、投稿をみればなんの話かは分かるだろう。しかしその投稿をした時はまだ上司がtwitterを始める1か月以上前だった。
上司は、あっさりと「君のつぶやき読めるだけ読んだんだよねー」と認めたし
「あれって、"more reading"し続けるとページ重くなって全部は見れないんだねー」とケラケラ笑いながら言うし、その後ももっと前の私の話をネタにして話続けることもしばしばあった。
さらには、別クラスタでフォローしてる子と私のリプライのやり取りの話までしてきた。つまりは私のprofileページをチェックしているということだ。
別に読めるようにしているのだから、昔のを読むことは文句言えなし、読むなとも思わない。
しかしそれはこっそりやってほしい。よりによって本人に告げるな。
webでも現実世界でも同一人物であることは本人も認めているわけだけれど、私はやはりネットとリアルは異なるものと捉えている。ネットという画面を通したものだからこそリアル世界で知り合ってる人とも向き合えることがあると考えている。
今まで、webでのルールなんて意識したことなかったけれど、あぁ実は自分にもwebルールがあるのだとまざまざと実感した。
上司には、私や若手が持つそんなweb概念が全くない人だった。
こんなことがずっと続き、少し私が嫌がっているのも気にせずtwitterの話ばかりされるのが本当につらくなってきたので、上司とは徐々に距離を置くことを決めた。
ネットとリアルの区別がつけられない人だからリムーブしただけで傷つくだろうなと思い、フォローはしたままで、仕事としては全く悪い人ではないので、ただ表面上仲良くし、飲みに誘われても断っていた。
どうやら、その時点で上司はひどく傷ついていたらしい。さらにひどい事が起きた。
その頃私は、プライベートなことで深く悩んでいて、ネガティブな発言が多かったし、誰とも分からないように人を批判する分を投稿していたりした。
できるだけ一般的な話に持ち込むようにはしていたけれど、感情的な部分もあったのかもしれない。
なんと、上司はそういう私の一連の投稿を、自分のことについて書かれたと思ったらしい。
長期休暇などもかぶりしばらくぶりに上司に会う日があった。
廊下で会っても無視するくらいの機嫌の悪さ。
なんだ?と思っていたら上司に個室に呼ばれた。
すると、上司は私のその問題のついーとをプリントしたものを数枚もってて、いきなり目の前のデスクにその用紙を投げ出し「これはないよね」と言い放った。
初めて空いた口が塞がらなかった。
はっきりいって、そんなことを投稿してる間、上司のことは微塵も考えていない。完全にドン引いた。
仕方がないのでその投稿をするに至った経緯まで全て話、関係ないことを主張し、なぜか上司がうなだれていた。
そして私が避けていることが気になったようなので、さらに自分のwebの使い方と上司のwebの使い方の違いを説明し、
ネット上の話をされるのは私はつらいとだけ訴えた。
これが約半年前。
その時上司は分かったとは言っていたが、現在もなにも分かっていない。
落ち込んだ投稿をした時は、一緒にがんばりましょうというDがきた。
つい最近もまた思わず愚痴っぽいきついことを書いてしまったら、
ボクだって努力してるんですというDがきた。
だからお前のことじゃねーよ、親とのことだよ
「だからといって、人がどういう考え方をしていても勝手で、使い方を他人に強制されるようなものではない」と上司は言った。
確かにその通りである。
上司のようなネットの使い方をして、自分が傷ついたんだ!ってことを相手に伝えれば、そっちだってある程度もしくはそれ以上の傷を被る。
相手にそんな傷をつけた時点で、自分の使い方を強制したことになっていることを上司は気がついていない。
それだってその通りである。
でも上司には「受け手側はそれをどう受信したかの責任は自分で持つべき」と言いたい。
私の発言が軽薄な時も確かにあるかもしれないが、鬱ポストを連発するわけでないし、個人を中傷したポストをしているわけでもない。
流そうと思えば流せるものを真に受け止めるのは、その受け手だけで留めてほしい。リアルにまで持ち込み、他者を責めるな。
彼ら彼女らは、どうしてそんな自分が不幸になるような使い方をするのだろう。
ネットでは発信者の状況は分からない。それなのにどうしてそれを真に受け止めて、ネットがつらくなるような使い方をするのだろう。
しかしそういった人達は一定数必ずいる。
結局はtwitterもまた一部の人の利用に留まっていくだろう。
すばらしいツールなだけに、そういった考え方をする人達のせいで広まらなくなるのならなんとも勿体ないことだ。
しかしもっと勿体ないのは、ネット上で実力を発揮している人がそういった人達のせいで姿を消していくことにある。
素晴らしい人がひとり姿を消せば、このweb上の可能性も同時に一つずつ消えていく。
ネットとリアルを区別しない人達による罪というのは実は予想以上に大きい。
今でも上司とのフォロー関係は続いている。恐らく今後も変わらない。
確かにめんどくさくなる時もあるけれど、折角いいツールを見つけ、いい人達とも巡り会えたのに、やめたくはない。
自分がweb界にいつか影響をもたらすとは思いもしないが、確実にそんなやつらよりはいい使い方をできる気はする。
なのでなにがあろうともやめることはない。
中央官庁での経験からいうと、基本的に省内文章のほとんどは電子化されてるし、電子文章のシステムも年々地道に改良されてる。省庁間を横断した電子文章システムの登場もスケジュールに入ってる。でも対外的な「文章」のインタフェースは結局紙にはんこ押した奴しかない。なので外に対して出す文章や、外から入ってくる文章はどうしても電子化できない。
これを全部電子化しようとすると、役所とか役人とかそういうレベルじゃなくて、日本中の公文章のやりとりを全部電子化するぐらいの勢いが必要。企業の社印が入った文章とか、個人が役所に出す書類とか、そういうのが全部電子化できる状態まで持って行かないと意味がない。
そのコストが本当に支払うのに足るものなの？現状でもそれなりに回ってるのに。
総務省が掲げる霞が関・自治体クラウドの計画が本格的に動き始めた。同省は2009年8月10日、「政府情報システムの整備の在り方に関する研究会」の中間取りまとめを公表した（資料はこちら）。これは、2015年の本格稼働をターゲットとして、府省の情報システムの将来像を描いたものだ。これによると、現在は府省ごとでバラバラに構築・運用している情報システムのうち、共用可能なものを霞が関WAN内のデータセンターに集約する。その際に、基盤となる「政府共通プラットフォーム」を開発。この上でアプリケーションをSaaS（ソフトウエア・アズ・ア・サービス）形式で利用する。政府共通プラットフォームには、府省間で共通利用するデータを連携する機能も含まれる（図1）。この政府版プライベート・クラウドが、霞が関クラウドの実態である。
府省横断の業務改革が不可欠に
この取り組みで重要なのは、どれだけアプリケーションを共用化できるかという点だろう。府省ごとに利用しているアプリケーションをそのままSaaS化するだけでは、単にWebアプリケーションのホスティングにすぎない。システムだけの統合・集約に終わらずに、業務プロセスの統合・集約、すなわちシェアード・サービス化にまでつながらなくては、大きなメリットを得ることはできない。
そのためには、府省を横断した業務の標準化が不可欠となる。中間取りまとめでも、業務の見直し（BPR）を課題として掲げている。しかし、その道筋は見えてこない。中間取りまとめの資料には、2009年度から2015年度までのスケジュール（予定）が掲載されているが、業務の見直しに関連するような工程は2010年度中の「要件定義」と「最適化計画策定」の2つだけだ。府省横断で業務を改革した上でシステム要件を定義するまでを、1年足らずの期間で完了できるのだろうか。
短期間での業務改革を実現するためには、強力なリーダーシップが必要だ。府省を横断して大なたを振るえるとしたら首相しか考えられないが、総選挙を間近に控えた今、実働部隊となるプロジェクトメンバーを選ぶことさえもままならないのではなかろうか。
一方の自治体クラウドも実現へ向けて大きく動き始めている。総務省は2009年7月17日、「自治体クラウドに係る開発実証団体」の募集を開始。実証実験に参加する都道府県を募り始めた（資料はこちら）。都道府県CIOフォーラム（詳しくはこちら）の事務局を務めている日経BP ガバメントテクノロジーでは、8月のフォーラム開催に向けて事前アンケートを実施しているが、実際にいくつかの都道府県が実証実験に参加する予定だと回答している。
自治体クラウドは、自治体専用のWANである総合行政ネットワーク（LGWAN）内にあるデータセンター（3カ所の予定）に市町村のシステムを統合・集約する取り組みである。市町村レベルでのシェアード・サービス化ととらえることできる。市町村の場合は、それぞれが同じような住民サービスを提供しているため、シェアード・サービスに向いているといえる。
理想論でいえば、全国の自治体が利用するシステムを統一すれば、コスト面で大きなメリットを得られるし、ガバナンスを効かせやすいというメリットも生まれる。しかし、アプリケーション（あるいはSaaS事業者）の品質を維持できるのかが見えない、地域特性による個別のサービスが提供しにくい、あるいは地場のITベンダーが育成できないなどデメリットも少なくない。実際、総務省の実証実験では、ASPやSaaSは自治体側が選択できるようにしてある。自治体クラウドは当面、都道府県単位のシェアード・サービス化ということになりそうだ。
ただし、都道府県単位でバラバラの仕様のシステムを作るわけではない。自治体クラウドの要件の中には、「自治体クラウド連携インターフェイス」というものがある。これは、アプリケーション間でデータを連携するためのインタフェースで、将来的には都道府県間の連携も見据えたものになっている。
とはいえ、都道府県を横断したアプリケーションの共用化は容易ではないだろう。都道府県をまたいで業務を標準化しなければならないからだ。自治体クラウドと霞が関クラウドの両方に共通することであるが、IT面での研究や実証・分析に偏らずに、業務の標準化にも力を入れていかなければ成功はおぼつかないだろう。というよりも、IT面の実装よりも、業務の改革・標準化のほうがハードルが高いのではないだろうか。
（吉川 和宏＝日経BP ガバメントテクノロジー） [2009/08/21]
http://itpro.nikkeibp.co.jp/article/Watcher/20090818/335667/
Twitterやはてブは印象を投影するには便利なメディアだけど、議論するには不向きだから仕方ない。
百数十文字では説明し切れないことなんか世の中いくらでもある。現実世界は善悪二元論みたいなシンプルなものではないからだ。
特にTwitterは同じテーマに対して複数投稿できるため一見長文の議論も可能なように思えるものの、標準的なインタフェースではつぶやき間の相互関係を判断することは非常に難しく、単一のつぶやきで完結していない発言はその可読解性は著しく低くなるのが現実だ。
例を挙げてみよう。
「写真の空に星がない、真空なのに旗がはためく、影の方向がバラバラ、背中にワイヤーが見える、岩に大道具の証拠の文字がある、月の石は地球の石と同じだなど、アポロの月着陸が捏造だったことを示す証拠は山ほどある。工作員が月に行った証拠を何一つ出せないのが何よりの証拠。」(140文字)
今でこそアポロ捏造説はFAQとして整備され、そこへのポインタを示せば大体おわる話だが、同程度の難易度の新規の問題だとしてみよう。この発言に対する反論を、この陰謀論者本人は別として、大多数に納得できる形で提示することができるだろうか。
blogなら相手の言う「証拠」をひとつひとつ検証して、ソースとなるURLを複数出して、必要なら図で説明して、客観的に納得できるレベルのものを提示できる。だがTwitterやはてブではこれは不可能といっていい。
諸兄はアポロ陰謀説ならまだアメリカ帝国主義者（？）が恥をかくだけで済むから無視すれば良いと言うかもしれないが、では個人攻撃をしてくる輩がいたらどうすればよいのか。(炎上するから無視しろというのは一見識だがここではおいといて。)blogの真面目な文章に対してはてブやTwitterでレッテル貼って一方的に決めつけた内容で個人の人格まで攻撃してくる輩なんか掃いて捨てるほどいる。印象で攻撃するなら短い文章で楽勝だが、真面目に客観的に反論すればするほど文章は長くならざるを得ない。それを常に140文字で反論し釈明し誤解をとかねばならないとか言うのであればあまりに一方的だ。
むしろ、短いつぶやきでなんでも解決できるなんて世界を過剰に簡単に考えてたり、一方的で野放図なつぶやきを不可侵で免罪されたものにしようとしたりする言論統制的な発想のほうが問題あるんじゃないか。
・その人材を適所にあてはめる。
・人々の士気を保つ。
・チームの結束を強め、維持する。
（それ以外のことは全部管理ごっこ）
・変更は、あらゆるプロジェクトの成功のために（ほかの大抵の物事についても）必要不可欠である。
・人は安全だとわからないと変更を受け入れない。安全が保証されていないと、リスクを避けようとする。
・リスクを避けることは、それに伴う利益をも逃すことになるため、致命的である。
・人は、面と向かって脅されたときはもちろん、自分に対して不当に権力が行使されるかもしれないと思ったときにも、安全ではないと感じるようになる。
・脅迫は、結果を上げさせる手段としては不完全である。
・どれほど強い脅しをかけても、最初に割り当てた時間が足りなければ、やはり仕事は完成しない。
・さらに悪いことに、目標を達成できなければ、脅迫の内容を本当に実行しなければならない場合もある。
・管理は心、腹、魂、鼻でやるものだ。
つまり……
心で指揮をとる。
自分の腹を信じる（直感を信じる）。
組織に魂を吹き込む。
くだらないものを嗅ぎ分ける鼻を持つ。
・戦闘が始まるときには、管理者のほんとうの仕事はもう終わっている。
・採用には、管理に必要な身体の器官、心臓、魂、鼻、腹をすべて使う（しかし、腹が大部分だ）。
・一人でやろうとするな。二つの腹には、一つの腹の２倍以上の力がある。
・新しく採用した人材には、１回は実証済みの能力レベルのプロジェクトを任せ、ほんとうに目標を拡大するのは次回とする。
・意見を求めよ。最も採用したいと思った人物は、ほかの優れた人材を知っている可能性が高い。
・話すより聞け。
・これらのことは、下準備をしておけばさらに効果がある。
・短期的に生産性を高める方法などない。生産性は、長期的な投資によって向上する。
・短期的な効果を約束するものは、いんちきである可能性が高い。
・やる気のある態度を常に引き出そうとしない人物をリスク管理人に任命せよ。
・悪い話が上層部に伝わりやすい経路（匿名性など）を作っておくこと。
・無駄を減らす。
・成功を最大化するより、失敗を抑えることによって、全体的な成績を高めることができる。
・失敗した作業は早く打ち切る勇気を持つ。
・チームの結束については必要のない賭けはしない。既存のチームを探して利用する。
・結束の遅い、または結束しないチームのために後継者が困らないよう、優れたチームは維持する（本人たちにその意思があれば）。
・新しい仕事を引き受ける意欲のある結束の固いチームは、プロジェクトの成果の一つと見なす。
・プロジェクトの初期にむだにする一日も、末期にむだにする一日も等しく打撃になる。
・一日をむだにする方法はいくらでもある……しかし、一日を取り戻す方法は一つもない。
・仲間との対話の中で、プロセスの進行に関する考えを伝えたり修正したりするためにモデルを使う。
・実際の結果と照らし合わせてモデルを調整する。
・いつでもクビを賭ける覚悟が必要である。
・しかし、それでも病んだ政治の影響を受けないとは限らない。
・病んだ政治はどこにでも、最も健全な組織にも出現する可能性がある。
・病んだ政治の決定的な特徴は、個人の権力と影響力の目標が、組織の自然な目標より優先されることである。これは、病んだ目標が組織の目標と相反する場合でも起こりうる。
・病んだ政治の副作用の一つは、少人数のプロジェクトを抱えることが危険になることである。
・すべての製品のサイズを測定せよ。
・単位を気にするな。客観的な尺度ができるまでの間は、主観的な単位を使えばよい。
・手に入るすべての基本要素（ソフトウェアの数量化可能な特徴）をもとに合成尺度を作成する。
・考古学的データを収集し、これまでに完了しているプロジェクトから生産性の傾向を算出する。
・合成尺度の公式をいじり、その値と、考古学データベースのプロジェクトの労力の相関関係が最良になるポイントを見つける。
・過去のデータベースをもとにトレンド・ラインを引き、予想される労力を、合成尺度の値の関数として示す。
・つぎに、予想を立てるべき新規プロジェクトのそれぞれについて、合成尺度の値を計算し、それを使ってトレンド・ラインから予想される労力を割り出す。
・生産性トレンドのノイズのレベルは、予測を立てるときの誤差の目安にする。
・優れたプロセスと、プロセスを絶えず改良することは、立派な目標である。それらはまだ、ごく自然な目標でもある。優れた技術労働者は、指示があろうとなかろうと、それらに焦点を当てる。
・形式的なプロセス改良プログラムには時間と金がかかる。一つのプロセス改良プログラムのために、プロジェクトが交替することもありうる。生産性の向上が実現したとしても、そのプログラムを受け入れたプロジェクトでプロセス改良の為に費やされた時間を相殺できる可能性は低い。
・プロセスは、注意深く選んだ一つの手順改良によって、その変更に投資した時間と金に報いるだけの利益を期待できることがある。
・プロジェクトの期間中に二つ以上の手順改良に順応することは、現実には期待できない。複数の技能改良プログラム（たとえば、全般的なＣＭＭ等級の引き上げ）は、プログラムを実施しなかった場合に比べ、プロジェクトの完成を遅らせる可能性が非常に高い。
・標準的なプロセスの危険な点は、人々が賢明な省略を行う機会を失わせることである。特に、人員過剰のプロジェクトの場合、標準的なプロセスによって全員に行き渡るだけの仕事（役に立とうが立つまいが）が発生するなら、標準的なプロセスが厳密に守られてしまう。
・デバッグの時間を大幅に減らさなければ、プロジェクトの成績を通常より大幅に高める方法はない。
・優れたプロジェクトは、デバッグに費やす時間の割合がはるかに低い。
・優れたプロジェクトは、設計に費やす時間の割合がはるかに高い。
・相手を好きになり、気遣わなければ、人に違うことをさせることはできない。相手を変えるには、相手の考えていることとその理由を理解し、尊重しなければならない。
・プレッシャーをかけても思考は速くならない。
・一時的なプレッシャーや残業は、人々の商店を定め、その仕事が重要であるという認識を高めるには有効な方法かもしれないが、プレッシャーをかけすぎると、かならず失敗する。
・管理者がプレッシャーを使うことが多いのは、ほかになにをすればいいのかわからないから、または、ほかの方法の難しさにひるんでいるからである。
・おそるべき推測：プレッシャーや残業を使うほんとうの理由は、プロジェクトが失敗したときにごまかすためかもしれない。
・管理者の怒りと侮辱は伝染する。上の管理者が怒鳴ると、下の管理者も同じような行動をとる（虐待された子供が自分の子供を虐待するようになるのと同じ）
・管理者が部下を侮辱すると、それが刺激となって部下は自分の仕事にされに力を注ぐと思われている。これが、「飴とムチ」式管理で最もよく使われる「ムチ」である。しかし、侮辱によってだれかの業績がよくなるという証拠はあるのか。
・管理者が部下を刺激するために侮辱を使うことは、部下ではなく管理者の能力不足のしるしである。
・仕様書があいまいなのは、システムの利害関係者の間で対立が解決されていないしるしである。
・入出力の完全なリストのない仕様書は、見込みなしである。使用を明確にする最初の一歩にもならない。
・仕様書がお粗末だとはだれも言わない。自分のほうが悪いのだと思い込みがちである。
・開発に複数の当事者が関わっている限り、利害の対立は避けられない。
・システムの構築と導入の事業には、特に対立が多い。
・対立は尊重すべきである。対立はプロらしくない行動のしるしではない。
・全員の勝利条件を尊重することをあらかじめ宣言しておく。あらゆるレベルで勝利条件を引き出すようにする。
・勝利条件が相容れないか、または部分的に相容れない場合でも、関係者が対立解決の為に仲裁に移行するように、あらかじめ準備しておく。
・注意：われわれは味方どうしである。敵は問題そのものだ。
・触媒のような人格というものがある。そのような人は、チームがまとまって結束し、なおかつ健全性と生産性を維持できるようにすることでプロジェクトに貢献する。触媒がほかになにもしなかったとしても（通常はほかにもいろんなことをするが）、触媒の役割は重要で貴重である。
・仲裁は、触媒の役割の特殊なケースである。仲裁はわずかな投資で学習できる。
・「あなたたちの仲裁をさせてもらえますか」というささやかな儀式の開始が、対立解決の本質的な第一歩になることがある。
・致命的なのは知らないことではない……知っているつもりで、実は知らない何かだ。
・初期に人数が多すぎると、プロジェクトは重要な設計作業を省略せざるをえない（全員に仕事を与えるため）。設計が完成する前に大勢に仕事を割り当てると、人や作業グループの間のインタフェースを最小化できない。
・このため、相互依存性が高まり、会議が増え、やり直しが増え、フラストレーションがたまる。
・理想の人数配分は、プロジェクト器官の大部分を少人数のコア・チームで行い、プロジェクトの終盤（プロジェクト器官の最後の６分の１ぐらい）に人数を大幅に増やすというものである。
・おそるべき推察：無茶なスケジュールを達成するように決められたプロジェクトは、妥当なスケジュールで開始されたプロジェクトに比べ、完成までに時間がかかると思われる。
・会議は、重要ではない人物が出席しなくても心配のないように、小さくする必要がある。欠席者が安心するための最も簡単な方法は、議事予定表を発行し、それに厳密に従うことである。
・プロジェクトには儀式が必要である。儀式は、小規模な会議や無欠点運動など、プロジェクトの目標と理想に目を向けるために使う。
・罵倒などの怒りから人々を守るために手を打つ。
・注意：怒りは恐怖である。部下に対して罵倒などの怒りの行動をとる管理者は、ほとんどの場合、怖いからそうしているのである。
・考察：怒りが恐怖であることをすべての人が理解すれば、怒りは、怒っている人が怖がっていることを明確に示すシグナルとなるだろう。起こっている人は、恐怖を表に出したくない。つまり、怒りが恐怖の表れだとみなにわかってしまったら、怒りを吐き出すこともできなくなる（これは怒っている人の問題は解決できないが、ほかの人の悩みは軽減できるだろう）。
・病んだ政治を下から治療することはできない。むだな努力で時間を浪費したり、自分の立場を危険にさらす必要はない。
・問題が自然に解決するか、行動するチャンスが来るのを待つしかない場合もある。
・奇跡が起こることもある（だが、あてにしてはいけない）。
・倹約精神とは、失敗した企業の中で、その失敗の責任者が作った公式である。
・それは、組織の自然な目標である繁栄と福祉の精神とは正反対である。
・「倹約精神」という言葉を聞いたら、その本当の意味である「失敗と恐怖」に置き換えるといい。
うちのカーチャンは賃貸の会社に勤めてた関係で、不動産関係が趣味。趣味ってのは買ったり売ったりをしているわけじゃなくて単に不動産関係だと興味津々で読みふけったり話したりずーっとできるというかしたがるとかそういう方向性。まぁ、それはいいのよ。個人の趣味だし、何かに熱くなれるってのはそれだけで良いことだと思う。
で、カーチャンはパソコン関係は弱くて、インターネットという単語は知ってるけれどブラウザという単語は知らない、程度の人間なので、「ねぇねぇ、インターネットで不動産とか見られるんでしょ」みたいな事を言い出したり、「このストリートビューって凄いわね。家の概観をこんな風に眺められるなんて」みたいな感じではしゃいだりする。なんとも微笑ましい。
ということで、俺としては不動産関係の記事とかを見かけたときに、これ教えてやったらカーチャン喜ぶだろうな、とか思って、家に帰ったときにその記事を読ませたりする。で、そういうのを何回か繰り返した後、いちいち家に帰ってからでないと見せられないとか、ノートPCでそのページを開いてからカーチャンみ見せるだとかいったことをしているのは非効率的であるという気持ちが爆発したので、カーチャンにgmailのアカウントを取らせて、今度からはこっちにmailするので読んでね、と、loginの仕方を教えたり読み方を教えたりした。
で、一つ目。
カーチャン、gmailのインタフェース(参考)だと個々のmailのSubjectの部分をクリックするんじゃなくて、その左側にあるチェックボックスをクリックするのよ。冷静に考えればそりゃそうだよね。ボタンに見えるのはそのチェックボックスしか無いもの。どう見てもただの文字列でしかない所なんてクリックしないよ普通。これ、3,4回言ったのだけれどまだ理解できないようで、一人では読めないのよと言われる。教え方がまずいのだろう。努力しよう。
んでまぁ、そういう問題は沢山あるうちの一つなのだろうからまぁ、慣れてもらう方向でいいや、と思ったのだけれど、URLをクリックした後にblogとかにぶち当たるともう駄目。
これが二つ目。
最近のblogって右にも左にも上にも、広告がはりついてるじゃん。特に上方向の広告、これがなんというか駄目。イカン。カーチャンに与えているノートPCは画面が横に長いというか縦が短いから、画面には広告だけしか映ってなくて、下にスクロールしないと記事が出てこないような所なんてのもある。そうなっちゃうと、それらの広告を読まなきゃいけないもんだと思って端から読んじゃう。そういう広告がいっぱいあるから、本文をまず探すんだよ、って言ってあってそういうことも理解してもらってるつもりなのだけれど、やっぱり目に入っちゃうからか、気になって読んじゃうみたい。で、記事本体にたどり着けなくて、「面白くないわね」になってしまう。
まぁ、他にもいろいろあったりするのだけれど、それは置いておく。でも上に挙げたようなものは、どちらかというとデザインが悪いとかそういう話なんじゃないかなぁとか思ったので愚痴ってみたかっただけです。にしても、単にURLを送ってその中身を見て欲しいだけなのに、それを完遂するための障害がこんなにも多いとは思ってもみなかったんだよなぁ。やれやれ。
今、日本のプログラマの多くが「休業中で自宅待機」のはずなのに、あまり語られていないので、俺が語ってみる。
---
今、壊滅的に仕事が無い。仕事が無いけど社員はいる。社員が会社にいると給料を払わないといけない。
クビにでもしないと会社は破綻する。しかしクビにしたら中小企業は立ち直る体力が無くなる。
よって。
社員を休業中にする事。休業なので、自宅待機。そして給料を６割まで減らす。休業にした社員の分、国が会社に助成金を出す。
---
よって、かなり多くのプログラマが休業中、自宅待機のはず。なのだ。
俺のつとめてる会社は中小なので、社長と直で話す事は多いし、社長は顔が広いので他の中小企業の社長がよく来る。
なので中小企業のソフトウェア会社の社長達の話を聞く事があるのだけど、今の日本、中小ソフト会社は社員半分以上が自宅待機なんてザラらしい。
---
つまり今、ものすごい数のプログラマが自宅待機している。
はずなのだ。
が。
全然それをネットで聞かない。
---
プログラマ大量自宅待機が始まったのは３月末ぐらいから。３月決済に合わせる為に、企業はこぞって外注なり契約なり派遣なりを切って切って切りまくった。３月を過ぎても切りまくった。５月になっても仕事は増やさない。
俺が外注してた会社なんて「外注０％を目指す」なんてすごいキャッチコピーを掲げていた。つまり「引継ぎ期間をどれだけ短くするのか」という事だ。「継続」は無し、社員だけで何とかするという話。
最初からそれが出来るならしてるわけで、今頃は大量に心に闇を抱えた社員を作り出しているに違いない。
---
俺は自宅待機中何をしていたのかというと、こんな時期に引越しをしてしまったので、引越しの手続きにほぼ追われていた。
それでも空いてる時間はある。そういう時は同人作家なんてものをしているので、新作を作ったり、広告用に絵を描いてネットにアップしたりした。
普通ならプログラムの技術を学ぶだろう。でも、俺はそれを無駄と感じていた。
何となく予感がしているのだ。プログラマじゃ食えなくなる時代がすぐそこまで来ていると。
プログラマとしての腕は自信がある。でも、腕があってもしょうがない。
仕事が無いのだ。
今回の強引な外注切りを見て思ったのだ。企業の偉い連中は金しか見ない。外注より、株主の声の方が怖いのだ。
今のご時世、株価が下がるのは当たり前なのに、株価が下がるのを恐れて決済の数字の辻褄あわせで外注を切る。切ったら立ち行かなくなるプロジェクトだろうが何だろうが切る。
そして数字だけ見れば、インドや韓国に頼んだ方が安い。当然ものすごい不具合、あり得ないインタフェース、信じられないクオリティのモノが出来上がるだろうが、モノが出来ればいいと考える企業の頭は「それでよし」と思うだろう。
---
さて、プログラマが暇になってネット上でゴロゴロしているはずのこのご時世。
そんな方々の話はネットでは全然出てこない。
おかしい。
どうなってるんだろう。
俺みたいに、別の道を考えているのかも知れない。
---
web系は確かに人が足りない状態らしいが、家電などの組み込み系全般、サーバ系、ルータなどネットワーク機器、などは殆ど仕事が無い状態。保守なんてほぼ全滅。
他の人もレスで書いてるが、ドライバ系などの腕の見せ所っぽい場所こそ仕事が無い。LinuxでもWindowsでも、メーカー提供のドライバなんて読みにくい上に不具合があって当然な上に、緊急度は高いものばかり。そういう問題をチャチャっと解決できてしまう人というのは限られるよ。そういう腕を持った人でさえ、バリバリ切られてる。
一言でプログラマと言っても分野が多いので、自分が聞かないからと言って無能扱いしない方がいい。いや、俺は無能扱いされても無名の増田だからしょうがないが、世には有能でも仕事が無い、尊敬すべき腕を持ったプログラマが山ほどいるのは確かなので。
つまりソフトウェア工学の基礎（二分探索だとかみんな最初に習ったよな？）やハードウェアの知識が何もない状態にSQLやルーティングプロトコルについて知識を詰め込み、現場に出している。
そうは言うけど、その即席NEが実際にルーティングプロトコルについて詳しいかと言ったら、そんなケースまず無いよ・・・・
数学（特にグラフ理論）を勉強したことが無い人間が即席NEになると大抵OSPFやスパニングツリーで戸惑ってる。
理解しているのはユーザインタフェースの操作体系ぐらいでパケットキャプチャとかをお願いすると大抵悲鳴を上げている。
NEを名乗ってるのにWindowsも知らなければLinuxも満足に触れない（エディタもtcpdumpも知らない）わけだからそもそも詰め込み教育すら功を奏していないと思うんだけど。
でも、会う人会う人が「なんでそんな高いの買ったの？ワンセグ見れないだろ？」と聞くのはなぜですか。
インタフェースの研究をしているので、最新の機器に興味があるのさベイビー。と、花輪君のふりしてやり過ごしています。
もっとよい返答はないものか。
言われる言われるｗ
そんなときはシャキーンと取り出して、リッピングしておいたDVDなんかを見せつけてます。
特に洋画なんかが好評で、字幕がちゃんと読めるのに感心されたりします。
一時期YouTubeを見せたときがあったのですが、ダウンロードのもっさり感でじゃっかん受けが悪かったです。
そうそう、シャネルとかのAppだと動画が綺麗に入っていて、ファッションショーの写真も豊富なので女子に自慢するときには使えます。
#「なぜこんなの入れてるの？」と逆効果の時もありますが。
##そんなときは「自慢するため」と正直に答えましょう。
今まで購入したiPod。
第4世代のiPod40GBと第1世代のiPod nanoの二台。
そしてiPhone3G。
でも、会う人会う人が「なんでそんな高いの買ったの？ワンセグ見れないだろ？」と聞くのはなぜですか。
インタフェースの研究をしているので、最新の機器に興味があるのさベイビー。と、花輪君のふりしてやり過ごしています。
もっとよい返答はないものか。
この会う人会う人の質問の「ワンセグ見れないだろ？」に違和感。
ワンセグってそんなに重要で、購入材料として考えるんだと思った。
まあ、ワンセグアダプタつければ一応視聴は可能だよね。
iPodの思い出を書く。
３年くらい前かな、弟がクラシックを買った。当時はナノがなく、名称がただのiPodだった。音楽プレーヤなんて興味はなかったが、カセット等を入れずに再生ってすげー！と思った。
１年くらいしたら、弟が小さいナノを買った。小さくなっちゃった。
半年ほど前、友人がシャッフルを買った。液晶なしってどんだけだよ。
先月、自分はiPhoneを買った。かっこいいと思ったからだ。
弟もほぼ同時期に新しいナノを買った。スマートだぜ。
勝った的な意味で買ったッ！
でも、会う人会う人が「なんでそんな高いの買ったの？ワンセグ見れないだろ？」と聞くのはなぜですか。
インタフェースの研究をしているので、最新の機器に興味があるのさベイビー。と、花輪君のふりしてやり過ごしています。
もっとよい返答はないものか。
そういうのはバッドノウハウとは言わないの？
関数ポインタをバッドノウハウとは言わないでしょ。C言語自体がバッドノウハウの結果だと言うなら、当たりだけど:)
手続き関数という抽象はまことに一般的な存在で（数学では汎関数というのもある）、それをC言語で直接的に表現したのが関数ポインタ。 関数的なものを オブジェクト指向言語でオブジェクトとして実装するほうがバッドノウハウだと思う。 少なくとも私は JavaのComparableインタフェースよりも C言語の heapsort/mergesort/qsort の関数引数 int (*compar)(const void *, const void *) のほうがシンプルで どちらかといえば本質をよりよく表していると思う。 なぜ関数的なものを表現するのに オブジェクトとかinterfaceとか継承とか「余計な概念」を導入する？それこそバッドノウハウでしょ。 まあでもC言語にはクロージャが無いから、関数的なものも扱いづらいことこの上ないが、Cにクロージャが無いこと自体はバッドノウハウとは言わないでしょー。
逆も然りで、オブジェクトを表現するために 関数を使ってれば そればバッドノウハウだけど、オブジェクトは関数ほど一般的な概念ではないと思う（オブジェクトなんか無くても別にいい、かも？）。
アプリ作者です。
ゲームの大まかな流れを説明します。
周辺の8つの数値のいずれかをドラッグして、
6つの演算子のいずれかにドロップすることで、
中央の数値とドロップした値との演算が行われ、
その結果が新たな中央の数値となります。
この演算を繰り返すことで、中央の数値を
targetとして表示されている目標値に近づけていき、
問題をクリアすると、次の問題に進みます。
演算子を周辺の数値にドラッグアンドドロップすることでも演算は行われます。
ある数値を他の数値にドラッグアンドドロップすると数値が入れ替わります。
こんなややこしい操作体系、何の説明も無しに分かるはずがないですね…すいません。
特に、ドラッグアンドドロップさせるというのは無理がありました。
できるだけ少ない操作で遊べるように、ドラッグアンドドロップ制を採用したんですが、
ドラッグ中に数字がポインタにくっついてくるようにする、などの画面効果は検討します。
それから、そもそもゲームが面白くないというのも致命的ですね。すいません…。
与えられた9つの値からより早く目標値を作り出すというところに、
パズル的な要素があるかなと考えたんですが…。
ほとんどが足し算と引き算で終わってしまう、とのことですが、
どうすればより早く目標値を作り出せるか、と考えると、
掛け算や割り算も必要になってくるかと思います…。
このような問題を解決する技能が他に使えるかどうか、という点については、
与えられた値からより早く目標値を作り出す過程を考える上で、
暗算を何度も行う必要があると思います。
それがいわゆる脳トレになるかな、と。
…今更脳トレも無いか。