ITインフラ 業務自動化現状確認会を催しました #infra_auto

LINEで送る
Pocket

昨日、「ITインフラ 業務自動化現状確認会」という勉強会を催しました。前々からゼミナール形式の勉強会を開いてみたいと思っていまして、ちょうど @kuwa_tw さんとある話をしているときに流れで「一緒にやりましょう!」と話しかけた事で実現しました。

人が集まるか心配したのですが、ふたを開けてみれば自動化に造詣が深い10人の方にお集まりいただきました。Togetter「ITインフラ 業務自動化現状確認会 (2014.10) #infra_auto」に模様もまとめています。

僕の発表内容

社内向けに開発した”hb-agent”という構築自動化・ドキュメント自動生成ツールについて紹介しました。

勤務先のハートビーツはMSPとして、お客様のサーバを預かり、構築・運用・障害対応・チューニングを一手に引き受けています。その中で、これまで培ってきたノウハウがたくさん存在します。一方、IaaSをはじめとして大量のサーバが即座に構築できる時代になり、かつ自動化が進展しています。そんな中、自社サービスとはちがい、たくさんいらっしゃるお客様それぞれ違った環境がある中で、どのような形で自動化すれば良いのか、自分たちで模索する必要がありました。今回は、その経緯についてお話ししました。

話している中で皆さんに刺さったのが、こういったツールを社内に普及させるために半年程度で完了した、という点でした。良い技術、良いツールを準備しても普及させるのが大変である事は、各地で聞かれます。そんな中で普及できたのは、次の点があったからだと考えています。

  1. 社内勉強会での宣伝
  2. ハンズオン会の開催
  3. CTOを初めとした上層部の後押し

1は、まずは「存在を知ってもらう」事を目的としてやりました。興味がある人を見つけて、まずは同志を作る事ができます。

2は、今考えると最も大切なプロセスだったのだろうと思います。数人を会議室に集めて、ハンズオンを行います。当然、全員集まらないので、何回も(確か5回はやった)行います。その上で、「触って」「感動して」そして「理解」してもらう事で普及を進めます。触る事で何者かがわかりますし、今までと変わる部分をきちんと体験してもらう事で良さを伝えようとしていました。そして、良いと思ってもらえれば、自然と使ってもらえます。

3は、CTOの @netmarkjp さんの「プログラム開発を通じてITインフラ 構築・運用業務を効率化するぞ!」という強い意志のもと、自動化を後押しをしていただけたのはとても大きかったのです。大方針を上層部の方たちと共有でき、その上でリーダーシップを発揮していただけるほど、やりやすいものはありません。

あと、ひらしーさんからドキュメント自動生成部分は公開されないの?という話を頂きました。時間を作って、ちょっとがんばってみようかなと思います。

なお、今回紹介したのは、自動化を進めている事の一部です。他の話は、また機会があれば現状確認の題材にします。

感想

ITインフラの自動化、本当に進展が早いですよね。「Automation Tech Casual Talks #1」という勉強会が2012年にありましたが、その頃とはだいぶ変わりました。1年前ともまた違いますよね。

さて、今回は名だたるWebサービス企業やITインフラを支える会社にお勤めの方が来ていて、とても濃厚な時間でした。そんな中で、話を聞いていて次の点が印象に残りました。

  1. 業務内容によって自動化の方針が大きく違う
  2. 規模と自動化の進展状況により悩みが違う
  3. ツールを調べる・作る力が自動化をより楽にする

iは、特に自社サービス・受託で自動化の方針が大きく違う事がわかりました。自社サービスですと、開発した製品に沿って完成度の高い自動化を進めます。一方で、似て非なるものが出来上がってしまう事があり、その整理に心血を注がねばならない悩みがある事がわかりました。受託ですと、お預かりしたお客様毎に状況が違うなかで、共通した秘伝のタレや結果をベースに最大公約数を見つける必要があります。非常に大変な作業なのですが、これができるとどのようなお客様に対しても、より素早くかつ人によってばらつきが少ない品質のサービスを提供する事ができるようになります。非常に面白い話でした。

iiは、大規模な場合、小規模がたくさんある場合とでまた悩みが変わってくることがわかりました。 例えば tnmt さんの話ではありませんが、皆さんの会社ではどのようなホスト・ロール管理をされていますか?その必要は無い規模?でもその環境って再構築できます?ふむふむ…と色々出ますね。

iiiは、ひらしーさんのように serverspec-runner というプロダクトを作り、B2Bだとよくあるテスト項目書の生成を自動化する事でみんなを幸せにできる人がいます。また、れいさんのように最新の技術をキャッチアップし、より自動化を楽にする事でみんなを幸せにできる人がいます。その中で、自分は何に貢献することが良いのか?は自問自答し続け行動する必要があると、覚悟を新たにしました。

まとめますと、ITインフラ、特にこの日参加した自動化を担当する人たちは、自分の所属する組織の状況を俯瞰し、その中で最も効果がある点に手を入れる事で、組織に貢献している事がわかりました。このような優れた視点と技術を持っている人たちと情報交換をする機会に恵まれ、僕自身とても幸せな時間を過ごす事ができました。

皆さんの発表内容

いつものノートです。オフレコ部分は省いています。

@noexpect さん

  • Jira を用いた大組織におけるノウハウ共有の方法についてのお話

  • ※公開するか判断に迷ったので一旦オフレコにしておきます

@rrreeeyyy さん

スライド: Itamae 使ってみた

  • Provisioning Toolの話

  • Ansible + Serverspec
    • Python + Ruby
    • いろいろ覚えないといけない
    • れいさん的には気持ち悪いとのこと (確かにそうだ)
  • Itamae
    • 先日の Infrastucture as Code 現状確認会 で発表された
    • よいところ
      • Agent Less
      • Simple
      • Ruby DSL Like a Chef (互換性は無い)
      • Specinfraの上で成立している
      • gemでレシピが管理できる(Berkshelfいらない)
  • dry-runいい感じ!
    • diffも映っていい感じ (あれChefでも出なかったっけ)
  • 設定も集約させやすそう
    • 変更も他の設定に波及させやすい
  • ディレクトリ構造
    • provision
      • レシピ
      • いらない場合はInclude Recipesを削除するだけで事足りる
    • spec
      • Serverspecのテストコード
  • デモよかった!
    • レシピ公開が期待される

@oko_chang さん

