satococoa's blog

Web や iOS アプリを作るエンジニアの日記です

やさしい AJAX on Rails という資料を作りました

最近 SPA (Single Page Application) についての議論が盛んで、Angular とか React とか Flux とか Mithril とかの名前をよく聞くようになりました。

でも必ずしも全ての Web アプリにおいて SPA は必須ではありません。

むしろ枯れた jQueryRailsremote: true の仕組みを正しく使うだけで十分なケースも多数あると思います。 (特に iOS, Android のネイティブ開発者が身近にいる環境では SPA で開発するのとネイティブで実装するのとでは後者の方がコストが低いこともありますし。)

ということで、「じゃあ RailsAjax ってどうやって実装するんだっけか?」というところをまとめた資料を公開します。 中級者以上の方にとっては特に目新しい情報は無いと思いますが、経験の浅い方の自己学習や研修などでよろしければお役立ていただけると幸いです。

サンプルコードはここ: https://github.com/satococoa/easy-js-on-rails

WWDC 2015に参加しています

運良くWWDC 2015のチケットを手に入れることができたのでサンフランシスコまで来ています。

f:id:satococoa:20150609074435j:plain

Keynote

WWDCと言えばKeynoteですね。10:00開始なのですが会場には前日の夕方くらいからもう並び始めている人がいました。 僕は時差ボケのせいで眠気がひどかったのでのんびり7:30くらいに会場着でした。あまり遅くなるとメインの会場には入れずに別室でストリーミングを見ることになるという話も聞いていたのでちょっと覚悟していたのですが、幸いちゃんとステージが見られる席に座ることができました。

f:id:satococoa:20150608093657j:plain

予想通りApple Watchでネイティブのアプリがちゃんと開発できるようになりましたね。watchのセンサーとかTapTicエンジンとかを使えるので本来Apple Watchで作りたいと思っていたアイディアがいろいろ実現できそうです。

また従来はiPhone側で処理を実行していたためにiPhoneとの間で通信が走らざるを得ない仕組みになっていて、正直Apple WatchのAppを積極的に利用することはほとんどありませんでした。

実際「Apple Watchどうですか?」みたいに人に聞かれたときは大抵「時計として便利です。あと通知とグランスは結構使います。」みたいに答えていました。watchOS 2からはアプリも活用できるようになるかもしれません。

iOSOSXに関してはそんなに驚きはなかったものの、Swift 2.0とオープンソース化の発表でだいぶ沸きましたね。 ところでApple Musicはなんであんなに長くしゃべってたのでしょうね。開発者に見せてもどうしようもない内容だとは思うのですが。。

セッション

大体の内容はKeynoteの直後にあるPlatforms State of the Unionでカバーされているんですね。もうWebにもアップされているのでざっと今回のWWDCの全体像をつかみたい人はそこから眺めるといいかもしれません。 https://developer.apple.com/videos/wwdc/2015/?id=102

もうすでにかなりの数のセッションの動画がUPされているようで、単純に発表内容を追いたいだけの場合は現地に来なくても十分情報が得られるんですね。

主にセッションはwatchOS関連、開発ツール関連(XcodeとかStoryboard絡みとか)、iOSの新機能の順番の優先順位で受講しています。 特にStoryboard関連がかなり進化している印象で、Storyboard ReferenceとかStack Viewなんかは今すぐ使いたいですね。

生活面

英会話が得意じゃないので正直、結構苦労しています。セッションはスライドもあるし、単語は大抵わかるものばかりだから大体理解できるのですが、突然誰かに話しかけられたりお店やレストランで注文したりっていうところでまごついてしまいます。。 これは本格的に日本に帰ったら英会話を鍛える方法を考えないといけないなぁと思いました。

宿泊先はありがたいことに同僚の家に泊めてもらっているためかなり費用が浮いています。会場からBART+徒歩で1時間程度のところなので、ちょっとした通勤気分も味わえて、「アメリカで暮らすのってこういう感じなんだなぁ」という体験ができています。

治安面が悪いから気をつけるようにとあちこちで言われていたのでかなりびびっていたのですが、実際こちらに来てみると親切で丁寧な人が多い印象を受けています。今の所怖い目には合っていないのでこのまま無事に帰国できるようにしたいです。

