あなたの大切にしたい開発スタイルTOP5は?

いきなりの質問です

「あなたの大切にしたい開発スタイルTOP5は?」

o あなたが開発リーダーだったらどういう開発する?
o どういう開発だったらそこに転職してみたいと思う?

などなど、自分がやりたいと思うこだわりの開発スタイル、五本の指に入るものをぜひ挙げてみてください。

jfluteだと...

って、どんなこと挙げればいいの?ってわからないと思いますので、jfluteだとこうかなっていうのを挙げてみます。

第一位: 概念図によるコミュニケーション
第二位: アーキテクチャデザインの一貫性と開発者への横断的フォロー
第三位: オープンソースへの貢献が推奨される文化
第四位: 勉強会やOJTなどエンジニアの教育が盛んな現場
第五位: ソースコードやDB設計の8割統一感

第一位: 概念図によるコミュニケーション

言葉だけの空中戦を避け、概念図でコミュニケーションがしたいです。

jfluteは、よくこのような図を描きます。(画像リンクです)
http://dbflute.seasar.org/data/model/environment/dbflute-infrastructure-map.png
http://dbflute.seasar.org/data/model/lastaflute/lastaflute-architecture-map.png

上記は、オープンソースフレームワークの図ですが、現場では現場固有の似たような図をよく描いています。全体像を把握したいというのはもちろんのこと、仲間とアーキテクチャ周り実装周りで議論するときは情報交換するときなど、こういった図があるとすごいスムーズに進むのです。指差しながら「これはこうあれはこう」って。

とはいっても詳細な図だと変化についていけず形骸化しやすいです。なので概念図、そこまで大きく変わらないので長持ちしやすいというところですね。概念図を描いて大切にする現場は嬉しいですね。

自分はツールを使いますが、ホワイトボードでも良いですよね。というか、ホワイトボードが座席の近くにある現場は最高です。個人でも持って机に置いておきたいです。

