| Home  |  Visit  |  Comment  |  RSS  |  Top  |
カテゴリ:   →私的仕事論( 10 )
最近の興味
BI(Business Intelligence)

たまたま今働いている派遣先が社内システム部門ということもあるのだけど、
今まで関わってきた受注生産の開発とはまったく違う側面がありおもしろい。

受託で開発する場合、
既にクライアントはどのようなサービスを提供したいという明確な意思やビジョンをもっている場合が多い。
つまり、受託開発をする開発者やエンジニアには、
「サービス」を考えるという機会がほとんどないということだ。

ところが、社内システムとなると、違う側面が出てくる。

当然、経理や人事などの社内の基幹情報を扱うのも社内システム部門の仕事なのだが、
(ここは業種によって大きく違うとので十把一からげにはできないが)
それ以外に、会社がクライアントとする顧客に対して提供する情報を
どのように管理しマネジメントするかということも考えなければならない。
つまり、会社の顧客のニーズを理解している必要があり、
それに即した「サービス」の提供という発想力が求められる。

ここがまた情報を扱う業種の社内システム部門のジレンマなのかもしれないが、
企画部門は、(テクニカルな意味で)どのような情報がどのような手段で手に入れられるのかについての造詣を深めておく必要があり、開発部門は(サービス企画という意味で)どのような情報がどのような形で提供できるかを創造&想像する能力が必要になってくる。

この両者がバランスよく機能してはじめて、「BI」というものが会社組織の中で成り立つのだろう。
ようは、一般的に言われる開発者に最も欠如している能力がたくさん求められる現場でもあるのだ。
技術一辺倒の知識や経験範囲だけでは対応できないことがたくさん出てくる。
[PR]
by harvestrain | 2009-10-07 14:40 |    →私的仕事論
スタンス
仕事のスタンスや目指すところは人それぞれあることはわかる。
わかるが、最低限ってものがあるだろうと思う。
その最低限のラインそのものが、違いすぎる人が多いような。
別に私のスタンスを押しつけるつもりもないし、
自分のスタンスが他の人にまねできるものでないことも分かってはいるが。

専門職という仕事柄、プロフェッショナルという目標を設定しやすいのかもしれない。

ようは、

子曰、
吾十有五而志于学、
三十而立、
四十而不惑、
五十而知天命、
六十而耳順、
七十而従心所欲、不踰矩。

子曰く、
吾れ十有五にして学に志ざす。
三十にして立つ。
四十にして惑わず。
五十にして天命を知る。
六十にして耳従う。
七十にして心の欲する所に従って、矩を踰えず。

ってことなんでしょうか?
[PR]
by harvestrain | 2009-09-26 02:42 |    →私的仕事論
無駄を省いて、利益を確保する
 Webサイトの構築においては、ユーザ画面設計、それを管理する運用者用の管理画面設計が必要になる。それらを統一の取れたものとするためには、クライアント(この場合は運用者側)が何をしたいかを明確にイメージしておく事が必要となる。しかし、大抵の場合、運用フローおよび何をしたいかを明確にフロー化できているケースはごく稀である。その部分から手伝い決定を促す必要がある。
 そして、このような開発における無駄には2つのボトルネックがあると思う。

 1.受注から仕様凍結までの期間における無駄
 2.開発工程における無駄


 これらの無駄が、納期の延長や質の悪いプログラム、動作保証のないシステム、したい事が実現できていないシステムといった最低最悪なものを生み出す大きな要因のように思う。
 理想を言えば、受注後すぐに案件担当PM/SEがアサインされ、下記のステップを踏めること。
  1. クライアントの要望をヒアリング。(PM/SE)
  2. 仕様策定。(PM/SE)
  3. 仕様書作成。(PM/SE)
  4. 開発スコープを決定。(PM/SE)
  5. 画面フローの決定。(PM/SE)
  6. DB設計、サーバおよびネットワークプラン構築。(PM/SE)
  7. 概要設計。
  8. 詳細設計(SE)
  9. テスト仕様書作成
  10. 開発
  11. 社内テスト
  12. クライアント検収
  13. 納品
なのかな、と思う。まあ、これも我流なのでツッコミどころは満載だとは思いますが。

