2010年01月02日

初夢 - GeekStation

とあるビル。その一角。常に明かりが灯っていて、まるで不夜城の様。
「ちわーっす」俺はドアを開けて入った。「寒いっすねー、死ぬかと思った。」
「おー!○○クン!今日は早く上がれたのか」奥から佐倉さんがお茶を持って来てくれた。「ほら、とりあえず暖まれ」
佐倉さんはここの管理人だ。けっこういい歳をしている中年太りなオッサンだけど、この佐倉さんの事情通には誰も適わないんじゃないかな。
「シングルどっか空いてるかな?小一時間ぐらい集中してリファクタしたいんだ」
「今空いてるのはペアが1室だけだねぇ。んー、服部さんがあと30分ぐらいで帰宅時間じゃないかな?」佐倉さんはテーブルの煎餅をポリポリやり出した。また太るぞ。「それにしても、DexRouteだっけ。続くね。次の1.9.6はいつ出るんだい?」
「ん〜〜…」俺の手が勝手に壁一面の書棚からテキトーな技術書を抜いていた。「Jamesのやつがさー、わかってねえんだよ。『こっちの構造の方がイイ!』とかメール来てさ、forkもせずにpushしてきやがって。これが見たらヒドイんだわ…」
技術書に目を落とす俺。ここの品揃えは厳選されている。持ち込む人の張り合いもあんのかな?自分が『良書』と思った本を持ち込んでくる。そして俺みたいなのがチョッピリ得をする。
棚によっては「マネジメント」だとか「コーチング」だとかビジネス書っぽい本も並んでるけど、俺には今のところ興味がない分野だね。
お茶を飲みながら本に集中する俺。しばらく静寂の時間が流れる…。

「ふわ〜〜、ねみ」ガチャ、と部屋のドアが開いて、服部さんが出てきた。「やっぱ捗るわ、ここ。助かるねー」
「たまには早く帰らないと」佐倉さんがお茶を入れるためにそそくさと立ち上がった。「奥さんにアイソつかされるぞ」
「わかっちゃいるんだけどさ」服部さんはチョコレートに手を出した。だから太…まあいいや。「家に帰るとダメなんだよ、俺。一行も書けなくなるタイプ」
世の中そんな人もいるんだよね。とか言いながら、俺もアパートに帰る前にこっち寄っちまうクチだけど。
「今週のワークショップってなんだっけ?」
「金曜の夜に、M社さんとこのG言語教室2回目があるね」お茶を入れたきゅうすと一緒に…えっと、バカウケが増えてるんですけど?佐倉さん?「あとエーラブの人たちの『非同期協調とOOインタフェース』が土曜」
「エーラブやるのか…」ちょっと興味を持った。あとで申し込んでおこうかな。
「エーラブの方は、もう一杯じゃなかったかな」
チッ。

「Sakuさん、相談にのって!」もう一つのシングル部屋のドアが開いた。出てきたのは中井戸くんだ。「俺がメンテ続けてるアレさ、企業からオファー来ちゃったよ!」
中井戸くんは同い年なので、なんとなく意識してる存在だ。ライバル心?ちょっと違うか?
「そりゃめでたい!」佐倉さんが席を立った。「どんなトコが声かけて来たんだい?へー、bit社が…」二人で部屋に引っ込んでいった。
ここのサーバ環境はちょっとしたもので、M社とG社が協賛に入ってるおかげでバックボーンがけっこう豊かに使える。フリープランの足かせが少し軽くなる感じ。
それに、やろうと思えば小規模のデータセンターぐらいの設備が使える。
そのためか、署名入りアプリをここから発信している人も多い。
ネックは通信経路。ちょっと細めなので、人気アプリができるとアクセスを捌ききれなくなる。「N社をなんとか巻き込みたいんだよね」が佐倉さんの口癖だ。

それに、法律方面、会計方面と、各種方面が専門のボランティアの人たちがサポートしてくれるから、今みたいな時も対応が素早い。
彼らにしても、そこで独立法人化となるといいビジネスチャンスになるし、持ちつ持たれつなんだろう。
俺ら一般会員もいくらかの会費を払っているし、協賛企業からの寄付金もあるけれど、圧倒的な収入源はこのオファーがあった時に企業から入る紹介料、そしてボランティア有志で開発を続けてるシェアウェアツールの課金だ。
一応、企業ワークショップの時や会議利用の時は場所代をとる仕組みになってるけど、残念ながらさほどの額になってない。
こういった会計の面が全て公開されて運営されてるのも、俺がここを好きで利用している理由のひとつだ。

去年の夏はひどかった。ここからBotNetを広げようとしたバカがいたんだ。
気づくのが早かったから広まる前に対策を打てたんだけど、あの時偶然その場にいた俺は、正直ちょっと興奮した。
でもその後、犯人がじつは会員の一人だとわかった時の佐倉さんの落ち込み様は、見ていてつらかった。
あの時のみんなの頑張りがなくて、BotNetの根城化してしまっていたら…おそらくここは閉鎖していただろうな。
考えるとちょっと怖い。

今日はとくに何もせずにビルを出た。息が白い。
今年はどんな年になるんだろうか。また面白いヤツに出会えるといいな。
どうも男くさいのが玉に瑕だけどね…。
そして俺は明日のために、暗いアパートへと帰路を急ぐ。




はい、夢です。
自分的GeekStationの有り様です。
もちろん、こんな収入モデルじゃホントにやっていけるものじゃないでしょうねぇ、というのは承知の上(苦笑)
いいじゃん、正月なんだからさ!
posted by 未知夢 at 15:25| 東京 ☀| Comment(0) | TrackBack(0) | システム開発 | このブログの読者になる | 更新情報をチェックする

2009年12月24日

リーダーが必ず受け入れるべき3つの指針?

「リーダーが必ず受け入れるべき3つの指針」(DIAMOND online) http://diamond.jp/series/sales_manager/10010/

ネットで偶然読んだ記事なんだけど、なんか「納得はできるけど賛成できないな、これ」と思ったので、ネットの片隅で勝手に反論。

【リーダーが受け入れる3つの指針】
 ・部下はリーダーの30%しか仕事ができない
 ・組織はリーダーの器以上に大きくならない
 ・部下に決して弱みを見せてはならない

