nDiki : 意思決定

コミュニケーション プロジェクトマネジメント メール リーダーシップ コミットメント 電話 ソフトウェア ADSL すごい会議 故障 社長 スプリッタ 書評 リスク 会議 モデム 問題解決 情報共有 レンタル アイデア ポイント コミットメント・リスト お薦めの本 プレゼンテーション ライセンス 東京都 ガイドライン ソフトウェアプロジェクトマネジメント バグトラッキングシステム 2002年

■ トム・デマルコ ゆとりの法則 - 誰も書かなかったプロジェクト管理の誤解

今年の1月からプロジェクトマネジメントをいくつか担当することになったのだが、まだまだ経験不足。 ということで遅ればせながら、「ゆとりの法則」を読み始めた。 誤った方向にマネージメントを進めていく前に手に取ってよかった。

社長からの「何をやっていいのかわからないスタッフがいるのでどんどん指示を出して、遊んでいる時間(指示待ち時間)を作らないようにして欲しい」というリクエストに違和感を感じていたのだが、この本の中にはその違和感が何かが説明されているようだ。

「適応型ソフトウエア開発」でも管理するのではなくリーダーシップをとってコラボレーティブにプロジェクトを進めていくといったような事が書かれていたと思う。

頭では理解しているのだがなかなか実践できない。 プロジェクトのスケジュールをにらみつつ、またチームをまとめつつ意思決定を下していく技術を身につけなくては。 一技術者としての能力を向上も忘れずに。

• ゆとりの法則

[ 書評 ] [ お薦めの本 ] [ コンピュータ書籍 ]

• 早朝会議革命 - 元気企業トリンプの「即断即決」経営 (2005-07-16)
• ピープルウェア読了 (2004-05-25)
• TQ 読了 - ちょっとずつ実践中 (2005-07-08)
• Joel on Software - 必読書 (2008-08-14)
• トム・デマルコ ピープルウェア 第2版 - ヤル気こそプロジェクト成功の鍵 (2004-05-13)

■ すごい会議の正しい手順

すごい会議FAQによると、付録の手順には誤りがあるらしい。

「最初の1、3、5が準備段階で一人でやる部分で、2からが参加者と一緒にやる部分」 すごい会議FAQより。

とのこと。すっきり!

• 手順5がミーティング前に行うというのは自明なのでミーティング時にはパスしていた(事前の招待メール時に適用)。
• その前に手順1、手順3 がくる事で手順5がパワフルかつ明確にできるようになると。
• 手順3。どおりで出席者が悩むわけだ。今回は既に走っているプロジェクトのメンバだった事からある程度方向性を共有していたのでそれなりに書けていたんだけれど、これは1人でやる手順なワケね。手順3と手順9がかぶっていて進をちょっと迷ったのだが、これですっきり。

@ 答えを作らない場所

また次の点も非常に参考になった。

ここでは、手順6、7、8は答えを作る場所ではないのです。 問題を前向きな形でたな卸しするだけです。 「答え」を提示する人がいたら、それはストップします(経営者自身がやってしまいそうになることも多くみます) ここで、誰かが「答え」を言ってしまうとドチッラケなのです。その答えが、各自、意識的または無意識のうちに手順11でコミットメントとしてその解決策が約束される可能性を最大化するためにやっているとお考えください。-- すごい会議FAQより。

もしや、思いっきりドッチラケだった?

さすがに手順8では答え作りしなかったけど、手順6、手順7では思いっきりアイデア出しに利用しちゃってたからなぁ。

• 初期の頃やっていたミーティングでは、手順6までしか時間的に進まなかったこともありそこでコミットメントに落としてしまっていた(担当と期日設定)。
• 先週の木金でやったミーティングでは、全手順を通してやるために手順6、手順7ではアイデア出しまでやった後、先に進めてみた。手順11でコミットメントを作る際、手順6、手順7で上がったアイデアを漏らしてしまわないかちょっと心配だったんだけれど、もともと答を作る場所でなかったのでなければ構わなかったということか。

@ リストにしてオシマイ

光栄な事にまた著者の大橋禅太郎氏よりコメントをいただいた。

初期のころの「この会議で達成したいことはなにか」を発表してもらってから、司会者がどうすればいいか? といったところがありましたが、司会者は特にそれについてはなにもすることはありません。そのほかにもグループとしての統一した「意思決定」がなくても進むやつは、リストにしてオシマイです。

ありがとうございます。非常に参考になります!