スライド: 発表資料

  • Cloud Automator のインフラ+開発担当

  • 開発
    • Rails
    • AWS SDK for Ruby
    • AWS Flow Framework (AWS Simple workflowを動かすために使う)
  • 監視サービスは持たず、全部Cloud Watchに集約。
    • 通知もSNSから。
  • SaaSは積極的に使う
    • 人が少ない
    • HipChat連携してる
    • Errbitを使ってエラーもとりまとめている
  • メンバー なんと5人
    • 仕事は兼任
    • 自動化をして開発時間を捻出
  • OpsWorks
    • Load Averageベース・時間スケール(Job集中を見積)でAuto Scaling
    • Auto Healing – インスタンス障害への対処
  • Itamae, serverspec 積極導入中

  • EC2再起動祭り
    • これにも対処しやすかった
  • 問題
    • Web上の設定が見える化できない
  • まとめ
    • 効率化して開発にリソースを割く
    • 設定内容の見える化
  • 議論
    • North Californiaにあるのは?: DRが主目的 マルチリージョンでできるように
    • OpsWorks インスタンス枯渇問題
      • 日本だと起きやすい
      • 足らない問題が出やすいインスタンスは避ける t2系とか
      • 最終的にはSpot Instanceを使う

@koemu

  • 自分自身: 前述の通り

@y05_net さん

スライド: インフラ構築とテストについて

  • serverspec-runner

  • serverspecのテストコードをそのまま利用する
    • テスト結果がテキスト(テキスト表、Markdown, CSV)に出せる!
    • 納品ドキュメントがすぐ作れる!
    • 最高だ!!!

@kuwa_tw さん

スライド: Chef環境の闇

  • 統合Chef Cookbookリポジトリの問題
    • 集約しよう!となるよね普通
    • はまりポイント
    • 依存度高い問題
      • リポジトリの間の依存度が高い
      • yumぐちゃぐちゃ どこ見てるの?
      • 整理した
    • 名前かぶり問題
      • apache, nginx めっちゃあるで
      • Community Cookbook使えない
      • Chefサーバやめない?
      • Renameで対応
      • 今後はCommunity Cookbookにしたい
        • しかし今度はどれ使うの?
        • ★の数?
  • 最初の設計間違えない!
    • (とはいえ、初期の頃はベストプラクティスも無かったから色々頭が痛い。)
  • Community Cookbook どう使うのか問題

  • 集約は無理にしなくても良いと思う

  • Chef-solo + Berkshelf 移行で幸せになれました

  • Chef-serverはサーバ管理に直結しないと使いづらい

@hokkai7go さん

スライド: なし

  • 前の会社の知見が本に活きた!とのこと。

  • Cookbook CI
    • やりすぎなのでは!?
    • 成果物をみるのが正しいアプローチだよね
      • Serverspec
    • コードの見通しも必要だが
    • テストのやり方は決まってない感ある
    • 全部の設定はみられない
    • 全体がちゃんと動く所まで確認できないのがわからん、どうすりゃいいんだ!
  • 自動化に至る軌跡
    • 受託・自社サービス それぞれ違う
    • どんなステップを踏んでどうするのか
    • そこを突き詰めて行きたい

@tnmt さん

  • 資料を作ったモティベーションをはなします

  • 10分デモし倒します!
    • Puppet
  • ホスト管理
    • みんなどうやって管理してる?
    • ホスト名の命名ルール
    • インベントリ収集ツールの結果
    • Zabbixの情報 → 監視しているサーバは存在すると決める
  • インベントリ管理サーバ パワーアップ

  • 議論
    • Consul
      • サーバ一覧出せるよね
      • DNSとも連携できるよね

@buty4649 さん

発表メモ: 発表資料

  • Hubot

  • デモンストレーション!

  • ChatOps事例
    • muninのリンクを返す
    • nagiosのリンクを返す
    • httpingする
    • テストメール送信
    • リマインダー
    • 自動デプロイ
      • CapのWrapperを叩いている
  • 議論
    • Hubotがいいところ
      • 流行っている
      • mentionのハンドリングとかは楽
      • 他のチャットエンジンと切り替えやすい
    • CoffeeScriptの辛み → 非同期パターン

@OmochiStrike さん

  • オフレコ話

おわりに

「理想の勉強会」とは何でしょうか。僕は、ゼミナール形式で知見を交換し、議論しあう場だと思っています。今回、こうして自分自身が参加してみたい勉強会を催せた事を本当に嬉しく思っています。仕事、家庭、個人、色々ある中ではありますが、またゼミ形式で現状確認会を開催したいと考えています。3ヶ月も経てばまた時代は動いているでしょう。その節はよろしくお願いします。

最後に。呼びかけに応じていただいた @kuwa_tw さん、懇親会会場をセットアップしてくれた @rrreeeyyy さん、そして誘導やセッティングを支援いただいた @ttkzw さん、どうもありがとうございました!

LINEで送る
Pocket

EOS 7D Mark II 体験イベントへ行ってきた #eos7dmk2

LINEで送る
Pocket

ええ、行ってきましたとも。Canon Grand Presentation 2014 Tokyoに。

デジカメWatchの「EOS 7D Mark IIの体験イベントレポート」に広く多くの方が欲していると思われる情報が既にあるので、自分で見た内容をとりあえず書いておきます。

※EOS 7D Mark IIは、以下7D2と略して表記します。

DSC_0174

入場時

28日(日) 15:00過ぎに入りました。
それなりに人がいましたが、体験ブース、説明ブース、共に待ち時間なしで入ることができました。講演のブースは人が多かったので見るにはなかなか厳しい状況でした。

説明ブース

EF-S15–85mm F3.5–5.6 IS USM を着けて色々話を聞きました。本当はEF 24–105mm F4L IS USM(いつも使っているレンズ)がよかったんですが、隣の人が使ってたのでやむなしです。

ここでは、動画撮影を試したのだけれど、吸い付くように歩いている人にフォーカスが合い続けます。なお、録画は連続30分まで(一旦切れば続きは撮れる)、電池はどの程度持つかの公称値は発表していない、との事でした。ちょっとしたものか、映像作品を作る際に何カットか撮る場合はあまり問題にはならなさそうです。ただ、長時間連続のビデオ撮影時は外部電源供給で利用した方が良さそうです。

体験ブース

バスケットボール 3 on 3の模様を撮影できるブースにも行きました。

レンズはEF 70–300mm F4.5–5.6L IS USM、EF400mm F2.8L IS II USM、EF400mm F4 DO IS II USM、そしてEF200–400mm F4L IS USM エクステンダー 1.4×です。尚、全て手持ちで試しています。

ISO6400にあげてISを駆使すると、手持ちでも十分問題なく撮影できる事がわかりました。まあ、後で腕がちょっと痛かったですね…。
それに、下手な鉄砲数うちゃあたると言わんばかりに撮れます。ゾーンAFにしておけばだいたい狙った所にピントは来ていまして、あとはちゃんとフレームに収められるかどうかだけの問題でした。

相方もEF200–400mm F4L IS USM エクステンダー 1.4×がついたカメラで試していましたが、ちゃんと問題なく撮影できていました。なお、このレンズは3,620gもあります!10年前だったら屋内で手ブレ無しで撮ろうとすると一脚は必須だったでしょう。

なお、撮影したデータをSDカードに保存はさせてもらえませんでした。EOS 70Dの展示会のときはやらせてもらえたのですが、今回はダメなようです。