これ、それぞれ「と思うと、気が楽だ」って文言を入れるとしっくり来るよね。
読んでみて「そうそう、そう感じることはある」というのが納得できた部分。
「でも、それってそう言い切るのが良いことなの?」というのが賛成できない部分。
ということで、反論してみたい。
まあ、技術畑と営業畑とは全く別のものなので、お前が反論するな!という話はあると思うけどね。

ちなみに自分は、開発でリーダーにたった時は「自分はカレッジ型」であるということを最初に公言してしまう。性格的にも「親分・子分型」運営なんてできないし。

「部下はリーダーの30%しか仕事ができない」は「部下は自分の思っていることの30%ぐらいしか汲んでくれない」



仕事柄、営業の人とは付き合いがあるし、「どうして営業と現場とは理解し合えないのだろう」というのをいつも悩んでいる。
で、ある「人売りIT企業」の営業さんの話。

その営業さんは「とにかく人を売って案件数かせぐ」ことが得意で、いつも「営業の中で会議ばかりしてちっとも外回りをしない」人たちがいるのを不満に思っていた。
一方、不満に思われた方といえば、いつも「外回りして数を稼ぐだけで、きちんと技術者と案件とのマッチングをしていない」のを不満に思っていたらしい。
技術者的に頼りたいと思うのは、きっと後者だろうね。そこでその営業さんはずいぶんと悩み込んでいた。そのためにスランプになった。

ある日、その営業さんが社長と酒を飲んで、言われたらしい。「彼らのやり方は、技術者を幸せにさせようと努力している点で、とても正しい。そこは理解して欲しい。ただし、会社としてはそれでは回らないんだ。だからキミのような数を稼げる人も必要なんだ。会社としては両方とも居てもらわなければ、成り立たないんだよ」
身も蓋もなく言ってしまえば「キミは必要悪なんだよ」ってとこだろうけど、それでもこの営業さんはそれを聞いて元気になり、仕事へ前向きになった。

部下がリーダーの想定している(技術的/仕事量的/思想的)範囲と一致するのはマレだよ



そう、人は本当にそれぞれで、同じGoalをかざしても、そこへの立ち向かい方も色々なら、持っているモノも色々だ。まずそこをしっかり抑える必要がある。
技術の話になるともっと色々になる。ある人は設計は得意だけどコーディングで凡ミスをする、とか、ある人は環境設定周りは得意だけどなぜか設計能力はない、とか。
リーダーのやるべき事は、部下を30%しかできない人として扱うのではない。部下を一人ひとり見極めて、たとえ想定と違っていても適材適所に人をはめる事だ。できるなら本人にしっかり選択してもらった方が力になる。
そのために必要なのは、リーダーがGoalをしっかり見極めて全員の共通認識にしていることだ。それさえできていれば、チームはGoalへ向かえる形になる。(たとえイビツな形でも)
あとはもう、チームのハンドル捌きにかかっている。

へびの足。現場の人はもっと営業を頼りにし、営業をこき使うぐらいの勢いでいるべきだよ。

「組織はリーダーの器以上に大きくならない」ことなんてない



うむむ…部下を認めろ、は前の章でやってしまったな。では別の切り口で。

どれほどの現場で「このリーダー、使えねー」があることか。
けっこうこの体験をした人も多いんじゃないかな。自分もある。
そんな時にチームそのものがバラバラになった場合と、チームとしてはまとまってGoalできた場合とでは、いったい何が違うのか。

プロフェッショナルを自覚した部下をどれだけ囲い込めるかが、組織を成功に導くポイントだよ



チームとしてまとまった場合をよく見ると、プロフェッショナルの意識をつよく持つ人がいた、という事に尽きる。
こういう人が一人いると、その人が変わりのリーダー(影の支配者)となって取り仕切るようになる。複数いると、それぞれ協調し出して、なにか勝手に動いているようで全体としてはまとまっている、という面白い運動コラボレーションがおこる。

プロフェッショナルとそれ以外の違いはなんだろうか。
それはGoalを見出す選眼力、そしてGoalに到達するために有効ならどのような手でも手を尽くす貪欲さ、そして自己責任感の強さ、じゃないかと(個人的に)思う。

逆に、組織的に・リーダーの権限でキャップを設定してしまい、こういうプロフェッショナルな人の行動を制限するようになると、チームは勢いを落として減退する。大型開発でひじょうに多いのだが。

「部下に決して弱みを見せてはならない」で封じ込められるリアルな現状分析



叱咤激励で部下がシャキン!目標達成!すばらしい!!
でも違うんじゃね?
まあこれ、営業にありがちな典型的なノリだけどね。

でも、昔読んだ開発系のリーダー養成本でも同じことが書いてあった。
はっきり言おう。楽観主義と根性論で仕事する時代は終わったよ。

部下がリーダーの顔色を見て仕事をするのは、じつは「それ以外にGoalを見据える判断材料がないから」なんだ。

きちんと「見える化」しよう。そのうえで、GoalとVisionを持とう



さっきからGoalを持てと強調しているけれど、Goalを持つのはリーダーとしてではなく、チームとして持たなくてはいけない。
チーム全体が「Goalは何なのか」を見極めて、はじめて「Goalへ向かう以外の余計なもの」も明らかになる。

そして、Visionもチームとして持たなければいけない。ようは「どういうルートでGoalまでドライブする?」という点だ。
ひとつは「余計なもの」を極力・ギリギリまで削る努力をすること。
もうひとつは「有効なもの」をどんな些細なものでも貪欲に取り入れること。
これをやるためには、リーダーが頭で考えていたのでは絶対に間に合わない。自分の知識は限界があることを自覚しよう。
そのために、情報はなんでもチームで共有しよう。そして部下にはどんどん相談し、意見出し合える雰囲気をつくろう。
そう、「相談するのはOK!」なんて、まだぜんぜん生温い。mustなんだ。

Visionをしっかり見るためには、もちろん現状を全員の認識にしておく必要がある。どんな些細なことも隠し立ては無用だ。

そしてここが重要な点だけれど、これらを踏まえて「給水ポイント」を明確化しよう。
Goalまでとても長かったとしても、中継地点とそこへ到達するルートが頭にあると、人はわりと頑張れる。
そこでほっと一息つけると、次の中継地点に向かう大きなバネになる。
切羽詰ったプロジェクトほど忘れやすいことだけれど、大事だ。

時々、情報を独占することと意思決定を独占することで自己の権力増強を図る人がいる。
こういうリーダーの下では、チームは絶対に大成しない。チームメンバーにいるだけでも有害だ。