手順を眺めてみると、参加者と一緒にやる部分のうち前半はリストにしておしまいだ。確かにすごい会議の本文でも、実際に出席者が順に発言するところが描かれているけれどそれ以上は書かれていない。

そこに書かれていない何かをしているんじゃないかなとも思ったのだが、本当にリストアップだけで良かったのか。安心。

となると合意は

• 戦略的フォーカス
• 担当分野と担当
• コミットメント・リストと、そのチェックのしくみ

となる。

やはりすごい会議は最後の手順までやらないとオイシイところが食べられないわけだ。 ふむふむ。

はやく次のすごい会議の機会こーい。

• すごい会議で、どの手順で前のどの手順を参照する? 何を記録しておく? (2005-07-07)
• 「すごい会議」をしてみる (2005-05-27)
• すごい会議はじめての全手順(1/2) (2005-06-30)
• 「すごい会議」2度目 (2005-06-03)
• すごいKPT事後評価セッション (2005-10-07)

■ 早朝会議革命 - 元気企業トリンプの「即断即決」経営

トリンプの吉越浩一郎社長による「会議を通したスピード経営」についてを、会議出席や社員へのインタビューを通して著者がまとめあげた1冊。

会議を中心とした内容であるが、「すごい会議」と同様ただ単に会議手法を述べた本ではない。 会議を通した経営についてが述べられている。

同社のMS会議 (Marketing and Sales 会議) は吉越社長が自部門の改革として始め、粘り強く改善・継続して全社的なものになったもので、そう簡単に真似ることができるものではないが、そのエッセンスには学ぶものが多い。

@ 朝開催

• 多くの人間が集まる時間帯。
• 集中できる時間。
• 同日に即行動に移せる。

特に最後のは魅力的。やる気がみなぎっている間に行動に移せる。 しかし、自分はオフピーク通勤が気にいっているからなぁ……。

@ 毎朝開催

当然週1回よりスピードがある。

回数は多いが、きちんと問題について意思決定しコミットメントに落としていくので無駄がない。

@ トップダウン

ただし民主的、フラット。

@ 「決める」会議

• 「誰が、何を、いつまでに」

ここら辺はすごい会議と通じる。

@ デッドライン

• ドイツ系の会社から。
• 厳しく。でないとみんな逃げる。
• 最大限で1週間。それ以上はスケジュール化。
• 稚拙でもいいから速く。

毎朝会議が開催され議論されることで、1週間でまわしていける。

@ プレゼンテーション

• プレゼンテーション自体を目的にしない。無駄に準備に時間をかけない。

@ コミュニケーションの場・情報共有の場

• 「和」を形成。
• 共通認識が広がる。
• 判断・決断までのプロセスを共有。プロセスから参加することに意味がある。
  • 意思決定に変化があっても理解できる。
  • 教育の場
    • 技は盗むもの。「教育なんてほんとはできっこない」。
• オープン、フェアネス。

見習いたい。 どのようにすれば我社で判断・決断プロセスから共有していけるようになるだろうか。

@ 継続

• 継続はトップの責任
• 改善こそ継続の母
• 成功するまでやれば、成功する。p.207

@ 結論から言え

• 言いにくくても、結論から言え。p.207

@ 感想

「決める会議」、「誰が、何を、いつまでに」という方針のメリットを再確認。

• 早朝会議革命 - 元気企業トリンプの「即断即決」経営

[ 書評 ] [ お薦めの本 ]

• すごい考え方 (2005-12-10)
• トム・デマルコ ゆとりの法則 - 誰も書かなかったプロジェクト管理の誤解 (2004-04-17)
• すごくない会議 (2005-06-29)
• このやり方でやると「すごいこと」が起きる。 (2005-06-08)
• 一緒に仕事をしたい人のタイプ (2006-03-17)

■ ソフトウェアかんばん「見えない化」

チームメンバが重なっている2005年度の2つのプロジェクトがほぼ終了したので、事後評価セッションを開催。

興味深いポイントについて:

@ ソフトウェアかんばんが見えない

今回1つのソフトウェアに対してソフトウェアかんばんを適用した。 担当開発者の2人は以前このコンビで別のソフトウェアでかんばんを使用し、コラボレーションが促進したのだが、今回はどうもイマイチであった。

先日のレイアウト変更で、タスクカード/ストーリーカードを貼る(座っている場所から見える)パーティションが無くなってしまったのが敗因と推測されている。

ぐらさん言わく「見えない化」

@ issue tracking