大体ぼっち行動なのでご飯なんかは気の向くままに適当にフラフラ行っているのですが、同僚に教えてもらったTu Lanが今のところ一番美味しかったです。

f:id:satococoa:20150609121215j:plain

治安が悪いと言われているテンダーロインの近くなのでちょっと怖いですが、もう一回くらい食べに行きたい感じ。

Growing Rails Applications in Practiceを読んだ

pragprog.com

読み終わったのはもう先月ですが、学ぶことが多い本だったので紹介しときます。 @1syoさんと@miyohideさんとやってる読書会の前回の課題図書でした。

どんな本?

まずは目次を見てみると良いと思います。 心に残った章だけちょっと抜粋すると、以下のような内容が書いてあります。

  • Beautiful controllers: コントローラのAPIを共通化して、コードを減らす方法
  • User interactions without a database: Formオブジェクトとか作って、コントローラからコードを減らそう
  • Dealing with fat models: fat model を回避するには / FormオブジェクトととかServiceオブジェクトはこんな風に作るといいよ
  • Taming stylesheets: BEMを "実践的に" 取り入れて、CSSも設計しよう
  • Building applications to last: 長くメンテするつもりのアプリはこんなこと気をつけて

誰のための本?

上述の箇条書きですが、ある程度以上の規模のアプリケーションをrailsで作ってるとみんな直面する問題ばかりだと思います。 これらの問題に関心がある方は是非一読していただきたいと思います。