ショールーム

常設のショールームも開いていました。

意外に空いていたので、7D2にEF 24–105mm F4L IS USMをくっつけてもらって試させてもらいました。ここでわかったのが、カメラが重いせいか手に持った時のバランスがちょうど良いのです。50Dだとカメラが軽いのでレンズの重さを感じるのですが、7D2だとそうならない。こういう事もあるんだなと感心しました。その分、結婚式等の長時間の使用時は体力を要求されそうです。

せっかくなので、普通に近くのものを撮ったり、部屋全体を撮ったりと自分自身が通常使う状態に近い感覚を試しました。すると、当然でしょうが通常の1枚撮影も問題なくこなせることがわかりました。また、ミラー消失時間も短いのもなかなか良かったです。高速連射のために、ミラーが上がるのも速いのでしょうね。

相方は、カメラもそうですが、カメラ教室の方に興味を持っていたようでした。NikonよりもCanonのほうが写真教室が充実してますものね。

退場時

タオルを人数分、パンフレットを1セット(何か一杯入ってた)、そしてインプレスのムックをもらいました。

手荷物がだいぶ重たくなりました…

まとめと感想

7D2はカメラの性能で動きものが「撮れてしまう」恐ろしいカメラだという事がわかりました。

基礎ができていないと、カメラの性能に飲み込まれてしまいそうです。

僕としては、屋内のイベント撮影時にISOが遠慮なく6,400まであげられて(EOS 50Dではノイズの関係から1,000くらいで止めていた)、かつ普段見慣れているAPS-Cの画角を使い続けられる点が良いなと思っています。あと、EOS 50Dよりもモノとしての耐久性がありそうなのも、安心感があります。

5年使ってきたEOS 50Dは、そろそろ交代の時期です。良い選択肢が生まれました。

LINEで送る
Pocket

PyCon JP 2014 Day 3 感想とノート #pyconjp

LINEで送る
Pocket

昨日に続いてPyCon JP 2014に足を運んできました。日本のカンファレンスながら、英語が飛び交う国際感高いものとなっています。実行委員の皆様、話者の皆様、お会いした皆様、大変お世話になりました。お楽しみ様でした!

それでは、今回もノートをアップしておきます。こちらは2014/09/14(日)に行われた3日目、カンファレンスとしては2日目のノートです。

IMG_2360

抽選会ではpepperが当選番号を読み上げていました。先進的!

2日間を通した全般の感想

  • 科学計算系、特に機械学習とそれに派生する話が他のカンファレンスに比べて多かった。自分がこれらに携わっている時に聞けていたら、もっと研究を楽に進められたはず。
  • PythonとITインフラ系の話を絡めたセッションは特になかった。というか、機会があれば自分が話せばいいのかとも考えている。
  • オフィスアワーが設定されていたのはとても良かった。実は、YAPC::Asiaの発表をしてから、質問したいけどkoemuを捕まえられなかったというコメントをもらっていて、何か申し訳ない気持ちになっていたからだ。実際、PyConの懇親会でもYAPCの発表の件で声をかけられてもいる。
  • Python 2と3の間にある溝をどう捉えるか、Pythonに入れ込んだ事がある人は考えなければならない課題となっている。ただ、僕の中ではまだ3にどっぷりという判断ができないので、辛い。
  • 懇親会は向き・不向きがある事を再発見した。当たり前の事だが、身内だとより現実的に捉える事ができた。今後は、懇親会に来てみたいんだが迷っている人の背中を押す事ができればと考えている。
  • 西尾さんの講演の後、ポスター展示を見てしまうと時間を持て余してしまって、さてどうしたものかと悩んだ。例えば、YAPC::Asia 2014のように、無限コーヒーコーナーを通じて交流を深められる場があると良いのかもしれない。
  • 相方とイギリスに旅行に行ってから英語がスムーズに話せる事の重要性をひしひしと感じていたが、今回さらにその認識を深める事となった。やはり、英語で質問・会話できないのはかなりの機会損失になっている。かなりやり込まないと行けない。もっと異文化交流したい。
  • 弁当やケータリングにハラル・ベジタリアンメニューがあるのは素晴らしい。そして、日本では本当に珍しい。海外のカンファレンスではよく準備されているので、日本人もそう言う意識は高めた方が良いと思った。

Keynote

  • @nishio さん
    • サイボウズラボ
    • 邪悪なPythonista www
    • Slide
  • 感想
    • ソフトウェア技術者の育成、これまで職人芸っぽいものがあってモデル化されていなかった所を、西尾さんが取り組まれているのはいつも感服する。
    • 西尾さんが持っているテーマを改めて棚卸しして伺っているように思った。
    • ソフトウェア工学とはまた違った、ソフトウェア技術者育成のモデルを作る事に、自分も加担していくモティベーションをあげる良い時間となった。
    • 「盲点」がみつかると思わず死にたくなるほど辛い気持ちになりますが、西尾さんの話を基準に考えるとそれは普通の事でそれほど気にする事でもないのがわかり、安心した。
  • 1行でPythonを書くwww ワンライナーの話
  • サイボウズラボ
    • 次世代のグループウェアを研究
    • 利用シーン
    • 自動化
      • 設定管理
      • テスト
      • Jenkinsスクリプト
    • インフラ
      • DRでのバックアップスクリプト
      • P2P automatic failure recovery system 月読
    • 解析
      • 収集
      • データクレンジング
      • 統計処理 NumPy, SciPy
      • 今日はここをクローズアップ
  • 解析について
    • 西尾さんの担当
    • kintoneとGitHubの比較: ソースではなく、データを溜め込む所が違う。
    • kintoneにはたまっているデータを見て、どのようにビジュアライズするか提案する機能がある。これはすごい。 詳細:「おすすめグラフ」の裏側
    • プロトタイプ、Flask + NumPy。
  • Groupware
    • Group + Software
    • Douglas C. Engelbart: Augmenting Human Intellect
    • Googleのある状態: 知性が強化されていると感じませんか?
    • コンピュータによって人間を強化する
    • モニタリング
      • 自分自身をモニタリングする事はできない。ダメな時にダメな自分でモニタリングしても、気づけないのではないか。
      • 他の人にモニタリングしてもらう: 精度は上がるかもしれないが、プライベートな情報等を渡さなければならず、人間関係が問題になる。
      • ではコンピュータにやらせてみよう。
      • やる気の出るアドバイス
        • 僕は前使った時にやる気が出ました!!!
    • 人間の情報を取り込む能力を強化するために、コンピュータを利用していく。
  • 人間の増強の4要素 (Augmenting Human Intellect)
    • Artifacts
      • Computer, Software …
    • Language
      • Design Pattern, 専門用語…
    • Methodology
      • 問題解決のための手順、戦略…
    • Training
      • これらを利用できるための育成・教育
  • Discover – 方法論
    • 詳しくなればなるほど、バイアスに縛られて見えなくなるものがある。
    • だからこそ視点を変えて行く必要がある。
    • Known <–> Unkonwn の間に「不明」な領域がある。
    • まずは「知っている領域」を明確にする。そうすると、盲点を理解できる。
  • 抽象的なものは、具体的なものに紐づける事で理解する事ができる。
    • 例えばTrueの定義の違いとPythonの事例
  • 歴史を追うことで盲点に気づく
    • 例えばなぜPythonにはNew-Styleクラスがあるのか
    • それは型とクラスを融合する必要性があったから
  • 経験をする事で理解する
    • 例えばPythonは 1 / 2 = 0.5 にならない
    • これってMediatorパターンって名前だったんだ!→経験に名前が付けられる事で言語化できる
  • 学びは必ずしもひとりでする事ではない
    • 経験の異なる他人と会話する事で盲点に気づく
    • オフィスアワー、ブログ、メールでのコミュニケーションしましょう!
    • 今後、情報は英語化を進めます。
      • 僕もやろう。
  • 質問
    • Q: 認知的不協和
    • A: U理論 (どう書くか後で西尾さんに聞いた、ありがとうございました!)では7つのステップに分解されている
      • 自分以外の他人を自分が啓蒙するのは、良い思考ではない。自分が変わる方が良い。
    • Q: CEで成功するポイントを挙げていると思う。モデリングをどう考えるかもポイント思うがどうか?Abstraction自体が大事なのではないか?
    • A: とても大事な話だと思う。 エンジニアの学び方─効率的に知識を得て,成果に結び付ける の第3章にまつわる話。
      • 試作して試して確認して…を繰り返して精度を上げる。
      • 人文系のような実験が難しい場合は、Grounded TheoryやKJ法を適用する。

