ソフトウェア工学

2018/05/08

論文のお作法は、さかばさんから真似る

さかばさんのブログにある論文のお作法の記事がとても良くて、いつも参考にするのでリンクしておく。
以下、ラフなメモ書き。

【参考】
社会人のためのシンポジウム発表入門 リーン論文作法: ソフトウェアさかば

論文の善し悪しをサンプルで見る: ソフトウェアさかば

できる人を観察して勝負する: ソフトウェアさかば

さかば流・論文作法 その1 - 論文の構成 -: ソフトウェアさかば

さかば流・論文作法 その2 - 論文を書く上での注意点 -: ソフトウェアさかば

さかば流・論文作法 その3 - 良い技術 -: ソフトウェアさかば

【1】僕も論文を書くのは嫌いだったかな。
学生の頃、先生からいつもたくさんの指摘を受けて直すのに、OKの返事がもらえなくて苦労した。

今思い出すと、その理由は、論文特有の書き方を知らなかったから、だけでなく、経験した現実とあるべき理想の対立を自分の心の中で強く持っていなかったから、とも思う。
僕は世間にこういうことを主張したい、という熱い気持ちで書き出して、その内容を数多くの人に叩かれたり議論したりして、アイデアを鍛えて、内容をブラッシュアップしていく、という過程を、その頃は経験できていなかったから、とも思う。
ずいぶん自分のレベルが低かったと思う。

まず言いたい主張が先にある。
そこから、その主張がどんな問題を解決するのか、何が課題として今後の研究テーマになるのか、などの骨組みが決まっていく。

【2】さかばさんの下記のツイートが好き。

【2-1】
さかばさんのツイート: できる人は、頭の中で知識の構造を常にリファクタリングしている。凡人は、整理しないままで置いておくから活用できない。大学院で学んだ事の一つです。

僕はSEA関西の知的サロンのような雰囲気が好きなのだが、そこでは、アジャイル開発とか新しい技術とか議論していると、必ず定義を聞かれることがあった。
互いの議論によって、自分が持っている知識体系、理解している知識ツリーに入れば理解できたことになる。
その作業が、知識構造のリファクタリングにつながる。
世話人の方は、たぶんそういう作業を常にされているのだろう。

僕自身の経験でも、いつもポンチ絵を描いている。
モヤモヤしたアイデアを明確にするために絵を描く。
新しい知識を色んな観点で比較評価するために絵を描く。
絵を何度もリファクタリングして描き直すうちに、あるべきイメージが固まっていく。

【2-2】
さかばさんのツイート: @tunemage まずは論文で主張したい点を3つにまとめて、それを裏返して問題設定すると論文の概要ができます。それを端的に表現すればタイトル。用語を説明すれば背景になります。各段落を一行で表した箇条書きを作ってから書き出すと綺麗な構造になりますよ。

普通は、自分が言いたい主張が必ず先に存在する。
その主張から問題点を明確にして、主張を正当化する必要がある。
その作業は、「Justify」と呼ばれている。
数学ならwell-definedに相当するだろうか。

論文作成の技法part2~論文作成の観点 : プログラマの思索

Well-defined - Wikipedia

このJustifyの作業を「主張の裏返し」という言葉でさかばさんが表現されているのは凄いなあ、と思う。
自分の経験を振り返れば、主張と問題点に線を引いて因果になっているか、トレースできているか、自分でチェックしていたけれど、その作業と同じだったわけか。

問題を明確にするというJustifyの作業が重要な理由は、問題となる前提条件、スコープが明確にされなければ、主張したいアイデアが何を解決するのか、一方、現在の主張では解決できないので何が課題として残るのか、というストーリーを説明できなくなるからだ。

自分の主張で、全ての問題が解決するわけではない。
普通は解決できた部分はごく一部だけ。

でも、その主張のアイデアが優れていれば、未開拓の分野にどんどん適用されて、関連研究が広がる。
たとえば、科学者の論文でも、すごく偉い科学者が理論を打ち立てたら、その後続の凡庸な科学者は、その理論を使って細かい問題をしらみ潰しに論文を量産していく、というパターンが多い。
そういう凡庸な論文が多いので、それを関連研究として整理するのもまた一苦労、みたいな感じかな。

【3】論文作成のお作法であるロジックの組み立て方は過去にまとめていた。

論文作成の技法part1~論文の構造: プログラマの思索

【4】さかばさんの「リーン論文作法」の発表資料には、そういうノウハウが濃縮されている。
なので、さかばさんの「リーン論文作法」の発表資料はお勧めです。
ダウンロードできるので、印刷したり、スマホに常に持っておき、いつでも参照すると便利です。

| | コメント (0)

2018/05/06

Excelの表をMarkdown形式に変換するExcelアドオン、Webサービスのリンク

最近、Markdownで資料を書いて、WordやPDF、epubに変換したり、RedmineやConpass等に書く場合が多い。
しかし、いつも表形式が書きにくい。
そこで、Excelの表をMarkdown形式に変換するExcelアドオン、Webサービスをリンクしておく。

【参考1】
選択したExcelのセルをMarkdown形式でコピーするExcelアドインをリリースしました。 - nuits.jp blog

nuitsjp/CopyToMarkdownAddIn: Add-In for copying from Excel to Markdown

Excelのアドオン。
Excel上で右クリックした後、テキストに貼り付けるだけ。
こちらを愛用してる。

【参考2】
Excelの表をMarkdown形式に変換 - Qiita

Markdown Tables generator - TablesGenerator.com

Excel上でコピーして貼り付けるだけ。

【参考3】
Markdown で書いた試験仕様書を Excel に変換するツールを作った

Markdownのテスト仕様書からExcelに変換するツールを作られたらしい。

似たような例として、FreeMindのマインドマップからテストケースを自動生成するツールもあったな。
因子の組合せによるテストケース生成は、ツールを使った方が簡単。

FreeMindからテストケースを自動生成するテストツールFMPictをリリース - 千里霧中

fmpict/manual.md at master ・ hiro-iseri/fmpict

こんな本もあった。

『マインドマップから始めるソフトウェアテスト』を読んでマインドマップを書こう! - そこに仁義はあるのか(仮)

| | コメント (0)

2018/04/28

技術革新とエンジニアのキャリア形成にオープンソースコミュニティの存在が重要性を増している

Publickey主宰者のインタビュー記事を読んで、気付いたことをメモ。
ラフなメモ書き。

【参考】
Publickey主宰者・新野淳一氏に聞く、エンジニアのキャリア・スキルの磨き方、「稼ぐ力」の付け方 - GeekOut

【1】Publickey主宰者のインタビュー記事を読んで、印象に残った点は2つある。
一つは、クラウドとオープンソースにより技術革新の場がベンダからオープンソースのコミュニティへ移ったこと。
もう一つは、エンジニアのキャリア形成に、オープンソース活動やコミュニティ活動による貢献が重要性を増していること。

【2】現在では、技術革新の場はベンダーから発信されるよりも、オープンソースのコミュニティを中心に発信させる場合の方が多い。
たぶん、その事実もかなり知られている。

(引用開始)
取材するスタイルも昔とはずいぶん変わりました。かつてはベンダが一番情報を持っていたので、発表会に出席して、新製品や技術のことを取材していましたが、いまのメインストリームは明らかにコミュニティです。僕もオープンソースのコミュニティの情報や、フォローしているオープンソースエンジニアのTwitterを見て、業界動向をウォッチしています。
(引用終了)

上記の記事のように、一昔前は、IBMやMSなどの大企業の技術動向をウォッチするために、大企業のイベントに出向いて、情報収集するのが普通だった。
でも、今では、LinuxやRuby、Python、Wordpress、LibreOfficeなど数多くのオープンソースが市場を支配して影響を与えている。
これらオープンソースコミュニティに出向いて、優れたコミッタやそのリーダーをウォッチしたり、直接話したりする方が、情報収集が速い。

この変化によって、大企業よりも、優れた中小ベンチャーやコミッタの方がIT業界において、政治的影響力を増している、という事実が挙げられるだろう。
たとえば、UberやAirbnbなどのシェアリングサービスも一気に普及し、昨今のAIブームに乗って大きく成長している。

つまり、オープンソースを中心としたコミュニティが技術革新と新しいビジネスの創出を生み出している。
その変化にエンジニアも付いていかないといけない。

【3】すると、エンジニアのキャリア形成に、オープンソース活動が大きな影響を与えてきている。

【3-1】エンジニアがスキルを向上させるために、オープンソース活動に積極的に関わり、貢献することで、周囲に彼のスキルを認めてもらい、彼自身の価値を上げていく、という成長のらせん構造が生まれている。

(引用開始)
 そうすると、エンジニアの働き方やキャリアも変わります。それまでは、最新技術はほとんどベンダに集まっており、ベンダの技術に詳しい人が求められてきました。しかし、オープンソースという新しい価値観が生まれることで、コミュニティへの貢献がキャリアに好影響を及ぼし、スキルアップにつながるようになりました。そういう新たなエンジニアのヒーロー像が生まれたのです。

 あとは、やっぱりクラウドですね。クラウドの最大の特徴は、一言では表現できないジャンルの広さです。その分、クラウドを活用することは非常に難しくなっている。社内で学べる範囲を超えているんですね。あらゆるレイヤーに精通する必要がありますし、オープンソースやベンダの技術も追っていかなければなりません。技術だけではなく、仕事や業務についても勉強する必要があります。そういう包括的な知識は、単に仕事をこなすだけではなかなか学べないのです。会社の枠を超えて物事を学ぶ姿勢を保ち続けないと、クラウドをキャッチアップできないと思います。

 クラウドとオープンソースが出てきたおかげで、会社の中でキャリアを考える時代から、会社を超えて自分のスキルやキャリアを考える時代へと変化しました。そうでないと、エンジニアは自分のキャリア人生を生き抜けなくなってきています。Linuxが出てきた頃からそういう雰囲気はありましたが、クラウドの登場で、その傾向が一段と鮮明になってきた。僕はそう思っています。
(引用終了)

【3-2】似たような話として、下記の記事もあった。

会津大学で「これからのエンジニア像」についてお話してきました - インフラエンジニアway - Powered by HEARTBEATS

(引用開始)
これからのエンジニア像

この先とか言ってるけど、未来人じゃないから先に事はわからないよ
・なので歴史を踏まえて推測するね

ここ20年を振り返ると、ITは10年でスキルの価値がなくなる業界です
・最先端の貴重なスキル =(10年)=> ふつうのスキル =(10年)=> こどもでもできる

世間的なエンジニアの評価軸が技術領域ベースから価値ベースにシフトしてきたよ
・ネットワークエンジニア => Webサービスエンジニア...

みなさんはきっと75歳くらいまでは働く必要があります
・たぶん私もね

ホワイトカラーは一生勉強し続ける必要があります
・宿命ってやつですね

いまのうちにじっくり基礎から勉強の仕方・活かし方を身に着けておくとよいですよ
・基礎知識と、学びの習慣化をしておこう

とにかくまず学校の勉強をきちんと真面目にやるのが最高
(引用終了)

IT業界にいて、つくづく思うのは、身につけた技術は10年経つと陳腐化してしまい、無意味になってしまう可能性が高い事実だろう。
実際、Cobolやメインフレームでバリバリ、プログラミングして経験を積んで、部課長に成り上がった人達を見ると、彼らの話が既に時代に合わなくなっていることをいつも感じる。
そして、彼らの経験やノウハウが陳腐化されるのと同様に、自分もそうならないか、といつも自問している。