1.受注から仕様凍結までの期間における無駄

 これは、会社の組織体制や業務分担によって変わると思うが、まず仕事を取ってくる営業サイドが無駄に時間を費やす。クライアントは自社のビジネススケジュールというものがあり、納期は当然クライアントのプランに合わせて要求される。無駄に時間を費やしている間に、クライアントが要望する公開日などが迫る。営業は、受注を取りたいので、その納期を承諾する。
 ここで最初の問題が発生する。クライアントとのやりとりに開発側の人間が一切タッチしていない場合、果たして開発ボリュームに見合う開発工数と納期のバランスをどうとるか。何を基準にそれを決めるのか。それが適当であるという判断は誰が下すのか。開発サイドに案件が下りてきた時点で、仕様や開発スコープがが決っていないにもかかわらず納期は決っている、という状況がまず問題である。
 このあたりのフローは、会社の規模や組織体制、開発体制によってまちまちだとは思うが、そもそも、納期を決定するところで開発ボリュームを考慮されないというのは、どう考えても間違っていると思う。
 そして、納期に間に合わせようと思うと、十分な設計やスコープ決定をしている時間がなくなる。当然、開発は各担当者がメールやわずかな書面による情報を元に、設計=プログラミングという最悪の手順を踏まざるを得ない。テスト仕様書なんて考えている時間もない。


2.開発工程における無駄

 上述の状況がゆえに生じる問題ではあるが、クライアントのヒアリングがしっかりされないままに、きちんと設計されないシステムを作るということは、開発の手戻りが多いということである。
 クライアントは、大抵の場合システムのプロではない事が多い。出来上がった画面をみて、こういう風にしてほしかった、こういう風にしてほしいな、という要望が次から次へと出てくる。それは当たり前のことなのだが、デザインや画面フローのきちんとした設計がされていないため、開発者は作りながらシステム中心の画面フローになりがちである。常識の範囲で当たり前に流れるべき画面遷移やフローはあるものの、ここのクライアントの運用フローによっては、その画面設計がベストマッチでないことはしばしばある。毎日使うわけではない管理画面は、ある程度の不便さも不便と感じないが、毎日業務で使い続ける画面となると、また要求される画面設計の思想は違ったものとなる。
 要はクライアントとが何を求めているか、何をしたいと思っているのかを、こちら側が十分にヒアリングし、それを具象化する事が必要なのである。しかし、その時間やスケジュール的なゆとりがない場合が多い。
 ヒアリングが十分にされないままの仕様はいつまでたっても凍結しない。仕様が凍結しないと開発スコープは決まらない。スコープのない設計はまとまりがなくなる。まとまりのない設計は、何をどう開発してほしいのかわからないままのコーディング作業となり、作ったものがユーザの要求にマッチしているのかすらわからない。そこを結局のところ、規約や前提条件や「これが仕様です」といった逃げ口上で乗り切る羽目になる。運よければ、それで開発し直しという事態は逃れられるが、使えないシステムを作った会社というレッテルは免れない。クライアントの要望どおり対応すれば、開発のやり直しという手間を生み出す。
 そして、仕様の定まらないままの見切り開発、設計書のない開発、タイトなスケジュールの開発というのは、間違いなくバグを量産する。きちんとした設計さえされていれば見落とすはずのない部分を見落としたり、エラーチェックやエラー処理が正しくなされていないという結果を生み出す。
 手離れの悪い案件というのは、想定外の動作、運用のイレギュラーケースへの対応漏れによるバグである事が多い。

 運用フロー、目的をユーザにきっちりと認識させ、明示的に書面化するということは、ただの形式上のドキュメントを整えるという作業とは違う次元のものである。想定されうるレギュラーケースの運用フローをきちんと決めていなければ、おきうる問題、予想されるイレギュラーケース、考慮すべきイレギュラー、想定されるリスク、そういったものを割り出せないのである。そのような想定のないシステムは、運良く安全な動作だけで運用されている間は分からない。しかし、一回イレギュラーが発生すると、それに吸い寄せられるように運用の矛盾が生まれ、その運用上の矛盾したフローは、システムの矛盾につながる。そうなれば、ボロボロである。




 ここで書いたことは、氷山の一角である。が、最低限のことでもある。
 そんな基本的な事が出来ていないようでは、利益があがるはずもない。割く必要のなかった社内リソースをバグ回収やトラブル対応に割くのだから。
 利益をあげたければ、無駄を省く事をまず考えるべきだ。
 どう見ても合理的でない、実際的でない。そんな行動を繰り返すのはなぜなのか。なぜ、学習能力がないのか。
 事象の原因を正しく分析できていないからである。
