私個人から見たチームの変化について

今年の1月15日に現在の会社に入社して、もうすぐ1年が経ちます。

フリーランスを卒業して「会社員」というステータスが久しぶりだったので、入社当初は色々戸惑うことが多かったのですが、今では立派な不良社員になりました。

そんな私個人の今年の振り返りは別途書くとして、チームや担当サービスがこの1年でどのように変わったか？を少し振り返ってみたいと思います。

ミーティングについて

週次ミーティングの在り方の見直し

アサインされた当時、定例のミーティングは以下の2つでした。

• 朝会（毎朝、今日何をするかを報告する会）
• 週1回の週次ミーティング（一週間何をしたか、次週何をするかの報告）

アサイン当初は右も左も分からない状態で、ミーティングもただ参加するような状態でしたが、会社にも慣れてきた頃、ミーティングの在り方をもう少し見直したほうがいいと思うようになりました。

というのも、当時の週次ミーティングは朝会の延長なような状態で、全員が集まる価値が生かされていないと感じたのです。そこで上長に相談して週次ミーティングの在り方を大幅に見直しました。その後も何度か内容の見直しが入り、最終的に現在はこのような内容に落ち着きました。

• 各チーム担当分の進捗状況の報告
• 次回リリースに関する報告
• 技術的課題の共有
• 発生した障害の共有
• 技術的ナレッジの共有
• ユーザからの要望の共有
• 売上・成長率の報告
• 新規Issueの確認、およびマイルストーンの設定
• 未解決Issueの棚卸し（月1回）

内容は今後も少しずつ変化していくと思いますが、その時々で最適な会議体を検討する風潮が根付いたことが、良い変化だったと思います。

おそらく入社直後だったから、第三者的な視点で長年の慣習に疑問を持てたのでは？という気もするので、転職直後の「曇りなき眼」のうちに、思い切って既存の体制に斬り込む勇気も時には大切だと思います。

ミーティング開催日の見直し

しばらくずっと、週次ミーティングは金曜の夕方に行われていました。でもこれにもちょっと不満がありました。

ミーティング内容の見直しの結果、せっかく様々な議論が出来る場になったのですが、金曜夕方に密度の濃い話をしても、具体的なアクションを起こせるのは週末を挟んだ月曜になってしまうのですよね。打合せで何かが決まったら、さっさと動いたほうが良いことって多いのですが、週末を挟むと残念ながら忘れちゃったりするんですよね・・・

ということで、週次ミーティングは火曜の午前中に行うよう開催日の見直しをしました。体感的に月曜って何かと忙しかったりするのと、ハッピーマンデーや振替休日などの影響を受けやすいので、週の前半、特に火曜は個人的にちょうど良いと思ってます。定時近くは避けて可能な限り午前中にやるのもポイントで、熱量のあるうちにアクションが起こせるため、午前中に行うのはなかなか良いと感じています。

技術的負債への取り組み

負債返済の日を作る

これはつい最近決まったことですが、「月に1日だけ技術的負債を返済する日」というのを設けることになりました。

なかなか手を付けられていない技術的負債が蓄積しており、しかし他タスクとの優先度を考えると、いつまでも放置されてしまうのが現状でしたが「月1日であれば通常業務への影響度も少なく済む」ということで、試験運用的に月に1日行うことで始まりました。

これはまだ始めたばかりなので、効果がどの程度出るかは未知数ですが、個人的には「負債が溜まり続けることへの精神的負担」の軽減効果は大きいと思っています。稼働ベースで言えば全体の5%程度しか負債返済に充てられないのですが、それでも「負債を返済する機会がある」ということ自体が、エンジニアの精神衛生には大切なことだと思っています。

全体に関わる技術的負債について

現在、サービスの根幹部分で、インフラコスト/開発効率/学習コスト共に負担の大きなアーキテクチャが採用されたままの状態にあります。

サービス開始当時はそれしか選択肢が無かったのですが、現在は他にも代替となるものが出てきました。しかし、今から変更するのは大きな労力を伴うが、このまま突き進めばデメリットも膨らみ続ける、という悩ましい問題にぶち当たっていました。

そこで、新しいアーキテクチャへ乗り換えをチームで慎重に検討したものの、最終的には「今はサービスのグロースが最優先」という結論になったため、乗り換え自体は見送りになってしまいました。しかし、ただ見送るというだけでなく、「売上目標が達成されたらアーキテクチャ変更を再検討する」という結論になったのは個人的にとても良かったと思っています。

