  |
はてなキーワード: 仕様書とは
んーごめん、言葉足らずだったね。
もちろん納期ありきなんだけど、そもそも「その納期じゃ絶対無理」だったり、納期は変わらず仕様変更、ていうかそもそも仕様書なくて相手の言うなり、っていう状況が多すぎるっていうことを言いたかった。
そういう構造である以上、よほど優秀な開発者であっても納期を守ってたらまともなものなんて絶対作れない。それこそ機能が追加されるたびにつぎはぎあてることになっちゃう。
元ネタの記事では、そういうことにまったく触れずにバグをしこんだ開発者が悪いっていう風に自分は読めちゃったから、
誰でも思いつく当たり前のべき論だ。それが当たり前にできないシステム開発業界の現状にまで踏み込んでほしかった。これじゃあ開発者が100%悪いことになってしまう。
って思ったのよ。
２００７年です。今年です。
でもね、変なんです。
これ、Ｍｅたんが入ってるっぽいんです。
作業してるとすぐフリーズするし。
終了がなかなかできなかったりします。
おかしいな。
Ｍｅたんはもうサポートも終了したので新しいＰＣに乗るはずはありません。
そもそもＭｅたんの次にＸＰが出てきたはずです。
おかしいです。
これは噂に聞く、ＸＰより後に出たＯＳです。
でも、動作はまるっきりＭｅです。
昔もってたＭｅたん機よりは全然早く動きます。
でも、当時はＰＣが対応してなくてメモリが５１２しか載せられなかったけど、今のＰＣは２Ｇまでのせられて、そして、４ＧのReadyboostをのっけているからです。
メモリ６Ｇ使って、５１２の時に動作が負けてたら、そりゃああなんじゃって感じです。
私は言いたいのは。
Ｍｅで失敗しといて、ＭｅみたいなＯＳ作ってんじゃねーよ＞マイクロソフト
ってことです。
私、ＭｅからＶｉｓｔａに移った人なのですが。
ＯＳが変わった気がしません。
Ｍｅだって、メモリ６Ｇ載せられるＰＣにのっけたらこんだけ働くよって感じです。
Ｖｉｓｔａに手を出す方がバカっていうご意見多数だと思いますが、別にＶｉｓｔａ機を買ったんじゃなくて、新しいＰＣを買ったらＶｉｓｔａがついてきただけなんです??????????。
本来乗っているメモリは５１２だったので、５１２で動かないＯＳを搭載しているのはおかしいとメールを打てば「出荷時での動作は確認しております」
うきーーーーーー。
店頭でＶｉｓｔａを見つけたり、Ｗｅｂ上でＶｉｓｔａの記事を見たら、反射的に憎々しげに睨み付けてしまいます。
Ｖｉｓｔａのバカ????????????????????！！
http://satoshi.blogs.com/life/2007/10/post-4.html
こういうことを権威のありそうな人が言うから「プログラマはクリエイティブな職である」というような誤認識が起きるんだろうなぁ、と。
ただし、世の中には完璧な仕様書なんてものは存在しないから、行間を読んで埋めてあげられる人が重宝される。
そういう人は行間を読み間違えないために、日々、情報収集＆精査をしてるんだよね。（半分趣味なのが普通だけど）
で、逆にそういうことをしてないせいで、行間の読み方を思い切り間違え（or読めず）、あげく「仕様書どおりにコーディングするだけなんて非創造的な職だ・・・」とか嘆く人が増えてるのがIT業界の現場の現状。
僕は組み込み系システムエンジニアなのだけど、自分の業務改善作業がとても好きだ。
キーボードを自腹で買い換えたり、メモリを自腹で増設したり、いろんなツール導入したり、GTD導入したり、職場にwiki導入してみたり、デュアルディスプレイを自腹で構築したり、仕様書とソースコードをPerlやRubyで出力して同時出力したりなど色々業務環境を改善してきた。
自分の開発環境をより開発しやすく、自分の開発工程をより完成度を高くしていく作業はとても楽しい。そういう記事を読むのもかなり好きだ。
でもずっと前からやりたいけどやれないことがある。それはペアプログラミングだ。
理由はペアプログラミングという業務改善作業には、それに賛同してくれる相手が必要で、今この職場には賛同相手は一人もいないからだ。僕の拙い説明では、「どうもペアプログラミングは悪くないらしい」ということが伝わらない。「そんなチャレンジしてる暇があれば目の前の仕事しなよ」と言われてしまう。きっと僕がペアプログラミング未経験者だからうまく説明できないというのもあると思うのだけど。
でも多分、ペアプログラミングは、「コミュニケーション不足になりがち」というIT業務の本質的な欠陥を補い得るかなり根本的な業務改善だと思う。だけど、それでも出来ない。賛同してくれる人が職場に一人もいない。だからペアプログラミングが出来ない。
「仕様書レビュー、ソースコードレビューで十分じゃないか」そう言われてしまう。十分か、十分じゃないかなんて試してみなければわからないじゃないか。
今のところ、地道に「ペアプログラミングやりたいやりたい」とことあるごとに周りに言って回る日々をすごしています。
俺の住む世界はアイティーとやらに支えられているらしい。
アイティーに関われば、俺の住む世界をさらに素敵なものにしていけるに違いない。していきたい。
そう願って、何も知らなかった文系新卒の俺が金融系のシステム会社に入って、もう一年以上が経つのだ。
昔、お遊びでゲームを作ったことはあった。RPGツクールなんかが好きだった。
パズルみたいで楽しかった。コンピュータの中身が理解できて、わくわくした。
楽々と基本情報技術者の資格を手にし、半年後にはほとんど勉強もせずにソフ開も取得した。
研修の課題では同期の誰よりも速く、短く効率のいいソースを仕上げた。
現場に出て、本番機に触った。
３０年間親会社を支え続ける偉大なシステムの中身を、わくわくしながら覗いた。
そこには、俺の求めていた世界とはまったく違うものが広がっていた。
俺が産まれる前から、入れ替わり立ち替わり何人もの手によって継ぎ足されたロジック。
何千行にもわたって、似たような処理が何回もひたすら繰り返される似たようなモジュール何十本。
1993年に行う臨時処理のロジックが、今もコメントもなしに埋め込まれている。
仕様がわからなくなれば、キャビネへと走って、黄ばんだ方眼紙に鉛筆で書かれた仕様書を探し、
そして修正履歴のみが書かれているのを確認して肩を落とす。
半年後に臨時で行われる業務に対応するため、いくつかのモジュールについて、処理可能なユーザーコードをひとつ、条件に加える。
与えられた期間は２週間だった。ずいぶん長いなと思った。
何枚もの設計書を書いた。つまり、方眼紙状のExcelテンプレートに同じ文章をコピペした。
追っていったモジュールはどれも、ヒープもソートもメモリ管理も論理演算も出番がなかった。
あるのはただ、IF文とMOVE文とばかりだった。ソースの難易度は使われている命令の数とは関係ないことを学んだ。
テストデータを作るため、階層型DBを何回も辿ってデータをアウトプットさせるモジュールを書いた。資格試験で学んだSQLは、無用の知識だった。
協力会社への仕事割り振りやユーザー対応に毎日忙しそうだった上司が、夜遅くまでの残業続きでくまのできた目を皿のようにして設計書をレビューした。
２日後、承認が出た。フェーズが設計から開発に移った。
ロジックを丸々コピペしてソースを修正し、コンパイルし、実行した。
２週間はあっという間だった。
俺のせいで、半年後以降は使われないロジックがソースにまたひとつ増えた。
今回の対応については、Excel方眼紙にレポートをまとめて共有ドライブに入れておいた。
だが共有ドライブの検索には時間がかかるし、Excelシートの中身となれば検索から漏れることも多い。
きっと誰にも読まれないだろう。
２バイト文字が使えない関係上、原則、ソースにはコメントはあまり入れられない。
数年後の新人はきっと、俺の書いたモジュールを見て「このロジックは何だ」と首を捻るんだろう。
数年後の俺はきっと、今回のレポートを共有ドライブから探し回って新人にパスを教えてから、
協力会社の管理に追われる作業に戻って目の下にくまを作るのだろう。
俺がやりたかったシステム開発って、こんなものだったのか。
俺は部署の中で、俺の望む仕事を探し続けた。
先輩たちは忙しくて誰も興味を持ってないけど、自動化できる作業はいくらでもある。
よく使われるExcelシートを改造し、定例作業をクリックだけでできるようにした。
ExcelVBAとはいえ、書いていて心地よかった。引数が明確な関数と変数のスコープと全角文字があったからだ。
COBOLで打つプログラムより、控えめに見て100倍くらいの生産性を発揮できていたと思う。
先輩たちは喜んでくれたが、ただし俺の仕事を、あまり仕事とは見なさなかった。
それでもよかった。業務時間外は俺は相変わらずスクリプトを書いていた。とても楽しかった。
VBAから入って、WSHなんてものを知り、やがてJavaScriptを学び、ネットで資料を探し、はてなを知り、はてブでWeb技術についての記事を読みふけった。
知れば知るほどに、どんどんCOBOLが、メインフレームが嫌いになっていく。
先輩は誇らしげに言う。システムはたいしたことをやっていない。業務知識こそが大事なのだ。
ユーザーより詳しく業務を理解し、適切に提案し、設計する能力。
協力会社を率いて、わかりやすい文書で指示を行い、スケジュールを調整する能力。
人を動かすぶん、責任も大きくやりがいもある。優秀な人材こそが我が社の強みだ。
そんな人材が育つよう、我が社は安定して働ける環境と福利厚生を整えている。
ああ、そうだよ。先輩、あなたは正しい。
俺だってメインフレームの信頼性のすごさはわかってる。
密なユーザーとの関係から生まれるシステム子会社としての強みも認識してる。
それだけじゃない。社内環境も悪くない。給料もいいし休みも取れるし先輩は優しい。
ここは、いい会社だ。
けど駄目なんだ。
３０年前のシステムを枯れた言語でツギハギする仕事じゃ、俺の心はやっぱり満たされない。
ユーザーの業務知識ばかり身につけたって、俺自身の人生には、いいことなんてない。
俺が求めていたのは、この仕事じゃないんだ。
社内の誰も、TumblrもTwitterもやっていない。ライフハックなんて聞いたこともない。
Joostやモバゲーや２ちゃんねるが社会に与える影響について誰も語れない。
休日はゴルフや酒に興じている。自宅にPCを持ってない人までいる。
おかしいことじゃない。普通の人たちだ。
それどころか彼らは、仕事とプライベートを切り分けている、立派な人たちだ。
でも、やっぱり俺の生きていきたい世界は、ここじゃないんだ。
たぶん俺がいるのは極北なんだろう。
ここが、人月計算とExcelとスーツの世界というやつなんだろう。
俺は80文字×32行の緑文字を見つめながら、遠い夢を見続ける。
http://anond.hatelabo.jp/20070821033820
上場が目的のベンチャーに限らず、多くの企業にとって「人材は宝」などという言葉が方便であることは、先のバブル崩壊で証明されている。
全てはカネ、カネが全てだ。
リストラとは名ばかりの、芸のない人材切り捨て、雇用抑制が横行し、派遣やパート、バイトなどの賃金の低い非正規雇用労働者が増加した。企業は「低い人的コスト」という蜜の味を占めた。同じ仕事内容でありながら、正社員でないばかりに生活の困窮と雇用の不安にさいなまれる多くの人たちが悲鳴を上げている。
企業内の構造改革も行わず、高い労働コストが必要なシステムのまま人員だけを切り落とし、クビになったら「失業」、会社に残ったら「過労」という、「いびつな二極化」も生み出した。過労死や過労自殺が社会問題化した。1998年以降「景気は上向いた」と言われる現在であっても、自殺者は3万人を下らない。
しかし世論（いや、マスコミか？）は「企業のコスト削減が推進されている」と称賛し、その影で泣いている人々を無視した。
「アウトソーシング」という響きのいい言葉を担ぎ上げて、多くの製造業が人件費の安い中国や東南アジアへ進出した。今まで長年築きあげた、国内の中小零細企業との関係をばっさり切り捨てて。そのため東京の大田区、大阪の東大阪市、他全国の都道府県に広がる、小さな町工場たちが無念の内にシャッターを閉め、二度と開けることがなかった。
なかには、元請けの立場を利用して圧力をかけ、下請け工場の財産である設計図や仕様書、技術マニュアルを奪い取り、それらを中国の提携企業に横流しして、現地での生産体制が整うやいなや、その下請け工場から仕事を全て引き上げる、などの卑劣な行為も起こった。これは、企業による強盗殺人にも等しい。
「国際的な企業競争に勝ち抜くため」と、多くの大企業が競争化社会を謳（うた）っている。グローバルな経済で勝ち抜くためには、必要不可欠だと。ただ、競争化社会なら、全ての企業、個人が、「公平」とは言わないまでも、「対等」なはずだ。実力のみで優劣が決まるからこそ競争化社会ともいえる。しかし、日本においては、企業内部における「上司と部下」「先輩と後輩」などの年功序列、企業間における「元請けと下請け、孫請け」などの、いわゆる「親分と子分」のような舎弟関係が幅をきかせているのが現状だ。
つまり「無能だがカネ、権力のある親分が、競争で勝ち抜くために、その下の子分達に大きな負担、苦痛を強いている」と取れる状況も多い。そういった仕組みが良いか悪いかは分からないが、それで本当に競争化社会で勝ち抜けるかどうか疑問だ。
景気回復基調、と、さんざん多くのメディアで目にする。東京証券取引所の株価表示は、銘柄と価格の流れるスピードが速くなるほど、売買が活発に行われていると聞く。景気も、お金の流れる速さや量が多くなっているのであれば、確かに回復したと言えるだろう。しかし、その流れる輪は、明らかに小さくなっている。多くの地方都市が、バブル崩壊以降その巡回経路から外された。もちろん、輪の中心が東京なのは言うまでもない。
先の政権末期、少子化対策にかなり大量の予算が拠出されたが、特殊出生率は、予想を遙かに下回り、戦後初めて人口が減少した。しかし、先の参議院選挙で少子化が争点になることは皆無に等しかった。個人の推測の域を出ない愚考だが、政府は「人口減を前提とした経済政策」にシフトしたと考えている。
だとすれば、日本の景気は、上昇するにもかかわらず、その規模をどんどん小さくしていくように思えてくる。一部の人たちのための景気になってしまうのではないか。文字通りの格差社会だ。
一行目のトラックバックに、企業経営者、ベンチャー創業者の反論を読んでみたいところだ。
「そもそもが生きるに値しない、代わりなど幾らでもいる労働者は、会社のためだけに働いて至極当然だ」という極論を、誰もが納得できるように書いてのける人間がいるとしたら、見ものだね。
気が付いたらExcel開いてばかり
そしていつも設計手直ししてる
諦めずにソースと書類見比べるけれど
すぐにミスに気づくよ
何回やっても何回やっても
設計書が直せないよ
あのロジック何回追っても分からない
だから次は絶対直すために
レビューの時間だけは最後まで取っておく
気が付いたら期限あと少ししかない
そしていつもそこでサビ残使う
諦めずに仕様すべてまとめきったけど
すぐに修正増える
何回やっても何回やっても
設計書が直せないよ
印刷したら改行位置が合ってない
行数増やして他セル見てたら何故だか式が壊れてる
文字列置換も試してみたけどオートシェイプは引っ掛からない！
だから次は絶対直すために
僕は補助マクロだけは最初に組んでおく
実際に俺が体験した出来事を聞いてくれ。
リニューアル案件をある女の自称ネットショップコンサルタントから、依頼された。
で、週末にその女コンサルタント同席で1回目のヒアリングに行ったんだ。
金銭面は厳しい条件だったんだけど、
面白そうだったから、詳細は2回目のヒアリングでって事で、前向きな返事を
しておいたんだ。
いざ、メールを読んでみると俺は驚愕した。
リニューアル予定日を宣言したり、正直参った。
それは2回目のヒアリングで決めるって言っただろうが！
メールの文章としてはこんな感じだ。
「1日の売上レポートをエクセルで書きだせるとうれしいかも!(^^)!」
「じゃあ、○○君、期待してるよ(^_-)-☆」
「あぁ・・・死ねばいいのに・・・。」って本気で思った。
で、こっそりそのコンサルタントに「それは違うんじゃないの？」という
趣旨のメールをしたら、「あなたにはプロ意識が足りない。」って逆ギレですよ。
ああいう人って自分の事しか考えてないんだろうな。
間違いを指摘されると自分の全てが否定されたと思っちゃうんだろうな。
君らの身近にもいないか？こういう人。
http://anond.hatelabo.jp/20070529190414
ソフトの値段が高いと買ってもらえないし（だから大抵ハード屋と組んでハードと抱き合わせ販売）、
社内にコンピュータいじれる人がいないから、NumLockが入ってない程度の些細な事も含めて、開発したソフトと関係ないトラブルも含め全部電話がかかってくるし。
サポート料金をケチってサポート契約を結ばない客もいる割には、そんな客に限って、トラブルがあってもずっと無料で診てもらえると思い込んでるし。
そして、そんな客に限ってスポット対応の出張料や技術料を高いの何だの言うし。
大手企業と違って、ちゃんとした仕様書を作ってくれとか言われる事は少ないけど、だから仕様はこちらの自由がきくとは限らず、これまで手書きやExcelシートに自由に書けたのが、システム化したら（いちいちマスタ登録が必要、イレギュラーパターンの時に入力枠をつぶして別の用途に使う事ができない、等）何でこんな不便になるんだと文句言われるから、「システム化とはどういう意味なのか」から教えなくてはいけないし。
ワンマン社長と実際に使う社員の温度差が激しくて、機能の要望について両者の意見が180度食い違うのは毎度の事だし。
SEやプログラマに親切に応対してくれていた古株の事務員さんが辞めるのを機会に、業務のシステム化＆ソフト開発というパターンも結構あって、その事務員さんが辞めた後に…あとはご想像におまかせします。
まずは RFC 1738 - Uniform Resource Locators (URL) （日本語訳）を参考にして、記号文字のURLエンコードがどのようにあるべきかを確認します。
いくらなんでもRFC 1738はないでしょ。RFC 2396 Uniform Resource Identifiers (URI): Generic Syntaxが出たのが1998年の8月だよ。最新のRFC 3986 Uniform Resource Identifier (URI): Generic Syntaxですら2005年1月、つまり2年以上前に出てるんだよ。
・・・といちゃもんつけようかと思ったけど、ECMAScript 3が1999年12月だからRFC 3986は参照できないね。さらにECMAScript 1にいたっては1997年6月だから、どうあがいてもRFC 1738しか参照できないわけだ。そのへんECMAScriptの仕様書にもちらっと書いてあるね。そこらをみんな考慮に入れて誰か改良版を作ってくれないかな、というだけいってみるテスト。
わからないながらも書いてみると「これじゃわからん」と言われる。
自分で作ってる範囲内の事も把握できてないんじゃ、登大遊みたいな1万行/日プログラマには程遠いな。
俺も昔は仕様書なんて書いてる暇あったらコードだけ書いてた方が早いって長い間思ってた。ある時、自分から見て凄いプログラマに仕様書の作り方を手取り足取り教えてもらったら、仕様をきっちりと決めてからコーディングした方が、開発効率が劇的に向上するようになった。それからは、自分で書く範囲のプログラムは必ず仕様書をしっかりと書く事にしてる。
仮に他の人が「こういう物を作って欲しい」っていう提案書なり仕様書を持ってきたとしても、その中でどうコーディングしたらいいかっていう仕様書は、自分用に作るようにしてる。
でもたまに上司が思い出したかのように「仕様書出して」とか言う。
社内で誰も作ったことのないものを突然出せと言われても困る。
わからないながらも書いてみると「これじゃわからん」と言われる。
けっきょくうやむやのままプロジェクトは進んでいく。
こういう人のプログラミングっていうのは、ほとんどコードと同じレベルまで細かく仕様書を書くよ。そして、いざコードを書く段になったら、その仕様書を翻訳していくだけ。バグが少ないっていうのは、仕様書の時点でバグを潰していくから。仮にバグが発生したとしても、それは単純な仕様書からコードへの翻訳ミス。それでもよく分からないバグが出た時は、設計が不完全だという事になるので、設計を見直す。
その作業を頭の中で完結することが出来る人もかなり居るだろうけど、紙か何かに書き出した方が利口。
http://d.hatena.ne.jp/softether/20070324#p1
どんだけー！！
自分がやったら１万回せこせこ改行するだけで一日おわっちゃうよ！！
一分間リターンキー押しつづけたけど1600行ぐらいしかいかなかった....
モジュールヘッダ＋関数ヘッダのコメントだけで100行ぐらいあって、ファイルの半分ぐらい定型で実はステップカウンタで数えたら3000行ぐらいだったり？
いや、3000行でも一日に書くのは尋常じゃないスピードだけど、それくらいが個人的経験からすると臨界点。
ステップに対してテスト項目をあげつらわなきゃいけないISOとってる仕事だったら死ねるよね。2、30ステップに一項目ぐらいテスト項目設けなきゃいけない基準みたいなのってあるじゃない？いくらバグ少ないと本人が豪語しても、cだったら組み込みとかでしょ？
出荷しちゃったら最後な状態でテストどうしてるんだろ？
組み込みじゃないのかな？？
対一万行でテスト仕様書作成→テストだけで一ヶ月掛かっちゃうよ。。
というかこの文章を読んでいる限り仕様書なんかなさそうだよね。
この人ひとりにたいして最低でもバックアップ部隊が20人ぐらいいないとダメなわけですか？？
どんだけーーー！！
・・・俺が知ってるプログラムと違うのかもしれない。とか思い始めた。
スタイルシート ソース理解クイズ - ［ホームページ作成］All About
まあ「仕様書で規定されていない部分については、IEおよびFirefoxの実装に従うものとします」などといった注意書きをもっとしっかりつけてくれれば大体は間違ってない。
しかし、Q7に関しては明らかに間違っている。選択肢の中に正解がない。
'margin-left' + 'border-left-width' + 'padding-left' + 'width' + 'padding-right' + 'border-right-width' + 'margin-right' + scrollbar width (if any) = width of containing block
CSS 2.1では通常フローにあるブロックレベル非置換要素の幅の算出に上の等式が使われる。しかし、問題の例では、この等式の左辺のすべての項がauto以外の算出値を持っている。この状態を「制約しすぎ」（over-constrained）であるといい、（包含ブロックのdirectionプロパティの値がltrならば）margin-rightプロパティの指定値が無視され、上の等式を基にmargin-rightの値が再計算される。よって正解は「包含ブロックの幅に等しいピクセル数」だ。
それから、Q9にも大きな不備がある。「同じ位置」「移動する」と回答中にあるが、これらが何に対してなのかが明言されていないのだ。固定配置の要素はスクリーンメディアにおいて、表示領域に対しては同じ位置にあるが、通常フローの要素に対してはスクロールに応じて移動するといえるので、このままでは正解をひとつに絞りきれない。
1年以上アウェーでの生活。疲れた。
契約書なんか無いよ。でもやると言ってしまったんだ。
その言葉だけに縛られている。
平均して9時から24時まで働いている。
22時30分に帰るでしょ、こう言われたことあるよ。
「昨日はもう少しやると思ったのにな。」
土曜日？休まないよ。
日曜日？2回に1回は休むかな。
仕様書？漠然としたものがあるよ。
仕様変更？何回あっただろうね。
給料？そうだな16万くらいかな。
支えてくれる彼女？別れたよ、おれに会えない寂しさを紛らすために
ネットである男性とメールのやり取りを始めたんだって。その人のことが
気になっているらしい。おれがホームに帰るまでは待つって言ってくれたけど
別れようと言った。
借金？無いよ、今はね。でもいろんな責任を取らされて下手すると1500万円くらいになるかもね。
やめればいいのに？そうも行かないんだ、会社対会社だからね。株式も半分以上取得されているし。
希望も何も無い。ただここから一日でも早く這い出ることができればそれだけでいい。
「質問者は知りたい単語を入力するとなにかの達人の猫が答えてくれます。」
利用者は知りたい単語を入力することができます。
回答者は「その単語」に添うURLを追加できる。回答に締め切りはない。またURLにタグ付けコメントをすることができる。検索結果はその単語に回答されたURLを表示。
回答が無ければ表示されない。
ただし回答があっても、他の猫が貼り付けたタグ等はよそ様の猫には見せてやらないにゃー！
というわけで、すべてにゃんにゃんで表示される。
友達の友達になっていない人の回答は「にー」とか「にゃん」とかしか表示されない。
質問者が登録した単語に回答をしあうと友達になれる。
一方的に回答だけや、質問だけを繰り返しても友達にはなれない。
赤の他人猫の書き込みは「にゃんにゃん」とのみ表示される。
最初に質問した「単語」がまだ誰もマーキングしていない場合、自分の単語としてマーキング登録することができる。
他の猫がマーキングした単語を奪うことができる。
単語を奪われないようにするためには24時間以内に自分がマーキングした場所に戻りマーキング予約している他の猫を蹴散らさなければならない。
三階層のカテゴライズ下のタグを配置することによりディレクトリ型リンク集が構成される。
ディレクトリ型リンク集もトップ画面、検索結果から表示アクセスすることができるが、部外者にはにゃんとも表示されない。
書き込み等には猫認証を使用(ex.三毛猫を選択してください)
パスワードは猫順序を採用（ex.子猫→三毛猫→黒猫順に選択）
一枚の画像に[子猫][三毛猫]など複数の意味を持った９枚の画像をランダムに表示。
