「アジャイル」は形容詞であり、使用方法としては「アジャイル開発」ではなく、「アジャイルな開発」となる。

 

アジャイルは色々言われているが、結局何がしたいかというと、「ほうれんそう（報告・連絡・相談）をきちんとしなさい」と言いたいだけだ。

早く報告しなさい、早く連絡しなさい、早く相談しなさい、ということ。

システム開発上、どういうふうにやればよいのか、という具体例が、XPやスクラム、クリスタル、FDDなどのプラクティスである。

 

だから、ウォーターフォール開発でもアジャイルな開発はできる。

大人数であっても、「ほうれんそう」はできるだろう。

問題は「どうしたいか」でしかない。それだけなのだ。

 

「変化を受け入れる」はその考えからくる。

アジャイルは「ほうれんそう」を早くするために、顧客も開発メンバーとしてみなす。

業務においては顧客の方がプロだが、システム開発においてはこちらがプロだ。

我々は完全性を証明するための方法を知っているのだ。顧客からヒアリングした内容が論理的であるかを検証しなければならず、非論理的でないことは指摘しなければならない。

我々はそのために、顧客にもメンバーとして参加してもらい、徹底的に議論する。

顧客に最初から論理的な要求を出してもらえると思ってはならない。

そんな事が出来るのであれば、我々は必要ない。

 

そして、徹底的に議論していくうちに、いろいろな要件が増えてくるだろう。それは当たり前なのだ。

最初から徹底した論理ではないのだから。だから、それは仕様変更ではない。設計検証の一貫でしかない。

「変化を受け入れる」とはこれに起因する。

全てがこれに当てはまるわけではないが、現在仕様変更といわれているものの大半はこれだろう。

 

結論として、「アジャイルである／でない」はありえない。

「ほうれんそう」の徹底であり、「アジャイルではない」という人は社会人として訝しるべきだろう。

存在する違いは契約の仕方である。

「まるなげ」が既存のウォーターフォール開発であり、

「顧客もメンバーとして一緒に開発する」が本来のウォーターフォール, イテレート, etc.開発である。

 

契約のタイプとしては、次のサイトにまとめられている。

http://capsctrl.que.jp/kdmsnr/wiki/transl/?10-agile-contracts

1.要件定義しない
2.設計書を書かない
3.コードを書かない
4.テストをしない
5.考えつづけることをやめない

1～4をどうすれば実現できるか、5をしつづけること。
5をした結果、残業せざるをえないこともあるが、それは有効な残業として認める。
5をせずにする残業は有効ではない。
それを残業として認めるから、残業が増える。
また、5は人によって程度が変わる。
だれを5にあてるか、がヒューマン・リソース・マネジメントとして必要なことであり、それは上司の問題である。

決して、次のような勘違いをしてはならない。
・明らかに無茶な言い分なのに「残業が発生するのは、お前の考えが足りないからだ」と非難する
・「お客さんのいうとおりに作業をしなければならないんだ」と1～4は実現不可能だと思い込む

基盤を考える人や共通チームが頑張る。
いっぱい仕事をしろっていう意味じゃない。
みんなが余計なことを考えなくて済むように、自分が考えなければいけないことだけを考えるだけ、という環境を整え、回していけるように、考え続けろっていう意味。

例えば、設計者には業務が正しく回ることだけを考えてほしい。
例えば、コーダーには綺麗なコードを書くことだけを考えてほしい。

複数人に同じことを考えさせてはいけない。
する時間も無駄だし、同じであることを確認する時間も無駄だから。

コードとかそういうのよりも、ヒューマンエラーのコントロールの問題の方が大きい。
それで次のことを目指してみたことがある。
・残業をさせない
・退屈な仕事をさせない

結果として、残業させてしまったのだが、他の全チームが徹夜を繰り返しているなか、まったく徹夜せず、バグ問題も発生させなかった。
これで満足してはいけないのだが、思い立っての行動としてはまずまず。