BEMの項については以前紹介した(Web制作者のためのCSS設計の教科書を読んだ - satococoa's blogWeb制作者のためのCSS設計の教科書 モダンWeb開発に欠かせない「修正しやすいCSS」の設計手法 を読んでおくとさらに理解が深まって良いと思います。"Web制作者のためのCSS設計の教科書"の方でBEM(やそれ以外のフレームワーク)の考え方を理解し、実践的な使い方を"Growing Rails Applications in Practice"で知る感じです。

うちの会社でも読書会をやろうかなぁと検討しています。

Reactとかgulpとかfirebaseとか色々いじってみた

色々一気にやりすぎてちょっとパンク気味ですが、以下のリポジトリにおいて最近興味があったものを色々試してみました。 iOSAPIサーバの仕事ばかりやっている間に大きく遅れてしまったWebのフロントエンド技術にキャッチアップしたいというのが狙いです。

satococoa/react-firebase-chat · GitHub

今できているものは単純なチャットアプリみたいなものです。ページングとかは手を抜いています。

試してみたこと一覧

Reactは最近流行りのJSのライブラリですね。最近仕事でVue.jsを導入してみてとても良い感触を得ているのですが、それと比べてどうなんだろう?という比較もしたいと思い。

FirebaseはいわゆるMBaaSの一つで、だいたいParseと同等の機能があるようですね。FirebaseがGoogleに買収されたことから興味を持ったのでした。

Web Starter KitはGoogleが公開しているWebのベストプラクティス集であるWeb Fundamentalsを元にした静的Webサイトのテンプレート(boilerplate)ですね。HTMLのテンプレート+UIコンポーネント+gulpタスクって感じです。

BourbonはSASSのフレームワークです。仕事ではCompassとかBootstrapとかを使っているのですが、他のものも一応知っておきたいなと思い。

感想

React良さそう

コードはほとんど Tutorial | React にあるものを真似てサーバとのやりとり部分をFirebaseのAPIに置き換えただけのものなのですが、それだけでもReactいいなぁという感触を得ました。特に以下のあたりが好みです。

  • stateとpropという概念で、Model (ViewModel?) が持つ状態と属性がはっきり分かれている
  • コンポーネントという単位への分割と再利用がわかりやすい
  • ドキュメントが豊富

唯一気持ち悪いと思うのが、JSのrenderメソッド内にべたっとHTMLを書いちゃうところですが、コンポーネントを構成するロジックとviewとが一箇所でカプセル化されていると考えればまぁ、アリなのかもしれません。

JSXのコンパイルとか既存ライブラリとの共存とかが難しそうなので、ガッツリJSでガリガリ動くアプリを書くときはReact、そうではなくて便利なViewModelが欲しいだけならVue.jsといった使い分けが個人的にはしっくりきています。

Firebase良さそう

特にはまりどころもなくすんなり使うことができました。提供されている機能はほぼParseと同等ですが、料金体系が結構違うのでアプリの性質によって使い分けるのが良さそうです。Parseはリクエスト数による課金、Firebaseは同時接続数による課金というざっくりしたイメージです。

今回作ったサンプルプロジェクトはfirebaseのhosting機能を使ってデプロイしています。静的ファイルを置くだけだからかもしれませんが、全くハマることなくすんなりデプロイできました。

Bourbon良さそう

Compass と比べても遜色ないと思います。ドキュメントもわかりやすく、機能的にもFlexboxとかAnimation、Modular Scaleなんかもサポートしているので十分使えそうです。

また、Bourbonベースで作れらたneatというグリッドフレームワークbittersというスタイル集もbootstrapほど何でも揃っている感じではありませんが、自前でスタイルをある程度頑張るつもりであれば足がかりとして使えそうな印象を持ちました。

gulpつらい

Web Starter Kit には最初からgulpのタスクが付いています。そのまま使うのなら良いのですがデフォルトで既に秘伝のタレ化していて、理解するのが若干辛かったです。具体的にはJSXをコンパイルするタスクを挟み込むのに結構苦労してしまいました。 middlemanとかを使ってrubyのasset pipelineに逃げたくなりました。 調べれば調べるほど、webpackだとかbrowserifyとかいろんなツールが出てきて大混乱でした。実際、今回のサンプルプロジェクトを作るにあたってFirebaseやReactでは全くハマらず、gulpで無駄に時間を費やしてヤクの毛刈りしている気分でした。

個人的には npm run を使う方法の方が gulp のお作法を覚えるよりもシンプルで unix 的だなーと今のところは感じています。 参考: npm で依存もタスクも一元化する - Qiita

モバイルデザインパターン 第2版を読んだ

アプリ開発者として UI デザインについてもより理解を深めたいと思い、モバイルデザインパターン第2版を読みました。 職業柄普通の人よりはたくさんのアプリを試しているつもりではありますが、iOS 以外のプラットフォームだったり、英語圏のアプリだったりはあまり試せているわけではないので、もう少し包括的にトレンドを知っておきたいなーくらいの気持ちで。

どんな本?

モバイルアプリ (ネイティブアプリが前提) の UI について実際のアプリのスクリーンショットを見ながら様々な実装パターンを紹介している本です。 読み物というよりは UI カタログみたいな感じだと思って購入すると丁度良いと思います。 ありがちなアンチパターンも掲載されていて、耳が痛いというか「あちゃー。。。」って何回も思いながら読み進めました(笑) ネビゲーション、フォーム、テーブル... といったようにカテゴリ分けして掲載されているので、UI 設計をしながら必要な項目だけつまみ食いして読むのも良いと思います。

また、OS は iOSAndroidWindows Phone をカバーしています。

それぞれの UI 設計についての原則 (iOSiOSヒューマンインターフェイスガイドライン とか AndroidMaterial design とか) の詳細は各公式ドキュメントを参照して知識を補った方がいいと思いますが、ちゃんとそれらを踏まえた上での解説になっているのでためになります。

誰にオススメ

デザイナだけじゃなく、ネイティブアプリを作っている人なら職種問わず手元に置いておきたい本だと思います。 UI について設計するときの共通理解を深め共通言語を増やす目的では、チームで頻繁に参照できるようにしておくと効率が良いかと思います。 僕の勤める イグニス でも会社の本として購入してもらいました。

デザイナ・プロデューサ視点では「技術的にどんなことが可能なのか」を知るいい資料となりますし、エンジニア視点では UI に関する提案力を手っ取り早く上げることができると思います。

しかし、贅沢を言えばこれは電子版で欲しいところです。。。

じっくり味わう本を読むには読書会が有効だと思う

タイトルで言いたいことは言い尽くしたので、そう思う理由を挙げたいと思います。

その本、読んだはいいけど理解できてる?

電子書籍のおかげで、物理的なスペースを気にすることなくつい気になる本を買っては積んでを繰り返してしまいます。 そうすると積ん読を消化するだけで消耗しがちです。

最近本を読むことをおすすめするエントリを書きましたが、やっぱりただ大量に本を 消費する だけでは効果は薄いと思います。 読んだ内容を自分の言葉、もしくはコードで表現できるようになって、初めて 理解した と言えるのです。 (本の種類によってはざっと斜め読みして、後で詳しく知りたくなったときのために頭の中にインデックスを構築すれば十分なものもありますが。。)

理解するためのひとつの方法として、本の中身について語り合うことが有効だと思っています。 その相手は同じ知識レベル、もしくは自分より上のレベルの人と話すことが好ましいです。 その機会として読書会を開く・参加することは非常に有意義だと最近特に感じているのでポエム書きます。

読書会って何?

まず僕が参加している読書会について、どんな感じにやっているのかをお話しします。 読書会に参加したことのない方はびっくりするかもしれませんが、基本的に音読します。 もし英語の本を読んでいるのなら一文、もしくは長い場合は適当なフレーズで区切って和訳しながら読みます。

そして1節程度読んだら音読する人を交代します。 また途中で気になるところがあったら音読を止めて、その内容について語ります。

その繰り返しです。

今までの読書会の思い出ほろほろ

まずは会社で リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice) 読書会をもう3年くらい前ですがやっていました。 「良いコードってどんなもの?」について同僚と意識と認識を合わせることができたのが非常に良かったです。あと、いろんな言語をやっている人がいるので「Java だとこう」「Ruby だとこんな感じ」など、言語の文化に基づいた議論ができたのも良かったです。