今回のような「新しいアーキテクチャへのチャレンジ」が見送られるようなケースは、往々にしてエンジニアのモチベーションをポッキリ折りやすいものです。しかし条件付きでも可能性があるのと無いのでは話は大きく違うし、今度はその条件をクリアしようという別のモチベーションにも繋がります。また、このような議論および結論が出せたこと自体が、チームにとって意義のある結果だったと思っています。

開発以外のタスクについて

マーケティングや営業活動

残念ながら、現在サービス専用のマーケティング部隊や営業が不在なため、チームとしても開発だけに専念していれば良い状態ではないのですが、アサイン当初はその辺がかなり手薄な状態にありました。

そこでチーム内で話し合った結果、直接的な営業活動は引き続き営業部門をはじめ他部署に依存するものの、社内の情報連携や、整っていなかったマニュアルを充実させていくなど、他部署との強化を図ることになりました。またマーケティングについては、サービスサイトや販促パンフレットの見直しから始め、外部メディアへの露出、開発ロードマップの公開などを行いました。

まだ十分とは言えないものの、この1年間で開発以外の部分については、以前より大幅に改善されたと思っています。

ユーザーヒアリングの実施

本来であれば定期的にユーザーヒアリングは実施すべきなのですが、慢性的なリソース不足でなかなか実施出来ないでいました。

現在、サポートページから要望等を投稿してもらう仕組み自体はあるのですが、表面的な要望しか分からず、もっと踏み込んで「具体的にどのように利用され、顧客の業務のどこに影響し、どのような不便を強いているのか」といったことを詳細に把握するために、ユーザーヒアリングを実施しました。

このヒアリングは、この1年で一番効果が大きい部分であったと個人的には感じています。

インタビューからは非常に多くの収穫があり、その結果として現在大きな仕様追加の開発を行っている真っ最中です。一般利用者向けのサービスとは違い、企業ユースのエンタープライズサービスの場合、顧客の業務に関する部分はヒアリングでしか把握出来ない、ということを改めて感じた次第です。

また、顧客だけでなく社内の各部署にヒアリングを実施したのも非常に良かったと思っています。弊サービスは社内でも多く使われているため、日々の業務効率に繋がるために必要機能や、どうすればもっとセールスに繋がるか、といった視点でもヒアリングを実施しました。これは代表から「売り上げを伸ばすことだけが利益ではなく、社内の業務効率を改善することも利益に繋がる」と言われたことが大きいのですが、それが結果として営業やサポートといった多方面からの意見の収集に繋がり、顧客だけではなく社内に目を向ける良いキッカケになり、そこから多くの課題も見えてきました。

現在はこれらヒアリングの結果から、必要な機能の開発中です。リリースされてからが本番ではありますが、以前よりは確実に効果が高い方向に舵を切れている感覚があります。

さいごに

この1年間で、サービスの売上は年間目標を達成出来るかどうかギリギリなところですが、成長率としてはかなり良い数字となっています。

これは勿論チームだけでなく、営業を始めとした他部署からの協力があって達成できた数字であり、1つ1つは小さな変化ですが、積み重ねの結果がしっかり数字として現れていることが大変嬉しく思った1年でした。

高価な幼児用教材を買ってみてどうだったか

娘がまだ0歳の頃に、「家庭保育園」というお高い幼児用の教材セットを買ったんですね。うろ覚えですが、当時で40万くらいした気がします。（上の写真は、私が購入したセットにほぼ近いです）

その時は私もまだ育児休暇中で、幼児教育というものにも関心があり、やるぞー！とやる気に満ち溢れていたので思い切って購入したのですが、仕事に復帰してからはサッパリできなくなりました。育児休暇中も、初育児で疲れ果てていたので、なかなか思ったようには出来なかったですが・・・

192abc.com

幼児教育に興味がある人も多いと思うのですが、それらの教材を購入してみた結果、うちの場合はどうだったかを残しておこうかと思います。

過去の記録

Facebookに、当時の自分がこの教材について書き記していたので、まずはそちらから転載します。

3歳の頃（2014年9月）

まだ赤ちゃんの頃に、何十万も払って幼児教育の教材を買ったのだけど、なんだかんだ使いこなせないまま、3歳を迎えてしまいました。

