Hatena::ブログ(Diary)

ヤマモトの日記 このページをアンテナに追加 RSSフィード

2016-09-04

センスの磨き方

去年くらいから絵を描きたくなった。それと同時に絵の勉強っていうか、過去の名画とか今評価されているものとか流行とか、そういったものに関心を持つようになった。

ちょうどPinterestを使い始めたところで、アート関連のボードユーザー積極的フォローして、ストリームをまめにチェックして、いいと思ったもの(好きなものだけじゃなくて、訴えてくるもの、引っかかりを覚えるもの、見ておくべきと思うもの)を片っ端からピンした。ひまな時間があると見直したり、ピンした作品の作者について調べたり、そのピンに関連するとしてPinterestレコメンドしてくれる作品にも目を通したりしている。

あと、Twitter作品紹介をするようなアカウントフォローした。具体的に言うと、アート@ArtsJpn、◆デザインwithアート最前線◆@rejykikafav、Kai Fine Art@Kaifineart とか。

そんなこと生活中のアート濃度がなにがしか上がった。アートセンスが磨かれたかというとなんともいえないけど、まあ、ちょっとは齧っているという下地ができたので、自分認知や考えにそれほど不安を持つことなく、世間にあるアートを考えることができるくらいの状態だ。悪くない。

と、思っていたら、同じようなことを描いているブログエントリがあった。

デザイナーが実践してきた『誰にでもできる』センスの磨き方 - OMGmag

ところで、僕は女性が好きで婦人画に特に関心がある。そういうことで上記のアプローチをしていると、レディースファッションも視界に入ってくる。まあ、見るだけならいいか、ということでそれらもちらちらみたりする。すると、メンズファッションも同じように視界に入ってくる。

自身ファッションにまるで無関心かつ無頓着人間なのだが、同じアプローチを取れば下地が作れることは明白だ。そして、それを買い物の際と朝姿見の前でちょっと発揮すれば、おしゃれおじさんになることはさして難しくなさそうである。まぁどうにも関心も動機もないのだが、いつか機運が高まるかもれない。

さらにいうと、どのようなジャンルであっても同じアプローチはできるだろう。ビジュアルものはPiterestとかで手早くカバーできるのに対して、そうでないものは網を投げて引き上げるのが面倒という違いはあるが、フィードリーダーとか使えば同じようなことはできるのだろう。実際、IT系ニュースサイトフィードを購読して見出しだけでも見るようにしたら、世間話程度ならできるようになった。

結局、ちょっとの関心(を持とうとする動機かなにか)と、頭を使って知識を活かそうとする姿勢、それだけで世界は変わるのかもしれない。

2016-08-17

名古屋アジャイル移動図書館「ふりかえり&ファシリテーション」ブックトーク

以下の二冊を読みました。

ソフトウェア開発を成功させるチームビルディング

現場リーダー技術」の加筆改版本とのことです。