次も会社でですが、 Working With Unix Processes (English Edition) の読書会をやりました。 今なら なるほどUnixプロセス ― Rubyで学ぶUnixの基礎 - 達人出版会 で日本語版も買えますが、当時は英語版しかなかったので交代で和訳しながら読みました。 英語の本って一人で読もうとするとモチベーションを保つことが難しいですが、みんなで読むことで楽しく読むことができました。 あとは一人で読むと英語の理解でいっぱいいっぱいになってしまうかもしれませんが、そこは仲間の知恵を借りて英語を理解するだけにとどまらず、内容についてもちゃんと理解できたと思っています。

あとは @1syo さん、@miyohide さんが タネマキ | 横浜 コワーキングスペース - シェアオフィス でやってる読書会に一昨年の年末から現在も参加させてもらっています。 この読書会は毎週土曜日の10:40から、しかも英語の本というなかなか意識高い感じの読書会になっていますが @1syo さんと @miyohide さんがいるおかげでなんとかくじけずに続けられています。

読む本も3冊目に入りました。 ちなみに1冊目は Objects on Rails、2冊目は Working With TCP Sockets (English Edition)、そして現在読んでいるのが The Pragmatic Bookshelf | Growing Rails Applications in Practice です。

もちろん3人とも同じ会社で働いているわけではないのですが、本を触媒にして Rails の設計の話だとか、実物のコードがないとなかなか語れない深いレベルでお互いの知識を覗き合うことができるのでとても楽しいです。これは普通の勉強会だと体験できない経験だと思います。 そして、「みんな勉強してるんだなぁ。。。」と自分の勉強不足を毎回思い知らされるわけです笑

ご提案

ここまでこのエントリを読んで「読書会やってみたいな」「読書会に参加してみたいな」と思った方向けに、僕の経験を基にしていくつかご提案したいと思います。

読書会に向いている本はこんな本

レシピ本の様にリファレンス的につまみ食いして読む本よりは、何か一つのテーマについて一貫して書いてある本の方がいいと思っています。 レシピ本は一人で斜め読みして速攻で頭にインデックスを構築しておく方が役に立ちます。 (補足: レシピ本の読書会は、参加人数が多かったり参加者が開催日によって異なる場合には有効です。)

