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

紺屋高尾

ぬしの女房はんに、わちき、なりたいんざます。来年三月十五日、年季(ねん)が明けるんざます。そのときは眉毛落として歯に鉄漿(かね)染めて、ぬしの傍に参りんすよって、お内儀(かみ)さんにしてくんなますか?

良いチームを作るために

なんだかんだ8年ほど働いてみて、今まで失敗したこと、成功したことを振り返ってみる。

これは私の主観によるものであり、私という人格が極めて限られた環境で行った場合の成功・失敗経験なので、他人が同じことをした場合には、その人の人格や試行した環境によって成否は異なると思われる。

反論・異論は多々あると思うが、取り敢えず書いてみよう。

ソフトウェア開発とは手段であり目的ではないと認識する

我々はなぜソフトウェアを開発するのか? それは、恐らく、世の中にある問題を解決するためだ。 問題解決の手段としてソフトウェアを活用する、ただそれだけである。

ソフトウェアを開発することが目的ではない。 問題解決の最善手はソフトウェアの開発ではないかもしれない。 問題を解決することこそが目的である。 我々エンジニアは、それを真摯に受け止めるべきである。

何故か? 個人の中でソフトウェアの開発こそが目的になってしうことが、往々にして多いからだ。 問題の解決が疎かになり、ソフトウェアの開発こそが目的となってしまう。 そして、進むべき方向性を失ったソフトウェアは存在意義が薄れて、一体なんのためのソフトウェアなのかが誰にも解らなくなっていく。 これは誰にとっても望ましくないであろう。

僕は携わったことはないが、ソフトウェアを開発することそのものが目的となる仕事もあるとは思うが、恐らく一般的にはそうではない。

我々が目的をきちんと共有できることで、今やるべきこと、やらないことが明確になりやすいであろう。

知らないことを責めない、蔑まない

言語・ツール・サービス等々、現在のソフトウェア開発はどんどんと便利になっている。 未だに○○すら知らない・出来ないなんて、、、と誰かに思う、思われることは多々あるだろう。

だがしかし、あなたはチームメンバーにそのような事を表立って言ってはいけない。 態度に表してもいけない。

相手が知らないならば、それを教えてあげよう。 きっとその相手も、あなたが知らないことを知っていて、あなたが相手に教わることだってあるだろう。

これは例えば現代においても、バージョン管理というものを知らず、面倒臭がる人を放置してバージョン管理をやめようという意味ではない。

相手はあなたのチームメンバーなのだから、有益なことは教えてあげよう。

去る勇気をもつ

上述した例では、ある程度チームで○○を使うなど醸成されており、そこに○○を知らない人が入ってきた場合である。

では逆に、あなたがアサインされたチームがバージョン管理すら誰もしらないようなチームだったらどうしたらいいだろうか?

有益性を説き、バージョン管理であったりなんであったりを導入するためにメンバーを説得することになるだろう。

だが、それが全て受け入れて貰えるとは限らない。 何一つ理解してもらえないかもしれない。

そうなれば、そこはおそらくあなたの居場所ではない。 そのチームを去るべきである。 そのチームのレベルが低いとか、低次元とか、そういう話ではない。 ただチームとあなたが合わないだけである。

世の中には解決を待っている問題が無限にある。 そこで腐る暇は、我々にはないのだ。

汚い言葉を使わない

  • 死ね

エンジニアは往々にしてこのような物言いをする。 なぜだろう? 格好いいのだろうか? 私には不明である。

このような物言いをする人に対して、上手く言葉を伝えられない人たちがいる。 自分に対してそのような暴言を吐かれたくない、吐かれた事で恥をかきたくないという人たちだ。

私もその一人である。 自分が作ったもの、提案したものに対して、正面切って「糞」だの「死ね」だの言われて誰が気分よく働けるというのか。

言っている本人は、周りが自分の意見に追随してくれているような錯覚を覚えるであろうが、それは本心からではなく、あなたとの会話を一刻も早く切り上げたいからである(それでプロジェクトがどうなろうと、それ以上にあなたのと関わりあいになりたくないのだ)。

「糞なものを糞と言って何が悪い」という意見もあるだろう。 それはそうだ、糞を糞と呼ぶ自由があなたにはある。

ただ、「糞」「死ね」など汚い言葉を使うような人と関わりあいになりたくない、というのもまた、自由なのである。

「糞」と言わないでちゃんと真摯に接することで、周りの人が気持よく働けるのならば、それはチームとして大前提ではないだろうか。

以上は自分自身が過去にやったこと、やられたことも含む。 今でも全部やれているなんて言えない。 とはいえ、「開発手法」などの前にそもそもな部分で破綻していくチームを自分自身でも経験してきた。 自分への戒めも含めて書いておく。