どうも、この「部下に決して弱みを見せてはならない」の章がいちばん嫌いだな。ありがちな「無理を通せば道理が引っ込む」を強調しているようで。

なんというか



この片山という人はよほど優秀な人なのだろう。
色々部分的にはいい事も言っていたりするのだけれど、全体的に他人を見下している雰囲気がある。

一方で思うのは、こういった論が気持ちにひびいてしまう背景に、日本によくある「プロフェッショナルじゃなくても仕事になってしまう」傾向があるように思う。
たとえば、この記事がおそらく対象としているだろう係長・課長クラスには、たいていの会社ではそれほどたいした人事権がない。
開発プロジェクトのリーダーともなれば尚更で、ほとんどの場合は寄せ集め部隊で出発する。(それが社外/社内関係なく)
そのために、「この人は完全にプロジェクトにミスマッチなのでは」と思っても、使わなければいけないという傾向がある。
一方で、「この人がプロジェクト的に欲しい」と思っても、なかなか融通が利かない傾向もある。
これって、本来は誰にとってもとても不幸なことだと思うんだけどね。

色々読んでいると、この人も各論・実践論ではちょこちょこといい事を言っているので、そこは学んでいいだろう。
でも、この精神論まで模倣するのは、とても危ない気がした。

ここで書いてることは理想論?
うん、そう、自分の中にある理想論さ。
でも、誰かが理想論をきちんと言わなければ、誰がそれを理想論だとわかるんだい?
タグ:リーダー論
posted by 未知夢 at 18:39| 東京 ☀| Comment(0) | TrackBack(0) | システム開発 | このブログの読者になる | 更新情報をチェックする

2009年12月23日

はたして、TDDを前提として障害収束曲線が描けるのか?

前のアーティクルで自分で言及してなんだけど、ものすごーく気になったので、思考実験。
規模は数人3ヶ月を想定してみた。

従来の障害収束曲線



障害収束曲線は色々呼び方があって、最も短い呼び方ではバグ曲線とか呼んだり、Wikipediaでは信頼度成長曲線という名前で出ていたりする。
基本は「テストを重ねていけば、自然と障害検出数が低くなっていくよね。」という「現象」を取り扱ったもの。
図としてはこんな感じかな。

image001.gif

図は、製造フェーズ後にテストフェーズが「単体テスト」・「結合テスト」・「受入テスト」と分かれている事を想定している。
(テストフェーズも、現場や企業の慣習によって大きく扱いが違うので、この程度にした)

「恣意的だ」とツッコミが入るだろう部分を先に解説。

  • 件数多くね? … 過去3ヶ月もテストフェーズがある場合、これぐらいじゃなかったかな?という経験則。(件数に厳密な意味などない)
  • ブレがないね … わかりやすくするため。
  • 各テストフェーズを分けるべきだ … 自分が経験した殆どの現場では、テストフェーズ全体で障害収束曲線を測るのが一般的だったので、それに習った。
  • なんで横軸が日付なの? … 自分が経験した(以下略)。


この図で「わかる」のは、単体テストから受入テストまでしだいに曲線がなだらかになっていき、受入テストが完了するころにはほぼフラットになっている(障害検出がされなくなっている)という事だ。

CI結果を障害収束曲線に!



同じようにして、次の条件でグラフを描いてみた。

  • チーム全体がTDDを前提に開発を進めている。
  • 指標に使用したのは、CIでビルド&テストが失敗した場合に、その失敗件数を障害件数と同等として使用した。
  • CIでの自動ビルドは、簡略化のために日に1回とした。


image003.gif

描いてみてわかったこと



この縦軸に出る「件数」って、「障害」の数じゃなくて「メンバの作業ミス」の数だよね



TDDを前提とすると、少なくともCIで実行するテストは常に「すべて通るハズのもの」であり、基本的にはデグレードしないことをチェックしている側面が強くなる。
そのため、ここでなんらかのエラーが起きるのは、たいていは単純な作業ミスに帰結することが多い。だから件数も少ないし、当然、日数とともに作業に慣れてくるので、ミスも少なくなる。
作業ミスとして現れるのは、だいたいこんなところかな。

  • ビルドエラー … マージのさいのコンフリクト解消を失敗する等で、コードが一時的にコンパイル不能な状態に陥る。
  • テストエラー … 原因はいくつかからなる。

    1. テストを実行せずにコミットした。(TDDに慣れない、切羽詰っててそれどころじゃなかった等)
    2. マージのさいのコンフリクト解消を失敗した。
    3. ローカルでのテスト環境とサーバでのテスト環境とに差異があった。




また、テストエラーも、Mockをあまり使わずにテストコードを書いていた場合、共有されやすいクラスを修正するとエラー範囲が爆発的に増える傾向があり、Mockを適度に使用するとそれが収束する傾向がある。

うん、まあ、なんていうか。
障害収束曲線という代物は、TDDを前提とした開発の場合、あまりにも合わない、というところが明らかになった感じかな。

※ もちろん、元請企業が「単体テストによる障害数」を求めているときに、これらの数字を使う/使わないは政治判断だと思う。その場合でも、「この件数とは何なのか」を自分できちんと把握しておくことは大事だ。

ただし



この障害収束曲線も、「カスタマテスト」および「QAテスト」で"(有効な)チケットを切られた数"に対して行う分には、十分計測する意義はある。
その場合、よりウォーターフォールに近いか、Agile/インクリメンタル開発に近いかが、件数の大小に現れてくるだろう。

おまけ:従来型ウォーターフォール開発で本当に障害収束曲線を描くと



最後のヘビの足。

障害収束曲線って、ホントに全テストフェーズを通してこんなキレイな曲線になるの?という点。
結論を言ってしまうと、障害収束曲線があのようにキレイな線になるのは、1つのテストフェーズに閉じた場合だけで、何段階もあるテストフェーズを通してあんなキレイな線になるはずがない。

image002.gif

こんな感じに。


  • テストを律儀に実施した/適当に省いた に関係なく、各テストフェーズ内でテストを繰り返す間は、曲線は次第になだらかになる。
  • だが、次のテストフェーズに以降した段階で、今までのフェーズになかったファクターが"当然"加わるため、また曲線は急勾配を描く。
  • とくにウォーターフォールでは、顧客受入れ時の要件変更のかなりの部分が「障害」として計上されるため、その傾向に拍車がかかる。