また基礎について書かれた入門書よりは実践、応用レベルの本の方が良いと思います。 入門書は一人で読んでサクッと次のステップに向かう方が良いのに対して、実践・応用レベルの本になると書いてある内容に関して賛否両論がある箇所があったり、疑問に思う箇所があったり、自分のこれまでの習慣に反することが提唱されていたりします。 そういう箇所を仲間と話し合うことによって、本の理解に対するレビューを行うことができます。

英語が苦手な人はぜひ英語の本の読書会に参加しよう

一人じゃくじけますからね。。 たとえ英語が得意な人がいなくても、数人で「これはこういう意味じゃない?」などと話しながら進めれば十分モチベーションを保つことができると思います。

一緒のチームじゃない人と積極的に読書会をしよう

一緒のチームの人とは読書会をしなくても実際のコードをもとにしていろんなことを話すことができます。 「このクラスはこう分割した方がいいんじゃない?」とか「変数名がちょっとアレだよね」とか。。

しかし一緒のチームで働いていない場合はなかなかお互いの知識を共有することができません。 教え合おうにも何を教えればいいのかわからないですし。。。

本を読みながらその内容に沿って、時には脱線したりしながら話すことによってコードを肴に話をするときと似た様な効果を得られると思います。 うまく説得力のある文章にできないのですが、本の内容をガイドに使うことによって、浅い意見交換に終わらずにちゃんと議論するレベルまで話をできる実感があります。

以上です。参考になれば幸いです。

RE: どんなことを勉強すればいいですか?

仕事でインターン生や経験の浅い方のレビューをしたり面接を担当したりしててよく聞かれる質問が「どんなことを勉強すればいいですか?」です。 それについてちょっとポエムを書いてみようかと思います。

主に会社で一緒に働いている人やこれから一緒に働くことになりそうな方向けに書いていますので、一般論として捉えるとやや極端だったり偏っていたりするかもしれません。ポエムなので許して。

専門家であるという視点から

エンジニアとして仕事をする以上、専門家 (プロ) であるという誇りと責任を常に持って欲しいと思います。 そのためにはその自信を裏付けるための知識が必要となります。

僕のいる Web やスマホアプリの業界は流行の移り変わりが激しく、新しい情報を常に追いかけ続けないとあっという間に置いていかれてしまいます。 しかしながら新しい知識を追いかけ続けるにも確固とした基本がないと、曖昧な知識の上にさらに曖昧な知識を積み重ねるだけの非常に頼りないエンジニアになってしまうだけです。

本を読もう

そこでおすすめするのが、まずは本を読むこと。 Web で検索すれば断片的な知識はいくらでも手に入ります。 Qiita とか stackoverflow などはとても頼りになるサイトだと思いますし、ブログを熱心に書いていらっしゃる方もたくさんいるので大量の情報が手に入ると思います。 でも断片的な知識をつなぎ合わせたところでどこか必要な知識が抜けてしまったり、整合性の取れていない知識になってしまったりするとやっかいです。

言語に関わらない知識ならまずこれを読んでください。

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

チーム開発でコードレビューを受けるようになると、ここに書かれている内容はもはや前提知識になります。 当たり前すぎてそのうち指摘すらしてもらえなくなるかもしれません。 僕も最近再度読み返しましたが、無意識のうちに「良いコードってこんなコードかな」って思っていることをきちんと具体例とともに言語化してくれている本なので、これを読んでおくことでコードについてのコミュニケーションがスムーズになります。

Ruby なら以下のあたりを押さえておくといいと思います。適当に Amazon のリンクを貼りますが、電子版もあったりするので適宜探してください。

初めてのRuby

初めてのRuby

初めてのRuby

ちょっと古い本になりつつありますが、他の言語の経験がある人が Ruby らしさを知るにはとても良い本。薄いのであっという間に読めますし。

プログラミング自体も初心者であるなら スタートアップRuby の方が易しくていいかも。

たのしい開発 スタートアップRuby

たのしい開発 スタートアップRuby

Ruby のコミュニティ含めた文化についても知ることができます。幸い身近にコミュニティがある場合は、この本を読んでから ⚪︎⚪︎.rb みたいなところに飛び込んでいくと、継続的にモチベーションや情報を得るきっかけが得られます。

Rails についてはまずは電車本だと思います。

RailsによるアジャイルWebアプリケーション開発 第4版

