- 作者: ドストエフスキー
- 出版社/メーカー: 光文社
- 発売日: 2012/02/10
- メディア: Kindle版
- この商品を含むブログ (1件) を見る
(782+756+864+1080+684) / 980 = 4.25
なので4ヶ月で読み切れば元が取れる。普通に読んでいくと2ヶ月くらいかかるので、言うほどお得でもない。普通に買う方が良いかもしれない。
光文社古典新訳文庫がたくさんあるのは良さそうに見える。
(782+756+864+1080+684) / 980 = 4.25
なので4ヶ月で読み切れば元が取れる。普通に読んでいくと2ヶ月くらいかかるので、言うほどお得でもない。普通に買う方が良いかもしれない。
光文社古典新訳文庫がたくさんあるのは良さそうに見える。
先日、一休.comを運営する株式会社一休の社内テックトークで『スマートフォンアプリ開発における共創的な開発チーム』というタイトルでお話しさせていただいた。元々、ずっと考えてきたエンジニアとデザイナーのコラボレーションというテーマを言語化してみたいと思っていたのだが、そこに丁度Fablicでの現場の体験を話して欲しいという依頼があったので、絡めた内容でスライドを作った。
しかしこの言語化する作業が想像以上に大変で、週末を二回潰して準備をした。結局今まで勉強したポインタになる書籍を紹介することで、なんとなくバックグラウンドについては察してもらうというスタイルになった。
タイトルも迷って何パターンか書いてみたのだが、最終的には「共創的」という耳慣れない言葉を採用した。本当は「Collavorativeな開発チームでのアプリエンジニアの役割」とかの方が言いたいことに近い気もするが、これはこれで何だかわからないので見送った。
Fablicで使っている手法について紹介したが、自分が入社する前からあったものもあるし、自分が関わって開発したものもある。これらは当然ながらFablicの開発チーム全員の成果であることを強調しておきたい。
とりあえず、現時点で勉強してきたこと、実践してきたことが詰め込まれた発表になったと思う。良い機会を頂いた一休の皆さんに感謝したい。
結構がんばって資料を作ったので、YAPC::Asia Hachioji 2016mid in Shinagawa(飛び入り予定)やpmjp.slack.comオフ会#4でもこの話をしようかと思っています。
Flux(とその実装としてのRedux)は中〜大規模のWebクライアントに向いている設計だと思っているので、具体性を出すためにサンプルとしてTwitterクライアントを作ってみた。iOS版はRIDEと同様にReSwiftを使い、Android版はReSwiftを写経したJava版Reduxライブラリを作って同梱している(用途があれば切り出してもいいかも)。
簡易な実装なので、UITableView、RecyclerViewとの同期問題、アニメーションの問題などは積み残しになっている。
普通にアプリケーションを作る場合に比べてFluxはコード量が増える傾向にあるが、一人で簡単なものを作っているだけではFluxのうまみもなく、実装は結構だるかった。開発に1ヶ月以上かかる場合や、チームが2人以上の場合などであればペイすると思う。
有名な本らしく、同僚から薦められたので読んでみた。人が騙されたり、冷静に行動できなくなる現象を解説した本である。セールスやマーケティングで用いられている人間の行動に関する知見が、社会心理学実験の結果を用いて説明される。
確かにとても面白い本で、自分は読んで良かったと思うのだが、同時にこんな知見が流通している世界に住んでいたのか…と唖然としたというか、少し辛い気持ちになった。もちろん騙す知見を流通させる目的の本ではなく、知っていれば騙されるのも防げるというスタンスで、防衛法も書かれている。
プロダクトマネージャーに関心がある自分としては、4章「権威--導かれる服従」に書かれていた、権威や上司には自動的に従ってしまう社会的な特性があるという部分が印象に残った。プロダクトマネージャーは開発チームの上司ではなく、人事権も持っていないことが特徴であると言われている。この知見を元に考えると、プロダクトマネージャーに権威を持たせないことで、メンバーの自律的な行動を引き出すという目的もあるのかもしれないと思った。
内容を覚えておこうと思って、各章の章末にある設問「内容の理解」へ回答を作ってみた(暇なのか?と言われると言葉に詰まるが…)。折角書いたので、以下に自分のメモとしてコピペしておく。ネタバレも含まれる。
Q1. 動物に見られる固定的動作パターンとはどのようなものか。このような行動パターンは人間行動のいくつかのタイプとどの様な点で類似しているだろうか。またどのような点で異なっているだろうか。
A1. 動物の固定的動作パターンとは行動を始める際にある特定、単一のシグナルがきっかけになっているものである。具体的には七面鳥の母鳥が雛を認識する条件は、ピーピー鳴くことだけであって、他の条件はほぼ考慮されない。
このような行動パターンは、人間の行動の内、少ない指標だけを使って自動的に行動するパターンに類似している。
異なっている点としては、動物のパターンは生得的なものが多いのに対し、人間のパターンは成長期に学習するものが多い点である。また人間が用いる刺激が多種にわたる点も異なっている。
Q2. なぜ、人間の自動的反応はこれほど魅力的なのか。また、なぜそれほど危険なのか。
A2. 自動的反応は少ないエネルギーと時間で正解にたどり着ける点が、複雑化していく世界に順応するためには大変魅力的である。一方で、深い考察なしに行動してしまう場合が多いので、詐欺などに悪用されることが多い点で危険である。
Q1. 返報性のルールとは何か。私たちの社会では、なぜこのルールが強力に作用するのか。
A1. 返報性のルールとは、他人が何かをこちらに施したら、自分は似たような形でそのお返しをしなくてはならないというルールである。
このルールによって人間の活動を広げるに辺り、コミュニティを作って互いに協調して作業したり、異なる集団と交易することが可能となった。このルールが強力に作用するのは、このルールがこうした人間の社会化のための基礎的な条件になっており、深く浸透しているためである。
Q2. 承諾誘導の専門家が利用する、返報性のルールの三つの特徴とは何か。
A2.
Q5. 「拒否したら譲歩」法を使うと、受け手はなぜ (a) 同意した内容を実行し、 (b)将来も進んで親切な行為を行おうとするのか。
A5. 最終的な合意に参加したという意識が高まり、責任感が生まれるため。また、この方法の受け手は満足度も高まるため、将来もよい顧客となる。
Incrementsの知人が社内で輪講していると言っていて、気になっていたので読んでみた。創造的なチームを作るために気をつけることと、そのために必要になるリーダーシップについて書かれている本とのこと。
現代のチームが固定されたメンバー制から専門集団の一時的な集まりになっている(例えば病院、災害救助、スタートアップなど)ことから、チーム構造からチームワーク自体へ注目するという意味で動詞のチーミングが提唱される。
自立的かつ創造的なチームのキーになるのが心理的安全である。
心理的に安全な環境では、何かミスをしても、そのためにほかの人から罰せられたり評価を下げられたりすることはないと思える。手助けや情報を求めても、不快に思われたり恥をかかされたりすることはない、とも思える。そうした信念は、人々が互いに信頼し、尊敬し合っているときに生まれ、それによって、このチームでははっきり意見を言ってもばつの悪い思いをさせられたり拒否されたり罰せられたりすることはないという確信が生まれる。
現在持っている知識の限界を認める…あることについて自分は知らないとリーダーが認めると、謙虚さを誠実に示したその姿勢によって、メンバーにも同様の姿勢を持つよう促すことになる。
心理的安全というキーワードの導入により、このチームには心理的安全はあるか、メンバーは心理的安全を感じているかといった議論が可能になるのが良いと思う。
また、心理的安全を高めようというプロジェクトを行って、結果的に失敗する話も書かれていたのが印象的だった。トップダウンで心理的安全高めようぜ!と言っても効果は無く、心理的安全を高める個々のリーダーシップ行動が重要であると書かれている。
心理的安全についてはThe five keys to a successful Google teamで見たことがあったのでGoogleの文化と思っていたが、この本の方が先に出たようだった。
「フレーミングの力」という章があるのだが、このフレーミングの概念が今ひとつわからない。
フレーミングは人々に行動を根本的に変えてもらうためのきわめて重要なリーダーシップ行動だ。チーミングと学習を促すときにはなおさら欠かせないものになる。また、フレーミングをすると、人々は前向きで生産的な変化に伴うぼんやりとしたシグナルを察知しやすくなり、自分自身のものの見方に対する理解が容易になる。
文中ではこの言葉がいくつかの意味で使われているように感じる。自分が読み取ったのは以下の通りだが、間違っているかもしれない。
専門性が異なる人間同士の混合チームで境界を越えてコラボレーションするための方法として、バウンダリーオブジェクトという概念が紹介されていた。
ボストン大学のポール・カーライル教授は、自動車産業の新製品開発チームの中にある知識の障壁を研究した。そして、バウンダリー・オブジェクトによって、職業や専門知識による境界が取り払われやすくなることを見出した。模型や図の要素を示したり話し合ったりすると、専門用語のわかりにくさが解消されるのである。
これは自分の仕事で言うと、ペーパープロトタイプやFlintoなどを使って作る動的なプロトタイプが相当する。確かにアイデア段階でデザイナー、エンジニア、ビジネス職が集まって議論する際のベースとして一番有効なのは、見て触れるプロトタイプである。
そしてプロトタイピングいいよねと言うより、バウンダリーオブジェクトとして有効だよね、という視点で考える方が応用範囲が広いように思う(やっていることは同じで、言葉が違うだけなのだが)。自分の意見が理解されないときや相手の意見が理解できないときに「この場合のバウンダリーオブジェクトになるものは何だろう」と考えることで、図を描いたりプロトタイプを作ったりする具体的な行動に移れるようになるのではないか。
多少冗長で読むのが辛いところもあるが、現代的なチーム活動とリーダーシップについて大切なことがまとまっていると感じた。自分の経験上も、確かにこの本に書かれている条件が満たされていたチームは良いチームだったと言えると思う。そういう「あー確かに」と言えるような良いチームの条件が言語化されているところに本書の魅力がある。
ワーク・ルールズやHow Google Worksが好きであれば、さらに楽しく読めるかもしれない。
チームが機能するとはどういうことか ― 「学習力」と「実行力」を高める実践アプローチ
PMJPのSlackでドラッカー風エクササイズというのを教えていただいいた。メンバー同士の期待の摺り合わせるためのワークショップとのことなので、チームのキックオフ時や新しい人がジョインした際に行うと、チームの心理的安全を高めることができるかもしれない。
ここ数年で自分のお酒の嗜好が日本酒に移って、ときどきお店や家で飲んでいる。そして日本酒はだいたい東京駅のはせがわ酒店で買っている。
お店の仕入れと回転の良さからか、置いている銘柄が毎日どんどん変わるので、見る度に知らない酒蔵や新作に会えて楽しい。何が入荷しているかはオンライン店の新着をチェックすることである程度把握できる。
しかしIT業界民としては東京の西側が活動の中心になるので、東京駅にはほとんど縁が無い。そこで自分は例えば恵比寿から新宿に行くときも、わざわざ東京駅経由で中央線に乗ったりする(JRの規則的にもOKなはず)。新幹線で関西方面に行くときも最寄りの品川駅ではなく、東京駅まで行って乗っている(…なんでこんなことしてるんだっけ?)。
以上、最寄りにいい酒屋がない民のTipsでした。近所にはせがわ酒店がある人がうらやましい。
余談だけど、新幹線のEX-IC予約は「品川-新大阪」のように品川で取らずに、「東京-新大阪」のように東京駅で予約すると、品川駅でも東京駅でも乗れて便利*1。時間があれば東京駅まで、なければ品川駅でという使い方が可能になる。
このエントリーは読者としてスマートフォンアプリ開発者とWebフロントエンドエンジニアを想定して書いています。
CROSS2016に出るので、最近の自分の考えを整理しておく。
最近ReduxのSwift実装であるReSwiftを使って開発している。使った感想なども最後の部分に書いたけれど、このエントリーの本題はアプリの状態管理の話。
iOS、Android共にアプリを実装しようと思うと大抵シングルトンが必要になる。各ViewController内をまたがってデータを共有したいというユースケースが多いからだ。例えば
UserManager
LikesManager
BookmarkManager
などなど。もちろんアプリの内容によってこれらの顔ぶれは違ってくると思うけれど、大抵UserManager
以外にも一つ二つはシングルトンが存在していることと思う。これらはどのViewControllerから呼びたいし、状態を一意に保ちたいものたちだ。DIでインスタンス化を制御することはできるが、結局内部的にはシングルトンである。
自分はシングルトンを増やすことには抵抗があった。シングルトンは様々なところから使われ、内部状態が常に書き換わっていく。これが増えていくと、結果的にアプリの内部状態がどうなっているのか把握できなくなっていく。今UserManager
がどんな状態にあるのか(初回の起動なのか?ログインしているか?ユーザー情報の更新は終わったか?)を想像しながらコーディングやデバッグをすることになり、これは結構なストレスである。もちろん今までこれをずっとやってきているわけだが…。
しかしアプリ内でデータを共有したい、データを一意に保ちたいというニーズはなくならない。であれば、アプリは全体が大きなシングルトンであると考えてしまったほうがいいのではないか。ReduxのStoreがそんな思想で作られているかは知らないが、結果的にはそういう作り方を強制される。自分にはこの制約は結構しっくりきている。
野放図に作られるシングルトンは更新のための規約を持たない。どこからでも呼び出してメソッドを叩けば更新される。また、更新や状態の読み出しのためのメソッドの命名も実装者依存なので、結果的にはregisterUser
, isLoggedIn
, addLike
などの名前が増えて行く(実装者にしても別に名前を混乱させる意図はなく、オブジェクトに注目して命名すれば自然とこうなると思う)。
ReSwiftのREADMEから転載
Fluxでは変更をActionに集約するという強い制約がある。すべてのActionはなんらかの状態更新を行うために発行されるので、ActionをLoggerに流していればアプリの起動時からの状態更新をすべて追うことができる。今の所は時々デバッグに使っているくらいなのだが、これをクラッシュ時に送信するというアイデアもあるようなので試してみたいと思っている。
別の効能としては、内部状態が実装者である自分の制御下にあるという、ある種の全能感が得られていてとても気分が良い。状態に起因する不具合があっても、必ず追いかけられるという安心感はとても心を落ち着かせてくれる。
感情的な部分を取り上げたが、内部状態が制御下にあるということは、開発メンバーが加わったり変わったりした際に開発がスケールすることに繋がるはずだ(まだその場面に直面していないので断言はできないけれど)。その辺りは大勢でステートルフなGUIをメンテナンスするという問題に直面したFacebook発祥のフレームワークだなという印象である。規約に沿って書けば誰でも内部状態が管理できる仕組みになっている。
結局の所、ある程度複雑化したクライアントサイド開発とは、状態遷移をいかに管理するかということに尽きるのではないかという気がしている。ユーザーからの入力、サーバーからのGETやPOST、様々なイベントがアプリの内部状態を変化させる。このイベントとそれによって起こる更新処理をどうモデリングして実装に落とすのかでアプリの複雑さは変わってくる。モデリングというと偉そうだが、要するに状態をすべて書き出してその遷移を記述するということである。
もちろん方法はFlux系だけではない。例えば状態遷移をステートマシン(有限オートマトン、FSM)として記述するというアイデアもある。今やっている開発の中でReSwiftと並行してSwiftStateも試してみたのだが、ログイン処理などはステートマシンで記述すると読みやすく書けそうだった。ステートマシンを使う手法はゲーム方面ではよく使われていそうなイメージがある(未経験なので詳細は不明)。
状態遷移の管理という観点で捉えると、Flux、ステートマシン、MVVM、Promise、FRPは対象としている状態の大きさの違いなのかもしれないとも思う。Fluxはアプリという大きな単位で状態を管理するためのアプローチである。Promiseはもっと小さな単位の状態遷移、ステートマシンはその中間くらいというイメージを持っている。PromiseやObservableはまとめることでより大きな状態遷移を作ることもできるので、小さな状態遷移を積み重ねて大きな状態遷移を作るものとして考えても面白い。
増え続ける状態と、その遷移をどうモデリングして管理していくかというのがアプリ開発の課題であると考えている。
しかし状態遷移をすべて書き出すプログラミングは、今までのように状態遷移を意識しないでプログラムを書いていた時よりも大変になる。自分がReSwiftを使っていて感じている問題を以下に書き出しておく。
現在進行形で実験している最中なので、特に今すぐReSwiftいいよと勧めるつもりはないけれど、この方向性はしばらく掘ってみたい。規模の大きいアプリを構築するために、状態を管理する仕組みが必要というのは今後も出てくる話題だと思う。
アプリ開発と状態遷移の管理 - ninjinkun's diaryシングルトンが状態を持つというのは悪夢のシナリオでは?
2016/02/03 01:05
@qtamaki 悪夢なのですが、グローバルな状態を持たずにクライアントを作るのは難しいと思います。少しでもましにしたいと思ってFluxでの管理を試しているところです
— ninjinkun (@ninjinkun) 2016年2月2日
アプリ開発と状態遷移の管理 - ninjinkun's diaryそれ、シングルトンではなくて、グローバル変数では?スコープがグローバルであることは、シングルトンの要件では無いような……
2016/02/03 09:09
仰るとおり、このエントリではシングルトンをグローバル変数と同義で使っています。言いたかったのはグローバルな状態+手続きなので、リポジトリと言った方が正確だったかもしれません。ただ自分の経験から言うと、クライアントではこの種のリポジトリはシングルトンとして実装されるケースが多かったので、クライアント開発者がイメージしやすい言葉を使いました。
ReSwiftを使ったアプリ「RIDE」がリリースされました。このエントリーで考察したことが実装に反映されているアプリになります。見た目は普通ですが、ウォッチリストの同期部分などを見て頂けるとReSwiftの恩恵がわかるかもです。
ReSwiftについて発表した資料を公開しました。
その後Reduxで小さなアプリを作る実験をやってました。個人アプリだと要件は合わないと思います。
昨年からぼちぼち読んでいて、先日読み終わった。どういう話か知らずに読み始めたのだけど、ナポレオンのロシア遠征を題材に、史実の人物とオリジナルキャラクターを混ぜて作ったフィクションとノンフィクションの間みたいな小説だった。物語の中に戦争の時期と平和の時期があるだけで、特に反戦とかそういう内容ではない。
岩波文庫の新訳がとても読みやすく、また訳者によるロシアの風俗や戦争の話が途中にコラムとして挟まっていて、内容を補完してくれて楽しめるようになっている。
読んでいると、うまいこと言うなーという箇所がいくつもある。文読む月日とかを書くだけあって、トルストイは簡潔で気の利いた文章に執着があるのかもしれない。以下にいくつか抜粋。
「うん、すばらしい、すばらしい子どもたちだよ」なんでもすばらしいと考えることで、自分には手の負えない問題をいつも解決してきた伯爵が相を打った。
1巻。ロストフ老伯爵という、好人物だが実務能力ゼロという人間を描写した一文。
ニコライは底意地の悪い目でピエールを見ていた。それは、第一に、軽騎兵流の彼の目から見ると、ピエールが文民の金持であり、美人の夫であり、要するに女の腐ったやつだったからだった。
2巻。ピエールは主人公の一人。いきなり莫大な遺産が転がり込んできたというチートキャラ。読んでいると、チートキャラだけど彼なりの辛さも抱えているしな…と感情移入しそうなっているところにこの一節。やっぱりピエールは女の腐ったやつだったのかと胸が空くようなニコライの批評。原文がなんなのか気になるけれど、とりあえずこの訳はとても気持ち良く決まっている。
彼は自分でも気づかないうちに、大きな口に酒を何杯かあおって、体にこころよい暖かさを感じ、近くの者みんなにやさしい愛情を感じ、ありとあらゆる考えに対して、その本質を掘り下げずに、表面的に応答する気になったときにはじめて、完全にいい気分になるのだった。
3巻。酒飲みの思考をトレースしている。
死と戦っている十万を超える人間を、一人の人間が指揮できないことを、彼は長年の戦争の経験で知っており、老人の知恵で悟っていたし、戦闘の運命を決するのは総司令官の指図でもなく、各部隊が占めている位置でもなく、大砲や死者の数でもなく、部隊の士気と呼ばれている、とらえがたい力だということを知っていた。
4巻。マネージャーは無力。
何かを望んでいる人間は、望んでいるものをあたかも裏書きするように、すべての情報をまとめる傾向のあることを知っていた。また、そういう場合、矛盾するものはすべて進んで見逃してしまうことも知っていた
5巻。バイアスについての考察。
以前、彼はいい人間だが、不幸な感じだった。そのため、自然に人は彼を避けていた。今では生の喜びの微笑がたえず口のまわりに漂っており、目には人に対する関心がみんな自分と同じように満足しているだろうか? という問いがかがやいていた。そのため、人は彼といっしょにいるのが楽しかった。
6巻。ピエールが様々な経験を積んで内面が変化した後、人々に受け入れられていく場面。
最終巻になぜか付いている訳者のQ&Aも面白い。
Q 第四巻二二九ページのコラム「貴族の荘園」を読んで、ちょっと寂しくなりました。こんな恵まれた人の書いた小説を、私のようなせせこましい生活をしている人間が理解できるのかと。
A いや、大丈夫ですよ。人間の問題はたいてい時空を越えているでしょう。それに、今の日本人の充足感と空虚感は、ロシア貴族に近いかもしれません。逆に、当時の庶民の重労働や飢餓感を想像することの方が難しいでしょう
内容はロマンスありの戦記ものという体裁なので、ぐいぐい読んでしまえる。しかし途中に作者が自分の歴史観を開陳する部分が挿入されていて、これが結構曲者だった。
物語の途中に挿入されている部分は短くてまだよかったのだけど、最後の巻にあるエピローグに文庫の半分のページ数を使ってさらに濃密な語りが入っていて、これがなかなか辛い。物語が終わってからそのまま読み始めたら、全然終わらないし内容は哲学的で小説みたいにテンポよく読めないしで、「俺は早く終わらせて物語の余韻に浸りたいんだよ!」と自分は一人でキレていた。
後日日を空けてから読んだら、歴史と個人の関係を真摯に考察していて面白い文章として読めたので、時間を開けて読むのがいいのかもしれない。
とりあえず今は長い小説を読み終わったあとの満足感に満たされている。
4月に行われたAndroidエンジニアのお祭り、DroidKaigiの第2回が2016年の2/18、2/19開催予定で、現在発表を絶賛募集中です。自分は今回もスタッフとしてお手伝いさせて頂いています。
自分は前回発表したのですが、その後「資料見ました」と言ってくださった方が入社したので、直接のコンバージョンかはわからないですが、採用実績も1あります。
また、初心者向けセッションも要望が多いので、そういった発表もお待ちしています。2016年にAndoidを始めるのに一番近道な方法まとめ とか、とても喜ばれそうです。
技術を深掘りしたい方、裾野を広げたい方、採用に繋げたい方、DroidKaigiはあなたの発表をお待ちしています!