この特徴をしっかり理解しておこう。
現場ではよく「前のフェーズでテストしたのに、なぜ今フェーズでまた障害が発生しているのか」が技術者の問題として槍玉に挙げられる。(そして障害票でしっかり「反省」させられる)
だがそれは、テストのスコープも違うし、ファクターも違うのだから、発生するべくして発生した障害でしかないのだ。

タグ:テスト TDD
posted by 未知夢 at 13:55| 東京 ☀| Comment(0) | TrackBack(0) | システム開発 | このブログの読者になる | 更新情報をチェックする

2009年12月20日

開発チーム・メンバにおけるパターンとアンチ・パターン

開発現場で出会う人をパターン化してみた。
もちろん、自分の経験の範囲なので、足りない部分も多いかと思う。
たしか、こんなのをまとめた文献があったような…?

人は時として複雑で、複数のパターン兼ね備えている人もいる。良いパターンを複数持っている場合、その人を逃さないようにしよう。
良いパターンとアンチ・パターンを兼ね備えている人は、その人の重要度から判断するしかないだろう。


パターン



ここに上げる人は、ぜひチームに一人は欲しいタイプ(ライト・スタッフ)の人だ。
正直、このような人が集まると、けっこう無茶なプロジェクトでも、なんとか乗りこなしてしまう。(日本の大規模な(WF型の)開発現場は、じつは*恥ずかしがりながら**暗黙的に*この効果に頼り切っている)

■リーダ



別名



指導者、支配者、声の大きな人(※物理的意味ではなく)

特徴



役職としてのリーダと一致するかは、現場による。
ある程度技術に通じており、プロジェクトのゴールを示せる人。
また、チーム・メンバーをうまく誘導できる人。
ある程度はスキルでカバーできる。
これを天性の才能でやってしまえる人を、自分は深く尊敬する。


■サービス・エンジニア



別名



業者、業務スペシャリスト

特徴



技術には少々疎いが、かわりに開発対象とする業務に詳しい/業務をより深く理解している人。
このタイプの人は、過去何度も同種の業務の開発を経験しているか、業務プロセスの掌握が人一倍早い。
そのため、顧客(エンド・ユーザ)から要件を聞き出すさいに、業務用語で会話ができたり、業務プロセスに敏感になり、システム化の境界面を判断できる。
ほぼスキルのみと言ってもいい。


■アーキテクト



別名



グル、導師

特徴



技術に通じているだけではなく、その思想に通じている人。
このタイプの人は、技術を設計思想的側面から掴むのがひじょうに上手く、そのため他のメンバーより素早く習得できるという特技を持つ。
そのため、顧客(エンド・ユーザ)から要件を聞き出すさいに、技術的可能性や代替案をほぼ即答できる。
また、理論が補強されているため、他のメンバーを指導するさいも手際がいい。
ほぼ天性の才能と言ってもいい。


■ファシリテータ



別名



会議の主、教え上手

特徴



じつは教え上手なのではなく、他のメンバーに「気付かせる」ことがとてもうまい人。
抱えている課題、持っている資質に気付いた人は、能動的に動けるようになるもので、そういう意味で貴重な人。
このタイプの人が活躍すると、会議や学習会といったものがとてもスムーズにいく。
そのため、顧客(エンド・ユーザ)から要件を聞き出すのも上手いことが多い。
スキル的に身につけている人もいる。


■アシスタント



別名



サポータ、お母さん

特徴



チームのメンバーのことをよく見ていて、必要なサポートを的確に行える人。
また、会議などで今チームに必要なことを自然に提案したり、実際に実践できる人。
ほぼ天性の才能だと思うが、スキル的に身につけている人もいる。


■スター・プレイヤ



別名



スーパーマン、ギーク(※敬称的意味で)

特徴



技術に通じており、他のメンバーより数倍早く・上手くプログラムを設計していける人。場合によっては、特定の言語などに特化している人も多い。
技術のトレンドにも通じているが、時々通じ過ぎていてスケープ・ゴート化している人もいる。
このタイプの人が一人いるだけで、プロジェクトの進み方がかなり違うし、コードの整理のされ方もかなり違ってくる。
完全に天性の才能なため、とても貴重な人。このタイプの人は絶対にプログラムから離してはいけない。


■ムード・メーカ



別名



チア・リーダ、マスコット、ピエロ

特徴



チームの雰囲気をよい方向に変え、他のメンバーから慕われている存在の人。
このタイプの人がひと言口にするだけで、場の雰囲気がとても和らき、時に前向きに元気にさせる。
完全に天性の才能なため、とても貴重な人。多少プログラム設計能力が劣るからといって、追い出してはいけない。


■プログラマ



別名



コード・メーカ

特徴



スーパー・スター程ではないが、プロジェクトの対象とする技術に通じており、プログラム設計に長けている人。
このタイプとスター・プレイヤーとをチーム/バディにすると、時としてとてつもない相乗効果を発揮する。
反面、自分の持つ技術以外に対しては、意外に興味を持ってなかったりもする。
いわばチームの裏方と言ってもいい。


アンチ・パターン



これから上げるタイプは、はっきり言ってチームに障害をもたらす人だ。
もし人事権を持つならば、早目に解放した方がいい。
人事権がない/じつは立場上は上司といった場合は、ひたすら耐えるしかないのが辛いところ。

■コーダ



別名



人数合わせ、奴隷

特徴



言われた事をただこなすことを得意とする人。残業や徹夜を打診すると、素直に従う。
全体的に、作業時間は突出して多くなる傾向があるが、それに見合った生産性は期待できない。
プログラムを設計できないのもこのタイプで、指示通りに書くことを得意としている。
逆に言うと、指示しないとやらない。
しかたなく使う場合も多いが、進捗がシビアな場合は解放した方が良い結果になる。


■フォリナ



別名



部外者、傍観者

特徴



なぜか達観した態度をとる人。ときに強い皮肉を伴っていることもある。
自分の意見を主張するわけでもないため、位置づけ的にはコーダタイプに近いものがある。
もし他メンバに悪い影響があるときは、解放することも考えよう。


■ローン・ウルフ



別名



一匹狼、人嫌い

特徴



他人に溶け込むのをとことん苦手とする人。
ときにコミュニケーション不全で障害を出してしまうこともある。
ひじょうに疲れるが、このタイプの人と一緒に仕事をするときは、あらゆる手段で意思を伝え、汲み上げる必要が生じる。
もし他メンバに悪い影響があるときは、解放することも考えよう。


■ミスマッチャ



別名



場違い、畑違い、○○畑の人

