ChatGPTを使って翻訳を補助する（2023年11月11日時点）

これ何

本業とはあまり関係がないんですが、趣味で中国武術の翻訳（中文=>日本語）をしています。二年ぐらい前にDeepLやGoogle Translateの力を借りながらやっている時期もあったんですが、翻訳に時間が割かれすぎて、練習の時間がなくなるという本末転倒の状態になりしばらく辞めていました。

最近ChatGPTが出てきたので試しにこれで翻訳の補助をさせると片手間でそれっぽい翻訳ができるようになったので、その方法を紹介します。

直接業務の役に立つ人はいない気はしますが、ChatGPTを使った業務改善ぐらいの温度感で読むといいと思います。ちなみにChatGPTは課金していて、GPT-4を使っています。言語能力に関してはGPT-4が断然優れていますし、最近出たGPTsを使った方が楽に作業ができます。

自分自身、ChatGPTを使って本格的に翻訳をする記事を探していたんですが、あまり引っかからなかったので記事にまとめます。

プロンプトエンジニアリング

最初はGPTsとかはなかったのでとりあえずプロンプトを工夫しました。

あまり細かくは書きませんが、翻訳業務を主にいくつかの段階に分かれます。

• 事前作業（翻訳のための文章調整、背景情報の調査、スタイルガイドの作成）
• 翻訳（単語の意味、構文の解釈、文章の工夫など）
• 事後作業（翻訳の正確性、流暢性、スタイルガイドに合っているかなどの確認、ファイル形式の変換）

そのため、タスクごとにプロンプトを作って工程ごとに指示します。以下は翻訳のプロンプトの例です。実際の指示は全て英語にしています（トークン削減のため）。

これから中国語を書いて行くので、日本語に翻訳してください。

訳のルールは以下です。
- できるだけ直訳で訳す
- できるだけ単語をそのまま使用する 
- 中国武術の文章として訳す
- ですます調ではなく、だである調で翻訳する
- 翻訳の際は日本語の訳文のみ返答する
    
以下の表にある単語は下記の表に従って、訳してください。
| 中国語 | 日本語 |
|-----|-----|
| 站桩  | 站樁  |
| 推手  | 推手  |
| 散手  | 散手  |
| 技击  | 技撃  |
| 功夫  | 功夫  |
 
以下が翻訳の例です。今後翻訳する際は以下を参考にしてください。
 
（中国語）
我国拳学兴自战国时代，后以达摩洗髓易筋两法参之于华佗之五禽戏，始汇成斯技。虽今门派繁多，其渊源一也。不论如何分派，总不出以拳为名。夫拳者乃拳拳服膺之谓拳。动静处中，能守能用，此尽吾人气质本能之道，非纯式套数专论招法之所谓拳也。
 
（日本語）
我が国の拳学は戦国時代より興り、後に達磨の洗髄易筋の二法と華佗の五禽戲とを合わせて、その技を形成することとなった。今日、多数の門派が存在するも、その淵源は一つである。どのような派閥であれ、拳の名を外れることはない。拳とはいわゆる拳拳服膺の拳である。動静の中にあり、能く守り能く用いる。これが我々の気質や本能の道である。単に套路を数えて、専ら招法を論じる拳ではない。

このプロンプトと原文を渡すと大体80点ぐらいの訳が出てくるので、辞書やBardに不明な箇所を投げながら翻訳作業をしていました。BardはChatGPTと異なる解釈をしてくれることが多いので迷ったら両方に投げて比較します。

これも悪くはないんですが、単語表を増やしたり、原文が長くなるとあっという間にトークン切れになるのが難点でした。毎回プロンプトをコピーして新しいチャットを作るのは気持ち面倒でした。

GPTs

最近、GPTsが出たので上記の問題点が解決しないか試していました。最初は指示を聞いてくれなかったのですぐに諦めていましたが、下記の記事を参考に作ってみるとうまくいきました。

note.com

設定項目	内容
Name	中→日翻訳
Description	help to translate Chinese into Japanese.
Instructions	This GPT translates Chinese text into Japanese. The provided Chinese text includes content related to Chinese martial arts. To ensure minimal loss of the original meaning, GPT will respond as literally as possible, and translates using standard Japanese (in a plain form, 'da/de aru' style) without using polite language (the 'desu/masu' form).This GPT uses words as they are as much as possible.The basic rules of translation are indicated in prompt.txt, and these are followed. The user will present only in Chinese, and GPT will respond with only the Japanese translation.

最初はCreateタブで頑張って回答したり、ファイルをアップロードしてそこに指示を書いていましたが、上記記事を参考にInstructionsに指示を英訳して書くとうまく行きました。英語なのはその方が認識してくれやすい気がするからです。

手軽に作れたので、下記はおまけで作った翻訳補助です。わかりにくい文章を投げると、翻訳、単語の意味、構文の解釈を教えてくれるようにしています。便利ですが、こっちももう少し解釈が難しい時に工夫できそう。

設定項目	内容
Name	中→日翻訳補助
Description	This GPT helps in converting Chinese text
Instructions	This GPT helps in converting Chinese text, written about Chinese martial arts, into Japanese. This GPT responses in Japanese.Specifically, it provides a literal translation of the entire text, interpretation and explanation of the syntax, and the meanings of each word that make up the composition, thus assisting in accurately translating the Chinese language.

やってみた感じ、数千字を投げても翻訳を諦めないので、トークン数を気にせずに翻訳作業ができるようになりました。これでプロンプトをコピペする雑務からは逃れることができました。

ただ、prompt.txt というファイルに用語表を入れているんですが、これを時折無視している気がしていて、用語表の扱いはもうちょっと考える余地がありそうです。どちらにせよ手直しするので実際にはそこまで手間ではないんですが、エンジニアリングしたい気持ちがあります。

あとはこれらのGPTsを統合してスーパーGPTにできるのかもしれませんが、今のところやっていません。コンテキストが混ざると、自分自身が混乱する気もします。

総括

ChatGPTが出るまで翻訳作業は面倒で手に負えない感じだったんですが、技術の発展でだいぶ楽に作業できるようになりました。

個人的にトークン数を気にするのが本当に面倒で、APIを使ってバッチ処理しようかとも思ってたんですが、今のところGPTsのおかげでかなり快適に作業ができています。これ以上文章量を増やしてもチェックする手間が増えるだけだし、先生の真意を理解しようと思えば、翻訳より比較や解釈、議論などが必要なところだと思うので、量を求めてAPIに投げるのは趣味ではやらないと思います。先生方の文章をできる限り食べさせて、研究を深める方向ならやってみたいですね。

要望としてはChatGPTにファクトチェックとか情報収集を任せたいんですが、中国語の情報収集はほぼ0点なのでこの辺りはもうちょっとなんとかして欲しいし、いい方法を考え中です。先生を指定して論文を調べてもらうと大体間違っており、Bing検索をONにすると大体BOTが許可されていません。

なので、おそらく中国から本を輸入して自炊して食べさせるのが一番早そうですが、技術の発展を待ちつつ、工夫してみたいです。