開発中に発生する

• モジュール間のインタフェースの問題点(あるいは不明点・疑問点)などの確認/議論の必要なもの
• ライセンス関連の問題など意思決定を要するもの

などについて誰かが指摘した後、迅速・確実に処理がなされないことが多かったという意見も多かった。

後半「コミットメント・リストチェックを電子上での各自チェックに切り換え」たことにより、皆が頭を突き合わせて真剣に意思決定する場が減ったのが大きなマイナスだったか。 その方式は2月に終了したスタッフが2拠点に分散したプロジェクトで成功した方式で、うまくいったので導入してみたのだが、このチーム向きではなかったようだ。

やはり基本は顔合わせということを実感。

またコミットメントではないけれど、細かい issue を追跡する仕組が必要かなと。 ツールに走って issue tracking system 導入して遊ぶという手もあるが、手段が目的になってしまいそうでもある。

どのようなプロセスがチームに向いているのかも含めて、ここはひとまず紙ベースでいろいろ試行してみようと思う。

できるだけシンプルにして、各自が自分の好みのツールと連動して処理していけるようにするようにしたい。

(というか、自分は自分の GTD プロセスとスムーズにやりとりできるようにしたい。)

@ インタフェースを変更するなら、古いのも deprecated 扱いで残して

複数人開発で途中開発者間にまたがるインタフェースの仕様が何回か変更になった。 改良のために仕様変更はアリだと思うが、コード変更に愛情が足りなかったため実行できないコードが断続的に発生し、確認のための開発待ちが発生した。

通常開発中のコード内でのこのようなインタフェース変更については

1. インタフェースを変更する人が、同時に呼出し側のコードも修正してコミットする
2. しばらくは古いインタフェースを @deprecated で残しつつ、新しいインタフェースを提供する

のどちらかを取りかつ周知をする必要があるが、この辺がうまくできていなかった。 次回はうまくやれるはず。

ちなみに「できるだけ早く仕様を決定するようにする」というアイデアも出たが、これはまず守られない。もちろんみんなそれを望んでいるし、そのように努力しようとするんだけれども、最初の時点で完全な仕様を決定できることはほどんどない。仮にその時点で完全でも、数ヶ月後には状況が変わり仕様がふさわしくなくなってしまっていることもある。 無理に最初の仕様に固執することの方がデメリットが大きいことも多い。

@ 止まらないプログラミング

変に一人で抱えこんで数時間あるいは1日プログラミングを止めてしまうことを無くそうという提案。

• 30分ルール

「30分」のところは15分だったり1時間だったりするかもしれないが、とにかく必要以上に一人で悩んで立ち止まらないようにしようという話。

関係者に確認すれば数分で解決してしまうことも多い。 技術不足とかそういうこととは関係なし。 もしかしたら「そのインタフェース実はまだできてないので結果は適当です」というのを呼び出して結果が合わないと悩んだりしてたりとか。

チームのトータルのスループットを最大にするようにコミュニケーションしよう。

• Evernote 使用開始 (2009-03-03)
• すごいKPT事後評価セッション (2005-10-07)
• Google ドキュメントでソフトウェアかんばん (2008-03-30)
• ソフトウェアかんばん (2005-10-28)
• ビジネスメールガイドライン案 (2006-05-05)

■ ビジネスメールガイドライン案

以前メールによる社内コミュニケーションの問題について書いて以来、いろいろと考えてみている。

そんな中、東洋経済新報社の「Think! SPRING 2006 No.17 超ロジカルシンキング」の中に参考になる記事を発見。 照屋華子氏の「ロジカル・ライティング - 論理的に考え、伝えるための3つの鍵を身につける」という記事だ。

すべてのビジネス・コミュニケーションは「伝え手」「受け手」「テーマ」「答え」「期待する反応」という5つの基本要素で成り立っている。-- Think! SPRING 2006 No.17 p.43

おお、ちょうどこういう切り口を探していたところだったんだ。 電子メールによるコミュニケーションも全く同じ枠組みである。 記事の中ではロジカル・シンキングをコミュニケーションで生かすという話題を中心に展開しているが、十分メールの書き方に通じるものがある。

この記事と、さらにちょっと前に買った「SEの実力を磨く究極仕事術」のメール術の章を参考にガイドライン案のスケルトンを作ってみた。

感情論は今回は置いておいて、情報共有・課題共有・リクエストの明確化・処理促進をポイントに列挙。 それから署名その他、一般的な話もいまのところ省略。

