技術memo

関数型ゴースト

チームでのプロダクト開発で私が大事にしたいと思っていること

これはお気持ち文書です。技術的な内容はあまり含みません。

近況、あるいは自己紹介

ねのといいます。日本でソフトウェアエンジニアをやってる32歳です。

2019年秋まで4年ほど名古屋の某社にいて、チームでアジャイルなソフトウェア開発を学び、実践していました。 その後は東京に引越し、某社で自社サービスの開発を1年ほどしています。

また業務以外では、同人音楽サークル(自主制作バンド)で8年ほど継続して活動し、音源リリースや年数回ライブしています。

今回は、ソフトウェア開発だったり、サークル活動での経験から、 チームでのプロダクト開発で上手くやるのに大事だと私が思っていることを書いてみます。

長いから3行で結論

  • ゴール指向でやろう。顧客にとっての価値だけでなく、自分や他の皆それぞれの立場での価値を考えよう。
  • 日常的な言葉の使い方と振舞いが大事。チームの文化をかたちづくるものだから。
  • 繰り返しのルーチンの仕組みを作り、乗っかり、改善していこう。

ということで雑語りいきます。

顧客にとっての価値が大事、でもそれだけじゃない

顧客にとって価値があるものを作らなければ、物は売れません。 どれだけハイスペックな製品を作っても、顧客の困りごとを解消したり、 嬉しさを提供してくれるものでなければ、買って・使ってはもらえません。 だからこそ、何がほしいと思われているのか把握するマーケティングや、 どう伝えるかのデザイン、何を伝えるかのコンセプトが必要になってきます。

プロダクト開発においては、そういった大きな目標、ゴールに対して、 開発するプロダクトが手段として「適している」「適していない」といった評価を常に考えていく必要があります。 要らないものを頑張ってつくっても時間とお金の無駄だからです。 大きなゴールに対して、何をやれば辿りつけるか。 その手段は無数にあり、正解が何かはわからない。あるいは何もかもが不正解になりうる。 そういった問題に取り組むのが開発が開発たる所以です。

目標は分割して、「まずはこのゴールに向かってみる」といった小目標を立てながらこなしていこう。 そういったことは、どこでも言われていることですね。 アジャイル開発の文脈では、たとえば次のようなワードをよく耳にします。

  • 検査と適応
  • 達成可能な(達成できたか判定可能な)ゴール(SMARTゴールなんて有名ですね)
  • 「上手くいかないということを学んでしまった」

つまりのところは、手段を模索しながら、無数に手段を取りうる問題に対して、ゴールを目指していこう、ということだと思っています。

そして大事なのは、ゴールは顧客にとっての価値だけではないということです。

ビジネスとしてのゴールは顧客が決めるかもしれません。 しかし、チームに属してプロダクトを開発する私はどうでしょうか。 あるいはチームメンバーのあの人はどうでしょうか。 何を思って、どういったモチベーションでチームに関わり、仕事をしていきたいと思っているのでしょうか。 あるいは上司、あるいはビジネスに協力して関わってくれる他社さん、様々な個人や法人にも、それぞれのモチベーションがあります。

そういった、それぞれの立場にとってどう嬉しくて、このプロダクトに関わろうとしてくれるのか。 それぞれのモチベーションは、決して無視できるものではありません。 嫌ならただ去ればいいのです。 去ってほしくないのなら、それに見合うメリットや魅力を提示できなければいけないのです。

個人的には「仕事なんて食べていければいい」なんて極端な気持ちはありますが、 それでも深掘りすれば「自分が面白いと思えないものに仕事として大きな労力を費したくはない」といった感情は無視できません。 何を面白いと思うかまでいくと本筋から逸れるので別の機会にしますが。 つまりは「仕事だからやれ」では何も言っていないも同じこと、ということです。嫌なら去るだけです。

プロダクトに関わるさまざまな立場の皆さんは、それぞれの人生を歩んできて、別個の経験をして、それぞれのスキルや価値観を持っています。 それぞれの目線で、プロダクトがどう見えるか、それはまたプロダクトの成功のために必要で重大なレビューの視点にもなるかもしれません。

それぞれの立場の「私にとってのプロダクトの価値」や、「私にとってのプロダクト開発に関わることの価値」を考え、会話すること。 またそもそも、目線や価値観が違うということを認めること。 それが大事かなと思っています。

日常的な言葉の使い方と振舞い

作ったものがどうにもよくないとき、なんだか微妙なとき、フィードバックのしかたには慎重になる必要があります。

もちろんそれを伝えられないのは、プロダクトのレビューとしては今一つです。 よりよいものを作れるはずなのに、そのままになってしまうからです。

伝えるときに、伝え方を間違えると、作ったプロダクトの否定がそのまま実装者を否定することになります。 このあたりは昨今の世の中では「心理的安全」といったワードで言われるものです。 フィードバックは具体的に、どこがどうよくないのかを指摘しましょう。 わからないなら漠然としても仕方ないですが、それでも言語化する努力は惜しむべきではありません。

何かがよくない、それならどう改善していったらいいのか、 否定するだけではなく共に目標を目指して進めることが、チームとして大事と思います。

大事なのはフィードバックだけではありません。普段の言葉遣い、振舞いのすべてです。

言葉遣いは自分の思考を規定し、ときに汚染します。 そして言葉遣いや振舞いは人に移ります。 使う言葉と振る舞いがチームの文化になります。 よいミームを残すも、わるいミームを残すも、普段の日常の、その一挙手一投足によって決まります。