最後に、翻訳作業を円滑にするためにはやはり翻訳業務や訳したい文章のコンテキストへの理解、日本語能力などが必要だなと思いました。80点を（自分なりの）100点に近づけるためにはその辺りのことを勉強する必要があり、求められるのはエンジニアリング能力だけではなかったです。まぁ、プログラミングもコーディングルールを決めて、コーディングをして、テストしてリファクタリングするので、似たような推論ができたのかもしれないですが。

ChatGPTを工夫していくとその辺りの業務理解やメタ的な思考能力が改善される気がしていて、それ自体が愉しみなんだなと感じます。久しぶりに研究して遊べてますね。

参考文献

駒宮 俊友『翻訳スキルハンドブック』

山田優『ChatGPT翻訳術　新AI時代の超英語スキルブック』

ベンチャー転職後の話

あらまし

前回からだいぶ日が空いたので振り返りも含めて書きます。

2022年秋ごろに前職から今の会社に転職しました。前職もベンチャーに分類される気がしますが、退職時には500人近くの人数がいたので最後の方はベンチャーという感覚はなかったです。現職は20人前後でまだPMF前の段階です。前職に入った時点では100人足らずぐらいだったはずなので、経験したことのないフェーズでした。

ちなみに前々職はグループ合わせて5000人規模、子会社だけで80人ぐらいでした。ここはこれでフェーズが違いました。

今回の転職動機は、経験したことのないフェーズの企業だったことが一つの大きな要因です。もう一つは前々職の上司がいて、その時に何もお返しできていなかったということです。

近況

基本的にはメンバーとして開発に参加しています。アプリの特徴として純粋なフォーム入力が少なく、1年間はほぼチャートを作っていました。自分でSVGをゴリゴリ操作していることもあれば、highchart などに頼ることもありました。チャート限定のアプリではないはずなんですが、フロントエンド専門が一人なので難しめのUIを任せられることが多く、その結果です。

メンバーはバックエンド、フロントエンド、インフラの全部を触ることになっていますが、元々バックエンドに主軸を持っている人が多いです。そのため、フロントエンドのマナー（エラーハンドリング、アクセシビリティ対応、UIの使い分けなど）を布教しつつ、最近バックエンドも真面目に触るようになりました。

所管

一言で言えば、当たり前のことを当たり前にやるのは難しいんだねというのと、やっぱり会社が違うと文化諸々は全然異なるというところでしょうか。

前職では採用、テストあたりは専門に任せられる方がいて、フロントエンドも専門のチームだったので新しい情報は意識しなくても入ってきていました。

今はいないので、この辺りの意識改革みたいなところは全部一から始める感覚でした。技術的なところはみんなそこそこなんですが、興味のない？ところは雰囲気でやってます。色々あって、採用候補者とのやり取りも自分でやるようになりました。

一応フルリモート、フルフレックスの会社なんですが、Slackのメンションとハドルのお願いは割とカジュアルに来るので、若干自由な働き方という面で勿体無い部分もあります。

よく言えば人の気持ちを理解できて温かみがある感じで、悪く言えば雰囲気でやっているところが多いなという感じです。そういうところをちょっとずつ会話しながら、世間一般レベルまでは来たんじゃないかとは思います。

あと、前職で言えば使っていただいているのが実感できましたが、今はアクティブなユーザーが数十人でなかなか使ってもらえる実感がないです。世の中の当たり前のソフトウェアを当たり前に作っている方々はすごい！というのがありありと感じられます。

あまり関係ないですが、絵文字も作っても社内で使ってもらえないので、この会社だとあんまり作らなくなりました。日本語で登録する人が多いので、日本語のエイリアスを登録すれば使用率が上がるかもですが、基本「ありがとう」「よろしくお願いします」が9割なので厳しそう。ただし、ネコの絵文字だけは使用率が高いので、よく更新してます。閑話休題。

note.com

年齢層は高めなので（40代前後）、地頭が良い人は多いです。最新情報を集めて研究！という人はあまりいないのですが、合理的だと思えばすぐに取り入れてくれる柔軟さはあります。労務制度も含めて働きやすさはあると思います。

前職の後半も含めてソフトウェア開発は人間と向き合うことだよねというのが先に来ていて、念願だった専門性を高めて研究という感じは今後も来ないんじゃないかという気もしつつあります。現職にいる限りは専門性よりも汎用性を広げる感じになると思います。これがベンチャーなのかもしれません。

なんだかんだ書いていますが、働きやすいのは確かなので気に入っています。ベンチャーなのに安住している感じなのは良くないかもですが......。

最近の興味

生成AIとそれに付随するツールはやっぱり面白いですね。趣味で中国語の翻訳をしていますが、数年前は2週間かけて書いていたところが3日ぐらいでできるようになりました。なのでChatGPTの有料プランも契約しています。言語能力はGPT-4の方が高いですね。Bardは時々天才時々阿呆という感じです。

本業もコーディング、アクセシビリティ対応などはほぼAIに投げれば済むような感じはしています。さすがにチャートは無理そうですが、それらしいマークアップならほぼ生成からの修正で済んでます。あとはテストの生成は便利ですね。

最近は新規開発ではなく修正が多いのであまり研究できてないですが、今後PoCをたくさん作るとなった時にみんなで研究したいなーと思います。それか翻訳を効率化するためにもう少しプロンプトエンジニアリングか、APIを使って何かするかな？

一方で翻訳もコンテキストを読むのは苦手で本格的に使うには結構手を加えないといけない感じはあります。この辺は学習させれば解決するのか、永遠に人間の専門性が必要なのかは微妙なところですが、とりあえずどちらも高めていくようにはします。でも、古文の翻訳は結構苦行なので機械にやって欲しいのが本音です。手間が倍以上かかります。

フロントの仕事はどんどん自動化できる雰囲気がありますが、仕事の本質的なところは人間の問題の解決ばかりなので、それを解決してくれるAIが来るまではしばらくなくならそうです。

会議の音声を食わせたら人の感情を考慮して、ファシリテーションのアドバイスくれたりしないかな。今のAIは聞かないと答えてくれないので、こういう包括的、全体的に見てくれる存在があればようやく専門性を発揮する夢に立ち返れるのかなと思ったり思わなかったり。もしくはバックエンドの線もありそう。

その辺の仕事もなくなったら、みんな仕事がなくなっていると思うので、翻訳か趣味のスポーツとかで生きていきたいです。それまではAIを使いつつ、そのAIの隙間とか人間と向き合って生きていくことになりそうです。まぁ、元気にやっています。

テストとコーチングを学ぶことにした

学習の動機

研究不足の2020年 - How IT Worksという記事を昨年の年末に書きました。2020年は当たり前のことを当たり前にやる年で新しい蓄積がなく、個人的に消化不良だったので、今年は何か深く追ってみたいというような内容です。

手前味噌になりますが、社内の同僚達はみな優秀です。設計論であったり、プロジェクトの進め方であったり、果ては採用の方法についてもよく考えて改善しようという意思があります。