序文(平鍋さん寄稿

今日必要リーダー

チームはある日突然チームになったりしない。少しずつ、行きつ戻りつしている。手をかけ、その意図があれば、少しずつよいチームになっていく。

第3章 ふりかえり

KPTによるふりかえり

継続は力なり。KPT以外の手法もよし(「アジャイルレトロスペクティブズ 強いチームを育てる「ふりかえり」の手引き」など参考になる)。

カンバン仕事術

10プロセス改善」を読みました。

ふりかえりの5つのステップ
  1. 場を設定する(目的ルール確認
  2. データ収集する(ふりかえる対象の期間のできごとのログやメトリクスなどを用意してレビューする、という意味かと思ったが、そういうことではなく(そういうことをしてもよいが)、ふりかえり対象に関する意見抽出することを意図している。KPTで言うと、主にKやPを出すこと。)
  3. アイデアを出す(分析とTの案出)
  4. 何をすべきか決定する
  5. ふりかえりを終了する(感謝の意の表明、ふりかえりのふりかえり(表明じゃんけんなど))
ふりかえりをいつ行なうか?

タイムボックス開発を行なっているなら、スプリントの終了時。カンバンなら(タイムボックスがないので)、チームにとって自然なサイクルで。具体的には1ないし2週間に一度とか。

カンバンのカタ

カンバンには通奏低音として流れる「カンバンのカタ」がある。カタとは空手とか生け花とかのカタのこと。

  1. 目的はなんですか?
  2. 現状はどうなっていますか?
  3. 問題はなんですか?
  4. どのようなアクションを取りますか?
  5. そのアクションの結果、いつ、どのようになっていますか?

改善説教でも、失敗や経験不足の指摘(という千尋の谷への突き落とし)でもない。

目的に対する、探索と検証、段階的なアクションの積み重ね、その促進(教育、場作り)である

と、理解しました。

2016-08-08

書籍「今すぐ実践カンバンによるアジャイルプロジェクトマネジメントレビュー

監訳者の長沢さんから献本いただきました。ありがとうございます。ようやく一通り読みましたのでご紹介します

カンバン」は、価値あるサービス製品をすばやく提供することが求められる今日IT現場マッチする、シンプルプロジェクトマネジメント手法です。現状どのような開発手法を行なっていたとしても、最小限の変更で移行でき、透明性あるプロジェクト運用と、流れるようなすばやい価値提供が実現できます

本書は、全体で約150ページと少ないページ数で、以下を説明しています

語り口は平易でリズムもよく、図や画像も随所に用いられており読みやすいです。各章に配置されたMicrosoft社のXboxプロジェクトでの実践事例コラム理解を助けてくれます。前述しましたが、ウォーターフォールプロジェクトおよびスクラムからの移行方法を手厚く説明していますので、新たにカンバンを導入することを考えている読者には大いに役にたつことでしょう。

私が本書を読んで得た最大の収穫は、カンバンにおける見積り方法です。本書の12ページにさらりと説明されている計算式がその答えです。どうしてこんな簡単計算でよいのでしょう?それは、ふたつの理由によるものかと思いますひとつは、見積りはその時点での予測であり、それ以上でもそれ以下でもないからです。見積りは方向を示すコンパスであり、探検者は歩を進めながら何度もそれを眺め、目的地に近づいて行きます。一歩も歩かないで正確な答えを得ることはできません。見積りに対するこのスタンスは、書籍アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~」に通じています。そしてもうひとつ理由は、カンバンプロジェクトの流れに着目しており、仕掛り中の仕事を極力減らすことに関連しています。このために、複雑(なわりに正確でない)な見積り依存する必要がないのだと考えられます。「アジャイルプロジェクトはい完了するのかはっきりしない」というよくあるイメージに対しても、本書は「納期を守る」として一章を割いて説明し答えています

カンバンは、チームが今どこにいるのかをあからさまなほど見える化ます。もしかしたら、カンバンを始めたばかりのチームは、カンバンが突きつける現実困惑し、以前の計画主義的なやり方(バッファが多いので問題が隠れやすい)に戻りたいと思うかもしれません。しかし、それこそがカンバンのねらいだということを忘れないでください。カンバンはチームやメンバーを辱めようとしているわけではなく、現状を見える化し、問題ひとつひとつ対処していくことを促しているのです。チームには、改善学習マインドを持って柔軟かつ積極的現実対処していくことが求められるのです。最小限の変更で始められるカンバンですが、このような体質改善も徐々に行なっていくことになるでしょう。カンバンがもたらす見える化はそれを促進してくれます。また、ファシリテーションサーバントリーダーシップの考え方やテクニックが活きるでしょう。書籍カンバン仕事術」の第10章あたりも参考になると思います

カンバンは、プロダクトの開発、保守運用に「流れ」を作ります。瞬間最大風速や、最終的な成果だけに着目するのではありません。滞りなく流れるように価値を届けられるようになるために、カンバン継続的改善と学び・成長を支援してくれます。本書をガイドに、価値あるサービス製品を、やりがいを持って提供できるように、進んでいきましょう。

以下は各章の概要と、山本感想です。

2016-07-30

名古屋アジャイル勉強会&わんくま同盟 名古屋勉強会「Coderetreat素振り会」

ほぼほぼ参加者として参加しました。最近は会社でも家でも全然コード書いてなくて、あんまりアレだとまずいかなと思って二三日前にちょっとGame of Life Javaで書いてみたけど上手く書けなくて、これはあかんかな…と思いながら参加しました。

午前中のスプリントでは、ソロでやってみようということでやってみたんですけど、やっぱり書ききれなくて。で、午後はペアでやったんですけど、これが以外にできてですね、3スプリント目はC++でほぼドライバーでやったんですけど、半分くらいの時間で書けました(TDDじゃなくて、いきなり書きでしたけど)。

お題に慣れてきたのと、ペアの方が集中して脱線が少なくなるというのが効いたのかと思います。ペアプログラミングってアジャイルプラクティスの中ではそれほど普及してない気がしていますけど、使い所あるかもね、と再認識しました。

コードはやっぱ書いてなんぼですね。勉強になりました。ありがとうございました。

2016-07-29

名古屋アジャイル勉強会 「ユーザーストーリーで学ぶスクラム」

ユーザーストーリーマッピング技法としては知っていて、プロダクトの全体像を掴み個々のユーザーストーリー位置付けを把握するために有効だと認識もしているつもりでしたが、なにせ実戦で使ったことがないのでもうひとつ分かっていませんでした。

今回の名古屋アジャイル勉強会では、誰でもよく知っている童話や、最近話題ゲームなどをお題にユーザーストーリーマッピングを行いました。これがとてもよいお題で、ユーザーストーリーマッピング直感的に理解できたような気がします。

とてもよかった。ワークショップリーダーを努めてくださったYou&Iさん、参加してくださったみなさん、ありがとうございました。

2016-07-20

名古屋アジャイル移動図書館「アジャイル手法スクラム」ブックトーク会

まえがき、目次、解説、あとはパラパラめくって目についたところを拾い読みしました。

本書を書いた動機IT世界で、計画主導のウォーターフォール式はうまくいかない。進化的で適応的なスクラムを考案し、定番となるまで普及した。しかしIT界以外では知られていない。そこで、スクラムを広く紹介するべく本書は書かれた。

スクラムトヨタ生産方式(「ムダ」の概念改善)、OODAループフィードバック適応)などをベースに考案されている。

継続的改善を旨とし、プロジェクト完了を待たずにフィードバックを得るための工夫を多く行っている。

感想:思っていたよりもソフトウェア開発方法としてのスクラム説明している本だった。もっとスクラム一般化して説明したり、IT界以外での適用事例を書いた本かと。

野中SECI理論や、NEW NEW論文とのつながりが説明されるあたりはちょっと感動的だった。


アジャイル開発とスクラム~顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント

アジャイル開発とスクラム~顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント

野中論文が気になったので、第8章 竹内・野中スクラム論文再考(「新しい新製品開発ゲーム」)を読みました。

  1. 不安定状態を保つ(完全な計画なしでプロジェクトを始める)プロダクトバックログ
  2. 自己組織化自主性のある自律的組織)開発チームとスクラムマスター
  3. 開発フェーズの重複(工程を区切ると一見リスクは減るが、不自由になる)コミュニケーション
  4. マルチ学習(さまざまな次元の学び。個人、グループ業務、開発技術マネジメントそれぞれに関する学びと成長
  5. 柔らかなマネジメント自己相互愛情サーバントリーダーシップ自己組織化されたチーム
  6. 学びを組織で共有(プロジェクトの学びから組織改革へ)SECIモデル

組織成功体験を制度化する。すなわち変化に弱くなる。→どう抗うか?「実践リーダーシップ」?調べてみる

2016-07-01

組織テストを書く文化根付かせる戦略戦術

社内講演会和田さんに来ていただきました。僕も聴講できたのでそのメモです。基本から最近の知見まで、まんべんなく丁寧に説明いただきました。

戦略

アジャイルサムライアジャイルソフトウェア開発を広く浅く説明した本。入門書としてお勧め

アジャイルプログラミング必須プラクティス

テスト」が重複している?

リファクタリングユニットテスト依存している。なので、ユニットテストリファクタリング、の順。

ユニットテストリファクタリングは、いつ行なうかについては語っていない。それらの有用プラクティスなので、早い段階から不断に行ないたい。それがテスト駆動開発

動作するきれいなコードテスト駆動開発価値であり目標

設計をしない」は誤解。ただし、文書化したり承認を得たりするかというとこれもまた違う。

TDD黄金の回転の中で、消極的になってなおざりにされるのがリファクタリング

リファクタリング普段生活における掃除のようなもの普段からまめにやっていれば簡単だが、ためると大変。

大変なことをするには上司許可とか必要になり、いよいよやり難くなる。

リファクタリング普段からついでにやるしかない。

労力をかけて自動テストを書き溜めたのは、テストのご利益を求めるから。なのに、実際にはいつもテストを直している手間ばかりかかって利益が感じられない。つまりテストコードリファクタリングする必要がある。そして、それは(プロダクションコード場合と同様に、あるいはそれ以上に)溜めずに不断に少しずつやるしかない。テストテストは、現実的には、書いた直後にしかできない。

テスト理想MICE

ユニットテストのサイクルの外側に、アクセタンテストのサイクルがある。さらに言えば、その外側にリリースデモがあり、…

テスト駆動開発は、「ギャップをコントロールする技法」(テスト駆動開発入門、ケントベック

「Testing vs Checking」にならえば、TDDテストは、一周目だけはTestingであり、二周目以降はCheckingである、といえるだろう。

誰が何のために(大きさやタイミングは無視して)

テスト駆動開発工数が2割増え、バグが8割減る(MS, IBM実践事例報告から

どの職場にも有効な、テスト駆動を定着させる方法はない。

テストを書く時間がない」は、テストがない→不安テストかけない→の悪循環ケントベックの回答は、自動テストを書く→ストレスが減る→テスト書く余裕ができる→の好循環。

陥りがちな失敗:理想を追いすぎる。現状をかなぐり捨てて理想に挑む。

処方:着地可能なToBeを作って、自分たちに合ったペースで進める。

小さく始める。アンダーザテーブルから

技術負債の四象限

テスト品質を上げない。テスト品質可視化する。見えたもの改善設計プログラミング)するからよくなる。

戦術

どこからやるか?一番困っているところからバグ修正のところからバグは偏在するという意味でも効率的)、静的解析のスコアの悪いところ、など。(リーン開発の現場リスクが高くて、手動コストが高くて、自動化コストが低いもの、で並べて、上から取り組む。

全員で始めるのは大変。できる(向いてる/キーになって欲しい)人からすこしずつ。例えば若手のホープから

こだわらない。全部、テスト駆動テストファーストユニットテスト、実行速度、網羅性、モック、等々。徐々に。

レガシーコード改善ガイド

レガシーコードジレンマテストがないかテストが書けない、に対する処方箋

見える化

メトリクスを取る(最近の静的解析ツールはいろいろな数値を取ってくれる)

静的解析ツールは警告が死ぬほど出るので、一番ゆるい設定から徐々に進める

メトリクスは変化を見る

静的検証ツール対象コードを動かさないで評価できるという特質をうまく使うべき

コードレビュー

インフラに投資しよう

githubgitをhostしたから栄えたわけではなく、レビューリクエストをうまく扱えるから栄えた。この点を学び取り入れることを考える。

コードレビューをするから質が上がるのではなく、コードレビューされると思うから上がる

実装をなぞったテストを書くと、実装を直すときに必ずテストを直すことになる。これはコスト的に合わない。そのコードインタフェーステストする。あまり細かなインタフェーステストしても同様なので、ある程度の大きさのインタフェーステストする。

現場の取り組み

テストの質を測るには(実験的なものも含め)

量を増やすとき品質も上げる

最初はとにかくテストがあることのよさを体験してもらうことが最優先

次に増やしてメンテナンスすることが大事になるので、最初の段階を過ぎたら意識する

よいテストコード:だいたいプロダクトコード同じ価値観

コーディング時間は増えるが不具合対応は減る。前工程に倒れるのでプロジェクト完了見込みが見えやすくなる。受託開発にはこれ大きい。

感想

以下は一般論ではなくて、僕の仕事から考えた感想です。

現状リリースまでの期間だけで考えるとTDDするメリットはあまりないと思う。しかし、そのコード継続的保守されることを考えるなら、動作するだけでなくきれいなコードである必要がある。それを維持するための治具としてのユニットテストセット、維持するための習慣としてのTDD、の必要性はあるだろう。

オブジェクト志向でないコードに対するユニットスティングgit-flowワークフローテストと込みで書かれテストパスしているコードレビューはこれまでのレビューとどう違うか、詳細設計は無くしていいか、代わりになにか必要か、などの考察余地があるだろう。

2016-06-24

AgileJapan2016<企業内サテライト>富士通(新横浜)

サテライト名古屋>に参加予定だったのですが急用で参加できませんでした。こちらには参加できました。

第I部 Agile Japan2016 (5/31東京開催)から

和田実行委員長あいさつ

アジャイルジャパンは、アジャイルを考える場、様々な立場、関心、手段、を繋ぐ」

基調講演(1)「スクラムイノベーションを加速する 〜ソフトウェア以外にも適用されはじめたアジャイル〜」

TEDでも話しているとのこと。探してみてみよう。

最も普及しているアジャイル開発手法であるスクラム」の生みの親の一人ジェフサザーランドの会社にお勤め。非ソフトウェア分野でのスクラム導入・活用を指導今日はその実践報告。

ジェフサザーランドスクラムは半分の時間で倍の成果をあげるチーム戦術であるとしており、ソフトウェア分野専用のものではないとしている。)

事例紹介、スクラムが注目される背景

スペースX社のイーロン・マスク火星ロケット開発をスクラムでやっている。ひとつのチームがソフトウェアハード設計と実装をすべてやっている。

ある流通業者はロジスティックセンター仕分けロボットの開発と運用スクラムでやっている。制御ソフトアップデートすることで業務改善ができるのが強みになっている。

投資家は事業者がスクラム採用するのを好む。なぜか?スクラムコストを下げ価値を上げるから

ポルシェリリースサイクルは7年(開発にはもっとかかる、オーバーラップでやっと7年になっている)。一般にハード製品リリースサイクルは長い。ソニーのプレイステーションは4年おきに出る。これが1年毎になったらビジネス的にどうだ?

市場アジャイルを求めている、価値を早く提供して欲しがっている。

半年以内に成果の出ないプロジェクトキャンセルされる。

教育分野にスクラムが導入されつつある。期間を短縮し、スコアを上げている。

スクラムについて

スクラムは「偉大なチーム」を求める

スクラムマスタースクラム実施する際に置かれる役割ひとつで、開発チームのコーチングや補佐を行なう)の仕事はチームをハッピーにすること。チームをハッピーにするとは、フラストレーションから解放すること。