あとER図、概念図と言えるか微妙ですが、リレーションシップを意識してデータの議論したりSQLを書いたりするのに欲しい図です。というか極端な話、ER図がない現場で週5で働くとなったら...別の職場探しますかね(^^。(自分で描いてOKなら描いちゃう...同期の仕組みも含めて)

第二位: アーキテクチャデザインの一貫性と開発者への横断的フォロー

アーキテクチャは答えが一つではありません。なので、デザイン要素がとても強いです。何のリーディングもなく構築していくと、つぎはぎのアーキテクチャができてしまい、全体としてのバランスが崩れてしまいます。

そのバランスをキープするための施策がしっかり存在する現場で働きたいですね。誰かにアーキテクチャデザインを依頼したり、アーキテクチャチームを構成して運営していったりなど。

その施策の中で特に重要になるのは、開発者への横断的フォローです。いくら良いアーキテクチャをデザインしても開発者に浸透しなかったら意味がないので、開発者への情報プッシュ、そして、開発者からの質問やフィードバック、それがスムーズに行われるような組織的な仕組みが欠かせません。

ということで jflute は、実際にアーキテクチャデザイナーとして全体バランスの判断をしたり、アーキテクチャチームのリーダーになって運営していったり、運営のアドバイザーをしたり、色々な現場で様々な形で推進していっています。チャットやチケットで質問箱・相談窓口みたいなのを作って、ディベロッパーへの仕組み周りの直接支援なども行っています。

開発者「これどうしたらいいんだろう...?誰も相談する人いないし、いいや勝手にこうやっちゃおう」

開発者を置いてけぼりにしないアーキテクチャにしたいですね。

第三位: オープンソースへの貢献が推奨される文化

オープンソースプログラマーですから、オープンソースに関わってプログラミングしていきたいというのもありますが...

オープンソースというのは、ユーザーである企業がそれぞれ少しずつ貢献をしていかなければ成り立たないものです。オープンソース貢献しないというのは、回り回って企業にとってもデメリットになります。一方で、企業の採用ブランドという面から、オープンソースへの貢献というのはプラスになります。

使っているオープンソースにバグや不足があって、無理矢理な回避や改善をするのくらいなら、本家にプルリクを作って改善したり、本家のコミッターとやり取りをして直してもらったり(その代わりテストを手伝ったり)、何かしらのフィードバックが堂々と業務として行える文化。

使っているオープンソースを勉強会などやSNSで堂々と語ることができる文化。社内で作った汎用ライブラリをオープンソースとして公開・コントリビュートできる文化。使っているオープンソースのコミッターを顧問として迎える文化。

「えっ、それ当たり前じゃん」って思われてる方もいらっしゃると思いますが、そうじゃない現場もまだまだ多いでしょう。

第四位: 勉強会やOJTなどエンジニアの教育が盛んな現場

普段からスキルアップのための定期的な勉強会を業務として開催することができる。業務の中で必要だなと思った時点で、気軽に勉強会を開催することができる。新人や中途やパートナーなどプロジェクトに新規参画された方への導入支援の研修もしくはOJTを業務として堂々と実施できる。

jfluteは実際に、毎週のように何かしらプログラミングやフレームワーク関連の勉強会を開いています。突発的に業務で必要になった知識などを臨機に勉強会で伝えたりしています。

また、新しく参画される方に導入支援の研修を二週間ほど(現場によって日数に違いはありますが)実施して、そのプロジェクトで使っているツールやコードに対するポリシーなどを伝えると同時に、いま一度スキルアップしてもらうために強いレビューをさせて頂いています(^^。(現場からは新しい人に基本的なフォローつどつどしなくて良いので助かるという声を頂いています)

それが巡って会社の強さになることを理解してもらえる現場で働きたいですね。

第五位: ソースコードやDB設計の8割統一感

コードの統一性のバランスって常に議論の的ですが、やはり8割の統一感は欲しいと考えます。会社で書いているコードである限り、別の人が続きの実装をする可能性があるわけです。(あちらこちらで実装の方向性がバラバラな現場で開発していくとストレスが溜まってしまいそうで)

かといって10割 (100%) の統一というのは現実的ではありません。実装ポリシー自体が完璧ではないからギャップが生まれがちです。ある程度ケースバイケースを配慮して、8割統一感というところです。それもバランス難しいですけどね。諦めて0割よりは8割にチャレンジ。

最低限のレベルのものはできるだけ自動化したいですね。コードフォーマッター、IDEの警告設定、checkstyleなど、現場フィットな調整をした上で漏れなく横展開できるように。合わないときがあったら設定自体を気軽につど修正して展開していける体制も必要です。もちろん、自動化できないようなものは、コードレビューで指摘・議論できるように。(レビュー文化)

コードだけではないですね。代表的なのはDB設計。最低限のレベルのものは DBFlute の SchemaPolicyCheck で自動化、あとはレビューで指摘・議論。「かたち」ってやはり大事なんですよね。

その価値観を伝えてみる

さて、jfluteで言うと、このようなところです。

大切にしたいことを、そのまま実践して実現してたり、元々にその価値観の合う現場を選んでたり、逆に現場に影響されてそう考えてたり、まだ道半ばなものもあったり、まあ様々ですね。

これが正しいとかじゃなくて「大切にしたい」ということです。もちろん、自分の考えとして正しいと思ってるから大切にしたい、ということでもありますが、それ自体が証明できませんから究極は「半分好み」でOKですし、あと自分自身が主に関わっている現場がどうしても前提になりますので、現場が変われば内容も変わってくるかもしれませんが別にそれでもOK。主観も含めての「大切にしたい」です。

もっと露骨なものもありましたが...

o MacBook選べないとぅ (メモリは16GBないとぅ)
o テストデータがしっかり整備さていること...
o 社内のフリースペースで作業が...
o コンパイルセーフを最大限活かした仕組みで...
o ディベロッパーもフレームワークをある程度理解した上で...

人によっては「何言語じゃないと絶対に」とか「エディターは自由じゃないと絶対に」とかあるかもしれませんよね笑。

まあ、挙げ始めると30個くらいでてくると思います。単に、あえてTOP5として強く主張したいものは?というところで、その順位も価値観の一つですよね。

その価値観、チームのメンバーに伝えてみませんか?

枝葉の平行線

チームで「Aにする?Bにする?」という技術的な議論が発生した時、当然意見は割れたりします。建設的な議論でその現場の答えを出せば良いだけですが、けっこう不毛な平行性にもなりがちです。

その不毛なときというのは、大抵「枝葉の選択肢」のことが多いと感じます。その A or B 以前に、そもそもその根底にある S と T の価値観が全然違くて、それが A と B の違いの原因なっていたり。

例えば、ER図というところで言うと、ER図にリレーションシップのカーディナリティのセカンドレベル (と勝手に呼んでいますが... 1:1 だけじゃなく 1:0..1 の有無表現) もしっかり表現していこうという提案があったとします。

提案したseaさんに対して、landさんは「いや、そこは自動で同期できないから間違う可能性もあって余計に紛らわしいんじゃないか?」という反対意見。

seaさんは「レビュー文化しっかりあるのでそんなにひどいことにはならない、間違いがあったらそのとき直せば良いかなと」とフォロー。

landさんは「そもそもセカンドレベルが表現されてても便利かな?なくても開発には困らない、みんな各自判断すればいい」と別角度で反論。

seaさんは「いや、有無の判断ミスでときどきバグも起きるし、ER図でDB把握するときに有無もあった方がわかりやすい」

landさんは「有無の判断ミスこそレビューでしっかり担保するようにしたらどうだろう?あと、業務理解の共有会をやるとか」と別角度で反論。

これたぶんラチあかないですよね。そして実は、seaさんは「ER図を大切にしてER図でDBを把握する開発スタイル」に対して、landさんは「ER図はあまり見ず(なくてもいい)、ドキュメント作業を極力減らす開発スタイル」だったなんてことも...。(これは完全にフィクションです)

根本の価値観が違うから、枝葉の選択肢で永遠にすれ違ってしまいます。

もはやどっちが良いって証明はできません。多くのことが社会実験でもしない限り優劣を証明することはできません。なので、結局「そのチームの中のメンバーが何かを大切にしたいのか?」次第です。

枝葉で平行性をひたすら辿ってしまうくらいなら、根本でしっかり議論した方が良いです。根本で意識合わせができれば、そもそも枝葉は自動的に答えが決まりやすいです。当然、根本でも意見は割れるでしょうが、枝葉よりは先の見える議論になる可能性が高いです。

上記のseaさんとlandさんはまだ全然マシかもしれません。堂々と議論してますからね。上記のような議論が、無言で行われることの方が多いかもしれません(暗黙の平行線)。議論は疲れますので避けようとする人が多いでしょう。互いにムードで牽制し合って提案が挙がらない、改善が何も進まない。たぶん、その方が多いかも。あと、本人同士では議論せず、身近な人にだけ愚痴のように主張するだけとか...。

【追記】そういえばこのようなブログも書いていました:
何を大事にしたいのか?があるから判断と行動ができる

価値観の情報交換

ゆえに、そういった価値観をチームメンバー同士で共有し合うってのが大切だなと思ったのです。それですべてが解決するとは思えませんが、平行線でくすぶるよりは大切にしたいことをオープンにして互いを理解し合えた方が妥協案も見えやすいかも。

jfluteは、アーキテクトチームのファシリテーターをやることが多いですが、チーム構成したときにやってみたいなと考えています(今からでも!?)。これまでも会話の中から根本を抽出するってのをアドリブでやっていましたが、アーキテクトチームが価値観バラバラだとディベロッパーは迷いまくりますから大切だなと思ったのです。(特にアーキテクトになる人はこだわり強い傾向にありますから)

アーキテクトチームと言わず、とにかく開発してるメンバーみんなで出してみると色々とわかっておもしろいんじゃないかとも思います。人のそういうのってあまり聞くチャンスないでしょうし、自分のそういうのを言葉にすることもあまりないでしょうから、単純に整理整頓にもなります。勉強になると思いますよ。

価値観の勇気

ただ、勇気は少し必要かもしれませんね。価値観をさらすと「あれこれ言われるんじゃないか?」「見下されるんじゃないか?」って思いがブレーキをかけてしまうものです。こうネット上に公開しているjfluteはなおさらそうです。でもKYだから「まあいいや」って笑。

それでも、要件も技術も多様化していますので開発も多様化しています。なので、互いがちょっと勇気を出して伝えてみることで、成り行きの選択ではなく、本当の「自分たちの選択」ができるようになるんじゃないかと思って。

逆に、他の人が価値観を伝えてくれた時は、勇気を出してくれていますから、つまり、あなたを信頼してくれていますから、気分を悪くするような言葉を投げかけないようにですね。反対意見を言う時も、建設的な議論として、スマートに。

このブログ自体も、開発スタイルの一つかも?

みなさんはどうですか?

開発スタイルというのが曖昧で、本当はもっと分類できるような気がします。「開発環境(ツール)」「開発組織」「オフィス環境」「開発の進め方」とか。あと、「最低限のこと」と「理想的なこと」と言う風にも分けられるかもしれません。

ただ、いったん余白をいっぱい持たせて、シンプルに「開発スタイル」という言葉から思い付くものを自由に発想してもらった方が、スコープも広がって多様なものが挙がってくるかなとも思いまして、ひとまずは。分類の垣根を越えての優先度も見えてくるかもしれませんし。

ちょっと、「そうだなぁ、自分は...」って考えてみて頂けたら幸いです(^^

f:id:jflute:20170925123221j:plain