OpenCVのpythonインターフェース入門

  • Masaki Hayashiさん
    • 機械学習の画像認識の研究に従事 (D3)
    • 人物姿勢推定を動画から解析する研究をしているらしい
    • Slide
  • 感想
    • がんばってC++を書く事が減るのはとても良いですよね。今度からPythonで書く。
    • CUDAとかはサポートしていないそうですが、これが直ちに問題になるのは限られた状況かなと理解している。
    • (話とは関係ありませんが)会場設営をもっと早め、せめてもう10分早くやるといいと思った。ポスターセッションが長く続いていたので、入場待ちの人が廊下に溢れていた。
  • 概要
    • OpenCVのPython I/Fのチュートリアル
    • C++で時間を損している人もいる!ぜひPythonでも触ってほしいなー
    • Scikit-learnやPandasが使える人が画像認識も使えるようになるといいな
  • OpenCV
    • Python, Java用のラッパーもあり、C++と同じように使える。
    • 現在は 2.4.9、先日 3.0.0のα版も出た。
  • 応用モジュール
    • 機械学習のライブラリは、OpenCVではなくscikit-learnの利用をお勧めする。実際、連携しやすいそうです(pandasも)。
  • 画像の可視化
    • matplotlib,PIL,scikit-imageはRGB画像で保持するのに対して、nnOpeCVはBGR画像がデフォルト。変換処理が必要。
  • あとは、実際の使い方を解説。
  • HOG, SVMを使って人の検出がOpenCVで検出
    • 詳しい話は GitHub リポジトリにて。
  • 質疑応答
    • Q. デメリット
    • A. 計算速度が遅い
    • Q. 2.4.9か2.5か?
    • A. anacondaで入るのが2.4.9なのでこっち
    • Q: GPUアクセラレーション対応のラッパはあるか
    • A: ラッパがない

Pythonによる非同期プログラミング入門

  • Hironori Sekineさん
    • アライドアーキテクツさん
  • 感想
    • 非同期なコードを書きやすいというだけでもPython 3.4に移行するのはありなのではと考えた。
    • サンプル、あまり実感が沸かなかった。もう少し現実に即した例だと嬉しい。
  • Agenda
    • 同期・非同期のおさらいと違い
    • Pythonの非同期F/W
    • asyncio概要とサンプル
  • 同期・非同期のおさらいと違い
    • 非同期はCPUバウンドな処理には有効ではない
  • Pythonの非同期F/W
    • twisted
    • tornado
    • gevent
    • そして thread, multi process (これはライブラリという訳ではないけど)
  • Twisted
    • イベントドリブン型 NWプログラミングF/W
    • 2003年〜
    • defferedを駆使して書く
  • Tornado
    • FriendFeedが作り始めて今でもメンテされている
    • Web F/W + 非同期通信ライブラリ どちらかを選択する事も可能
    • 非常に高速 アドテクでも使われているくらい
  • さて
    • 選べるけど、どれがスタンダードかわかりづらい。
  • asyncio
    • PEP 3154 のリファレンス実装
    • Python 3.4 から標準ライブラリとなった
    • 各種プラットフォームサポート
    • 既存のF/Wを保管している
    • アーキテクチャ
      • Event loop: プラットフォームに最適なI/O処理を提供する
      • Corutines: PythonでいうGenerator
      • Future, Task: 非同期実行をカプセル化

NOCツアー

  • NOCのみなさん
  • 感想
    • 最高のカンファレンスは最高のITインフラに支えられている。
    • カンファレンスネットワークと、携わっている人はもっと評価されていいと思う。
    • 敷設、及びトラブル対応の手際の良さはハンパない。普段相当取り組まれているのだろう。
    • NOCツアー、仕事の差し障りがあるはずなのであまり大々的にできないかもしれないけど、話がこうして聞けただけでも良かった。そして、いきなりお邪魔してすいませんでした…。
  • See also: PyCon JP 2014 開催前レポート 第3回 会場・パーティについて :CodeZine
  • プログラムになかったけど、急遽(?)開かれていた模様。
  • ネットワーク機材、NOCの模様、及び各部屋への配線の事例について解説。
  • 設計
    • 事前に建物の配置等を確認していた。
    • 綿密に設計書を書かれていた。特に配線。
  • ゲートウェイ
    • Flet’s Nextをこのために引き込んでいる
      • (ONUはいつも家で見るそれそのもの)
    • DualStack-lite
      • IPv4はv6をトンネルしている
      • v6のIPが降ってきているのはそのため
      • IPv4は局側のLS-NATを使って外に出ている
    • カンファレンス2日目は最大110Mbpsをマークしたそうだ(カンファレンス1日目はもっとあったらしい)
  • Macのifconfigの結果