ボーイングスクラムを使っている。ウォーターフォール型の見積りと計画をやめた。アジャイル見積り当事者が、繰り返し見積もる。

スクラムを導入するために

マネージャが納得しなければアジャイルの導入はない。スクラムリスクが低いことを示さなければ、マネージャは嫌がる。

バーンダウンチャート(バックログ量を時間軸で描いたグラフ)を描け。リリース顧客提供サイクル)バーンダウン、スプリント(開発サイクル)バーンダウン、デイリーバーンダウン。透明性はリスクを低減する。

テスト駆動開発(TDD)の考え方はハードでも使える。ダブル(まだできていない部分の代替)を使って実物を作っていく。

ハード開発はサプライヤに依存するので、サプライヤにもスクラムサイクルに入ってもらう必要ある。

オブジェクト指向アーキテクチャ採用すべき。すなわち、コンポーネントインタフェースを介して連携し、インタフェース仕様を満たしていれば交換可能な構造にする。

ハードであっても、スプリント毎に設計、実装、テストする。ソフトウェア場合と同じ。あるいは、DevOpsに近い。

ふたたび事例紹介

カリフォルニアワイナリースパーリングワイン生産世界一)でスクラムを取り入れた

ワイナリーを、早く、幸せにする方法従業員全員で考えた。アイデアを要求とみなしてバックログにした。バリューストリームマップを作った。二倍のワインを半分の時間で作るための見える化ボードを作って運用した。

