Stock

最初はうまくいかないものだ。「自分はこの分野に向いていないんじゃないか」「才能がないんじゃないか」などと考えない。

できるようになる気がしないことも、何百時間・何千時間と積み重ねれば脳が最適化され、できるようになると信じる。

そのあれこれ考えている時間を手を動かすことに費やそう。

そのネットを見て一喜一憂してる時間を手を動かすことに費やそう。

小さくても、拙くてもいいから自分が欲しかったものや表現したかったものを作ってみる。小さなゴールが学び始めの苦痛を和らげてくれる。

「何が理解できていないのか」「何が上手く出来ていないのか」を把握する。足りていないことを1つずつ満たしていく。

「本を読む」や「動画を見る」といったインプットだけでは頭からすぐに抜けていく。脳みその複数箇所に負荷をかける学び方をすると効率が良い。

未知の分野で一から何かを学ぶとき、最初は苦痛を伴うことが多い。しかしある程度できるようになると突然楽しくなったりする。その「ある程度できるようになる」に達する前にやめてしまうのはもったいない。

その道の上級者と比べない。「このレベルまで達することができるんだろうか」とか考えない。

いずれにせよここで大事なのは、自分がどの領域で専門性を発揮して周りに頼られたいのか自覚することだろう。そしてその領域を深掘りして徹底的に理解することを目指す。この研鑽が他者に提供できる価値を生み出す。与えられた仕事をこなすだけでは go-to person 足り得る知識や経験を得るのは難しい。自発的に学び広げることが重要になる。

分からないことを素直に認め、質問者と一緒に調べて考えよう

何か学んだら積極的に発信していく。情報は隠すのではなく共有する。仕事内容を他者に秘匿してジョブセキュリティを高めたほうが go-to person として重宝されそうだが、むしろ情報を積極的に共有することで「これはあの人に聞けばいい」という雰囲気を作り出すことが重要。

一方、こうした経験が無い人の中には、変更容易性は余計なもの、面倒なもの、過剰なものとして捉えるケースがある。これは致し方ない面もある。私自身も書籍などで見聞きしていたものが、実体験を伴った（痛みを経験した）ことでその重要性に気付いたという経験が何度もある。こうした変更容易性の重要性が分からない状態で原則を駆使すると、ともすれば形だけ適用してピントを外したものにもなりかねない。例えば、クリーンアーキテクチャを採用したのに、ただ手数が増えるばかりで効果が実感できないというようなことが起こり得る。

副次的な変更に影響を受ける箇所は限定的にしておくことで、その影響範囲を小さくできる。これはレイヤ分けしなくてもクラス設計の工夫で十分に対応できる。例えば、外部ライブラリをアプリケーション全体で広く使うのではなく、それを内包したクラスを実装し、アプリケーションではその内包したクラスを利用するという方法だ。

外部変更容易性を向上させるには、クラスの組み合わせを変えられるポイントを作っておき、状況に応じてそこに必要なクラスを差し替えられるようにしておく。例えば、DI（依存性注入）やOCP（オープンクローズド原則）、さらに GoF のデザインパターンにこういった例がある。この方法は有効である場面はある一方、方法によってはあらかじめ変更できる箇所を予測して実装しておく必要があり、構成としてもやや複雑になるという面がある。

「Easier To Change」（変更をしやすくする）。これがETC原則です。 (略) 我々が知る限り、この世の中のあらゆる設計原則はETC原則を特殊化したものとなっています。

一方、内部変更容易性を向上させるには、クラスやモジュールの内部実装を変更しやすい状態にしておく。有効なもの一つに情報隠蔽がある。

どういった状態が理解しやすいものかというのは読む人にも依存する。そ

情報がオープンになっていればタスクの背景やそこに至る過程が見えるが、そうでない場合、何のためにそれをやるのかが分からない。