私の中で3歳までに……というのが一つの目安としてあったので、タイムリミット超えちゃったような、なんとなくもう手遅れ感があって諦め気味だったのだけど、今からでも遅くないよね、と思い直してチョロチョロと再開しているこの頃。

挫折した理由は、仕事で忙殺されてたことも大きいけど、まだ言葉が通じず集中力がまったくない年齢の時には、本当に根気が必要で、私にはその根気が続かなかったのが一番大きいかな。

でも、3歳過ぎてそれなりにコミュニケーション取れるようになってきたら、以前よりも教材を使って遊ぶことに苦労しなくなってきたので、最近なんとか続けてみよう、という気持ちになってます。

ワーキングママが子供と教材使って何かするなんて、週末くらいしか出来ないし、お出掛けすると週末すらも時間が取れないので、家事の合間にパパにも協力してもらったりしないと難しいですね。

なんでこんな事を言い出したかというと、また別の教材を買いたくなってしまい…(笑)

それが20万近くするもんだから、本当にいいのか？！出来るのか？？という自分への戒めというか、また途中で放棄したりすることがないか不安で、ちょっと思考を整理してみようと思ったのがキッカケだけど、書いてるうちに、買う言い訳を探してるだけだな、と気付きました……ｗｗ

※ちなみに、20万近くする別の教材というのは、後で出て来る英語学習用のDVDセットのことです。

5歳の頃（2016年9月）

経過報告。

赤ちゃんの頃に買った幼児用教材は、一部は今でも遊んだりしているけど、フルセットなヤツを買ってしまったのもあり、ほぼ使いこなせていないです。結構なお値段したので勿体なかったけど、漢字がプリントされてる積木など、小学生以降になったら別の遊び方も出来そうなので、完全に無駄とは思ってないです。が、お値段を考えると微妙です😅
(論語の朗読CDとかも入ってて、今考えるとそれ必要か？と思う物が多いw)

このポストを書いてた時に購入を迷ってて結局買った英語教材については、2年間ずっと続いてます。と言ってもメインはDVD教材なので、保育園の送迎時に平日毎日往復20分ほど見せてるだけですが、単語量は飛躍的に増えたのと、日常会話のフレーズなんかも色々覚えたので、こちらはちゃんと成果を感じる。

動物や食べ物といった定番単語だけでなく、楕円や長方形などの図形や、形容詞なんかも自然と言えてるのを見ると、母が教育に手抜きをしても子供はそれなりに覚えるもんだな…と感心しますw

英会話の教室にも週1で行ってるので、そちらとの相乗効果というのもあるかとは思います。

ワーママが幼児用教材に手を出すなら、フルセットなヤツはなかなか難しい。もしやるなら何かに絞って一点集中させるのが良いのかもしれないな、と思いました。

そして現在

結論から言うと、高かった幼児教材は、絵本以外はほぼまったく出番が無い状態です。積み木はかろうじて、たまに引っ張り出してきて遊ぶかな？程度。

ドッツカード（算数を赤ちゃん時期に学ぶためのカード）を始めとする紙の教材は、私がやる気を出さないと子どもだけでは遊べないので、使っていない理由の99%は私のせいなのですが・・・💧

はっきり言って無理だった。仕事で疲れているのに、平日の夕飯時間帯に幼児学習させる余裕なんて無いに等しい。週末もなんだかんだで予定があって、スケジュールに追われている感じだし。

かなり意識が高いワーキングママとか、時短勤務で時間的余裕が多少あるとか、そういう人しか難しいだろうなと思います。

反省点としては、私は欲張りすぎました。算数も国語も絵も英語も・・・と、幼児期に色々と伸ばしてあげたいと考えていたのですが、仕事もしているママは、優先度を考えないとどれも全て中途半端になってしまう可能性が高い。

3歳の時の振り返りにも書いてますが、3歳未満の頃って日常のコミュニケーションすらままならないし、集中力も5分も持たないわけで、そんな子どもを相手に根気よくやるには、時間だけでなく心の余裕も本当に必要なんですよね。仕事で疲れている時に無理をしてやると「もう！これはこうでしょ！」などと、つい怒ってしまったり。それで子どもも余計に嫌がり・・・という悪循環。

3歳以降なら、それなりにコミュニケーションも出来るようになるものの、他に楽しい遊びも知ってしまっているのですよね。なので、よほど「楽しい！」と思わせる工夫をしないと、「やりたくなーい」となりがち。当たり前なんですが、思ったように子は動いてくれないのですよね。