サーブは一週間スプリント戦闘機を開発し、6ヶ月単位リリースしている。パイロットスクラムチームの一員。

ノキアは五ヵ年計画を遂行したら会社のシェアがなくなってしまった(硬直した五カ年計画なんて時代遅れ

ボッシュは役員がインセプションデッキ(アジャイル開発で使われるプロジェクト憲章)を書いている。ミッションに対する課題が、各事業部のミッションになる。

自動車メーカーでは、車のモジュール化が重視され進んでいる。モジュール毎にプロダクトオーナー製品コンセプトや要件に責任を持つロール)がいる。一週間のスプリント最初はなにもできない。部品サプライヤーとの契約も変えないといけない。大変だけどフィードバックから学び、徐々にできるようになる。メンバーはプロダクトオーナーと話、何が障害なのか理解する。

まとめ

ミッションとゴールと課題が見えないマネジメントとはいったい何だ?意味がない。スクラムは透明性と検査適応を柱とする、あらゆる問題を解決するフレームワークだ。


基調講演(2)「アジャイルなIoTプラットフォーム開発」

玉川氏の開発手法遍歴。研究所時代アドホックラショナル時代:ユニファイドプロセス(RUP)、留学時代スクラム、TeamConcertのエバンジェリスト時代:大規模アジャイル。AWS:????、ソラコムリーンスタートアップ

