【CEO/事業責任者向け】これからソフトウェア開発を始める人の学習ロードマップ
対象となる人
・小さなチームでこれからソフトウェア開発を始めたい経営者・チームの責任者
・ソフトウェア開発を勉強したことがない経営者・事業責任者
・その他、ソフトウェア開発の基礎から勉強したい人
このロードマップでは、主にこれからソフトウェア開発を始めようと思っている経営者や事業責任者の方へ向けての学習方法を紹介しています。
特に初期の段階で潤沢なリソースがなく、自らも開発チームに参加することが多い、初期のスタートアップのようなスモールチームの方にフォーカスした内容になっています。
◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆
このロードマップの目的
経営者や事業責任者は、プロダクト開発のフェーズが進んで行くにつれて、最終的には、多くの開発工程を各スペシャリストに委譲することになります。
しかし、人数も少なく成熟度も低い初期のチーム状況では、経営者自身もソフトウェア開発の工程自体に積極的に参加し、他メンバーと同様に作業をしなければいけない時期があります。
そのようなフェーズで、全く知識なく開発に臨むのは大きなリスクです。
まずは事前に最低限の知識を知っておくことで、将来のリスクを回避することができます。
このロードマップは「はじめのプロダクトを世の中にリリースするまで」をイメージして、初期の開発プロジェクトを想定しています。
学習内容は、どちらかというとプログラミングのような技術面よりマネジメント面に重きを置き、エンジニアチームでの円滑なコミュニケーションを取れるレベルを目指しています。
◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆
学習の範囲
・1.コンピュータサイエンス基礎
・2.プロダクト開発基礎
・3.ソフトウェア開発基礎(開発マネジメント)
・4.ソフトウェア開発基礎(開発技術)
基本的には上から優先度が高い内容となっています。
まずは基本的な用語や知識を学び、マネジメントに近い分野から技術的な内容を学習するという順番です。
これらの分類については、次の記事にまとめていますので、一度確認していただけると良いかと思います。
◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆
学習する上で大事なこと
・全て理解しようしない
・すでに理解している項目は飛ばしても良い
ソフトウェア開発は専門的な分野のため、基礎学習の中でも不明な点が多く出てくるかもしれませんが、全て理解しようとしなくても大丈夫です。
また、このロードマップには基礎的なIT用語がわからない人のための内容や、すでに経営する上で身についている知識についても記載されているかもしれません。
そのような項目については飛ばしていただいて構いません。
◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆
1.コンピュータサイエンス基礎
★ 学習の目的
ソフトウェアは専門性の高い領域であり、チーム内で話す内容の最低限のレベルが揃っていなければ、コミュニケーションを取ることができません。
ここでは、最低限の用語、IT技術分野などの基礎知識を学習してチーム内でコミュニケーションできる下地を作ることを目的とします。
★ 学習する内容
最低限必須な知識として
・ソフトウェア
・データベース
・ネットワーク
・ソフトウェアにおけるセキュリティリスク
・ソフトウェアにおけるプライバシーリスク
のような基本的なIT知識を簡単に説明できるレベルまで学習してください。
加えて、
・人工知能
・VR
・IoT
・ブロックチェーン
などの世の中で話題になっているテクノロジーについて、簡単な技術理解(どんな仕組みで動いているか)ができているとなお良いと思います。
★ 参考学習コンテンツ
コンピュータサイエンスの基礎基礎的な内容について、イラストとやさしい言葉で図解して説明されています。
個人的には、本当に初めてITの勉強を始める人でも理解できる丁寧な内容だと思いました。
逆に多少の知識がある方には簡単すぎるかもしれません。
国家資格である「基本情報技術者試験」の参考書です。
こちらもイラストが多く使われて説明されているため、非常にわかりやすい内容となっています。
専門的な内容もあるため、IT基礎を比較的深く理解したい人にはおすすめです。
資格参考書ということもあり、網羅範囲が広いので全てを勉強する必要はありません。
「CPU、メモリ、補助記憶、データベース、ネットワーク、セキュリティ」など知りたい内容を中心に勉強するのが良いと思います。
ソフトウェア開発についてや、経営戦略など幅広い分野も網羅されているので、興味がある内容については読んでおいてもよいかもしれません。
【記事】ソフトウェアの周辺技術について知っておこう！
この記事でもソフトウェア開発の周辺技術について記載しています。ぜひ一読ください。
[他、随時更新中...]
◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆
2.プロダクト開発基礎
★ 学習の目的
比較的小さなチームやスタートアップでは「ソフトウェア開発をすること自体が会社の製品を作ることである」というケースは多いと思います。
そのため、プロダクト開発の正しいプロセスを理解することが、そのままソフトウェア開発の品質向上や生産性向上に直結していることが多いです。
ここでは、プロダクト開発のマネジメント方法やプロセスモデルについて学習し、アイディアの構想段階から初期プロダクト開発の開始までをスムーズに行えるようにすることを目的とします。
★ 学習する内容
プロダクト開発で学習したい基礎的な項目は主に2つです。
・プロダクトの開発サイクルの学習
・初期のチームのマネジメント方法
【プロダクトの開発サイクルの学習】
プロダクトの開発サイクルの学習で覚えておきたい基本概念は以下の3つです。
・仮説の抽出
・仮説の検証
・検証結果をプロダクトへ反映
これらの開発サイクルを回すための具体的なプロセスやそのマネジメントモデルについて学習してください。
【初期のチームのマネジメント方法】
開発はどこかの段階で複数人のチームになります。
まずは、初期のチーム最低限のマネジメント方法を学習します。
少人数である初期チームでは、最低限の手法として『1on1』について学習しておくことをおすすめします。
組織作りの課題はフェーズごとに無数に発生するため、いきなり多くの方法論を学習することは難しいと考えています。
まずは柔軟性を持って運用可能な「1on1」を適切に運用することで、初期に発生するチームの多くの問題を解消できると考えていることが理由です。
★ 参考学習コンテンツ
【プロダクトの開発サイクルの学習】
スタートアップにおいて、失敗する要因を排除するための科学的な方法論が書かれている入門書籍です。
スタートアップ以外のチームであっても、リーンキャンバスやジャベリンボードを始めとする「事業の検証サイクルを回す方法」については学習する価値があると思います。
基本的には、この1冊だけでも期待する基礎知識が身につけられる内容となっています。
こちらもスタートアップについて書かれた書籍ですが、リーン思考という無駄のない、生産的なプロセスに基づいてプロダクト開発を行なう思考法について記載されています。
個人的な感想として、体系だった学習としては向いていない気がしますが、非常に勉強になる良書だと思います。
デザイン思考については、色々なモデリングがされており、どの書籍というのは僕自身理解が深くはありませんが、デザイン思考のツールの使いかたや実践的な内容が記載されているため良い本だと思います。
プロダクトマネジメントを成功に導くためのクライテリアです。
初期のチームでは全てのチェックをつけることは難しいとは思いますが、どんなことに指標を置くべきかを把握するためには、一度は目を通した方がよい素晴らしいドキュメントだと思います。
[他、随時更新中...]
デザイン思考、リーンスタートアップについては記事でも概要を触れていますので、まずは一読いただけると幸いです。
個人的な見解としては、「入門 企業の科学」1冊で開発サイクルについては十分学べるとは思いますが、他のモデルについても学習しておくことで思考が広がるため、補助的な意味でも勉強しておくのが良いかと思います。
【初期のチーム運営方法】
漫画やQA方式などわかりやすい表現で、1on1を実践する意味や導入方法について書かれています。
ヤフーという巨大な組織で実践されていることから、スモールチームだけでなく、すでにある大きなチームに所属している人でも多くの学びがあると思います。
Saasを中心とした投資家である前田ヒロさんの対談ポッドキャストです。
1on1の重要性や意識していること(時間、曜日、話す内容など)勉強になることが多いです。
「この1本を聞くだけで1on1を始められる」くらい詳しく話されており、非常におすすめです。
1on1からは逸れてしまいますが、この前田ヒロさんのポッドキャスト自体も非常に勉強になりますので他のエピソードもぜひ聴いていただきたいです。
色々な起業家の方のチーム初期の悩みや失敗などを本人の口からリアルに聞けるのは非常に貴重ですし「今だったらその時どんな選択をするか？」など気になる話題も多くされています。
ポッドキャストという媒体も、本は読むのが苦手と思っている人や時間がない人にとって良いと思います。
[他、随時更新中...]
◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆
3.ソフトウェア開発基礎(開発マネジメント)
★ 学習の目的
・ウォーターフォールモデルの基礎学習
・スクラム
・技術的負債
ここでは、ソフトウェア開発の工程やマネジメント論など開発プロジェクトのマネジメント基礎知識を学習します。
ソフトウェア開発は、50年以上前からより良いプロセスを研究されてきた専門的な分野です。
少人数であれば独自の方法でプロジェクトを運用することも可能ではありますが、たとえ2人しかいないチームであっても、先人たちのプロセスモデルを学習しておくことは無駄にはなりません。
ここでは、最終的にアジャイルソフトウェア開発の手法の一つである『スクラム』を導入することを目的とした勉強を行います。
★ 学習する内容
【ウォーターフォールモデルの基礎学習】
スクラムを学習する前に、異なる開発モデルである「ウォーターフォールモデル」の学習を行うことを推奨します。
スクラムは、軽量なプロジェクトマネジメントのモデルであり、ソフトウェア開発の詳細について多くは語られていません。
しかし、要件定義、設計、テストなど、開発の基本工程については、スクラムでも必要な内容のため一度は勉強しておく必要があります。
ウォーターフォールモデルは、体系立てられたシンプルなモデルであるため基礎を学習するには非常に良くできています。
ここでは、あくまで工程理解のための勉強ですので、詳細な運用方法まで学習する必要はありません。
【スクラム】
スクラムを導入する理由はいくつかあります。
スクラムは「リーン思考(無駄のない、効率的な生産を考える思考法)」に基づいて作られており、ここまでのプロダクト開発の学習内容(リーンスタートアップなどの思考法)と親和性が高いモデルであること。
ルールや仕様が非常にシンプルで軽量に作られていることから、初期学習のコストが低いこと。などが主な理由です。
ただし、実際にスクラムを効果的に運用するのは簡単なことではなく、実践的な学びを必要とします。
「とりあえず概要だけさらって適当に運用してみよう」とはせず、スクラムの目的や効果についてまずは理解することからはじめてください。
【技術的負債】
ソフトウェアを開発で必ず出てくる問題の一つに「技術的負債」があります。
ソフトウェア開発では、エンジニア以外には理解しにくい専門的な理由で開発が遅れてしまったり、突発的な修正が必要になることがありこれを技術的負債と呼びます。
具体的な理由は「コードのバージョンが古すぎる」「コードにテストがないためメンテナンスできない」「スピードを重視した結果、コードが複雑になっている」など様々です。
これらの問題はたびたび、エンジニアとマネージャー(経営者)にコミュニケーションの軋轢を生んでしまいます。
そのため、チームを作る前にまず『技術的負債』というものがどういうもので、どうやってコントロールしていくものなのかを学習しておく必要があります。
★ 参考学習コンテンツ
【ウォーターフォール基礎】
ソフトウェア開発の各工程の概要からプロジェクトマネジメントまで一通り基礎的な内容を学ぶことができます。
最新版ではウォーターフォール型開発、アジャイル型開発の両方が記載されていて、比較して学習できるのも良い点です。
各設計工程の成果物(設計書など)のサンプルもありイメージもしやすいです。
ウォーターフォールモデルは、その性質上、請負(受託)業務でよく使われるため、請負の事業背景も含まれていますが、あまり気にせず開発工程の流れを中心に学習すると良いかと思います。
プロジェクトマネジメントについてはPMBOKという比較的昔から大企業でも採用されてきたマネジメント体系について書かれていますが、この辺は読み飛ばしても現段階では問題ないと思います。
【スクラム】
20ページほどの小さなドキュメントとして公式に作成されたスクラムについてのガイドブックです。
これがルールの全てであるといってもよいため、まずはこのガイドをよく読み概要を理解してください。
スクラムについて漫画形式でわかりやすく説明されています。
漫画形式とはいえ、内容は薄くはなく、具体的な事例や運用方法も記載されており、始めの1冊としては十分実践的な内容となっています。
数時間もあれば読めると思うので、まずは読んでみることをおすすめします。
2つの書籍を読めば十分な内容が記載されていますが、10分で概要を理解したい場合は、こちらの記事を一読していただければと思います。
【技術的負債】
技術的負債については、ネットで調べるだけでも数多くの情報が存在するため、勉強するコンテンツには困らないと思いますが、個人的はこの本の内容が非常に論理的であり深い理解を得ることができると考えています。 (Capter5)
技術的負債以外でもこの本には、エンジニアリング組織を作る上で必要な多くの内容が書かれているため、必読の一冊です。
ただし、内容は初心者向きとも言えないため、一気に全て読まなくても問題が発生するたびに逆引きするような使い方で、少しづつ理解を深めても良いかと思います。
◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆
4.ソフトウェア開発基礎(開発技術)
★ 学習の目的
ソフトウェア開発を進める上では当然ながら技術的な意思決定も必要です。
(選択言語、システムアーキテクチャ、運用環境など)
これらは基本的にはエンジニアが行なうものですが、初期の少数チームでは、プロダクト責任者が意思決定に関与するシチュエーションも少なからず存在します。
あくまで、技術的な最終判断はエンジニアが行なうことが好ましいですが、技術的な意思決定で少しでも失敗のリスクを減らすために、プロダクト責任者が、知っておくべき最低限の技術的な基礎学習を目的としています。
★ 学習する内容
・アプリケーションの設計パターン基礎
・テスト
・(プログラミング)
【アプリケーションの設計パターン基礎】
ソフトウェアの開発の設計パターンの基礎を学習します。
ここでいう設計パターンとは、
・モバイルアプリケーションがどのような仕組みで構成されているか？
・Webアプリケーションがどのような仕組みで構成されているか？
・モバイルアプリを開発することのメリット/デメリット
・各設計パターンによってどのような職域のエンジニアが必要なのか
のようなアプリケーション開発の直近の課題に近い内容を指しています。
設計やアーキテクチャには、必ずメリット・デメリットが存在するため各設計パターンのポイントを押さえておくことを目的に勉強します。
【テスト】
テストについて、エンジニアや専門職種以外の人間が学習に触れる機会は少ないと思いますが、テストは小さなチームにおいて、ソフトウェアの専門的な知識が高くなくてもチームに貢献できる数少ない工程の一つです。
テストについて勉強しておくことで、ただ闇雲に触るだけのテストでは、見つけられなかった問題を発見できるようになります。
専門のテスターがいないことが多い、初期のプロダクト開発において品質を上げることに役立つでしょう。
【(プログラミング)】
非エンジニア向けのソフトウェア学習として、プログラミングを推奨する内容も時々見受けられますが、個人的にはプロダクト責任者がプログラミングを学習することは必須ではないと考えています。
理由は、プログラミングを習得し、ユーザーが満足するアプリケーションを開発できるレベルになることは短期間では到底難しく、ほとんど実践的な業務で役に立たないためです。
プログラミングをもし学習したいと考えているなら限定的な目標をもって注力することをおすすめします。
プロダクトの内容にもよりますが、自分で開発もできるようになることを目標にするのは、あまり効果的なアプローチではないかもしれません。
(限定的な理由の例)
・プロトタイプを自分で作れるようになりたい
・論理的な思考ロジックをプログラミングを通じて学びたい
★ 参考学習コンテンツ
【アプリケーションの設計パターン基礎】
この分野を専門的な用語や知識なしで図解したコンテンツなどがなかなかみつからないため、局所的になってしまっている部分はありますが、個人的にわかりやすいものを載せておきます。
この方の記事はすごくわかりやすいです、設計パターンという観点で除外しましたが「非エンジニアのための基礎知識 ②言語の仕組み」も良い記事だと思いますので読んでみると良いかと思います。
【テスト】
ソフトウェアのテストとはどのようなものかを理解するのにわかりやすいスライド資料です。
ソフトウェアのテストとはどういうことなのかをまずは理解するために読んでおくと良いと思います。
もう少し詳細にテストの技法について学びたい人は、この本を読めばテスト技法について十分に勉強できます。
ですが、専門性は高いため全て理解するのは難しいかもしれません。(まったくの初心者向けではないです)
おそらく、初めて読んだ段階では、記載されている技法がどのようにプロダクトのテストに生きていくのかがまだわからないと思いますので、実際に自分たちのプロダクトをテストする段階になって改めて詳しく勉強するという方法でも良いと思います。
【(プログラミング)】
未経験者がまずはプログラミングを体験するには、今はプロゲートが主流だと思います。
ここで習得できるのは「体験レベルの最低限の基礎知識」という認識でいると良いと思います。
プロゲートのコンテンツ自体は素晴らしく、多くの技術について基礎学習が簡単にできるため、プログラミングやその他技術について手を動かして学習したいという方は、ぜひ一度やってみてください。
[他、随時更新中...]
◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆
まとめ
主にプロダクト開発初期にノウハウが必要になるであろう、CEOや事業責任者の方へ向けて、勉強するためのロードマップを紹介しました。
参考の資料や書籍には、重複する内容もあり、ボリュームが多いと感じる方も多いかもしれませんが、学習のポイントを確認していただき取捨選択して進めていただければと思います。
◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆
アンケートのお願い
このチャンネルでは、これから提供していくコンテンツやサポートの内容を改善していくために、アンケートをお願いしています。
ぜひアンケートにご協力ください。
この記事が気に入ったらサポートをしてみませんか？