目に見えるものを全てよくしようという情熱に溢れ、目に見えて日を重ねるごとに良くなっているのがとても伝わってきます。

自分はどちらかというと物事を深く見て、本質は何か、もっといいものはないかと時間をかけながら、思索していく方が好きで、じっくり煮詰めて煮詰めてものにしていくのが好きです。

同僚達の動きは素早く、広くという感じなので、そこに関しては自分が追いつくのは難しいと思います。やっていることを理解し、実践はできますが、彼らより早く、より広く考えるのはきっと向いていないでしょう。

だから、より遅く、より狭く研究する方が、チームに貢献できるのではないかなと思ったりします。また、テーマも今のWeb業界の開発者の中で学ぶ人が少ない方がきっと競争優位はあるのかなとも感じます。

テーマ選定

まだ10年も働いていない若造ですが、テーマは10年、20年と深く追求できるものが良いと考えました。自分は継続することは得意なので、10年ぐらい研究すれば流石に卓越した知識と技量は身につくのではないでしょうか。

一方で自分は飽きっぽいところがあります。デザインを勉強したり、プログラミング言語を勉強したり、スクラムを勉強したり、テーマの興味は割と変わっています。

なので、テーマは全ての分野を包括するぐらい広いものがいいです。広いテーマをやるというよりは抽象度が高ければ高いほどよい。

テストを選んだ理由

その辺りを考えながら自分の得意分野を探していると、テストがいいのかなと思い始めました。テストや品質管理は、実質的に全ての分野を含みます。

ユーザビリティテスト、パフォーマンステスト、保守性テスト、セキュリティテスト、結合テスト、受け入れテストなど。

これなら知識を全て生かせるし、同じ分野を研究する同僚もそう多くないので、きっと専門性を発揮できる分野です。

テストや品質管理の道はとにかく地道です。仕様を洗い出し、推論して、システムを壊す方法をあらゆる角度から考え、仕様が変わればもう一度テストを設計し直します。必要ならバックエンドもフロントエンドのコードも読んで、パターンを全部出します。メモをひたすらとり、構成を図に書きます。アイデアも必要なので1日でテスト設計が終わることはないです。

自分でも開発しながら、最高の品質を目指して徹底的にテストするのは難しいと思います。だからこそ、社内でやる意味があるのではと感じました。

趣味で休日開発している人は社内にいますが、趣味で休日テストしている人は今のところ知りません。

また、テストの分野はE2Eの技術や開発者ツールなど新しく学ぶことも多いですが、視野自体はそこまで時間で変わらないものも多いです。新しい技術と比べて学べば学ぶほど深くできるのも良いです。

コーチングを選んだ理由

これは趣味が一番の理由です。趣味で高校生を教えたりしているのですが、その手段としてコーチングがいいと考えるようになりました。

コーチングというのは知っている人も多いと思いますが、「対話や承認を通じて相手の能力を引き出すコミュニケーション」です。いわゆる「知識を直接相手に伝える」ことを指すティーチングではありません。

率直な実感で言うと、スポーツの世界はコーチの知識、技量の深さがそのまま選手の技量になります。特に小中高の選手は指導者が変わればチームは全く変わります。

また、過去にコーチングをやってみた経験からして、数年しか経験していない選手が数十年やっているコーチと同じレベルの発想まで行くことは絶対にないと言うのが正直な感想でした。

なのですが、最近また本格的に教えるようになって選手は「自分で気づいた技術しか自由に使えない」という実感も出てくるようになりました。

こちらとしては最高のやり方を伝えているつもりでも、それが自由に使えるというか応用のある技術にはならないのです。どうしても劣化コピーになり、これだと競争に勝てるほどのものにはなりません。

また、そもそも強い選手は自我も強いですし、いろんなコーチ、OBなどの話も聞いていて、そもそものガードが硬いなと思うこともあります。聞いているふりをして聞き流されることも多いです。

なので、やはり「自分自身で気づいてもらう」というプロセスを踏まなければきっと卓越した選手に育てるのは難しいのだろうと最近は考え始めました。

社内の仕事に関しても自分はひねくれた人間なのでリーダーになって、プロジェクトを引っ張るということはきっとないでしょう。情熱があり、改善意欲に溢れたエネルギーのある人の方が良いものが作れるでしょう。

そういう時に「今この判断をしたら長期的にはどうなるか」「今考えられる最大のリスクはなにか」「どうして今スクラムをやっているのか」という視野を広げる質問をしたり、「今の改善はとてもいいと思う」と肯定したり、そういった面で気づきを与えれればいいのかなと思います。

社内にこういった役割がとても上手い人はたくさんいますが、意識的に立ち回ることでまた違う側面で価値ができるのかなと考えます。

また今の仕事だと面談・面接に出ることも多く、その時に評価者の立場で質問することが多いです。でも、良いか、悪いか判断するだけの時間は息苦しいので、そういう時に候補者の本質を一緒に考えて、いろんな角度で自分のやったことを見直す時間にできた方が楽しいんだろうなと。

評価するのは終わった後で、面接中は相手の言うことを素直に聞いて、どう感じたのか、なぜ感じたのか、他の視点から見るとどうか、考えの軸は何か、もし時間があれば何が変わるか、と言うようなことにフォーカスするのもありかなとか。

社内ではどちらかというとコーチング反対派も多く、自己開示を嫌ったり、ティーチングも大事ということもあるので、それを受け入れてその上でどういうコーチングだと良いのかを考えてみたいのもあります。

今の所感

テストを学んでみて

JSTQBの本を読んだり、テストの記事を見つけたら社内のSlackに挙げたり、Redditを適当にwatchしたり、本を読んだりしています。TDD、型システム、といった技術面のものもあれば、テスト設計だったり、そもそもテスターの役割とはという原則論まで当然のように広いです。

実務ではとにかくメモを取るようになりました。今の社内ではウォーターフォールと比べると仕様が明文化されていない場合があるので、とにかくメモをとって仕様の漏れはないか、懸念事項はないかを考えるようになりました。

要件定義のミーティングでは、関連する画面はないか、とりうる値のパターンはなにかなどを図に整理して考えるようになりました。

また、視点の切り替えがとても大事だと思っています。アクセシビリティについてテストしながら、コードの設計について見るのは難しいです。

なので最初にテストを設計して、最初は仕様が正しいかをみて、次にありうるパターンを洗い出して、終わればコード品質を見て、最後にアクセシビリティ、セキュリティをみるというように段階を分けています。

はっきりいって時間がとてもかかります。開発モードだとここら辺を納期を理由に少し手を抜くところですが、テストについて学ぶ以上、全身全霊でやる他ないです。テスターと開発者を分けている会社の意味がここにしてようやくわかりました。

当然学び始めたばかりで正直テスト漏れは頻繁にあります。それを他の開発者に指摘されることもあります。今はそれをメモして、テスト観点を増やしたり、チェックリストを増やしたりしています。

完璧とはいきませんが、それ自体が能動的な学びであるので、それはそれで良いのかなと思ったりします。

