2013年2月14日木曜日

Developer's Summit 2013 参加メモ（５）

★受講中に書いていたメモを、推敲無しでそのまま上げています。
★誤字脱字、内容の漏れなどあるかと思いますがご了承下さい。。

現場で役立つUX -エンタープライズUXの現在とこれから- / 仙波真二氏@オージス総研

導入

consumer [product -> service] -> Enterprise
特定の顧客向けのスクラッチ開発が多いですよね

UXとは

ニールセン・ノーマングループの定義
- 混乱や面倒なしで顧客の的確なニーズを満たす事
- 所有する楽しさ、使用する楽しさを生み出す「簡潔さと優雅さ」
つまり個人の感覚に依存する部分

今日伝えたいこと：EnterpriseUX

現在→これから
- 見た目のデザイン
- 行動のデザイン
- 現場への適用
社内のシステムとかイケてないよね

見た目のデザイン

見た目は重要
- デザイニングインターフェース
見た目を良くするには？
- レイアウト
  - 基本パターンを意識する
- 整列と余白
  - 左揃えや中央揃えですっきりと
  - 余白を適度にとると洗練された印象に
- 色
  - ベースカラー、メインカラー、アクセントカラー
- 一貫性
- メリハリ
ソフトウェアにはデザインパターンがある
デザインにももちろんパターンがある
学生向け開発コンペのポスターの例
- 素材は全く同じで、デザインの原則に則ってリヴァイスすることが可能
アプリケーションでも一緒。
- 画面幅いっぱいに文字を配置すると見づらい、とか
スマートフォンの画面デザインのパターン

行動のデザイン

ユーザーの行動を観察してデザインする
ユーザーが「こうなんだ」ということを鵜呑みにしない
コンテキストを考える
- どういうユーザーか、どういう状況か、何を行いたいか
- コンテキストにはストーリーがある
  - だれが、どこで、何をする
（機能ではなく）行動をモデリングする
- これまでは機能をモデリングしていた
  - データ構造、処理フロー、画面遷移
  - ユーザーの頭の中、イメージをモデリングする
- 家具選びなら、個々のカテゴリーから選ぶのではなく、全体のイメージから
- コンテキストに応じて変える
  - 同じアプリケーションでも、PCとモバイルではコンテキストが異なる
    - PCならフル機能
    - モバイルなら必須のもののみ
どう感じるかを自分で体験する
- 重要な所はプロトタイピング
- 試行錯誤を繰り返す
- スマートフォンアプリをデバイス無しで開発するようなのはNG
  - 予算の関係で調達出来ない、自分の端末はセキュリティ上使えない、、
  - FirefoxやChromeでも出来るじゃん ← これはNG
EVOLTA / robo-garage
- ひとりで作った
- 「設計書を作ってしまうとカッチョいいものは作れない」

現場への適用

経済的な視点からの実行リスト / ユーザビリティエンジニアリング言論
- 社内に置ける必要性
- 経営陣からの支援
- 担当者確保
- 開発プロセスへの組み込み
- ユーザテストの実施
きっとagileが欠かせない
これからは
- お客様も含めた必要性・支援
- Agile開発プロセス
- 担当者確保、ユーザテスト

現場への適用：具体的なアプローチ

UXの価値をみんなで共有する
- 開発者、デザイナー、お客様、経営陣、エンドユーザー
社内の責任者と、各プロジェクトの担当者を設置
- 多段階発注方式
  - 元請け、下請け、二次請け、、、とかだと収拾がつかなくなる
  - なので責任者を配置して、品質を担保する
お客様とともにAgile開発を行う
- RFPに「UX品質を担保する」を入れる
- 開発プロセスにUXアプローチ・レビューを入れる
- チケットに登録してしまう(チケット駆動開発)
- お客さんの意識も改善させていく
  - 既存システムは従来のやり方になる
  - スマホなんかだとお客さんの要求も変わるので、突破口になりうる
ユーザビリティテストの実施
- 出題者・被験者
- 合否判定者、タイムキーパー

Action!