ポイントを列挙しただけなので、他人にもわかる形にはなっていない。

まずは自分自身に適用して、整理していってみることにする。

@ 1. 考える

• 【伝え手】伝え手は誰? (自分)
• 【受け手】受け手は誰?
• 【テーマ】テーマは何? 問いの形で。メールのテーマは1つに絞られているか?
• 【答え】 テーマに対する答え(テーマに対する説明)は何?
• 【期待する反応】受け手に期待する反応は何?
  • 誰に、いつまでに、何をどうして欲しい?
• コミュニケーション手段としてメールは適切?

@ 2. メールを書く

 ○○様へ                     # 受け手

 △△の××(自分)です。       # 伝え手

 テーマ
 ******
 コミュニケーション設定

 ○○の結論                   # 答え (結論)
 ==========
 ...

 (ここまででポイントを言いきる。)

 具体的な内容                 # 答え (詳細)
 ============

 項目1
 -----
 ....

 - リスト項目
 - リスト項目

 項目2
 -----
 ...

 - リスト項目
 - リスト項目

@ サブジェクトを書く

• 見ただけでわかるようにする
  • □ 具体的に書く

@ 導入部を書く

コミュニケーション設定を行う。

• □ 冒頭に宛先【受け手】を明記する。(誰に読んで欲しいのか? 他に誰に送られているのか?)
• □ 次に発信者【伝え手】を明記する。(From: フィールドに頼らず書く → 印刷・コピー用)
• □ 【テーマ】を書く。
• □ (オプション)【テーマ】の経緯・背景を書く。(「なぜこのテーマのメールがくるの?」)
• □ (オプション)なぜこの【伝え手】からなのかを書く。(←「なぜあなたからリクエストされるの?」)
• □ 【期待する反応】を明記する。
  • □ 「誰が」「何を」「いつまでに」「どのような品質で」して欲しいのかを書く? (← 「で何をして欲しいの?」)
  • □ 反応のメリットを書く (←「なぜこの反応をとらなければならないの?」)
  • NG 「ご意見があればお願いします」 → ない場合は?
  • NG 「どちらが良いと思いますか?」 → 意見として? 決定として?
  • NG 「ご検討ください」→ 検討した後どうして欲しいのか?
• □ (オプション)なぜこの【受け手】に読んでもらいたいのかを書く (←「何で自分なの?」)
• □ 特記事項があれば書く
  • □ 答えの情報源など

@ 答え (結論)

結論を書く。

• □ 詳細まで読まなくても済むようにする。
  • NG 「以下のように……」 → 要旨を書く
  • NG 「添付ファイルの通り」 → 要旨を書く

@ 答え (詳細)

根拠・資料などを書く。

• □ 受け手から見て必要十分な情報を書く
  • NG 「添付ファイルの通り」 → 要旨を書く
• □ 受け手が読みやすいように書く
  • □ リスト化する

@ 全般

• □ 具体的に
  • NG 「来週までに……」 → 「×月×日までに……」
  • NG 「先日の……」 → 「×月×日の……」
  • NG 「この間の……」 → 「×月×日の……」
  • 説明は肯定形で書く (否定形だと具体的に何なのかわからない)
• □ 論理的に
  • □ 構造化する
  • □ リスト化する (箇条書き化する)
• □ 受け手が読みやすいように
  • □ フォーマットを工夫する (ソフトウェア技術者間なら reStructuredText がお薦め)

@ 3. 送信する

• □ 送信する前に見直す
  • □ typo チェック
  • □ スペルチェッカ通す

@ A. メールを受信した時

@ まず返信する

どれか

• リクエストを「受ける」 / 返信で処理する (意思決定を返すなど)
• リクエストを「断わる」
• 「別の提案をする」
• 明確化の質問をする

メールでは不適当と思ったらコミュニケーション手段を 直接 / 電話に切り換える。

@ B. 返信する時

@ サブジェクト

• □ テーマが変わったら書き換える

• メールによる社内コミュニケーションの問題 (2006-04-12)
• ソフトウェアかんばん「見えない化」 (2006-04-10)
• パーソナルファクシミリを物色 (2007-01-07)
• 私的10大ニュース2005 [ comp ] (2005-12-31)
• 今日のさえずり - PuTTY って「パティ」なのか (2008-09-11)

■ [ 映画鑑賞 ] 太陽

ロシアのアレクサンドル・ソクーロフ監督による、昭和天皇ヒロヒトを描いた作品。

@ チネチッタ CINE 6