コーチングを学んでみて

学習方法は同じく本を読んで、要点をまとめて、何人か仮想のクライアントを想定して、質問を考えたりしています。

こちらは面談、面接でやっているぐらいで、候補者の考えはわからないので、実際の効果検証が難しいです。

どちらかというと今は自分自身で検証している感じです。本を読んで、挨拶をする、相手の言葉を言い換えるなどの技法があるのを見て、それをやっている人を探して、それが本当に良いのか自分の心で検証しています。

特に強い人たち、面接が上手い人と同席しながら観察をしていると確かにそういったことをやっていることが多いので、それを見ながら真似しています。

強いていうなら今の会社は振り返りが多いので、そこで気づいたことを率直に伝えたり、いくつか視点を変える質問を使ったりしています。その反応を見ながら、理解を深めている段階です。

というように効果検証は難しいのですが、自分がどういうコミュニケーションをとっているのか、自分はどんな角度で質問を指定いるのかが認識できるので、メタ認識は上手くなった気がします。

趣味でやっている料理、中国語、競技を勉強していて、課題にぶつかった時に自分で自分をコーチングをするのには長けてきました。

そんな段階ですが、全部を統合してみるなら、上手くいきそうな気配は感じているぐらいの感触です。

今後について

テストとコーチングを学び、少しだけ視点が変わって見れなかったものが見れるようにはなってきています。

一方で無限の深さを感じていて、もっと良い質問はないか、もっと考えられるパターンはないかというのに日々気づき、全然足りないというのも同時に感じます。よくよく考えると視野を広くして穴を探すのはテストもコーチングも似ている気はしますね。

そういう意味で10年、20年時間をかける価値はあるぐらいには楽しそうな印象です。

実際的な問題について言えば、自分はテスターでもなく、コーチでもなく、あくまで開発者なので100%コミットするわけにいかないというのは難しいです。テストの視点を持つ開発者であり、コーチの視点を持つメンバーなので。

それはそれで中間の色合いみたいなものがあって、極端に行けば良いというものでもないので、良い塩梅を見つけるしかないのでしょう。Googleもエンジニアとテスターの中間の役割がいると聞きました。

課題としては今は基本的なことしかできていなくて、例えば単体テスト、PRのレビューあたりで工夫しているところですが、全自動E2Eは導入すべきかというテーマになれば本格的に深く研究して、実験するしかないです。

そういう深さを求め始めた時にどうやって学んでいくかとか、テスト分野の中の優先順位みたいなものも出てきそうな気はします。

今後、どうなるのかはっきり言ってわからないですが、出てくる状況に直面した時に素直に悩んで、答えを出して行けたら良いなと思います。

最後に素晴らしい同僚と一緒に働けて、自分の足りないところがわかり、良い面を真似できる今の環境にはとても満足しています。自分もそう言われるように学びを深めて、共有していきたいです。

研究不足の2020年

今年の総括

今年は記事がほとんど書けない年になりましたが、それは単純に外に発信できるだけの研究が進まなかったという単純な理由によります。

さらにその背景には組織体制の変化もありますし、心情の変化もあるように感じます。

会社に提出した目標シートは割と埋めることができたので仕事はしていたはずですが、一方でなぜ書くことがなかったについて弁明します。

当たり前のことを当たり前にやる

今年、特に後半は当たり前のことを当たり前にやるという仕事が多かったです。詳しいことは同僚のブログ記事にあります。

職能横断型スクラム体制になってからのチーム改善活動 - STORES Tech Blog

新しい組織横断型のチームに入って、文化的な衝突があり、そこをどうするのかというのが当面の課題でした。

MTGは週に何回やるか、リリースまでの計画はどうするべきか、スクラムはどう進めていくか、結合テストのスコープはどうするか、そういったことを詰めて、まとめて、実施するという作業をよくやっていました。

ここに特筆すべきことはなく、地道に課題を見つけて、潰して、また見つけるということの繰り返しでした。

改善も過去によかったプラクティスを基準にしてやってみるというやり方で、特段本を読んで研究するということもなかったです。

当たり前のことを当たり前にできていないのであれば、深い研究をしてもそこまでやることは変わらなかったと思います。

社内外を見回して平均点ぐらいにはなったかなというところで、今年は終わりました。なので、過去の貯金を使っただけで、あまり個人の資産は増えていません。

資産を増やすことを目標としているわけでもないので、それはそれでいいのですが、あえて筆をとりたいと思うようなことは少なかったです。

組織の分化と文化

組織全体で見ると今年は分業であったり、チームの分解が進んだ年ではありました。フロントエンドチームはこれまで多くても2チームぐらいに分かれて働いたりしていましたが、今年は4チームになりました。

機能開発するチームが2チーム、ライブラリや開発環境を整備するチーム、あとはマーケティング施策を打つチームでした。機能開発するチームも特徴が異なり、片方のチームは大規模なリファクタリングをやったりしていましたが、自分が所属するもう1つは小改善が多かったです。

チームが分かれたことで特徴が出てきました。TypeScript、OpenAPIあたりに強いチーム、Nuxt.jsやVue.jsに強いチーム、あとはバックエンドを含めた広範なドメインに詳しいチーム（自分たちのチーム）などです。

なので、あえて主体的に研究はしていませんが、組織体制が分かれたことで課題が変わり、興味が絞られたことでフロントエンドチーム全体ではある種の研究が行われたと言えそうです。

ただ、自分たちのチームは会社のドメインに強くなっただけなので、やっぱり書くことはないのですけれど。

片手間にやっていた勉強

研究と言えるレベルまではしてませんが、本自体は一年を通して読み続けていました。よく読んでいたのはデザイン系、アクセシビリティ系、コーチング系、TypeScript系です。

どれも社内で簡単な勉強会をやったりもしましたし、本も何冊か通読はしました。

ただ業務に生きたかと言われるとすごく微妙で、気持ちいいコードやマークアップは書けたと思いますが、質の違いを生み出すレベルではないです。

業務課題としてシンプルな画面が多かったのもありますし、単純に本は読めど、訓練・研究というほど深堀りしてないのが原因なのかなと思います。

どの分野もIT系の文脈で専門的に語られることが少なく、あっても深い考察と洞察があることはさらに少なかったので、自分から研究しない限り、自分のものにするのは難しかったでしょう。

研究について

趣味の方も今年はそこまで深く研究できていないので、研究能力が純粋に今年は低かったというのは言えるのかもしれません。

中国武術に興味を持ち、中国書籍を集めたまではよかったのですが、そこから無駄に日本武術と比較したり、動物の動きと比較したり、動画を集めたり、色々やりすぎたのが敗因でしょう。肝心の中国武術の本質が理解できていないので、独自研究になりすぎました。

Scrapboxも500ページぐらい作りましたが、99%のページは見返すこともなかったので、研究の方法・構造もよくなかったんでしょう。最初の構造が悪いと、そこからどうやってもうまくいかないのはアーキテクチャ論に似ていますね。