お客様が自慢したくなるようなシステムをつくりましょう！
- このメッセージには“UX”という言葉はあえて使っていない

Developer's Summit 2013 参加メモ（４）

★受講中に書いていたメモを、推敲無しでそのまま上げています。
★誤字脱字、内容の漏れなどあるかと思いますがご了承下さい。。

デザインを考える時にデザイナーが考えること〜デザイナーの頭の中〜 / 秋葉ちひろ氏@Baidu Japan

導入

立ち見がいっぱい
とにかくデザイナーが必要！
- 必要なデザイネーにリーチ出来ていますか？
- うまく協業出来ていますか？

自己紹介

デザイナー/アートディレクター
Web制作関連、Androidアプリ制作関連
農学部出身
Simejiの画面(UI)デザイン
- 新しい機能をどういう風に配置しようか、とか
Android App Designs勉強会
- デザイナー向けのつもりが、半分くらいデベロッパー
デザイナーズハック
- 「技術に縛られないでデザインを考えていく」コミュニティ
- iOS向けとAndroidでは実装技術が違う、、、とか

デザイナーとエンジニアの協業

*こんな印象ないですか？ * どちらからも文句しかない、、 * 美意識高そう、プライド高そう、馬鹿なことできなさそう、、 * 会話のキャッチボールが出来ないことがある、、 * 分からない話をされると自分の世界に入り込む、、

デザイナーへのリクエストの例
- きれいにしてほしい
- かっこよくしてほしい
- ださいのでなんとかしてほしい
これら、具体的に説明出来ますか？
- 伝えたいことがキチンと伝わるデザインにしてほしい？
- アートな要素を入れてほしい？

デザインを考える時の頭の中

コンセプトメイキング

ターゲットを考える
- 欲張りすぎず、明確に決める *いつどんな時に使うのか
- ユースケースを想定する
  - Simejiの録音入力：中国のBaiduから「入れなよ」って
    - おじいちゃんおばあちゃんに孫の声を！
    - 誕生日におめでとうメッセージ
    - アリバイの録音
  - Voicepic
    - 写真と一緒に音声を送る
    - マッシュアップアワード最優秀賞
    - 利用シーンを示すプロモーションムービー
  - paper (iOS App by 53)
    - いいかんじなオシャレなムービー
  - 用途を意識しないグラフィックだけの「カッコイイデザイン」が多い
  - シンプルさと世界観の中間点を考える必要がある

画面の設計

* シンプル過ぎ vs 要素多すぎ
    * デベロッパーは要素過多なデザインに慣れてしまっている
    * シンプルすぎるとアクションが増える
    * 要素が多いと迷いが生まれる
* 画面の設計はインターフェース、ユーザーとのコミュニケーションの端
* 「人間のためのコンピューター」インターフェースの発想と

デザインと実装

Everything comes from observation：全ては観察から
- 電車の中吊り広告の美しさ
- その美しさからデザインパターンを見つけ、適用する
  - パルテノのポスターは「アレっ？」ってなる
使いやすく/コミュニケーション
- カンペリモート
  - 昨
○○しているように見せる
- ふくらみ、へこみ、光っている、、
- 現実世界の光の当たり方
デザイン vs コード
- デザインを考える時にコーディングのことを考えない
- コーディングはデザイン通りに
画像で書き出すと
- 複雑なの表現には楽
- ピクセラレーション
- 縦横比
- 画面密度
コードで書き出すと
- できるだけこちらに寄せる

演出、は省略

まとめ

料理に例える
- 材料を用意：画面の設計
- 切ったり下ごしらえ：デザイン、実装
- 調味：コンセプトメイキング
- 納期やなんやで省略・優先順位が下がっちゃうと良くないよね！

Action!

一般教養レベルの知識を、まずみんなが持ってほしい
- 「世界は分けてもわからない」
- デザイナーだけど、プログラムで何が出来るか知っている
- エンジニアだけど、デザインの最低限のTipsを知っている
身の回りのデザインを自分で分析することからはじめよう

