スポンサーサイト 

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

ドキュメントはどこまでいらないのだろう? 

@ITで「アジャイル開発ではドキュメントを書かないって本当? 」という記事を読みました。

このシリーズはよいソースコードを書くということについてわかりやすく解説してくれるということで私も結構好きなシリーズです。 今回は簡単に言ってしまうと


ソースコードにアカウンタビリティ(説明責任)を持たせることで不必要なドキュメントを減らしましょう。


ということだったと解釈しています。記事の中に出てきますがソースコードも設計書であって、 大事なドキュメントの一部ということで話が進んでいきます。今回も大変ためになるお話でした。

 

ソフトウェア開発という意味においてドキュメントという点から俯瞰してみると、 ドキュメントの必要性は人から人へのアカウンタビリティだと言う事ができます。この場合、別々の人というだけでなく、 過去の自分と現在の自分も含まれます。今回の@ ITの記事ではソースコードについて言及されていますのでソースコードを読む人からソースコードを読む人へのアカウンタビリティについてです。 極論になってしまうとは思いますが、これは同じモジュールをメンテナンスする人に対するアカウンタビリティですね。

 

システムをモジュール分けし凝集度を高めたり結合度を弱くするのはアカウンタビリティを満足させるために必要なものをできるだけ減らしましょうという意味があるのだと思います。 あるモジュールを利用するためにそのモジュールのソースコードを隅々まで読まなくてもよいようにしましょうということだと理解しています。 ATAのI/FでもSQLの文法でもなんでも構わないのですがいちいちハードディスクのファームウェアのソースコードやデータベースエンジンのソースコードを読まなくてもよいようにドキュメントが存在するわけです。

 

アジャイル開発においてはソースコードの編集のための所有権を個人に属することがないようなプラクティスが存在します。 しかしその所有権はチーム自体にはあるはずです。所有権を持つということは所有権を持たない人に説明責任を果たす必要があるはずです。 逆の見方をすればアジャイル開発においてドキュメントが減らせる領域というのはチーム内においてということになるのではないでしょうか。

スポンサーサイト

魂と脳味噌 

「睥睨するヘーゲル」という本を読みました。たぶん、半分も理解できていません。 哲学に重心を置いた女性が書いたエッセイというつもりで読みました。

 

大江健三郎氏の息子さんは知的障害を持っているそうです。それをNHKがドキュメンタリーとして放送したことが書かれていました。

広島の原爆記念館に、嫌がる息子を無理に連れてきたお父さん、
「どう、だった?」
頭を抱えてうずくまる息子、しばしの沈黙の後、吐き出す息とともに呟き、
「ぜんぶ、、、だめでした、、、」

特に気にも留めず読んでいました。その後の著者の池田晶子さんの一文です。

脳味噌に障害があっても魂はかくまで鋭敏であり得る。

ものすごくショックを受けました。原爆記念館のエピソードをさらっと読み流していた自分にです。 自分の考えを表現することを磨くことは大切なことです。 でも表現された言葉がつたないからといってその存在を否定してしまう怖さを思い知らされました。「ぜんぶだめだった」 と表現するための根っこを私は持っているのかという自分への問いかけに私は自信を持って答えることができません。

 

言葉によるコミュニケーションが多くを占めるネットにおいて表現された言葉だけでなく、 表現の向こう側にあるものに今より丁寧になることを心がけたいものです。

 

睥睨するヘーゲル
睥睨するヘーゲル

アジャイル開発モデルの臨界点はどのあたりだろう? 

アジャイル開発が導入されたプロジェクトに直接かかわったことのない人間の空想です。

 

ソフトウェア開発におけるアジャイル的な要素ではなくて、 XPやスクラムなどの開発現場におけるプラクティスが比較的明確なものについて考えてみました。私はアジャイル開発宣言自体はまっとうなものだと思いますし純粋なウォーターフールモデルなどは非現実的だとも思っています。 ただ、ウォーターフールモデルと比較されるべきはアジャイル開発宣言を基にした思想ではなく、 XPやスクラムの様な開発モデルだと考えています。

 

アジャイル開発モデルには様々なプラクティスが存在し、極端な言い方をすればその組み合わせの数だけ開発モデルが存在すると言えます。 ですのでアジャイル開発モデルの適用範囲はプラクティスによって規定されると言うことができるでしょう。

 

以下のプラクティスについて注目してみます。

  • 毎日15分のミーティングを行う
  • チーム内のコミュニケーションを円滑にするため、パーティション等は廃止する
  • コードは2人のプログラマにより一台のマシンで
  • 誰でもどのコードでも修正できる

