多能人材になれ！ソフトウェア開発の職種の壁を攻略〜シンクロ率100％ソフトウェア開発補完計画〜

この記事は プレイドアドベントカレンダー23日目です。

はじめに

私は プレイド のエンジニアの大平 (@Victoria_Peak_) と申します。グーグルとロードバイク、筋トレが大好きです。特技は早起きです。

twitter.com

2019 年も年末に向けて後少しのところ、みなさまどうお過ごしでしょうか？ そろそろ今年の振り返りなどする頃ではないでしょうか。

私の 2019 年はかなりチャレンジングな年となりました。SE・PM キャリアとして7年勤めた野村総合研究所を辞め、プレイドに2018年の7月に転職しました。

PMキャリアからエンジニアキャリアへのレーンチェンジのため、スキルセットは新卒の時と同じゼロになり、業界も SIの基幹システム系 から Web業界のマーケティング周りへと、環境が激変した中でチャレンジした一年となりました。

振り返りの中で、未経験からwebエンジニアとして一年半勤めた中で業務経験から、一つ考察をしてみましたのでこのエントリとしてご紹介したいと思います。

対象読者

• 十数人以上のソフトウェア開発組織に在籍し、環境がすぐに変えられないが自分を適応させたい人
• 自分を磨くことを通して職種の壁を超えたい人
• ポータブルスキルを持ち、どんな環境や会社にいっても自分を適応させたい人
• 職種の壁を感じていて、どうにかしたい人
• ソフトウェア組織の確認・認識合わせの作業に疲弊している人
• 未経験からレーンチェンジをしようとしている人
• ビジネスからエンジニアになろうとしている人
  
  
  

目次

目次は大きくわけて3章構成となっています。 私のエントリは相変わらず長い(今回は1万字)ので、さらっと見たい方は下記で概要をつかみ、見出しを飛ばしながら見ていただければと思います。

• 1.モデリングはソフトウェア開発の共通言語になる
• 2.私たちのソフトウェア開発組織は意思疎通に疲弊させられている
• 3.多能人材で職種の壁を無効化し、私はソフトウェア全能神になる
  
  
  

言葉の定義(職種の壁)

エントリ内で「職種の壁」という言葉がでてきますが、これは「職種と職種の境界」と「職種毎のスキルセットの境界」の意味でつかっています。別の職種の経験がなく、コミュニケーションなどに説明や経験が必要な状態を指します。

1.モデリングはソフトウェア開発の共通言語になる

転職してから一年ほど経った後、業務の経験を昇華させて整理し、9月にモデリングベースでフロントエンド設計を見直した記事を執筆しました。

tech.plaid.co.jp

フロントエンド設計概念の依存関係を整理し直す中の気づきを整理したのですが、この執筆の中でモデリング起点でシステムが構築されることに気づくことができました。

モデリング起点は私のエンジニア活動でのバイブルになりました。モデリングに可能性を感じる日々、その中で年末に向けて仕事やそれ以外でもいろいろな活動の中で模索していきました。

- ブログエントリの反響 〜そして気づき〜

エントリの内容にコメントをもらったり、LTで発表して実際の反応を聞いたりしている中で、ある一つの共通点に気づきました。

私の想像以上にみなさまの職種の境界線に対する関心が高いことです。

要約すると下記のような話が多いように感じました。

仕事をしている中で「プロダクトの今の仕様についてはエンジニアさんの言うことが正しいから」「ここはデザインの範疇だからデザイナーさんに任せよう」

と思いつつも、

「本当にその仕様はそうあるべき？ユーザーを考えたらこうならない？」 「デザインはアートっぽくキレイにするだけじゃなくてプロダクトの使いやすさによせられない？」 「やっぱりもう少しプロダクトの仕組みにも踏み込んで理解したい」 「(聞くのはこわいけれど)分かれば自分の仕事をもっと質を高められるはず」

と思っていたり。

- ビジネス × システム = △ 　デザイン × システム = ？？

やはり私の想像以上に世の中にはまだ職種境界というものが多く存在し、人はその境界を意識し、ストレスを感じているのではないでしょうか。

元々一人で作成するようなものだったソフトウェアは、成果物として大きくなるほど、作業分担化が進みました。

既にビジネスとシステムの関係性については、下記のエンジニアブログにて、私の経験則も踏まえ記載しています。みなさんもご存知の通りビジネスとシステムは密接に関わっており、意識するかと思います。 私もここを経験として知っているからこそ、ビジネスとシステムの役割の壁は壊せると思っていましたし、それに向けての活動をすすめています。

tech.plaid.co.jp

私も9月のエントリのネタになったプレイドでの活動の中で、みなさまと同じように、デザインとシステムに壁を感じていました。

9月のエントリで活動を整理した際に、壁に気づいてからというもの、今度はどうやったらデザインとシステムの壁を超えられるのかを考えるようになりました。