[PR]
by harvestrain | 2004-10-15 00:41 |    →私的仕事論
BtoCとCRM、そして最適
 エキサイト社長、山村氏のブログより「One to One marketing 「ちょっとやりすぎ!?」 9月7日」にトラバです。

 システム開発者の視点でサービスを語ってみようと思う。偉そうなのは気にしないでください。(笑)
 システム開発者といえど、Webのシステムを作っている以上、「サービス」について考えないで済まそうとするのは、個人的には如何なものか思う。もちろん、仕事のスタンスやポジションで違うのだろうが。しかし、たかがプログラマといえど、自分が作ったプログラムを含むシステムを使うのはコンピュータではない。人間だ。人間が使う以上、コンピュータの向こうにいる人格を思わずにはいられない。
 何でもかんでもシステム化してしまうこの時代に、「心」を忘れたシステムは、やはり良くないんじゃないかと思う。利益を度外視しろと言っているわけではない。営利団体である以上、利益があってこそのサービスなのは当然だ。しかし、顧客が、エンドユーザが、心地よくサービスを受けれる形が何なのか、そのためには何が必要なのか、これは追求し続ける必要があるんじゃないだろうか。技術の追求だけではやっていけない世の中になってきていると思う。

3つの取引形態

 まず、一般的に言われる電子取引の種類として、以下の分類がある。