アジャイル開発は常識だ: プログラマの思索

ライフ・シフト」のように、人生100年時代の中で、現代を生きる人は皆、死ぬ直前まで働くことを前提に、一生勉強し続けることを準備しなくてはならないのだろう。

たとえば、昨今は、いわゆる文系の士業は人工知能で代替されるニュースが相次いでいるので、士業の受験者数がかなり減少していて、危機感を持つ人が増えている、という話も聞いた。
いわゆる士業のAI受難だ。
よって、士業だけでなく、普通のホワイトカラーも、価値を生み出さないエンジニアもAIで代替されてしまうリスクがあるのだろう。

AIによる代替可能性90%以上の士業は3つの士業 | 株式会社ネクストフェイズ

では、技術や知識を得たとしてもすぐに陳腐化してしまう時代において、どんな方針で働くべきなのか?

現状では、社内研修やOJTだけでは、エンジニアのキャリア形成は不十分だ。
むしろ、エンジニア自身が積極的に、オープンソース活動に加わった方がいい。

現代では、オープンソースコミュティが技術革新の発信源であるからだ。
だからこそ、オープンソース活動に加われば、自身より優れた開発者と交流することで、やる気も出るし、自身の能力向上にも役立つ。

自分にも銘じておく。

| | コメント (0)

2018/03/29

SwaggerでWebAPIドキュメントをExcel仕様書から脱却するアイデア

Swaggerを使うと、WebAPIドキュメントをExcel仕様書から脱却してシステム化することができる。
自分はまだ無知なので、以下は自分用のメモのリンク。

【参考1】
【連載】Swagger入門 - 初めてのAPI仕様管理講座 [1] Swaggerとは|開発ソフトウェア|IT製品の事例・解説記事

(引用開始)
システム開発のトレンドとして、マイクロサービス化が進んできています。モノリス(一枚岩)スタイルの開発に比べて、アプリケーションの単位は小さくなり、多くのサービスが構築されます。

Uberの配車ビジネスやAirbnbの民泊に代表されるデジタルビジネスにおいても、APIエコノミー化が進んできており、Google Map APIやTwitter APIなどさまざまなAPIを組み合わせて素早くシステムを構築します。
Programmable Webでは、2017年1月時点で16,590以上のAPIが検索可能で、2009年9月の10倍以上、2006年5月の90倍近くに達しています。

では、そういったマイクロサービス・APIエコノミーの開発現場では、一体どのようなことが起こっているのでしょうか。

例えば、Androidのアプリから叩いているサーバのAPIが機能追加されたために、3日間かけてテストして終わったと思ったら、いつのまにか更なる仕様変更が入っていた。APIのインタフェースを定義するドキュメントの仕様に従ってアクセスしたら、実は実装との乖離があり、うまく動かなかった。

このようにAPIプロバイダとAPIコンシューマ間の悩みはさまざまです。ただし、いずれもサービスインに影響を及ぼす重大な問題と言えます。インタフェースの向こうの世界は関与できないことが多いだけに、仕様と実装の乖離はあってはならないものなのです。
APIエコノミーを作るにあたり、このようなことを起こさないためにも、APIについて正しく記述した仕様書が必要となってきます。
(引用終了)

【参考2】
Swaggerとは何か? - プログラマでありたい

Swaggerを使ってインタラクティブなWeb APIドキュメントをつくる - Qiita

SwaggerでRESTful APIの管理を楽にする - Qiita

Swaggerの概要をまとめてみた。 - Qiita

【Swaggerの実例】
API リファレンス | SORACOM Developers

【1】Webシステムをモノリック・アーキテクチャからマイクロサービス・アーキテクチャで設計することで、まるで部品を組み立てるかのように、迅速にシステムを構築することが可能になった。
つまり、斬新なアイデアを実現するWebサービスを素早くリリースして、市場のニッチリーダーからシェア独占を狙って、先行者利益という独占利潤を得たいわけだ。

例えば、Uberの配車ビジネスやAirbnbの民泊。
日本なら、例えば、メルカリ、DMMとか。

現代は、これらシリコンバレー発祥のWebサービスが、自動車業界やホテル業界を直撃している、と言える。
よって、マイクロサービス・アーキテクチャで作られたWebサービスは、ありとあらゆる業界のビジネスモデルを一瞬にして破壊してしまう可能性が高い。
だから、こういうAPIエコノミーに対し、古い業界の人達も戦わざるを得ない。

【2】しかし、マイクロサービス・アーキテクチャの根幹となるWebAPIは、VerUpによってコロコロ変わってしまう問題がある。
そこで、I/F仕様をWebで公開して、即時に情報共有できるようにしたい。

つまり、マイクロサービス・アーキテクチャの実装基盤であるREST APIのI/F仕様を公開できるようなWeb基盤が欲しいわけだ。

【3】そこで、その候補として、Swaggerがあがる。
Swaggerの特徴は、「インタラクティブなWeb APIドキュメント」。

つまり、単純にWebへ公開できるドキュメントが作成できるだけでなく、リクエストを入力すればレスポンスを表示できる仕組みまである。
すなわち、APIをWebに公開できるだけでなく、使用しているAPIがVerUpしても使えるかどうか、事前に自動テストすることも可能。
これによって、Webサービスをリリースする時、利用しているAPIが使えなくなった、というリスクを減らすことができる。

たとえば、ソラコムさんのWebサイトが最も良い事例だろう。

API リファレンス | SORACOM Developers

上記の記事にもあるが、Dockerによるビルド環境構築やCIツールをSwaggerと組み合わせれば、マイクロサービスで組み立てたWebサービスの自動テスト、デプロイやリリース作業の自動化にもつながるだろう。
つまり、マイクロサービスで作られたWebサービスの品質向上、開発速度の向上にも役立てられるはず。

但し、Swaggerで全ての問題が解決されるわけではなく、まだ課題もある。
たとえば、Swaggerて゛のapi開発よもやま話の18ページにあるように、たくさんのAPIを一瞥できるような『オブジェクト構造図(仕様書のObjectの参照関係を階層構造で定義)』が欲しくなる。

【4】今の僕は、Excel仕様書からいかに脱却するか、というテーマを持っているが、その中でも、I/F仕様書は色んな意味で重要性が高い。

なぜなら、公開したI/Fというものは、自分のチーム以外の他チームも参照するので、説明責任が発生するし、I/Fの仕様はシステムのVerUpによって変わってしまう時が多いのに、その変更内容をExcelドキュメントへ反映する手間が結構かかるからだ。
しかも、I/FがVerUpで変わった、という事実を他チームにも随時連絡する手間も発生する。

よって、I/Fが変わったら、自チームがプッシュ通知するのではなく、他チームがプル通知で自動検知する仕組みの方が運用が楽になる。
そこで、SwaggerのようなWebAPIドキュメントの基盤を有効に活用できるだろう、と思う。

【4-1】ここで、I/F仕様書がSwaggerで置き換えられる可能性を考えると、現代という時代は、Excelドキュメントを一生懸命に書くよりも、仕様書というモノさえプログラミングする時代なのだ、という気がしてくる。

実際、単体・結合テストなどのテスト工程の作業は、TDDやCIなどの開発支援ツールでプログラミング作業に集約できる。
また、デプロイやリリース作業、そしてビルド環境や本番環境のインフラ構築作業も、DockerやGitHub、CIツール、AWSなどのクラウド環境などの技術によって、プログラミング作業で代替できるようになった。

今後は、要件定義や設計作業ではExcelドキュメントを書く、という作業も、きっとプログラミング作業で代替されるようになるだろう。
つまり、いちいち自然言語で要件や仕様を書くよりも、YAMLやJSONに似たデータ構造あるいはDSLによって、いきなりプログラムを書いた方が速いし、その後の保守更新も楽になる、という方向へ進化していくはずだ。

仕様書をプログラミング作業の本体であるテキストで代替できれば、Gitで管理できるし、そうすれば、TDD・CI・プルリクエスト・継続的デプロイなど昨今の開発支援技術の恩恵を受けられる。
よって、ドキュメントの情報共有が促進され、フィードバックを受けて修正すれば、仕様書の品質そのものも向上できるはず。

では、仕様書のExcel脱却の起点となる課題は何か?
答えは、Gitで管理できるか、そして、テキストからAPI仕様書や図表などを自動生成できるか、という課題に集約されるだろう、と思う。
幸いなことに、MarkdownやPlantUMLなどの記法でテキスト化すれば、HTMLやOfficeドキュメント、PDFへ自動生成するツール(Pandoc、MkDoc、他たくさん)で、今まさにたくさんの技術が実験されている。

この辺りの技術も、技術の進化の歴史の観点で今後整理していきたい。

| | コメント (0)

2018/03/23

製造業の品質管理の背後にあるSDCAという考え方をソフトウェア開発に適用できるのか

製造業の品質管理を調べてみて、その背後には、「SDCA」という考え方があるのではないか、と考えてみた。
ロジカルでないラフなメモ書き。

【参考】
日常管理 - エクセルQC館

PDCAサイクルとSDCAサイクル【品質改善と維持管理の考え方】

mame1

「当社の業務改善サイクルは『SDCA』」 トステム 佐藤方厚 執行役員IT推進統轄部統轄部長 | 日経 xTECH(クロステック)

【1】製造業の品質管理では、「標準化(Standard)」という言葉が頻繁に使われる。
彼らの意図としては、定型化できる作業、皆が知るべき技術ノウハウは標準マニュアルで整備して、安定した状態(品質)にすべき、という考え方がある。

たとえば、工場で大量生産するネジを作る時、不良品がたくさんできて歩溜まりが低いと、製造原価が高くなってしまう。
製造作業が不安定であると、製品の品質のブレが大きくなってしまうからだ。
つまり、管理図で言えば、UCLやLCLを超えた製品が多くなり、品質不良として出荷できなくなることを意味する。

そこで、ベストプラクティスを標準化という名の下に作業マニュアルにしてしまい、作業員はその作業マニュアルに従って作業すれば、安定した品質となり、歩溜まりが向上する、という方向へ持っていく。

その考え方をプロセスとして定めると、SDCA(標準→Do→Check→Action)という流れになる。
まずは標準を守って、そこから実施して評価し、是正対策を取って、標準を更新していく、という流れ。
つまり、PDCAサイクルで品質統制を行う発想だ。

このプロセスは、量産品を作るメーカーだけでなく、チェーン展開するサービス業や飲食店などにも適用しやすい。
どこに言っても同じサービスや料理の味を低価格でそこそこの品質で提供する、というやり方が向いているからだ。
たとえば、大量のアルバイトや社員を雇ったサービス業として、コンビニ、小売業、航空機内の客室乗務員、ホテルのオペレータとか。

また、個人経営の飲食店であっても、毎日提供する料理の品質を安定させることができれば、原価低減でき、利益を安定的に確保しやすくなる。

【2】しかし、昨今の時代の流れの中で、特にソフトウェア開発では、SDCAの考え方は向いていないと思う。

たとえば、業務ルールを策定したり、技術ノウハウを共有したい、と考えるWF型開発に偏ったプロジェクトリーダーは、Excelドキュメントでそれらをまとめて、共有ファイルサーバーに置いて、メールで告知して共有しようとする。
しかし、その内容はすぐに忘れられて、同じようなことを何度も繰り返す。