たとえば日常的には、私が気にしているものとして、適当に思いつくものを挙げてみます。

  • 各種ツール(ソース管理だったり、チャットツールだったり)の使い方。何を書き、何を書かないか。どういう粒度か。
  • 言葉遣いでも、特に主語や目的語のサイズ感。たとえば「やはり〇〇言語はクソ」みたいな雑な物言いがあるか。
  • よしあしの理由、どういう価値観における判断かを説明するかどうか。
  • 自分の価値観、よしあしの判断基準。あるいはその自覚と、多様性を許容するかどうか。
  • 何を、どう振り返るか、どういった問題意識を持つか、どう改善しようとするか。
  • 困りごとへの向き合い方。人を責めるか。人を頼れるか。
  • メタな視点や、長期的な視点があるか。その振舞いが1年後・5年後・10年後にどう影響するかという意識があるか。

なんだか抽象的になってしまいましたが、行動や言葉遣いのパターンは様々な場面で、様々な抽象度で見出せるということです。

ルーチンを持つことと、その改善

アジャイル開発の文脈ではよく「定期的なイベントが大事」といった風に言われます。 スクラムなど典型ですが、たとえば1週間といった単位で、 始めに計画、毎日朝会や夕会で状況共有し、最後の日にレビューと振り返り、といった繰り返しをやります。

スクラムなどやっていなくても、たとえば朝9時に出社して、まず今日のやることを仕事上関わる人と会話・共有して、仕事にとりかかり、 昼休憩をして、午後の仕事をして、夕方には報告や情報共有をして、19時ころには退勤する。 そういった習慣を持つ人は多いのではないでしょうか。

ではなぜ繰り返すのでしょうか。それは、いちいち考えなくてよくてラクだからです。 ルーチンは、あると便利で、むしろルーチンなしに生活や仕事は不可能でしょう。

仕事でソフトウェア開発を始めてから数年たって、仕事のルーチンなんて現場で自由に決めていいことが多い、ということに驚きました。 別にミーティングしてもいいししなくてもいい。 まともなプロダクトができあがって納品に間に合えばなんでもいい。 やることの理由は聞くし意味がなさそうなら止めるかもしれないけど、自由にやっていい。 そういった現場は多かったのです。 そもそも上長自身がその現場のルーチンを作る人だったりしますからね。朝会をやると言ったり、日報を書かせたり。

システムに自分自身がパーツとして組込まれるような、業務マニュアルの決まった職種ならどうにもなりません。 でも、ソフトウェア開発者というのはシステムを、業務を作るもの。 自分自身の業務ルーチンを作ってはいけない理由は、あんまりありません。 もちろん、時々はあるのですが。 セキュリティとか、勤怠管理とか、品質管理とか、納品ドキュメントとか、色々と……。

ルーチンはどうやって作り、改善していくのがいいのでしょうか。

達成可能なTry、といった言い方を耳にします。 Tryというのは、「行動を変えてみようと思うもの」ですね。振り返り手法でKPTというものが有名ですが、そのあたりから来ています。

たとえば日常生活で、睡眠時間が足りてないなあと思い、「夜は早寝する」と書道みたいに書いて貼り出しても、 「早寝しなきゃなあ」と思うばかりでぜんぜん早寝できるようにならない、といった経験は誰しもあると思います。

ルーチンにおけるよいTryは、自分でコントロール可能なものを、条件付けられた行動として指示するものだ、と私は思います。 たとえば早寝で言うなら、「23時になったら全てを中断して布団に入る」という形だったら、実現可能かもしれません。 それで何か上手くいかないことがあったなら、そこに対してまたTryを考えればいいのです。 時計に気付かないとか、風呂に入れていないのに布団に入るのが嫌とか、 布団に入っても目が覚醒していて全く寝付けないとか、色々な理由が出てくるかもしれません。 布団でネット小説を読んでいたら毎日午前3時、そんなことをやっていたこともあります。

仕事におけるルーチンも、似たようなものです。 たとえば、チームでの情報連携が上手くいっておらず作業が重複したりするから、毎朝チームでミーティングしよう。そんなものです。 「正解が一つではないもの」を作るのがプロダクト開発ですが、プロダクト開発をやるための業務マニュアルは、あんまりありません。 アジャイル開発とかの分野で、色々な人達が模索しているくらいの、そんなものです。 時にはそういう方法論を借りてきて取り入れるのもいいでしょう。

ルーチンを考えるときに気をつけなければいけないのは、コントロール可能なものは何かということです。 特に、人は自分自身の身体の性質には抗えません。

食べたり寝たりしなければ人は死にます。 労働したら疲れます。 疲れたら判断は鈍ります。 ムカつく人の物言いはムカつきます。

そういった諸々の「どうにもならないこと」を無視して、人に改善要求を押し付けても、何も改善はしないのです。

その他

人との信頼関係が大事と思います。信頼関係なしに、人は動きません。 人は人の普段の言動をよく見ているものです。 約束したことは守る、あるいは誇大な約束をしないこと。 人の価値観や尊厳を否定せず、しかし言うべきことを言えていること。 言葉や振舞いが大事というのは、人との関係作りといったこともあります。

厳しい環境で日々が苦しくても、それでも腐らずにやっていくことは、難しいですが、重大です。 自分にとってその職務に関わる意義・価値を再確認して、納得すること。 納得した上で、それでも苦しいものはガス抜きなり何なりする。 漠然とした不満のなかで日々しんどいと思うよりは、指針を理性で確かめ、感情をメンテナンスすること。 仕事は顧客にとっての価値がベースですが、自分にとって関わっていく価値があるかどうか。自分の人生を大事にするべきです。

といったところで、まとまらない文章ですが、今回はこの辺にしておきます。