Developer's Summit 2013 参加メモ（３）

★受講中に書いていたメモを、推敲無しでそのまま上げています。
★誤字脱字、内容の漏れなどあるかと思いますがご了承下さい。。

SIの未来ってどうなのよ？/大石良氏@サイバーワークス

導入

サイバーワークスはAWS専業特化というアプローチをとった会社

自己紹介

クラウドノ助
切腹します
「私達の過去のActionがきっと皆さんの材料になります」

会社紹介

大学向けの合格発表サービスを提供：私学の60%くらいが利用
2月の特定の数日にピークが集中
- そこに合わせたリソース調達は現実的でない
AWSと出会う⇒社内サーバ購入禁止令
- 使い物になるのか、セキュリティは、、などを社内利用で実証
AWS Solution Provider⇒最上位へ
日経コンピュータクラウドランキング総合スコア56.6

Action! by AWS

心の底から「やっててよかった」と思ったこと
震災時「赤十字社に繋がらない」というtwitterの声
日本赤十字社にAWS導入（ボランティア）
- AmazonEC2にサイトのコンテンツを移し、キャッシュにアクセス
- 30minで稼働 *「義援金受付システム」やってくれ、というリクエスト
- 負荷分散、メールサーバー、webサーバー、、
- 環境構築2時間、AP構築48時間
- 震災後の迅速な義援金募集に一役買ったのはAWS+ServerWorks

SIって死ぬの？

ネガティブな声

SIは必要悪
SIは終わった
SIは保険屋
倒産過去最多
厳しいのは事実っぽい

AWSでSIオワタ

AWSでハードがいらなくなる
ソフトの流通もいらなくなる
ユーザ企業が自分でシステム構築できてしまう

仮説と検証

AWSをユーザーがコントロール出来る仕組みを作ればいいのでは？
“cloudworks”フリーミアムモデルのサービス
- ユーザー数はうなぎのぼり
- 有料ユーザーが全く増えない
原因は？
予測不能
- リーマンショック
- 震災・原発事故
- AKBあっちゃん
大切なことは、「予測の精度を高める」のではなく
「予測不能な事態が起きても最前手を打つ」＝「適応マネジメント」
顧客が望んでいるのはセルフサービスではなく、新しい技術を安全に利用するための保険
突発的な事態への迅速な対応が求められる
Agileな意思決定

Pivot & Action

cloudworksは無料提供を続ける
SIで収益化

クラウドをやって分かったこと

調達モデル

* SIはいらないんじゃないか？⇒No!
    * これを言うのはみんな「中の人」
    * 顧客はSIerを求めている
    * ただし、求めるものが変化する
* 今までのSI
    * 喉が渇いた！
        * 調達チームと品質チーム
        * 意思伝達にドキュメント
    * 人が変わっても同じサービスを提供出来るように
    * ピラミッド型
        * 人が多いことが前提
        * コミュニケーションが重要スキル
        * 下請け企業は技術じゃなくて人材のバッファ
* これからのSI
    * 喉が渇いた！
        * アマゾン工場からHとHとOを持ってきて、組み合わせて水を作る
    * つまり、組み合わせる
        * Amazonのサービス、MQが最初
        * 使い方が分からないと訳が分からないけど、組み合わせて使えば効果を表す
    * クラウド型調達
        * 非常に小さいチーム
        * つくらない技術≒使う技術
        * 「組み合わせる」分子式の知識
            * AWSのCDP
            * HerokuとEC2+SQS
            * S4cとS3
* 分業モデル崩壊による下請けニーズの縮小
* コミュニケーションより技術
* 人材バッファとしての役割は終了

国産クラウドとAWSは何が違うか

戦艦大和と零戦の共通点は？ ⇒ 一点豪華主義
欧米はシステム思考
レーダーを例にとると
- 日本
  - 技術としては確立していた
  - 実地で戦闘員が外しちゃう
  - 通信網として意味を為していない
- 米国
  - 開発者を母艦に乗せて現場を見ながら一緒に改善を回していった
  *
クラウドでは
- 日本
  - SIer、自社クラウドに載せてる？＊米国
  - 4兆円のECサービスをクラウドに載せて一緒に枯れさせていく
一点にこだわる姿は日本人特有の姿
- 世界に類を見ない美点
- でも、戦争にしてもSIにしても、システマティックな部分では仇
- システム志向が必要なサービス開発には仇
- クラウド構築は車輪の再発明。得意な人に任せる。
- で、日本のSIerは「使う技術」の洗練に拘ろう。
- 黒船に対抗した人、黒船を作ろうとした人は成功していない。
- 成功したのは黒船を利用して商売した人。

AWS導入に必要なもの

クラウドを利用するために必要なものは何？
- その答えは「予算」
- 社内に、社外に未来を示す
利益減るんじゃないの？
- HW+保守運用+SI費用
- 保守運用+クラウド利用料+SI費用
- トータルコストは下がっても、SI費用は上がるのではないか
セキュリティは大丈夫なの？
- クラウドってセキュリティが不安？
  - 外部からのアタック、データ漏洩
  - 内部からのデータ盗難
  - クラウドだと、場所も分からないし誰が見てるか分からないし、、
- AWSは、内部の面は担保します（第三者認証）
- 外部は今まで通りお願いします
- 会社経営に必須の資源は何ですか？それはどこにありますか？
  - 資金は銀行に預けてますよね？
  - セキュリティも可用性も利便性もある
- クラウドも一緒です
  - ファイル耐久性は1千万年に1件無くなるレベル
- NASAと御社ではどちらが強固なインフラ持ってますか？
- クラウドに預けた方が積極的にセキュリティ担保出来る

聞かれるポイントは分かっている

事前に想定し、相手の立場で「何がメリットになるか」考える
- チームが小さくなる
- 一人がカバーする範囲が増える
- 伝える能力がより重要になる
サーバーワークスのAction
- 毎週金曜の夕方、無作為に選んだ2名のエンジニアが社内でLT+UST配信
- Yammerでリアルタイムにフィードバック

まとめ

保険いいじゃないか！
- 日本人は90%生命保険に入る民族
- 顧客は保険を求めている。自信を持って突き進もう
会社も個人も、未来の予測より適応力を身につけよう
クラウド分子式・説明力を身につけ、クラウド時代を突き進もう！

suggest your Action

自分で変化を起こす方法を学ぼう！
周りの独りに、あなたが進めたい技術の話をしてみて下さい
- そしてフィードバックを受けて下さい
変化を楽しもう。SIは楽しい！未来がある！というメッセージを発信しよう
- 中の人がSIをdisるのは、もうやめよう。
未来は、今日の私達のActionの連続の先にある。

Developer's Summit 2013 参加メモ（２）

★受講中に書いていたメモを、推敲無しでそのまま上げています。
★誤字脱字、内容の漏れなどあるかと思いますがご了承下さい。。

HBase at Ameba / 鈴木俊裕氏@サイバーエージェント

導入

AmebaにおけるHbaseの導入事例

自己紹介

@brfrn69
Ameba ソフトウェアエンジニア
テクノロジーラボラトリー

HBaseについて

会場で使ったことある人は20–30%ほど
BigTableのOSSクローン
可用性が高い、多次元ソートマップ、ハイパフォーマンス
Auto Sharding
- 自動分割、運用負荷の分散

Master-Slave型アーキテクチャ

アーキテクチャ説明(Region,、SPOF回避、HDFS)
HBaseの信頼性はHDFSに依存

HBaseのデータモデル

列志向データフォーマット
RowKey/ColumnFamily/Column/Timestamp/value
ColomnFamilyはIO分割したいときに使う

HBaseのAPI

Get
Put
Scan
- 範囲・フィルタ
Increment
- valueのインクリメント
CAS(Compare Ans Swap)
- 簡単なトランザクションが実現できる

HBaseの設計