流石にこれはまずいと思って、後半は流派を絞り、枝葉の比較研究は捨てて、著名な武術家、研究家の文献に絞りました。また、資料を読むだけでなく、資料を時系列に並べたり、武術家同士の関連図など作りながら、試行錯誤を始めました。

そうするとこの武術家は流派の特徴を受け継ぎつつ、このあたりはこの人が独自で考えたのだろう、というのがはっきり見えるようになりました。それによって捨てていい要訣もわかってきました。

研究の範囲は狭くなり、しかし却って深さが無限になり、研究時間が伸びました。それにより理解が深くなり、効果も少しずつ実感しています。

また、ちょうど研究がうまく行き始めたところで、「独学大全」という本に出会いました。

独学大全 絶対に「学ぶこと」をあきらめたくない人のための55の技法 | 読書猿 |本 | 通販 | Amazon

似ている手法もあるし、知らない手法もありましたが、研究の観点を整理しやすくなったのですごくありがたたかったです。自分は研究しているんだという自信みたいなものもつきました。

過去にメタ研究の分野は科学哲学など色々漁っていたものの、いいものに出会えず、結局「本を読む本」ぐらいしか知らなかったので、助かりました。修士時代にあるともっと嬉しかったかもしれません。

この本の手法を掛け合わせることでもう少し研究がよくなるのかなと思ったりします。

今後のこと

研究自体は昔からやっていたのですが、それを概念にできていなかったり、環境のおかげでたまたまできていることも有ったのでしょう。なので、環境が変わったり、トピックが変わると、研究ができなかったというのがありそうです。

当たり前のことを当たり前にやるようになった後は、卓越したことを為すにはどうすればいいかというのがチームのテーマになると思うので（そうで有って欲しい）、今度こそ個々人の研究スキルが求められる年になるのではという気がします。

そういう時にどういうふうに研究するべきなのか、研究とは何かというのがうっすらわかったので、そういう意味で辛抱の一年だったと言えなくもないのかもしれないです。

さらにメンバーが増えたらどうなるのか、そもそも事業計画的にどこまで研究改善できる時間があるかなど、わからないことも多いですが、現状の認識は書けたので、これを2020年の総括にしたいと思います。

研究することが仕事ではないし、目的ではないのですが、自分の認識を深めるあの時間がすごく好きなんだなと思ったりはしました。

フロントエンドのお仕事

前職のこと

自分は新卒でシステム開発に初めて携わり始めましたが、その会社ではサーバーサイド、フロントエンド、デザイナーという分業はありませんでした。

SE（システムエンジニア）と呼ばれる職種の人が要件定義、設計、デザイン、結合テスト、運用を行っていて、PG（プログラマ）の職種の人が開発と単体テストを行っていました。

部署によってはその境界も曖昧で両方を兼ねている、1人で全てを行っているエンジニアの方もいました。

PCのネイティブアプリ、Webアプリ、VBAフォームと色々なものを作っていましたが、最後の方に作っていたのはWebアプリでした。ここでは上記の役割のほとんどを自分が関わっていました。

その中でも好きだったのはアーキテクチャ設計と技術検証、パフォーマンスの出るSQLを書くことでした。1つの入力に対して、1つの出力が決まる完全性がとても好きでした。

フロントは技術検証ではたくさん触りましたが、デザイン、今でいうところのUI / UXにはほとんど関わっていませんでした。

そのプロジェクトの途中で、こんなに色々やっていて大丈夫かなという不安がありました。その頃の界隈を見ていると、デザイナー、バックエンド、フロントエンド、QA（品質保証）、PM（プロダクトマネージャー）と分業をしていて、圧倒的に専門性があるように見えました。

何でも屋でいると仕事がなくなるかもなぁという感じたところもあり、一度技術力で勝負してみるのもいいかもしれない、そうすれば不安がなくなるだろうと思って、転職しました。

半人前のフロントエンド

募集要項を眺めていてVBAフォーム、Windowのネイティブアプリを評価してくれる会社は少なく、C#のWeb APIを作っている会社も少ないし、引っかかるとすればフロントエンドしかないよなぁと思って、フロントエンドで仕事を探しました。

なんだかんだSPA、TypeScript、Sass、UIコンポーネント、認証認可、パフォーマンス改善、多言語、単体テストは全部触ってたし、いざとなればバックエンドの方が自信あるし、なんとかなるかなぁという目論見でした。

そんなこんなで無事フロントエンド専門になりました。技術力で勝負すると言いつつ、結局設計〜運用まで全部やっているという話はひとまず置いておきます。

1年目は共通コンポーネントの環境を作ったり、ユニットテスト環境を作ったり、リプレースをしたりして、なんだかんだバックエンド時代みたいな仕事が多かったです。

プログラムの全体像を把握して、理想の出力を作っているだけなので、バックエンドのAPIを作ったり、技術検証している時の感覚に似てますね。期待値ぐらいには働いたと思います。

フロントエンドとデザイナー

バックエンドの感覚を引きずったまま、フロントエンドの仕事をしていたわけですが、当然デザイナーと関わります。仕様を頂いたり、そこに対して工数を答えたり、成果物をレビューしてもらったり。

当然デザイナーの方がビジュアルやその裏にある論理には詳しいです。うちのデザイナーはマークアップは書けますし、JSの振る舞いも書ける人もいます。

それを見るとデザイナーがフロントエンドの仕事を兼ねた方が早いのでは、と考えたことも多いです

分業は組織の人数構成と開発体制に寄るよねという元も子もない話になるとは思いますが、少なくとも幾らかはフロントエンド専業の方が強いことがわかってきました。

• 開発環境の整備
• 全体のデータ設計
• パフォーマンス改善
• ブラウザ対応・網羅的なテスト
• 成果計測
• コンポーネント技術を使った設計（フロント技術から見たデザインシステム）
• コンポーネントの状態の表現
• アクセシビリティ
• インタラクションの設計
• どこまで実現可能かという判断と工数の見積もり
• 新しい技術を使った新しいUI
• システム開発でよく使われるUI

上3つは半人前のフロントエンドで書いたようなことですが、その下はフロントエンド専業だからこそできる、やるべきことなのかなと思ったりします。

上でも少し触れましたが共通コンポーネントを作ったのはエンジニアの発案で、これはコードの重複が嫌だったというのが大きな理由でした。

デザイナー的にはそこまで気になっていなかったようですが、コンポーネントの洗い出しをするとやっぱり似たUIが多くてわかりにくいよねという話になって、統一化が始まりました。

あとはインタラクションや状態などは静的なデザインを作ることが多いデザイナーのイメージが掴みにくく、フロントエンドエンジニアの方が提案しやすいように感じました。

また、前職は業務システムを作っていたので大量のデータを一括で扱うUIだったり、業務で使う以上安全に寄せたデザインだったりはよく使っていました。

ここら辺の経験を積めるデザイナーは少ないので、そこも優位性を感じたりします。

フロントエンドと他の開発者

うちの会社であれば、インフラを含めた開発環境の整備するチーム、バックエンドの環境を担当するチームが他にいます。