教材について

私が赤ちゃん時期に購入したお高い幼児教材は、昨今のITを駆使したような教材ではなかったのも、大きな失敗だったかなぁ？という感じです。

現在6歳になった娘は、iPadで出来る算数アプリとか、絵本が定期的に配信されるアプリとか、ストーリーが楽しい英語のDVDなどは、自分から進んでやりたがっています。

効果について少し言及すると、アプリだけの効果ではないですが、算数については小学校入学前でも、簡単な足し算・引き算・掛け算は出来るようになりました。

絵本だけは、高い幼児教材の中にあった「推奨絵本」を最初に50冊（だったかな？）をまとめて買ったのは良かったです。3歳までは年齢に合わせて自宅で毎日読み聞かせをしていました。高い幼児教材の中で唯一良かったのはコレですね。どこをポイントにして読み聞かせると良いかの解説や、絵の中に隠された別ストーリーなどの解説も入っていたので、読み聞かせ時に絵本を楽しめるような工夫が出来た気がします。

3歳以降は、毎月定期購読の絵本を月に4冊 ＋ アプリで配信される絵本 ＋ 保育園に置いてある本、という感じで年間150冊くらいは読んでいるんじゃないかな。おかげで絵本は大好きなようです。（図書館は私が面倒がりなので利用していない💧）

英語は3歳から教室にも通っているので教材だけではないのですが、単語はやたら覚えました。特に英語のDVDがお気に入りで、全30巻あるDVDを、毎日の送り迎えの車内でひたすら繰り返し見続けて早3年。簡単なフレーズは暗記しつつあります。

さいごに

うちの場合は、ママが手を煩わせなくても自分一人で楽しめるものなら継続できた、という感じです。iPadなどのアプリなら、インタラクティブで音も楽しく、3歳以降はこういったものを活用するのも良いなという感想です。（赤ちゃん時期は、電子機器に頼りきりなのは個人的にどうかなぁ、とは思うのですが）

奮発して買った幼児教材の9割は活用しきれなかったので、もし今の私が当時の私にアドバイスするなら、「絵本以外は必要ないと思うよ」と言うと思います。

でもまぁ、やってみないと子どもは何に興味を持つか分からない、というのはありますが、最初から張り切って始めると、継続しなかった時の罪悪感もスゴイので（高ければ高いほど）、最初は小さく少しずつ試してみて、子どもが楽しめそうかを見極めてから、大きく投資するのが良いのではないかな、と思いました。

会社の規模が違うと何が違うのか、自分なりに考えてみた

1月に会社員に戻ってから、早くも8ヶ月が経っていました。

これまで私は、千人以上の大企業か、少人数ベンチャーのどちらかしか経験がなく、現所属の100人前後の規模の会社は初めてだったので、色々と新鮮な日々です。

私の経験から、会社規模によってどんな違いがあるかをちょっとまとめてみました。当然これが全ての会社に当てはまらないとは思いますが、何かの参考になれば幸いです。

これまでのキャリア（ざっくり）

※ここにある従業員数などはすべて当時の情報です。

• 新卒入社：1000人超の中堅SI企業
• 転職1：10名前後のベンチャー
• 転職2：2000人超のグローバル展開しているコンサル会社
• 転職3：5名のベンチャー
• フリーランス：主に数人〜30人前後のスタートアップ
• 現在：100人弱のCI企業

出戻ったり、他にも色々しているので、転職回数自体はもう少しインクリメントされてますが、ざっとこんな感じです。

ベンチャーはどうだったか

早速ですが、まずはベンチャーがどんな感じだったかを書きたいと思います。

良かった点

これはなんといっても経営者との距離の近さでした。大企業に所属していた時には、社長と話をする機会なんてまったく無かったし、正直顔も覚えてないです。

社長との距離が近いと何が良いかと言うと、会社が何を目指しているのか、どんなビジネスを見据えているのか、社長の熱意や温度感をリアルに感じられたこと。そしてそれに対して自分がどう貢献していくべきか、といったお互いのビジョンの共有が当たり前に出来たことです。

サラッと書いてますが、これが大企業になると現場にそのような情報が届くのは、伝言ゲームを経た結果のただのテキスト情報です。自分ごととして捉えるにはあまりに難しい。