あるいは、社内の標準プロセスを定めて、設計書テンプレートのExcelドキュメントを作り、すべての案件に適用しようとするが、受託開発から保守案件、実費請求の要件定義案件まで多種多様なPJがあると、一つの標準では当てはまらない。
結局、数多くのカスタマイズによる派生ドキュメントが発生し、標準からどんどん離れていってしまう。

組込みソフトウェア開発のプロセス改善の違和感: プログラマの思索

【3】では、なぜ、ソフトウェア開発では標準化という考え方が上手くいかないのだろうか?

僕の考えでは2つあると直感的に思う。

【3-1】一つは、ソフトウェア開発は、組織能力よりも、個人のパフォーマンスに依存する度合いが強い事があると思う。

ソフトウェア開発では、システムの技術ノウハウや設計ノウハウは人に付いて回る。
たとえば、受託開発したシステムを本番リリース後、大量の派遣・委託のプログラマが抜けると、システムに関する知見もチームから失われ、保守コストがどんどん大きくなる、という事例はよく見かける。
そのために、数多くの設計ドキュメント、ノウハウを書いたExcelドキュメントを大量に残すけれど、結局役立たない。
システムは保守するたびにどんどん変化していくので、それらドキュメントも古くなり陳腐化してしまう。

また、新しい技術の知見も人に付いて回る。
ドキュメントを読むよりも、その人に聞いたり、レクチャを受けた方が速い。

「現場から始めるアジャイルの技術プラクティス」資料が素晴らしい~技術は人やチームに残る: プログラマの思索

すなわち、標準化しようとしても、形式知化できない部分があるし、暗黙知の部分の方が大きすぎる。
ゆえに、ソフトウェア開発の生産性は個人の能力に依存する度合いが大きく、それを組織で維持ししていくのは非常に難しい。
よって、個人のパフォーマンスを最大限に発揮できるような環境や組織体制を整備する方向へ持っていくべき、というのが最近の時代の流れなのだろう。

たとえば、議論しやすい場を設けてお菓子を用意する、プログラマが座る椅子を高価なものにする、最新のPCやサーバーを用意する、などのファシリティ(資産)が重要な理由は、個人のパフォーマンスを発揮できる環境づくり、という意味もあるのだろう。

そして、アジャイル開発がプログラマに好まれる理由の一つは、アジャイル開発は組織駆動ではなく、個人のパフォーマンス駆動であり、人重視のプロセスでやり抜く、という点にあるのだろう。

だから、人を大切にすることで、システム開発で得られた知見をチームに残す、という発想につながるのではないか。

アジャイル開発とウォーターフォール型開発の違いについて再考: プログラマの思索

【3-2】もう一つは、Excelドキュメントと相性が悪い点もあるように思う。

技術革新が速いので、Excelドキュメントに書いても、陳腐化してしまう。
Excelドキュメントの賞味期限が短すぎるのだ。

そして、Excelドキュメントは履歴管理しにくいし、検索しにくい。
日付の入ったファイル名のExcelが増殖し、最新の内容がどこにあるのか、作った人も分からなくなる時もある。

そこで、技術ノウハウはWikiに書いて残す、という手法もある。
もちろん、Wikiの内容も陳腐化してしまう可能性は高いが、Webで公開されていれば、他の人が気づいて更新することもできる。
全文検索エンジンによって、有用な情報だけ探す、ということもできる。

標準化した情報がすぐに陳腐化してしまうなら、その内容を即座に更新できたり、それらを即座に共有できたりする基盤があれば、ある程度は解決できるはずだ。
この辺りの内容は、一つのテーマとして、ずっと考えている。

仕様書にもExcel脱却が求められている: プログラマの思索

PlantUMLを使ってExcel設計書をテキスト化するアイデア: プログラマの思索

静的ジェネレータを使ってExcelマニュアルをWeb公開するアイデア: プログラマの思索

【4】SDCAという考え方が合わない場面が増えているのは、定形業務のビジネスモデルが最近は儲かりにくい、という点にもあるのだろう。
「Software is eating the world」という流れでは、定形業務や低賃金労働は全てソフトウェア化できるし、ソフトウェア化されたビジネスは、限界費用ゼロまでコストが徹底的に低くなる。
すると、人間の手でSDCAサイクルを回して品質管理をやっていく、という悠長なやり方は通用しにくくなるのではないか。

「ソフトウェアが世界を飲み込む理由」「ソフトウエア、それが問題だ」の記事のメモ: プログラマの思索

『ソフトウェアが世界を飲み込む理由』 - 渡部薫 ジークラウド CEO - 経歴・略歴 - Kaoru Watanabe, Profile, Career

ソフトウェアが世界を変えている – うめのんブログ

この辺りも整理してみる。

| | コメント (0)

2018/03/21

静的ジェネレータを使ってExcelマニュアルをWeb公開するアイデア

ちょっとしたExcelマニュアルの内容を公開する仕事があって、色々調べたこと、考えたことをラフなメモ書き。

【参考1・MkDocs】
MkDocs

ドキュメント作成ツール > MkDocs - Qiita

MkDocsでドキュメント管理 - notebook

ドキュメント生成ツール「MkDocs」でRedmine Guide日本語訳のWebサイトを作ってみた - ファーエンドテクノロジー株式会社

【参考2・Jekyll】
まだWordPressで消耗してるの?Netlify CMSでブログを作成しよう! - Qiita

Jekyll ? シンプルで、ブログのような、静的サイト

Jekyllで作るシンプルWebサイト - Jekyllとはなにか | CodeGrid

GitHub Pages の Jekyll で Web サイトを無料公開する方法 - Qiita

【1】Excelマニュアルの問題点

IT業界では、設計書のたぐいは、とにかくExcelでマニュアルを作りたがる。
インストールマニュアル、製品マニュアル、運用マニュアルなど。

Excelマニュアルの一番の問題は、誰も見なくなることだ。
共有ファイルサーバーにExcelマニュアルを置いてメールで連絡しても、そこにたどり着いて、Officeファイルを開かなければ見れない。

マニュアルを作った本人としては、皆に周知して使ってもらいたいのに、いつも、どこにあるのですか?という問合せばかり受ける。
こういうExcelマニュアルのたぐいは、社内イントラ上で公開できればいいのに、といつも思っている。

また、社内ポータルにリンクを貼っておけば、検索エンジンや更新案内で、勝手に見てくれるようになる。
つまり、マニュアル設計者がプル戦略で周知できる仕組みを作ればいいはず。
すなわち、多数のユーザが自ら情報を引き出すような仕組みを作ればいい。
プロモーション戦略におけるプル戦略と考え方は同じ。

では、マニュアルをプル戦略で公開する仕組みはどう作ればいいか?

【2】静的ジェネレータの使い道

【2-1】マニュアルのようにドキュメントの構成が統一的で簡単であるならば、静的ジェネレータでHTMLを自動生成してApacheで公開するのが一番簡単だ。
静的ファイルを配置するだけでいい。

この発想に落ち着くまでに、CMSのような製品も必要か色々考えてみた。
しかし、複雑なドキュメントを書くのでなければ、静的ジェネレータでHTMLを生成するので十分。

たとえば、OSSのCMSならば、WordPressが一番有名だ。
ブラウザ上で更新できるし、管理画面や機能も豊富だ。

しかし、公開後のアプリ保守やインフラ保守を考えると、セキュリティパッチやVerUpのたびにWordPress本体の保守作業が発生して、かなり手間がかかる。
また、機能改善のためにプラグインを導入せざるを得ないが、WordPress本体のVerUpでプラグインの動作保証まで検証するコストも発生してしまう。
つまり、その後の保守コストが結構かかってしまう。

一方、静的ジェネレータであれば、普通は、Markdownでドキュメントを自然言語で書けるし、CSSやJavaScriptでプログラミング・ライクに装飾できるし、Gitのようなバージョン管理ツールと相性も良い。
Gitでバージョン管理できれば、ビルド管理やデプロイ管理も、今までの自分が持っているノウハウで自由にカスタマイズできるし運用しやすくなる。

ドキュメントの中身を保守更新することを考えると、コンテンツそのものはMarkdownでテキスト化してGitで管理して、いつでもビルド・デプロイできる環境を作っておいた方が良いと思った。

【2-2】では、お勧めの静的ジェネレータは何が良いのか?

単純なExcelマニュアルの元ネタは、Markdownやマインドマップで書いているので、個人的には、MkDocsで十分だった。

Pythonを入れて、インストール
pip install mkdocs

MkDocプロジェクトを作り、Markdownでどんどんテキストに書いていく。
mkdocs new my-project
cd my-project

書いたら、localhost上でプレビューしながらチェックする
mkdocs serve

ビルドしてHTMLを生成したら、それをAacpheへアップして公開するだけ
mkdocs build

他の記事を探してみると、CMS代わりの静的ジェネレータは色々あるみたい。
個人的には、Ruby製のJekyllを触っていて、Blogコンテンツを移行できないかなあ、とか思っている。

Jekyllのメリットは、Blog記事をMarkdownで書き溜めておけば、GithubPagesでそのままWeb公開できる仕組みがあるからだ。
GitHubでバージョン管理して、静的HTMLをビルドしたら、GithubPagesへデプロイするような仕組みを作っておけばいい。

もちろん、静的ジェネレータは他にも色々ある。
大量のMarkdownドキュメントになってくると、もっと他の選択肢が必要になるのかな、と思う。

静的サイトジェネレーターは脱CMSなブログが作れるツール | Qookie Tech

WordPressの代わりになる!2018年注目の静的サイトジェネレーター6選|ferret [フェレット]

静的サイトジェネレータを比較してみた - Qiita

【3】他の解決方法

【3-1】一昔前なら、PukiwikiのようなWikiで、こういうノウハウを書いて社内で共有するのが一般的だった。
最近はQiitaのように、技術ノウハウをWeb上で記述してストックし、公開して知見を共有するスタイルが流行しているように思う。

つまり、静的ジェネレータが最善の解決策ではない、とは思っている。

でも、製品マニュアルや技術ノウハウなど、不特定多数のユーザに情報共有したい内容をExcelマニュアルでまとめるのは、もう時代遅れではないか、と思う。
Qiitaにせよ静的ジェネレータにせよ、Web上で公開する仕組みが時代として要求されている、と感じる。

自分では大したことはない、と思う情報であっても、インターネット上あるいは社内イントラ上で公開されていれば、他の人が検索エンジンによっていつでも探し出すことができる。
つまり、検索しようとする人たちが、そのコンテンツに新たな価値を見出してくれるわけだ。

【3-2】Qiitaが静的ジェネレータよりも優れている点は、コメントやリンク、いいね、タグ機能など、著者と読者がインタラクティブにコミュニケーション出来る環境を提供している点だろう。
それによって、著者もフィードバックから得るものがあるし、他の記事と相互リンクすることで、記事の価値も高まる。
自分のアイデア、得られたノウハウは、一人で貯めておくよりも、Webで公開した方が、読者によって新たな価値を創りだしてくれるメリットがある。

【4】最近の自分のテーマは、Excelドキュメントをいかにテキスト化して、Gitのバージョン管理の配下に置けるようにできないか、だ。
それについては下記で色々考えていて、まだ試行錯誤中。