クラウドの登場が初期投資と失敗のリスクを下げた。スタートアップ追い風不安リスクが下がれば、イキイキハッピーになる。

ソラコムの成り立ち

IoTについて考えたときネットワークに弱点があると思っていた。Bluetoothとかあるけど尺が合っていない、モバイルネットワークが適していると思うがヒト向けのサービスばかりでモノ向けがない。このサービスキャリア)をSoftware-definedでやる。というアイデアを思いついた。

ちょっと余談

プラットフォームビジネスにはエコシステム必要一社だけでは成り立たない。パートナー制度、ユーザーグループ、などなど

プラットフォームビジネスソフトウェアベースがよい。フィードバック対応していくスピードのため。

前述のアイデアポイント

1. デバイス暗号化しなくても、インターネットに入る手前で暗号化すればいい。ソラコムサービスクラウド上だから暗号化リソースはある。

2. ソラコムはAWS上のサービスなので、AWSの機能で、顧客サーバーとVPSを組めば安心安全

リーンスタートアップでは、MVP(価値のある最小の製品)を世に問え、と言っている。間違いではないが、価値があるだけでは弱い。MLP(愛される最小の製品)でいこうといっている。

20人くらいの、キャリア(と能力)がある人で始めた。全員がリーダーAmazonリーダーシッププリンシプル参照。新しいモノを作る会社だから定性的な評価が大目。働き方は各自リーダーシップを発揮する。チャットSlackベースコミュニケーションリモート勤務OKなので、だからこそ毎月のランチミーティング、隔週のハッピーアワー(慰労のため定時後に会議室ビールを飲む)を大事にしてる。