$ ifconfig   # 一部省略
en0: flags=8863 mtu 1500
	ether 84:38:35:??:??:?? 
	inet6 fe80::8638:35ff:fe44:8584%en0 prefixlen 64 scopeid 0x4 
	inet 10.1.0.25 netmask 0xfffffc00 broadcast 10.1.3.255
	inet6 2409:10::504:8638:35ff:fe44:8584 prefixlen 64 autoconf 
	inet6 2409:10::504:5481:e39:453e:628f prefixlen 64 autoconf temporary 
	media: autoselect
	status: active
  • DHCP
    • 約1,000個確保
    • 500〜600個程度リースされている実績を確認している
  • 機材
    • 事前に別の場所で設定、稼働テストを実施。 (これはLTで聞いた)
    • 機材の死活は Dead Man で監視。
      • Interopでも使われていたもの。確かにShowNetで同じものを見たな。
      • Pingのみでシンプルだがいいソフトっぽい。
    • YAMAHAさんから提供を受けている
    • Wi-Fi AP
      • YAMAHA WLX302 がメイン。
      • 予備はIIJのWi-Fi APがいくつか。
      • 大ホールは5台。
      • メディアホールは 2台。
      • 各会議室は1台。
      • 急遽、懇親会会場や1階のテラスに増設。
    • スイッチ
      • 動画送信だけ、品質が落ちないようQoSで優先して使えるようにした。
      • スイッチをリピーターとしても使っている。
      • 急遽AP追加もある程度見据えて設置。
      • 看板の裏等に隠してあまり目立たないようにしている。セキュリティ、及び景観を考慮。
  • ケーブリング
    • 3時間で構築 ただし事前の設計は綿密だったようだ。
    • 機材は看板の裏に隠して置いている。
    • 3階から4階は階段経由。隙間をうまく使ってケーブルをショートカットさせている。
    • メディアホールは3階から直接接続しづらかったため、調整室の窓から出している。なので3→4→3階と経由している。
    • 断線を考慮して、その可能性がある部分は部分的に取り替えられるようにメス・メスのコネクタでケーブルを分離。
      IMG_2357
    • その他の配線の様子はこちら。足の踏み場や防火扉をうまくかわして配線されています。
      IMG_2359
      IMG_2356

Python Quest in Taiwan

  • Keith Yangさん
  • 感想
    • 台湾、ソフトウェア開発教育に積極的だ。
    • 教材にPythonが使われているケースが増えているような気がしている。
    • ローカライズしてまで使ってもらおうとする組織力、すごい。日本ももっと大きな集団でやれたらいいなと思っている(実際ちょっとやってる)。
  • 変化・チャンス・そして挑戦
    • 教え、学び、書き、そして教育する
    • Pythonは学びやすい(と思う)
    • イギリス: Code Club
      • 放課後教育で9〜11歳に教えている
      • BBCがソフトウェア開発教育に関する番組をはじめているらしい
      • (前にLondonで聞いた話と同じだった)
    • CheckIO
      • 体験の共有?交換?
    • PyCon Taiwan (2014)
      • CheckIOを中国語で
      • 地元での挑戦
      • 英語から中国語に訳さないと
      • カスタマイズしたゲーム
      • 旧来の教科時間とぶつかってしまう
        • あー、とりくめなくね?これだと。
    • geekpy.org
      • 優秀者にはpycon taiwan 2014に参加できる
      • 楽しさを拡散させて行く
      • モティベーションを持つのが大変
  • PyCon Taiwan 2014
    • 100枚の学生チケットが売り切れた
  • 教え学ぶ勉強会
    • Taipei Python Workshop
      • 朝: setup games
      • 昼: チームプレー
        • Web, GUI, Mobile, Data
      • 良い結果を得られた
  • その他のイベント
    • PyLadies Taiwan
    • Django Girls Taiwan
    • Raspberry Pi Workshop
LINEで送る
Pocket

PyCon JP 2014 Day 2 感想とノート #pyconjp

LINEで送る
Pocket

2014/09/12(金)から始まっている、PyCon JP 2014に来ています。今は3日目の朝に行われる西尾さんの基調講演を待っている所です。楽しみです!実はPyConは初めてなのですが、YAPC::Asiaとまた違った趣があって楽しいところです。

それでは、今回もノートをアップしておきます。こちらは2014/09/13(土)に行われた2日目、カンファレンスとしては1日目のノートです。

オープニング

  • 感想
    • しょっぱなから英語
    • 海外から人を招聘しているんだ感が高かった

Keynote

  • Kenneth Reitzさん
    • Heroku
    • PSFの中の人
  • 感想
    • 安定と変化のバランスの難しさを再認識させられる話だった。
    • Python開発の中心にいる人たちは早めにPython 3に移行してもらいたいいのだろう。
    • 言語を選ぶより、言語の中のコミュニティを選ぶ方が、開発の時に幸せになれそうな気がしている。
    • Self
    • Time
    • Other
    • Space
  • そもそもLanguaeだよね
    • Pythonの前に集っている
    • 自然言語のように今日は扱ってみる
  • 言葉の歴史
    • 言葉を通じて考えている事を人に伝えている
    • 時間とともに考えを保存して伝承できる
    • とっても素晴らしい事だよね!
    • 人というハードは変わっていないけど、スキルを通じてソフトウェアをアップデートしている。
  • 1-to?1
    • 実際ではもっと多くの人とコミュニケーションしている
    • エジプトの石盤
  • 1-to-many
    • 印刷機の発明
    • ひとりが何千の人とコミュニケーションできる、これは革命。
    • 新聞、本、テレビ、ラジオ、等。
  • many-to-many
    • the Internet !
    • 全ての世界から情報にアクセスできる。
    • 大規模だ(huge)
  • 空間(space)
    • 知らない間に、たくさんの人とコラボレーションできる空間。
  • 軸をまたぐもの
    • 様々なツールがある
    • テクノロジーがあるように言語がある
  • Pythonの未来に恐れを抱いている、怯えている。
    • これは世界の将来が危ぶまれている。
    • 2と3の分断された世界
    • (挙手の状況が2の方が比較的多かった)
    • 3はみんな怖がっている、話者も使ってない。
    • Flask開発者によるとUnicodde ,Codex, and Friendsの物事をどれだけ破壊したか長い話があった
    • Standard Libraryが壊れていて辛い(僕自身も辛い)
    • こりゃ残念な事だ
    • 改善は毎日進んでるけどね
  • なぜ?
    • Python 3のユーザが少ないから
    • (挙手の状況を見てもわかるよね!)
    • PyPi, pipに変更が加わった→利用しているPythonのバージョンによって切り替える仕組みができた
    • 2週間で、2は81百万、3百万ダウンロード。偏りがあるのがわかるよね?これが現実。
    • (動かない→使わない→改善されない、悪循環っぽい。)
      -
  • Python 3
    • 新しい人が、Python 3を選び始めている。
    • 初めてだから、選択する事ができる。
    • 既存の確立されたコミュニティとは違う。
    • 開発者、Pythonのコミュニティの間にも断絶がある。
    • 製品を開発する時のマーケットの問題。
    • 2と3で2倍のメンテコスト。辛い。
    • 分裂が促進されている。
  • これは貴方の問題です
    • 同時にあなた方がソリューション。
    • 2つのものが1つになる。
    • 知識と愛。
    • 直接体験して自分で決めてほしい。
    • Python 3を使って、何かあればブログを書こうぜ。体験を共有しよう。
    • Python 3の食わず嫌いはやめよう。
    • 静かに、何かを待っているのは良くない。
  • 質疑
    • Q: Perl5/6の問題とにてるけど、あっちはPerl6は別のものとして分かれた。Pythonは分かれずに収束していこうとしているけど、どうして?
    • A: 変換はできるパワフルなツールはあるけど、それだけでは間に合わない。だから、多くの人がどちらにも対応できるコードを書くようになってきた。でも、それって良くない。Python 3の利点が活かせない。
    • 同時にみんながPython 2をやめて3に移行するならいいけど、そんなわけにはいかない。
    • PSFでは2.8はないと決めている。ただ、もっといいソリューションがあればいい。
    • ご自身の意見をみんな持ってほしい。
    • Q: 同時にどっちもサポートするのは辛いのは知ってると思う。で、Python 3で書くメリットとは?
    • A: ない…な(ここで一同爆笑)。でも、いろいろいいものは入ってるよね。他の言語でできる新しい事もできる。エキサイティングだ、でも、同時に…ここで2をきっぱりやめる事もむずい。
    • Q: 自然言語処理をやってるんだけれど、C, C++のような標準化は行われるの?Pythonの標準化活動ってあるの?長期的なPJでは、そうあったほうがいい。
    • A: Python 2.7は今後10年変わらない(多分RedHatがサポートする事は踏まえられているんだと思う)から、それを選ぶのはどう?2系がいいと思うよ。
    • Q: 2つ目の質問に近いんだが、Python 3を使おうと言いながら2を使っている。クリアなコミュニケーションが行われていない、3の方向性もよくわからん。悲観主義的な話を唱えているのではなくて、クリアなビジョンも難しいと思う。ダウンロード数を見りゃわかるでしょう。
    • A: コア開発者と話をすると、10年かかるかもしれないが対した事はないさ、と話題になっている。参加して、発言して行くことが必要。コア開発者は数値をあまり気にしていない。言語の改善を考えている。その対立が分断を引き起こしている。私が理想的な状況とは、みんなが2.7を使い、3は忘れるってのがいいと思う。ただ、公式な意見は確立されて行く必要はあるよね。
    • 私は3を嫌いになってもいいと思う。
    • Q: 2と3で違う見方なのだが、1年前に3が選択肢となる話が出始めて、ここ最近互換性が問題になってきた。Ubuntu, Debianが3がデフォルトになって増えたっぽい。2から3に必要なものをポーティングすりゃいい気がするけど。
    • A: それでいいと思う。
    • Q: RubyとPythonの比較
    • A: Rubyの場合は1.8→1.9の変化は急だった。RubyとPythonはだいぶ違っていて、Pythonはこれまでstableで後方互換を保つようにしていて、安定していた。この歴史が、科学的な背景があった。Rubyの変化はとても早い、ポイントリリースも違う、パッチりリースでも違う、でもそう言うのに慣れているから大きな変化にも慣れている。それがRubyの文化。でも、Pythonではそんな変化にあまり対応できない。Rubyは変化を楽しんでいるのはいいし、Python 2,3でもそれができればいいなと思う。僕らも慣れて行く事も必要だと考えている。

Programming the Performance Co-Pilot toolkit

  • Nathan Scottさん
    • RedHatのなかのひと
  • 感想
    • PCP知らなくて不勉強だったことを反省する。
    • Pythonで拡張できるのはなかなか良い。
    • そしてリモートホストからのデータも取得できる点も非常にいい。
    • 検証時のメトリクス取得にもってこいと思われる。
  • 今日のお話
  • PCPとは
    • オープンソースの ツール集
    • システムアナリシス
    • ライブで履歴をとれる
    • 拡張性が高い
    • 分散できる
  • アーキテクチャ
    • pmlogger
      • 各種ミドルウェア、カーネルから拾ってくる。
    • pmchart
      • ビジュアライズ
    • pmie
      • インタフェース、こねくり回す時にはこいつを使う。
  • メトリック
    • pminfo コマンド
      • データ拾う時に使う
      • Sensuメトリックを拾う時の名前ににてるっぽいな
    • Collector extentions in Python
      • 目標: new dmcache metrics
      • dmcacheの推移がわかってキャッシュあたりの追跡をするのによさそう
      • かなり密な単位でとれるっぽいな 1秒単位がある
    • git clone git.pcp.io/pcp からどうぞ。
    • プログラミングガイドブックもあります
    • pmchartはJavaっぽい
  • 質問した
    • Q: リモートシステムからデータは取れるの?
    • A: できます。Ciscoのルーターとかのデータを、TCP/IP経由でとれます。
    • 英語の質問緊張した

Gunicorn, the thundering herd and other concurrency programming challenges

  • Benoit Chesneauさん
    • gunicorn開発者
  • 感想
    • gunicorn開発者本人から話が聞ける事が貴重。
    • 英語で後で話に行けないの、いろいろ損している気がしている。
  • gunicorn = じゅにこーん
  • デザイン
    • prefork-workerモデル
    • ソケット共有 (spawn-share sockets)
  • ソケット共有
    • arbiterがworkerにspawnする、よくある話。Unicornと変わらん。
    • copmetiton to accept (競合管理)
      • バックログに溜め込む
      • 同期ワーカーは1接続まで
      • 非同期ワーカーはいくつものコネクションを支えられる
    • ワークフロー
  • なんでいろいろなワーカーが?
    • 同時接続の戦略
    • 違うプラットフォームのサポート
    • WSGI以外にハンドルしてほしい
    • いろいろ
  • The thundering herd problem
    • 重たい処理が引っかかると全ての処理が引っかかってしまう
    • 対策
      • 792 参照
      • パイプを通じてシグナルをやり取り Workerプロセスの状態を聞いてまわっている模様
      • arbiterがソケットの読み込みが可能かチェック
  • One command to rule them all
    • gunicorn_ほげほげ とか書かなくていいよ!
    • プリロード問題は直しました
    • ?paste, ?pythonpath, ?env をサポートしました
    • 20個の引数です (非推奨は勘定していない)
  • Enhance the user experience
    • 837 参照
    • plugin everywhere: logging, workers
    • more embeddable: the gunicorn engine
    • https://github.com/gunicorn/ に移ります
    • 2014/12までにやります!!!