1.企業企業 >> BtoB( Business to Business )
  • メーカーと卸
  • 卸と小売
  • 業務アプリケーションをASP( Application Service Provider )として提供する。
  • 2.企業消費者 >> BtoC( Busines to Consumer )
  • オンライン販売サイト(ECサイトなど)
  • ゲームやコンテンツなどのオンライン提供サービス
  • 3.消費者消費者 >> CtoC( Consumer to Consumer )
  • インターネット・オークション


  • CRMという手法

     顧客のニーズに合わせたサービスの提供を実現するための経営手法として、CRM( Customer Relationship Management )というものがある。どんなサービスを、どんな商品を、どういうタイミングで提供するのが最適か、集めた情報を体系的にまとめ、顧客をセグメント化し、適切なところに適切なサービスを提供するための手法である。
     まず、顧客の情報を収集をする必要がある。次に、収集された情報を体系的にまとめ、顧客が求めるものが何かを知り、優良顧客を洗い出し、優良顧客には更なるメリットの高いサービスを提供し、そうでない顧客には、優良顧客に導くために適切なサービスが何かを知る。そうすることで、企業は、適切なタイミングで適切なサービスや商品を顧客に提供できるわけだ。
     仕事柄、このCRMを実現するためのシステムを作ることもあるので、こういった概念を持っておかないと、商品(私の場合はシステム)を企画したり、目的に合った仕様やシステムの設計が出来ない。


    顧客ひとりひとりのニーズを探る

     特にBtoCの取引形態において、押し付けがましいサービス、過剰なサービスというのは客離れを招く。何事も程々がよいとはいえ、どこまでが適当で、どこからが行きすぎか、それを判断するのは大変難しいように思う。特に、ターゲットが広ければ広いほど、それは困難な作業になる。それは人間にしか出来ないことだ、というのも重要なポイントである。
     以前にも記事にした事があるが、ユビキタス社会を作ろうという風潮も、顧客それぞれのニーズに対応できるモノづくりという発想が根底にあるように思う。
     この「顧客ひとりひとりのニーズ」に合ったサービスを提供するという考え方は、決して新しい発想ではないと思うのだ。山村氏は昔の有名ホテルのサービスを例に挙げておられるが、身近なところでも、行きつけの居酒屋のおやっさんやおかあさん、よくいく食堂のおばちゃん。そんな人たちに「今日はあんたの好きな○○があるよ」とか「そろそろ来る頃だと思って○○入れといたんだよ」とか、「あんた、これ好きやろ、とっといたんやで」なんて言われたことはないだろうか?それは、CRMという手法で表現されようとしている事柄と根本的な概念は同じだ。彼らはそれを自分の頭で行っている。当然、ターゲットも狭いからそれで間に合う。それでまかなえない規模の大きいサービスにおいて、システムが果たす役割が大きくなる。


    最適なサービスとシステム化

     何でもかんでも「IT化」だの「システム化」だのともてはやされた一頃は、客がシステムの仕様に慣れて合わせることが当然の如く要求された。しかし、もはや消費者はそれでは満足しない。顧客も質の高いサービスを知るようになった。今や、極め細やかなサービスが要求されるのである。
     どれだけシステム化したとしても、「心」の抜けたサービスは、顧客にとって最適とは言い難い。CRMという手法で、情報を集めて統計された顧客の動向データも、使う側の考え方と発想力次第なのだ。たとえCRMのための素晴らしいシステムを開発できたとしても、使う側のサービスにこめる「心」がなければ、それはただのクズだ。
     山村氏は「ITは武器である。しかし武器は間違うと凶器になってしまう。」と述べている。まさしくその通りだと思う。人を魅了する武器の使い手になるか、人を遠ざけてしまう武器の使い手になるか、それはシステムの問題だけではない。提供者の手腕が問われるところだと思う。
     それは同時に同じ事がシステム開発者にも言えることだと思う。対クライアント、対エンドユーザが見えていないシステムは、「最適」とは程遠い。そして忘れてはならないのが、システムには限界があると言うことだ。開発的見地から見て、どれだけ素晴らしい秀逸なシステムであったとしても、ユーザにとって最適でなければ、その価値は半減する。システムでは判断しきれない事が多くある。
     下手すると、一部の開発者は技術や技巧に凝ったシステムを作ることに必死になり、技術的な素晴らしさだけに目が行きがちだが、優れた技術が本当の意味で生きるのは、顧客にとって何が最適かを見据えた上で創られたシステムなのではないだろうか。


    あるべきサービスの形とは

     コストや開発工期に追われがちな現場の身としては、「そこまで考えてられない」という気持ちが沸く時があるのも否定はしない。人の数だけ「最適」があるのだから、追求したらキリがないというのも分かる。
     けれど、システムのために顧客があるのではない。サービスのために顧客があるのではない。顧客のためにサービスがあり、システムがあるのだ。その順序をはきちがえてしまうと、この先、立ち行かなくなるんじゃないだろうか。技術力だけに頼ったシステム設計、予算にしばられたシステム設計、スケジュールに縛られたシステム設計、システムありきのサービス、それを続けていては、成り立たないように思う。開発者として、設計に携わることのある者として、クライアント、そしてクライアントの向こうにいるエンドユーザを見失わないシステム開発をしていきたいものだ。

     「心」が抜け落ちたサービスやシステムは、いずれ廃れる。
     私はそう思う。
    [PR]
    by harvestrain | 2004-09-10 22:36 |    →私的仕事論
    ユビキタス

    ソニーの2004年度経営方針は「派手なことをせず着実に

     記事としては少々古いですが。
     個人的には、日本にある大手の電機メーカーの中で、世界の舞台で最も華々しい成功を手にしたのは、ソニーではないかと思う。製品に対する信頼度や好き好きはさておき、企業として好感が持てる。
     ソニー代表取締役会長兼グループCEOの出井伸之氏は、5月に行われた経営方針説明会で、

    「ネットワークが普及し、情報格差もなくなっている。これからは画一的なマスプロダクションは通用しない。個人が(商品を)選択する基準が変わるだろう。大企業のあり方、技術のあり方、顧客との接し方、宣伝効果のあり方などすべてが変わる。10年前に比べて考えられないほどソニーを取り巻く環境は変わっており、現在の延長線上ではいけない」

    と述べたそうだ。
     その通りだと思う。「ユビキタス社会」の到来とよく言われるが、その変化に対応するためには、今の「メーカー仕様に客があわせろ」「これが仕様なんです、これに慣れて。」的なやり方では、通用しなくなるだろう。サービスや製品を提供する側は、今まで以上にエンドユーザの細かなニーズまで察知できるようにならなければならないと思う。
     空を翔るような身軽さや、マッハGOGOGOみたく(古っ)あっという間に駆け抜けていくような疾風怒濤のスピード感も大事だとは思うけど、地に足の付いた、足腰のしっかりした経営母体があってこその良さだと思う。着実さを求める大企業があってもいいんじゃないだろうか。


    →ユビキタスとは?

    アスキーデジタル用語辞典
    UBIQUITOUS
    Ubiquitous

    ラテン語の「ubique」に由来する言葉で、「神のように遍く存在する」という意味。IT業界では、Ubiquitous Computingを略してこう呼ぶことが多い。

     画一的な規格どおりにしか使えないコンピュータに人間があわせるのではなく、個々の必要にいつでも柔軟に対応できるようにしよう、という発想である。「ユビキタス社会」とはそういう環境が整った社会を指す。家庭にあるパソコンがしゃべったり、人間のように自分で学習して判断することができるようになるという話ではない。
     IT業界では、「ユビキタス・コンピューティング」といわれる。つまり、後述の例のような事を可能にするインフラやハード、システムの開発が求められるようになるということだ。

    →ユビキタスの例を挙げてみよう。
     冷蔵庫をのぞき、その中の材料を見てレシピをインターネットから探したい、と思ったとしよう。次に何をするだろうか?パソコンの前に行き、コンピュータを起動し、インターネットにつないで、ブラウザを立ち上げ、検索サイトにアクセスし、冷蔵庫の中にある材料を入力して検索する必要がある。それは情報を得るために、人間がコンピュータという存在を意識し、コンピュータが使える状態に合わせて行動しているわけである。そうではなく、冷蔵庫にコンピュータが内蔵され、パソコンの前までいって行っていた事が、冷蔵庫の前でできる、という環境である。つまり、情報がいつでもどこでも手に入るわけだ。

     これは、AI(人工知能)や、はたまた感情の学習までしてしまうAIといった、SFチックな発想ではなく、実現可能なリアリティある話である。


    ※もっと分かりやすい説明が「現在の日本」というサイトにありました。「Ctrl+F」で「ユビキタス」と入力して検索してください。ページの下の方にあります。
    [PR]
    by harvestrain | 2004-09-03 16:07 |    →私的仕事論
    でばっぐ。
     言ってもはじまらないのは、よぉぉ~~~~く分かってはいるけれど、あり得なさすぎる。

     どんだけ忙しかろうが、時間がなかろうが、一通りのチェックはして欲しいもんだ。
     明らかに、次ページへ遷移した時の画面はおかしい。最低限の入力チェックもされてない。未入力であれば、変数の定義で引っかかり、ページはエラー表示になるはずなのに、それすら対応されていない。

     明らかに見た目がにおかしいの、気がつかないのかな。時間がないとか、忙しかったとか、精神的にゆとりがなかったとか、そんなのはただのいい訳だ。プロである以上、最低限守り抜きたい品質というものはないのか?自分が作ったプログラムにプライドはないのか。
    [PR]
    by harvestrain | 2004-07-12 02:11 |    →私的仕事論
    ゆとり
     今頃になって、すこしだけ、自分自身にゆとりが生まれた、というよりは作れた気がする。というよりも、いろんな人と話をして、アドバイスをもらって、客観的になれたというか、自分の判断や行動の指標ができてきたというか。

     どうやら、SEのB氏はココ何年かコーディング作業は全くしておらず、ずっと仕様や設計の方で働いていたらしい。それだけブランクがあれば、そりゃぁ、しんどいわな。分かってはいたものの、そこまで考えてあげれなかった事や、それを踏まえた割りふりやハンドリングできなかった自分小ささに情けないものを感じる。

     自分自身、初めての経験で、判断や決定の指標や基準として何を持てばいいのか、わからず迷いながら指示を出していたので、みんなやりづらかっただろうなぁ。自分の中で『ゆとり』がないと、人の状況や気持ちまで考慮して労われないものだなと痛感した。ちょっとした言い方や、ちょっとしたヒトコトで、使われる側は気持ちが楽になったり、ストレスを感じたり、イライラしたり。使われる側としてはいっぱいそういうのを経験してきたはずなんだけど、いざ自分がその立場になるとホントに大変なのね。上の人間にはいつもシビアに求めていたけれど、上には上の苦労があるということを、ほんのちょっとだけ体験した。

     もう少し、人に優しくなれるだけのゆとりを持てる人間でいたいな。
     心のゆとりっていうのは、勝手に転がってくるものじゃなくて、自分で作り出すものなのかもなぁ。と思った。
    [PR]
    by harvestrain | 2004-06-28 22:42 |    →私的仕事論
    リスクヘッジ
     今日の会議で、「起きていない事を考えてもしょうがない」といわれてしまったんだけど。。。

     リスクヘッジを追求しすぎると、際限ないのはわかる。
     でも、開発案件の種類によっては、リスクヘッジの徹底度や、どの部分のリスクヘッジにどれほど力を注いだかが、今後を左右すると思うんだけど、考えすぎなのかなぁ。今回の案件においては、それだけの事が必要だと判断したから、そう話したんだけど・・・。

     結局、苦労するのは、本人たちなのに。
    [PR]
    by harvestrain | 2004-06-21 17:09 |    →私的仕事論
    人を活かす
     初めて、マトモに責任ある立場として、人の上にたった。今までは、ずっと使われる立場にあったから、使われる側の人間として、上司に対してどう接したらいいか、どうサポートしたらいいか、程よく勘所はつかんでいたつもりである。

     突然、立場が逆転し、みんながみんな、自分と同じようには考えてくれないというのをまず思い知った。頭では理解していたけれど、実際にその立場になってそういう状況を経験すると、思っている以上に大変だった。

     下につく人間が、みんながみんな使えないわけではない。能力がないわけでもない。でも、経験地の差や得意不得意の分野によって、出来ること出来ないことがある。それを見極めて、上手にその人の能力をプロジェクトに活かすって、本当に難しいと思った。

     仕事のプロセス上においては、その判断が正しいかどうか、この状況で考えうる要因をいろんな観点から考慮し、ベストと思われる判断を下すのは、まだよいのだが・・・。何よりも、人の評価を下すというのは、本当に難しいなぁと思った。本当にその評価が正しいのかどうか。自分が見えていないその人の部分がまだ隠れているんじゃないだろうか?大事なことは見落としていないだろうか?そんな事をずっと考えていたら、頭のてっぺんから、煙が出てきた。


    もくもくもくもく。。。

    [PR]
    by harvestrain | 2004-06-18 14:51 |    →私的仕事論
    スタンス
     仕事におけるスタンスというのは、その人の大事な一部だと思う。でも、案件の状況によっては、そのスタンスを頑なに固持することが賢明な選択であるとはいえないんじゃないかと思う。

     外注のSEさんが保とうとするスタンスは、本来あるべき姿だとは思う。けれど、クライアントあっての仕事であり、そのスケジュールにあわせてやらなければならない時、執拗にそのスタンスややり方にこだわって、「この状況じゃ、開発できない」と言い切ってしまう事が、本当に正しいのだろうか?
     いいたいことは分かるし、保ちたいスタンスも理解できる。それは理解できる。そのスタンスがいつでも実行できればいいけど、時にそれはただの理想論でしかなく、状況にあわせた順応性も必要じゃない?
     少なくとも、外注さんたちの直接のクライアントは、うちの社であり、うちの社が求めたものに対して、「できない」というのであれば、やはり、こちらとしては担当を替えてもらうしかないんだろうか。

     開発における見切り発車が、いいとはいわないけれど、本当の意味で、見切り発車になってしまいますというほど、必要な情報が欠けているわけではない。開発し、考えるのに必要なだけの基本的な情報は全て揃っている。というか、無理やり揃えたんだよ。私は。


     一体どう扱えばいいものやら。
    [PR]
    by harvestrain | 2004-06-18 14:43 |    →私的仕事論
    自己完結型棚上げ駄文
    Since 2004.5.11
    検索
      猫、堕を貪る。
    すっかり妻らしくなった
    新妻Harvestrain
    もとい若干古女房です。
    いつのまにか、
    年とともに、
    打たれ弱くなったねこにんです。
    モットーは、
    気の向くまま。
    風の吹くまま。
    猫のまま。
    頭は使うな、アホになる(ぇ

    -------------------
    twitter
    日記
    ブログ
    技術メモ
    -------------------
    お問い合わせ・ご意見はこちら
    メールを送る
    -------------------
    最新のトラックバック
    裏バイト行ってきましたっ
    from わたしのおナニー
    バイト行って来たぞ
    from わたしのおナニー
    マジだ!どうしよう?
    from 童 貞プレミアン
    web 作成
    from web 作成
    ★☆★今ビジネスは劇的変..
    from 在宅ビジネス
    その他のジャンル
    ファン
    記事ランキング
    ブログジャンル
    画像一覧
    ヨコの会
    ◇◆◇◆◇
    ブロガー互助連盟 ヨコの会本部
    ◇◆◇
    加盟窓口はこちら
    ◇◆◇
    第28独立小隊
    吾輩は猫である?方面部隊
    CELL725
    -- サマーアイズ --
    ◇◆◇

    共同戦線中。
    ◇◆◇◆◇
    AX