RailsによるアジャイルWebアプリケーション開発 第4版

そこから先は パーフェクトRuby (PERFECT SERIES 6)パーフェクト Ruby on RailsメタプログラミングRuby などなどたくさんの本がありますが、まずは上述のあたりから入るといいと思います。

iOS なら本ではないですがまずは Apple Developer で公開されている公式のドキュメントから始めるといいと思います。

チュートリアル Start Developing iOS Apps Today: Setup

その他のドキュメント 日本語ドキュメント - Apple Developer

特に iOS View Controller プログラミングガイド に一通り目を通しておくと、iOS 開発の勘所はなんとなくわかります。

そのあとの書籍ですが、以下がおすすめです。

UIKit徹底解説 iOSユーザーインターフェイスの開発

UIKit徹底解説 iOSユーザーインターフェイスの開発

主に View について書かれた本ではありますが、View, View Controller 周りで何ができるのかをちゃんと知ることによって、ようやく MVC を意識した設計が出来ると思いますので。

アンテナを張ろう

次におすすめするのが、新しい情報にアンテナを張ること。

ただアンテナを張るだけではなく、情報を鵜呑みにせずに自分で確かめることも必要です。 Web にある情報は特に玉石混交で、誤った知識をそのまま業務に適用してしまうのは非常にまずいことです。 また、必ずその記事の書かれた日付を確認してください。技術情報には鮮度があります。

その前提の上で鮮度の高い情報を得る方法は以下のとおり。

1. 信頼できる人をフォローする (Twitter, GitHub, はてなブックマーク)

GitHubTwitter で有名な人とか信頼できる人をフォローしておくことで、非常に鮮度の高い情報を得ることができます。 はてなブックマークの場合は、「お気に入り」っていう機能ですね。

例えば

  • ブログ書いたよー とか
  • こんなリポジトリの Watch を始めた / Star をつけた
  • ⚪︎⚪︎でハマった
  • このエントリにブックマークつけた

一度習慣にしてしまえば気になる人を見つけるたびにフォローを増やせばいいので楽ですが、まだやっていない方はこの休みのうちにガッとやっておくといいと思います。

GitHub の Star は http://starseeker.so っていうサービスを使っておくと、自分がフォローしている人がスターをつけたリポジトリが毎朝メールで配信されてくるので超絶便利です。

はてなブックマークのお気に入りは iOS 限定ではありますが HBFav2- Hatena-Bookmark Reader for iOS を使うと、自分がお気に入りに入れているユーザがブックマークした URL が随時 iPhone に配信されてくるのでこれも超絶便利です。

2. 一次情報にまず当たるクセをつける

なるべく一次情報にあたるようにするのも時間節約のコツです。 鮮度の落ちた日本語のブログエントリよりも、githubリポジトリ上にある README を読む方をまず優先するといいと思います。

3. 実践してみよう

最後にその情報を自分のものにするために手を動かすことも大事です。 書籍や Web の情報源から得た情報をきちんと自分のものにするには、ちゃんと手を動かすことだと思います。コードにして自分のリポジトリなり gist に置いてみて初めて「自分のものになった」と言えるかもしれません。

なので、ぜひ試してみてブログなり GitHub なりにコードを載せてみて欲しいと思います。

チーム開発という視点から

チーム開発においては、会社で使っているコミュニケーションツールに慣れておくことも大事だと思います。 例えば Git / GitHub を普段から使って、その機能に慣れておくこととか。

今までコードレビューを受けられる環境にいなかった人は、「人に読んでもらう」ことを前提としたコーディングを心がける必要があります。

なかなかこれは意識してやるようにしないと身につかないのですが、コミットの粒度とかコミットログの書き方、コード内のコメントとか関数名、変数名などあらゆるところに読む人の目を意識する必要があります。 詳しくは前述のリーダブルコードで。