Data collection, analysis and optimization with python

  • Shinji Iwakiさん
    • @shinji071
    • 構造計画エンジニアリング
    • Python歴 1.5年
  • 感想
    • iPythonのデモンストレーションとして見ていても非常に興味深かった。
    • Pythonが書けるなら、無理にRでデータ分析に取り組まずとも、データ分析に取り組める事がわかった。
  • 膨大なデータの計算どうすっぺ
    • まず、全体の構造及びライブラリ構成を紹介。
    • 最適化
  • データ収集
    • HTMLをかき集める
    • BeautifulSoup4で解析(スクレイピング)
      • 時間・タイトル・出演者をとる (価格.comのテレビ番組欄)
      • 出演者の出演頻度を出してみる
  • データ分析
    • pandas
    • skleam
    • そしてビジュアライズwww
    • k-means法による出演者のクラスタリング
  • 最適化
    • pulp
      • LP modeler
      • 線形計画法を解くライブラリ いろいろあるんですなー
      • ナップサック問題を解くとか
  • 質問
    • Q: GAのライブラリって?
    • A: scipyとか、でもあんまつかってないな。

Effective numerical computation in Numpy and Scipy

  • Kimikazu Katoさん
    • Egg technology に勤務
    • CSのPh.D
    • Python暦 2年未満
    • 科学計算歴は10年以上っぽい
  • 感想
    • 行列圧縮を自力で実装していた事があるが、もうそんな事をしなくて良いのは助かる。
    • 自然言語処理の研究を手伝っている時に、これがあればどれだけ楽だったかと想いを馳せた。
    • 講演中、もっと抑揚がある話し方があると注意を引きやすくて良かったのではないか。
    • 1つ後のセッションと入れ替えた方が、より理解が深まったのではと考えた。
  • 流れ
    • NumMyについて
      • 展開
      • インデクシング
    • スパース行列
    • ケーススタディ
  • 数値計算をなぜPythonで?
    • プロダクティビティの高さ: 書きやすい・デバッグあすい
    • ビジュアライズしやすい
    • Webシステムとつなぎ込みやすい
  • だけど、Pythonは遅い!
    • CとPythonでは80倍違う計算があった
    • だけど、numpyを使うと…Cに近いくらい速度が出た!
    • まあ、PythonからCに書き換えるってのは大変だしな、こう言うのがあるならいいね。
  • パフォーマンスの肝
    • forなどのループを減らす
    • 良いライブラリがあれば使おうぜ
    • メモリコピーのコストとか、忘れてません?(確かにヤバい)
  • スパース行列
    • 行列の圧縮のメリット→メモリ空間の削減、計算量の削減。
    • 3つのメソッド→[lil,scr,csc]_matrix
    • ある計算において 1000×1000 のsparse matrix でlil は11.7 sec, cse 0.06 sec
    • ただ、性質を熟知している場合は、自力で書いた方が早い 場合 もある。

Introduction to scientific programming in python

  • Olivier Hervieuさん
  • 感想
    • 科学計算ライブラリのサーベイ発表だった。
    • matplotlibがあればRを使わなくてもビジュアライズできるなと改めて理解した。
    • 今の本業で使う事はないが、以前は必要だったし、今後また必要になるかもしれないので、改めて動向は見ておこうと思った。
  • もうあんたらは科学計算プログラマだよ!こんなにセッションあるしw
  • 今日の話
    • 科学計算プログラマ必携のライブラリ・ツールを紹介するよ!
    • 製品化のための注意点を話すよ
  • iPython
    • Must Use だってさ〜
    • インタラクティブシェル
    • ブラウザベースで実行可能 いろいろサポートしてる
    • 簡単に使えて並列計算機でも高いパフォーマンスが出せる
    • Data collection, analysis and optimization with pythonでも使ってた
    • コメントはHTML, LaTeX, Markdown等等に保存できる
    • notebookのエクスポートも簡単
  • NumPy
    • (Effective numerical computation in Numpy and Scipyでも紹介されたもの)
    • 多次元オブジェクトをこねくり回せる
      • 行列計算のアルゴリズムを実装する手間が省けていいですね
    • フロントエンドはnotebookという
    • 線形アルゴリズムに最適化
    • ただしメモリを食う
    • Julia benchmarkの結果なんて信じちゃダメだ!!!(本当かはわからん)
      • numpy使っているか否かは言及してなかった
  • SciPy
    • 科学計算ライブラリ (名前の通りですね)
  • matplotlib
    • 2D, 3Dのハイクオリティプロッター
    • MATLABっぽくいける
      • 実際でもを見ると本当にそれっぽい
    • Introduction to Numpy and Matplotlib ってビデオを見るといいよ!4時間あるけど。
  • scikits
    • 機械学習
  • pandas
    • データ操作ライブラリ グルーピング、マージ、そしてインデクシング。
  • 注意点
    • numpy, scipy, scikit-lean をつなげて行くと、 Fortranレベルでいけるっぽい。
    • 再コンパイルは長い。(辛い)
    • パフォーマンス重視: numba, cython
    • DSL: sympy, nltk
    • bindings: rpy2
    • storage: pytables
    • 無料で利用できる
      • なんかあったら直そう、直します。

リファクタリングツールあれこれ

  • @tell-k さん
  • 感想
    • コーディング基準を守るんでなくて、コーディング基準に沿ったコードを自動的に生成する時代となった。
    • そして僕の前に狂戦士がやってきて殺される。
    • 心を入れ替えて.vimrcをアップデートします。
    • ごめんなさいごめんなさい。
    • 一方で、コードの見通しやコメントの良さはこれらではカバーできない事でもあるので、引き続き広い視野を持ってコードを書くのを忘れないようにしたい。
  • リファクタリングそのものの話はしない!
  • リファクタリング ツール の話をします。
    • vim中心に説明します!
  • pep8, pep257
    • 文法チェック
  • pyflakes
    • 文法エラー
  • flake8
    • pep8, pyflakes
    • pep257対応のために flake8-docstring を突っ込む
  • gofmtの代わり
    • autopep8
    • autoflake
  • 支援/リファクタリング
    • jedi
  • 特にリファクタリング
    • Rope
      • IDEに見劣りしない編集ができるようになる
  • Code Climate
    • 自動でレビューしてくれるサービス
    • ただRuby, PHPのみで、Pythonは使えない。
  • Radon
    • 2つの指標で評価
      • Cyclomatic Complexity: 循環的複雑度 6段階で評価
      • Maintainability Index: 保守容易性

Python を支える技術: ディスクリプタ編

  • Nozomu Kanekoさん
    • @knzm2011
    • 公式ドキュメント 翻訳担当者
  • 感想
    • いろいろはまった時に、この事を思い出すとコーディングでつまづかないのではと考えた。
    • ただ、自分自身で改めて人に説明できるほど深く理解できたとは思っていない。
  • はい
    • シリーズ物ってことではありません。
    • ドキュメント、ソースを読めば一通り書いてある。
    • Python 構文解説にディスクリプタの事が書いてあるwww かぶった。
    • 公式ドキュメント 翻訳担当者 大募集中!
  • 分類
    • データディスクリプタ
    • 非データディスクリプタ
    • 読み取り専用のデータディスクリプタ
  • 分類は属性アクセスの優先順位に影響してくる
  • プロパティはディスクリプタの一種
  • インスタンスメソッドの読み出しは、ディスクリプタによって単なる関数呼び出しに変換される。だから、第1引数にselfがある。