RowKeyの設計で負荷やデータ量が偏る可能性がある
RowのColumnはいくらでも増やせる。ソートもされるし、更新もAtomic
Joinはない＝非正規化がほぼ前提
クエリに対してスキーマが決まる。
- RDBだとまずスキーム
Codezine「初めてのHBase」読んでね！

グラフDB “Hornet”

Amebaのスマホ向けプラットフォームをリリース
デカグラフ構想
- 各サービスのユーザ層：ミニグラフ
ユーザのグラフ構造を保持するデータベースが必要
- スケール、高スループットが必須
従来はMySQL+Sharding
- Pigg、グルっぽ、なう、みんなMySQL *書き込みのスケールに難
- Shardingの管理が大変
そこでHBaseの採用
- スケールする、速い、Scan、AutoSharding
- 元々ログ解析にHadoopを使っていたので、ノウハウもあった

Hornet

データモデル：プロパティグラフ
JavaAPIの説明
スキーマ（リレーションシップ）の説明：フォロー関係を例に
- RowKey:hash(NodeId)+StartNodeId+type+direction+timestamp+endNodeId
- ColumnFamily:“h:”(単一の値)
- Column:""(未使用)
- Value:Serializeしたプロパティ(dateとかfavoriteとか)
プレフィックススキャンを使ってリレーションを取得（正引き・逆引き）
今後オープンソース公開したい。

社内ライブラリ

社内で複数サービスを同時展開している
DB、一部基盤化はされているが、各サービスで個別に構築している。
- MySQL,MongoDB,Casandra,,,
DBをHBaseに統合することで運用を一元化・障害削減したい
いかにRDBに慣れているエンジニアにとって簡単にできるか

Json Persister

「JSONデータとしてJavaオブジェクトを永続化する」社内フレームワーク
- Beanをシリアライズする
- 主キーとかインデックスとかをannotate
- 主キーで取得(load)、リスト取得(list)。シンプル。
このシンプルなインターフェースを介してHBaseを使おう。
これもオープンソース公開したい。

おわりに

HBase触ってみませんか？

Developer's Summit 2013 参加メモ（１）

★受講中に書いていたメモを、推敲無しでそのまま上げています。
★誤字脱字、内容の漏れなどあるかと思いますがご了承下さい。。

600億件を数十秒で検索するクラウド検索クエリサービスBigQuery / 佐藤一憲氏@google

導入

BigQueryのプレゼン

自己紹介

@kazunori_279/#gaeja/#gcloudja
クラウドソリューションチームソリューションズアーキテクト
appengine ja night管理人(23回くらい)
- AppEngine技術者のための情報交換イベント

Agenda

ビッグデータをGoogleスピードで
- 「Googleスピード」は社内用語、すごく早い
デモ＆事例紹介
- WhitePaper
なぜ早い？
MapReduceとGoogleBigQueryの適材適所

ビッグデータをGoogleスピードで

Googleではコードを書く時に最初にスケーラビリティを考える
アベイラビリティを持つデータ構造
Googleのサービスはビッグデータ
- Youtubeは72h/1min
- Googleの検索インデックスは100PB
- Gmailのアクティブユーザー数は4.25億ユーザー
もともとはAdwords 、結果をすぐに知りたがる
- すぐデータ分析したい、どうする？MapReduce？DWH？

MRもDWHも使わない

DWHはメモリ・SSDをたっぷり積んだアプライアンスが多い
数千万〜数億円規模のハイコスト
ad-hocなデータ分析には対応しにくい
- インデックス・ディメンジョンの事前設計がないとフルスキャン/テーブルスキャンしか無い
データ量に比例して性能向上はハイコストすぎて無理！

so, whatabout Hadoop?

DWHより安価
RDBMSよりスケールする
けど、レスポンスが遅い。簡単なクエリでも数分かかる。長ければ数時間
やはりad-hocな分析には向かない

Dremelという虎の子

大規模並列クエリインフラ
数百億件のフルスキャンが数十秒で完了。
検索は全てフルスキャン
Webコンテンツの分析、スパム解析、トラッキング、デバッグ、解析、全部Dremel
で、そのDremelの公開版がGoogle BigQuery