これらのプラクティスが多く導入されるほどチームが同じ場所で業務を行うことを要請されるようになります。 大規模な組織においては目的ごとにチーム分けされるのが普通です。 そして分けられたチームはおそらく同じ職場で業務を行うことが多くなるでしょう。このチーム内においては適用が可能であると考えられます。 アジャイル開発モデルにおいては顧客とチームという関係が用いられています。

 

では2つ以上のチームにおいて一つの機能を実現しようとした場合、それぞれのチームに対応する顧客とは誰なのでしょう。 機能を提出した人でしょうか。それともチームの成果物の依存関係において顧客関係が構成されているのでしょうか。 XPでの顧客をフルタイムでチームに加えるというプラクティスを用いる場合、 フルタイムでチームに加われる人は論理的に存在しうるのでしょうか。スクラムマスターを経由する場合、 結局顧客とチームの関係はウォーターフールモデルを基にした組織の関係とどうちがうのでしょうか。現実としてウォーターフォールはこう使え (まとめ)でいわれている、

ウォーターフォールとスパイラルの役割分担について。プロジェクト全体を俯瞰し、 マスタースケジュールを粛々と実行するのはウォーターフォール、個々の「すべきこと」 を割り当てられたチーム内で実行するのはスパイラルが適している。

の形になってしまっていると思います。 ウォーターフォールモデルの強みは組織論への展開が容易であるということです。 それに対するためにアジャイル開発モデルは独自の組織論を展開していくのかウォーターフールモデル型の組織とのハイブリッドで落ち着くのか興味深いところです。

 

全自動ブックスキャナ 

だぁ、もうすばらしすぎるっ!
全自動ブックスキャナ
消しゴムです。LEGOです。感激しました。いやマジで。

ついやってしまうコーディング 

ステータスが2つ(STATUS_A、STATUS_B)があって、STATUS_Aのときに行う処理を処理Aとした場合、


if (status != STATUS_B) {
    処理A
}


じゃなくて


if (status == STATUS_A) {
    処理A
}


とかかないとやっぱりまずいよね。ステータスが3つに増える可能性があるから。
自分への戒めです。

ソーシャルブックマークのタグ付けの目的 

私も便利にソーシャルブックマークを利用させてもらっています。 ソーシャルブックマークといえばみんなでタグ付けするというFloksonomyがソーシャルブックマークサービスの存在価値なわけですが、 付けたタグのゆらぎを気にする人がそれなりにいるようです。


ネイサン・シェドロフの理解の外観によるデータ、情報、知識、知恵の定義でいけば、「お、この記事おもしろい」 と思ってURLを登録した段階ではただのデータです。データはなんらかの分類によって整理されることで情報になります。 情報は経験と合わさることでパターンを見出されます。このパターンが知恵を生み出す母体となる知識です。


通常は知識を得るために情報を集めることになります。つまり知識を得るためにデータを整理するわけです。この場合、 どのような知識を得ることが目的かによって有効な整理の仕方が変わります。 知識を得る目的が決まった時点で整理の方法の範囲が限定されることになります。


ところが現在のソーシャルブックマークの利用のされ方は読んだ記事が自分にとって興味があるかどうかが登録の判断基準になります。 この段階ではどういう知識を得るかという目的が存在しません。方向が逆なわけですね。 すべての人の将来訪れるであろう目的に対応できる整理方法というのはなかなか難しいのではないでしょうか。 あるジャンルを俯瞰する立場の人もいるでしょうし、そのジャンルの中をディープに関与しようとする人もいるでしょう。 同じタグ付けで役に立つ可能性は低いと思います。


私がソーシャルブックマークサービスを利用するのはあくまで個人の目的のためです。 個人に絞り込むことによって将来訪れるであろう目的の範囲を予想しやすくなります。それに合うようにタグ付けします。 そしてたまたま同じタグ付けをする人を見つける機会があることでデータ収集の幅が広がることがこのサービスがソーシャルである理由だと考えています。


それは「情報」ではない。―無情報爆発時代を生き抜くためのコミュニケーション・デザイン
それは「情報」ではない。―無情報爆発時代を生き抜くためのコミュニケーション・デザイン

TiddlyWikiのtiddlerに枠をつける方法 

tiddlerの境目がどうにも見にくいので枠をつけてみる。
StyleSheetというtiddlerに以下を記述。

.tiddler {
border-top: solid 1px #ccc;
border-left: solid 1px #ccc;
border-right: solid 3px #aaa;
border-bottom: solid 3px #aaa;
padding: 1em 1em 1em 1em;
margin: 0em 1em 2em 1em;
background: #fff;
color: 333366;
width: 50em;
-moz-border-radius: 1.0em;
}

上から覗ける計量カップ 

たいして料理に興味とかあるわけじゃないんだけど
上から覗ける計量カップ
こういうアイデアは大好き。これでデザイン的に「うおっ」と思わせるものがあってラインナップが組めれば結構ファンがつくんじゃないかな。

