セットベース開発とA3報告書 と 考える時間

本日、ゴールシステムコンサルティングさんに初めてお伺いしました。

もちもん、

最新手法で開発生産性倍増を目指せ！　TOC/CCPM×リーン開発セミナー

を受講する為です。

受講目的は、リーンを学ぶ為はもちろんですが、
今回は特にセットベース開発でA3報告書を残すという改善について
具体的な事例を聞き出す！　です。


最後のQAでは、A3報告書に関する質問も多く
みなさん興味のあるところなのかな　と改めて感じました。

ですが、今回、一番驚いたのは、
セミナーの冒頭に、西原さんから
どこの開発でも「考える時間」が削減されている」
「考える時間」が無いといった技術者の悩みを多く聞く
という事で、
私の取組も、開発現場の問題解決のヒントになっていれば
と改めて感じた次第です。


以下、本日のセミナーに参加して
今後やってみようと思った事。
#まだ聞いたばかりであまりまとまっていませんが...

セットベースのイテレーション毎に（リーンではIE？）

1)まずは、イテレーション開始時に、A3報告書を残す事を合意する
2)各課題や調査事項ごとに、記載の有無を明示
　（LAMDA表みたいなものに、A3を記載する／しないを追加）
　記載項目は、都度検討し、全部書かなくても良いものとする
　また、記載は、手書きや、ホワイトボードもOKとする
3)イテレーション終了時に、記載したA3報告書を整理、追記
　この時間を出来るだけ短くしたい（1日くらい....）

みたいな感じで出来ると良いかなぁ....
と考えています。

しかし、その後、Knowledge Baseとしてそれを整理したりする事も必要
という事も大収穫でしたが、
こちらは、じっくり考える必要ありですね...


また、最後には、稲垣さんと
組込み開発にはセットベースや因果関係図などリーンが適用可能
といった事もお話し出来ました。

プロジェクトと共に成長する

ASDoQ大会2014に参加しました。

そこで、「アジャイル開発の教科書」などの著者である細谷さんと
お話する機会がありました。

というより、お話したくて参加しました。

ASDoQ大会2014を通して、
改めてアジャイル（リボンモデル含む）とは
プロジェクトと共に成長する
プロジェクトの中で各技術者が成長していく為のアプローチだと感じました。
もしかすると、それがプロジェクトを成功に導く為の大きな要因なのかもしれませんね


成長する要因は以下の3点かと思います。

・その１：能動的となる

プロダクトオーナー（顧客　or　もしくは仮想顧客）
と開発チームが一体となって相互理解の元に意思決定していく事が
開発チームを能動的にする。
能動的な事は成長の大きな要素となります。
更には、能動的な事は無駄な事や後戻りが減る事にも繋がります。

・その２：機会が多い

イテレーションや単体テスト、リファクタリングを繰り返すので
失敗しても、改善する機会が多い
更にはもっと良くする為の改善なども可能となる。
プロジェクトで繰り返しが多い事（機会が多い事）
がプロジェクトの進行と共に自然と成長していく

また、意思決定から動くソフトウェア作成
までを出来るだけ小さくする事で、
意思がダイレクトにソフトウェアに反映される。
という実感を得られる。（何の為の作り込みかが分かる）

そして、サイクルが小さい為に、それを何度も経験出来る。
つまりは、価値の確認やフィードバックなどを何度も得る事が出来る。

・その３：一体感

顧客を含めた一体感の中で開発していく事も
成長には大きな要因となると感じています。
楽しい、役に立っている、ワクワクする
といった感情が、「もっと～したい」、「より～したい」を増殖させて
各々もチームとしても成長していく事に繋がる。

考える時間

昨今、ソフトウェア開発で、
考える時間を削減する傾向にある気がします。

複数案もそうですが、
多角的に考えて、メリット／デメリットを共有した上で
一気に作る

のが最も早く作れる気がしています。

これは、つまるところ、

セットベース開発にて
多角的に分析し、
ポイントベース開発で一気に作る

のが最も早く作れるのだと思うのです。
セット・ポイントベース開発についてはこちらも参照してみて下さい。
セット・ポイント開発のススメ

セットベースの段階で
個客と共にいろいろと考え、共有する事が
ポイントベースの速度が上がる最大の要因だと感じています。


昨今は、このセットベースの段階を省略、
もしくは、とても短い期間となり、
ポイントベース開発が出来る状況では無いのに
ポイントベース開発に入ってしまう事が多いのだと思います。


そんな状況なので、
プロセスとか、いろいろな事をリセットして、
「今、本当にすべき事は何か？！」
みたいな事を
議論というより、みんなで改めて考えてみよう！
という感じで社内ワークショップとして開催してみました。

その結果をざっくりまとめて公開しました。
考えよう！

なぜアーキテクチャーが語られないのか？！

最近、アーキテクチャーが語られない気がしていますが、
みなさんの回りではどうでしょうか？

私の回りでは一部ではされていますが、
社内でみると、決して多くは無い気がしています。

では、どうすればアーキテクチャーが語れるようになるのか？！

いっぽう、フレームワークやプラットフォーム
という言葉は話の中で登場する事はあるようです。

しかし、その内容に
アーキテクチャーが無い（検討されていない）のでは？！

と感じる事が多く、
私がそう感じるのはなぜなのか？！
なぜ、アーキテクチャーが語られないのか？！

アーキテクチャーって
全ての中心にある事な気がしています。