特徴



開発対象に疎く、技術的にも疎いが、なぜかアサインされてしまった犠牲者。
プログラマタイプの人も多いが、大体において習得するよりも先に進捗の悪さが露呈してしまう。
コーダタイプの人物の場合は要注意となる。
なるべくプロジェクトから解放してあげた方が、お互い幸せになる。


■フォーチュン・テラー



別名



不安屋、諦めた人

特徴



何が原因かはともかく、プロジェクト/チームに対して強い絶望感を持った人。
無茶なチーム運営の犠牲者である場合も多いが、元々の思考的にこうなっている人もいる。
このタイプはそのネガティブな雰囲気を周囲に撒き散らし、巻き込んでしまう。
パターンに上げた人がこちらの側(ダーク・サイド)に転化してしまうと、そのインパクトは大きい。
なるべく早くプロジェクトから解放してあげよう。


■トリックスター



別名



反抗期、天邪鬼

特徴



なぜかチームの方針に事あるごとに楯突く人。
このタイプは、チームやプロジェクトが上手くいっているかよりも、自分の考えていることが反映されているかを最重要視する。
その考えもコロコロと変わる場合、他メンバーを翻弄して疲弊させる。
なるべく早くプロジェクトから解放しよう。


■スタンピード



別名



暴走、暴徒

特徴



プロジェクトやチームに関係なく、自分のやりたい事をやり出してしまう人。
これも無茶なプロジェクトチーム運営による犠牲者の場合も多いが、自分の技術力を誇示したいだけの場合もある。
ローン・ウルフタイプを伴い他メンバから倦厭されたりする。
プロジェクトと関係ない事をやっているだけなら利も害も生まないが、プロジェクトに関係するところをやり出すと被害を出しかねない。
なるべく早くプロジェクトから解放しよう。


posted by 未知夢 at 15:46| 東京 ☀| Comment(0) | TrackBack(0) | システム開発 | このブログの読者になる | 更新情報をチェックする

2009年12月18日

なぜUnitTestは理解されない?

TwitterでこんなTweetが流れた…
エビデンスとしてNUnitのGUIのスクリーンショットと、対応するテストコードが含まれている部分のVSのスクリーンショットを取る作業が終りません・・・

UnitTestのエビデンスって…なに?



一般的にテストのエビデンスというと、次の2点を指す。

  1. テスト手順を明らかにするもの(ex. テスト設計書、テスト仕様書、...)
  2. テスト結果の証拠(ex. 画面ハードコピー、DBスナップショット、...)


UnitTestでは、これはこのように解釈できる。

  1. テスト手順を明らかにするもの = テストコード
  2. テスト結果の証拠 = 今実行すればテストが全てグリーンになること


これがなぜか理解されず、軋轢とストレスと大きな工数追加になっている現場がずいぶんある。
なぜUnitTestはいつまでも理解されないのだろう。

余談。これらのことは、Seleniumなどを使って反復可能なテスト(一応結合テストにあたると思う)を実施する場合にも当てはまるようになる。

微妙に食い違う認識


テスト実施の時期に対する認識



テストを実施する時期…古典テスト方法では、これはいつでも「テストを実施した時点」であった。これがテスト自動化の登場・一般化で覆された。
自動化され反復可能になったテストでは、テストを実施する時期は「いつでも」になった。つまり「今動くこと」が重要になったのだ。
これがパラダイム・シフトになった。

従来の手動駆動テスト手法



  • テストを実施したタイミングでのエビデンスが、必ず残っていた。
  • そのエビデンスは必ずエラーを含み、実施を重ねるごとにエラーが少なくなっていく現象が見えた。
  • テスト・エビデンスを追うことで、時点ごとに(スナップショット)「テストがどういう結果になったか」をチェックできた。
  • 障害収束曲線(ほらこれだ!)を「計測」でき、それによって「テストの充実度」を間接的に観測できた。


反復可能なテスト自動化



  • テストは常に動いているため、今現在のエビデンス(オール・グリーン)以外(要するに過去の結果)は重要ではなくなった。
  • テストは常に動かせるため、コード作成とともにテストするように手軽になった。
  • コード作成とテスト実施を同時に行うため、コードの完成と完璧なテストが同じタイミングで揃うようになった。
  • 障害収束曲線は決定的に意味がなくなった。


コードというものが何かという認識



ここには、古くはクヌース先生等の時代から続く宗教戦争の歴史がある。

従来の、とくにウォータ・フォール型開発においては、コードというものは「最終成果物」であり、それは「製造」の結果でしかないとみなされる。
製造物のクォリティは「テストを通るか(条件を満たしているか)」のみが重視され、コード内部の整合性についてはほとんど重視されないようになった。
この視点で見た場合、UnitTestのような「コードで記述されたもの」は「余計(余分)な成果物」以外の何物でもない。

しかし一方でこれを戒め、「コードは一番詳細で唯一実行可能な設計書である」とする一派が従来からいた。この従来からある主張が、UnitTestの登場で大きく花開いた。
コードの設計書的側面が、テストによって補強される現象がおこった。
TDD/BDDでは、コードはテスト可能なまでに整理されることが前提となり、実施者は誰もが整理されたコードを書くようになった。(よく逆に考える論者(きれいなコードを書ける技術者しかTDD/BDDは実践できない)がいるが、それは違う)
そして、テスト・コードがインタフェースの詳細な仕様を表明するようになった。これがどのようなコメントよりも有言なことが確認されるやいなや、いわゆる詳細設計書を駆逐するのはおろか、コメントさえも駆逐しかけている。

何にバグが潜むのかという認識



ソフトウェア開発で不文律とされているものに「コードにはバグが存在する」というものがある。これには誰も異論がないだろう。

手動駆動テスト手法においては、その反復性の低さから「すべてのコードにはバグが存在する」という認識が強い。
バグが発生した時にそれを修正するとおこる、デグレードという現象もこの認識を補強することになった。
この認識に立っている人物は、UnitTestによるテスト・コードにもバグが潜んでいるのが当然だ、という見方をしている。テスト・コードは信頼できないものにしか見えない。

テスト自動化で反復可能になると、それが肌で感じられるほどに明らかになったことに「テストしていないコード・条件にこそバグが存在する」ということだ。
デグレードはヒューマン・ミス以外にはほぼ発生しなくなった。
この認識に立てると、コードの完全性をテスト・コードに依拠するようになる。そして、ガンガンとコード改善に手を出せるようになる。