あと、フリーランスでスタートアップを手伝っていた時は、会社やサービスの成長過程を共有させてもらえたのは、かなりエキサイティングでした。自分たちの手で作り上げていく感は、文化祭前の興奮に似た状態が続いている感じに似ています。そういった面白さはありました。
・・・ただしそれは、私が部外者でリスクを取っていない立場だったから、単純に面白さだけを感じられた、というのもあるとは思います。

悪かった点

逆にベンチャーで一番しんどかったのは人間関係です。仕事の内容とか給料よりも、これが一番辛かったです。特に超小規模の会社では、上司とウマが合わない場合は地獄でしかないです。チーム替えとか部署移動とか、そんなことできませんからね。少人数の会社に入るのであれば、メンバーが一緒に働きたい人たちなのかどうか、見極められるケースだけオススメします。

ウマが合わない以外でも、例えば「女性が1人しかいない」といった環境もかなり辛いものがありました。トイレが男女共用だったり、トイレ掃除をさせられたり。（トイレの話ばっかりだな💧）
「私、トイレ掃除するためにこの会社に入ったんだっけ？」と何度思ったか分からないです。家事は普段の自宅で既にお腹いっぱいなのに、なんで会社でまで・・・という気持ちが大きくなりすぎました。

大企業はどうだったか

良かった点

一方、大企業で良かった点は、やはり福利厚生の手厚さとか、研修制度の充実とか、ありきたりですがベンチャーを経験した後では身に染みてありがたかったです。

あとは、規模の大きな仕事をそれなりのポジションで経験できたことは良い経験値になりました。また、自分の望むプロジェクトへのアサインも時には叶ったり、社内に選択肢が多かったのは良かったな、と今になって思います。

悪かった点

ただし、何かと事務手続きが多かったり、例えば客先常駐の仕事が長く続くと帰属意識が薄くなったり、意思決定プロセスが面倒だったり、よく分からない中間管理職が増殖したり、それなりに大企業ならではの問題もあります。

でも私が一番辛かったのは、人数が多いと無能な人も多いということ。よく言われる「働き蜂の法則」に従って、優秀な人もいるが、無能な人もそれなりの数いるという現実。それが何に影響するかというと、無能な人を基準に仕事を組まなければいけなくなることです。ベンチャーで少数精鋭だった時には考えられないような、スケジュールのバッファやレビューの頻度など。
私が所属していた環境が特別だったせいだと思いたいですが、おそらくこれが現実でしょう。

大企業・ベンチャーの良い点／悪い点って、両者ほぼ裏返しのような関係。だから、何を重視するかによってどちらが向いているのかは、人によって分かれると思います。

中規模会社はどうなのか

まだ入社1年未満ではありますが、端的に言って私には今が一番居心地が良いです。

まったく不満がないわけでないですが、自分の成果が会社に与える影響をほどよく感じられ、ベンチャーのような人間関係の苦労も薄まりました。大企業と比較すると、人によっては待遇面や環境など見劣りする部分があるかもしれませんが、個人的にはその辺の差は他のメリットで相殺されている感じです。

社長が雲の上の存在でもなく、あらゆるリソースが不足しているようなベンチャーとも違い、今まで所属してきた会社との違いを楽しんでいる毎日です。

ただ、企業風土が自分とマッチしているかどうかも大きな要因ではあるので、単純にいいよ！と言えるわけではないのですが。

さいごに

転職回数が多いと日本では何かと不利になるケースが多いので、なるべく自分にマッチしている会社を選びたいものです。それで会社規模によってどんな違いがあるか、を自分の経験を元にまとめようと試みたものの、最終的には「企業風土」などという明確に計れない言葉を出してしまい、こんなの何の役に立つんだ・・・という申し訳ない気持ちで一杯になったところで、終わります。

【小ネタ】最近読んだ本について

最近読んだ本について何となく書いてみます（漫画は含めていないです）。量が多いので6ヶ月以内に絞り、内容を2/3以上読んだものに限定してみました。

購入しただけで積読状態な本は主に技術書が多いので、そろそろそっちを消化するか…と思いつつ早幾年。。。

本紹介

kindle unlimited な本が半分くらいある。書籍代はケチらない主義だけど、unlimitedで読み放題のお得感につい釣られてしまいます。

世界のトップ1%に育てる親の習慣ベスト45 地方公立→ハーバード合格! どこの国、会社でも活躍できる子の育て方

ビジネスモデル思考法 ストーリーで読む「儲ける仕組み」のつくり方

