Posted by & filed under 開発.


社内で新卒向けに講義をしました。社内固有の情報を削除した上で、下記に講義資料を公開します。

ソフトウェア開発における開発者の仕事を理解してもらうために話をしました。

講義対象者の半数以上が開発志望ではなかったので、開発者でない人が、今後、IT業界の中でどう開発者と向き合っていくかを主眼にして話しました。IT業界にいながら、開発者のことを理解できない人たち、あるいは何をしているのか分からない、と偏見を持つ人がいるからです。彼らにそうなって欲しくないからです。共感できるかは別です。考え方や価値観が違うなら違うでもいいと思います。はじめから理解を拒否していたら、いつまでもコミュニケーションが生まれません。

ついでに、半数以上が女性だったので、裏の意図として、プログラマがモテるようになって欲しいと思って話しました。プログラマがモテる世界にしたいと思っているからです。若い女性の前で話す機会を得られた今、プログラマの世界で育てられた自分にとって果たさなければいけない責務だと思っています。

==========================================================
新卒向けの講義:

ソフトウェア開発という仕事

* この講義の目的

– ソフトウェアの開発者の生態の理解

(原則)開発者志望ではない人を想定します

* 目次

– ソフトウェア開発にはどんな職種があるのか?(世間一般)
– 開発者は普段何をしているのか?
– ソフトウェア開発とは?

* ソフトウェア開発にはどんな職種があるのか?(世間一般)

** IPAのITスキル標準(ITSS)

– http://www.ipa.go.jp/jinzai/itss/index.html
– 職種名、必要スキル、業務内容を整理した一覧
– 職種と専門分野が横軸、スキルレベル(7段階)が縦軸
– 資格ではなく、スキルの指標

** ITSSの特徴

– 単線キャリアパス(PG=>SE=>PM)から、複線キャリアパス(下級PG=>上級PG、下級SE=>上級SE、下級PM=>上級PM)へ転換

** ITSSの職種

– マーケティング
– セールス
– コンサルタント
– ITアーキテクト
– プロジェクトマネジメント
– ITスペシャリスト
– アプリケーションスペシャリスト
– ソフトウェアデベロップメント
– カスタマサービス
– ITサービスマネジメント
– エデュケーション

詳細は
http://www.ipa.go.jp/jinzai/itss/download_V3_2011.html
「2部 キャリア編の補足A」を参照

** ITSSのスキルレベル

– レベル7: 世界で通用するプレーヤ
– レベル6: 国内のハイエンドプレーヤ
– レベル5: 企業内のハイエンドプレーヤ
– レベル4: 社内においてプロフェッショナルとして認められる
– レベル3: 要求された作業を全て独力で遂行
– レベル2: 上位者の指導の下に、要求された作業を担当
– レベル1: 最低限必要な基礎知識を有す

** スキルのジレンマ

– 固有の知識(特定の製品・サービスや特定のプログラミング言語)だけでは、いずれ古びるリスク
– 固有の知識を伴わない知識や技能だけでは単なる評論家

古びないように自分のスキルを常に見直す必要

** ITSSの使い方

– 「普通の人」は、ITSSの知識体系から自分に必要なスキルを具体化する
– 「普通でない人」は、自分のスキルを抽象化して、ITSSの知識体系のどこに位置するか知る

– 職種の分類にこだわる必要はない

* 開発者は普段何をしているのか?

** 開発部内の主な職種

– プログラマ: ソフトウェアを書く人
– テスト担当者: ソフトウェアの正しさを検証する人
– インフラ担当者: ソフトウェアが正しく動く環境を整備する人

** プログラマが普段していること

– コードを書く(新機能開発、バグ修正)
– コードを読む(壊れないようにするため)
– テストする
– 調べる(どうやって実現するか調べる)
– 考える(どうやって実現するか考える)
– 新機能を提案する
– 技術の先行調査(知識のストック)
– 情報伝達(成果を披露)
– 営業協力(実現可能性の相談)
– 製品サポート(トラブル対応)

** 製品開発の段階とプログラマの役割

1. 要求を聞き出す or 発見する
2. 何を作るか考える(いわゆる要件定義)
3. どう実現するか考える(いわゆる設計)
4. コードで実現する(いわゆる実装)
5. 要求を満たす品質にする

– アリエルの多くのプログラマ: 3と4を担当
– アリエルの一部のプログラマ: 2と3と4を担当
– アリエルの古老プログラマ: 1から4まで担当
– アリエルの伝説的プログラマ: 1から5まで担当

** テスト担当者が普段していること