amazonのカスタマーサービス 

amazonのカスタマーサービスについての覚書。

メールフォーム

特定商取引法に基づく表示

フリーダイヤル;0120-999-373
携帯電話から; 011-330-3000

 

空中に浮かび上がる3次元映像 

科学技術ネタでワクワクするのは意外と少ないんだけど、
産総研:プレスリリース 空中に浮かび上がる3次元(3D)映像
これはワクワクするねぇ。妄想も広がるってもんだ。


ところで3D映像ってスターウォーズなんかのメッセージに使われたようなものであれば可能だと思うんだけど2次元であるがゆえに表現できる空間の広がりはどのように表現するんだろう? やっぱりスタートレックのホロデッキのように人を囲む必要があるのかな。

非同期がよさげなこと 

仕事をしていてなんか効率が悪いなとか、なんかかったるいなと思うことがあります。ちょこちょこと待ちが入ったり、 仕事を止めないための仕掛けを用意したりしてることが多いような気がしてます。


待ちが入るってことは仕事の進め方が同期処理しちゃってるってことで、 仕事を止めないための仕掛けってのは非同期処理ができるようにしてるってこと。 かったるいってのは一度しか使われないような非同期処理のための仕掛けを毎度毎度やってるからかな。


そういや、マルチタスクやマルチスレッドも互いに非同期だから都合がよい。 いろいろと変化する相手の都合にいちいち合わせる必要がないってのがよい。 いくつかのルールだけ覚えておけばいろんなパターンで使えるのがよい。


一般的に非同期ってのは同期と比べるとミクロなレベルではパフォーマンスが悪い。 ってことは渡す側がぽつぽつと渡してくるような場合によさげ。渡される側の処理能力が渡す方より上回っていればかなりよさげ。 AJAXってのはくすぶってた不満を見事に答える仕掛けとそれを処理できる条件がうまく合わさったからはやるんだろうな。


同期処理になってるから効率が悪くなってるところとか、 個別に非同期になっているところにそこそこ汎用的なパターンを見つけられないかなって視点を持つようにしてみるかな。

考える技術・書く技術がおもしろい 

今、「考える技術・書く技術」という本を夢中で読んでます。 どれくらい夢中かというと電車の網棚に自分のスーツを忘れるくらい夢中です。(泣)
と、これではあまりに主観的過ぎるので少し客観的な数字を出しますと、1973年に第1刷が出て、 2004年に第64刷ということなので新書としては結構いい線いっているんじゃないでしょうか。

前半のキーワードは型把握。これはもう抽象化と直結するキーワードです。私もソフトウェアを書いていますが、 いまどきのソフト屋で抽象化を軽視する人はそうそういないでしょう。MVC(モデル、ビュー、 コントロール)なんてフレームワークはその典型的な例ですし、組込み屋さんでも状態遷移なんてのはハードウェアの抽象化でしょう。

その次あたりからは情報の収集や収集した情報から自分の考えをまとめていく際の流れの例が出てきます。もちろん、 この本が書かれたのはインターネットなんて全く一般化されていない頃ですので、古臭さはどうしても感じます。 KJ方なんてだされてもいまさらって感じですしね。でも、紹介されている事例をある種のメタファーとして捉えると、 こういう機能があるウェブサービスがあればなぁと思うところが多々あります。

まだ、読んでいる途中なのですが続きがとても楽しみな一冊です。


考える技術・書く技術
考える技術・書く技術

スワン・タッチ 

電車の中でよく本を読んでたりするんで、読書グッズにはそれなりに興味があったりします。この前、 del.icio.us見てたらスワン・ タッチというのがありました。

使い勝手とかはよくわからないけど、アイデアにほんとに感心。くちばしのあたりの丸め方とかはきっといろいろ調整したんだろうなぁ。

チューバッカのblog 

あかん、わらってもーた。
チューバッカのblog

tiddlerにリストを表示したい 

やっぱり、メモは後で見るときにはリストで見たいなと。


ToDoのメモにはToDoとタグを振ってあるのでそれを一覧で見たい。ToDoのtiddlerに表示されているToDoタグをクリックしてOpen tag 'ToDo'を選択。新しくtiddlerができるので編集状態でdoneしてtiddlerを作成。


これでもいいかなと思ったんだけど、このtiddlerにちょこちょこっと書き込んでみたらテキストの回りこみ具合が見にくかったので新規にtiddlerを作成してタイトルをToDoListとして内容を



<<tagging ToDo>>



として保存。とりあえずOK。いちいちtagにToDoと入力するのが面倒だったのでToDoListに



新規ToDoの作成<<newJournal NewToDo ToDo>>



として保存。これでToDoListのnew journalをクリックすれば自動的にToDoのタグがふられたtiddlerができる。あとはToDoListをMainMenuに追加して終わり。


上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。