マーケティング・インタビュー 問題解決のヒントを「聞き出す」技術

ユーザーインタビューをはじめよう ―UXリサーチのための、「聞くこと」入門

ザ・ファシリテーター

面白い企画がなぜ、残念な商品・サービスに変わってしまうのか？

凡人が最強営業マンに変わる魔法のセールストーク

PROOF MARKETING(プルーフマーケティング)?ギネス世界記録®の突破力

仕事は楽しいかね？２

仕事は楽しいかね？ (きこ書房)

金がないなら頭を使え　頭がないなら手を動かせ: 永江一石のITマーケティング日記2013-2015 ビジネス編

一生使える見やすい資料のデザイン入門

『徹夜しないで人の2倍仕事をする技術三田流マンガ論 ─三田紀房流マンガ論─ 』 (コルク)

あなたの話はなぜ「通じない」のか (ちくま文庫)

おまけ（技術書）

最近、あまり技術書を買わなくなっている気がする… 半年に限定するとこんなもんだろうか。積読状態なままのものが他に3冊くらい…💦

レガシーソフトウェア改善ガイド

実践 Googleタグマネージャ入門 増補版 (デジタルプラスブックス)

できる逆引き Googleアナリティクス Web解析の現場で使える実践ワザ240 ユニバーサルアナリティクス＆Googleタグマネージャ対応 できる逆引きシリーズ

Webフロントエンド ハイパフォーマンス チューニング

さいごに

色々読んでる気になっていたけど、積ん読や途中で読むのを辞めた本を除くと、1ヶ月3冊程度のペースだったのでガッカリ。kindle unlimitedは値段を気にせずつまみ食い出来るのが良いのですが、内容が想像と違ったり、いまいち面白くなかったりで途中で読むのをやめることが非常に多いので、今後はunlimitedではなく良書に絞って冊数を増やしたい感があります。

活発な議論を促すために必要な「心理的安全」の具体策について考えてみた

私は現在、Webサービスの開発に携わっていて、サービスの今後の追加機能だとかプロダクトの今後について、チーム内でミーティングをすることがよくあります。現会社に入社するまでは、フリーランスで数社のベンチャーやスタートアップのプロダクトの開発チームの一員としてお仕事をさせてもらっていましたが、その時にも、同様にプロダクトの方針に関わるミーティングにも何度か参加させていただく事がありました。

入社して5ヶ月が経ったのですが、フリーランス当時と今とで、チーム内のミーティングの在り方が全然違うなぁ、と思うことがよくあります。そのことについて少し書きたいと思います。

スタートアップでよく見る人間関係

私の半径5m内での感想になりますが、スタートアップの創業メンバーというのは、以前から友人関係・同僚関係にあった人同士が会社を興しているケースが多く、人間関係がフラットな状態から始まっていることが多いように思います。人間関係がフラットというのは、先輩／後輩、上司／部下、経営者／従業員といった、各人をカテゴライズする属性を感じさせない人間関係のことを言っています。

そういった人たちのコミュニケーションは、多少の気遣いはあるものの、会話は基本タメ口だし、時には冗談も言い合える関係。プライベートな情報も日常的に共有しており（おそらく無意識に）、その人の性格だけでなく、得意・不得意、共感ポイントなどもある程度分かり合っている。

そのため、定例ミーティングも形式的なもので終わらず、何も発言しない人がいた…といった無意味な打合せは少なかったように思います。

少人数のプロダクト開発の現場において、例えばプロダクトの今後の方向性を議論するような重要な場面では、密度の高いブレストが求められると思います。フラットな関係の人同士の集まりでは、「一理あるけど、それってちょっと違くね？うまくいえないけど」といった気軽な会話が可能で、総じて活発な議論になりやすい。（議論が発散していくリスクも多少ありますが）

一方で、フラットな関係ではないサラリーマンチーム（と、ここでは呼ぶことにします）の場合、もし誰かの発言に違和感があっても、「うーん、それはどうなんだろう… でもハッキリとした根拠や理由が今は思いつかないな… なんて言えばいいだろう」などと心の中でワンクッションが入って、発言を迷っているうちに話がどんどん先に進んでしまう、といったケースはあるんじゃないでしょうか。（私はよくある）

「活発な議論」というお題目においては、どう考えてもフラットな関係のメンバー同士のほうがその目的を達成しやすいと思うのです。

フラットな関係を作るためには