今日は「朝一番で見にいこう」ということで川崎のチネチッタで 9:20 の回で鑑賞。 客数は 10名前後。

@ 太陽

物語は過去のフィルム風の薄い色合いのトーンで、静かに淡々と進んでいく。 派手な動きはなく静かなのだが、何とも言えない張り詰めた緊張感が続く。

「嫁のバカ」の「アトムおじさん」など一人芝居のプロであるイッセー尾形はまさにヒロヒトの適役。 苦悩する孤独なヒロヒトを演じきっている。

最後に出てきた桃井かおりは個人的にはちょっと違和感があり。

天皇/皇室については特に思い入れもなく、私にとってはニュース・特番の中の存在である。 そんな私でも劇中天皇が米兵や記者、マッサーサーから非礼な扱いを受けるとなぜか憤りを感じてしまうのは、日本人であるが故であろうか。 それとも単に主人公に感情移入したからだけであろうか。

アメリカ大使館で、誰も開けてくれない扉を現人神自身が開けるシーンはかなり印象的だ。

ヒロヒトは苦悩する。当時得られた情報量からするにかなり悩んだ上で意思決定をしていったに違いない。

上映後、後の方の席で観ていたらしい杖をついたお爺さんが階段を降りてきた。 お爺さんはどんな風にこの映画を受けとったのだろう。

「あっ、そう」

• 映画『太陽』オフィシャルブック
• イッセー尾形 DVD-BOX1

• [ 映画鑑賞 ] M:i:III (2006-07-17)
• [ 映画鑑賞 ] 20:30 ゼブラーマン (2004-02-25)
• [ 映画鑑賞 ] コンスタンティン (2005-05-03)
• [ 映画鑑賞 ] ビッグ・フィッシュ (2004-05-31)
• [ 映画鑑賞 ] シンデレラマン - あしたのジョーを久しぶりに見たくなった (2005-09-23)

■ 「プロジェクトマネジメント」はどうやって勉強すれば良いですか?

会社の後輩から問われた。

答えがあればこちらが知りたい。

プロジェクトマネージャには、そういう事を自力で模索し掴みとる能力が必要なのではないか。プロジェクトマネージャは答えの決まっていない問題の解決をしていかなければならないのだから。

もちろん他の人から学ぶというのも重要なので、質問すること自体は悪くない。 ただもう少し自分で考えてみて「○○と△△というのがあり、○○の方が～～で良さそうだと思うのですがどう思いますか?」などと、やるのが良いかと思う。

ちなみに私がどう試行錯誤しているか、何を読んでどう考えたかはココ (nDiki) に書いているから、後輩君なら(反面教師にせよ)見てくれればいいと思う。

ていうか、何か面白いもの見つけてきてドンドン紹介してクレ。

• 技は盗むもの - 早朝会議革命

@ とはいえ自分なりに列挙してみる

ソフトウェアプロジェクトマネジメントで、必要なキーワードを思いつくままに挙げてみた。

• 問題発見力、問題解決力 (思考法)
• 意思決定力
• リーダーシップ力
• コミュニケーション力
  • コーチング
  • ファシリテーション
• プレゼンテーション力
• (リスク管理力)
• 以下に関する知識
  • 開発ガイドライン
  • ソースコード管理 (リビジョン管理)
  • バグトラッキングシステム
  • ビルド管理
  • リリース管理
  • ドキュメンテーション
  • ソフトウェアテスト
  • ソフトウェア見積もり
  • ソフトウェアライセンス
  • ピアレビュー

• ビジネスメールガイドライン案 (2006-05-05)
• 早朝会議革命 - 元気企業トリンプの「即断即決」経営 (2005-07-16)
• 久しぶりに build.xml を書く (2005-11-14)
• トム・デマルコ ゆとりの法則 - 誰も書かなかったプロジェクト管理の誤解 (2004-04-17)
• ソフトウェアかんばん「見えない化」 (2006-04-10)

■ 今日のさえずり - 停電って近隣にいる Twitter-ers あぶりだしに最適

@ 2010年01月21日