テスト・コードにはバグはあるのか



はたしてテスト・コードにバグはあるのか?
以下の視点でみた場合、テスト・コードにしても相変わらず"バグ"はある、と言わざるをえない。

  • テスト内容に抜けが発生する可能性がある。
  • テスト内容に間違いがあり、その間違いを見逃す可能性がある。(偶然に結果が一致する場合に多い)


だが、これらはUnitTestだから起こるという類のものではなく、手動駆動テスト手法においても、十分起こり得るものだ。
そのため、これをもってUnitTestを無効だと主張するのは無理がある。

そして重要なことだが、次の点は完成した状態のUnitTestでは起こらない。

  • テストが動かない。
  • テストが誤動作する。


なぜ起こらないと宣言できるのか。それは、UnitTestにおいてはテスト・コードは100%通るからだ。カバレッジ率100%というのは実コードではなかなか難しい課題だが、テスト・コードにおいては誰でも完璧にその状態にできる。
そしてもうひとつ、テスト・コードは従来にないほど繰り返し実行される。この反復実行がまた、テスト・コードを頑強にする。

開発者は都合の悪いことには目をふさぐ?



よく言われる批判のひとつに、「開発者は都合の悪い部分をテストから無意識に排除する性質がある」というものだ。
だが、これらは原因がはっきりとしている。

  1. そもそも気づいていない。
  2. インタフェースに対する認識の低さから、インタフェースを満たすようなテストを行えてない。
  3. 反復性の低さから、一度通ったテストを省略する衝動に駆られる。


最初の問題はもう、どんなテスト方法をとっても検出はムリだ。
二番目の問題は技術者の一定の訓練・経験を必要とするが、UnitTestの方がダラダラ書きができなくなりインタフェースへの意識が高まるため、UnitTestを行うことでより強力に訓練できる。
三番目の問題は反復性を高め常時実効するUnitTestではおこらない。


どう立ち向かうか



味方にしてしまおう



まず、理解していない人には十分に反復テストを理解してもらう努力をする必要がある。

  • UnitTestの場合は、それが「単体テスト」であり、手でやってもコードでやっても開発者が主体でテストしている事に変わりないことを理解してもらう。
  • Seleniumなど結合テストの自動化の場合は、従来テスト設計書でシナリオを用意してやっていたことを自動化しているにすぎないことを理解してもらう。


そのために、次のように働きかけるのはどうだろうか。

  1. まずテスト・コードを見てもらい、どの部分がどのような事をやっているか概要を説明する。
  2. じっさいにテスト・コードを実行し、テストがすべて成功する瞬間を見てもらう。
  3. 目の前でTDDを実践し、テストが失敗から成功に移り変わる様子を見てもらう。


現場に近い人間ほど、上記を目の前にし「TDDを体験」することで認識を改めてくれる傾向がある。
残念ながら、現場から遠くなるにつれてその人物のアンテナの感度がより重要になってくるようだ。

CIサーバを立てよう



Hudsonのような本格CIサーバでもいいし、スケジューラでバッチを使ってAnt(NAnt)を定期的に実行するようにするのでもいい、またAntを手動起動するのも手だろう。
とにかく、次の手順を自動化してしまう。

  1. ビルドを実施する
  2. テストを実行する
  3. テスト結果をHTML形式で出力する(最近のUnitTestとAntの組み合わせではほとんどのもので可能なはず)


これだけで、テスト毎にエビデンスを残すとか障害収束曲線の判断元がほしいといった要請には対応可能だ。

また、Seleniumなどは画面ごとのスナップショットを保存するような改造もWeb上で公表されている。積極的に活用しよう。

結合テストを強くする



自動で結合テストをしようが、手動駆動テスト手法で結合テストをしようが、結合テストという視点は大事だ。
Agileではこの時に顧客サイドに使用シナリオを書いてもらう、リアルなテストを行うプラクティスがある。
個人的には、より結合テストを強固にするためには(予算との兼ね合いもあるが)、これに加え、やはり「危険な匂いを感じ取れる」職人気質なテスト技術者を招きいれ、シナリオ作成に参加してもらうのが良いと考えている。
またそのうえで、反復しないテストの実施を職人テスト技術者に行ってもらうのがより望ましい。
これをモンキー・テストと言ってバカにする傾向もあるようだが、やはり人間は、実際にアプリケーションを使ってみて初めて気づく、というものがある。
ただし、これを行う場合、テストに失敗したものは自動テストシナリオに組み込む、というタスクを忘れてはいけない。

最近の経験から



最近の経験で、技術者たちの頑迷な強い抵抗に合い、UnitTestを導入できない、という事があった。
仕方なくUnitTestを捨て、従来のようにテスト・フェーズを厚くする手法に切り替えた。(顧客の強い要望により、WF形式での開発だった)
その結果、何がおこったか。
メンテが難しいほどに長い「メソッド」の乱立。
バグを修正するたびに起こるデグレード。
いつまでも終わらないかに思えるテスト・フェーズ。

システムは苦心惨憺の末に大改造して納品した(あらためて書き上げたUnitTestと一緒に)。だが、短い開発期間だっただけに、この時の開発-テスト・フェーズは完全に失敗だった。

TDD/BDDを実践しようとしている人は、それが絶対的に正しい行為だと自信を持ってほしい。
結合テストの自動化を目論んでいる人は、それが絶対的に正しい行為だと自信を持ってほしい。
それはシステムを迅速に仕上げる助けになるだけでなく、システムの品質をより高みに置こうとすることなのだから。
タグ:Agile応援団
posted by 未知夢 at 12:46| 東京 ☀| Comment(1) | TrackBack(0) | システム開発 | このブログの読者になる | 更新情報をチェックする

2009年12月17日

原点

本当に久々の更新。
自分が腐りそうだから、というのは内緒。

自分のプログラムの原点。

最初は中学生のころ。ファミコンが普及し、売れまくっていた時代。古いね。
当時、友達がそのファミコンを手に入れ、一緒にソフトを一本買った。
スーパーマリオだ、なんだと周りが騒いでいた時にそいつが買ったのが、「ファミリー・ベーシック」だった。どうにも渋いね。