LINEで送る
Pocket

広げる話・収束させる話を使い分けて会話を楽しみたい!

LINEで送る
Pocket

人間、生きていると誰かと話をするものです。そんな中で日々思った事をまとめます。

今回は、広げる話と収束させる話、場に応じて切り替えると良いと思うし、特に仕事でもない時は収束させる話に持って行って結論を急がなくてもいいんでないの?というお話です。

広げる話と収束させる話

話を始める前に、この記事の中で使う言葉の定義をします。

まず「広げる話」とは、会話の場に登場した話題を発散させる方向の会話の進め方とします。例えば、アフタヌーンティを楽しみながらあーだよね、こうだよねと話を会話を通じて時間を過ごす事を楽しむ状況を想像して下さい。また、会話に参加している人同士で人となりを知り、そして快楽を得る事ができます。

続いて「収束させる話」とは、会話の場に登場した話題を収束させる方向の会話の進め方とします。例えば、仕事中に催される会議において、決まった時間の中で結論を導き結果を出す状況を想像して下さい。また、会話に参加している人同士で問題解決を行い、各自の使命をより明確にする事ができます。

仕事じゃないのに話を収束させてしまうのはつまらない

IMG_6084

ふとした会話なのに、話を収束させられてしまう事があります。言い換えれば「確かにあんたが言う事は正しいよ、でもその話がしたいんじゃないんだ僕は!」って状況です。これは、直接の会話ばかりでなく、 Facebook などのテキストベースの会話でも起きています。

「〇〇だから××、故に△△。」全くその通り。わかる。でも、それ以上続かなくないですかね。また、否定しちゃうともそこで終了です。例えば、「ベトナムはいい所だ、飯もうまいし旅費も安くてさ〜」と切り出したときに、「いや、私はいやだった。航空会社は〇〇航空に比べてサービスが悪く、現地は感染症も日本に比べて多い。」としたらどうでしょうか。もちろん論理的に反論する事はできると思います。しかし、ここではどちらかに結論を収束させるのが目的ではないので、僕がこの話題を切り出したならその会話は打ち切り、別の話題を出します。

僕が求めているのは、「ベトナムはいい所だ、飯もうまいし旅費も安くてさ〜」と切り出されたときに、「おお、フォーってのがあるらしいけど、あれはうまいのか?」や「そりゃいい、俺も行きたい!」と、話が広がるよう更に盛り上がるように掘り下げることです。さらに、近い経験をしたなら「実は俺も行った事があって、××ってのがよかったぜい。」とより話を豊かにしたり、論理的に「ベトナムは日本よりコーヒーが△割安くて良かったよ!」と話しつつ相手がより理解しやすい形になっていたら、更に楽しいなと思うのです。

その中で、会話の相手がどのような体験をして、価値観を持って生きている事を知り、そして楽しい時間を過ごせたら最高だなと考えています。

ちなみに僕の中で例外がありまして、その一つが思考実験です。例えば「情報教育において指導する先生が不足しているが、それを解決するにはどんな手だてがあるか?」という話題が当てはまります。これは、論理的に展開しつつ結論に向かって会話する事を楽しみにやります。とはいえ、人となりを知り、快楽を得る点は変わりません。

仕事なのにだらだら会議も良くない

逆に、仕事中にダラダラ会議をしてしまう人がいます。これは、話を収束させるために論理的に物事を整理する事が足りていないのが一因ではと考えています。

時々、論理は相手を攻撃するための道具だと誤解されている事があるようです。僕は、論理は会話する相手に対して再現性を持って伝えるために必要だと考えていて、攻撃に使うものではありません。また、人は一人一人違う事を考えていますから、自分が何を考えていてどうしたいと伝えるためには、感情だけでは理解されるものでもありません。

会議はコミュニケーションを楽しむ場ではなくて、集団で物事を推進するにあたって意識をあわせて次の段階に進むために必要な工程だと、僕は理解しています。その中で、漫然と話を広げて会話をするのはあまり賛成できません。とっととコード書くなり、企画を熟成させるほうに力を注ぐほうが生産的です。

尚、効率の良い会議の手法自体は様々な所で語られており、ここでは述べません。

やばかった自分の20代

実は、平時の会話を収束させてしまう状況は、20代の自分によくありました。どうしてかなと、今振り返りますと次の点があったのだなと思います。

  1. コンプレックスが強かった
  2. 会話には勝敗があると思っていた
  3. 日々を楽しむ視点がかけていた

1は、その頃は高卒でして、大卒相手に仕事をする際に絶対に負けたくない!という気持ちが強すぎたのでしょう。だから、会話中に負けないように「私はあなたよりも〇〇を良く知っている(という趣旨の話)」や「いやそれは違う」などと言ってしまいがちでした。ちなみに、大学院を出たときに、これはなくなりました。

2は、1にも続いてやってしまっていました。だから、相手が腹立ったからこいつの鼻っ柱をへし折ってやろう!となったときに、逆に悔しい思いをして会話を終えてしまった事もありました。

3は、仕事ばかりの事を考え、そして休み無く仕事をしていたせいか、一緒にいる人と楽しく時間を過ごそうという視点に欠けていました。これでは、少しでも僕の事を面白い人だな!と感じてもらえたとしても、その後にテンションをダダ下がりにさせてしまっていたかもしれません。

あと、こうしていると、なぜか疲れてしまうんです。気を張っているし、楽しんでいないからなのでしょう。勝ち負けだけで物事を捉えてしまうと、辛いだけですね。

そんなこんなで、仕事こそちゃんとやっていたつもりですが、私生活ではあんまよい感じじゃなかったなー、と33歳になって振り返っております。まだ、残ってたら指摘してやって下さい。

平時は会話を楽しもうぜ

IMG_9683

では自分が広げる話と収束させる話を意図して切り替えるようになったのは、昨日今日ではありません。よく行くバーで飲みながら他のお客さんと話したり、普段とは違う領域・組織の人と付き合う中で、徐々に醸造されたものです。

そうしていると、特に私生活では自然と疲れづらくなった気がします。というのも、悪い人じゃないんだけれど無理に付き合う事も無いかなー的な人と、話してて楽しいし自分が気持ちよく付き合える人が自然と見えてきて、やりやすくなりました。

あと、僕の場合だけかもしれませんが、気持ちよく付き合える人と仕事をすると、不思議とうまく結果が出せるように感じます。単に恵まれているだけかもしれませんが、その率が上がっているのは僕にとってとても有益です。そして、相手にとっても有益であって欲しいと願います。

なお、改めて申し上げますが、どの場面においても論理的思考・説明を否定するものではありません。広げる話の場合と、収束させる場合で、使い方を変えるといいんでないの?と言いたいのです。

ということで、広げる話と収束させる話を使い分けて、特に仕事以外の平時では広げる話を通じて交流を深めるのが楽しくてよくね?というお話でした。

LINEで送る
Pocket