細かい機能や性能を考える前に、
アーキテクチャーをどうするか
が無いと、極端には全てが無駄になる事もあると思うのです。

なぜ、アーキテクチャーが中心に無いのだろう？


弊社でも派生開発、保守開発が多いので
それが原因の1つであろうとは思います。

しかし、アーキテクチャーを語っても
周りの反応も今一つなのは、やはり意識されていない
言葉に馴染みが無い

という事なのだろうと思います。


といった事がモヤモヤしていました。


そこで、一大決心し、
SWESTからちょくちょく議論させて頂いている大先輩に
突然の連絡をしてみる事にしました。

すると、快諾を頂き、いろいろと議論をさせて頂きました。

議論すると、そこから発展して、視野が広がり、
付随する思わぬ情報まで得る事が出来て、とても楽しいですね。

やっぱり議論する事って大事ですねぇ

出力しよう！

今年もSWEST16に参加しています。

今年で3年目になりますが、
3度目でもこのような場は貴重だなぁ　とつくづく実感します。

オープニングセッション、夜の分科会
と参加し、
「分ける」と「分かる」と「分かち合う」を再考する事が出来ました。

最初の難関である「分ける」為には、
言うまでもありませんが、考える必要があります。

以前も多角的な視点で考える事で
「似て非なるものを分ける」といった内容で投稿しましたが、
この多角的な視点を持つ事が難しいですよね。

その為に具体的に何をするか！？

それは「出力」ではないかと思っています。

文章でも絵でも　出力する事で、

1)自身の考えが整理出来る
　これは恐らく、みなさんも実感した経験があると思います。

2)もう一人の自分になれる
　出力したものを改めて見ると、もう一人の自分が必ず現れませんか？！
　「けっこーいけてるじゃん！」とか「ぜんぜんダメじゃん！」
　というような、もう一人の自分が突然出現しませんか？！

3)分かっていない事が分かる
　いざ、出力しようとすると、出力出来ない！
　という事ありますよね。
　つまり、”分かっていない”　という事ですよね。

4)更に掘り下げられる
　出力すると、具体的に何をもっと掘り下げる必要があるのか
　と逆に何が不要なのか
　といった事が明確になりますよね。


などなど、つまるところ、整理されるのだと思いますが、
出力するだけでも、こんなにも分かる事がある
と改めて感じた次第です。

なので、この出力を「早め」に実施する事が重要なのだと思います。
自分の状態を知る為にも、まず現段階の考えを出力してみる。

そこから改善していく。

つまり、リボンモデルですね！
小さな改善の繰り返し！！

考えるだけでなく、出力して、小さな改善を繰り返す事で、
「分ける」事が可能となり、「分かる」と「分かち合う」となります。

と、いう事で、出力しましょう！

実装時は、複数案を意識せずに考えている？！

前回は、設計において複数案を考える
でした。

今回は、実装時にも有効
という事ではなく、
実装時には意外と、複数案考えていませんか？！

設計時よりも、実装時は、比較的複数案を検討し、
ベスト？なコードを選択している事は多いのでは無いでしょうか？


例えば、デバッグ時です。

原因は分かっても、さてどう対策（修正）するか
といった場面は誰しも体験しているかと思います。

この場合、複数案を検討している事が多いのではないでしょうか？
また、このような場面ではペアプロ（ペアで作業）しているケースも多いかと思います。


例えば、複雑な処理を実装する時です。

タイミングや分岐条件が複雑な場合など
どう実装すれば分かり易いか　など
こっちが良いか、あっちが良いか　などなど
詳細設計まで落ちていても、
細かいところでは、実装案を複数考えている事がある気がしています。


などなど、意外と
実装時には、あれこれ考えている気がします。

実は、設計でも複数案考えているのかも！？
と思ったりもします。

設計時にもいろいろ考えてはいますが、
コードのように実装イメージが明確ではなく
曖昧な状態な気がしています。

なので、設計時は、
複数案をある程度まで形にする必要がある気がしています。

設計の場合は、形に（アウトプット）して見直す事で、
メリット・デメリットを明確にする
という事が必要なのだと思います。

実装の場合は、実装イメージそのものがアウトプット（最終形）になるので、
出力する前に解決可能となり、
複数案を考えている事が分かり難いだけで、
複数案考えているケースが多い！

と思います。

続・複数案で考える

前回の続きとなりますが、

設計では複数案を検討するのは
とても有効だと思っています。

上流設計であればあるほど効果は高いかと

特に重要なアーキテクチャー設計では必須！？

複数案を検討し、メリット、デメリットを比較し
何を、どんな理由で選抜するか

といった事が明確になる

と、いうより、
複数案を検討し、メリット、デメリットを比較し
何を、どんな理由で選抜したか

を明確にする必要がある

という事だと思うのですが、

初期の段階で、これを明確にしないと、

その後の工程で

”どうすべきか”が時間と共に徐々にブレてきます。

このブレが大きくなると、

アーキテクチャーのメリットが最大限に生かされず、

デメリットを克服出来ない

という結果となり、

当初に検討していたアーキテクチャーは
影も形もなくなってしまいます。

明確にしてもブレてしまう問題はありますが、
こちらの対策は、また今度。

まずは、明確にする事が大事かと思います。

少人数のプロジェクトであれば、
明確にするだけで、各自がメリット、デメリットを生かす為に
更に工夫していきます。
そうなると、アーキテクチャーは、より強固なものとなります。

もしかすると、こういう状態にならないと、
アーキテクチャーは維持出来ないのかもしれませんね.....