計画は、大きなイベントを入れて目標にする、が、固執しない。

アジャイルは何のためか?

人は与えられて生まれ、決断して生きて死ぬ死ぬときに考えるのは自分決断だろう。

自分たちアジャイルを作ってください。

ここまで(基調講演2本)の感想

玉川さんはビジネス成果で勝負している人であってアジャイルは手段でしかない立場。ベンチャー企業として生き残りをかけている人がアジャイルバリエーションひとつであるリーンスタートアップでやっていますというのだから、そういうドメインではアジャイル有効なのは間違いないと思う。Justice氏はスクラムをさまざまな業種で実践することのサポートをしていて、スクラムのよくないところについては言わないだろうことは差し引くべきだが、それでもスクラム汎用性有効性は高いと思われる。我々も、なにかを変えたい、なにかに適応したいという課題があるなら、スクラム賢明選択肢と思われる。

第II部(午後の部)富士通サテライト企画

詳細は割愛ますが、さまざまな環境要因があって従来のウォーターフォールプロセスでは間に合わなくなってきているため、アジャイル開発を始めている。目下の課題は、マネジメント品質評価方法ウォーターフォール前提になっていること。透明性を確保しているつもりでも分からないと言われる。説明責任が果たせないことにリーダーは悩んでいる、といったところ。まあ、頑張りどころですね。僕も頑張ります

