読者です 読者をやめる 読者になる 読者になる

seri::diary

プログラミングのこととかポエムとか

ハイコンテクストな仕事とローコンテクストな仕事

ポエム

追記

書いてからしばらくして読み返してみたら「ハイコンテクスト」と「ローコンテクスト」の使い方逆じゃないのかもしれないと思った。「仕事の成果を説明する」ためにハイコンテクスト文化の中で技術的な要件は抜きに、実現するビジネス要件だけの説明が求められる仕事と、ローコンテクストな文化で技術的に細かいところまでかなり突っ込んで説明が求められる仕事、という意味合いで分けたつもりだったが、「要件が細かく決められる」とかそういう観点だと意味が逆転するような気がした。いずれにせよ日本語に存在しない概念は使うもんじゃないと反省した…

以下本文↓


自社サービス会社のエンジニアがやるのはだいたいハイコンテクストな仕事のような気がする。私だけだろうか?

少なくとも私が今まで仕事で携わってきた仕事はすべてが「特定のビジネスに特化したシステム」だった。つまり、Aサービスを動かすためのシステム、B企業の社内だけで使われる業務システム、とかそんな感じだ。

そういう仕事で作るwebアプリなりバッチなり画面なりは特定のビジネスモデルとか業界の慣習に特化しており、そういった要素に関連するコンテクストが多分に盛り込まれる。プログラムのソースには業界用語もたくさん含まれてくる(余談だがRestaurantのスペルを正確に綴れるようになったのは飲食業界向けの仕事をするようになってからである)。

ハイコンテクストな仕事において、ビジネス要件は常に毎回異なる。全く同じものを2個作るほど余裕がないというのもあるしそもそも無駄なので我々エンジニアは概ね反対するのだが、サービス開発の場合、要件には常に新しいビジネスモデルや機能が反映される。 その要件を噛み砕いて、予算・スケジュール・人的リソースなど、いろいろなものをパズルのように組み合わせて開発していく。それがハイコンテクストな仕事の特徴といったところか。

時に、知り合いのとあるエンジニアが「サーバーサイドの仕事はDBとjsonを変換する仕事」と言っていた。

REST APIを実装する場合、極論すればそうなのかもしれない。 もちろん、どういうレコードを取得してどのようにjsonを作るかというビジネスロジックは毎回異なるし、やるべきテスト内容も変わってくるわでなんだかんだで毎回苦労しながら実装している。 だから、個人的には毎回違うことをやっているなと思っていたのだが、見え方によってはDBとjsonを変換している、というシンプルな言葉で表現することもできるのかもしれない。

逆に、シンプルな言葉で表現されない、複雑で変化の多いエンジニアの仕事はなんだろうか。

自分の少ない経験から考えると、真っ先に思いつくのは研究職。それこそメーカーの研究所で開発しているような人たちは、コンテクストのレベルは様々だろうが、少なくとも特定の問題だけでなくローコンテクストな普遍的な問題も取り扱っている気がする。

この場合、求められるスキルは、誰かから与えられる要件を噛み砕いてそれを実装するスキルよりは、自分で問題を定義して、その問題を解くためにあれやこれやのアプローチをして解決していくスキルのような気がしていて、それは多分自分がやっている仕事の仕方とはだいぶ違うんだろうなぁということはなんとなく想像がつく。

考えてみれば自分はそういうローコンテクストな仕事をしたことがなかった。すべて誰かに決められた要件に従って開発をしてきた。

  • 横顔でも人物を特定できる顔認識アルゴリズムを考える
  • 特定の匂いをデジタルデータ化してまったく違う場所で再現する方法を考える
  • 大量のデータをほぼリアルタイムに処理する分散処理基盤のアーキテクチャを考える(Apache sparkがすでにあるやんというのは置いといて)
  • AWSVPCのようなprivateなネットワークでの利用に限定したlinuxサーバ間のデータ通信に特化した効率的なネットワークプロトコルを考える
  • 現代のマルチコアで大容量キャッシュを積んだCPUアーキテクチャに最適化するコンパイラを開発する
  • 大量のjsonをやり取りすることに特化した新しい通信プロトコルを考える

というような比較的ローコンテクストでいろいろなアプローチが考えられるような仕事をすると、一体どういう世界が見えるのだろうか。 いつかはそういう仕事もしてみたいが、コンピュータサイエンスの学位すら持ってない自分にできるのだろうかという一抹の不安はありつつも、一方でいくらでも勉強するための資料はあるので余暇の時間の独学でなんとか突破できないかということもいろいろ考えている。