あとは仕事の優先順位のつけ方にも考慮が必要です。 タスクが複数あるときにどのタスクから手をつければいいのか。 それは状況によって違ってきますが概ね以下のようなことを考えるといいと思います。(そして困ったらチームメイトにすぐ相談することも大事)

  • このタスクを {始めること or 終わらせないこと} によって誰かの仕事を止めてしまわないか?
  • 技術的なリスクや検証が必要な項目が含まれるタスクの場合、早めにやっておかないとその他のタスクに影響を及ぼしてしまうのでは?
  • 作ろうとしている製品にとって、このタスクの優先度はどのくらいなのか?(実装に時間はかかるけどなくてはならない機能だったら、すぐ終わるなくてもいい機能より先に実装した方がいいのでは?)
  • ユーザにとって自分がこれから行うタスクはどんな影響を与えるのか。

ちょっと抽象的な感じになってしまったし、普段無意識で行っていることを網羅はできていないと思うのでちょっと頼りないですが、参考にしていただけると幸いです。

社会人としての視点から

ここから先はさらにポエム度が高まってしまうのですが、要は「一緒に仕事してて楽しい」って思われる人になりたいな!ってことです。 普段から僕も気をつけていることではありますが、日常の中でついつい雑になりがちな部分なので気をつけたいです。 Team Geek ―Googleのギークたちはいかにしてチームを作るのか の HRT: 謙虚 (Humility), 尊敬 (Respect), 信頼 (Trust) も参考になると思います。

同僚として敬意を払う

「親しき中にも礼儀あり」です。 必要以上に踏み込み過ぎず、かといってよそよそしくなりすぎず、同僚としての適度な距離感を取れるといいと思います。

また意見の相違がある場合は意見についての厳しいやりとりは必要ですが、人格の否定をしてはいけません。

「あの人、全然システムのことわかってないからな」って諦めてしまうのはまずいです。 (ついつい自分が詳しい分野については上から目線になっちゃったりもしますが...。)

そうではなく、ちゃんと相手に教えるべきことを教えていない、または相手にとってわからないことを聞いてもらえる関係を築けていない自分になっていることを反省すべきです。 そして逆に自分が知らないことをたくさんその相手は知っているはずです。お互いの知らないことをきちんと質問しあえる、そしてその上で意見を交わせるようになりたいですね。

不平・不満と付き合う

仕事をしていると、大小さまざまな不平・不満が出てきます。 全てが自分の思い通りに進むわけではないので当然だと思います。

その不平・不満をどのように解決しますか? SNSで愚痴ったりしていると何の解決にもならないし、偶然同僚がそれを見かけると非常に嫌な気分になると思います。 同僚じゃなくても、大抵そういう愚痴って見かけるたびに見る人の心を重くするものです。

確かにその愚痴は正論で「正しい」ことかもしれませんが、それを声高に唱えて周りに威圧感を与えることは必ずしも正しい方法だとは思いません。 解決すべき問題なら解決策を考え自ら動く、もしくは解決できる権限を持つ人に相談をする、など前向きな態度で挑むことが必要だと思います。

とはいえ、愚痴ってすっきりする程度のものごとも多いので、それはそれで人に見えないところでこっそりお酒の肴にでもしながら楽しい時間に変えてしまえればいいと思います。結構そういうのも僕は好きです。

人を頼る

人を頼ることってなんとなく自分のダメさを認めてしまうことだったり、人に迷惑をかけてしまうことだったりしそうでなかなか勇気が要るものです。 でも全てを自分一人でこなそうとするとタスクの量か質の問題で必ずどこかで限界がきます。だからチームで仕事をしているんだと思います。

チームメイトにはそれぞれ強み・弱みがあります。自分一人で閉じてしまって、個々がブラックボックスになってしまうのはもったいないと思います。 常に気軽に相談ができる状態にチームを保ち続けられるといいですよね。

そのためにはあまり関係なく思えるかもしれませんが、普段から雑談したり、ご飯を一緒に食べたり、くだらない話をチャットでやりとりしたりして心理的な距離を近めておけるといいなと思います。

そして、いざとなったらきちんと頼る。そして自分もどこか一部でいいから誰かに頼ってもらえる。そうなりたいです。

まとめ

途中から論点がズレてまとまりが無くなった感じもしますが、何かの参考になれば幸いです。 僕がこういう気持ちで仕事をしているっていうことだけ伝われば十分なのかもしれません。。という自分のためのポエムでした。