  |
はてなキーワード: tddとは
相手の勘違いや、単純に忘れた等で、すっぽかされて、その場で時間が過ぎてから連絡を取って、しょんぼりすることが多い。
直前のドタキャンはまだともかく、連絡すらなくてこちらからするって相当でしょう？
相手は必死に謝っており、1年弱の付き合いで普段はこんなことない相手だとしっているので、こちらとしては、
いえ、いいんですよ、それでは明日会いましょう
くらいの感じで対応した。
これとは別の話として、友人と遊ぶときや、異性を食事に誘ったようなときも、すっぽかされたことがちょいちょいある。
それぞれに事情は聞いているのだけれど、事情・真相がなんであれ、
個別の事象はともかくとしても、人生においてこういうことに遭遇することが多いというのは、
今日、必死に謝罪する相手の言葉を電話越しに聴きながら、そんなふうに目の前の問題とはちょっと違うところで少し落ち込んだ。
私の容姿がフランシス・ガヌーみたいだったら、きっと違ったはずだ。
ガヌーはグラウンドに穴があるんじゃないかという意見がたまに見られますが、
カーティス・ブレイズとの試合を見ればわかるように、意外とTDDは良い動きをしており、TDされてしまった展開でも、すぐ立ててました。
また、この試合での2Rまでの動きを見ている限りでは、スタミナがまるでないタイプではないのも明らかです。
以前の試合では、スタンドでキムラをセットしてのサブミッション勝利という、意外な程の対応力も見せており、その上で彼のスタンドは恐ろしいの一言。
証明されていないものがあるとすれば、グラウンドでの柔術への対応でしょうけど、
あの程度のレスリングの対応力と馬鹿力があれば、穴があったとしても、ヘビーでは大抵の相手にはなんとかなるのでは。
そもそも意味あるのかちゃんと考えてる？
馬鹿じゃねーのかｗ？
テストコードのメンテなんてデバッグの手順書メンテしてるのと大して変わらねーよｗ
その単体テストが本番と同一の動作をテストできてる保証はねーって気づけボケが
それと「テストコードがあるから安全です」なんて寝言まだ言ってるの？
プロジェクトが進むにつれソースも依存ライブラリも変化する以上
いつも同じ結果になるわけじゃねーだろが、（保守しないって選択はあるけど金入ってこないだろ）
本番でもテストコード動かしますってやつら以外無理して単体テスト書く必要ないんじゃねーか？
お前らが欲しいのは軽いデバッグモードであって単体テストじゃねーだろ？
工数削って単体テストを書いてソースが変わったらエラーになるからテスト書き直して・・・ってどう考えてもお前らが望む世界じゃないんじゃねーか？
流行りのTDDするくらいなら新人にデバッグやらせた方がよっぽど筋がいい
というわけでよく考えなおせ
そうなんよね。金がありあまっててミッションクリティカルな携帯キャリアならではって感じではあったのでちょっと元記事のアドバイスとしては適切じゃなかったかも。
別記事で言ってたように根幹のチェックして検収OKでもいいとおもった。そのシステムのトレードオフどれくらい許容出来るかって感じで割り切りでいいと思う。
まるぱくりだけどKent beckのトレードオフの制約を貼っとく（TDDの議論で出てたものだけど受け入れテストにも適用できるとおもう）。
■ 頻度：どれくらいの頻度でフィードバックをもらいたいか？
■ 精度：レッド/グリーンのシグナルに求める精度はどれくらいか？
Qiitaに書こうかと思ったけど、言いたいことも言えない、こんな世の中じゃ。
モバイルファースト、APIファーストな文脈でハイブリッドWebをやってきた目からすると、サーバーサイドでHTMLを生成してページ遷移させるなどという90年代調のクラシカルな発想を基本に据えるフレームワークはとても斬新に思えました。HTMLをゴリゴリ生成するなんてよほど特殊な最適化をしようとするのでなければそもそも発想として出てこないです。それでいてDSLやメタプログラミング等のテクニカルな技法が宝石のように鏤められている様はまるでエジプト時代の骨董品を見るかのような趣がありました。turbolinkなどは、かつて表計算ソフトに出しゃばっていたイルカを思い起こさせる味があります。かつて慣れ親しんできたSPAが星のように遠い存在になりました。
Web界隈の人々がモデルだとかアクティブレコードだとか"MVC"だとかを非常に具象的に話す様を見るにつけ、お前らどんだけPofEAA読み込んでるんだよと畏怖していた時期が僕にもありましたが、どうやら彼等はRailsのクラスやディレクトリという特定の実装について話していただけだったようです。Modelという概念もこれだけ肥大化してしまったら、オリジナルな概念で彼等と会話するのは諦めるべきかなと思いましたし、Railsの"MVC"をアンクォートして語るのはもはや害悪であるとすら感じました。
Rails界隈の人がよく「Railsの流儀」や「正しい"MVC"」というのを口角泡を飛ばして議論しているのを目にするのですが、おそらく外に広がる不条理で火傷を負って快適なRailsの世界に引き篭もった結果としての一種のストックホルム症候群なのだなと思いました。いまやAjaxとかWebsocketとかWebRTCとかを組み込もうとする至極真っ当な方法論がとてつもない高難度に見えてきます。設定よりも規約、というのも一つの方向性だと思いますが、ドメインやサービスレイヤの名前空間を構築しようとしたりコードジェネレーションしようとしたりしただけで地獄のようなCircular Dependency罰を受けてしまったので、自分がとても間違った事をしているような気がしてしまいました。とはいえConcernsに特別な名前や役割を与えられても正直しんどいので、皆が皆libにゴミを放り込んでいく様子にも納得がいきました。
RailsをAPIサーバーとして使おうとするとまずビューが無くなってMとCだけになりますが、いわゆる"MVC"の文脈で育ったエンジニアがなぜ息を吸うようにFat ControllerやFat Modelを作ってしまうのかという事が良く分かりました。多くのRailsのリファクタ手法と称されているものはクラスを書くファイルを分割する事以上のものでは無いように思えたので、Rails使いを大きめなAPIサーバー案件に回すときはセットポジションでDDDの青本を投げつける必要が有るなと思いました。
ビューとコントローラを結合させた場合、結合テストはCapybaraとかのBDDでマークアップサイドとの干渉を恐れながら強い気持ちでメンテしていくしか無いのかなと思いました。おそらく脳に電極を埋め込んでいるか、緑色のランプを見るだけでハイになれる特殊な人にしか生き抜けない闇が垣間見えました。コントローラを薄くしてサービスレイヤを挟めばその辺りもうまくいけそうな気がしましたが、ビューからヘルパーやモデルがいくらでも透けて見えてしまうという状況では裏側の完全性に自信を持つ事は難しそうでした。
ビューがRubyを叩いて永続化レイヤと直接コミュニケーション出来るというのはとても生産性が高いのだろうとは思いましたが、こうして出来たパーシャルやら何やらをデザイナーとどうやって共有するかを考えると頭痛が痛くなりました。おそらく適当に切り出して綺麗な空間をassets以下に構築した上でpublicにRPCのような窓口を備えたゴミを量産していくのかなと思いましたが、もっと綺麗な方法はあるのかもしれません。でもきっとRails案件に関われるデザイナーはRubyもバリバリ書けるに違いないはずなので、ここが問題になる事は無いのだろうなと思いました。
RESTはとても美しいパラダイムではありますが、そもそもHTTPがさほど美しくないので歪んだ空間には目を背けるか勝手解釈を与える事で人は初めてRESTfulを名乗る事が出来るのだと思います。GETがbodyを(公式には)持たないという事について美しい説明を与える事は出来ないでしょう。サーチAPIはどうしますか。ステータスコード足りなくないですか。401エラーはどうしますか。そしてRESTはあくまでリソースを抽象化する美しい概念なので、アクションや副作用については貧弱です。動詞が足りないですし、一般動詞に狭義の意味を与えてドキュメントするのは二度手間にしか見えません。PUTには冪等性があるべきみたいなこだわりは家の猫にでも説教してればいいと思います。というわけで、REST的な設計を拝借することはよしとしても、「○○はRESTでは無い故云々～」みたいな注文はやめて頂きたいものです。
とか言わないで欲しいです。こういう時にセットでPHPをディスって悦に浸るのは知る限りRubiestとPythonistaと中学生だけです。それにこれはあくまでサーバーサイド初心者の感想なので、想像するにこれ系のFWは多かれ少なかれ似たような不満を抱えるものなのかなと思います。というわけで、おそらくこれから選択肢がある限りはRailsを使い続けると思います。
クリエイティブな仕事に憧れてたけど、絵も描けず、楽器もできず、文章も書けないみたいなワナビーこじらせた人間たちの最後の逃げ場って感じがするよね。
RailsやjQuery作った人間はすごいけど、それを使うあなたは全然すごくないじゃん。ただの消費者じゃん。
でも絵や音楽と違って供給者と消費者の境目が一見曖昧だからなんかすごいように他人も自分も錯覚するんだよね。
それもワナビーを呼び込む理由なんだろうけど。
TDDとかも、それを導入したら現場の効率が上がるとか本当はどうでもよくて「TDDやってる俺かっこいい」なんでしょ？
ワナビーとしての充足願望が満たされるんでしょ？
それで「会社にTDDを導入するにはどうしたらいいか」みたいなブログ書いたらはてぶで「こいつはわかってるヤツ」みたいなコメントもらえて嬉しいんでしょ？
そりゃ教条主義に陥るわな。反原発をTwitterでつぶやいて仮初の賞賛を集めるニートと同じだわ。
まあ「銀の弾丸は無い」って言ってるヤツも「銀の弾丸は無いって言える俺かっこいい」だから本質的には同じなんだけどね。
検索窓にふと tdd is って打って出た候補にワロタｗｗｗｗ
容赦なさすぎやろｗ
肯定的な文句がまったく出てきませんでした。事実はともかくとして、このように思われているということでしょうね。啓蒙は難しそうですね。大変ですね。
こちらからは以上です。
初音ミクのオンラインかるたゲーム「ミクミクかるた」をリリースしました。
http://mikumikuplay.com/karuta/
個人で開発して、開発期間は3週間くらいです。
http://www.nicovideo.jp/watch/sm22964822
リリースしたものの過疎ってるので、増田で宣伝をさせてくださいなと！
「ミクミクかるた」はブラウザで簡単に遊べるオンラインかるたゲームです。ゲームのルールは簡単で、ボカロ曲が流れたら、歌詞の先頭文字の札をクリックするだけです。「みっくみ～くにし～てあげる♪」と流れたら「み」の札を取ります。かるたの札の読み上げの代わりにボカロ曲が流れるというシステムです。オンライン対戦することも出来ます。ボカロ好きな人たちが集まって遊べる場になればと思っています！
ゲームで使わせて頂いた曲はpiapro(ピアプロ)でお借りしました。改めて素晴らしい曲がたくさんあることを知り感動しました。このゲームによって素晴らしい曲が、より多くの人に聴かれることを願っています。
実はこのゲームの開発者である私もボカロPをちょびっとやっています。私の場合、曲を作ってニコニコ動画にアップしても2日も経てば再生数の伸びが止まってしまいます。毎日すごい数の曲がアップされている為、すぐに埋もれてしまうのでしょう。私の曲は大したことがないのでいいのですが、中にはすごく良い曲でも再生数が少ないものが多々見られます。このゲームによって埋もれている隠れた名曲に、光を当てられたらと思っています！
以前、「ミクミクすごろく」というオンラインすごろくゲーム(http://mikumikuplay.com/sugoroku/)を作り、ユーザーがイラストと文章を作ることによってゲームコンテンツを拡張していくことが出来るCGG(Consumer Generated Game)の仕組みを作りました。CGGはブログなどでおなじみのCGM(Consumer Generated Media)のゲーム版に当たります。
今回開発した「ミクミクかるた」では、開発作業をニコニコ生放送で配信していました。すると視聴者の方がゲームの機能やデザインについてのアイデアをコメントしてくれました。コメントしてくれたアイデアのほとんどを採用しています。言わば、生放送駆動開発(Live Driven Development)と言えるのではないでしょうか？まぁ、これは悪乗りですが・・・。
最近流行している開発手法としてテスト駆動開発(Test Driven Developement→略してTDD)というものがあります。TDDをするとテストしやすいインターフェースやモジュール設計が出来るようになりますが、この生放送駆動開発すると、ユーザーが望んでいる設計が出来るのではないかと思います。新たな開発手法を発見することが出来ました。
■特徴一覧
・ニコニコ動画等で埋もれてしまっている隠れた名曲に光を当てるシステム
・HTML5、Node.jsによりWebブラウザゲームにおけるリアルタイム処理を実現
私は大規模・小規模、それこそものすごい人数でのチームや、自分一人のプロジェクトまで経験してきた。化石のような連邦事務局でもクールなシリコンバレーの会社でも働いたことがある。私は１２種類以上のプログラミング言語を学び使っていた。私の時代には ウォーターフォール/BDUF (big design up front), 構造化プログラミング, トップダウン, ボトムアップ, モジュラーデザイン, コンポーネント, アジャイル, スクラム, エクストリーム, TDD, OOP, ラピッドプロトタイピング, RAD, その他思い出せない様々な手法が生まれた。 でもそれらで上手くいってると思えるものは一つもなかった。
（ 注：ここで書いてある「ソフトウェア開発手法が上手くかない」の意味について説明させてほしい。それらはソフトウェア開発のプロセスや、ソフトウェア開発そのものについて予測性や再現性を提供していないという意味だ。ほとんどのソフトウェア開発手法はプログラミングに工学風のプロセスを提供してくれる。しかし、上記の理由でそれだけでは不十分だ ）
チーム生産性・幸福度・メンバーのつながり・１日あたりのコード量・人月・コードの品質・製造された成果物、、、そういったもの以外でソフトウェア開発手法が上手くいってるか、いってないかを図るものはあるのだろうか？
もちろんどんな手法論だって、それに合わせた正しい指標を使えば上手くいってるか・いってないかが計測できる。しかし一番肝心の問題 ーー予算と期限内で要求を満たす事ーー について定常的に結果を図れる開発手法を見たことがない。
上記は私の経験則だけど、僕の知ってる殆どのプログラマは同じような事を経験している。それらの話から言えるのは「ソフトウェア開発手法について厳密な研究は存在しない。なぜならソフトウェア開発上のすべての要素をコントロール事が出来ないからだ」
こんな思考実験をしてみよう、
２つのプログラマのチームがある。どちらも要求・期間・予算はしっかり確定していて、同じ開発環境・プログラミング言語・開発ツールを使うとする。一つのチームはウォーターフォール/BDUFをつかう。もう一つのチームはアジャイルテクニックを使う。
この思考実験にはもちろん意味がない。メンバー一人ひとりのスキルや性格、お互いにどんなコミュニケーションを取るか、そういったことの方が開発手法よりも大きな影響を与えるのは明らかだ。
アリスター・コッバーンが２００３年に"People and methodologies in software development" (http://alistair.cockburn.us/People+and+methodologies+in+software+development) という記事でまとめている。
" 人と人の間で、更には刻々と経過する時間の中で変化するメンバーのキャラクターこそがチームの振る舞い、結果に影響する最初の要因だ。 "
私がプログラミングを始めた1970年当時、開発体制はプロジェクトマネージャー・ビジネスアナリスト・シニアプログラマと言った階層構造でガッチリと管理されていた。開発言語やツールを選ぶことは許されていなかった。私はいくつかの大きく複雑なプロジェクトに関わっていたが大体上記の様な働き方だった。成功したプロジェクトもあれば上手くいかないものもあった。
今は開発言語やツールに合わせて、開発手法・働き方をプログラマが選ぶのが当たり前になっている。アナリストやらがプログラマを監査することは殆どなくなった。プロジェクトマネージャーは"リーダー"・"スクラムマスター"という形で矮小化され、管理職の権限は無力化され「チームの意見をまとめる事」以外は何も出来なくなっている。
ガントチャート・スケジュール・ドキュメントを使った「厳格なマネジメント」は"ユーザー"や"ステークホルダー"の関与を省かせて、"ユーザーストーリー"を要約していた。今や私の周りではまともな大人が監督してるとは思えないプロジェクトばかりだ。プログラマのカウボーイスタイルのコーディングを放っておいてるのに、彼らは自分好きな手法を適用するか作るかさせて、１９８０年代以上に決め事・儀式だらけだ。
実際、今のプログラマは１９７０年代のCOBOLの現場以上に手法論について厳格で、盲信している。実際私が最近関わるプロジェクトは、大体の場合何も価値を生み出さないのに一人か二人のメンバーが開発したプロセスや"ベストプラクティス"を背負わされてるものばかりだ。
プログラミングチームが手法論を採用する（多くの場合チームの数名か、一人のいじめっ子が決めるのだが）と、やがて厳格に従うように要求を始め、やがてそれは宗教になる。そうなることではじまる無自覚な攻撃が、手法論やテクノロジーが生産性を高めるより早く、チームの生産性を下げてしまう。
私の経験から言わせると、アリスター・コッバーンの論文やフレデリック・ブロックスの「銀の弾丸はない」http://www.cs.nott.ac.uk/~cah/G51ISS/Documents/NoSilverBullet.html で述べられているように、プロジェクトを成功させるにはチームメンバーが共通のビジョンを共有する事（その本では「コンセプトの統合」と呼ばれている）が必要だ。特に何かの手法論を指しているのではなく、これと言ったプロセスがない場合でも同じだ。私はプロジェクト管理ツールの「完了」ボタンをクリックするだけのチームで働いことがあるが、何故か分からないがBDUFやアナリストの監査の元で働いていた昔よりも気分が悪いものだった。
私はプログラマは様式やツールにこだわるより、同僚の話にもっと耳を傾け、もっと一緒に働くことに注力したほうが良いとおもう。そしてプログラマは手法論やプロセスについてもっと疑って掛かった方が良いと思う。そうすればみんな魔法の様に生産性が上がる、間違いない。多分プログラマが社交的なスキルを高めるのは他の職業より大変な事だと思う。（私は必ずしもそうだと思っていないが。）でもそういったスキルを鍛える事は、手法論を試すより事よりはるかに元が取れる、間違いない。
これの翻訳です。
http://typicalprogrammer.com/why-dont-software-development-methodologies-work/
注1 '14/02/11 まだ半分しか翻訳してません。（明日完成予定）
多少書けるけど絶対に「プログラマです」とは名乗れないゼネラリストたちで構成されている会社。
そんな会社だと、プログラムでなるべく解決する（コードが業務プロセスを頑張っちゃう）ために頑張るよりも、
業務プロセス・開発プロセス全体で最適化するよう頑張った方が、
プログラムで頑張ろうとすると、
外注するのに設計しようにも結局学習コストがかかりすぎるとか、
外注が逃げるとか、
引き継ぎ先がいなくて死ぬとか、
そんな余計なことが多かった。
反復性・正確性が求められるものはプログラム化に適しているけれど、プログラムは解決の一手段だし、一分野にしか過ぎない。
ともすればプログラムのスペシャリストでないことに大きなコンプレックスを抱くけど、
生産物が割合ライトで公共性も低い（例えばエンタメ系スマホアプリ）だったら、
身の程わきまえて、他の業務パラメータも見て総合的に結果を最大化しようというシンプルな結論に至る。
オブジェクト指向の本を読むのも結構だけど、もっと大きな見地から比較して
ライトなフレームワークを選択して、ライトな開発プロセスでやる選択がもっと歓迎されていいと思う。
そして、アジャイルとかTDD/BDDとかももちろんいいんだけど、開発現場からのボトムアップ的な思想やツールでなく、
マネジメント視点や経営視点から自分たちがライト層として開発するなら、という発想がもっとあっていいと思う。
元プログラマが経営層になっての話は近年よく聞くけど、非プログラマが経営層でかつ開発もある程度やるよ、というスタイルもそれなりにあるのに。
こういう情報が出回りにくい理由は、そもそも人数が少ないか、文章に書く魅力/余裕がないか、文章化が難しいか、まだ分野的にこなれていないか、のどれか。
暇ができたらまとめたいなあ。。
その前に売上UP（白目）
勉強会のつもりで行ったらただのOFF会であまり勉強にならない、という事が多い。
(OFF会的な側面がメインなら、そう銘打って欲しい)
アウトプットは大切だけど、LTは銀の弾丸ではないので万能のように言うのいくない
テストファーストは有効な場面が多いけど、TDDは銀の弾丸ではないので万能のように言うのいくない
アジャイルの理念は素晴らしいけど、アジャイルは銀の弾丸ではないので万能のように言うのいくない
全ての言語は銀の弾丸ではないので、万能のように言うのいくない
アレ。。。
いじょー。
Multilevel Marketing Plans
Produced in cooperation with the North American Securities Administrators Association
November 1996
Multilevel marketing plans, also known as "network" or "matrix" marketing, are a way of selling goods or services through distributors. These plans typically promise that if you sign up as a distributor, you will receive commissions -- for both your sales of the plan's goods or services and those of other people you recruit to join the distributors. Multilevel marketing plans usually promise to pay commissions through two or more levels of recruits, known as the distributor's "downline."
If a plan offers to pay commissions for recruiting new distributors, watch out! Most states outlaw this practice, which is known as "pyramiding." State laws against pyramiding say that a multilevel marketing plan should only pay commissions for retail sales of goods or services, not for recruiting new distributors.
Why is pyramiding prohibited? Because plans that pay commissions for recruiting new distributors inevitably collapse when no new distributors can be recruited. And when a plan collapses, most people -- except perhaps those at the very top of the pyramid -- lose their money.
The Federal Trade Commission cannot tell you whether a particular multilevel marketing plan is legal. Nor can it give you advice about whether to join such a plan. You must make that decision yourself. However, the FTC suggests that you use common sense, and consider these seven tips when you make your decision:
Avoid any plan that includes commissions for recruiting additional distributors. It may be an illegal pyramid.
Beware of plans that ask new distributors to purchase expensive inventory. These plans can collapse quickly -- and also may be thinly-disguised pyramids.
Be cautious of plans that claim you will make money through continued growth of your "downline" -- the commissions on sales made by new distributors you recruit -- rather than through sales of products you make yourself.
Beware of plans that claim to sell miracle products or promise enormous earnings. Just because a promoter of a plan makes a claim doesn't mean it's true! Ask the promoter of the plan to substantiate claims with hard evidence.
Beware of shills -- "decoy" references paid by a plan's promoter to describe their fictional success in earning money through the plan.
Don't pay or sign any contracts in an "opportunity meeting" or any other high-pressure situation. Insist on taking your time to think over a decision to join. Talk it over with your spouse, a knowledgeable friend, an accountant or lawyer.
Do your homework! Check with your local Better Business Bureau and state Attorney General about any plan you're considering -- especially when the claims about the product or your potential earnings seem too good to be true.
The FTC also publishes: Wealth-Building Scams; Business Opportunities: Avoiding Vending Machine and Display Rack Scams; Work-at-Home Schemes; Franchise and Business Opportunities; and A Consumer Guide to Buying a Franchise. For a free copy of these brochures or a copy of Best Sellers, a complete list of the FTC's consumer publications, contact:
Federal Trade Commission
(202) 326-2222
Where to Complain
You may send questions or complaints to:
Correspondence Branch
Federal Trade Commission
Although the FTC cannot resolve individual disputes, the information you provide may indicate a pattern of possible law violations requiring action by the Commission.
You also may want to contact the National Fraud Information Center (NFIC), a project of the National Consumer League, at 1-800-876-7060, 9 a.m. - 5:30 p.m. EST, Monday - Friday. The NFIC is a private nonprofit organization that operates a consumer hotline to provide service and assistance in filing complaints. NFIC helps the FTC and the state Attorneys General by entering complaints into a computerized database to help track and identify fraud operators.
和訳は以下のページ。
http://www.ne.jp/asahi/kato/logos/ftc-mlm.htm
Willcomファンサイトの暇？人氏と、ソフトバンクモバイルの副社長、久慈毅氏(ペンネーム)との議論から、いろいろな人間を巻き込んでの大騒ぎとなった。（以下一部敬称略）
久[1]http://k-tai.impress.co.jp/cda/article/interview/37483.html
暇[2]http://www.phs-mobile.com/?p=249
久[3]http://blog.sbibusiness.com/interview/001/index5.html
暇[4]http://www.phs-mobile.com/?p=287
久[5]http://blog.sbibusiness.com/interview/001/index6.html
暇[6]http://www.phs-mobile.com/?p=294
口火を切った暇？人氏は撤収したが、どうしても確認しておきたかった点があり、個人的に書き散らかしておく。それはこれ。
暇＞「2G帯は15MHzしかないから容量が小さい、これでは顧客のニーズを満たせませんから、
暇＞当社ではどうしても使うことができません」とウィルコムが言ったとして、
暇＞松本氏はどう反論するのでしょうか。
久＞ウィルコムさんは「15MHzでは小さすぎて使えない。」とは言えないはずです。
(中略)
久＞ウィルコムさんも、どうしても15MHzでは困るというのなら、既存バンドも含め、
久＞周波数利用の全体像を明確にされるべきだったと思います。
（ http://blog.sbibusiness.com/interview/001/index6.html より）
かみ合ってねえええええ！ てかそんな話は総務省の委員は把握しきってるはずだろ。
XG-PHSの規格書(簡単な登録で誰でも読める。ただし英語)によれば、XG-PHSはガードバンド込みで1.25, 2.5, 5, 10, 20MHzという連続した周波数帯域（占有周波数帯域）を必要とする。XG-PHSの規格として何故15MHz帯域が含まれないのかについては、規格を考えた人じゃないと正しいことは言えないだろうが、おそらくTDMAのスロットがPHS的仕様として固定されていて、これをOFDMA-TDMAで処理するのに効率のよい帯域になっているのではないかと推測される。そしてXG-PHSではOFDMA-TDMAで区切られたスロットをいくつ占有するか、で単位時間あたりの情報伝送量(≒伝送速度)が決まる。
2.0GHz帯および2.5GHz帯はTDDなので、端末が伝送速度を稼ぐためには周波数方向の帯域を拡大しなければならない。しかし連続周波数帯域はOFDMで処理されるわけだから、ガードバンド込みの帯域を２つ併用するという無茶は出来そうにない（本当か？）。仮にこれが出来るとしても、RF帯からダウンコンバートする回路やIDFT/DFT処理する回路が２つ必要になったり、内部で結合したりするのか……？ いずれにせよ素人目に見てもややこしい。無線回路屋が暴れそうだ。MIMO使うんだから周波数ダイバーシチが実現できていいだろう？ その検証を今からやれと？
となると、所要に満たない占有周波数帯域がいくつもあったところで同時接続ユーザ数は確保できても『最大伝送速度』を確保できるものではない、と考えるのが自然。なので15MHzという占有帯域しかない2.0GHz帯では、20MHzから30MHzという帯域を活用できる2.5GHz帯との勝負では最初から分が悪いということになる。そんなところに行けと発言するんだから、『最初から負け戦確定の部分に相手を追い込むような発言』ととられても仕方ない。このあたりが久慈氏に対する悪印象のひとつ。
もうひとつは端末価格の問題。端末価格を規定する要素として、伝送回路がらみのコストはいかほどか？ もっと他に要素があるんじゃないのか？ そのへんが明確になってないからおかしな議論になっていると思う。
それと伝送周波数帯の変更に伴う伝搬特性にはさほど変化は無い、とか久慈氏は書いてた気がするが、さほどってどんだけ？ 現場で蓄積してるデータをご破算にして新たにフィールド実験からやり直せと？ ありえん。マジでありえん。そんな意見を社外から述べられてはいそうですかと聞き入れる上司がいたら辞表を叩きつけたい。
XG-PHSはマイクロセルなので、伝送周波数帯が高周波数であるほうが有利に働く気がする。2.0GHz帯の”電波的に使いやすい”と言われる特性は、信号の時間分解能をもたないOFDMでかつTDMAを抱えるXG-PHSでは不利に働く可能性が高いからだ。CDMAoneで RAKE受信機を用いているにも関わらず干渉波に苦しんだauの例がある。
ガチ記名で書くと間違いが発覚したときに色々ややこしいことに巻き込まれそうなので、増田で書き散らかしておく。ビバ増田。
とりあえずペンネームは「通信勉強中」を名乗っておくか。つーか暇？人氏は技術わかってんだったらちゃんと書けよなー。
間違いがあったら指摘してくれ。参考文献とかも書いといてくれると超助かるｗｗｗ
追記：久慈氏による総括＞http://tedm.sbibusiness.com/2008/03/post-1.html
本当に論戦すべき相手を間違えてないか？ その相手が出てくるまで叫び続けるべきではないのか？
という思いを強くしてしまう。つまらない者たちの相手ばかりしている大人はあまり見たくないんだよな。