前項にもつながる話だが、チームが上記のようになるよう、考えなければならないものが徹底的に考えるだけ。

テスト（検証）をするんじゃない。
自分がそう主張する根拠を述べるんだ。

東洋哲学に唯識という考え方がある。
「唯、識があるのみ」という考え方で、空の境地に至るための論理みたいなもの。

識とは認識するもの（５感）、認識したもの（意識、無意識）のこと。
例えば、聞いたことは聞いたままのものでしかないにも関わらず、たいていの人は、聞いたことに対して過去の経験や好き嫌いなどの思いを混ぜて変形したものを「聞いたこと」として認識している。
具体的に言うと、顧客からヒアリングした内容を“簡単にして／整理して”設計書に書き表しているが、聞いたことと整理した内容が区別されないため、論理的に結び付かない。「設計書は顧客にヒアリングしたとおりに書いた」と言いつつ、「簡単にしよう」という考えが混ざった別物でしかない。
簡単にしてはいけない、というわけではないのだが、少なくとも、それぞれは別物であることを認識できていなければならない。
そのためには、最初から簡単にしようとしてはいけない。まずはそのとおり書き表す。
そして、それが論理的に正しいことが証明されたあと、再度見たいと思った時に分かりやすくするために、簡単にする。

リファクタリングの目的はこの通り。
まずは正しいもの、求められているとおりに動くものを作る。
そのあとで可読性とか共通性の整理をするためにリファクタリングをする。
最初から変な気を起こして、自分の思い込みで固められたプログラムを書かない。

アジャイルで誤解されている「設計書を書かない」の考えも、これに従えば分かる。
まずは正しいもの、求められている通りに書き表す。
そのあとで、あとで読みやすくするために、「ｘｘ設計書」という書式に整理する。
書式にこだわった「ｘｘ設計書」を先にかいてしまうと、ヒアリングした内容と整理した内容の区別が付きづらいし、それを修正したときに、「ヒアリングした内容が変わり、整理した内容が変わらない」または「ヒアリングした内容が変わり、整理した内容が変わる」の区別もつかない。
もっといえば、書式を整えるのも大変だ。

プログラマは忙しいので、やらなければいけないことだけをやりたい。出来る限り、やらなくていいことはやりたくない。
「やらなければいけないこと」は「ヒアリングした非論理的な内容を論理的に結び付くことを考えること」であり、それがプログラマの仕事といえる。
逆に「やらなくていいこと」はそれ以外だ。前述においては「書式を整えること」がそれにあたる。
そんなプログラマはこんな風に考えるだろう。
「自然言語を形式言語に変換するのは難しいが、形式言語を自然言語に変換するのは表現が固くなるかもしれないが、そこまで難しくもない。ならば、最初からすべて、形式言語(UML)で書き表そう。そのあと、求める人によって、別の形式言語(Code)に変換したり、自然言語(設計書)に変換すればいいだけだ。」
書式はプロジェクトによって異なるから、プロジェクトごとに変換プログラムを作らなければならないだろうが、そのあとのコストを考えると、最初にやってしまった方がトータルで安くつくだろうし、最初にやる分、最初からコストが把握できることが良い。
１プロジェクトに１人はそういう人がほしい。

今までいろんな所でいろんなお仕事をして、それなりに評価を受けてきたわけだが、「他の人も同じようにできるようにするためには、どうしたらいいか？」と言われたことがあり、どうすればいいか悩んだことがある。
私は魔法使いではないので、「時本だからできる」と言われたくない。
私はプログラマなので、「論理的に考えているからできる」と言われたい。

「人に依存するのではなく、論理に依存する」
それを証明するための鍵が哲学だと考えている。

 

プログラマの仕事は「論理的に整理したもの（知識と知恵）」を提供すること。

システムエンジニアの仕事は「ドキュメント（知識）」を提供すること。