私は日頃からソフトウェア開発では、職種の壁はないと信じているのですが、まだ半信半疑になっていました。

その中であるワークショップに出会うことで確信を得ることになりました。

- OOUI との出会いでデザインとシステムの壁撤廃が確信に変わった。

この確信のきっかけとなったのは弊社のブログでも取り上げられている下記のワークショップです。私もこのワークショップに参加しました。

note.com


前から OOUI には注目していて、弊社のデザイナーの 鈴木さん とはよく会話をしていたのですが、このワークショップを紹介いただき、参加することになりました。

詳細は上記エントリを確認いただきたいのですが、ワークショップの内容は、まさに私が今までやっていたモデリングの内容そのもので、OOUI はモデリングベースで UI を考察する、「構造を起点とするデザイン手法」だと解釈しました。

このワークショップを通して、元々感じていたデザインとシステムの境界を超えるためには、OOUI はとても有効で、デザイナーもエンジニアもモデリングを共通言語として学べば、ソフトウェア開発の可能性をまだまだ広げられると確信を持ちました。


以前から私はビジネス × デザイン × エンジニアの全ての境界線を取り除けば、ソフトウェア開発をより確実に迅速に進めることができるのではと信じてやみませんでした。今回はそれを裏付けるような内容に興奮さえ覚えました。

そのようなことを考えていると、今年の弊社の活動の中でとても良い事例が既に行われていました。下記のアドベントカレンダーを参照いただければと思います。


note.com


このビジネス × デザイン × システムは モデリングベースを共通言語として壁が撤廃できることが確信に変わったところでもう少し考察を進めたいと思います。

今度は組織に目を向け、ソフトウェア開発の組織構成について考察をしてみることにします。ここからは図で段階を追って説明することにします。下記の2点について論じようと思います。

• 2.私たちのソフトウェア開発組織は意思疎通に疲弊させられている
• 3.多能人材で職種の壁を無効化し、私はソフトウェア全能神になる
  
  
  

2.私たちのソフトウェア開発組織は意思疎通に疲弊させられている

私自身あまりソフトウェア開発の歴史は詳しくないのですが、ソフトウェア開発は一つのソフトウェア完成品の成果物を作成するのに、はじめは一エンジニアだけで作成したのが、コードの肥大化と共にいつの間にか役割の分化が進みました。

- 個人のソフトウェア開発

個人のソフトウェア開発

ソフトウェア全能神創世記

まずは最小単位の一人でアプリを作るケースです。 エンジニアが一人で作成するケースがイメージしやすいでしょう。 この段階ではデザインも好きに決めていいですし、ローンチ後のビジネス展開も一人で決められます。 有名なアプリたちもこのようなケースから始まったものは多いのではないでしょうか。 プロダクトが手にとるようにわかり、自分が神様になった感覚ではないでしょうか？

- 少人数チームでのソフトウェア開発(細かい・少量のバケツリレー)

チームのソフトウェア開発

役割分担が始まる。軽く話しながらそれぞれがそれぞれを分担することで開発スピードは上がる。

少人数スタートアップなど、チームでのソフトウェア開発のイメージです。 作業メンバーが分かれるので、作業工程は Vue.js設計地図 でも書いたように、ビジネス → モデリング → デザイン → システムの順で進んでいきます。

役割分担はもちろんビジネスとシステムやモデリングを同じ人がやるケースもありますし、デザインもビジネスの人が書くこともあるでしょう。そこらへんは垣根がありません。出来る人がやるイメージでしょうか。

作業の流れは大まかに左から右に流れ、細かい・少量のタスクのバケツリレー形式でタスクがいったりきたりしています。

プレイドもほぼこのようなチームが複数あるゲリラ組織的なチームになります。ただ組織全体の話になるのでその解説は割愛します。

- 会社のソフトウェア開発(細かい・大量のバケツリレー)

会社のソフトウェア開発

作業コスト・コミュニケーションコストが爆増

これ以上大きくなってくると一つのソフトウェアでも様子が変わってきます。人数が増え、一気に組織的な(十人〜数十人規模など)開発になります。みなさまが会社で開発しているケースがこれがほとんどではないでしょうか。一つの職種が2人以上になった時点でこの概念に入るかと思います。

作業の流れはかわりませんが、バケツリレー(タスク)の量が格段にあがります。バケツリレーの種類も、依頼調整に加えて確認のバケツリレーが多くなってきます。会社としてどのようなシステムにすべきなのかという点で工程間の人々の距離が遠くなり、書面確認などでの間接コストが高くなります。ここらへんはみなさん体感で分かるかと思います。

[ソフトウェアを良くする活動] ＜ [認識を合わせるための間接的な活動] → そして私たちはリスクヘッジに疲弊する

