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

働く上で手段と目的を考える

概要

エンジニア数人で話をしていたところ、職場を決める際にプログラミング言語は考慮するかしないかについて話をした。 組織によっては「言語に関係なくサービスを良くしたいと考えるエンジニアが欲しい」とする意見があった。 一方、エンジニア側からすると、「仕事に使う道具(言語)にはこだわりたい」とする意見と、「サービスが良ければ、手段(言語)にはこだわらない」とする意見があった。 そこから、働く上で何を目的とするか手段とするかによって、働き方やキャリアの作り方のイメージが異なることが分かった。

組織として求める人

サービスを育てる人として考えた場合には、仕事の内容に対してこだわる人よりもこだわらない人の方が都合がいい。 なぜなら、状況に応じて必要なところへ人を移動させられるからである。 しかし、人によって仕事に応じてスキル差があり、こだわらないとしても仕事の無いように応じてパフォーマンスには差がでる。 それを踏まえても、普段は、仕事Aを100%の速度でやっているけど、仕事Bを70%の速度でもいいからやって欲しいといったときに、 仕事を選ばない人は、違う仕事をしてもらえるので良い。

働く人として求める組織

働く人のこだわりに関しては、人に応じて幅が違っていた。 働く人の意見としては、例えば、「サービスが良ければ言語は選ばないがエンジニアでないと嫌だ」「エンジニアであることは当たり前でPHPを使っている会社は嫌だ」である。 こだわりの幅に応じて、所属する組織を変えたい。エンジニアしかやりたくなくても小さな組織であれば、専業にはなれないことも多い。

開発チームとして分割する場合

スクラムで開発チームとして仕事をする場合について考える。 チームの切り分け方はコンポーネントチーム(サーバ/クライアントのような切り分け方)よりも、フィーチャーチーム(XX機能)といった切り分け方のほうが望ましい。 また、メンバーは単能工よりも多能工の方が望ましく、T型人材のように特定分野の専門性が高く、他の分野も幅広く知っている人であることが望ましいとされている。 チームの切り分け方では、コンポーネントチームだと、それぞれのコンポーネントの足並みを揃えないと仕掛り在庫が多く作られ、意思疎通に失敗するなど作り直しの無駄が発生しやすい。 多能工が居ないと、フィーチャーチームを作っても進捗が遅れている時にフォローできなくなる。 どちらにしても、

マッチング

働く人として最悪のケースを考えると、自分のスキルとは違うスキルが要求される特定技術のコンポーネントチームに所属することではないだろうか。 フィーチャーチームにしておくと、100%マッチした仕事ができないかもしれないが、100%外れることもないし、 他の専門性のある人に教えてもらいながらスキルを伸ばすこともできる。 などを考慮した上で所属する組織を選択したい。