PlantUMLを使ってExcel設計書をテキスト化するアイデア: プログラマの思索

仕様書にもExcel脱却が求められている: プログラマの思索

今回の静的ジェネレータの件も、Excelマニュアルをいかに駆逐するか、という点で方向性は同じ。

プログラムだけでなく、設計書やマニュアル、ブログ、プレゼン資料のような自然言語で書くドキュメントも、Gitで構成管理できるようになれば、昨今の開発環境の技術革新の恩恵を受けられるはず。
このアイデアがどこまで実現可能で、どこまで問題や課題をクリアしてくれるのか、考え続けている。

| | コメント (0)

2018/02/04

第18回Redmine大阪の感想 #RedmineOsaka

第18回Redmine大阪の感想をメモ。
疲れているので、ラフなメモ書き。
書きかけなので、また後で書く。

【参考】
第66回 SEA関西プロセス分科会&第18回 Redmine大阪 - connpass

2018/2/3 第66回 SEA関西プロセス分科会&第18回 Redmine大阪 - Togetter

第18回Redmine大阪のまとめ | MadosanPlace 新しい風をプラス!

【1】気象庁のRedmine利用事例の話は、本当に面白かった。
JAXAのRedmine運用とは、また別の観点の思想を持って運用されている。

第65回 SEA関西プロセス分科会&RxTStudy #15 「チケット管理システムによるプロセス支援と今後の課題」の感想: プログラマの思索

第13回東京Redmine勉強会の感想~『Redmineの今と未来』 #redmineT: プログラマの思索

気象庁内のシステムには、天気の予測シミュレーション、PM2.5やら色んな気象データのデータ収集と分析、シミュレーションなどがある。
それらのシステムは、全て内製化されている。
つまり、気象庁の研究者がプログラマとなり、実際に開発している。
この点は、JAXAなど他の官公庁とは全く違う。

だから、気象庁では、数値予報官という役職だけでなく、「プログラマ」という名前の役職も公式に存在する。
この点も他と大きく異なるのだろう。

【1-1】気象庁内では、Fortran、シェル、Rubyが一般的なプログラミング言語。
数値予測などの科学計算は過去の開発資産があるので、Fortranが使われている。
一方、仮想サーバー構築、バッチ処理、インフラ構築などは、シェルとRubyがよく使われている。

【1-2】気象庁では、部署もあるが、開発はシステムごとに、各部署を横断してプログラマや研究者が集まって担当する。
そのシステムに携わる集団を開発コミュニティと呼ぶらしい。
僕の理解では、マトリクス型組織のように思えた。
つまり、研究者やプログラマは部署に所属するが、天気予報、シミュレーション、共通基盤などの各システムの開発に携わるので、クロスファンクショナルなチーム構成になる。

但し、プログラマはどこか一つのコミュニティに属する運用になっているので、複数のコミュニティに所属することはほとんどない。
つまり、各開発コミュニティは縦割り組織に似たような雰囲気になっているみたい。

【1-3】最近は、欧米の気象庁ではPythonを使って数値予測プログラムを書く事例が多くなってきたので、彼らから、なぜまだFortranを使っているの、Pythonなら他言語のライブラリや資産も簡単に呼び出して使えるので、Pythonがいいよ、と言われているため、Pythonをこっそり試し始めている、とのこと。

この辺りの話を聞くと、海外の研究動向にも追随しながら、最先端の技術を導入しようという雰囲気が既にあるのだろう。

【2】気象庁では、各開発コミュニティごとに「あえて」Redmineインスタンスを複数個立ち上げた意図

バージョン管理は、2000年代からCVS、Subversion、Gitへ移行してきた。
2008年頃から、各コミュニティが独自にTracやRedmineを使い始めた。
原さんが海外の動向を踏まえて、各開発コミュニティがバラバラな開発基盤を持つのではなく、共通の開発基盤で運用すべきだ、と提案して、2014年頃から、RedmineとSubversion、Gitを共通の開発基盤として各コミュニティに提供する運用になったらしい。

その時、1台の物理サーバーに1個のRedmineインスタンスで運用する案も考えられたが、一つのRedmineの運用ルールに縛ることを目的とすると、各開発コミュニティから反発が起きるかもしれないことと、各開発コミュニティの組織文化を尊重することも考慮して、複数個のRedmineインスタンスを各開発コミュニティごとに立ち上げることになったらしい。

【3】2段階コードレビューの意図

【3-0】Redmineを導入した動機

そもそも、RedmineやSVNを開発基盤として導入しようという契機になったのは、コードレビューをしっかりやるべきだ、という考え方が、原さんだけでなく、各開発コミュニティでもそのような気運が盛り上がっていたから。

たとえば、天気予報の数値予測シミュレーションのようなプログラム開発では、理論物理や流体力学など科学理論から導かれる機能要件から、それに基づくプログラム実装が行われる。
しかし、かつてはバージョン管理すらなかった時代では、なぜそのような機能が実装されたのか、なぜそんなソースコードになったのか、記録が残っていない。
しかも、科学理論の発展やソフト・ハードの進化に伴うプログラム修正の履歴やその変更理由も残されていない。
だから、システムのリリース後に障害が発生して、トラブルが起きることがあったから。

【3-1】2段階コードレビューの意図

Redmineではコードレビューのプロセスはワークフローの一部として運用されている。

興味深い点は、気象庁のコードレビューでは、2段階レビューが踏まれていること。
まず、サイエンティフィック・レビューでは、科学者の観点で、数値シミュレーションが物理法則や物理の理論に基いた要件でコードが実装されているか、レビューされる。
おそらく、研究者同士の議論に近い雰囲気なのかもしれない。

次に、ソースコードがプログラミングの観点できちんと書かれているか、という立場でコードレビューされる。
Fortranのコーディング規則に従っているか、エラー処理、とか、この部分は我々のコードレビューと同じだろう。
また、物理法則の要件に従って実装されたプログラムを、実際に膨大な気象データに基いてシミュレーションするテストも行う。
このテストには、半日で終わることもあれば、数週間かかることもあるらしい。

たとえば、そこで性能が出なかったりすることが分かれば、その要件の実装はソフトウェア的に実現可能性が低いので、別の代替案を考える、などのフィードバックがコードレビューで行われる。

つまり、単なるコーディング規約のチェックだけでなく、たとえば性能要件を満たすかテストしてみた結果をフィードバックする、などの作業も行われている。

この辺りは、アーキテクチャのフィージビリティ・スタディ、つまり、アーキテクチャ実装のコスト・品質・納期のトレードオフを評価しているのと同じように思える。

これら2段階レビューは、既に欧米の気象庁では行われているので、日本でもやるべきだ、という提案があり、徐々に浸透しているらしい。
そういう内容を聞くと、Redmineチケットにコードレビューの結果を記録し蓄積していくことは非常に有意義な作業であることが理解できる。

【3-2】そして、git-flowによる並行開発とコードレビューが組み合わされて、上手く運用されるようになっているらしい。
つまり、ある要件を開発する場合、trunkからブランチを派生し、そのブランチ上で修正して、コードレビューが完了になれば、trunkにマージされる。
そのブランチはRedmineチケットと対応付けられて、Redmineチケットに要件や仕様、コードレビューの結果などが全て記録される。

【3-3】気象庁のRedmineでは、チケットのカスタムフィールドは使わないし、複雑なワークフローも設定されていないし、プラグインもほぼない。
Redmineのチケットに、コードレビューの指摘、結果、対応の記録を残すことに注力している。
そのおかげで、海外派遣で2年間、気象庁から離れた研究者も、帰国した後、Redmineのチケットを検索するだけで、すぐにプログラム開発の仕事に復帰できた、と言っていたらしい。

つまり、気象庁のRedmineは、進捗管理用のRedmineではなく、ナレッジ資産の為のRedmineなのだ。

【4】複数個のRedmineインスタンスで運用されるデメリットは、原さんによれば特に感じていない、と言われていた。
もし、他コミュニティのRedmineを参照したい場合、RedmineにはRSS機能があるので、RSSをフィードすれば、リアルタイムにチケット更新の状況を把握できる。

【4-1】また、Redmineという開発基盤が普及した後、Redmineの副次効果がいくつかあったらしい。
たとえば、あるコミュニティで、コードレビューはプログラム実装後に行うのではなく、プログラム実装前に関係者が集まって事前に内容を協議する運用を始めた所、他コミュニティでも、その運用はもっともだ、という意見があり、他コミュニティにも徐々に反映されたらしい。

つまり、あるコミュニティのRedmineのベストプラクティスが他コミュニティにも自然に横展開された、という事実を示唆している。

また、気象庁がいくら先進的な官公庁であっても、やはり役所なので縦割り組織の雰囲気がある部分はある。
しかし、Redmineを利用することで、コミュニティ内では、チケット経由のやり取りによって、研究者の知見やソース修正の履歴が記録されて、メンバー間の情報共有がスムーズになったらしい。

【4-2】さらに、データ処理など共通の処理を行う基盤担当のコミュニティがあり、そのコミュニティは気象庁の各コミュニティと関係するが、そのコミュニティのメンバーは、各コミュニティのRedmineにログインできる。
すると、各コミュニティでRedmineやコードレビューの運用ルールが微妙に違うので、同じように運用したい、という声が上がっているらしい。

つまり、現状はあえてコミュニティ単位の複数Redmineインスタンスで運用しているけれど、現場から、ボトムアップでRedmineの標準化を図るべきだ、という声が上がっているわけだ。
将来は分からないけれど、いつか、単一の標準Redmineにサーバー統合される可能性があるかもしれない。

【4-3】この点に関して、参加者からは、Redmineではトラッカーやカスタムフィールドがグローバル変数のような性質のために、使いづらくなっている。
Redmineにも、サイトのような機能を持たせて、各プロジェクトごとのトラッカーやワークフローを定義できるようにすれば、一つのRedmineインスタンスで、各プロジェクトごとにトラッカーやワークフローの自由裁量の権限を与えて運用できるのではないか、という指摘があった。
この意見は全くその通り。

以前も、東京Redmineでも似たような議論があった。

Redmineのワークフロー設定を拡張する機能提案~Redmineは汎用的なBPMツールになりうるか: プログラマの思索

【4】個人的には、Redmineは単一インスタンスの運用だけでなく、複数インスタンスの運用もベストプラクティスの一つになりうる、という発見があって、改めて深く考えさせられた。
この点はまたまとめる。

akipiiさんのツイート: "#RedmineOsaka #seakansai 気象庁の事例ではRedmineをナレッジ基盤として使う運用を目的としたら、色んな副次的効果も出てきた。単一の標準Redmineがベストの先入観があったけど、Redmine の複数インスタンスでも成功事例があるのは改めて衝撃を受けた。奥が深いね。"

Redmineインスタンスとプロセスの関係~Redmineは組織に従うのか、Redmineに合ったチームを作るべきか: プログラマの思索

【追記】
今回のRedmine大阪で、気象庁における開発管理の取り組みの公開資料に基いて、Redmineのチケット管理やGitによるブランチ管理やコードレビューについて数多く質問したのだが、「テストハーネスを用いたテスト自動化」の内容は聞き漏らしてしまった。
おそらく、Fortranプログラムをシェルからバッチで起動して、入力データと出力データを差分比較するようなテストを自動化する仕組みを取り入れていると思われる。
この部分のノウハウも聞きたかった。