でも、それがコンピュータ初体験な二人には新鮮で、二人して雑誌とにらめっこしてソースを打ち込んだり、ソースの改造をしたりして明け暮れた。
上半身がマリオで下半身が戦闘機のヘンキャラを作ったりとかねw
当時はゲームも作ろうとしたけど、そこまでの力がお互いになくて断念したな。たしか疑似3Dシューティングができないか?とかムチャなことを考えていたようなw
でも、コンピュータの動作を自分の意思で変えられる、制御できる、という魅力にこの時とり付かれたのは確かだ。

高校に入って、ムリしてMSX2を買った。自分の全財産で。当時はいた彼女にモーレツに怒られ、すねられたのは余談w
当時はMSXマガジン、MSXfanという2大専門誌が発行されていて、MSXはちょっとした盛り上がりを見せていた。
とくにMSXfanで流行っていたのが、1ページプログラミング。あらゆるテクニックを使って1ページに収まる量にコードを縮めるその遊びは、ときにマシン語が入り、ときにそれをVRAM展開し、といったひじょうにこった物が多かった。
当時はただただ「世の中には凄い人達がいるな、こういう人がプロになるんだろうな」と思いつつ、サルのようにソースを打ち込んでた。

その中に、「ホンモノのプロ」が作った、パズルゲームのちょっと長めのソースが公開されたことがあった。
「なんだこれ?」読んでみて落胆した。
「俺にも読めるし、この程度だったら書けるよ。プロってこの程度?」
そう、そのソースはあまりに読みやすかった
そして、実行速度もさほど悪くはなかった。
とりあえず打ち込んだ。
遊び倒した後は改造した。なにせ自分で書ける程度のソースだ、手を出さないわけにはいかない。
キャラを変え、ルールを変え、とにかくごちゃごちゃといじった。やがてソースは汚く変形していき、改造不可能になった段階で放り出した。

このプログラムと出会えなかったら、たぶんコ業界に入ろうなんて思わなかっただろう。
そう思わせたのは、Cを学び出してからだった。
ようこそ、構造化プログラミングの世界。すべてを整理整頓できる世界へ。
ロジック本を読んだ。プログラム書法を読んだ。無我夢中で吸収した。そして気づいた。
そうか、わかりにくいテクニックを駆使するのではなく、わかりにくいロジックをなるべくわかりやすく書く、それができるのがプロなんだ!
何かが変わった。プログラムに対する姿勢だろうか。その時、あの「ホンモノのプロ」がつくったソースの偉大さを知った。
十分にわかりやすく、そして十分に実用的。単純なBasic文だけを使い、それを果たしていたのだ。
それを弄繰り回して冒涜していた自分の行動に笑った。
快くソースを公開したプロの心意気に感じ入った。おそらく、当時のやもすると裏技的テクニックだらけが推奨されるような印象のあったアマチュア・プログラマーに、何かを伝えたかったのだろう。ソースのかたちで。

これが自分のプログラムの原点。
もうプロの道に足を入れて、長い月日が経った。
自分ははたして、あの時のプロに追いついたのだろうか?
posted by 未知夢 at 12:21| 東京 ☁| Comment(0) | TrackBack(0) | システム開発 | このブログの読者になる | 更新情報をチェックする

2008年03月12日

"彼ら"と"我々"のチガイ(マネジメント編)

  • "彼ら"は契約とその履行を第一に行動する。
  • "彼ら"はプロジェクトを「自らの責任で失敗させたくない」と考える。
  • "彼ら"は理想からの乖離で全てを測る。
  • "彼ら"はプロジェクトメンバーを管理する。
  • "彼ら"はプロジェクトメンバーをも数で管理する。
  • "彼ら"は進捗をパーセンテージで知ろうとする。
  • "彼ら"は数値を溺愛する。
  • "彼ら"は未決事項をあいまいにして進めることを好む。
  • "彼ら"はチームメンバーを統率・監督する。
  • "彼ら"にとってモチベーションとは個々人の問題にすぎない。
  • "彼ら"のチームに対する静的な接し方は軋轢の元になる。
  • "彼ら"はチームメンバーが勝手な事をして予測不能性が高まる事を恐れる。
  • "彼ら"はKLOC等でプロジェクトを定量的に予測しようとし、結果を予測に合わせようとする。
  • "彼ら"は新しいものや概念を導入することを極端に嫌う。
  • "彼ら"にとってコスト意識とはいかに期限内に最小の人員・資源構成で完成させるかでしかない。
  • "彼ら"にとっての仕事とは、ほぼ100%デスクワークだ。

 

  • "我々"は顧客とその満足度を第一に行動する。
  • "我々"はプロジェクトを「何がなんでも成功させたい」と考える。
  • "我々"は現実で全てを測る。
  • "我々"はプロジェクト自身をマネジメントする。
  • "我々"はプロジェクトメンバーの状況・状態を常に気にする。
  • "我々"は進捗を実際の出来高で知る。
  • "我々"は数値を従える。
  • "我々"は未決事項をも含め、物事を確実にしながら進める。
  • "我々"自身もチームメンバーの欠かさざる一員である。
  • "我々"にとってチームの動機付けとはなによりも大切にすべき原動力だ。
  • "我々"はチームが求める事を常に考え、ファシリテーション・ゲーム・コーチング・インタビューと、必要だと感じたあらゆる事を実行する。
  • "我々"はチームメンバーの自発的なプロジェクトへの関与を歓迎し、奨励する。
  • "我々"は成果物の規模に関する予測値はどうやっても「予測」の域を出ない事を知っていて利用する。
  • "我々"はそれが古かろうが新しかろうが、チームにとって役立つなら躊躇無く導入する。
  • "我々"にとっては効果的で的確な開発を行い、顧客の利とする事でWin-Winの関係を築き上げ、常に次に繋げることこそがコスト意識だ。
  • "我々"はかなりの時間をかけてチームの中をフィールドワークし、その合間にデスクワークをこなす。
続きを読む
posted by 未知夢 at 00:44| 東京 ☀| Comment(0) | TrackBack(0) | システム開発 | このブログの読者になる | 更新情報をチェックする

2008年03月11日