インフラ系の仕事については全く知識で太刀打ちできていないので、専業したらここまですごいのかと驚かされてばかりです。

アクセス数が増加した時の対応が限りなく俊敏で、あっという間にインフラをスケールさせますし、障害が起きそうな時間を予測して当てたりします。

その他、デプロイの仕組み、セキュリティ対策、権限管理、予算管理、などを全て高いレベルで行っていてとても勉強させてもらっています。

バックエンドチームの中でも、リファクタリング、言語・ライブラリのバージョンアップを専門にするチームもいてここも専門性が高いです。

言語の仕組みをハックして影響調査をしたり、大規模なリファクタリングを広い視点で行ったり、コードのメトリクスを集計したり、専業ではないと厳しいところを感じます。

こうやって仕事を眺めると、全部やる兼業よりもより高いパフォーマンスを出している組織は多いのかなと感じます。

どちらがいいというよりも、そもそも前職では3人とかで開発をすることが多いので、この選択肢をとるのは厳しいということでもあります。

フロントエンドのお仕事

改めてこの分業化でのフロントエンドのお仕事は何かを考えます。

あえて分業しているわけですから、デザイナーやバックエンド、その他のチームがフロントエンドを兼ねた方が効率がいいと思われているようなチームでは存在意義がないことは確かです。

月並みな結論ですが、まず技術を使ったデザイン、ユーザーへの体験への貢献が一番できるのがフロントエンドエンジニアであるべきだと思います。

デザイナーがユーザーへの理想の体験を考えているときに、今できる技術で一番わかりやすいUIは何か、考慮しないといけないことは何か、UI以外の技術でそこを助けることができないか。

マークアップ、JavaScript、CSS、ABテストツール、パフォーマンス計測ツールなどを駆使して、本当に最適な体験が提供できるかどうかを考えるのがフロントエンド専業である意味の1つなのではと思ったりします。

技術で何ができるのかがわかっているのは当然エンジニアなわけですから、そこの想像力はとても大事です。

また振る舞いを書くだけでなく、どこまで体験を許容するのかの判断もフロントの責務だと自分は思います。

どれほどのパフォーマンスなら許容されて、どれぐらいデザインが整合されていれれば良いか、時間内にできるのはどこまでかというのは技術者しか判断できません。

フロントエンドチームでもさらに分業が進めばまた変わると思いますが、専業エンジニアとしての強さというのは考えていきたいところです。

後書き

ずっと半人前のフロントエンドの人間で、最近も組織体制とかマネジメントとかばかり口を突っ込んでいる身ではあるのですが、その中でフロントとしてどう判断すべきかを考えたくて書きました。

世の中に素晴らしいフロントやデザインは溢れているので、それを見て感動しながら、プロダクトをよくするためにその感動を表現できるような専業者でいたいなと思いました。

もちろん、専業であるか、兼業であるかは組織が決めることなので、与えられた場所で与えられた役目を考えて動きたいです。どちらにせよ、どうして今この場所にいるかを忘れずに仕事をしたいです。

Webエンジニアが効率よく成長をするために心がけるべきこと

こんにちは、STORES.jpのUI改善チームに所属する@dexia2です！

普段は文字通りUIを改善したり、古いフレームワークで書かれたページをリプレースしたりしています。

STORES.jp Advent Calendar 2019の4日目は、「Webエンジニアが効率よく成長をするために心がけるべきこと」というテーマについてです。

よく語られるテーマなのでハードルがなかなか高いですが、経験を交えながら頑張って書こうと思います！

要約

• 書を読む際は心を虚しくして、熟読すべし
• 博く学び、問い、思い、弁じ、行うことを通じて、道を明らかにする
• 知っていて行わないのは、知らないということ
• 学の広さと深さを同時に求める

背景

この業界ではWebエンジニアへの要求が日々高まっており、学ぶべき領域は広がり続けています。 目にする情報量は増大し、学べば学ぶほどその広さに愕然します。

そうした背景からWebエンジニアは広く学ぶことへの執着を深め、何を学ぶべきか、新しい技術は何かについて探し続けているように見えます。

しかし、広い情報をいかに学んでいくか、についてよく語られている一方で、深い情報をいかに獲得すべきかについて語られることは少ないように思います。

そこで本稿では、生涯をかけて「いかにして学ぶべきか」を突き詰めた偉大な先人たちの論を振り返りながら、改めて学ぶことについて思索していくことにします。

論拠

中国思想

本稿では中国思想を元に論じていくことにします。
科学偏重の時代にあるからこそ、科学でない哲学体系から学ぶものは大きいですし、自分自身が実践していない哲学の論を述べることは誠実な態度ではないと思うからです。

中国の哲学体系は広範で捉えどころがないですが、本稿ではその中でも朱子学、中庸、陽明学の三つを取り上げます。

中国思想に抵抗がある方は「本を読む本」という書籍があるので、そちらを参考にしてもらえばいいと思います。 こちらは技巧の面から書かれていて、誰でも読みやすいです。

朱子学

朱子学は朱熹（以下、朱子）が成立させた宇宙論まで含んだ巨大な哲学体系です。朱子は南宋の時代にこれまでの中国哲学を省み、それらを統合するという計り知れない偉業を成し遂げました。
したがって、学ぶということに関して朱子より適した人物はいないのではないでしょうか。

中庸

中庸は朱子やその後の論争に当たってよく取り上げられる書の名前です。 成立自体は朱子よりかなり古く、作者もはっきりと確定していませんが、朱子学やその後の論争を振り返る際に中庸を知らずして語るのは難しいように思います。

陽明学

陽明学は王陽明の論述を基に築かれた哲学体系です。 王陽明は元々、朱子学の徒でしたが、朱子学を突き詰めるうちにその限界に突き当たり、それを乗り越えるために新しい学を説きました。これが陽明学です。

本稿では朱子学を中心にした論を展開しますが、あえてそれを批判した陽明学を知ることで、かえって広く思想を理解することができるのではないかと思います。

先人たちの学び方

朱子学

本項では朱子の読書法を通じて、その学び方に触れていきます。

一つの書を徹底して読む

朱子の説く読書では、作者の心が自分に重なるまで徹底して一つの書を読みます。 一文字、一段の意味を追求し、その本がなくても書いてあったことが心に刻まれ、全て口に出して言えるという段階を求めます。

また、知識をひけらかすことをよしとせず、書の伝えんとすることを自分ごとのように理解するように努めます。読書は知識の追求ではなく、自分自身を追求することと捉えます。

「論語」を読むときは「孟子」は存在しないと思いつめ、いたずらに本を読まずに、ひたすら丹念に繰り返し読むのが朱子の読書の特徴です。

心を虚にする

朱子の読書では一つの本をひたすら読むわけですが、その際は心を虚にします。 心を虚にするということは自分の意見を立てず、新説を立てず、著者の心に寸分の狂いもなく従うということです。

理解できないところも一字一字噛みしめながら読み、分かるまで読みます。 全体像がわかっても、詳細を理解するまで細心を払います。