本来効率化のために作業分担しているにも関わらず、職種間で余計なコミュニケーションコストが増えています。 ソフトウェア自体を良くする活動に注力すべきだと思うのですが、 「誰かがいった何かを確認する」ために職種間で認識を合わせる何かのリスクヘッジのために日々追われることになります。

言った言わないを繰り返さないために確認工程は肥大化し、確認用ドキュメントを作り、やっても意味のないようなチェックが横行し、私たちは疲弊していきます。

- 私はソフトウェア開発の時代の揺り戻しをかけたい

機動力を失った開発組織

このように疲弊してしまった組織はソフトウェア開発の機動力を失います。

時代として一人でやっていたシステムは分担化が進み、中〜大規模になることが多くなりました。 感の良い方はお気づきかもしれませんが、単純に作業をするだけではなく、特に会社のソフトウェア(少人数のチームでももちろん)では、人数がここで大きなファクターが存在します。

• 作業工程(見えるバケツリレー)
• 意思疎通(見えないバケツリレー)☆

そうです、意思疎通です。意思疎通は見えていないコストですが、やっかいなことにこの意思疎通はタスクに具現化します。このために私たちの貴重な時間や労力を奪われています。

意思疎通を可視化する

先程お話したように、意思疎通を具現化したものが細かい定義書だったり、確認のメールだったり、打ち合わせだったりします。意思疎通がソフトウェアの本質以外を肥大化させます。

一章で考察してきたようにモデリングは共通言語になります。共通言語にしただけで全てが解決するとは限りません。そうです、役職の壁がハードルになるのです。先程は作業工程のみの図でしたが、ではこの意思疎通を含めたコミュニケーションの相関図を書くと、下記のようになります。

開発のコミュニケーション組織相関図(意思疎通 追加ver)

こちらはモデリングを共通言語にそれぞれがコミュニケーションをとる相関図です。真ん中の相互矢印はメインの意思疎通で、点線は実際のバケツリレー(タスク)となります。開発職種もA,B,Cさんの3職種となります。

意思疎通を撲滅させる

私はより良いソフトウェア開発を考えた時に、今後は一人でソフトウェア開発をしていた前の状態に揺り戻しをかけたいと思っています。規模感が小さくなることはおそらく無いと思いますので、それを保ったままシステムをさも一人で作っているよう(全員Aさん)に近づけたいのです。

開発のコミュニケーション組織相関図(理想)

3. 多能人材で職種の壁を無効化し、私はソフトウェア全能神になる

ではそのような規模が大きくなりがちなシステムを、さも一人で開発する(全員Aさん)ようにはどうすればよいのでしょうか？壁を撤廃するといっても本当にできるのでしょうか？

- 多能人材を目指す

越境ではなく境を無効化する

少なくとも、仮にモデリングを共通言語にしたとしても認識をあわせるコミュニケーションコストは絶対にかかります。では、意思疎通を撲滅させるためにはどうすればよいのでしょうか？現実的な解を模索していきます。

私はそれを自分自身を多能人材にすればいいという発想に至りました。つまり私が全部Aさんになることができればいいのです。

巷ではよく「エンジニアのわたしが○○チームで頑張った、越境した」と聞くことがあります。

それでも確かに素晴らしいと思うのですが、まだそれでは人の意識の壁は超えられていません。私はどんな環境でもソフトウェア開発とそれを取り巻くチームとのシンクロ率100％を目指したいと思っています。

多能人材は「ビジネス・デザイナー・エンジニア。どの職種でもそのシーンで必要な人にリアルタイムで化ける人」です。

この人材像が達成できると、極端にいうと、メインの矢印である職種間の意思疎通が不要になり、役職の壁が無効化され、コミュニケーションコストがゼロに近づきます。それに伴い確認のバケツリレーもなくなります。

なぜかというと

• エンジニアの私がデザイナー(ビジネス)を「見聞き、理解」して「教えてもらいながら」開発する
  

よりも

• エンジニアの私がデザイナー(ビジネス)を「やったことがある」ので「なにを考えているかを手にとるように把握できている」

には圧倒的な差があると思っています。これを目指したいと思っています。

- 環境はすぐには変わらない。自分自身を鍛え、適応させろ

なぜ環境を変えずに自分を変える方向を選択するようになったのか？

組織自体を組み替えたり、という方法もあるでしょう。これは完全に好みと私の生き様に近いのですが、私は転職や複数組織に携わった経験から、会社など他人や環境を変えるのは社歴の浅い人やポジションの関係もありすぐに変えるのは難しい事が多いです。組織自体を変えるにも時間がかかり、必ず変えられるとは限りません。自分を変えるのであればそれよりも遥かに簡単で確度が高いです。

自分が多能になれば、自分がジョインするだけで組織や環境に関係なくソフトウェア開発を一つに補完できると思うし、すぐに効果がでるはずなのです。

