非IT業界だった僕がIT業界に飛び込んでからの3年間のお話
誰にでも「あの時期は変化が激しかった」「本当に悩んだ時期だった」という時期があると思います。
僕にとっては2017年1月〜現在（2020年2月）までの3年間がそれに当てはまり、非常に悩みと学びと変化の激しい時間だったので、改めてここに残したいと思います。
めちゃくちゃ参考になる知見が書かれているわけではなく、「そういえばこんなことがあったなぁ」「こんな失敗したなぁ」という内容なので、経験を積まれている方からしたら「なんだ何もできてないじゃん」と思われるかも。
同じ様に思い切ってIT業界へ飛び込んでみたけど悩んでいる方にとって、勇気が出るまでは行かないだろうが、こんな人もいるんだ〜頑張ろう〜とか思ってもらえたら嬉しい。
2017年、27歳
はじまり
自分はまだIT業界に飛び込んだばかりの新人だった。いまでも新人だけど。 （それまでは新卒入社した小さな会社で何でも屋さんをやっていたのだが、そこから転職に至るまではまた別のお話で）
ディレクター*1として入社したものの、ソフトウェア開発はどのように進んでいくもので、どんな役割の人が関わり、どんな問題が起こるのかなど、全てが未知の世界だった。
よく採用されたなぁとは思うが、CEO曰わく、「そこら辺は後からどうとでもキャッチアップできるけど、そんなことではなく人柄がマッチした」らしい。ありがたい。
幸いなことにその会社はみな素晴らしいスキルの方が集まっていたので、教えて貰いながらディレクター業務をこなしていくことができた。
とにかく、2017年春時点の僕はITド素人だった。そして、最初の1年はほとんどが失敗であり学びの連続であった。
記念すべき初プロジェクト（17年1月 〜 5月）
やっていたこと
- プロジェクトのキャッチアップ
- ソフトウェア開発ってそもそもどうすんの？を理解
- テストケース作成、テスト、バグ起票、修正確認
別のディレクターが元々担当していたプロジェクトで、開発も終盤を迎えていたので、キャッチアップ兼ねてテストを担当することになった。 （いま思えば良くも悪くもスタートアップ感溢れるテストだったなぁと思う）
ここから、怒涛の日々が幕を開けた。
キャッチアップが異常に大変
「Issueが仕様」とは良く言ったものだというか、Issue（Githubにおけるチケットのこと）にわかりやすく書いてあればまだ良かった。
基本、Issueのコメント欄の会話で仕様決定までが行われていたので、全ての文章を時系列で追いながら読解する必要があった。
また、一つのIssueのコメント欄だけでは完結しないことも多々あったので、複数Issueを彷徨いながら把握して、何が最新で正しいかを確認する必要があった。
更に、完結しているように見えて実は別Issueで変更になっていることもあるため、キャッチアップが非常に難儀だったことを覚えている。
「前任のディレクターさんとか、わかる人に聞いては？」という意見もあると思うので予め補足しておくと、誰も正確には把握していなかったのでIssueコメントを見るしか無いという状況だった。結果、多分入社2〜3週間後の僕が一番理解していた。
どうにかリリースはできたのだが、全体を見据えた仕様になっていなかったこともあり、仕様と仕様が殴り合った結果の悲しき不具合というか負の仕様は多々埋蔵されている。
学び
- スタートアップでは「誰の責任」とか言ってる余裕はない（そう言いたい訳じゃない）。実際、その瞬間瞬間で全員が全力を尽くしているが、どうしても優先度が低いことが後回しにされているので、自分ごととして、やるべきことに全力を尽くすことが必要だと強く感じた。
- みんな忙しいが、自分はどうやら忙しさに対するストレス耐性は人よりちょっと高いかもとわかった。
- Issue（チケット）のコメント欄に仕様を書くべきではない。
- 仕様は文章で書くべきではない。
- 複雑な仕様は避けるべき。
- 必要ではないことなら入れ込まない。
大規模開発案件にjoin！（17年3月 〜 12月）
やっていたこと
- プロジェクトのキャッチアップ
- Prottでプロトタイプ作成、レビューを経てブラッシュアップ
- 要件定義
- ステークホルダー（社外に複数）との調整諸々
- テストケース作成、テスト、バグ起票、修正確認
大手企業複数社が合同で進めるプロジェクトが既に動いており、こちらも途中で上司から引き継ぐ形で加わることになった。
前回の反省を活かし、仕様は各Issue冒頭のディスクリプション欄にまとめることにした。（当時はコンフルエンスなどのサービスも使ってなかった） また、極力箇条書きで、正しいワードを用い、簡潔な表記になるよう心がけた。
結果、エンジニアさん、デザイナーさんとのやり取りは比較的スムーズに進み、実装前やデモの際に問題に気づきやすくなり、低コストで修正できるようになった。 （背景の異なるステークホルダーが多くいたため、どうしても複雑な実装を避けられないところも多々あったが…）
そのため、「開発自体は」概ね問題なく進んでいると言えた。
…が、プロジェクト終盤、とある別の事情で正式リリースされずクローズした。 その話は非常に複雑なためここでは割愛する。
学び
- 仕様をIssue冒頭に箇条書き・正しいワード・簡潔な表記で記載するのは結構やりやすい。が、後で探すときにやはり苦労する。どこか「確実にそこを見れば分かる」場所があると便利
- リリースまでに必要な作業を洗い出し、不確実かつ影響がでかいものがあれば、開発関係無いところでもまずそこをわかるようにすべし（今回の原因は概ねそれ）
- MVPといえども実装するならコストがかかる。ペーパープロトタイプを活用せよ（多くのステークホルダーの確認・修正が必要な場合は特に役立つ）
- ユーザ視点で考えよ（そうじゃない場合、なるほどこうなるのかと大変勉強になった）
恒例！サービスのリニューアルプロジェクト！（17年6月 〜 18年10月）
やっていたこと
- Prottを用いた仮説検証
- 要件定義
- Sketchを用いたデザイン作成
- 進行管理
- テストケース作成、テスト、バグ起票、修正確認
- なんちゃってスクラムマスター
多くの会社で既存サービスのリニューアルが行われていると思うが、例に漏れず当時の会社でもリニューアルを実施することになった。
やると決まったときは、「こんなにも楽しそうなことをやれるなんて！」と思った。いや、実際にめちゃくちゃ楽しかったが、同時に同じくらい辛さもあった。
野放しにしてしまったややこしい体制
一大プロジェクトということもあり、全リソースがそこへ注ぎ込まれた。 結果、ディレクター2.5名体制（1名、常には関わらない人がいた）になった。
また、小さい会社でもあり予算も無かったのでデザイナーは専任で置かず、ディレクターがデザイン（ワイヤーとかじゃなく）作成を実施することになった。
このとき、事前に諸々のガイドライン（ボタンの文言は「〜する」、フォームのエラーはこんな感じで出す、仕様はこんな書き方をする、どこに書くetc）を定めたり、誰にどんな役割を期待しているかを明確にしたり、各々の作業の見える化にも取り組めていれば…と後から思うが、そうはできていなかった。
では、できていないとどんなことが起こったのか？
起こった問題
まず、機能や画面ごとに仕様が、担当したディレクターごとでバラバラになった。
影響がちょっとした見た目のみにとどまれば「うん…まぁ…」という感じだったが、ロジックも互いを考慮せず作られた部分があったので、知らなかったことで余計な手間が発生したり、既に完成していたはずの機能がおかしくなるなんてこともあった。
また、デザイン未経験者が勉強しながら作りあげていき、見栄え自体はなんとか世に出せるレベルのものにはなり（デザイナーさんごめんなさい…）、序盤は「お、案外行けるな」とか思っていたが、中盤以降問題が発生した…というより元々あった問題が顕在化してきた。
例えば、ボタンやフォームなど他の画面でも使える部品はコンポーネントとして登録して再利用できるように作るのが当然だが、そうなっていなかった（正確には、やってはいたのだが下手すぎて結局再利用しにくかった）。
そのため、ちょっとした変更が入るたびにデザイン更新に数時間かかったり、新たな画面を作るときにどの部品を使うべきかの確認が非常に難儀だったりした。
他には、人によって他者に期待することが異なったことでの問題もあった。
WhyとWhat、つまり、「何故この対応が必要で、どんな画面でどんなことを成し遂げたいか？」を明確に伝えるだけで良いよ！という人もいれば、使用するAPIも全てリストアップして使い方を示し、ライブラリもどの様に使うかまで指定してね！タスクも全て事前に洗い出しておいてね！という人もおり、すり合わせも難航したため結局最後まで曖昧なまま進んでしまった。
いまとなっては、やはり先ず状況の見える化がなってなかったと痛感している。
状況が透明になったうえで、「チームとして」最も問題となっている箇所、ボトルネックを見つけ、「チームとして一丸となって」立ち向かえたら良かったと。
ただ、その経験をしていたことで、状況に応じて臨機応変な対応をとれる引き出しが増築されたんだろうなぁと思う。
蜃気楼の様に遠ざかる着地見込み
プロジェクト始動時はだいたいのスケジュール感を出すためにざっくりとした見積もりを取りますよね、僕たちも取りましたとも。
そして、はじめの見積もりは特にブレるらしいということも聞いていたので、1.3倍してスケジュールに落とし込んでいた。
その時の予定では確か半年以内で完了する計画だったと思う。
が、実際はリリースまでに1年半ほど要した。約300%に膨れ上がった訳だ。
（不確実性コーン的には、起こりうる可能性の範囲内に収まっているのでそう突拍子もない話ではないんだろうな）
何があったのか？
まず、実装が進むごとに、どんどんどんどん新たなことがわかってくる。
（これも実装しないといけない、これは非常に難易度が高い、このままだとユーザに価値が届けられないから変更せねば…etc）
それらを入れ込んで行くと、当然ゴールは徐々に遠ざかっていく。
また、予定外の作業が定期的に必ず発生する。
内容はといえば、別プロジェクトの優先度が高まったために2~3ヶ月は数名がそちらへ掛かりっきりになるだったり、利用している外部サービスの変更による対応だったりと様々だが。
そして、前途の曖昧な体制で進んだ弊害によりちょいちょい手戻りや速度ダウンが発生した。
不幸中の幸いというのか、リリース日に強い制約があったわけではなかったので、スケジュールがどんどん後ろ倒されていき、1年半がかりのプロジェクトへと育っていった。たくましくなったなぁ。
学び
- 1種類のプロダクトで、画面・機能ごとに舵取りを分けるのは難易度が上がる。別プロダクトで担当を分けるか、同時並行でどうしてもやるのであれば、進め方は揃えて頻繁に同期も取るべし。
- ガイドライン超重要。共通のなんやかんやはとあるページに整理して、原則そこを見てもらうようにすべし
- 期待は事前にすり合わせすべし。ドラッカー風エクササイズが良いかも。
- なによりも先ず状況を見える化すべし
- 「われわれはなぜここにいるか？」にチームで議論しておくべし
- コントロール不能の予定外の事態は必ず発生すると心得て、それを考慮したマネジメントをすべし
- 見積もり時は、不確実性コーンを意識すべし
2018年、28歳
管理者向け画面（いわゆるadmin）作成プロジェクト（18年7月 〜 19年2月）
やっていたことはこれまでと同じだったが、リニューアルプロジェクトの経験を踏まえ、以下は対策を打った。
変えたこと
- ガイドラインを厚めに準備した
- 仕様を極力コンフルエンスに整理するようにした
- 関係しそうな画面・機能は、ディレクターお互いが積極的に理解するようにした
- 一人、明確なPOをおいた
結果
上記対策を打った結果、手戻りはガクッと減り、ディレクター2名体制でも大きなズレやムダ無く、リニューアルプロジェクトよりは安定して進められるようになった。
POが新たに専任でいてくれたおかげで方針がブレず、正しい方向へ進んでいるかの確認もスムーズに行えたと思っている。
…が、やはり想定外の問題は起こるべくして起こるのであった。
新たな問題が発覚
POは営業の責任者（以後、Aさんと呼称）とも密にコミュニケーションを取ってくれていたのだが、あるときこんな話があった。
「この機能が無いと困る…それ込みで契約も取ってるし、アナウンスも出している」と。
また、POは必要だと認識していて既に実装済みの機能も、よくよく話を聞いたら不要だったことも判明した。
そんな状況になったらやらない訳にも行かず、全力で開発したのだが、そもそも何故そんな事になってしまったのか？
詳しく話を聞いてみると、どうやら営業責任者は、POではない別の人（以後、Bさんと呼称）へ要望を伝えて開発機能もコミットしていたとのことだった。
どういうことか？
組織図上ではBがPOの上司にあたるため、Aさんとしては「Bさんがプロジェクトの責任者」の認識だったのだ。
確かに、プロジェクトの体制は決まってはいるものの、どこかの資料に整理されて誰でも見れる状態になっているわけでは無かった。
「誰が何に責任を持つか？」が、人によって異なる認識になり得る状況になってしまっていたのだ。なるほど。
学び
- プロジェクトにおいて、誰が何に責任を持つかは明確にしておき、いつでも誰でも確認できる状態にしておくべし
- ガイドライン超便利
- 仕様をコンフルに残す運用超便利
- ある一点における最終責任者は1名にしておくと超スムーズ（プロダクトの価値、進め方…etc）
「君の給料はこれ以上増えないよ」問題
小さなスタートアップでしたので本当にいろんなことがあるもんです。
経緯についてはあまり詳しくは書くつもりは無く、きっと関わっていた人たち全員が感じたこと受け取ったことが違うと思うので、あくまで自分の身に起きた事実だけ書きます。
ある時、会議室に呼ばれて次のようなことを言われました。（急にではなく、事前にたくさんの議論や説明会、水面下の相談が行われた後です）
「あなたは、この会社の同年代の人と比べてたくさん給料をもらっている。追いつくまでは給料はこれ以上上げられない（昇給が無いの意）。恐らく数年から十数年くらいはいまのままだ。ボーナスも無い。その代わりに、失業の心配無く安定して働く事ができる。」
僕は、会社を去ることを決めました。
僕が求めていないだけで、他の人にとっては魅力的な話だったかもしれません。
あくまで、僕としては合わなかったというだけです。
学び
- 半年先のことは、本当に何が起こるかわからない。（プロジェクトのみならず、会社がどうなるか、自分がどうなるか）
- いつ、自分一人になっても食い扶持を繋いでいけるだけの状態にしないと、この先生きて行けない。自分の行き方を考えて、市場価値を高める必要がある。
- 転職もだいぶ慣れてきた。案外どうとでもなる。
- 寧ろ、回を重ねるごとに自分にマッチした会社に出会える率が高まっている。
2019年、29歳
僕は何ができるだろうか？
いろんなタイプの人とチームとして働き、いくつかの毛色の違うプロジェクトにも関わった。
そのどれも、学びは非常にたくさんあった。が、それ以上に悔しさの方が大きかった。経験からしか学べていないため、予めスキルがあればもっとうまくやれた、スムーズにできたのにと思うことが多かった。
チームとしても、「チーム」という単語を使ってはいるが、全員が一つの目標に向かって動けていたかというと自信はない。
非エンジニアの僕にとって、次にどこを目指していくべきか？の選択肢が多すぎて悩んでいた。（2019年になって悩み始めた訳ではない）
ただ、デザインも並行で進めていたときの経験から、あれこれやるだけの余裕は無いことは理解していた。
エンジニアへ寄り添えるよう技術を習得するか、ユーザに寄り添うノウハウを習得するか、その他なのか…
悩んだ結果、「最高のパフォーマンスを発揮できるチーム、環境」を作り上げるためにリソースを集中しようと決めた。
理由はいくつかあったが、主に以下が大きいのかなぁと思う。
- 前回の失敗から「次はこうしよう」と考えたことがハマり、スムーズに開発できたのが楽しかった
- あるチームメンバーから、「○○（僕の名前）と一緒のプロジェクト楽しかったよ。議論めっちゃしたけどね。一緒に良いものを作ろうとしてる感があった」と言われて、嬉しかった
- 上司から「この業界は変な人が多い。技術はすごいけど頑なな人、ユーザのことを見ない人、チーム・他者の気持ちを考えないひと。君にはその中でうまくやれる能力がある」と言ってもらえた
- 自分自身、働きやすい環境、ともに駆け抜けられるチーム、ムダの無い効率的な仕事をしたいと考えていた
- シャーマンキングの主人公たちのチームが、自分の昔からの憧れだった
そこから、なんちゃってアジャイルの脱却のため、スクラムの勉強をはじめた。
認定スクラムマスター（LSM）になったのはその3ヶ月後のこと。
3度目の転職
上記のような背景もあり、スクラム経験者を求めていた会社とマッチングすることができた。
いま思うとタイミングも業務内容もチームメンバーも素晴らしく、自分は本当に幸運だったと思う。
リニューアルプロジェクト、再び！！
ここからは会社のブログに投稿しているので割愛します。
おしまい
これまでのお話は、一旦これで終わり。
次はIT業界に飛び込む前の「なんでも屋」時代のお話もまとめたいと思う。
*1:「ディレクター」という職種は組織によって扱いが大きく異るが、ここではプロジェクトマネージャーとプロダクトマネージャー半々のようなイメージで捉えていただければと。
