ソーシャルコーディング時代の非技術者と技術者の関わり方についてちょっと考えをまとめたい。なお、これは「技術によって実現されるなにかをベースに商売をしている団体」という前提のもとで書く。たまたまインフラの一部にGitHubを使っているとかそういうのはここに含めない。また、大きめの企業・団体では数の利をいかしてなんとかこのあたりを解決できてしまったりするので、それもここでは含めない。
昔々、自分がメーカー系の会社に勤めていた頃バグトラッカーやレポジトリ(Perforceだった)などにエンジニア以外の人を入れるのは御法度だった。技術者側からの「わけのわからん注文をされる」「話がかみ合わない」など、納得の理由もある。なにより技術的な素養をもたない人達にとってはこれらのツールを使いこなすことが難しく、閲覧することさえなかなかかなわなかった。こちらもごもっとも。
が、21世紀に入って10年以上過ぎている今日、GitHub等のソーシャルコーディングを可能とするプラットフォームを使っている現場においては非技術者も積極的にコードやドキュメントの状態の閲覧、そして時には自ら介入して意見を言う必要があると思っている。そしてプライベートなプロジェクト等ではそのためにGitHubにアカウントを持つべきだと思う。特に小さいチームにおいては全員がプロジェクトに参加できるようにするべきではないだろうか。自分は100人も200人もいるチームなら別だが、10人、20人のチームであるなら自分達が関わっているプロダクトの開発がどのように行われているのかせめて見える・見るようにするためにGitHub等に積極的に参加するべきだと思っている。
自分がこれを必要と思う理由はいくつかある。
まずは分業文化を避けるためである。ある程度それぞれの部署で自力でどうにでもできる大きさの企業なら分業制は効果があるだろうが、小さいチームでは一蓮托生。全員での密なコミュニケーションを取り、なにが今必要なのかをちゃんと共有する必要がある。非技術者がコードやドキュメントの状況を見られない、というのは「自分はコードには責任を持たない」という気持ちを肯定する意味があると思う。それでは駄目だ。当然実装には関わらないが彼らにも当事者でいてもらわないといけない。営業や顧客対応をしている人達こそがプロダクトの本当の姿を知っているのではないだろうか。彼らこそがエンジニアのケツをひっぱたくべきなのではないだろうか。もちろん、全体の状況を鑑みて取捨選択をしたり、エンジニアを余計な労働から守る人も同時に必要にはなるが、それもまた密なコミュニケーションにより状況を相互理解しあう事が必要だと思ってる。
次にエンジニアの怠慢を避けるためである。これは前の点と根っこは一緒なのだが、自分も含めエンジニアというのはやりたくない機能の実装や修正はとにかく先延ばしにしたい、というのが本音だと思う。たまに意識の高い人もいるが、それは稀であると思う。基本人間怠けたいものだ。プログラムを書いている側というのは自分が書かなければ何も始まらないという圧倒的アドバンテージを持っているため、立ち回り方を間違えなければエンジニア以外の人から見たら信じられないほど怠けることができる。秘密にしてたんだけど、ここではしょうがないのでバラす。僕の元クライアント・元同僚の皆様、僕はあなたたちに気づかれないようにかなり怠けてきました、すみません。ところがソーシャルコーディングプラットフォームを使って可視化することによって、多少鼻の効く非技術者が混ざればこの辺りが圧倒的にやりにくくなる。非技術者が実装して欲しい機能を技術者側から「えー、それはやりたくない…」と言われても、開発の状況をなんとなく見つつもう一歩突っ込めそうなタイミングで突っ込んでみる、ということができるようになるわけだ。
そして最後に自分達の命運がかかっているプロダクトの本当の姿を知ってもらうためだ。営業、運用、みんな自分達のプロダクトがどういう状態なのか知っておくべきだ。問題がある部分やすごくうまくできてる部分。どれも知ってるべきだし、その状況に合わせておのおのの仕事の戦略を変えるべきだ。何もエンジニアはプロダクトをSGUPP(スーパー・グレート・ウルトラ・パーフェクト・プロダクト)レベルに常にしておく必要があるというわけではない。現実とのバランスを取りつつ「ここは手を抜く」「これは駄目駄目だけど、とりあえずの形で実装しておく」などの取捨選択をせざるを得ないだろうし、それが普通だ。でもその状況をチームは共有すべきだ。
もちろんこのような事を実現するためにわざわざGitHubのアカウントを取るのではなく、ミーティング等で共有する、というのはありだろう。だけど俺が共有のための報告を行う場合、相手が開発の状況を何も知らないのなら俺は絶対に話の内容を盛ります。面倒くさい追求を受けたくないから、実害のでない範囲で嘘もつきます。そしてなによりミーティングはみんなの時間と生産性を奪う。昔ならばこの辺りの情報共有をしたかったらレポートに色々まとめないといけなかったのだろうが、2015年である。GitHub等のツールが使える。パーフェクトなツールではなくとも、issueの報告もできればwikiも書ける。コードの統計情報も見えるし、テストが通っているかという状況も見えるし、実装についてのエンジニア同士の喧々囂々も読める。
要はこの手の情報共有をするためのコストが10年くらい前と比べると圧倒的に低くなっている。もはや少なくともGitHub等に参加することによってコードの状況を見る事がコスト増(=損)にはならない。見ない事はマイナスになりえる。
エンジニア達は非技術者達にもっと自分達のやってることを見せるべきだし、非技術者達は恐れずにもっとプロダクトの中身の光と闇に向かい合うべきだと思う。
おまけ。若干違う論点だけど、似たようなトピック:
昔々、自分がメーカー系の会社に勤めていた頃バグトラッカーやレポジトリ(Perforceだった)などにエンジニア以外の人を入れるのは御法度だった。技術者側からの「わけのわからん注文をされる」「話がかみ合わない」など、納得の理由もある。なにより技術的な素養をもたない人達にとってはこれらのツールを使いこなすことが難しく、閲覧することさえなかなかかなわなかった。こちらもごもっとも。
が、21世紀に入って10年以上過ぎている今日、GitHub等のソーシャルコーディングを可能とするプラットフォームを使っている現場においては非技術者も積極的にコードやドキュメントの状態の閲覧、そして時には自ら介入して意見を言う必要があると思っている。そしてプライベートなプロジェクト等ではそのためにGitHubにアカウントを持つべきだと思う。特に小さいチームにおいては全員がプロジェクトに参加できるようにするべきではないだろうか。自分は100人も200人もいるチームなら別だが、10人、20人のチームであるなら自分達が関わっているプロダクトの開発がどのように行われているのかせめて見える・見るようにするためにGitHub等に積極的に参加するべきだと思っている。
自分がこれを必要と思う理由はいくつかある。
まずは分業文化を避けるためである。ある程度それぞれの部署で自力でどうにでもできる大きさの企業なら分業制は効果があるだろうが、小さいチームでは一蓮托生。全員での密なコミュニケーションを取り、なにが今必要なのかをちゃんと共有する必要がある。非技術者がコードやドキュメントの状況を見られない、というのは「自分はコードには責任を持たない」という気持ちを肯定する意味があると思う。それでは駄目だ。当然実装には関わらないが彼らにも当事者でいてもらわないといけない。営業や顧客対応をしている人達こそがプロダクトの本当の姿を知っているのではないだろうか。彼らこそがエンジニアのケツをひっぱたくべきなのではないだろうか。もちろん、全体の状況を鑑みて取捨選択をしたり、エンジニアを余計な労働から守る人も同時に必要にはなるが、それもまた密なコミュニケーションにより状況を相互理解しあう事が必要だと思ってる。
次にエンジニアの怠慢を避けるためである。これは前の点と根っこは一緒なのだが、自分も含めエンジニアというのはやりたくない機能の実装や修正はとにかく先延ばしにしたい、というのが本音だと思う。たまに意識の高い人もいるが、それは稀であると思う。基本人間怠けたいものだ。プログラムを書いている側というのは自分が書かなければ何も始まらないという圧倒的アドバンテージを持っているため、立ち回り方を間違えなければエンジニア以外の人から見たら信じられないほど怠けることができる。秘密にしてたんだけど、ここではしょうがないのでバラす。僕の元クライアント・元同僚の皆様、僕はあなたたちに気づかれないようにかなり怠けてきました、すみません。ところがソーシャルコーディングプラットフォームを使って可視化することによって、多少鼻の効く非技術者が混ざればこの辺りが圧倒的にやりにくくなる。非技術者が実装して欲しい機能を技術者側から「えー、それはやりたくない…」と言われても、開発の状況をなんとなく見つつもう一歩突っ込めそうなタイミングで突っ込んでみる、ということができるようになるわけだ。
そして最後に自分達の命運がかかっているプロダクトの本当の姿を知ってもらうためだ。営業、運用、みんな自分達のプロダクトがどういう状態なのか知っておくべきだ。問題がある部分やすごくうまくできてる部分。どれも知ってるべきだし、その状況に合わせておのおのの仕事の戦略を変えるべきだ。何もエンジニアはプロダクトをSGUPP(スーパー・グレート・ウルトラ・パーフェクト・プロダクト)レベルに常にしておく必要があるというわけではない。現実とのバランスを取りつつ「ここは手を抜く」「これは駄目駄目だけど、とりあえずの形で実装しておく」などの取捨選択をせざるを得ないだろうし、それが普通だ。でもその状況をチームは共有すべきだ。
もちろんこのような事を実現するためにわざわざGitHubのアカウントを取るのではなく、ミーティング等で共有する、というのはありだろう。だけど俺が共有のための報告を行う場合、相手が開発の状況を何も知らないのなら俺は絶対に話の内容を盛ります。面倒くさい追求を受けたくないから、実害のでない範囲で嘘もつきます。そしてなによりミーティングはみんなの時間と生産性を奪う。昔ならばこの辺りの情報共有をしたかったらレポートに色々まとめないといけなかったのだろうが、2015年である。GitHub等のツールが使える。パーフェクトなツールではなくとも、issueの報告もできればwikiも書ける。コードの統計情報も見えるし、テストが通っているかという状況も見えるし、実装についてのエンジニア同士の喧々囂々も読める。
要はこの手の情報共有をするためのコストが10年くらい前と比べると圧倒的に低くなっている。もはや少なくともGitHub等に参加することによってコードの状況を見る事がコスト増(=損)にはならない。見ない事はマイナスになりえる。
エンジニア達は非技術者達にもっと自分達のやってることを見せるべきだし、非技術者達は恐れずにもっとプロダクトの中身の光と闇に向かい合うべきだと思う。
おまけ。若干違う論点だけど、似たようなトピック: