受託開発のサガ？！ソフトウェア開発のサガ？！

最近、トラブル続きで、
その原因を対立解消図や因果関係図を使って分析しています。

分析の結果、
「受け身だった」
「早く終わらせたいという気持ちから自分勝手なゴール設定をした」
という根本原因が見えてきました。

「ソフトを作っていたい」、「動くものが作りたい」、「早く動かしたい！」
といった”サガ”が、その行動を引き起こす！

という分析結果です。

これってプロフェッショナルのやる事？？？
これも「不確実性の非耐性」と言っていいのか？？？
という感じですが、
この”性（さが）”も分からなくは無いです。

ここで、1つの疑問が。
これは、受託開発だからそうなるのか、
それとも、メーカーやツールなどの
製品開発に関わるソフトウェア開発技術者全般に言える事なのか？！

組込み系の製品ソフトウェア開発では、
ハードなどの仕様に合わせて作り込む事が多いと思います。
この場合は、仕様提示者が別にいる事になり、
受託開発と似た状況でもあるかと想像しています。

ツール開発などでも同様に仕様提示者がいる場合は似た状況といえるかもしれません。

大きくは、システムや製品としての上流工程に如何に関わるか、
というより、プロとしてどのように関わるか
といった「関わり方」の問題なのかもしれません。

いずれにしても、プロとしての性（さが）を持つような革命？
が必要なのかもしれないと思う今日この頃です。

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

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

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

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

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

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

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

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

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

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


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

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

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


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


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

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

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

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

出力しよう！

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

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

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

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

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

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

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

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

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

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

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

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


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

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

そこから改善していく。

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

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

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

複数案で考える

昨今、設計やコードが吟味されていないと感じる事が多いです。

吟味されていない原因を考えてみると、
1)どのように吟味して良いのかを知らない技術者が多い
2)論理量の肥大化と反比例して、短納期要求が多い

という事かと思います。

特に受託開発では、2のような状況を理由に
良いものを追及するモチベーションが低下しているような気がしています。

その長年の蓄積により、1となる？
もしくは、いろいろ諦めている間に、吟味しなくなる
のかもしれません。

要するに、
現場の声は、「そんな時間は無い！」
という事なのだろうと思います。

しかし、時間が無いからこそ、良いものを追及する事で
短期間で高品質が実現出来るのだろうと思います。

と、いうのはタテマエで、
良い物を追及する方が結果的に、ラク出来るので
最大限ラクする為に
どーするかを必死に考えているだけです...

そして、ラクする為に
最近お勧めしているのが、複数案を検討する事です。

複数案を検討し、それを選択する事で、

1)多角的な視点が生まれる
2)レビュー時にも、様々な意見が出る
3)漏れ抜け防止にもつながる
4)どうして、この設計にしたのか、このコードにしたのか　が明確になる
5)デメリットが明確になる

インセプションデッキ同様に
やらない事や、デメリットを明確にする事って
重要だと思っています。

デメリットを明確にするには、
この複数案による選択はとても効果的かと思います。

デメリットが分かっていると、
そこで無理をしなくなる　

分かっていないと
デメリットを無理矢理に、強引に力技で突破してしまい
そこから、どんどんコンセプトやアーキテクチャなどが崩れてしまう。

一度壊れると修正は難しく、どんどん汚くなり、
超巨大な関数が作成されてしまう　など
ウィルスのように、あっという間に全てに感染していきます。

このような失敗をしない為に
複数案を検討し、選抜するアプローチ
如何でしょうか？

10の手強い質問

先日、インセプションデッキ使ってみました。
といっても、私は「使ってみて！」と　お願いしただけですが....

受託開発でも営業的な立場の人を参加させれば
十分使える（効果が高い）と感じたので、
各プロジェクトリーダーにお願いしました。

ほとんど説明はせずに、自分達で調べて使ってみて！
と、お願いしただけです。

そして、その試行第一回目に参加

議論となったのは、
「やらないことリスト」　と
「トレードオフスライダー」

この2つと「夜も眠れなくなるような問題」
の3つは私のお気に入りです。

そのお気に入りの2つで議論となったのは
なんともワクワクしましたね。



やってみて、改めて
インセプションデッキではなく、

「10の手強い質問」

として、次回は、10の質問は以下のタイトルで試行してみようと思いました。

それは、可能な限り、開発で使わない言葉や
極端な言葉を使った質問にする方が
より多角的な視点でプロジェクトを捉えるキッカケになるような気がしたからです。

1　我々はなぜここにいるか？！
2　エレベータピッチ
3　目指すイメージ画像（絵）
4　やらないことリスト
5　ご近所さんを探せ
6　攻撃的な解決策を描く
7　夜も眠れなくなるような問題は？
8　セットとポイントを見極める
9　何を諦めるか
10　何がどれだけ必要か

受託開発に特化する面も多少ありますが、
今後も、このタイトルを模索していこうと思います。