全てを理解する前に自分の意見を先取りしてしまえば、学ぶところがなく、結局何にもならないというのが朱子の主張です。

中庸

中庸は学び方がよくまとまっている一節があり、そこから得るものが多いためそこに絞って紹介します。

学問思弁行

博くこれを学び、審らかにこれを問い、慎みてこれを思い、明らかにこれを弁じ、篤くこれを行なう。

「何事でもひろく学んで知識をひろめ、くわしく綿密に質問し、慎重にわが身について考え、明確に分析して判断し、ていねいにゆきとどいた実行をする」（『大学・中庸』金谷治訳）

中庸の学び方はこれらの学、問、思、弁、行の実践を説いています。 ただ実践するというだけではなく、学んでいないことがあれば十分になるまでやめず、分析していないことがあれば分析し尽くすまでやめないという徹底的な態度です。

朱子の読書は一つの書に集中し、自然に思いが湧いてくるまで読みふけるというものでしたが、中庸では学ぶだけでなく分析的、行動的な態度が強調されています。

とはいえ、それは朱子から見たときの相対的な物の見方であり、中庸自体の考えを素直にとれば、中国哲学らしいバランスを重視した思想という見方ができると思います。 学ぶだけでなく、問うこと、思うことが必要であり、さらに考えるだけでは不十分で、実践までしなくてはいけないというところは五行の思想に通じるものを感じます。

陽明学

先述した通り、王陽明は朱子学を学んでいましたが、その限界に突きあたって新しい学問を開きました。 本稿では朱子学に対抗した陽明学の考えを紹介します。

ただし、陽明学は朱子学の一部を問題にしているだけであって、朱子学の全体を批判しているわけではありません。

知行合一

朱子はどちらかといえば知が先立つことを考えていました。徹底して理を追求し、物事の自然とは何かを悟るまで学んだのちに行動するという態度を徹底していました。

しかし王陽明は自身の経験から、物事の自然は自分自身にあり、それは知の後にくるものではないということを主張しました。 これが有名な知行合一という考え方です。

陽明学の立場からすると、「知るということは必ず行うことに結びつくはずであり、知っていながら行わないというのはまだ知っていないことだ」と主張します。 どんなものでも自分が体験してこそ知ることができ、いかに語ることができたとしても知っているとは言えない、という態度は朱子、中庸の考えと比べてもかなり激しいものです。

事上練磨

知行合一と並んで陽明学でよく取り上げられるのは事上練磨という考え方です。 事上は日々の生活、日々の仕事のことを指し、練磨というのは自分の能力を磨くことを意味します。 これも読書、静坐につとめて学を深めようとした朱子に対抗した学説と捉えることができます。

静かな環境に浸っていても、いざ事に対した時に自分を見失うのであり、むしろ日常の中で培ったものが静かな環境でも生きてくると説きます。 知行合一と合わせて陽明学の行動学的な側面が強く伺えます。

先人たちから何を学ぶべきか

徹底して学ぶ

ここまで朱子学、中庸、陽明学の三つを取り上げましたが、いずれも広く浅く学ぶべきだと説くものはありません。 朱子は徹底した学を、中庸は徹底したバランスを、陽明学は徹底した行動を説いていますが、どれも苛烈で集中した態度を求めています。

学ぶための道筋はいくつかあるとしても、徹底して学ぶ態度がなければ深く道を悟るのは難しいのではないかと思います。

学ぶことに留まらない

中庸あるいは陽明学から朱子学を捉えるなら行動が弱いように見えますが、朱子も書を読むときは自分ごととして読まないといけないと主張しており、決して学だけを尊んでいるわけではありません。

それぞれが、自分の問題として学を捉え、その上でどのように自分を練磨していくかということを問うています。 また、中庸ではその手段として問い、議論、分別も挙げており、知ることは過程のうちの一つに過ぎないという見方をしています。

よって、学を極めようとするなら、知ることを前提としていかに自身を変えていけるかまで追求していく必要があると言えます。

いかにして学んでいくべきか

以上まで、先人たちがいかに学を捉えてきたか、そこから何を学ぶべきかについて論じてきました。 しかし、実際の問題に立ち向かうにあたっては、以上の議論は実践には不十分であり、朱子が論じるところの「自分ごと」として認識を深めなくてはいけません。

本項では、先人たちの学と自分たちの問題を繋げる接点について考えようと思います。

広さと深さの統合

科学から発した学問領域は全ての分野で拡大しており、科学の性質を踏まえれば今後もその傾向が変わることは考えづらいです。 かといって、深さのない学問は用に足らないため、学習者はこの矛盾した要求を成立させなくてはいけません。

矛盾の論理

この矛盾を統合する際にも、中国の哲学思想である陰陽思想が役に立ちます。 以前書いた記事が詳しいですが、端的に書けば「どんな時でも矛盾の関係はなくならないけれども、互いに助け合って存在する」というものです。

広さと深さにこの論理を適用すると、広さと深さは矛盾していますが、かといって広さと深さは独立して存在するものではないということになります。 ここから導かれる結論は、どちらも両立させるように調整し、どちらかを完全に無くしてはいけないということです。

基本的に中国の哲学の底には有りか無しかという二元論ではなく、割合を変えていくという発想が流れています。

初学と老練

具体的にこの問題を解決するにあたって、熟練度による切り分けがあると思います。 特に初学の段階であれば、ひたすら深さだけを追求しても仕事をなすことができないため、広さが要求されます。

そこで最初の段階であれば広く学ぶことを尊びながら、その上で深く学ぶ領域を少しだけ残しておくというのが良いかなと思います。 初学の段階を過ぎれば、そこから広く学ぶことを減らし、深く学ぶ方法を追求していくというのが現実的な解になります。

また、広く学ぶ中でも学、問、思、弁、行を欠かすことはしてはならず、知って終わりということはしないようにします。 ただし、徹底的にやり尽くすのではなく、広さを維持できる程度に行うというバランス感覚が大事です。

何を学ぶべきか

学問領域には深さを追求できるものと追求できないものがあります。 端的に言えば、具体的なものは浅く、抽象的なものは深さを持ちます。

良いコーディングスタイルを何かを知ろうとすれば追求が難しいですが、エンジニアはコードをどのように認知しているかという問いには深さがあります。 あるいはBOTの実装方法はこれまた単純な問題になりますが、良いBOTとは何か、BOTは開発業務をいかにして改善するかという問いを立てれば、深さに限りがありません。

したがって、学を深めるためには高い抽象に取り組み、それを実践していくことが求められています。 高い抽象、すなわち原理原則は科学の方向で論述されることが多いですが、哲学、東洋哲学などの思想領域にも高い抽象は存在します。

そうした学について朱子学、中庸、陽明学の学び方ができれば得ることは甚大になると思います。

STORES.jpはいかにして学んでいるのか

知行合一の重視

STORES.jpは、陽明学を遵守するような立場をとっています。 すなわち、知っていることと行動することに差異がない状態を目指しています。