気象庁における開発管理の取り組みの公開資料のP.52で下記の引用がある。

(引用開始)
asuca については、トランクへの変更がなかった場合も含めて、テストハーネスと呼ばれる仕組みを毎日自動で実行している。
これは
・ 理想実験
・ 石田ほか (2014) で述べられている、2 次元定常山岳波、周期境界条件における重力波、暖気塊のテスト、重力流、St-MIP
・ 静止大気実験
・ 2 次元スカラー移流
・ 3 次元モデル 3 による狭領域実データ実験
・ 局地解析
・ 接線形モデルチェック
・ 随伴モデルチェック
・ 局地予報
・ メソ予報
といった様々なケースについての実験 4 が、最新のトランクを用いて行われる。
入力データは毎日同じものを用いるため、入出力システムの変更等、予報結果を本質的に変える変更でない場合には、結果はビットレベルで一致する。
自動実行されたテストハーネスの結果は毎日メールで報告され、結果が前日とビットレベルで合わない場合にはそのようなメッセージが付加され、開発者が覚知することができる。
このため、トランクへのマージを行う改変については、テストの段階で開発者が自らテストハーネスを実行し、その結果についてもチケットに記録する。
また、変更の前後で結果が一致しない場合には、その理由や差の妥当性(分布図で見た場合の評価等)も含めて、記録を行う。
(引用終了)

| | コメント (0)

2018/01/27

開発プロセスを管理することでしか、ソフトウェアの品質は管理できない

ネットでフラフラしていたら、偶然良い記事を見つけたのでリンクしておく。
特に主張は無し。
ラフなメモ。

【参考1】Embedded Software Manufactory: ISO 26262との向き合い方 (21) 安全について理解を深める

【1-1】「開発プロセスを管理することでしか、ソフトウェアの品質は管理できない」という文言にしびれた。
ああ、そうなのか。
自分がRedmineにハマっている理由は、たぶん、Redmineを通じて開発プロセスをモニタリングすることで、ソフトウェアプロダクトの品質・コスト・納期を調整しようと暗黙的に行っていたから、と思う。

でも、プロセスアプローチの発想は、アジャイル開発とは異なる。
アジャイル開発は、プロセス重視ではない。
では、その部分はどう解釈するべきか?

(引用開始)
しかし、何もしないで放っておく訳にはいかないので、ソフトウェア開発プロセスによるアプローチを定義することになる。これは現在のところ、どの業務ドメインでも同じようだ。開発プロセスを管理することでしか、ソフトウェアの品質は管理できないというのが、ソフトウェア品質論の定説となっている。(『ソフトウェア品質論の歴史的推移』を参照されたし)
(引用終了)

【1-2】IT業界では、新しい技術や設計思想は、熱意を持った人がエバンジェリストとして普及させる必要がある、という経験則があるのだろう。
Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン」の最初にも「エバンジェリスト」があったなあ、と気づく。

(引用開始)
そして今では、安全とは何かについての考えが深まっていない人々に対して、どうすれば安全の概念についての考えを深めることができるのかを伝えることが自分の責務だと考えるようになった。
(中略)
Microsoft の社員の肩書きで Evangelist(エバンジェリスト:伝道者)というのを見たことがあるだろう。上に書いた役目は Journalist とか、Consultant ではなく、Evangelist が一番ぴったりくるかもしれないと思っている。
宗教じゃないから伝道という言葉はあまり好きではないが、人間はコンピュータのように常に論理的とは限らないから、熱意を持って伝えないと伝わらない。自然科学ではない、ソフトウェアに対する考え方は、説明ではなく伝道でないと伝わらないことを Microsoft はよく分かっているから、その道のエキスパートに Evangelist を名乗らせているのだと思う。(洗脳者のような胡散臭い感じもするが・・・)
(引用終了)

【参考2】Embedded Software Manufactory: ソフトウェア品質論の歴史的推移

(引用開始)
「不良をなくすことが、究極的な品質の実現である」とする考え方は、古典的な統計的品質管理を極端に形式化した観念論的な品質論である。
「良いプロセスが実践されているからこそ、良い品質が生み出される」と考えるのがプラグマティズム的品質論。
「当たり前品質」と「魅力的な品質」の相対概念は高度に先験的で観念論的な日本的品質管理の概念である
(中略)
この新しい品質論は、グローバル化経済において、究極の品質論のように見える。
「民主主義的原理に基づく品質論」
「品質概念の本質は、製品やサービスの存在目的に基づき、ユーザから見た利用目的の達成度に関する評価である」とする。
評価対象としての製品のサービスの性質と、評価時点における市場のユーザニーズ(利用目的)への適合性(利用目的の達成度)によって決定される。
同じ製品やサービスであっても、評価の時点が違えば、その品質評価は変化する可能性があることを意味している。
「民主主義原理に基づく品質論」はソフトウェア品質評価法に代表される観念的品質論とCS運動における顧客満足に基づく品質改善を基礎とするリバタリアニズム的品質論を融合するものになる。
(引用終了)

製造業の品質管理技法は、いわゆる古典的な統計的品質管理が発端らしい。
つまり、量産品のバラツキを統計的手法によって原因分析して解決し、不良率を減らす。
日本が得意。

一方、プラグマティズム的品質論は、「良いプロセスが実践されているからこそ、良い品質が生み出される」と考える」。
この発想を元に、プロセスを国際規格として定めて、トップダウン・アプローチで形式知として実現したものが、ISOなどの各種規格。
今の日本は、このやり方がグローバル・スタンダードになったために、すごく苦労している。

さらに、「民主主義的原理に基づく品質論」はマーケティング3.0または、アジャイル開発を連想させる。

しかし、日本の品質管理でも、製品ライフサイクルによって、狩野モデルにある「魅力的品質」から「一元的品質」「当たり前品質」へ品質が変化する、ということも既に指摘されていた。
この辺りの整合性はどう取るのか?

【参考3】Embedded Software Manufactory: 機能安全の意味がわかった(IEC61508とISO26262の最新情報)

最近よく聞く「機能安全」とは、安全装置が保証する安全に関する機能、という思想があるわけか。
そうならば、すごく理解しやすい。
最近は、IPAも組込安全規格に関して、盛んに研究しているしね。

(引用開始)
機能安全の説明でよく踏切の例が挙げられる。踏切ではなく高架橋を作ることによって通行者の安全を確保するのが本質安全で、踏切という安全装置によって安全を確保するのが機能安全。
(中略)
機能安全の規格は安全装置によって安全を確保する狭義の Safety という意味合いが強いということがこの記事を読んでよく分かった。本質安全に対する安全装置による安全(=機能安全)と考えると非常にすっきりする。
そして、安全は安全装置の設置という狭い考えではなく、システム全体を踏まえた包括的な安全性の実現を考える必要がある。
(引用終了)

【参考4】Embedded Software Manufactory: ISO 26262との向き合い方 (6) 機能安全のマネジメント2

【4-1】現代のソフトウェア開発では、ITS、SCM、CIツールの3つが使われるのは当たり前。
その効果は、変更管理や構成管理がツールで制御できるようになったこと。
今後の課題は、要件管理である、という主張。

(引用開始)
変更管理や構成管理はここ10年で浸透した。要件管理はこれからで、ISO 26262 への適合がトリガーになって、導入が進むのではないかという内容だ。
(中略)
構成管理や変更管理が日本でも受け入れられているのは、 構成管理や変更管理がボトムアップの開発にも十分に役立つからである。同じように要件管理ツールも普及すると思ったら大間違いだと自分は思っている。(構成管理や変更管理のボトムアップでの組織への浸透については『リコールを起こさないソフトウェアのつくり方』の二章にやり方も含めて詳しく書いた。)
(引用終了)

【4-2】日本発祥の開発プロセスであるXDDPは、特に派生開発で有効。
その理由は、日本人に合うボトムアップ・アプローチによる変更管理をコントロールできるから。

(引用開始)
日本では問題が分かったときの修正のスピードが速い。デグレードはゼロとは言えないが、とんでもない見落としは少ない。それは、品質を心配する意識: Awareness: Worrying about Quality の力ではないかと思っている。(これうまくいかず品質に悪影響を与えるケースが増えており、変更の影響を分析、管理しながら変更を実装していく XDDP という取り組みが今話題になっている。)
(引用終了)

【4-3】安全が確保されている証拠、機能安全の規格を満たしている証拠として、トレーサビリティマトリクスがある。
そのトレーサビリティマトリクスを作成・維持するために、要件管理ツールの存在意義がある、という主張。

(引用開始)
その状態を回避し、ユーザーの期待(安全は当たり前に確保されているはず)に答えるには、安全に対する要求と、その実現方法、実現の結果(証拠)を常にトレースが取れるようにしておく必要がある。そのトレースのセットがトレーサビリティマトリックスとなる。
要件管理ツールはこのトレーサビリティマトリックスを保持するための助けとなる。
(引用終了)

【参考5】Embedded Software Manufactory: ISO 26262との向き合い方 (1) 最初に読んで欲しいこと

著者がISO 26262 にこだわっている理由を経験談を元に書かれている。
「「自分はキチンとやっていたが、組織的な品質システムとして実施されたものではない」という状態」だったから、米国での製品販売が止められた。
著者は、当初、理由が分からなかった。
きちんとやっているのに、なぜ差し止められるのか。

しかし、後に著者は理解する。
「個人が自分の考えで実施している検証は品質マネジメントに基づいたものではないローカルルールで行われものであるため認められないのだ。」
つまり、世界標準のやり方でないと通用しない世界がある。
その背後には、プロセスアプローチ、プラグマティズム的品質論の考え方がある。

| | コメント (0)

2018/01/01

アジャイル開発にはモデリングや要件定義の工程はあるのか、という問題とその周辺

最近のツイートで、アジャイル開発には要件定義工程はあるのか、というテーマで、DOAモデラーとアジャイル系のアーキテクトの間で議論があった。
内容がとても奥深い。

僕はまだ自分の考えをまとめきれていないので、自分が後で参考にしたいためにリンクしておく。
以下、ロジカルでないラフなメモ書き。

【参考】
@yusuke_arclampさんのまとめ記事が公開されました。

アジャイルにおける事前合意について - arclamp

【1】エンタープライズアジャイル勉強会 2017年12月セミナー開催のお知らせ

アジャイルを機能させる外枠について - arclamp

(引用開始)
アジャイルを機能させる2つの外枠

1つ目の外枠は「何を作るべきか」という観点。
チームが何を作るべきか、という手前には「そのチームが実現すべき価値とは何か」をきちんと考える必要があります。この点はギルドワークスの市谷さん(@papanda)にお願いしました。市谷さんの講演は「アシ?ャイル開発はWhyから始まる」というタイトルで、機能開発の前にWhyとしての仮説検証を行うことで開発が右往左往しなくなる、という話でした。「顧客開発をプロダクト開発よりも極端に優先するとチームが右往左往する」という指摘はその通りですね。

2つ目の外枠は「どう作るべきか」という観点。
ただし、これはプロダクト本体の作り方ではなく、プロダクトの外側と連携する部分の作り方の話です。これは僕が「アジャイルを支えるアーキテクチャ設計とは」というタイトルで、アーキテクチャ設計にも、プロダクト本体の作り方を考える「小さなアーキテクチャ」と、プロダクトの外側の作り方を考える「大きなアーキテクチャ」という紹介をしました(参照:大きなアーキテクチャ設計と小さなアーキテクチャ設計 - arclamp)

