設計について本気出して考えてみた
こんちは、じぬです。
本日のメニューはこちらです。
- 設計に興味をもった
- クリーンアーキテクチャ本読んだ
- 趣味プロジェクトをリファクタリングした
はじめに
お仕事で扱っている SDK のドッグフーディングとして、趣味でミニゲームらしきものを作ってます。 せっかくなので UniRx や Extenject など使ってみたかったライブラリもふんだんに盛り込んで好き放題に書いています。
が、好き放題やり過ぎてとっちらかってきたので、リファクタリングしたくなりました。 あわせてクリーンアーキテクチャなどの設計にも興味が湧き、そのあたりを学んでみました。
※ 正直まだ理解し切れていないので、あくまで試した内容の紹介としてご覧ください
ゲームの現状
概要
このゲームは操作キャラ（ユニティちゃん）が赤白のボールに触れることでポイントが貯まります。 操作キャラはジャンプやスライディングなどのアクションも可能です。
黄色のボールはポイント獲得の代わりに操作キャラをパワーアップさせます。 パワーアップ中は障害物を破壊できるなどの変化があります。
ほかにも SE、タップエフェクト、3D オブジェクト生成中のプログレスバー、SDK の機能を使ったボールのランダム配置、などの処理が存在します。
当初の実装概要
名称は一部省略してます。 はじめはサンプルを無理やり拡張したので Main が二つあったりしました。（笑（笑えない
| class | role |
|---|---|
| Main | ステートマシン 建物などの GameObject 生成 ミニマップカメラの生成 ロード中のプログレスバー管理 |
| GameMain | ゲーム開始のカウントダウン ゲーム中と終了の管理 ロード中のテキスト更新 タップエフェクト |
| Walker | ボールに衝突した際の処理 パワーアップ処理の反映 パワーアップ中の障害物破壊 |
| CharacterControl | 入力を操作キャラに反映（移動、ジャンプ、スライディング） アニメーションの制御 |
| Ball | ポイント獲得処理を発生 パワーアップ処理を発生 自らを Destroy SDK にランダム配置されるための処理 |
| BallMaker | ボールの生成と配置 |
| PointManager | ポイント加算処理 ポイント表示の更新 獲得エフェクト ボール破壊エフェクト |
まず感じたのは個々の役割が多いことです。
Main はつなぎ役なのでまだしも、Ball は複数の役割が入り乱れています。
また、依存の向きに統一感がありませんでした。 例えばキャラがボールを獲得した際、ポイント計算、サウンド、獲得エフェクト、ボール消滅、などが発生します。 しかしそれぞれの処理を「誰が誰に対して」起こすのかが統一されておらず、拡張する際にどこを直すべきかが曖昧でした。
リファクタリング
ここでは、リファクタリング前に考えたことを一通り説明していきます。 最後の節で実際に行った修正をまとめます。
仮想の追加仕様
目的も無くリファクタリングすると迷走しそうだったので、仮想の追加仕様を考えそれに向けて実装を整理することにしました。 考えたネタは以下のものです。
| 追加仕様 | 修正方法とその意図 |
|---|---|
| 別キャラを使いたい | キャラ操作を抽象化して差し替え可能にする、パワーアップ時のパラメータ調整を可能にする |
| ボールの種類を増やしたい | パワーダウンや速度アップなど新たな効果を想定し、操作キャラとボールが相互に行う処理を抽出することで差し替え可能にする |
| 壁破壊時にポイント獲得したい | 操作キャラに対するポイント処理を抽象化して、発生元を差し替え可能にする |
これらの実現を目標として、既存クラスを役割ごとに分解していきました。
クリーンアーキテクチャについて
ある程度分解が進むと、次はそれらをどう整理するか考えます。 せっかくなら原則にそって見直そうと考え、クリーンアーキテクチャを調べました。
クリーンアーキテクチャ自体の説明は著名な本なり記事なり多数あるので割愛します。 少なくとも自分にとっては難しい部分もあったので、複数の情報を取り込んで自分なりに噛み砕く必要はあるかと思います。
クリーンアーキテクチャと聞いて有名なのは次の図ですが、重要なのは「図に遵守したレイヤー分け」ではなく「依存方向の向き先」であると耳にします。 とは言え初めてでピンと来ない部分もあったため、感覚をつかむまでとりあえず図に倣った分類を考えてみます。
クリーンアーキテクチャによる分類は以下です。（一部の名称を略してます）
| layer | role |
|---|---|
| Business Rules | ビジネスルール |
| App Rules | ビジネスルール同士のつながり、関係 |
| Interface Adapters | 上位レイヤーの具現化、下位レイヤーとの接続 |
| Frameworks | DB やデバイスなど環境に応じた具現 |
これを元に整理した結果が次の図です。
整理前に考えたこと
まず、UI（特に UnityEngine.UI）に依存している部分を切り離すことは比較的分かりやすいです。
Frameworks 層に UI に直接依存する処理を置き、Adapters 層の IPresenter を通してそれらを利用します。
こうすれば UI 以外のテストが容易になります。
例えば、UI として表示する部分だけを切り離すことでポイント計算処理がテスト可能になる、という感じです。
Frameworks 層に依存しない具体実装も Adapters 層に置くことを想定しました。 抽象の実体化に伴う複雑さを引き受けるのが Adapters 層という印象だったため、このレイヤーは必然的に厚くなります。 とは言え散らかり過ぎな印象はあり、本来はこの内部をもっと役割ごとに分類するべきかと思います。
Business Rules 層と App Rules 層を実際に分けていくのは混乱がありました。
参考記事をいくつか見る限り、User などのモデルや純粋なロジックなどのドメイン知識が Business Rules 層、それらの使い方を定義したり関連付けるのが App Rules 層という分け方のようです。
いまのところ、純粋な知識の層とそれらを関連付ける層、という理解が感覚としてはしっくり来ています。
この点はなにをドメインとするかという話が重要なため、プロダクトの思想が出る部分かと思います。
整理後に考えたこと
ひとまず依存方向の統一はできていそうです。
Business Rules には依存される抽象クラスを、App Rules にはそれらをやや具体化したクラスを置いています。 App Rules が少ないですが、おそらく通信や DI などドメイン外のやるべきことが増えると合わせて拡大するのではと思います。 もしくは、ドメインの定義が甘いために Business Rules に要素を乗せすぎているという可能性もありそうです。 上位のルール層は、正直見直す余地があるだろうなと思っています。
Others は整理すれば Frameworks 層ぽい役割ですが、各所から気軽に呼び出せた方が使いやすいため独立した整理をしています。
実際にやったこと
実際に行った修正は以下のような内容です。
Main の責務を分割
まず、記述量が多い GameObject 関連の処理を別クラスに切り出しました。
建物や地形、ボールの生成と配置です。（MapObjectCreator）
プログレスバーの内部挙動がベタ書きされていました。
管理を別クラスに分け、初期化時に必要なパラメータを渡し、Main からは次に進むタイミングだけを伝えるように疎結合化しました。
（ProgressManager）
そもそもステートマシン自体イマイチな気もしましたが、やめるのは少々大がかりでした。 そのためこのクラスからはステート変更時の呼び出しだけを記述し、具体的な処理は他クラスに委譲する形で整理しました。
Ball の整理
Ball は生成時に SDK の機能でランダム配置され、ポイント獲得やパワーアップが発生するという役割があります。
まず形状が同じというだけでポイント獲得アイテムとパワーアップアイテムという役割を持っていますが、両者のコアロジックは無関係です。
また分かりにくいですが、自動ランダム配置されるための処理も他の機能と無関係です。
そこで役割を分け、フィールド上にある獲得できるアイテム（FieldIem）、ポイント獲得できるアイテム（IPointItem）、自動配置されるアイテム（OrnamentItem）という役割を必要に応じて Add する形にしました。
細かい依存関係の修正
例えば Walker クラスがゲームのアクティブ判定を持っている、Ball の Destroy を実行している、CharacterControl と密結合である、などが気になりました。
このあたりは依存性逆転の原則を意識し、interface で抽象化して依存方向を整えました。
Manager の分割
例えばポイント獲得イベントが発生すると、現在のポイントととの足し合わせ、複数ボールを獲得した場合の調整、その数値に向けてカウントアップしていく表現、など一連の処理を一つのクラスが管理していました。
結果としてクラスの役割が広くなり Manager という無難な名前がつけられていました。
対処としてまず、UI（UnityEngine.UI）と触れる部分を IPresenter として抽出し、Manager との接続は interface 経由で行うようにしました。
残った処理はほぼ計算だったので、責務を限定的にするため Manager を Logic というクラス名にしました。
感想
基本的にはやって良かった（面白かった、設計を考慮する有益さが理解できた）と思いますが、良し悪しをまとめておきます。
Pros
interface を切り出すことで強制的に役割の整理が行われるので、図示したことと合わせて制御の流れが分かりやすくなりました。 特に UI と切り離すことでテストがしやすくなる、というより「テストしたいところに注目して切り出す重要性」を意識できるようになりました。 今回は大した物量がないため効果は薄いかも知れませんが、ある程度大きなアプリケーションではもっと有益かと思います。（その分整理し続ける負荷はあると思いますが...）
また今回はリファクタリングを一部省略しましたが、プログレスバーやローディング表示などもテスト可能にした方が良いと思います。 地味にロジックが入り組んでいるため、はじめから TDD を意図した設計・作り方ができれば工数削減にも繋がると思います。
Cons
例えば Manager の分割では二つのファイルが増えており（IPresenter とその Impl クラス）、ルールを徹底するほど管理が煩雑化しそうです。
また複数メンバーでの開発を想定すると、レイヤーの分け方を具体的に定義・明文化しておかないと徐々に混沌としていきそうです。
実際、一人でやった今回でも割と迷走があったと思います。
アーキテクチャを主導できるスペシャリストがいる、継続してチームで学び続ける、など開発の土台が必要だと思います。
参考記事
【書評】チーム・ジャーニー 逆境を越える、変化に強いチームをつくりあげるまで
よく見かける本。ここ最近気にしてることに刺さったので感想まとめ。
チーム・ジャーニー 逆境を越える、変化に強いチームをつくりあげるまで | 市谷 聡啓 | コンピュータ・IT | Kindleストア | Amazon
それな！ってなったところ
- 特にチーム初期はお互いのリズムをつかむために定期で関わる機会を用意する。場作りを通して誰でも動き出しやすい環境を作る
- 集中力もリソース、集中すべき時間を意識して作り出す
- リードタイムを計測することでなめらかな進行（書籍内で言う「人間のようなチーム」）ができているか判断する
- タスクの重要度や優先度はリーダーだけでなくメンバー全員が把握している状態を目指す（民主化）
- スループットやリードタイムは定期的に計測し、ボトルネックの検知と解消を図る
- リードはまず目の前のタスクをなくす、片付けるのではなくまずはなくす
なるほど！ってなったところ
- リーダーは目標を定め、優先順位を決め、基準を定め、それを維持するもの
- まずはメンバー間の違いを理解し、チーム活動に支障があるようならチームにおけるルールを決める
- チームファーストとプロダクトファーストでチームのあり方が動くのはよくあること
- メンバー同士の制約がなければ活動は集約せず結びつきが弱くなる、完成条件や透明性などチームのルールを自分たちで決める
- OODA は空軍パイロットが用いる意思決定モデルで、PDCA に比べて予測の付きにくい状況に適応するためのモデルである
- PDCA の P に時間がかかりすぎる、という問題が起こるときがある
- チームの相互理解を進めるには何かを一緒に作るのが1番速い
- チームに基準があることで確信を持って前に進むことができる
- 役割を越境するには境界を認識する必要がある、そのために問うのは「自分は何をする人なのか」
- リーダーではなく役割であるリードは交代することができる
- マネジメント故に俯瞰から詳細に踏み込まない、という姿勢は分断を生む。これを避けるには両者を行き来するという負荷と戦う必要がある
- 意思決定の精度はどれだけ前提を問い続けたか、どれだけ選択肢を挙げられたか、という2軸で構成される
- チームメンバーの練度と自立性が高まったなら、リードがボトルネックにならないよう形態を変えていく（ヒトデ型へ）
- 最適化は現状を維持することが前提になる、そもそもこの仕事は必要なのかという前提を疑う機会も必要
- それぞれのメンバーがただ意見を出すだけではカオスになる、仮説検証に基づくチームの基準（共通理解）を作る
感想
新しい視点の発見もあった一方で、自分が実際にやっていることの目的や根拠が明確に言語化されていると感じる箇所も多かった。 自分の考えが自分だけの思い込みではないという後押しになったし、曖昧な思考が言語化（命名）されることで深化させたり派生して考えることがしやすくなった印象がある。 なのでリードエンジニアを試行錯誤中のいま読んだことは非常に有意義だったと思う。
具体的には、リードの民主化や定常的に自分たちを計測する機会の設計はぜひ形にしたい。
【書評】シンプルに人を動かす ５W１Hマネジメント
読んだ。最近気にしていることにマッチしていたのでまとめる。
Amazon.co.jp： シンプルに人を動かす ５W１Hマネジメント eBook: 渡邉 光太郎: Kindleストア
議論
- マネージャは発散させない議論を作る
- 深掘りするのか抽象度を上げるのか、議論の目指す方向を考える
- 話が分かりにくいときはとにかく全体像をつかむところから
育成
- なぜ？を問いすぎることはメンバの萎縮に繋がるリスクもある
- なぜ？ではなく原因がどこ？という観点を持つ
- 実況中継するだけではなく、だからなんなのか（so that）を考える
- 視野が狭まると自己の正当化を考えてしまう
- 依頼と丸投げが違うことを双方で認識する
- 丸投げを避けるため、上司の介入すべきポイントを明らかにする
- どこでつまづきそうか、難所も自分で考えてもらう
- なぜこの仕事を頼むのか、どういう成長を期待するか、という仕事の理由（why）も共有する
- 自分が考えて決めた、という感覚が強いほど主体性が強まる
- ポジティブに捉えることは必要、ただし難易度の高さも自覚しなければやり遂げることは難しい
その他
- 今の半分の時間でやるなら？など前提を排除した思考を心がける
- 前後（取引における前後の工程）左右（取引における強調、敵対関係者）の視点を考える
- 「メンバとコミュニケーションする」ではなく「毎朝15分技術について話す」のように具体的なアクションを定義する
感想
部下を持って2期目に入ったし、チームに人が増えたりもしたのでマネジメントの細かいことが気になる。 特に「きちんと伝わる伝え方」は試行錯誤だなぁと。
Unity から出力したプロジェクトを iOS シミュレータで動かして位置情報取得する際の設定
久々に初期設定からやる機会があり、その際に詰まったところのメモ。 動かせただけで細かい確認はしてないので他の方法もあるかも知れない。（というかありそう）
確認環境
- Unity 2020.3.4f1
- Xcode 12.4
Unity で行う設定
文言設定
Build Settings > Player Settings > Other Settings > Location Useage Description で位置情報取得時にアプリで表示する文言を設定する。ただし、後述の通り Xcode でも設定が必要。
ターゲットの設定
まず、Build Settings > Player Settings > Target SDK で Simulator SDK を選択したうえでビルドして xcodeproj を出力し、一度シミュレータを起動する。
ここの目的はシミュレータをターゲットとすることで以下のファイルを出力すること。最初から実機向けにビルドした場合はシミュレータ起動前にエラーとなった。
Library/Developer/Xcode/DerivedData/Unity-iPhone-hogehoge/Build/Products/ReleaseForRunning-iphonesimulator/UnityFramework.framework
その後、Target SDK を Device SDK にしたうえでもう一度ビルドする。（目的は後述の通り Capabilites 設定のため）
Xcode で行う設定
ビルド設定
初期状態だとデバイス向きでシミュレータが選択できないため、ビルド設定を変更する。
画面左の Unity-iPhone を選択、TARGETS で Unity-iPhone を選択、Build Settings タブを選択する。
Architectures を Standard Architectures、Supported Platforms を iOS に変更する。
（図は変更後の状態）
文言設定
先ほどの状態から Info タブを選択する。
Unity で設定した文言が反映されている行があるがこれだけでは不足している。
選択した項目の + ボタンで項目を増やし、Privacy - Location Always and When In Use Usage Description を追加する。
大文字の P で入力を始めると候補が一覧に出るため選択しやすい。
文言は埋まっていればなんでもよい。
Capabiliies の設定
位置情報をバックグラウンドでも取得することをあらかじめ設定する必要がある。
先ほどの状態から Signing&Capabilities タブを選択し、+ Capabilities をクリックして Background Modes を追加する。
Target SDK を Simulator SDK にしていた場合、Signing&Capabilities タブが表示されていなかった。
2020年の振り返り
こんちは、じぬ です。 人のを見てると自分も書きたくなったので振り返ります。（アドベントカレンダーもこんなノリで書いた）
と言っても仕事とその他自分にとって大きかった変化はこっちですでに書いてます。なのでそれ以外のことを。
ゲームの時間が増えた
特に4月から6月あたりはこれが顕著でした。仕事もフルリモート、それ以外の趣味も基本停止になっていて家で過ごすしかできなかったので。 18時半で業務を終えてそのまま PS4 を起動する日々でした。（当時はひたすら荷物を運んでました）
読書の時間が減った
電車の時間が減ったので。なので取り急ぎ目を通したいものは土日で読むようになりました。学生時代に本を読みすぎた反動から家では読まないようにしていたのを解禁です。 また仕事にからむことは、仕事中に30分ほどで目を通す、というのも悪くなかったです。
携帯通信の消費量が減った
今まで 5GB/月くらいだったのが 1GB 未満になりました。まぁ外出が劇的に減ったのでそれはそう。 たまたまその直前に通信量に応じて支払うタイプに変えたので、だいぶ安くなりました。
料理することが増えた
せっかくリモートで家にいるのに、仕事後に食事で外出するのがめちゃくちゃ億劫でした。 そのため家での食事を考えるようになり、コンビニ弁当→ご飯炊いて冷凍おかず→自炊、という風に変化していきました。
自炊はもっぱら鍋を作ってます。同僚に勧められたのですが、お鍋の素とそれっぽい素材を放り込めばできる、というのが想像以上に楽です。 やってみると面白くなって、色々アレンジしたくなります。お気に入りはトマトペーストとチーズです。 そろそろ魚介類も試そうかと思ってます。正直、いろいろ買いすぎて冷凍おかずより食費は上がってきています。
料理を気楽にやれているのは食器洗い乾燥機の存在が大きいです。たかが5分短縮できるだけなんですが、自分にとっては体感がかなり向上してます。 サブスクでレンタルしてるんですが、そろそろミニマム期間を過ぎるので自分で購入しようと思ってます。
生ゴミを家に置く状態が起きるようになったのでスマートゴミ箱を買いました。 料理やおやつのたびにビニール袋を縛り直す手間が減ったので地味に QOL が上がりました。ただちょっと小さかったです。
ほかにも家の環境が整った
アドベントカレンダーにあるように電動昇降机、ゲーミングチェア、食器洗い乾燥機が導入されました。
運動不足の対策にリングフィットアドベンチャーを始め、空間を用意するために片付けをしつつヨガマットなど買いました。 1日 50kcal を基準に続けています。楽しいんですが、運動負荷マックスだとそれなりにしんどくもあります。あとリアル友人のガチ勢から毎日のプレイ量を聞いて戦慄しています。
布団のマットを買いました。 実家で古びていたやつを持ち出して8年感使ってました。薄いのでずーっとフローリングの固さを感じながら眠ってました。 新しく買ったのは高さが 10cm 近くあり、まったく床を感じません。最高です。
リモート会議用にマイクを買いました。が、これはすぐに返品しました。 自分のベストとしてはイヤホン無しで過ごせるのがベストなんですが、スピーカーとマイクを分けるとどうしてもハウリングして上手くいきませんでした。 自分にとってはマイク付きイヤホンで充分です。ただこの辺は自分がちゃんと理解できてないので、もうちょっといいやり方があるかもしれません。
Alexa を購入しました。友人から激推しされ、不要になった LiveSmart というスマートリモコンを譲ってもらいました。 電灯とエアコンの ON/OFF に使ってます。あととりあえず音楽をかけたいときに便利です。まだそこまで劇的な感動は無いかな。 どちらかというと、実家に買って贈りたいなという感じです。
次に欲しいもの
不思議なもので、何かを買うと次の何かを買いたくなります（アカンのでは？）。 いま興味があるのは分割キーボードです。PC 操作で若干ですが手首に負荷がかかっている気がするので、それの解消を試みます。 あとはコーヒーかなぁ。ただ自分は水分量をとりたいので、ミネラルウォーターをがぶ飲みでそれなりに満足しています。
エンジニア的な振り返り
せっかくなのでこういう観点も。 振り返ってみると充電の年というか、将来のために色々と貯めていった1年かなと思います。
そもそもは Unity をガツガツやりたくて今のチームに入りましたが、そういう観点では満たされないところはありました。 が、その一方で関わりが薄かった技術（Web API とか Rails とか DB とか）に触れることができましたし、新規開発に初期から携わるという貴重な経験もできています。
あとは正式に部下を持つことになり、人やプロジェクトのマネジメントについて改めて考えることが増えました。 ちゃんと考えてみると 1on1 って難しいです。結構準備に気を遣ったりしてます。 あと自分なりにプロマネを考えてから向き合うと、改めてスクラムはよくできているなと感じました。この辺は真面目に勉強してみようと思います。
とは言えクライアント技術をやりたいこともあり、自然と業務以外でいかに力をつけるか考えたりもしました（せっかく自宅の作業環境整ったし）。 この辺は楽しく習慣に組み込んでいこうと思ってます。
まとめ
飲み会が減った分のお金を自宅に投資してみましたが、色々と楽しくやれたと思います。 とは言え今年の前半は遊び、後半は残業（地味に忙しかった）に時間を使った感はあるので、次はインプットの2021年にしていきたいです。
【書評】OKR、1on1 関連
@reximology です。 私事ですが中間管理職というやつになりました。と言うわけでマネジメント系のフレームワークについて本を読んだ所感をまとめます。要点を絞りたいので知っている内容は端折っています。
読んだ本はこちら。
OKR
- OKR は日々見返すことで進む方向を見失わないためのフレームワーク
- 評価の時期にだけ見直す、は間違い。今月、今週、今日行う作業が目標に対して進むものか確認するために使う
- 自分を目標に対して縛ってくれる
- 自信度レベルを可視化することでムーンショットの実現に OKR を活かす
- OKR に対して真剣さを求めるため、途中で変更することはしない。結果が失敗ならそれを次に反映すれば良い
シリコンバレー式 最強の育て方
- まずは信頼関係の構築、そのうえで成長支援につなげる
- 言語化できていない問題を見つけるためにあえて時間を取る、ということが大事
- 問題解決ではなく問題発見の場
- 特に希望されていないなら、細かい業務の話はしない。解像度は高くする
- とにかく話を聴ききることで話者のモヤモヤを晴らす
- 会話にゴールを定めなくていい。ただしどんな内容でどこを話しているか、というのは把握する（地図を持っておく、という考え方）
- 毎回褒める。そのための情報収集を常に行う。他者が実際に褒めていることを伝えるのも有効。
- アドバイスはしない。答えを伝えることもしない。あくまで本人の思考を促す
- 部下に上司（自分）を使ってもらう、という感覚でいてもらう
- 質問例：今の仕事の要点、懸念や悩み、今のチームに感じる課題
ヤフーの１ｏｎ１
- まずは承認でいい。話を聴いてくれる、というだけでも信頼関係につながる
- 1on1 の構成要素
- コーチングの質問も技術、試行錯誤と慣れで向上できる
- 分かっていても聴くことに徹するのは難しい。もはやガマンと言ってもいい
感想
OKR については以前も読んでいたので特に違和感なし。OKR の強みを改めてチームの人にも伝えていく必要はある。
1on1 については自分の意識を色々と変える必要がありそう。アイスブレイクはあるにしても、基本的には相手から喋ってもらえるように準備する。 正直まだ雑談と進捗確認がメインになってるので、時間管理や会話の案内を組み立てる。話を促せるようになることで、相手の話す割合をもっと増やしていく。
【書評】DevRel エンジニアフレンドリーになるための3C
読書感想文です。いつもより流し読みです。（本を速く読む実験です）
DevRel とは、自分たちのプロダクトをサービス利用者である開発者に使ってもらう、浸透させるための取り組み全般と理解しています。
グッときたところ
- DevRel に必要な 3C (code: 技術力, contents: 技術以外も含めた発信, community: ユーザコミュニティ) の言語化
- デベロッパージャーニー（ユーザが自分たちのプロダクトを通してどのような経験をしていくのか）の重要性
- そもそも DevRel という仕事に求められる能力（技術力、発信力、信頼性、速さ、アクティブさ）、プロとしての手腕の定義
雑感
自分は SDK 開発の中で DevRel と言われるような取り組みをしてきましたが、その中での曖昧とした部分を言語化してくれている本でした。書かれているとおりですが、発信には技術への理解が必要になります。技術と発信を両立するには、作業の速さやユーザに対するアクティブさも必要になる仕事です。
個人的には、3C の中でも contents が特に重要と思っています。 技術に限らず、ユーザ目線でどんなものが必要かを自分たちが理解し、それに応えられる発信を続けていくことが重要だからです。