名古屋アジャイル勉強会「一言で言うと、アジャイルって何なの?」

今回はワークショップリーダーを努めました。

アジャイルという言葉もすっかり普及して、いろいろな人がいろいろな文脈で使うようになってきていると思います。その考え方の根底にあるもの再確認して、どのようなシーンであってもその意図するところが汲み取れるようになろう、という意図でした。

言いたいことは言えたのですが、ちょっとひとりよがりになってしまったかもしれません。もうすこしワーク内容を工夫して体感から理解できるとよかったなという反省が残りました。

この反省は今後の勉強会で活かしていきます。参加してくださったみなさん、ありがとうございました。

2016-06-15

名古屋アジャイル移動図書館「導入しやすいアジャイルプラクティス本」ブックトーク会

アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣

久しぶりに読み返しました。第一章と第八章を読みました。

第一章
第八章:アジャイルコラボレーション

協調しようとする意思と行動

アジャイルサムライ――達人開発者への道

アジャイルとは…

価値ある成果を毎週必ず届ける」

「たゆまぬ改善のための努力を惜しみなく続ける」

自分の頭で考えるのをやめちゃだめ」

2016-05-25

ロン・ハズバンドが教えるクイックスケッチ

著者のロン・ハズバンドディズニーのアニメーター(グレン・キーンと同期だそうです)であり、美術教育にも取り組んでいる人だということです。

スケッチから学べることはたくさんあると思いますが、この本は動きとその背景、つまり物語を観察し掴みとり、シンプルな線で描きだすことの雄弁さと楽しさを、豊富な作例で教えてくれます

とてもよい本です。図書館で借りてきたのですが、手元に置いておきたい。

クイックスケッチは、スキルのレベルを最高の状態に保ち、創造性を枯らさないための最高の方法です。高い観察眼を維持し、手と目をスムーズ連携させるには、日常的に描き、継続することが重要です。

本書は、クイックスケッチとそのテクニック説明していますポジティブシェイプとネガティブシェイプの観察、複雑なフォームの中に単純な基本形状を見つける方法からアクション分析アクションラインの使い方まで。ディズニーレジェンドが、スケッチの基本要素と、短時間で描くための方法を教えます