レビューが溜まりがちだと感じたらすぐにBOTで状態を通知するようにし、テストのやり方がまずいと思えば体系的なテストの方法をすぐに適用するようにします。

行おうとする気持ちと行うことに差がなく、全員が今のこの瞬間を観察し、咄嗟に動いてしまう性格がチームをどれだけ良くしているのか計り知るのは難しいです。

読書会

また具体的な学習方法として、チーム・社内では時折、読書会を行っています。具体的な手順としては、下記のように実施しています。

• 事前に書を読み、問いを立てる
• 当日読み合わせ、問いに対して議論する
• 自分たちを改善するための行動まで落とし込む
• 著者の意図を汲んで改変はせず、できる限りそのまま実行する
• 反省する
• 自分の言葉で経験をまとめ、社内外で発表する

朱子学、中庸、陽明学のいずれの立場から見てもそれなりの学習方法が実践できていると思います。 内容としてはセキュリティだったり、スクラムだったりです。具体的なものもありますが、その中でも抽象的な原理にも着目するようにしています。

課題

陽明学を遵守すると前述したように、STORES.jpは何より実践を重視します。分からないことはやっていないから分からないのだと考えます。

一方で朱子学のような特定の分野に対する徹底した態度にかける面があり、一部ではようやく深い追求が始まりましたが、まだまだ広く浅くという面が残っています。

また、中庸が説くところの「問う、思う」よりも先に行動が来ることがあり、早すぎる行動が目立つように感じています。

よって、現在の学習態度に甘んじず、どうすればより深く学べるのか、背景にある根本原理は何か、についてさらに考え、実践していきたいと思っています。

まとめ

この記事は自分の失敗経験を踏まえて書きました。 以前は広さを求めて、知識と行うことが離れてしまい、学んでいるのに何も学んでいないような状態でした。 学の広さは十分になりましたが、遠くにいるエンジニアと差はまるで埋まらないようでした。

そこから思い直して、深さを求めながら実践を心がけるようにし、議論を行い、それを自分ごとになるまで言葉を練っていくというのを続けました。 幸い、会社の文化もそれに合っていたため、それが実現し、得るものは多大でした。

繰り返しているように、学ぶべき情報は依然として多くなるでしょう。 ゆえに枝葉と幹を見極め、より深い幹を涵養することがWebエンジニアに求められるのではと思います。

以上から、深く学ぶための哲学を理解、実践していくことが、結果的にWebエンジニアが効率よく成長していくことに繋がるのではと考えています。

広告宣伝

今回の記事はどうでしたか？ 少しでも心に響くものがあったなら嬉しいです。

明日のSTORES.jp Advent Calendar 2019の担当は@thamamurです。

楽しみにしていてください！

参考文献

参考文献は以下によりました。

三浦國雄『「朱子語類」抄』

金谷治『大学・中庸』

守屋洋『新釈 伝習録』

要はバランス

背景

なんとなく界隈のなかで「要はバランス」という言葉に好意的でないニュアンスが広がっているような気がします。 自分自身は中国哲学の陰陽理論がとても好きでできる限り発想をそこに寄せている立場なので、「要はバランス」に対して誤解されていることに対して補足を加えたいと思います。

ここでは中国哲学の陰陽理論の解説を以って、バランスとは何か、誤解の元は何かを説きます。

出典

陰陽理論といえば『易経』がもっとも有名な出典ですが、理論自体が中国哲学の一部となっている感があって、色んなところにこの話が出てきます。

自分はどちらかというと武術のなかでそれを見ることが多くて、太極拳の『太極拳論』などを通して陰陽理論を体認しています。

なので、明確な出典から理論を持ち出していないことに注意してください。

あとは似た概念に五行、中庸もありますが、今回は紹介しません。

陰陽理論

すべてのものは陰陽でできている

この理論の基本的な考え方はすべてのものは陰陽でできている捉えます。朝と夜、男と女、火と水、長いと短いなどすべてのものは相対的に逆のものからなります。

例外的なものは存在せず、この陰陽の関係を理解し、助けていくことがこの理論の根本にあります。

動的平衡

陰陽はそれぞれ5:5のような印象を持たれますが、実際には完全な平衡を嫌います。この理論の背景は動的平衡であって、静的平衡ではありません。

陰陽理論の長である『易経』の易という漢字の意味は「変化」であり、絶えることの滔々とした変化を前提にしています。 その変化は陰が強くなればそれを補うように陽が強くなり、陽が強くなれば陰が強くなってそれを支えるというものです。

武術でも重心を5:5で固定することは居つくことになり変化が弱まるため、咎められます。 そのように陰陽の平衡はむしろ陰と陽を明確にするものです。あるときは陽が主で陰が従になり、次の瞬間にはそれが逆になっている、そういう動的な関係性を大事にします。

陰陽相済

すべてのものは陰陽でできていると書いた通り、完全なる陰もなければ完全なる陽も存在しません。陰と陽は支え合っているものです。 また、「陰極まれば陽となり、陽極まれば陰となる」というように互いの基となるものは同じで、陽は陰になるし、陰は陽にも転じます。

したがって、陰と陽は一見対立関係にありますが、一方で補完関係にあります。

他の概念との比較

近い概念にはトレードオフ、アウフヘーベン（止揚、弁証法）がありますが、これらは対立関係に重きを置いているように思います。 対立関係を強調し、それらを解決する第三案を出すという印象で、陰と陽の基は同じものである、動的平衡の中で常に関係性は変わると言ったダイナミックさはないように思います。

とはいえ根本にある原理をみると実用上はそう変わらないように思います。

なぜ誤解されるのか

陰陽の世界に絶対的なものはせず、全ては相対的なものです。具体的なものは全てその時点での陰陽の平衡であって、次の瞬間には別の形で平衡します。 なので、「要はバランス」おじさんになれば、毎回言う事やることが変わります。その時々で判断するのでどうしてもそうなります。

また、バランスという概念はどちらかが強くなればもう片方も強くなる道理があるのですが、なんとなく静的な平衡に捉えられがちなように感じます。 したがって、発展性がない議論、行動に思われがちです。ですが、バランスのない成長はなく、必ず両者が助け合って進んでいくものです。

あるいは今話題になっているのは対立関係を止揚して相補関係であることを発見したという言論ですが、対立するものが完全に相補関係だけになることはありません。必ず対立性・矛盾性が同時に存在します。 意見が割れているのは相補関係を強調する人と、対立関係を強調する人がいるからだと思いますが、それらは同時に存在するものです。

これらの哲学から、自分は「要はバランス」というのは一つの真理を付いていると考えるのですが、それが抽象的で捉えどころのないものだから、正確に認識されていないのではないかと思います。

ただ、自分は数千年続く中国哲学に傾倒していて、それを以って物事を認識しているので、西洋哲学、科学哲学、あるいは他のどこかにもっと素晴らしい哲学体系があって、そこから見ると間違った、偏った認識であることは否定できません。

とはいえ、自分としてはまだ中国哲学の認識が甘いので、もっと原典などに当たりながら認識を深めていけたらいいなと考えています。