チーム開発の文脈では、「発言しやすい雰囲気（心理的安全）を作るのが大切」といったことがよく言われています。

確かにその通りなんだけど、でも具体的にどうやったらいいの？といつも思うのです。いきなり全員が友達になれるわけではないし、ある程度の規模の会社なら、当然ながら上司／部下の関係は出来上がっていて、すぐに取っ払うことも難しい。

いきなりフラットな関係に持っていくのはかなり無理があるので、おそらく段階的にやっていく必要があると思っています。

例えば、まずファーストステップとして、「お互いをニックネームで呼び合う」くらいから始めてみる。これ、人間関係構築の初期における鉄板で、ニックネームで呼び合うと、セカンドステップの「タメ口で話す」に移行しやすい、という副次効果もあります。

ビフォー： 「阿部さん、この件の進捗どんな感じでしょうか？」
アフター： 「アベちゃん、この件の進捗どんな感じ？」

“ちゃん付け” で呼びかけてるのに、敬語だと逆に違和感ありますからね。

私にはこの程度しか今は浮かばないのですが、精神論ではなく実践できる具体的案について、何かアイデアがあればぜひ共有していただきたいです。

さいごに

一見するとくだらないと思われるかもしれません。でも、本気で「チームの心理的安全」について考えるなら、ただ漠然と「各人が気をつける」だけでは何も進展しないので、具体策にまで落とし込んで実施していく必要があると思うのです。

もし、ニックネームやタメ口は性に合わないわ… というメンバーが多そうな場合には、もういっそ諦めて、誰か絶対的なリーダーシップを持った人の独裁チームにする方がまだマシ。だと私は思っています。中途半端にお互いを立てあって、気を使い合った上辺の議論よりも、ジョブス的なリーダーシップを持つ人に導いてもらうほうが、議論もまとまって意味のある打合せになる気がします。

アプリエンジニアもUIレビューしよう

私が所属しているチームはBtoBのWebサービスを開発しているのですが、専属デザイナがいるわけではないため、デザイナ経験のある私がUI全般の責任者をしています。

UIに変更が入る時は、Issueの時点でデザインをどうするかコメントを求められたり、担当者がPRした内容のうちUI部分のレビューをする、という感じになってます。

小さな機能変更であれば、現場の開発者がボタンを1個増やす程度の修正はよくあるかと思います。そういうちょっとしたUIの変更時に、コードレビューとは別に「UIレビュー」を別のエンジニアがやってみたらどうだろう？と、ふと思いました。

というのも、今日偶然このスライドを見て、これは良いなと思ったのです。

初めてのレビューでも、二次受けレビュアーがいてくれれば安心できますよね。自分が気付けなかった部分があれば、指摘で更に成長できる。

これって何もコードレビューだけじゃなく、色々なことに応用できそうです。そう、UIレビューです。

ツールを使うだけがデザインではない

デザインを勉強したいけど、デザインツールを使ってまで何か作るのはちょっと…と思ってる人は多いんじゃないかと。それなら、UIレビューから初めてみませんか。

おそらく、大半のエンジニアはUIデザインに真剣に向き合う機会がほとんど無いと思うのです。なのでレビュアーになることでその機会を作りましょう。

実際にやってみると分かるのですが、デザインルールが決まっていないグレーゾーンのものって結構多くて、例えばサブミットボタンなら色や配置は決まっていても、そうでないボタンの色／大きさはどうすべきか？など。ある程度ルールがあったとしても、やはり例外は出てくるものです。そんな時に、

• このボタンデザインはこれで正解なのか
• 配置はここで良いか
• ラベルは利用者にとって分かりやすいか
• 前後のパーツとのバランスは取れているか
• 押した時の動きはどうか

たかがボタン1つですが考える視点はいくつもあります。コンシューマ向けサービスだと、更にコンバージョンへの影響なども気にする必要があるかもしれません。

レビューを正しく行うことよりも、これらを真剣に考えることが大切なのです。二次受けのレビュアー（デザイナ）がいれば、自分のレビューの答え合わせになりますし、気付けなかった指摘があれば一粒で二度美味しい。

これならイラストレーターやフォトショップを使うこともないので、やってみようかな？という気持ちになれたんじゃないでしょうか。

UIレビューの具体例

デザインレビューって個人の好みになってしまうのでは？と懸念するかもしれませんが、大きなデザイン変更ではなく、ちょっとした変更のレビューであれば、好みが入る余地はあまり無いです。