なので今回は環境は変えず自分を鍛えて開発適応度を上げていく、という方法で模索していきたいと思います。自分が強くなれば組織を変えられるかもしれない。なので先に自分が強くなる方を選びます。

- どのようなキャリアパスで経験していくのか。(ただし、これは茨の道)

まあ、言うは易く行うは難しです。この人材になるには生半可な継続時間だと達成できないと思っています。私はこれまでも、この先も、長い戦いを覚悟して目指します。 いろいろな人からも無理だとか組織を変えたほうが速いとかという意見も聞くことになるでしょう。でも私は進みます。

先程お話した「ビジネス・デザイナー・エンジニア。どの職種でもそのシーンで必要な人にリアルタイムで化ける人」というのは、それぞれを経験しているからこそリアルタイムに化けられるのです。

そのためにはビジネス、エンジニア、デザイナーをそれぞれ数年は経験することが必要になってきます。

少なくとも私は今の時点でビジネス(PMキャリア)7年 → エンジニア(1.5年)なので理想に近づいてきています。ビジネス × エンジニアのメリットも感じております。

では、どのようにキャリアパスを歩んでいくか、自分の経験を積んでいくかの計画をこれから述べていきます。

- ソフトウェア開発体制の実態

キャリアをどう歩んでいくか

私たちのとりまく環境は実際こうなっており、まずこの図をベースとして表現をしてみました。これからどうやって一つにしていくかを実態に落として考えていきます。

- コミュニケーションするのはリーダー

キャリアをどう歩んでいくか

システムの共通言語はモデリングであると述べました。そのモデリングをつかって、各職種チームとコミュニケーションを取ります。実質はリーダーのような人(図の白抜きの人)を中心に仕様やデザインを検討していくことになるでしょう。

この際先程の大量のバケツリレーが行われるコストがネックになるのですが、これを多能人材は解消することになります。下記の図のように、この人たちをAにすること が目指す方向性となります。

茨の道のゴール

- スタートはメンバーから

茨の道第一歩目

スタートはみなさま新卒時など、よくあるようにこうなります。赤い人のようにメンバーからスタートです。

- 普通はここまで

普通はここまで

普通はそのまま何年か経つとリーダーになり、コミュニケーションの先頭に立つことになります。ビジネスでもいろいろな守備範囲があると思いますので、ビジネスの中で経験を踏んで極めたりして価値を出し、そのまま定年を向かえるのも全然正解です。(エンジニア、デザイナーもしかり)

- メンバーに戻る勇気をもって、あえてレーンを変える

メンバーに戻る勇気をもって、あえてレーンを変える

でも目指す方向は全部Aさんにすることですので、このまま甘んじててはいけません。ここであえてレーンを変えます。メンバーに戻りますし、スキルセットはゼロになりますし、年収は下がるでしょうし、怖いですがやります。私は既にビジネス(SE・PM) から エンジニアになっているので、これは一回クリアしています。私は今この状態です。

- あとは繰り返し

何年か経つとこうなる(Cさん→Aさん)

はい、ここまでくるとわかりますね。あとはこの繰り返しです。

- 最後のレーンチェンジ

最後のレーンチェンジ

ここでもう一回やってみましょう。

- 更に数年でやっとゴール

完成形

はい、これで晴れてBさんもAさんとなり、全てがAさんになりました。ここまできて晴れて「ビジネス・デザイナー・エンジニア。どの職種でもそのシーンで必要な人にリアルタイムで化ける人」多能人材となりました。

こうなったあとのメリットは先程述べたとおりですが、ここまで来た後が本番だと思っています。

正直ちょっとここまでいけるのかどうなのかは自分でもわかりません。挫折してしまうかもしれないし、別の方向にいってしまうかもしれません。 現時点で私の意志は堅く、多能人材に挑戦したいです。私は今2段階目の途中なので、まずはエンジニアをしっかり続けて、CさんをAさんにする活動を続けていきたいと思います。

まとめ

はい、いかがだったでしょうか？年末ですので、今年の振り返りから現状の把握、将来像を考察してみました。みなさまの今後のキャリアのご参考になれば幸いです。 ソフトウェア開発はまだまだ可能性があります。私は今エンジニアという構造の中身の方に身をおいていますが、可能性を感じるその気持ちは日に日に強くなっております。

今回は職種の壁をテーマに執筆しましたが、どうにかしてこの壁を撤廃・攻略し、その一心で今後も活動を続けていきたいと思います。

2019年、みなさまはどのような自分だったでしょうか。 2020年、みなさまはどのような自分にしたいでしょうか。

私もそんな問を自分に問いかけながら年を越したいと思います。

最後までお読みいただきありがとうございました。

P.S. 日々の活動の記録を見たかったり、転職やその他仕事についてご興味がれば下記までよろしくお願いします。

twitter.com www.wantedly.com