というわけで、アジャイルチームを機能させる外枠は「仮説検証というビジネスの話」と「大きなアーキテクチャという技術の話」があるのでは、という整理をさせてもらいました。
(引用終了)

つまり、見積りできないモノ、ステークホルダーとの調整をアジャイルチームに持ち込まない。

isopさんのツイート: "kent beckや平鍋さんが偉大なアーキテクトだから、という文脈は激しく同意したい"

isopさんのツイート: "@hiranabe 先日のエンタープライズアジャイル勉強会での @yusuke_arclamp さんのQAセッションで開発サイクルを回すことでアーキテクチャは自然と生まれてくるのか?という質問に対する回答でした"

鈴木雄介/Yusuke SUZUKIさんのツイート: "どちらかというと「平鍋さんやkent beckがアジャイルを語るとき、アーキテクチャの重要性が本人達にとって自明すぎるがゆえに語られないのは問題だ」というクレームめいた言い方をしまして... https://t.co/P6Ou6WRkpl"

【2】上記に関する感想をツイート。

akipiiさんのツイート: "名言。ストンと落ちた。RT @yusuke_arclamp: エンプラ開発における調整の多さに対してアジャイルなんてうまくいかないだろうと思っていたが、うまくいく方法があるんです。仕掛けは簡単、調整をアジャイルチームに持ち込まないことです。外で調整してから持ち込む。その防波堤がPOやSM https://t.co/qFNXcROiek"

昌。さんのツイート: "@akipii @yusuke_arclamp 先日のアジャイル勉強会でもその辺り激しく主張されてましたね"

akipiiさんのツイート: "@aj15_aj15 @yusuke_arclamp 立場によっては、当たり前だろ、という意見と、開発を最大に効率化する観点では、この方法しかないので、この方法を洗練化すべきだ、という意見があると思います。"

鈴木雄介/Yusuke SUZUKIさんのツイート: "@akipii @aj15_aj15 特にエンタープライズ業界でアジャイルをスタートする方は強めに意識してもらいたいな、と思います。僕の知る現場で苦労しているのは、この2つということが多いので。"

門屋 浩文さんのツイート: "@yusuke_arclamp @akipii @aj15_aj15 なるほど。エンタープライズアジャイルにはまだ踏み込んでいませんが、納得です。ただ、それができるPOやSMはウォーターフォールでもうまくいく気がします。早く成果物を作る・使うって効果を優先ってことで手法を選択、ですかね"

akipiiさんのツイート: "@MadoWindahead @yusuke_arclamp @aj15_aj15 いえいえ、もっと深い意味があります。DOAモデラーとの議論では、アジャイル開発では要件定義やアーキテクチャ設計は誰が担当するのか?と言う議論がありました。アジャイル開発の文脈では、開発チームは要件定義やアーキテクチャ設計を担当せず、POに委ねることで解決しようとしてます。多分。"

akipiiさんのツイート: "@MadoWindahead @yusuke_arclamp @aj15_aj15 よって、DOAモデラーの観点では、そうならば 速く開発できるのは当たり前でしょ、と。でも要件定義やデータモデリングを他人の手に委ねて良いのかと。僕は、アジャイル開発のような特化したやり方は有りと思うし、そういう仕組みがあるから中小SIが市場に食い込めるので日本では人気あると理解し… https://t.co/QO72yG0fhm"

鈴木雄介/Yusuke SUZUKIさんのツイート: "@MadoWindahead @akipii @aj15_aj15 アジャイルでは「要件定義レベルでモデルやアーキテクチャを固くすることに意味がない」とも言えます。なぜなら変化するから。つまり、作りはじめるまでに、いつ、どこまで、誰が固く表現するのか?というのが論点かと。"

【3】スクラムとの関わりについて。

鈴木雄介/Yusuke SUZUKIさんのツイート: "アジャイルで「エンジニアにとって面倒なことをチームに持ち込まない」というのを「効率化のために調整は減らすべき」と考えるか「エンジニアの甘え、仕事の醍醐味は調整だ」とするかで分かれそう。もちろん、両面ある。僕としては「両者を混ぜて曖昧にするな」というだけ。"

鈴木雄介/Yusuke SUZUKIさんのツイート: "スクラムマスターってエンジニアの世話役とかおもりみたいな面もあり「そんなの甘え」と思う人もいるだろが、そういう人がいないとエンジニアが機能しないのも事実なんだよね。ウォーターフォールでいう「バッファ」を実体化したのがスクラムマスターともいえるのかな?"

鈴木雄介/Yusuke SUZUKIさんのツイート: "ともかく日本でまともな開発現場、エンジニアがやり甲斐があって、つらくならない開発現場を増やしたい。でも、なんでもできるエンジニアは限られているから組織やチームとしてできる体制を作らないといけない。だから、マネジメントが必要になる。アジャイルは良いツール。"

みぞやんさんのツイート: "@yusuke_arclamp WFでいう(人数によりますが)サブシステムごとのチームリーダーがスクラムマスターを担えるといいのかなと思いました"

鈴木雄介/Yusuke SUZUKIさんのツイート: "@mizoyan432 最新のスクラムガイドでも「スクラムマスターはサーバントなリーダーである」と記載があるので、ある意味ではその通りです。ただしコミュニケーションパスを抑えるようなリーダーではないべきですね。"

HARADA Kiroさんのツイート: "@yusuke_arclamp 有効なら「甘え」でなにか悪いことでも?くらいのノリですかねえ。バッファよりは、もうちょい能動的で、バッファ減らす要因に働きかけに行く感じ。"

【4】アジャイル開発とWF型開発における、プロセスの違い、体制の違い、

鈴木雄介/Yusuke SUZUKIさんのツイート: "企画の決める仕様がゆるい、基幹システム連携がもめる、運用部門に提出するドキュメント作成が大変、といったことはWFからアジャイルになっても変わらない。むしろ、課題として明示化される。作業に落とし込めない調整事を開発チームに持ち込ませないのが大事。"

鈴木雄介/Yusuke SUZUKIさんのツイート: "エンタープライズ開発だと、WFでもアジャイルでもやるべきことはきちんとやる、のです。ただ、作業にならないものはスプリントに持ち込めなくなるからPOやSMが頑張って作業になるように調整を行うことになる。その代わりチームは機能の実現に全力を尽くす。"

鈴木雄介/Yusuke SUZUKIさんのツイート: "スプリント計画で「開発チームが見積もれないものはスプリントバックログにいれない」というのが大事です。それがグダグダになるとうまく回らなくなる。そもそもプロダクトバックログに調整中のものは持ち込まないべき。その手前に解決しておかないと。"

鈴木雄介/Yusuke SUZUKIさんのツイート: "アジャイルに比べてWFの方がゲートやプロセスが厳密なんて聞きますが、間違いです。アジャイルはスプリントごとのゲートやプロセスは大変に厳密です。ただWFはゲートの数が少ないので一回でやるべきことが多くなるだけで。"

上記のツイートは、本当に同意。
大規模WF型開発でも、優秀なプロジェクトマネージャは故意にフェーズ分けして段階リリースを踏む、という手段を取る場合が多い。
最後の1回だけの本番リリースは危険すぎる。

鈴木雄介/Yusuke SUZUKIさんのツイート: "WFからアジャイルへの転換で相談を受けることがあるけど、大抵のお悩みはプロセスの問題ではなくて、その会社の組織やルールの問題。で、そうであるならアジャイルに転換しても解決できません。むしろ、転換を機会にどうするのかを考えないと。"

鈴木雄介/Yusuke SUZUKIさんのツイート: "エンプラ開発における調整の多さに対してアジャイルなんてうまくいかないだろうと思っていた頃が僕にもありましたが、うまくいく方法があるんです。仕掛けは簡単、調整をアジャイルチームに持ち込まないことです。外で調整してから持ち込む。その防波堤がPOやSM"

そういう文脈で、アジャイル開発では、スクラムマスターやプロダクトオーナーが防波堤になる。
組織パターンにおける防火壁、ファイアウォール。

鈴木雄介/Yusuke SUZUKIさんのツイート: "エンプラで調整が面倒なのは仕様合意、システム連携、インフラ調整、運用引継。インフラ調整はクラウド化で軽減、システム連携や運用引継はプロセス関係なく事前ネゴ。仕様合意はアジャイルの締切駆動や定期調整に変更。つまり、アジャイルで変化を強く求められるのはビジネス側"

鈴木雄介/Yusuke SUZUKIさんのツイート: "みんなアジャイルに期待しすぎなんだよ。面倒なことは面倒なままだし、ちゃんとしないといけないことはちゃんとすべき。むしろ、エンプラなんてそうじゃないと困る。ただし、仕様を先に全て決めるという無理ゲーからは解放してくれる。"

【5】@yusuke_arclampさんと@sugimoto_keiさんのやり取りを読んだ後で振り返ると、おそらく、アジャイル開発には要件定義工程はあるのか、という問題の本質を突いているのではないか、と直感した。

杉本啓さんのツイート: "鈴木さんのエントリで一番気になったのは「見積もれないことをチームに持ち込まない」という点です。興味深い要求は、ふつう最初見積もれないですからね。これは「なすり合い」「平行線」とは違うと思うのです。私は鈴木さんの心情を批判しているのではなく書かれた主張を批判している点ご理解下さい。 https://t.co/XE9KG0za2U"

吉田 収さんのツイート: "@yusuke_arclamp @sugimoto_kei いわゆる「ビジネスアナリスト」の領域はチーム外とした方がよいということになるでしょうか。"

杉本啓さんのツイート: "@omuysd @yusuke_arclamp お尋ねの点は、どう仕切りたいかという意思の問題に依るところが大きいように思います。私としては、業務側との関係が宜しければ、業務要件の定義・分析もチームで担当する方が好みですが、それは設計/開発だけチームで受けるのとは少し異なるビジネスかと思います。"

鈴木雄介/Yusuke SUZUKIさんのツイート: "@omuysd @sugimoto_kei フェーズによると思います。初期は完全に外でも良くて、作るものが見えて来たらやり取りを開始し、画面への落とし込みはチームに任せていくという雰囲気でしょうかね。杉本さんが言われるようにチームのスキルや関係性で寄り方は変わるでしょうが。"

@yusuke_arclampさんも違和感を感じられているのかな、と感じた。

akipiiさんのツイート: "DOAモデラーとの議論を読んでたら、そんな感じがする。RT @yusuke_arclamp: なんか自分の主張がRUP的にフェーズによってチームスキルの濃淡を付けろという話になっている気がしてきて微妙な気分。うーむ https://t.co/Vweh4rkrnO"

【6】DOAモデラーからの意見。
モデリングするという行為の立場から言えば、まさに正論。

年忘れLT宴会<第60回IT勉強宴会> | IT勉強宴会blog

ソフトウェア開発と業務システム開発(杉本さん)

(引用開始)
アジャイルとウォーターフォール

・「ソフトウェア開発」に関するアプローチの違いだけではない。
・スコープ(視野に収めている範囲)が違うよね。
・ソフトウェア開発 vs. 業務システム開発
・超高速開発は、スコープの点ではWFと同じ。
・ソフトウェア開発を仕事としているエンジニアに超高速開発を訴えるとき、注意しないとスコープを誤解される。
・超高速開発は、業務システム開発の面を強調した方がよい。超高速開発というとソフト開発が早くできるというメッセージだけ。
(引用終了)

