2011-05-11

DevLove / 縦サミット参加レポート (3) - 鈴木さん / 和田さん編

DevLov / 縦サミットに関するPOSTの中で、アップしていたと思っていたものの、ずっと下書きのままだったのが、鈴木さんと和田さんのレポート…!
今ごろですが、自分の感じたものとして、Blogにアップさせていただきます。

2. なぜソフトウェアアーキテクトが必要なのか - 鈴木さん (@yusuke_arclampさん)

2番目は、『ソフトウェアアーキテクトが知るべき97のこと』の監修もされている、鈴木さんのお話しです。

tatesami-2

社内で小さな読書会をしていたので、『サインをお願いしよう!』と思っていたのですが、あいにく本を忘れてしまいました...。しかも、お願いする時に、『ピンクの...』と言ってしまいました (>_<)

アーキテクトの方は、緑なんですよね....orz 
失礼してしまい、申し訳ありませんでした。(そうこうしながらも、鈴木さんからはサインいただいています) 

とても穏やかで、静かな口調でのお話しでスタートしました。そういえば、4名の講演者の中で、鈴木さんだけがスーツでした(^^

私には高度な内容が多く、メモをかろうじてとったところと、スライドを確認しながら書き起こしてみますので、品質の件はどうかご容赦下さいませ (_ _)

アーキテクチャってなに?:

    • 『構造』のことではない。(Not Structure)
    • システムにはミッションがある。
    • システムにかかわるすべての人々のビュー(関心事)の整合性を取ったものを作ること。
      • システムのミッションに従いながら、
      • 制約を考えつつ
      • 複数のステークホルダーの関心事を整合させ
      • ライフサイクルまで考えたシステムの分け方と組み合わせ方のこと。

3. プログラマが知るべき、だったひとつの大事なことがら - 和田さん (@t_wadaさん)

和田さんのセッションも、デブサミ当日、みなさんの呟きを眺めながら『ああ、聞いてみたかった~』と思っていた1つでした。

上記の鈴木さんの監修された本も、いわば『きのこ本』なのですが、最初にわたしが『きのこ本』として認識したのは、こちらの『プログラマが知るべき97のこと』。

プログラマなきのこ本には、ロゴがありますが、これは北海道のデザイナーさんにお願いして描いてもらったそうです。

tatesami-3

まずは、デブサミの講演者として、何を話したらいいのか....という葛藤からスタートです。

『プログラマが知るべき97のこと』は、各自の想いや立場の上で書かれたものなので、お題としては取り上げにくい。悩んだ末、デブサミの先人スピーカーの方々のお話しを参考にし、

    • 自分』の話をしよう。
    • 会場じゃないと聞けないことを話そう。

という結果に至ったそうです。このことが、和田さんのお話に、『自らの物語』としての魂を吹き込んだことになったんだなあ....と思っています。

実は、TwitterのTLから、和田さんにとって大きな転機になる、衝撃的なことが起きたということは知っていたのですが、改めてご本人からそのお話しを聞いたとき、ずしりと心にのしかかりました...。

大事なこと:

    • 量は質に転化します。
    • 写経しましょう。
    • 自分が渦に入り、そして渦を作っていきましょう。
    • 学び、受け継いだものを伝えることが大切です。次は、あなたの番です。
最後は、お話しを伺っている私たちが、『渦を作る人間になってほしいです』、との言葉でした。

 

感想:

技術的なノウハウ、Tipsの講演ではなく、和田さん自身の『体験』を伺った、という印象があります。

和田さんの『原体験』である、『やってみせること』は、体験・経験を伝える直接的な手段です。ただし、どんなに人に勧められても、実際に自分が手を動かして、やってみないと判らない楽しさもあります。

どんなに熱く語っても、興味をそそられない相手もいます。ただ、この会場に集まっている方は、みんな志を同じくし、すくなくとも、自分から『渦』に引き寄せられた皆さんばかりだと思います。すでにそこに縁のようなものを感じますし、きっと、それぞれ皆さん自身の渦を作っていけるんじゃないかな.....と、私も思いました。
#自分はどうだろう?動けないしなあ.....と少し悩みましたが、こうやって記録することもちょっとは役に立つのかしら、と思って書いてみました。

質問タイム:

Q. 一番納得いかない「きのこは」?

A. コードのコメントについて、16と17という。相対した記述がある。和田さんご本人としては、17の立場だとのこと。

AttributeError: 'module' object has no attribute 'TestCase'

本日のトラブル - AttributeError: 'module' object has no attribute 'TestCase'
縦サミの@t_wadaさんのお話しを聞いて、『せめてこれからはテストを書く習慣をつけたいなあ~』と考えました。
#テスト書いてないというのはわたしだけで、同僚や職場の方がそうだということはありません、念のため....。


さて、ちょうどジョブとして仕込む予定の簡単なプログラムを、Pythonで書くつもりだったので、ここからテストの練習をしようと思いました。


http://www.python.jp/doc/2.5/lib/module-unittest.html のあたりの記事を参考に、まずはコードをCopy&Pasteして(下記の通りサンプルそのまんま)、unittestの動作を確認することにしましたが...。



import random
import unittest

class TestSequenceFunctions(unittest.TestCase):
    
    def setUp(self):
        self.seq = range(10)

    def testshuffle(self):
        # make sure the shuffled sequence does not lose any elements
        random.shuffle(self.seq)
        self.seq.sort()
        self.assertEqual(self.seq, range(10))

    def testchoice(self):
        element = random.choice(self.seq)
        self.assert_(element in self.seq)

    def testsample(self):
        self.assertRaises(ValueError, random.sample, self.seq, 20)
        for element in random.sample(self.seq, 5):
            self.assert_(element in self.seq)

if __name__ == '__main__':
    unittest.main()

実行してみると、こんなエラーが!

AttributeError: 'module' object has no attribute 'TestCase'

ええ~?と思って、pythonを対話モードで起動して、 "import unittest" とタイプしたとたんに、同様のメッセージが。


『なんじゃこりゃー』状態だったのですが、もしかしたらmoduleが無いんじゃないかと、% locate unittest.py とすると、Pythonのライブラリにはちゃんとファイルがあります。

....悩むこと5分。


『もしかして?』と思って、サンプルコードのファイル名を確認したところ、"unittest.py" になっていました。

早速、ファイル名を変更して、python test.py としたところ...。

# python test.py
...----------------------------------------------------------------------Ran 3 tests in 0.001s OK

とまあ、めでたしめでたしではありますが.....。

こんなことで大丈夫でしょうかね。何事もやってみるものですが、『OK』の文字1つ出てくれただけでも、本当に有難かったです(^^;

2011-05-10

DevLove / 縦サミット参加レポート (2) - よしおかさん編


つづきまして、縦サミットのレポート、今回はよしおかさんの分です。長めになってしまっているので、どうかご容赦下さいませ。


※スタイルとして、お話しを伺っている時に書きとめたメモ、簡単なスケッチを載せていますが、不都合な点、配慮が足りない点は、どうかご指摘いただければ幸いです。

4. ハッカー中心の企業文化を日本に根付かせる - よしおかさん (@hyoshiokさん)

よしおかさんの講演資料は、デブサミの後に拝見し、社内のOSS-CONTACTのMLにご紹介させていただきました。
というのも、社内で勉強会を開催すること、また、社内で社外の勉強会を開くことの意義やメリット、デメリットについて触れられていて、きっと共感したり役に立てていただけるんじゃないかと思ったからです。テクニカルな内容よりは、むしろどんな業種、立場にも役に立てることのできるノウハウが詰まっていました。
ですので、ご本人の講演を生で伺うことができた、とても有難~い機会でした。

はじめに:


本題に入る前に、『質問』することの心構えや大切さについて触れて下さいました。
    • 質問のコツは、講演の内容を聞かないうちに考えておくこと。
    • 特に海外のセッションや英語など日本語じゃないセッションでは、あらかじめ質問内容とどう話すかを考えておかないと、余裕が無くなってしまう。
    • また、講演内容を聞いていくうちに、本当に質問したかったことがぶれてしまう。(だからできるだけ事前に決めておくことが大事)
自分が素晴らしいと思っている物事を紹介する。それをどう実現するか、みんなで考えるきっかけを作る。
今日できることを考える。スキルと知識の差は何かと言ったら、『出来るようになること』がスキルである。『質問する』ことも、訓練をしていきましょう。
  

よしおかさんのお顔を拝見し、お話しを伺うこと自体初めてのことでしたが、飄々として、魅力的なお話しぶりをされる方だな、という印象を受けました。(おかげ様で楽しくメモも取らせていただきました)
個人的に、蚊やり豚がなんとも可愛らしいと感じています...。
企業の組織文化を記述することについて:
    • 企業文化は、本来、『中の人』でないと知りようがないもの。(人の異動や、転職などにより、ゆるやかに口承などで伝えられることはあるが....)
    • 企業文化を記述することで、その企業の『何が良いのか』が分かってくる。
    • 民族誌を例にとるならば、『その文化では、当たり前として受け止め、行われていること』を記述する。
    • 例えば、ある会社では『勉強会は当たり前のこと』と考えられている場合、それはなぜなのか?
    • 理由を明確に伝えないと、異文化(異なる組織)には、そのメリットやデメリットが伝わらない。
...と、このあたりまでお話しされたところで、『ストップウォッチ押すの忘れてた...』という、1コマがありました。


#組織文化を改めて記述してみる、というのは面白いなあと思いました。地理学科という、フィールドワーク中心の学科出身なので、なんかこのあたりは嬉しくなってしまいます。
引き続き、セッション内容です。 スライド&中継の資料のほうが確実ではありますが、メモしている分を書き起こします。
DECのスタイルの紹介:
    • ミッドナイトプロジェクト(Googleで言う20%ルール)が、むしろ『推奨』されていた。
    • 社内コンピュータのネットワークですべて繋がっていた。(ただし、スタンドアロンでは使わず、分散してるけど繋がっている)
    • VAX Notesという、社内の巨大掲示板があった。
    • ありとあらゆる情報が共有されていた。(開発日誌でも、なんでもかんでも!)
    • 世界中の、見たことも会ったこともないDECのエンジニアの日誌を読んだりできた。そして、実際に会えたりすると、ものすごく感動!(あの人だ~!)

実は、ここまでの話で、『ああ、質問したいなあ~』という内容が出てきました。結局できなかったのですが(;_;)

というのも、『統制』というキーワードで、『情報統制』のことを思い浮かべて、こういったオープンな巨大掲示板でいろんな情報が交わされるのだとすると、お客様の情報とか、一般社員が知っていてはいけない情報なんかも紛れる可能性があるかと思ったからです。そこを参照したり、書き込んだりするために、なんらかの認証やコントロールはあったのか....と。で、80年代はオープンだったとして、その後はどうなっていったんだろう...と。

ただ、よしおかさんの語られた意味の『統制』は、そうした情報統制のことではなく、文化や価値観を共有しあうことで、企業としての一体感を生み出すという意味での統制ということかなと思っています。(あってるかな?)

ハッカーって?:
    • 何かをやった人。(世の中を変えちゃった人)
    • よしおかさんの場合は、行動するエンジニアになりたかったとのこと。


ハッカーの倫理:
    • 共通の価値観を持つ
    • コンピュータで社会を良くする
    • ラフなコンセンサスと動くコードを大事にする
    • 許可を求めるな、謝罪せよ

ハッカー中心の文化を必要とする企業は?:
    • 良いソフトウェアを必要とするすべての企業!
    • 最高のプログラマを雇えばいい。(そう言っちゃうとみもふたもないけど)
    • 最高のプログラマは最高のプログラマのいるところで働きたがる。
    • 『こんなアプリが良いな』『こんなものが欲しいな』といくら言っても、案があっても、作れる人がいなかったら絵に描いたモチだよね


なぜ必要なの?:
    • 社会善 (世の中を良くするためのものを作るんだよ、という大きな使命感。....ただしこれは偉い人向けの建前でもある :-P)
    • 企業の競争力 (そうしていかないと生き残れない)
    • ベストプラクティス (デスマーチ知らず。楽しんでやれるのって大事!)
    • + ハッカー中心の文化は気持ちいいから (よしおかさんの個人的な理由)


どうやってハッカー中心の企業文化を作るか?(作るだけじゃなくて、伝承するか?):
    • 暗黙知の継承
    • 形式知の継承
    • 楽天という会社の中ですら、文化の衝突がある
    • 組織が大きくなると、タコツボ化してしまう
    • 部署を超えた、『クロス・ファンクション』は、言うほど簡単じゃない!

ここまでで、『ううむ...』と思いつつ聞いておりました。私はスキルのあるエンジニアでも、偉い人でもなく、一平社員の身分なので、『お前に言われんでもわかっとる!』と突っ込まれると思いますが...。


ちなみに、ここでよしおかさんの一言。


『タコツボ』を英語で表現すると、『サイロ』がそれに該当するんだとのこと。ちょっと検索したら、こんなブログを見つけました。

http://blogs.yahoo.co.jp/kenfsakai/38913019.html / 企業のサイロ化



そこで社内勉強会!:
    • 志を共有するメンバーでドライブする。(上からの強制ではない。上からアサインされた、組織を超えたプロジェクトではない)
    • コミュニケーションは組織を活性化させるビタミン!

ここでまた個人的な感想。コミュニケーションの活性化を狙って社内SNSとか、社内限定コミュも立ったりしていますが、今一つ盛り上がらなかったりするのは、大義名分の関係もあるかなあ....と思ってしまいます。『ビジネス上の自分のスキル、技術向上』という目的も見いだせる勉強会のほうが、より前向きですし、業務につながる分、精神的にも気持ちよく取り組めるかなと思っています。

xxxクラブ的な、単純な交流目的のクラブでは、『そんなもん業務時間中にやるな!退社後とか週末にやれ!』的な後ろめたさも感じたりしてしまうかなあと思っています....。
そういう意味で、勉強会というのは、いろんな面から見ても『好ましい』ですよね(^^
勉強会の意義は、多くの方が肌身で感じられていると思うので、うんうんと聞くに留めています。

さて、お話しは続きます。

一番伺いたかったのは、『社外の勉強会を社内で開催すること』の意義でした。わたしの会社でも、そういう志を持っている方々が、定期的にではないですが、いろいろなイベントを開催することがあるからです。そういう活動の意義を再確認できたらな....という想いもありました。


社外の勉強会を社内で開催すること:
    • 本当は、(自分の好きな/知りたい)勉強会をやりたいから引き受けるんだ。
    • でも、それだけでは組織の中は進まないので、メリット・デメリット(リスク・コスト)をきちんと説明することが重要。
    • メリット、デメリットがある。(メリットについてはあえてメモしません)
    • オープンイノベーションの時代。
    • 技術は会社のものではなく、社会のもの。
    • 会社の中での活動を通し、社会を良くするためのものを実現していこうという価値観。
    • デメリットと思われる点は?
      • 情報漏えい -> 会場以外は入らせないことで防ぐ。
      • 会場提供 -> 直接的な費用はほとんどかからない。(光熱費はかかるかな)
      • 時間外勤務 -> とは言っても、残業でも出勤扱いでもないのでコストはかからないはず。
    • 企業イメージの向上や社員のモチベーションアップ、人材の交流のメリットの方が大きい
    • 開催のメリット -> 開催のコスト (よしおかの勉強会第一の法則)

勉強会継続のポイント:
    • 勉強会は極めて俗人的
    • 情熱と仲間が必要。(これはかなり痛感しています)
    • 暗黙知や価値観の共有が必要。
    • 維持、継続していくためには方法論や戦略が必要。(これも大事ですね~)
    • ガイドライン、戦略、ルールを形式知化することも大事。

幸いにも、わたしの職場では、イベントをホストしてくださった先輩たちが、設備利用の際の管理部門・総務部門とのワークフロー、主催者側とのやりとりの流れといったノウハウをまとめておいて下さっているので、ゼロからのスタートよりは格段にやり易くなっています。
よしおかさんのスライドも併せて、たくさん苦労されたんだろうな....と思いましたし、先人たちは、確かに社内のワークフローにも外にも通じている方になっています。(いまさらながら本当に感謝)



わたしも開催のメリット > 開催のコストだと思っています。

しかし、これも仲間がいないとできません(^^;


子どもが小さいので、夜や週末にそんなに時間を取れないということもあり、『やりたいよね』、だけではできないんだということをひしひしと感じています...。


そしてまた、いま、精力的に活動されている方々でも、そういった時間を取れなくなる時が来るかもしれません。(おおきなお世話か??)

だからこそ、こういう想いを絶やさないように、文化の伝承や価値観の共有をし、あとに続いてくれる皆さんを増やし育てていかないといけないなあと感じました。
そしておそらく、そこから生み出された良いものに、自分の子どもたちが振れて、感動してくれるなら、どんなに良いだろう...と。 (なんというか、母親モードの感想で申し訳ございません...)

よしおかさんの Post 3.11


よしおかさんも、新たにご自身の言葉で語っていらっしゃったので、メモを書きとめておきます。


やはり、『仕事をするって、どういうことだろう?』という想いや、なかなか会社としても、世の中も動かないことへの絶望感も感じられた、と仰っていました。

その上で、震災前に戻ることはできないから、その意味を良く考えよう、震災が組織を変える機会だと思って進んでいこう、と。

被災地に行って何かできるわけじゃないけれど、電力削減は自分たちでできるはず、という想いで、Project60という取組をされているとのことでした。
オフィスの小さな節電から、DCのオペレーションの方法を変えるということなど、やれることはたくさんある、なんでもやってみようと、と仰っていました。



それこそ、ハッカー的な行動だよね、と。



実は、その後、節電の取り組ででなにかできないかという話が部署で持ち上がったので、よしおかさんにうかがった内容も紹介させていただきました。
小さいことから、個人の信条でそれは無理!というものまで、いろいろ議論や意見が出てきましたが、『できることから』という想いは皆さん持ってくださったようです。
いわゆる、『ハック』なTipsも自然と提案がされてきました。


こういう動きは、会社ではなく、『社会を良くするためのハック』だと思っています。


よしおかさん。貴重なお話、本当にありがとうございました。

DevLove / 縦サミット参加レポート (1)




ずいぶん時間が経ってしまいましたが、4/23 縦サミットのセッションのレポートになります。ただ、聞き違いや勝手な思い込みの混ざったレポートであることは、どうかご了承ください (_ _)
そういうものは排除して、ご自身の目で講演を確かめたいという方は、下記の動画をどうぞご覧ください。
1つのBlogに4つ分まとめて書いてみようと思ったのですが、長くなることと、なかなかまとまらないことから、数回に分けてみます。(オープニングと嵩原さんのお話しを取り上げます)
スタイルとして、お話しを伺っている時に書きとめたメモ、簡単なスケッチを載せていますが、不都合な点、配慮が足りない点は、どうかご指摘いただければ幸いです。

はじめのごあいさつ: @papandaさんから

最初のご挨拶は、@papandaさんです。
"DevLove Urakata Team" (良い言い回しですね)  の立場として、今回のイベントについてのお話し、#4tateへの意気込みをお話し下さいました。プレゼンの画面には、『3q! 楽天さま、翔泳社さま』の感謝の言葉も。しみじみと有難い機会をいただいたんだ、と思いつつ聞いておりました。

@papandaさんのお話しの中だったと思いますが、DevLove立ち上げの経緯が紹介されていました。
きっかけは、つくばでのRubyKaigi の帰り道だそう。(そんなに昔ではないんですね)
@papandaさんの同僚と、『なんかやりたいよね~』という会話がきっかけになり、そこに加え、
    • 楽しいだけじゃない!
    • 開発を前進して行られるような場を作りたい!
という想いから立ち上がったそうです。
そこからここまで...って、本当に凄いパワーですね。大切なきっかけを、会場の皆さんと共有できたことも、ちょっと幸せを感じました。
DevLoveの皆さんのイベントでは、皆さんからの#4tateのメッセージを集めていて、5/28の東北ディベロッパーズイベントに届けて下さるそうです。今回も、『渾身会』の場で、メッセージ集めをされたとのこと。
そうこうして、デブサミ史上最強の1時間となった、『4本の帆立』のセッションの再演が始まりました :)

1. これからのRIAの話をしよう - 嵩原さん (@take3000さん)

最初は、クラスメソッドの嵩原さんのお話しです。
今はFlex開発から離れちゃっていますが、やっぱり、『Flex、RIAのアプリと言えばクラスメソッドさん!』がまず思い浮かびます。(過去のデブサミでも同社の方の講演実績がありますし、私もお話しを聞いて、方法を取り込んだことがあります)
基本的には前回(2月のデブサミ)をベースにしてはいるものの、中身を少し変えている&2回目ということで、『SP1 』と銘打っての、220枚にも及ぶプレゼンの開始となりました。(凄い...)

業務アプリの使い勝手について:
    • テクノロジーの進化、設計手法の進化によって、システム中心から人間中心の設計、デザインに変わってきた。(RIAもそう)
    • 人事給与システムやメールシステムといった、業務アプリケーションは、非コアコンピタンスの部分。(その会社の直接のサービスとなるものじゃない)
    • 使い勝手は気にしなくて良いよね、そこそこ使えて安く使えれば良いよね、という考え方。(ある種の妥協、諦め)
    • でも、ほんとうにコストが抑えられているのか?と言ったら、そうとは言えない。結局使いにくければ問い合わせがたくさん来るし、コストがかかってしまう!
User Experience Design:
    • ユーザに対して有意義な体験優れた経験を与えるためのデザインを提供しよう。(ビジュアルなデザインじゃなくて、体験をデザインする)
    • 目指すものは、ある目的のために作りこまれたアプリケーションが、優しく快適に利用できるという点。(Ease & Pleasureのライン)
    • 『楽しい、面白い!』まで求めるのなら、それは別のアプリで...。(ゲームとか)
大事なのは "Strategy" (戦略):
    • 『インタラクションデザインの教科書』からのUXの5Sのうち、大事なのはStrategy。(ユーザのニーズやサイトの目的、という部分)
    • ビジュアルデザインだけではない。
    • プロジェクトの終盤の方でデザイナをアサインするというのではダメ!
    • 早い段階から、User Experienceを意識した設計や開発を!
    • モデリングでは、ユーザの感情や使い勝手に踏み込んだ設計はできない!
ユーザビリティの5つのルール:
      • アクセス: ツールの利用経験の無い人が、助力や指導無しに使えるものでないといけない。
        現実のフローに従った処理を想起させるようなつくりでないといけない。
      • 支援: ユーザの真の仕事をよりやさしく、単純に、速く、楽しく達成できることにより、さらに新しいことが出来るように支援するものでないといけない。
      • 何をシステムに反映させよう?
    UI設計の原則:
      • Exp. 再利用の原則: 同じことをさせるなら、同じダイアログを出すようにする、など。
      • ....でも、原則、ルールがたくさんあるし、どれからあてはめていけばいいんだろう?
      • 指針はシンプルに!
      • ウェブ戦略としてのUIであれば、ここ -> 効率を改善させる。より早く、正確に(間違わずに)!
      • 早く、間違わずに操作できることを目指そう。
    優秀なUIデザイナはどこ?:
        • 日本には少ない....。
        • 逆に、適正のある人を『育てていく』ほうがいいのではないか
      RIAの話:
        • Flash(Flex), Java, Silverlight -> ランタイムを配布する形で広める。
        • HTML5 -> ブラウザの標準化を進めることで展開を図る。 
        • Silverlightはブラウザ外でも動作する。.NETアプリがMac上で動かせるんだよ!
        • UIデザイナが、Blendを使ってSilverlightアプリを開発することも出来るよ!
      HTML5が出たらFlash要らなくなるの?:
        • HTML5で実現できている機能は、現状、Flash8くらいのレベル。(今Flash10)
        • 同じ機能を有するアプリケーションでも、HTML5に比べてFlashやSilverlightの方が早いものもある。
        • ユーザの要求は年々上がって行くもの。(スマートフォン、マルチデバイス対応...)
        • いったん便利さに慣れたユーザは、機能が劣ると満足しない。
        • HTML5は何でも動くと言っても、やはりJavaScript書かないといけないから、クロスブラウザの問題が残る。
        • HTML5の仕様が実際に実現できるまでに、ユーザ要求はもっと複雑化しているかもしれない
        • システムのライフサイクルを考えて、どんなRIAの技術を取り入れるかを考えることが必要。
      キネクトについて:
        • それって何になるの?
        • デバイスが触れない環境でも使える、という発想から何か考えられないか。
        • 例えば、外科手術中の執刀医が、『忙しくて、手がふさがっていて、パソコンなんか触ってられない!』という状況でも、動作をすることでTVやモニタ、CTを切り替えたりする...というのはどうだろう?
      TweetDeckの楽しさ:
        • AIRでできたTwitterアプリ。おもしろいよ。
        • いろんなサービスと連携して、成長してきている。
      アジャイル開発とUIについて:
        • クラスメソッド社の経験からのお話し(貴重!)
        • UI、UXは、コンセプトを変えるのが大変!
        • ただし、アジャイル開発でユーザへの提供がこまめに発生する分、UIに対する検証の機会も多いので、必然的にアジャイルっぽくなっていく。
      契約について:
        • IPAで、アジャイル型開発に適したモデル契約をまとめているので、参考にどうぞ。
        • 開発手法はどんどん変わっているのに、契約形態は変わっていないのが現実。
        • 変わっていくといいよね...。
      良いデザインのためには:
        • 良いデザインをするには、良いデザインを知ることから!
        • 悪いものほど印象に残り、たとえば、クレームは50人に伝播するのに対し、良い情報は3人くらいしか伝わらない。
        • 「良いもの」は、意識しないで使えてしまうからなのかも?
        • UXに向かう最初の一歩は、良いデザイン、UXに触れ、褒めること!
      正しくない行動パターン: (UIを正しく使えないパターン): 


        • 1. そのUIを見て、使い方を考える。(考えなければ使えない、どづしたらいいのか、何のためのものか判らない)
        • 2. (考えた通りに) 実行、操作してみる。
        • 3. それが正しい操作だったのか、目的を達成できる動作だったのかを、ユーザ自身が確かめる。(確かめなければならない)
        • ユーザの時間を無駄にする、余計な負担や動作を強いるものはNG。

      ITシステムに関わる全ての人が共通の目的を持とう:

        • 誰のためのソフトウェアか?
        • 誰のためのデザインか?
        • UIは、システム全体、ひいては、社会全体のコストにかかってきます!

      嵩原さんの Post 3.11


      1つめだけでも、とても聴きごたえのある内容でしたが、デブサミ時点と違うことは、3.11後であるということでした。スピーカーの皆さんが、それぞれに講演内容 に加え、 3.11を経験してからの新たな想いを語って下さっていました。
      今回のBlogでは、嵩原さんの震災後の心の葛藤と決意といったお話しを最後に添えさせていただきます。
        • ITの人間として、『為す術なし...』という無力感。
          『瓦礫一つ動かすことができないじゃないか...。』
        • でも、ぼくたちは情報を扱うプロだ!
        • ITが専門では無い人たちに伝えることが大事。
        • 情報を得るための道具が、結局使えないようじゃいけない。
          使いやすいUIじゃないといけない!
        • 理想は、『助力や指示が無くても使えるUI』ではあるけれど、まずは『根気よく使い方を教える』ことが大事だ。
        • 『魚を与えるのではなく、魚の釣り方を教えよ』、のたとえもあるように。
      ITに関わる者の責任として、人に対する優しさを忘れないことが大事、ということを仰っていました。

      感想:

      嵩原さんのまとめには、とても素直に共感できました。
      良いデザイン、良い点は、意識しないとそれが伝わってこないけれど、良いものは『良い!』、という感受性や、素直に認めて褒めるこころは大事にしたいなあと思いました。
      良いものに触れ、経験し、感動することこそが、良いものに繋がると私も思っているからです。また、作り手も、褒めてもらうと本当にうれしいですものね。
      また、このお話しの中で、業務アプリケーションのデザインというと、地味な印象かもしれませんが、重要性を再確認できました。UIデザインのお仕事は、ユーザの喜んで下さる現場に一番近いお仕事です。システム開発にかかわったすべての皆さんの願い、『このシステムはこういう目的で、こんなふうに使って欲しい』という想いが、UIを通してちゃんと伝えられないといけないんですね。
      私も少しですがUIにはかかわっていたので、『またやってみたいなあ~』という希望や、UIの価値、目的意識を改めて持つことができました。

      さらに、キネクトについての視点や、「HTML5登場でFlash/Silverlightはどうなるか?」という内容も、非常に参考になりました。そもそも私はクロスブラウザの問題が嫌でFlexを使って開発していた過去があるのですが、最近のHTML5の隆盛に、『もう行けてないのかしら....』という不安と寂しさを感じていたもので (^^;
      今回のお話しで、『いや、AIRとかSilverlightもまだまだ行けそう!』と勝手に自信を持ってしまったのでした。

      もちろん、最後に嵩原さんのお話しして下さったことも。

      UXのお話しをまとめていて、1つ思い出したのが、『ソフトウェアアーキテクトが知るべき97のこと』の1トピックです。

      上記のトピックでは、ソフトウェア全体について語られていますが、UXも含め、使い勝手や生産性、人に対する優しさと言ったものは、『ソフトウェア倫理』として、つねに振り返る必要があるなと感じました。

      お話しを聞いた者の役目として、自分の職場や、メッセージを届けられる範囲でも良いから、想いを伝えていこうと思っています。

      嵩原さん、papandaさん、どうもありがとうございました!