Google BigQuery

2012年5月公開
1クエリ、35ct/GB、月額120ct/GB
デモは無償で一般公開（2TBまで）
Dremelのサブセット
- ProtocolBufferのツリー構造には未対応
使い方としてはGAE/CSVインポート⇒Cloud上のエンジン⇒Googleスプレッドシート/etc

デモ＆事例

Wikipediaの全ページの全更新履歴から、ページ更新TOP10を検索して表示
- select top(title), count(*) from publicdata:samples.wikipedia where wp_namespace = 0;
Wikipediaの全ページからタイトルに数字が含まれるものを抽出
- 正規表現の文字列マッチングが速い⇒非構造化データのクエリも速い
サブクエリも普通に書ける。従来ではスケーラビリティを上げるために制限が多かった
3rdPartyのERPパッケージからインポートした4.5億件の売上データを分析
- bime / cloud上のBIツール
- ちょっと時間かかったけど
Crystalloidsの事例：リアルタイム意思決定支援ツール

なぜ速い？

カラム志向
数万台での並列処理
- Google DCの「規模の経済」
- ディスクI/Oを極限まで並列化
- 圧倒的なフルスキャン性能
階層アーキテクチャ
- クエリの分配

得手不得手

MapReduceも無くならない
MapReduceは大規模バッチ処理
- アドホックには向かない
- レスポンスも遅い
- 技術がややこしい（Tenzing/Hive）
BigQueryは巨大なデータのエクスポートが出来ない
- 複雑なロジック、データ生成、更新、データマイニングには向かない
- マージ処理なんかには向かない

なので

BigQuery
- Try&Errorな分析、トラブルシューティング、あたりをつける、特性をつかむ
MapReduce
- しっかり分析（駆け足でメモ取れず、、）

2013年2月5日火曜日

[DevLOVE]『セカイとカイシャと自分の仕事を考える』参加レポート（メモ）

2013/2/4 セカイとカイシャと自分の仕事を考える@日本オラクル青山センター

http://devlove.doorkeeper.jp/events/2503
参加時に書き溜めたメモです。

本日の目的（私の）

自分と会社の関わりについて再考する
自分がやりたいこと（仕事）を組織ベースで考えてみる
「組織の中での存在意義」「自分にとっての組織の存在意義」について考えてみる

はじめに

「ようこそオラクル青山センターへ！」by papandaさん
説明前後で謎の拍手

概要(DoorKeeperより)

DevLOVE2012ではいろいろ考えすぎてうまくまとまらなかったので、もう一度リベンジしてみます。
会社の中でどうするか、あるいは別の会社を探そうか……などと考える前に、そもそも「カイシャ」と仕事について考えてみましょう。
形式：レクチャー
登壇：高橋征義氏
- 札幌出身。株式会社達人出版会代表取締役、一般社団法人日本Rubyの会代表理事。
- Web制作会社にて主にWebアプリケーション開発に従事する傍ら、日本Rubyの会を設立。
- 2010年にITエンジニア向け技術系電子書籍の制作と販売を手がける (株)達人出版会を創業。
- ちなみにそれまで勤めていた会社２社はどちらもすでに現存しない。
- 著書に『たのしいRuby』『Rails3レシピブック』（どちらも共著）など。好きな作家は新井素子。

intro

DevLove2012では物足りなかったので再演（再構成）
「かつて所属していた会社は2社とも存在していない」ところが重要

本日のなかみ

本日夕方、ファイルぶっとび
TimeMachine超重要
「もうDevをLoveしていないんですか？」
自分戦略、だけど自分の経験は参考にならない、、
けど、色々やってきたのでシェアしたい。
- 会社員
- 任意団体代表
- 営利法人代表
- 非営利法人代表
会社はツール
自分に合ったツールを使う
なければ作る、作らせる、外から使う

わたしの自分戦略？