個人的には、関西IT勉強会で、DOAとアジャイル開発におけるモデリングや要件定義の違いについて、@yusuke_arclampさんと@sugimoto_keiさんの対談を聞いてみたい、と思う。

【7】個人的な感想を以下、書いておく。
ラフなメモなので、論理がズレているかもしれない。

【7-1】超高速開発ツールが何故プログラマに嫌われるのか

超高速開発ツールを使うと、DB設計や実装モデルを作れば、プログラミングレスで即座に業務システムを作れる。
つまり、超高速開発はモデル駆動開発の方向性に似ている。

しかし、プログラマの観点では、超高速開発ツールは正直面白くない。

プログラマなら、誰もが自分のプログラムが一番と思っている。
でも、自分が書いた優れたプログラムを見てくれ、という場面をアピールできない。
Githubで互いに書いたプログラムをフォークして、プルリクエストを送る、といったソーシャルコーディングが実現されない。

また、モデルという絵や、モデルを表現するための別のプログラムであるDSL(ドメイン特化言語)を別途覚える手間がかかる。
そんなものを覚える暇があるなら、RubyやPythonをガリガリ書きたいし、そちらの方がはるかに意味があるでしょ、と。

すると、超高速開発ツールは製造業のSE向けがマーケットなんだろうな、と思う。
つまり、プログラミングしないけどシステムを開発したい人達、すなわち発注者、特に日本では製造業のSEがターゲットになるだろう。

彼らはプログラミングは下流工程とみなし、外部へ発注するのが普通と考えているからだ。
外部に発注する工程が超高速開発ツールで代替されて、発注費用がなくなるのが理想だろうから。

akipiiさんのツイート: "同感。良い物なのに肝心のターゲット、つまり発注側のSEに届いてない気がする。RT @sugimoto_kei: 翻って超高速開発ツールを見るに、ターゲットがバクっとし過ぎのような気がする。もちょっとターゲットを定めた方がよいのでは?"

また、超高速開発ツールは多分最終的にはDSL基盤を目指しているんだろうな、と思う。
つまり、超高速開発ツールはプログラミングしない代わりに、モデルを描くために特化したスクリプト言語が必要になり、それがDSL(ドメイン特化言語)になるわけだ。

たとえば、UMLでもOCLみたいなDSLが提唱された時もあった。
DSLの優れた事例は、ExcelのVBAという意見もあったな。

そのDSLの最大の特徴は、プログラマでなくても、ユーザが分かるようなプログラミング言語であり、ユーザが簡単に書けることだろう。
システム化したい業務を一番良く知っているユーザ自身が、モデルをDSLで書いてしまえば、後は超高速開発ツールが即座にシステムを作れる、というストーリー。

そういうストーリーでは、プログラマの出番はないし、業務システムの発注者であるユーザ自身が超高速開発ツールを使いこなせるようにならなければならない。
超高速開発ツールはおそらく、そういう方向へビジネスモデルとして進化するのではないか。

【7-2】アジャイル開発における発注者と開発チームでの設計上の役割分担の誤解

上記のように、アジャイルチームには、外部との調整や要件定義に関わる作業は担当させない。
要件定義やそこから定まるプロダクトバックログはプロダクトオーナーが担当するし、スクラムマスターがスクラムチームの守護神として守る。
つまり、アジャイルチームの外側に、要件定義やモデリングの作業が追いやられているように見える。

モデラーの立場から言えば、そういう分業体制なら、速く開発できるのは当たり前だろう、と。
既に、作るべき機能リストがあり、チームはそれを淡々とこなせばいいのだから、と。

おそらくこの部分で、アジャイル開発とDOAモデラーとの間で、認識の相違が生まれるのだろうと思う。

【7-3】アジャイル開発が何故日本では中小SI企業に人気があるのか

では、なぜ、アジャイル開発が日本でも注目されているのか?
アジャイル開発が注目される理由の中に、日本特有の事情があるのか?

理由として、日本の中小SI企業が大手の下請けに依存しない受託ビジネスを行う時、アジャイル開発の手法が最強の道具になるから、という@sakaba37さんの意見があって、すごく納得した。

実際、日本のIT業界では、受託開発は請負契約の多段階の下請構造になっている場合がほとんど。
すると、その構造のままでは、中小SI企業自身がIT案件を主導するビジネスはやりにくい。

しかし、アジャイル開発を採用すると、ユーザ企業とシステム企画や要件を直接ヒヤリングしながら、スピーディにシステム開発して納品するビジネスモデルを実現できる。
つまり、今までは、元請けSIの大企業が担当していたシステム企画や要件定義フェーズを、下請けの立場に甘んじていた中小SI企業が直接担当して、ユーザ企業と直接契約できるようになるメリットがある。

特に、Webシステム開発のように、技術力に特化しているならば、要件定義さえ上手くまとめれば、ユーザ企業と直接やり取りしながら、小刻みにリリースしながらシステムを納品していくことができる。
一方、発注者であるユーザ企業も、早い段階でシステムの受入れで確認できるし、途中で細かな改善要望も織り交ぜられるので、双方にメリットが共有できれば、受け入れやすい契約になる。

また、ドメイン駆動設計のような設計手法、ユーザストーリーマッピング等の要件定義手法、リーンキャンパスやリーンスタートアップなどのシステム企画の手法も色々編み出されているので、従来のアジャイル開発の盲点であったフェーズもカバーできるようになってきている。

すなわち、日本におけるアジャイル開発の文脈では、アジャイル開発は、中小SI企業が多段階の下請構造から脱却するためのビジネスモデルとして捉えられる、のではないか。

【7-4】DDD(ドメイン駆動設計)がアジャイル開発におけるモデリング技術の補完的役割を担っている

では、アジャイル開発では要件定義やモデリングは不要なのか?
開発チームの外側で要件定義やモデリングを行うとしても、プロダクトオーナーはアジャイル開発の文脈でどのような要件定義手法やモデリング手法を持つべきなのか?

2018年初頭の日本では、ドメイン駆動設計がアジャイル開発における唯一のモデリング手法として認知されている、という回答になるのではないか。

現場で役立つシステム設計の原則を読んだ | mizoguche.info

Takuto Wadaさんのツイート: "(トッパン|ピアソン)ショック、単に絶版、様々な要因でOOA/OODの書籍がほぼ死滅し、訳書が出るタイミングが遅かったDDD本だけがオーパーツのような存在になった結果、日本ではDDD ≒ OOA/OODになってしまったという奇妙な状況の背景の話をした #teppeis_sushi"

@t_wadaさんの指摘の通り、2000年代はオブジェクト指向分析の観点で色んなモデリング手法が提唱されていたが、それらの本を出版していた出版元が書籍発行を辞めてしまったため、最も遅く出版されたドメイン駆動設計本だけが生き残り、その本しかアジャイル開発者は参考できない、という現状があるからではないか。

つまり、ドメイン駆動設計が日本で注目されている理由の一つは、そういう日本特有の事情があるのではないか。

【7-5】超高速開発ツールには、DOA基盤のツール以外にも、SalesforceやKintone、Ruby on Railsも含まれる

そういう超高速開発ツールはDOA基盤のツールだけでなく、著名なパッケージ製品では、SalesforceやKintoneも含まれるだろう。
たとえば、DOAの発想でデータモデルさえきちんと設計すれば、Salesforceで簡単に実装できる。
また、要件定義できちんと要件さえ確定していれば、KintoneでAPIを駆使して、簡単な業務システムを作り込める。

杉本啓さんのツイート: "kintone というのは複数テーブルのジョインも出来ないと聞いて、全然だめじゃないのと思っていたのだが、使ってみるとそうでもないようだ。簡単な台帳を作るにはよく練られている。ターゲットとする用途をうまく選択することがいかに重要かを示す例かもしれない。"

杉本啓さんのツイート: "@akipii はい。私も超高速開発ツールと同じと思っていましたが、おっしゃるように、想定している利用シーンが異なる(kintone の方が絞り込まれている)のではないかと今は考えています。@iteman さんの方が詳しいですが。"

Atsuhiro Kuboさんのツイート: "@sugimoto_kei @akipii 汎用の CMS と WordPress 等のブログシステムとの違いに近いと感じています。超高速開発ツールは「設計する」というアクティビティがあると思いますが、kintone にはそれがない感じでしょうか。"

そういう観点では、Ruby on Railsも超高速開発ツールの一種とみなすこともできるだろう。
業務のデータモデルをActiveRecordで対応付けることができれば、画面は簡単に自動生成できるから。

さらに、画面の細かなUIは、JavaScriptで作りこめばいい。
たとえば、XEADでも、画面UIの作りこみの部分はJavaScriptで実装できるように作られている。

特に、Ruby on RailsはJavaScriptと大変相性が良いので、画面UIをデスクトップアプリのような操作感で実現できる。

よって、最近は、DOA基盤のツールだけでなく、SalesforceやKintoneのように手軽に操作できる有償のパッケージ製品、さらにはRuby on Railsのような強力なフレームワークが普及したことで、超高速開発ツールを適用したいニーズに当てはまるのだろう、と思う。

【7-6】超高速開発ツールが普及したからこそ、匠Methodのような要件定義手法に価値がある

アジャイル開発やプログラマの視点では、超高速開発ツールに否定的になってしまう。
しかし、超高速開発ツールのおかげで、発注者自身がお手軽にシステム開発できる基盤が整った、という側面もある。
つまり、要件定義できちんとシステム要件さえ確定できれば、超高速開発ツールを使えば、即座にシステム化できるのだ。
よって、萩本さんが提唱する匠Methodを要件定義のための手法として扱って、超高速開発ツールのインプットに連携すれば、スムーズにアジャイルに開発できるだろう、と思う。

そんな話を連想できたのは、先月に関西匠塾に行ってきて、匠メソッドの概要を初めて聞いたから。
詳細はまだ理解しきれていないけれど、ビジネスモデル設計やシステム企画から業務の要件定義まで一通り、設計できる、とのこと。

価値を描き、活動に落とし込む手法を学ぼう! - connpass

では、その後はどうやってシステム開発するのか?
お話を聞くと、たとえば、Salesforceを使って、システム要件を元に素早くシステム開発していく、というストーリーみたい。
つまり、匠メソッドを要件定義のアウトプットを作るフェーズで使って、業務の要件定義書を作り、それをSalesforceやKintoneのインプットとして用いることで、アジャイルに開発できる。

【7-7】kintoneという超高速開発ツールの開発基盤があるからこそ、業務ハックという職業も生まれる

この考え方は、最近、倉貫さんの会社でも提唱されている業務ハックにつながるのではないか、と推測する。

業務改善とシステム化を一緒にやってしまう「業務ハッカー」という新しい職業 | Social Change!

業務ハック勉強会@大阪 ? 働き方改革にも効く!事例で学ぶ業務改善のノウハウ - connpass

つまり、超高速開発ツールのような即座にシステム化できる開発基盤があるからこそ、プログラマの観点では、業務モデリングも実装ツールの一つに組み込んでしまって、アジャイルにシステムを作りながら、業務もシステムも改善してく手法を取っていく、という考え方ではないか。
ユーザから画面UIに関する細かな改善要望があっても、JavaScriptさえ操ることができるなら、画面UIの作りこみにさほど苦労することはないだろうから。