"彼ら"と"我々"とのチガイ

  • "彼ら"にとってはプログラムはマシンへの命令そのものだ。
  • "彼ら"はプログラムをマシンへの命令の組み合わせのように書く。
  • "彼ら"のコードは良くてコメントだらけ、悪いとわけのわからない呪文になる。
  • "彼ら"は条件分岐やループが大好きで、まるで魔術師のようにそれを操る。
  • "彼ら"はモジュール/クラスをつくる事を厭う。
  • "彼ら"はシステムの表層を考えるだけに終わらせたがる。
  • "彼ら"はひとのコードを読まない。
  • "彼ら"は書いているコードを他人に見せたがらない。
  • "彼ら"は仕事だから言語を覚える。
  • "彼ら"は言語の新しい仕様を暗記すべきめんどくさいものと捉える。
  • "彼ら"は仕事だからプログラムを組む。
  • "彼ら"は自らをSEと呼んだりSIerと呼んだりなにかと差別化を図りたがる。

 

  • "我々"にとってはプログラムこそがソフトの最終的な設計書だ。
  • "我々"はプログラムを文章のように書き、マシンへ行わせたい事が明確にわかるように書く。
  • "我々"のコードはコメントが最低限あればよく通じ、文書のように読める。
  • "我々"は条件分岐やループをなるべく減らそうと親の敵のように平坦にする。
  • "我々"は適度に細分化された状態のモジュール/クラスが好きだ。
  • "我々"にはシステムの仕組みを考える事がまたいい刺激になる。
  • "我々"は悪文も最良のコードも同じように読みこなし、最良のコードに感動する。
  • "我々"は常に隣人の・向かいの・そして未来の他人の目を感じながらコードを書く。
  • "我々"は好奇心に心をふるわせて言語を覚える。
  • "我々"は言語の新しい仕様が出てくるとその背景に想いを馳せる。
  • "我々"はプログラムを組む事自体がまた楽しい。
  • "我々"はプログラマであると胸を張って言える。
続きを読む
posted by 未知夢 at 01:09| 東京 ☀| Comment(0) | TrackBack(0) | システム開発 | このブログの読者になる | 更新情報をチェックする

2007年03月22日

設計書の限界

およそ世の中にはいろいろな設計書があるけれど、一貫して設計書に求められる事は次の点だろう。

  • 要求が満たされている事

  • 実現可能である事

  • システムの動作が要約されている事


しかし、設計書は時として嫌われ、役立たずの烙印を押される。
そんな嫌われる設計書とは、こんな感じのものだ。

  • 要求が漏れていたり、追加された要求が反映されていない事

  • 実現可能性が薄い仕様が記述される事

  • しばしばシステムの動作とはかけはなれた内容が記述されている事



そもそも設計書がこのような状態に陥りやすいのは何故か。

続きを読む
posted by 未知夢 at 01:04| 東京 ☀| Comment(2) | TrackBack(0) | システム開発 | このブログの読者になる | 更新情報をチェックする

2007年03月16日

プログラムは設計

前置き
べつにここで設計書不要論を立ち上げようという意図は(毛頭)ない。

コードは設計書であり、プログラムとは設計という行為そのもの。
だからこそ、合理的に書くこと、書くように努力する事が強く求められる。

  • 構造が合理的

  • 他人が見て読める

  • 適切なレベルで抽象化され、詳細化されている


これらを満たしてこそ、プロが設計したと言うにふさわしいプログラムと言えるだろう。
(ただ動けばいいのであれば、そこらへんのアマチュアの方のほうがずっとうまく書けるものだ、とも自覚すること)
続きを読む
posted by 未知夢 at 00:17| 東京 ☀| Comment(1) | TrackBack(0) | システム開発 | このブログの読者になる | 更新情報をチェックする

2007年03月10日

設計書って、なんだろう?

まず、自分なりに設計書の定義をしてみる。
業界に限らず、建築業、加工業、色々な場所で設計書が活躍している。
それらに共通する点は、こんなところだろうか。
  • 構造が明らかになっている。

    • 動作するものは、その動作も明らかになっている。

  • 多少の専門性は必要だが、人が読んで理解できる。

  • 様々な段階で適度に抽象化されている。

    • また逆に、細部まで詳細化されている。


続きを読む
posted by 未知夢 at 15:27| 東京 ☀| Comment(0) | TrackBack(0) | システム開発 | このブログの読者になる | 更新情報をチェックする

2007年03月07日

業界の実態

IT Proの「記者の目」で、面白い記事が上がっていた。
「IT業界の“イジメ”の実態を紹介」
続きを読む
posted by 未知夢 at 12:13| 東京 ☁| Comment(0) | TrackBack(0) | システム開発 | このブログの読者になる | 更新情報をチェックする

2006年01月15日

あたりまえの事だけど

「わからない事」がある場合、本人が一番自覚している。
「知らない事」がある場合、本人もそれを自覚できない。
続きを読む
posted by 未知夢 at 00:00| 東京 🌁| Comment(6) | TrackBack(0) | システム開発 | このブログの読者になる | 更新情報をチェックする

2005年12月09日

つかれるのぉ〜

いやもうね。
人の話聞かない人って、疲れる。
ホント。

ぶっちゃけグチなんだけどね…続きを読む
posted by 未知夢 at 00:27| 東京 ☀| Comment(1) | TrackBack(0) | システム開発 | このブログの読者になる | 更新情報をチェックする

2005年12月08日

「Webデザイナー」って…

世の中ってけっこうイイカゲンにできてるようで。
いわゆるIT業界(イヤな呼びかただよな)にも普通の開発者となんちゃって〜な「開発者」がいるように、仕事で時々関わるWebデザイナーさんにも、よくできた方と、なんちゃって〜な「Webデザイナー」が、これまた律義にいるんだよねぇ。

続きを読む
posted by 未知夢 at 00:21| 東京 ☁| Comment(0) | TrackBack(0) | システム開発 | このブログの読者になる | 更新情報をチェックする

2005年05月10日

プログラマとセキュリティ

職場でウィルスメールが蔓延。
まてこら、ダレだよ、おい(-_-;

開発者って、意外とセキュリティ意識が欠けてる(or欠如してる)んだよなぁ。
前のプロジェクトでも数度ウィルス騒ぎあったし。
て、完全にローカルに閉じているハズのLAN環境で、なぜあんなに何度もウィルス騒ぎが…
今もって不思議だ(汗)
続きを読む
posted by 未知夢 at 00:45| 東京 🌁| Comment(0) | TrackBack(5) | システム開発 | このブログの読者になる | 更新情報をチェックする

広告


この広告は60日以上更新がないブログに表示がされております。

以下のいずれかの方法で非表示にすることが可能です。

・記事の投稿、編集をおこなう
・マイブログの【設定】 > 【広告設定】 より、「60日間更新が無い場合」 の 「広告を表示しない」にチェックを入れて保存する。


×

この広告は1年以上新しい記事の投稿がないブログに表示されております。