卒業、入社、吸収されて転職、Rubyの会設立、退職して創業、Rubyの会が社団法人化
自分の戦略を予め考えるのは苦手。難しい
ソフトウェア技術者の戦略ってこんな感じ
- 社内で頑張る
- 転職する
- 独立する
- 起業する
転職
- そもそも他人の評価や時期の問題
- つまり客観的とも実力勝負とも言い切れない
独立・起業
- リスクが大きい、運に左右される
- 全力でリスクがとれるか、リスクを下げられる手がある場合意外はオススメしない
- 成功した人の話はバイアスだらけだし、失敗した人は語りたがらない
なので、心に棚を作る
現実を直視するのは厳しいので、現実から全力で目を背ける

会社とは何か

「Ruby知ってますか？」「（会場苦笑）」「この質問で笑いが起こるのは嬉しいことですね」
法人と自然人
- 法人でなければ「任意団体」
  - 会場も口座も個人名義
  - なにかあったら個人に責任が降ってくる
- 法人になると
  - 口座も作れる
  - 契約も結べる
  - なにかあったら訴えられるのも法人
  - 義務も権利も構成員じゃなくて法人になる
民法：一般的な話：法人の定義
- 権利を有し、義務を負う
- 登記すれば出来る
- 法人
  - 営利法人：構成員に利益を還元できる：頑張って儲けたらウハウハ：事業拡大できる：構成員の生活は保証してくれる（法人差があります）
  - 非営利法人：構成員に利益還元できない：
- 法人以外
  - 権利能力無き社団
  - 任意団体
会社法：会社固有の話：会社法人の話
- 会社はうまくできてる：冒険もできる：税金がとられる
- ひとりが所属出来るのはだいたい1つ
  - それを回避するのが非営利団体とか
  - けどNPOは縛りが多い
    - 理事が10名以上、報告書提出義務、、、
    - 一般社団法人の方が楽

会社と自分との関係を考える

目的が必要
- 「報酬の目標」は実現するのが案外難しい
- それよりも「何かをやりたい」「一人ではできないことをやりたい」を実現するためのツール、と割り切って再定義する

会社っていいよね

平日昼間から動ける
会社は任意団体とするよりも組織を大きくしやすい
一人じゃ出来ない規模のはたらきが出来る
⇒じゃあ何をやりたいの？？？

たまたま見つかった高橋さん

「日本の技術書も電子書籍で読みたい」
できるまで1年
利益が出るまで3年＋数百万円溶けた
やりたいことを思いつくのも難しいし、実現するのも難しい。

実現方法は色々あった？

社内の事業
他社とくむ
個人で取り組む
非営利法人としてやる
けど、会社でやってよかった
- 時間を投入出来る：サービス開発に注力出来る
- しばらく赤字でもOK：会社じゃ許されない
- 関係者（原稿書いてくれる人、読む人）にも安心感
- 周囲に対して本気度が伝わりやすい

「あったらいいな」から考える

突き詰めると、、、
- あったらいいなを考え続ける
- 実現方法を考える
- 実行する
この「実現」の一手段に「会社に所属する」「会社を経営する」etc がある
でも「やりたいこと」が無いとやっぱりしんどいよね

スタートアップと目標設定（DevLove2012ボーナストラック再現）

テーマ「世界を変えるのは、自分自身だ」
大きい言葉。大げさな言葉。
普通の開発仕事とはギャップがある。
けど、よくそういう言葉はよく聞く（特にスタートアップ方面）
多くの場合、実際のところ世界はそんなに変わらない
騙しているわけではなく、進めるにあたって、遠くの目標が欲しい
組織は（犯罪じゃなければ）何をやってもいい
すると、何をしていいか分からなくなる。混乱する
新規事業のほとんどはうまくいかない
上手く行かない事業は、変えないと死ぬ。
最初上手く行かない、のは迷走なのか遠回りなのか進んでいるのか分からなくなって不安
なので、すごく遠くの目標を立てる
多少ぶれても誤差の範囲。それで充分。
例えば「北極星を目指す」は431万光年先を目指すのではなく「北上する」ということ
無限遠にある目標としての「世界を変える」

だけれども