• 09:26 116 に電話して、レンタル中の ADSL モデムと ADSL スプリッタを合計1800円で買い取り。月490円の使用料は日割りで昨日分まで。
• 09:29 ADSL モデムはレンタル中に1度故障して交換してもらったことがあり、購入時のリスクを考えてつい今までズルズルとレンタルしてた。
• 09:34 @kagua_biz 意思決定すれば電話で10分の手続きで済む継続的なコストダウンでした。
• 09:40 メールけいしちょうによると比較的近所でひったくりが多発している。要注意。
• 09:55 秋葉原駅内の電光掲示板電源入った。 http://movapic.com/...
• 10:17 今日の 23:00 から「にごり水」なのでそれまでに風呂に入る。
• 10:39 目標による管理シート書く。
• 12:35 Twitter で小遣い帳入力「キャッシュブック」。ちょうどケータイメールから小遣い帳入力したいなと考えていたので、これでいいかも。 http://bit.ly/5CYr2C
• 12:39 キャッシュブックサインインした。
• 12:41 弁当 350円[昼食]。向日葵。
• 12:59 洗濯機は分解して洗濯漕取り出して洗ったことがあります。
• 15:03 オフィスのブレーカ落ちた。
• 15:04 というか近隣一帯瞬電/停電してる。
• 15:08 ファミリーマートも真っ暗。 http://movapic.com/...
• 15:15 東京都千代田区神田佐久間町4丁目あたりはまだ停電している。 L:東京都千代田区神田佐久間町4
• 15:20 RT @akiba_beetleMTG: 神田佐久間町一帯停電
• 15:29 ここが停電の原因か? http://movapic.com/...
• 15:34 まだ復旧しきってないな。東京電力ぐるぐる回ってる。大学堂も、ぐるぐる回ってる。
• 15:41 このあたり。 L:東京都千代田区神田佐久間河岸45 RT @Naney: ここが停電の原因か? http://movapic.com/...
• 15:45 ん? 今一瞬また電気チカッとしなかった?
• 15:49 一部地域停電って近隣にいる Twitter-ers あぶりだしに最適だね。
• 16:00 げ。他人事じゃなかった。さっきの停電による PC 落ちで、C++ ソースファイルが1つ滅茶苦茶になってた。コミット直前だったのでまたやりなおしだ。トホホ。
• 16:27 @it00h Emacs で作業している方はノート PC なので被害なしでしたが、壊れたのは Visual Studio 2005 on Windows XP でのファイルでした。なぜかバイナリファイルに。
• 18:26 Xperia、POBox Touch 1.0。
• 22:51 23:00 のにごり水の前に風呂・歯磨き完了。
• 24:20 Xperia SO-01B 欲しい欲しい。

• まだ ADSL モデムレンタルしているんですか? (2010-01-21)
• 今日のさえずり - 許されるのは嘘ではなくドワーフのような沈黙 (2010-02-23)
• 今日のさえずり - 入り口に盛り塩? (2010-02-15)
• 今日のさえずり - オールラインレッド! (2009-10-08)
• 今日のさえずり - 除虫菊を栽培していただきます (2008-08-05)

■ まだ ADSL モデムレンタルしているんですか?

自宅に ADSL を引いたのが2002年4月。その頃は ADSL もまだ変化が激しかったので ADSL モデム・ADSL スプリッタはレンタルで契約した。 しかし気がつけば、もうすぐ8年。毎月490円(440円 + 50円)使用料を払い続けている。ずいぶん払っちゃったなあ。

ADSL モデムはレンタル中に1度故障して交換してもらったことがあり、購入時のリスクを考えてつい今までズルズルとレンタルしていたというのもあるのだが、これ以上レンタルし続けるのももったいないので、買い取ってしまうことにした。 この古い機種を買い取るのもなんだかという気もなくはないが、まあまず安定しているしすぐには壊れないだろうし(と期待したい)、なによりレンタルし続けるのはそれ以上に馬鹿らしいので。

116 に電話して買い取り価格を確認。7年以上8年未満なので ADSL モデムが 1,700円。ADSL スプリッタが100円。 その電話でそのまま買い取りをお願いした。

今月の使用料は昨日までの20日分の日割計算。買い取り費用は ADSL の月々の費用と合わせてどこかのタイミングで請求されるとのこと。

意思決定すれば電話で10分の手続きで済み、以降ずっと継続的にコストダウンである。塵も積もればマウンテン。

• 今日のさえずり - 停電って近隣にいる Twitter-ers あぶりだしに最適 (2010-01-21)
• 自宅の電話番号に電話すると、他人の家にかかる(NTT東日本) (2004-02-08)
• 今日のさえずり - 過去の未使用年賀はがきが累積で41枚 (2009-12-29)
• モデム故障…… (2000-09-26)
• パルディオ用 PHS 通信カード DC-6S を購入 (1999-09-22)