クイックスケッチによって向上した能力ひとつが、すばやいアクション分析です。現在では、人や動物の動きを目にすると、その基本形状やそれを構成するさまざまな形状(全体としてまた部分として)を把握することができます。描いている対象空間内での関係性を短時間で見て取ることができるのです。アート必要着眼点に目を開かせてくれました。

クイックスケッチのもうひとつメリットは、「サムネイル」です。サムネイルはクイックスケッチから自然に生まれたもので、クイックスケッチを小さく描くだけです。シルエットの強弱(濃淡)、遠近法比率、形状、筋肉組織、骨格構造などの原則を使うと、サムネイルなら、イラストがどのように見えるかが早い段階でグラフィックスとして把握できます本来サイズで描いたときに遭遇する問題も事前に分かります

クイックスケッチによって腕をみがいていくうちに、私は自分の上達パターンに気がつきました。同じことを表現するのに、以前よりも少ない線しか必要ではなくなるのです。クイックスケッチ目的ひとつは、対象に関する最大限の情報を最小限のライン、最短の時間表現することです。

一日あるいは一週間描かずにいると、紙におろすペンストロークリズムが崩れ、単純な形状を「見て取る」能力が弱まり、クイックスケッチをしているときには感じられる自然な流れを感じることが感じることができなくなります

何かを伝える力のあるラインは、かんたんには描けるようになりません。

クイックスケッチ習得する利点は、アート世界の別の側面にまで及びます。より自信を持って紙に描きだせるようになり、コンセプトを理解することでより早く、よりよい製作可能になり、描く対象がどうしてどのように動くのかを理解できます。そしてなにより本当に楽しいのです。

クイックスケッチは楽しんで行ないましょう。スケッチを満喫しましょう。なにが起こっているのかをじっくり観察(分析)し、アートの授業で学んだ骨格、筋肉組織比率、遠近感、シルエットの濃淡、形状を考慮してスケッチすると、分かりやすく芸術的になります

クイックスケッチ原則

  1. 自分が描くスケッチについて、「誰が、何を、いつ、どこで、なぜ、どのように」を明確にすることを忘れない。
  2. いつでもスケッチブックを持ち歩き、常に描く。
  3. 自分自身に問いかけてみよう。「どれほど創造的な人間になろうというのか?月並みでいいのか?能力の一部分しか活用していないのではないか?ポーズの最初のコンセプトはそれでいいか?身体的(体型)、感情的ボディランゲージ)、性格的(ストーリー)な観点からジェスチャー可能性を徹底的に検討たか?このポーズは最適だろうか?何か見落としてはいいか?そのポーズに別の可能性はないか?」
  4. 作品他人に見てもらうことをためらわない。見てもらうことで自信がつく。
  5. 頭に思い描けることを適切に伝える妨げが、スケッチ能力の不足であってはならない。描いて描いて描きまくろう。

基本

  • クイックスケッチとは目の前にある生命ある対象20〜30秒程度で紙に描くこと。
  • 起きていること、つまり、「誰が、何を、いつ、どこで、なぜ、どのように」をはっきりと描きだす。場所時間は必ずしも明らかにする必要はないが、誰なのか(子供、大人、女性男性の別)、そしてなにをどのようにしているのかを一目で見てわかるように描く。
  • 題材をシンプルな形状(円、三角形、四角形)またはこのような基本形状の組み合わせで捉える。目をそれに慣らす。
  • 体型に着目する。
  • 体は曲がる(曲がりやすい)ところと曲がらない(曲がりにくい)ところがある。
  • 重心
  • すべてを描ききらなくても、ある程度描けば目が補完する。

アクション分析

The Art of アナと雪の女王

もう一冊、大ヒットアニメーション映画アナと雪の女王」のコンセプトアート集です。

ディズニーがどのようにして作品を作り上げていくのかをうかがい知ることができます。それはまさにデザイン思考に基づいたアーティストコラボレーションの場であるようです。アートエンターテイメントをこのように扱うことができるということ、そしてそのクオリティに感嘆せずにいられません。

それにしても、