全部が全部遠いわけでもなく
Social Change
Kent Beck 時を超えた〜〜
XPの課題は、ソフトウェア開発と社会の関係の再構築。ソフトウェア開発への新たな価値の創造。
言ってることとやってることのギャップがありすぎないか？？
1987の論文：プログラミングにパターンランゲージを導入したら？というやつ
顧客と開発の関係性を変えるhttp://c2.com/doc/oopsla87.html

まとめ

日常の「あったらいいな」を実現しよう

ここで休憩。

たのしい会社戦略

概要(DoorKeeperより)

自分戦略って考えるのはしんどいし、都合のいい戦略はあまりない。
だったら、「自分」を一旦離れて、「どんな会社があるといいのか」を考えてみませんか。
自分が働きたい会社ではなく、世の中にとってあると良い会社。
ここで考える会社がまだ無いなら、作っても良いかもしれませんね。
形式：ダイアログ

どんな会社・事業があると世の中にとってよいか / 10min

ひとりで考える（メモ）

ひとに優しい
貧乏人にやさしい
たのしくなる
苦しくなくなる
夢がある
やりたくないことをやってくれる

だいあろーぐ（４人で） / 15min

夢を失った人を救う「褒め屋」
個人の夢を応援してくれる会社

いいね！を付箋に / 5min

みんなで話をする / 20min

なんでも出来る人がなんでもやってくれる会社

なにかをやるには、なんでも出来なきゃいけない
少数精鋭でのなんでも屋

エンジニアの欲望をそそる会社

「どんな会社がいいか」だと黒い話が多い
負の感情、欲望がうずまいてくる
男性エンジニアが女の子とペアプロ出来るような会社

二次会できる場所を探せるサービス

芸能プロダクション的な会社

派遣の発展系みたいな
フリーランスの仕事をマネージング、プロデュースしてくれる
本当のマネージャーはこれ。ピープルマネージャー

会社の枠を超える、制約の少ない、ハッカブルな仲間と出会えるあれ

どういう事業であるのかは気にしない
事業にはこだわらず、働きやすいかとかそういうことの方が優先順位が高いのではないか
誰と働くか、が
金が儲かる会社に集まるよね

国境、文化を気にしない会社

公用語を英語にしたりしなくても、自身の行動力や考えで、世界中と仕事ができる
言語より文化
どうやったら仲間になれるのか？
どうやったら仲間だと考えられるのか、思わせられるのか？

社内版クラウドソーシング

Googleの20%のアレ的なのを使って全社的に人を使う
隠れた適性に気づいたり
普段プログラミングしてるけど、実は板前のスキルあるよ！とか
仕事と人のマッチングを、社内でやってみることが出来る仕組みがあると面白いね

吉岡さんより

「どういう事業をやりたいのか」にフォーカスしたかった
nice to have な組織構造は世の中を変えない
世の中を変えられる事業を考えたかったが、そこまで深堀できなかった
コトを起こすために組織が出来て、事業になって、そこにエンジニアや営業やマネージャーが集まってコトを為す。で、その「コト」って何だろう？という話がしたかった

高橋さんより

会社っていうと悪いイメージがある
会社じゃ出来ないからコミュニティ、ってなる
けど、出来ること、したいことベースで考えたら、やっぱり会社というツールは良く出来てる。
入りたいとか入れるとかは一旦置いといて、やりたいことに対してのアプローチとして「会社」という仕組みはうまいこと出来ている。
でも自分ベースだと考えにくいし、辛くなるし、制約もある。
なので、「やりたいこと」とか「あったらいいなサービス」をベースにして考えたら、もっと会社に対しても前向きになれるんじゃないかな、というのが今回の発表を通じて得られたl気づき。

メモは以上です。
ほかの参加者の方のメモはこちら。

【講演録】たのしい自分戦略 -セカイとカイシャと自分の仕事を考える-

貴重なお話を提供いただいた高橋様、
主催の@papandaさんはじめDevLOVEの皆様、
会場提供いただいた日本オラクル様、
ありがとうございました。

登録: 投稿 (Atom)