ソフトウェア開発をもっと楽にしたい
僕は沖縄のSIer新兵二年目です。
ソフトウェア開発苦しいので楽にする方法は
こうじゃないか、ってところをまとめて見ました。
人間は弱い
- 忘れる
- 飽きる
- 勘違いする
- 都合良く捉える
- 嫌なことは後回し
- 嫌なことは人に押し付ける
ソフトウェア開発、特に大規模になればなるほど弱さは露呈する
だからどうにか克服したい。それには
- 段階的な開発
- パターン化、モデル化
- 自動化
が効果的ではないか
段階的な開発
*どんなことが問題なのか
要件定義、設計、実装、テスト、基本的にはこの流れで開発は進む。
開発の規模が大きい場合、この流れを一度だけで進めるのは難しい
なぜなら、規模が大きい開発ほど、各フェーズの時間も関わる人数を多くなる。気にしないといけないことが多くなる。
気にすることが多くなるほど、進めるための時間が多く必要になる。
時間がかかればかかるほどに、気にすることが多くなる、よってどんどん開発は泥臭くなる
*だから段階的な開発
そもそも一度にすべてを開発する必要はないのでは。だから、段階的に開発を分ける。
分け方はわからない。優先度をつけた機能毎がいいじゃないかな。機能毎に要件定義、設計、実装、テスト を行う。
*段階的な開発をすると気にする範囲が減る
優先順位をつけて、少しずつ開発していけば、一度にたくさんのことを気にしなくていい。
各フェーズの時間も短くなるし、関わる人数も減らすことができる
*段階的な開発をすると振り返りがし易い
一度にすべてを開発しようとすると、振り返りのフェーズが最後にしかとれない。
振り返りは、すべてが終わってからしかできないので、次に活かせるのは次の開発となってしまう。
だけど、段階的に開発を行い、一度のイテレート(要件定義、設計、実装、テスト)の後に振り返りのフェーズを設けると、次のイテレートに活かすことができる。開発の質が、イテレート毎に向上していくことになる。
そうして、開発の中にみんな大好きPDCAが完成する。
*段階的な開発をするとリズムが作れる
もし、段階的な開発に、決まった期間をそれぞれ設けることができれば開発にリズムが作れる。リズムがいい、ということはいいことだ。
*段階的な開発をすると仕様変更が明確になる
いちど開発を終えて納品したものに対しての、仕様変更が明確になる。
一度に全てをやってしまうと、途中の仕様変更があやふやになりがち。慎重な判断と交渉が必要になる。
*段階的な開発をするために超えないといけない壁
お客さんに付き合ってもらう。
- お金とかの契約
- 頻繁な検収
- 要件追加の場合は、別途っすよ(ほんとは当たり前なんだけど)
でもどうやって越えればいいかは、わからない。よく知らないんです
パターン化、モデル化
*どんなことが問題なのか
開発してて、全体像がわからなくなる。
ソフトウェアは複雑で目に見えない。自分で書いたコードも
1ヶ月後には理解できなくなっている。コードだけじゃない。
設計書もそうだし、要件だってそう。
超ロジカルでシビア。抽象的なことが許されない。たったのひとつも
*だからパターン化、モデル化する
パターン化、モデル化して複雑なものを単純化する
人間の気にしないといけないところを、少なくするには、パターン化とかモデル化とかして
"単純化"するのがいいと思っている。
*パターン化、モデル化するために超えないといけない壁
そもそもどうやっていいかわかってない。dfdとか?。
パターンランゲージとか、そこら辺にヒントがある気がするが勉強ちう。
頭がよくないとできなさそうな気がしている。
人間の能力に依存しそうで、あまり頑張りたくない。僕は頭がそんなによくないので費用対効果的に
自動化
*どんなところが問題か
開発してると
- 書いたコードが正しいかわからない
- 手順書を作っても漏れる
- 以前何をしたか忘れる
- やり直しなくなる
- これ人間がやる作業じゃないよね?と虚しくなる
*だから自動化する
それを補うために、いろんなことを自動化する
自動化できること
- テスト
- テストの自動化はもはや言うまでもない。
- プログラミング
- コードの自動生成。wagby とか。
- 設計
- わかんない。できそうな気がする
- 環境構築
- puppetとか。Chefとか
*自動化するために超えないといけない壁
- 自動化を保ち続ける意思
- 自動化部分を見極める能力
- 技術
まとめ
なるべく、気にしないといけない事を減らす。
それに限る気がする。気にしないといけないことをそのままにして、根性で頑張ることはしない。
その為の方法を、いろいろな視点から試す。
今のところ、
- 段階的な開発
- パターン化、モデル化
- 自動化
が良さそう。
最後に
いいとはわかっていることだけどなかなか実現できない。
僕一人もまた弱い人間である。
経験も知識も実力も信頼もまだまだ足りない
僕一人だけじゃなく、同じく開発に関わる人が同じベクトルに向かってないと実現はできない。
自分の考えをまとめたり、発表したり、実践したり。周りを巻き込めるような動きをする。
それもまた短いイテレーションの中で、PDCAを繰り返すのが良さそう。だから完璧な意見じゃなくても発信する
また PDCAはフラクタル構造をとれるので、そこが素晴らしいところ。
- イテレーションレベル
- PJレベル
- 部署レベル
- 会社レベル
- 地域レベル
- 国レベル
- 世界レベル
PDCAが回る個人になることがまずは目標。
参考文献 and 最近読んだもの
- 人月の神話
- 構造化分析とシステム仕様
- アドレナリンジャンキー
- デッドライン
- ピープルウェア
- ゆとりの法則
- スクラムブートキャンプ
- アジャイル開発とスクラム
- 知識ゼロから学ぶソフトウェアテスト
- リーダブルコード
- 小さなチーム、大きな仕事
- 数学文章作法
- デザインパターン
- ラーニングパターン
- プレゼンテーションパターン
- 愛せないコードを書くには人生はあまりにも短い
- いろんな先輩の考え方