例えば今日私が実際にレビューしたのは、こんな感じでした。

これまではグレーのボタンが1つだったボックスに、機能追加でボタンが2つ追加されていました。1つの時は良かったのですが、狭いボックス内にグレーのボタンが3つとなると事情は変わってきます。私がコメントしたのは、

「メイン操作となるボタンだけ色を付けて目立たせ、利用者が迷いなく操作できるようにしよう」

というものでした。結果だけ聞くと簡単そうだと思ったかもしれません。実装している時には既存のデザインに引きずられたりして、案外気付かないものですが、レビュアーになるとよく見えてきます。

そしてこの程度なら、指摘された人は今後似たようなケースの時にすぐに応用できますね。小さな変更のレビューでは、指摘の大半は容易に実践できて応用可能なものなので、爆速でパターンの引き出しが増えていきます。

毎回レビューするのも大変だとは思うので、期間を決めてやるといいかもしれません。例えばチーム内で週ごとに順番でやるのも良いと思います。

さいごに

どんな方法であれ、大切なのは真剣に向き合う機会を作ることです。それが意識に繋がります。私たちの身の回りは、ありとあらゆるデザインで溢れています。意識が芽生えるだけで、目に入るほぼ全てのものが勉強対象になるのです。

今日、新しい洗濯機が届いたのですが、この操作パネルを見てください。

こいつ、光るぞ…！ pic.twitter.com/TuzOarC7OC

— HAL ( ˘ ³˘)♥量産型 (@bump_of_kiharu) 2017年6月16日

一色しか使っていなくても、ボタンの形状や大きさが異なるだけで、分かりやすくなっています。 意外と身近なところに色んな発見やヒントはあるのに、意識していないと気付けない。でも意識していれば気付くこともある。ただそれだけのことなのです。

Slackの専用チャンネルでフロントエンド周りの情報を垂れ流している話

早いもので、私が転職してから約5ヶ月になろうとしております。

二週間ほど前から、社内Slackでフロントエンド周辺の最新記事やトレンドなどを垂れ流すチャンネルを作りました。

内容は、Webブラウザ関連だったり、JavaScript関連だったり、JSフレームワークだったりと、とにかくWeb周辺で私がビビっと来た旬の情報を垂れ流すだけの、フロントエンド情報の専用チャンネルです。

なぜそんなチャンネルを作ったのか

単に自分の情報を整理する場が欲しかったのと、あわよくば他の人からも何らかフィードバックがあったら最高だと思ったから。

私が所属する会社はクラウドインテグレーションがメインなので、フロントエンドの話で盛り上がれる機会があまりないのです。無いなら自分で作ろうぜ！の精神により、勝手に作って勝手に垂れ流して、勝手にコメントしております。

現段階では9割方私しか発言していないですが、そんなこたぁ構わない。私が飽きるまで続ける所存です。

やってみてどうだったか

今まではローカルのメモにURLと簡単なコメントを残したりしていたのですが、これってすごく勿体無いなと。自分で言うのもなんですが、情報収集だけは割りとコツコツやってきたほうなので、こういうのは共有したほうが絶対良いよな、と。なんなら他の人の意見も聞きたいし、と。

でも、パブリックにするのは私の性格上ダメなんですよね。情報元に気を遣って当たり障りないコメントにするのは面倒だし、中途半端な知識のままネットの海に流したくないし・・・とアレコレ考えるとスピードが落ちる。何よりブログ形式にするほどの熱意も無い（文量的な意味で）。

なので、結論としてはSlackで簡単なコメント付きで共有するくらいが丁度いい。これが本当に丁度いい。

ちょっとしたコメントと共にURLを共有するのをマイルールにしているのですが、実際に続けてみると、内容をそれなりに理解しないと簡易コメントも書けないので、流し読みで終わらせず、知らなかったこと・分からないことは調べる癖が付きました。今までのようにローカルでストックするだけだと、この強制力は働かないので、これは続けてみて良かったと実感している点です。

さいごに

私としてはこのSlack垂れ流しは結構気に入っております。

情報のシャワーを浴び続けるうちに、点と点が繋がって線になることはよくあるので、数ヶ月単位では目に見えた効果を感じなくても、年単位になると違うはず。そして何より継続は力なり。ほぼ自分のためにやってるようなものなので、これからも自分よがりな垂れ流しを続けます。

以上。