この辺りは聞いてみないと分からないけど。

【8】以上は妄想にすぎない部分もあるけれど、今年も色んな勉強会に行ってみて、上記のアイデアの方向性が合っているのか、確認してみたい。

【追記1】
鈴木雄介/Yusuke SUZUKIさんのツイート: "相変わらずウォーターフォールとアジャイルの話は受けがいいなぁ。最近のエンタープライズ界隈はウォーターフォールからアジャイルへの転向が増えている気がするので、もっと、こういう話はされていいんだろうな。 https://t.co/yR1x9ZUku4"

【追記2】
杉本啓さんのツイート: "読みました。興味深い試みですね。業務の仕組みを作るという志向において超高速開発やDOA界隈と似ていると思います。「業務ハッカー」という呼称は、確かに新味があってプログラマに受けそうですが、顧客サイドからするとどうですかね。現場の人には響くでしょうが、上の方には響きにくいかも。 https://t.co/fbXybQn6vL"

akipiiさんのツイート: "@sugimoto_kei 実現したいものは超高速開発ツールも業務ハッカーも同じ方向性に感じます。但し、モデリングに注力してノンプログラミングにする超高速開発ツールと、プログラミング作業の中に業務設計や運用設計を取り込む業務ハッカーは手法が異なると読み取りました。"

杉本啓さんのツイート: "@akipii まあ、嗜好は違うのだとは思いますが、同じ問題領域を対象にするのであれば、収斂してくるような気がしますね。超高速開発がノンプログラミングというのはセールストークであって実際にはDSLなどでプログラミングするわけだし、業務ハックで使うkintoneもある種のDSL環境ですしね。"

杉本啓さんのツイート: "@akipii 業務ハッカーについては、私は、さほど違和感を感じていません。買う側の意思決定者には響きにくいだろうなと思う程度です。調整をチーム外にという鈴木さんの話については、たぶん問題意識についても不一致があると思います。"

杉本啓さんのツイート: "@akipii とはいえ「超高速開発」よりは「業務ハッカー」の方がセンスありますね。ユーザ視点に立つと、前者では開発が速くなるんだろうなあという印象しか湧きません。後者だと、自分たちの業務に踏み込んで考えてくれるのかも、という期待が持てます。"

| | コメント (0)

2017/12/27

安全性解析手法STAMP/STPAセミナーの感想

先日、安全性解析手法STAMP/STPAセミナーに行ってきた。
ラフな感想をメモ書き。

【感想】
安全性解析手法STAMP/STPAセミナー@大阪(ソフトウェア高信頼化 SECセミナー )-SEA関西

安全性解析手法STAMP/STPAセミナー@大阪

「はじめてのSTAMP/STPA(実践編)~システム思考に基づく新しい安全性解析手法~」の公開:IPA 独立行政法人 情報処理推進機構

一般社団法人JASPARと相互協力協定を締結<br />自動車産業における「STAMP/STPA」の普及促進で、さらなる安全性の向上を加速:IPA 独立行政法人 情報処理推進機構

【1】最近のIT業界だけでなく、メーカーでも、IOTやAI、ビッグデータがバズワードになっている。
家電製品は既にソフトウェア化されてしまって価格破壊と鮮度劣化が激しいけれど、ついに自動車にもEVの波が押し寄せてきたように、メーカーが製造するあらゆる工業製品もソフトウェア化が迫ってきている。

しかし、従来のメーカーの品質管理手法は、そういうソフトウェア化の環境変化に対応しきれていないと考えている。
メーカーの品質管理手法は、統計的品質管理を主体とした、量産品の品質管理技法だと思う。
つまり、品質が保証された製品を大量生産するために、品質のばらつきを管理図などのQC技法で潰し、歩溜まりを上げて、経験曲線効果を活用して、コスト低減と品質向上を目指す。
この手法が以前まで、日本の製造業は品質で世界一だ、という評価をもたらしてきた。

しかし、製造業における、大量の資金投入による投資と生産設備の最新化、大規模化、という規模の経済の考え方は、ソフトウェア開発では全くと言っていいほど通用しない。
ソフトウェア開発は徹頭徹尾、労働集約的な産業だと僕は思う。

たとえば、人月の法則で言われるように、大量の開発メンバーが加わるほど、システム開発は遅れる。
他に、コンウェイの法則のように、大人数の組織は、その複雑な組織構造がソフトウェア設計にも反映されて、ソフトウェア構造がより複雑化され、ソフトウェアはエントロピー増大にさらされる。

そこで、アジャイル開発、そしてスクラムでは、規模の経済をベースにした製造業の開発スタイルではなく、サーバーントリーダーシップや自己組織化の理念の元で、小規模な開発チームで状況変化に素早く対応できる仕組みを提唱してきた。
よって、ソフトウェア開発をビジネスの主体とするならば、たとえメーカーであろうとも、アジャイル開発の導入は避けては通れないはずだ、と僕は思っている。

【2】でも、ソフトウェア開発の仕組みを製造業にそのまま取り入れたとしても、上手く行かない部分がある。
それが、安全性という品質特性だろう。
特に、フェールセーフという安全性の品質だろうと僕は思う。

たとえば、鉄道の踏切、交差点の信号、レンジやドラム缶式洗濯機などでは、人が事故に合わないように、安全が保持できる方向へ切り替わる仕組みが考えられ、昔からその機能が提供されてきた。
しかし、ソフトウェアが製品に組み込まれると、ちょっとしたバグが人命の危機にさらされるリスクが増大する。
そして、ソフトウェア開発者なら誰でも知っているだろうが、全ての潜在バグを潰すことは事実上不可能だ。
つまり、ソフトウェアが組み込まれた製品は、安全性に関して、何らかの不安が残る場合がある。

そういう課題は以前からずっと認識されてきたようで、たとえば、自動車の電子制御系に関する機能安全規格はISO 26262として最近公開された。
ついに自動車でもISOとして安全性という品質が業界標準で決まったために、組込ソフトウェアにおける安全性の研究は現在ホットな状況なのだろう、と思う。

IPAでも、この分野の研究が重要と認識しているようで、セーフウェアの本の著者であるナンシーさんとも共同して、安全性解析手法STAMP/STPAという手法を作り、日本のメーカーに広げようとしているようだ。

今回は、そんなセミナーに行ってきた。

【3】正直な感想を言うと、僕は門外漢なので、安全性解析手法STAMP/STPAがどこまで有効なのか、分からない。
でも、こういう安全性解析手法がどんな考え方をしているのか、というイメージは持つことができた。

一言で言えば、部品単体レベルの品質向上を目指すのではなく、もっと抽象的なレベルを上げて、製品とそれに関わるステークホルダーの関係に注目する観点で、安全性を議論しようとしている。
下記の絵が分かりやすい。

一般社団法人JASPARと相互協力協定を締結<br />自動車産業における「STAMP/STPA」の普及促進で、さらなる安全性の向上を加速:IPA 独立行政法人 情報処理推進機構

一般に、メーカーの品質管理の考え方では、下請け業者から仕入れた部品の品質を徹底的に管理し、それら高品質な部品を組み立てて、最終製品の品質を維持しようとする。
しかし、製品が複雑な構造になると、部品単体の品質が良くても、それら部品の関係や依存性で品質が悪くなる時がある。
その話は、部分の合計は全体と一致しない、むしろ全体よりも大きくなる、という集合論の話を連想させる。
バナッハ=タルスキーのパラドックスだったかな。

バナッハ=タルスキーのパラドックス - Wikipedia

ソフトウェアが混じってくれば、なおさら、プログラム単体ではなくシステム全体として機能させた場合の方が品質に大きく関わってくる。
つまり、部品レベルではなく、製品全体、製品とそれに関わるユーザとの相互作用を考慮した「システム」のような考え方が必要になってくる。

【4】この考え方にはいくつか特徴があると僕は思う。

【4-1】一つは、製品のI/Fがユースケースになること。
たとえば、電気自動車を考えた場合、ユーザは電気自動車に何を期待するのか、という観点から、電気自動車に必要な機能を考えていくことができる。
この考え方のメリットは、ユーザの価値や便益を起点に機能を考えるので、ユーザに優しい製品になる可能性が高いことだろうと思う。
つまり、ソフトウェア開発の企画や要件定義の手法を取り入れているように思う。

すると、製品とユーザの接点は、製品のI/F機能、またはユースケースと考えることができる。
なぜなら、ユーザが製品を使う利用シーンを考えるようになり、それを表現しようとすると、ユースケースの概念が自然に現れてくるからだ。

また、ユースケースの概念が現れてくると、「SysML」本のコンテキスト図のように、製品に関係するステークホルダー全てがアクターとして現れ、その中心に製品が配置されるような図が作られることになる。
つまり、この考え方では、アクターを漏れなく抽出すること、アクターと製品に関わるI/Fとなるユースケースを自由な発想でどれだけ考えられるか、という観点が重要になってくるだろう、と思う。

そして、そのコンテキスト図を元に、安全性の観点を組み込んで製品の機能を付けていくことになるはず。

ただし、アクターやユースケースが漏れると、その後の工程で検出することは不可能なので、自由な発想を補強するようなプラクティスが必要になってくるのではないか。

【4-2】もう一つは、製品のハード設計がなくても議論できること。

一般に、ハード屋さんはどうしても実際のモノの設計図から考えたがる。
しかし、企画段階ではモノがないので、イメージにしくい。

だが、製品にはこんな機能があるとユーザにとっていいよね、という観点で、製品のI/Fを洗い出していくことができるし、それらI/Fを整理することで、製品のおぼろげなイメージが出てくる。
たぶん、iPodやiPhoneのような製品も、プロトタイプ製品はあったとしても、ユーザの利用シーンから色々考えて作られたのではないだろうか。

すると、製品のハード設計図がない状態で製品の機能を作り出し、安全性の品質の議論ができるようになる。

なお、SysMLのメリットは、ハード設計図がなくても、ソフトウェア層の観点で抽象的なレベルで要件や機能をイメージできること、という話を聞いたことがあったが、たぶん、その内容とほぼ似たことなのだろう。

実際、IPAの方の講演でも、抽象的なレベルで考えることでより広く安全性を考えることができる。
部品レベルのような粒度の細かい観点で考えると、安全性を考慮すべき観点が漏れやすいから、あえて、抽象度をあげて幅広く議論するのだ、という話があったから。

【5】上記の内容は素人の考えなので、どこまで正しいのか分からない。
でも、安全性の品質に関する議論を、箱と矢印の図で行おうとする方向性を見ると、ハード設計図のレベルではなく、SysMLのようなソフトウェアのレイヤーで抽象的なレベルで設計しようとしているように思える。

この手法がどこまで通用するのか、僕は分からない。
でも、ソフトウェア開発がハード設計でも重要になってくるならば、具体的なモノがない状態で機能を設計する必要性は出てくるだろう。
すると、ソフトウェア設計のように、要件や仕様を決めていく技法やプロセスが必要になってくる。
それら技法は、たぶん今までのハードのやり方は通用しないだろう、と思う。

そして、アジャイル開発を取り入れた場合の品質保証は、どのような観点に考慮すれば効果的なのか?
そういう課題も考えてみたい。

【追記】
STAMPについての分かりやすい記事が紹介されている。

STAMP/STPAとは何か (4/4) - MONOist(モノイスト)

| | コメント (0)

より以前の記事一覧