– 製品のテストをする
– バグを報告する
– 機能提案をする
– 修正されたバグを検証する
– 製品の品質を見える化する(リリース判断の情報提供)
– テストを効率化する
– プログラマの情報を翻訳して情報伝達
– プログラマにプレッシャーをかける
– プログラマを励ます
– 製品サポート(トラブル対応)

** プログラマとテスト担当者のまじわり(新機能開発編)

1. プログラマが機能について課題管理システムにチケットを作成して仕様を記載
2. プログラマが自分の手元でコードを書く
3. プログラマが自分の手元で動作を確認する
4. プログラマがソースコード管理システム(SCM)にコードをコミットする
5. プログラマがチケットの仕様を最終確認してステータスをfixedにする
6. 自動で単体テストなどのチェックが走る
7. 毎日、自動でビルド(コードから完成物を生成)が走る
8. できたソフトウェアを動かす(一部のテスト環境は自動デプロイ、一部は手動デプロイ)
9. テスト担当者がソフトウェアが想定どおりに動くか確認(verify)
10. 想定どおりの動きをしない場合、チケットをreopenする
(reopenされたチケットはプログラマに戻る)
11. 動作およびチケットに記載された仕様に問題がなければチケットを閉じる

** プログラマとテスト担当者のまじわり(バグ修正編)

1. 毎日、自動でビルド(コードから完成物を生成)が走る
2. できたソフトウェアを動かす(一部のテスト環境は自動デプロイ、一部は手動デプロイ)
3. テスト担当者がテスト仕様書をもとに、ソフトウェアが想定どおりに動くか確認する(システムテスト)
4. 想定どおりの動きをしない場合、チケットを作成してバグ報告する
(作成されたチケットはプログラマに行く)
5. プログラマがチケットに記載されたバグを修正する
6. 以下、略

** インフラ担当者が普段していること

– パフォーマンス計測
– 営業協力(実現可能性の相談)
– 導入支援(キャパシティプラニング)
– 情報伝達(導入や運用のマニュアル化)
– 技術の先行調査(知識のストック)
– 製品サポート(トラブル対応)
– 管理コスト軽減の側面での機能提案

* ソフトウェア開発とは?

** 様々な見方

– 製造?
– 設計?
– サービス?

業界での完全なコンセンサスをまだ得ていない
ソフトウェア開発が未成熟な証

** 製造業アプローチ

建築や製造業のようにソフトウェアの故障率の予測可能を目指す考え方

– プロセスモデル(cf. CMMI)
– ウォーターフォール
– クリーンルーム手法
– ソフトウェアファクトリー
– ハッカー気質や職人の否定

周期的に盛り上がっては消えていくソフトウェア業界の青い鳥

** 設計業アプローチ

建築や製造業と比較した時、コードは設計図に当たるという考え方(故障率という発想そのものの否定)

– 設計図なので試行錯誤は必然と見なす
– 製造に相当する工程はコンパイルやビルド(自動化済み)
– プロセスよりツールや技法(職人)を重視
– ハッカー気質の肯定

現実にもっとも適合したアプローチ。あるがままを受け入れる禅の世界

** サービス業アプローチ

ソフトウェア故障率の予測ではなく、使う人の満足度の向上の予測可能を目指す考え方

– プロセスより顧客との対話を重視
– アジャイル(cf. スクラム、XP)

コミュニケーションや顧客満足度を出されると誰も反論できない最強兵器
(熟考の末ここにたどりつく玄人と、歴史を知らず雰囲気だけでここに飛びつく素人が共存する世界)

** 開発プロセスと用語

– 要求(wish or desire)とは?
利用者の願い
(本当の要求は言語化されるとは限らない。マーケティングの領域に近い)
– 要件(requirement)とは?
技術的な裏付け(実現可能性:feasibility)をもとに要求を定義したもの(広義)
かつ関係者で合意したもの(狭義)
– 仕様(specification/spec.)とは?
ソフトウェア動作を記述したもの
完全な仕様はコード以外に存在しえないジレンマ
– コード(code)とは?
ソフトウェアの記述そのもの
– 設計(design)とは?
広義には、仕様作成からコード記述まですべての行為を指す用語
狭義には人それぞれ(仕様書とコードの中間生成物の設計書を書く行為など)
語源に忠実になれば、概念を記述(コトバ、コード、図など)して伝達すること
– 実装(implementation)とは?
一般にコードを書く行為のこと
– ビルド(build)とは?
コードから動くプログラムを生成する工程(一般に自動化される)
==========================================================


関連文書:

  • 関連文書は見つからんがな

Comments are closed.