酒の上のAI噺 #RedmineOsaka

4月に引退して暇になるかと思ったら、やりたいことが多くて結構忙しい。いやいや時間調整は自由なのだから仕事で疲れてできなかったことをもっとやろうと先月はデブサミ関西、今月はRedmine大阪に参加しました。どちらも10年ぶりの人たちとの再会もあって同窓会のようでした。

Redmine大阪の懇親会では、AIの話題で盛り上がり、初心者ですが私も持論を展開しました。興味を持っていただいた方もおられるようなので、少し整理しておきたいと思います。

話題のきっかけはtokujiroさんのLT「ＡＩとチケット駆動開発」です。

基本的なアイデア

AIのループが暴走しないように人間のレビューを入れるというお話でしたが、従来言語なのでそうなるのではないか？形式手法のような言語であれば、仕様通りのプログラムができ、検証もできるので、人間は介在しなくてよいのではないかと思います。

2つのクリーンルーム

このアイデアは、ローカルＬＬＭサーバーだと与えた情報のみで判断するので、古い情報参照による不具合が生じないと聞いた際にふと「クリーンルーム」を思い出したことからです。調べてみるとクリーンルームには2種類ありました。

1. IBM PC互換機向けにI/F仕様からＢＩＯＳを作ったクリーンルーム設計
2. IBMの超高品質ソフト開発手法であるソフトウェアクリーンルーム

元々1を調べたかったのですが、2を読んでいると、ＡＩがプロトコルから生成するものは2で使われた形式手法が良いのではないかと思いました。2の方はコストや人間の負担からかあまりはやらなかったようですが、ＡＩなら可能だろうなと思っていました。

任せられるのか

もちろんきちんと作ったのか、要件を満たして不要な機能はないのかといったことが問題になると思います。そこで、よく言われる少しできる新人ではなく、協力会社と考えてはどうかと思います。具体的にはＣＭＭ*のように成果物だけでなく、開発途中のエビデンスまで主強くさせ、それをチェックすればよいと思います。こうすれば、実施プロセスのルールとエビデンスが成果物と矛盾なく安心できるものか判定できると思います。必要な成果物にトレーサビリティマトリックスも含めれば、要件を満たし余分なものが含まれないことを確認できるでしょう。

システムテスト、検収テスト、デバッグ

とはいえ、検収テストは必要です。フィジカルＡＩが高度になるまでは、システムテストへの協力も必要でしょう。逆に検収テストの項目はＡＩに作成してもらいレビューするといった方法もありでしょう。不具合があった場合はプロンプトレベルでの修正が必要ですが、ＡＩに原因がわからない時にはデバッグも必要になります。形式手法言語から直接バイナリコードを生成する場合でも、昔のように１６進やアセンブラでデバッグする必要はなく、元になった形式手法言語やプロンプトでの表示は可能になると思っています。

人間のやることはなくなるのか？

上記のような確認はあるにしろ、UIを含めてAIが生成することが増えるでしょう。では、人間のやるクリエイティブな仕事はなくなるのかと言えば、とんがった業務の仕事は残ると思います。どこにでもあるような業務はＡＩが要件定義を含めてできるようになると思いますが、ほかにないような業務は人間の仕事として残ると思います。よりクリエイティブになれということです。
（牛尾さんの動画などを見てそう思ています。牛尾さんの本も出ているようです）

「アジャイルを飯のタネにして生きている人々」を読んで

書いている内容は興味深い点もありますが、前提に対して指摘すべきだと思いましたので、感想を書きます。

内容をざっくり書くと、先駆者はアジャイルの文献の翻訳や技術紹介、新参者への支援など、コミュニティに大きな貢献をしてきた。しかし、影響力やビジネス機会が集中しており、まるでカースト制度かねずみ講のようだ。継続的改善や自己組織化をめざすアジャイルのコミュニティとしてはおかしい。といった内容です。

勝手な印象を書くと、前半のイメージは先駆者あるいは伝道師はずるい、もっとオープンにすべきで良い仕事を回してほしい。後半は新参者は新しい分野やコミュニティを立ち上げるなどして頑張ろう。アジャイルのコミュニティにはもっと可能性があるはずだ。と書くと、うがち過ぎでしょうか。

ここで前提になっているのは、参加者が個人事業主あるいは会社の経営者もしくはその可能性のある人なのでしょう。そもそも技術中心のコミュニティを通じて、ビジネスに生かすという時点で方向性が違うように思います。勉強会などで人を集め、ビジネスの機会を得て、新しい人にも仕事の機会を与えるのなら、そういう会社か企業連合を作ればよいと思います。そうすればルールもはっきりするでしょう。また、（個人）事業主にこだわらないのであれば、アジャイル開発を導入予定の企業に入社すれば良いだけです(6/6追記)。

技術コミュニティはもっと草の根的なボランティアで、自己紹介を超えた営業活動はコミュニティの外でやるべきだと思います。お金を出すから、場所を貸すから宣伝させろという人もいます。しかし適切な切り分けをせずに、ずるずる許してしてしまうと、腹を割った議論ができなくなってしまいます。以前、コミュニティの個人的な利用が目的の人をスタッフにして大変な目にあったこともありますが、それと同じぐらい迷惑な話です(6/6修正)。協力するならコミュニティで扱う技術の発展に協力すべきであって、それ以外の理由で協力を装わないでほしい。昔から貢献しているとか、コミュニティでのポジションとは関係ないと思います。これはアジャイルとは関係なく、技術系コミュニティ一般にそうあるべきだと思います。

民主的なコミュニティで、声の大きい人が勝つのは仕方のないことです。ただ、仕事を回してほしいから反対できないというのは、そう思う人がコミュニティを悪い方向に向かわせていると思います。新参者に発表の場が与えられないなら、つぶさないようにLTをするなど提案してはどうでしょう。ほかにも色々とやり方はあると思いますし、気持ちが悪いなら抜ければよいと思います。意見が出しにくく、抜けられないのは仕事がちらつくからで、そもそもコミュニティを通じて仕事を期待するという前提が悪いのではないでしょうか？

内容的にはラブ・ボム、ダニング＝クルーガー効果、マシュー効果など知らない用語が紹介されていて勉強になりました。ただ、丁寧に概要を入れられているせいか、内容の重複が気になりました。個人的には後半が面白かったので、前半は重複部分を減らし、もっとシンプルに書いて欲しかったです。

アジャイルを飯のタネにして生きている人々

祝 #TX2D お散歩はこのコンデジと！ LUMIX DC-TX2 その２選択のポイント

液晶パネルが精細になったLUMIX DC-TX2D全機種の発売を記念して、カメラ選択のポイントと全機種のLUMIX DC-TX2をどう考えたかをまとめました（その１購入経緯はこちら）。

センサーのサイズ

大きいサイズのセンサーの方がたくさんの光を受けられますので、無理に感度を上げなくて良いのできれいな写真をとることができます。一般向けでは35ミリフィルムと同じフルサイズが大きくてきれいな写真えお撮ることができます。

逆にサイズが大きいとレンズのひずみが出やすくなるので、レンズが複雑になって高価に、重く、大きくなります（ひずみが大きいと写真の端の方で柱を撮ると曲がって映るなど見てわかるひずみが出たりします）。価格や携帯性を考えるとセンサーが小さい方が有利になります。

そこでカメラを選ぶ際は価格と携帯性のバランスを考えることになります。

私の場合、下の項目も考慮して1インチで良いと思いました。フィルムのハーフサイズだと解像度が低くなりますが、最近のデジカメはセンサーサイズが小さくても解像度は十分なことが多いです。ＴＸ２は１インチで、カメラ最重視の一部のスマホで使われるサイズです。ミラーレスよりも小さいですが一般的なスマホよりは十分大きく、写真にひずみを感じることもなく、満足しています。

レンズの焦点距離

焦点距離が短いと広角に、長いと望遠になります。フィルムカメラのころは50mmが標準、風景写真委は28か35mmの広角、ポートレートは明るくてボケ味の良い80㎜の中望遠、運動会など遠くのものは200㎜以上の望遠といった感じで紹介されていました。

一般に単焦点の方がきれいに撮れるようですが、ズームがないとトリミング（画像の切り出し）が必要になります。フィルムカメラのころにレンズメーカの200mmまでのズームを持っていましたが、2倍のテレコンバータをつけても野鳥の撮影には力不足で、トリミングをしていました。

ＴＸ２は360mmまでのズーム＋デジタルズームで大きな鳥ならトリミングしなくても迫力のある写真が撮れます。4k動画は最大450㎜で撮ることができます（焦点距離は35mmカメラ相当）。

レンズの明るさ

レンズが明るいと光をたくさん集めることができるので、星空など暗くてもきれいな写真が撮れますし、絞りを開放するとピントの範囲が狭くできますので、80mmぐらいでも風景にボケ味のあるポートレートが撮れます。レンズの明るさは焦点距離とレンズの後継の比率できまします。明るいレンズほど高額に、大きく、重くなります。

TX2のレンズは暗い方ですので、星空はあきらめています。ポートレートは少し離れて撮ることでボケ味を出すことができます。

レンズ交換が必要かどうか

レンズ交換が可能だと、お金をかければ色々なレンズを使うことができます。そこに沼の喜びがあると思います。写真誌に載っているような写真は、腕だけじゃなく機材もあると思います。

TX2はレンズ交換の楽しみはありませんが、交換しなくても良いメリットがあります。埃っぽい時もレンズ交換をせずに、少々の雨なら傘を差すだけで広角から超望遠まで色々な写真を撮ることができます。

持ち運びやすさ

写真を撮りに出かけるなら少々重くても、かさ張っても気合を入れられるのですが、散歩に持ち歩くなら邪魔にならない大きさ重さでないとつらいです。

TX2は電源を切ればウェストポーチ型のカメラケースに入りますので、買い物に出かけた際のちょっとした風景も逃すことなく撮ることができます。良い写真を撮るには機材も大切ですが、チャンスを逃さないことも重要ですので、広角から超望遠をいつも持ち歩けるのはありがたいです。

価格

9万円以下で買えます。安いミラーレスならズームレンズ付きで10万円からありますが、超望遠や明るいレンズをそろえるとレンズだけで20万円するものも多いようです。

TX2の値段なら、コロナでのみに行けなくなってたまっている小遣いで買えてしまいました。たまには贅沢をしようと思っていましたが、機会を逃しました。

その他

液晶パネルが固定なので自撮りができませんが、スマホで良いと思っています（鏡をつけるテクニックはあるようです）。ローアングルも撮りにくいですが、視野角が広いのであまり苦労はしていません。あと、フィルタがつけられない。アクセサリシューがない。といった弱点は割り切りました。

（使用感に続く。たぶん）

祝 #TX2D お散歩はこのコンデジと！ LUMIX DC-TX2 その１購入経緯

LUMIX DC-TX2を買って約半年、コンデジの開発停止ニュース（スラド）が流れて、壊れても買い替えできないかと心配していましたが、TX2の後継機種TX2Dが出ました（パナソニック、「LUMIX G99」「LUMIX TX2」の背面モニターを変更）。買って半年なので悔しい思いもありますが、部材の関係なのでしょうがないですし、なによりコンデジが終わらないことの方がうれしいです。半年ほど使って、お散歩やちょっとしたお出かけにいつも持ち歩きたい！一台だからです。

このカメラを買としたきっかけは早起きした朝のことです。近所の川を散歩をしていたら、朝焼けと野鳥がきれいででした。思わずスマホで撮影してInstagramを始めました。お散歩しながら写真を撮り始めると、楽しくてどんどん撮りためるようになりました。最近のスマホのカメラはよくできていて、とてもきれいに撮れました。しかし、学生の頃にフィルム一眼レフを使っていた経験から、ついついマクロがあればなぁ、もう少し光学の望遠があれば、と思いました。そして写真のコントラストが強くてなんだか薄っぺらに感じるようになりました。

じゃあデジカメを買おうかと思い、調べてみるとコンデジは最近新製品が出ておらず、スマホと同じイメージセンサを使った３万円台のものが売れ筋になっています。マクロと望遠は満足できるものもあるのですが、イメージセンサのサイズがスマホと同じだとちょっと残念です。センサが大きいと光をたくさん受けることができるので、よりきれいに撮れるからです（最近はスマホのセンサも大型化が進んできました）。

もう一つの売れ筋のミラーレスや一眼レフを見ると、１０万円前後からズームレンズが１本あるいは２本ついた入門機があります。確かにお買い得ではありますが、サイズが大きくなってしまいます。ミラーレスの沼にはまると、きっと全域でF2.0とかF2.8の明るい中望遠ズームレンズとか、そのうちに300ミリ以上の超望遠レンズが欲しくなりそうです。マニアックで楽しそうな世界ですが、どんどんかさばって散歩の邪魔になりそうです（もちろん、写真を目的に出かけるなら良いのですが、偶然出会う絶景のために大きなカバンは持ち歩けません。コンパクトであることの良さはこの記事（私はこれを買いました！：現在最高のポケッタブル記者カメラ）でよくわかります）。

散歩中に手軽に鳥、草花、風景、夕日、できれば月も撮りたいと考えると、いまさらながらコンデジになってしまいます。レンズの明るさやチルト可動式液晶などDSC-RX100M6にかなり惹かれました。しかし、野鳥を撮ると考えると経験上200ミリでは足りません。かつて学生の頃は重い200ミリの望遠ズームにテレコンバータをつけていましたが、それでも近寄れなくてあまり大きく撮れませんでした。デジタルズームを使うにしてももうちょっとです。そこでレンズが暗い点や自撮りをあきらめて、24-360ミリ相当のレンズを持つLUMIX DC-TX2を選びました。

ベルトのポーチにTX2を入れ出かけた際の写真をインスタグラム（鳥、草花、日の出、夕日など）に載せています（最近のもの）。写真の修正はトリミングと回転のみで（トリミングは記載しています）、基本的にiAオートで撮っています。ご笑覧ください。

（選択のポイントに続く）

One fact in one placeとチケット駆動開発 - Software Processes are Software, Too -

プロセスプログラミングを提唱したオスターワイル(Leon J. Osterweil)氏のことば

　　“Software Processes are Software, Too”
　(ソフトウェアプロセスもソフトウェアである)

をヒントに、開発とマネージメントの共通点として、今回は「One fact in one place」と「チケット駆動開発」を考えてみます。開発者からマネージメントをするようになった方には経験を生かした管理を、管理をされている方には技術的な裏付けを知る機会になれば幸いです。

One fact in one place

データベースの正規化で使われる言葉です。ほかのデータから算出できる推移従属のデータを除いて、データを1か所に限定することです。同じデータは1か所にしかないので、常に一貫性のあるデータ集合を求められるようにします。他のテーブルと関連付ける場合もデータベースの機能を使えば、矛盾の生じない構造を実現しつつ多くの情報を管理することができます。

チケット駆動開発

チケットで障害やタスクを管理するRedmineやTracなどを用いて、情報共有しつつ開発を進めていく方法です。これらのツールはITS(Issue Tracking System) あるいじはチケットシステムと呼ばれ、チケットを介して議論やステータスの管理ができます。プロジェクトの様々な情報をこのチケットに紐づけて管理すれば、最新の状況をチーム内で共有できます。

チケット駆動開発をうまく実践するには、チケットで情報を一元管理することです。ITS本来の使い方である障害や課題だけでなくタスクもチケットで管理し、バージョン管理ツールやWikiの情報もチケットと関連付けます。こうすることでプロジェクトの様々な情報をチケットと紐づけて管理できます。

何らかの理由で表計算ツールなど他の形式にする場合も、チケットから生成すれば情報の一貫性が保てます。とはいっても情報の粒度や目的などで自動生成できない時もあるでしょう。そのような場合も一から作成するのでなく、チケットの情報を確認しながら作成する、関連するチケット番号を記載するなどで、情報間の矛盾を減らし、正確で詳しい資料を作ることができるでしょう。

このような考え方はチケット駆動開発だけではありません。開発ドキュメントは工程間で抜け漏れなくトレースできないといけませんし、お客様への説明も一貫性がないといけません。アジャイル開発のストーリーカードとタスクカードの関係も同じでしょう。チケットシステムを利用しなくても、情報を小さな単位で整理して矛盾が生じないようにしましょう。

この記事はSRAアドベントカレンダーでも公開しています。

マルチスレッド処理と進捗管理・配員・作業分割/割り当て- Software Processes are Software, Too -

プロセスプログラミングを提唱したオスターワイル(Leon J. Osterweil)氏のことば

　“Software Processes are Software, Too”
　(ソフトウェアプロセスもソフトウェアである)

をヒントに、開発とマネージメントの共通点として、今回は「カプセル化」と「組織パターン」を考えてみます。開発者からマネージメントをするようになった方には経験を生かした管理を、管理をされている方には技術的な裏付けを知る機会になれば幸いです

マルチスレッド処理

複雑な問題を短時間で処理する方法の一つです。複数のスレッドを用いて並列処理すれば効率的です。シングルスレッドの処理をマルチスレッドで処理する場合、以下のような順になるでしょう。

1. 並列処理の準備
2. スレッド開始処理
3. スレッドの主処理
4. スレッド終了処理
5. 並列処理の後処理

これらはマルチスレッドを考慮して設計します。うまく設計できればスレッド数に応じて効率化されますが、うまく設計できないで主処理以外のオーバーヘッドが多い場合はスレッドが増えても効率化できません。特にすべてのスレッドの完了を待つ場合は最も遅い処理に全体が引きずられるでしょう。

進捗管理・配員・作業分割/割り当て

並列処理の簡単な例は進捗管理です。リーダーが各メンバーから順にヒアリングするには多くの時間が必要ですが、メンバーそれぞれが進捗を報告すれば短時間で終わるでしょう。しかし、各メンバーがバラバラな形式で好きなタイミングで報告するなら、内容の把握や確認でかえって時間がかかるかもしれません。手分けする準備として情報共有の仕組みを用意しておけば、メンバーの処理が標準化でき、その管理や集約も容易になるでしょう。

配員の場合はさらに工夫が必要です。進捗や成果物の共有環境を用意するのはもちろんのこと、メンバーが独立に同程度の品質を保てるようにします。具体的には横展開できるように先行して部分開発してサンプルを用意します。サンプルは成果物だけでなく、部分開発を踏まえたルールや手順などを用意して、サンプルをたたき台に作業を横展開できるようにします。

作業の分割にも工夫が必要です。作業量を平準化しやすいように時間のかかる作業は細かな作業に分割します。また、マイルストーンに合わせないといけない作業とそれ以外を分けておき、予定通りに進まないときに作業の空きがないように工夫します。

作業の割り当てにも工夫が必要です。作業者の得意な作業を割り当てれば一見、効率的ですが、作業には偏りがあるので、作業量がバラツキが出て手が空いてしまったり、誰かが体調を壊すとプロジェクト全体が止まってしまうことになります。このようなことを防ぐには、教育的な視点で作業を割り当てたり、処理の実装とテストで担当者を分ける、ペア/モブプログラミング（作業）などを長期的な視点で取り入れると良いでしょう。

この記事はSRAアドベントカレンダーでも公開しています。

カプセル化と組織パターン - Software Processes are Software, Too -

プロセスプログラミングを提唱したオスターワイル(Leon J. Osterweil)氏のことば

　“Software Processes are Software, Too”
　(ソフトウェアプロセスもソフトウェアである)

をヒントに、開発とマネージメントの共通点として、今回は「カプセル化」と「組織パターン」を考えてみます。開発者からマネージメントをするようになった方には経験を生かした管理を、管理をされている方には技術的な裏付けを知る機会になれば幸いです
。

カプセル化

カプセル化(リンク先はwikipedia)は情報隠蔽の手法で、オブジェクト指向にも取り入れられています。カプセル化することで外部には必要な情報のみが公開され、内部のデータや処理は守られます。オブジェクト指向において、外部からはメソッドを介してのみ情報を得ることができます。

オブジェクト間で連携するには、呼び出しとデータストア共有の2つの方法があります。呼び出しは責務を果たしてくれるオブジェクトのインタフェースを定めてその参照を知って知っていることで、オブジェクトに対して定められた方法で呼び出すことで、オブジェクト間で連携できます。データストア共有ではデータベースのようなデータストアを介する方法です。データ構造をあらかじめ決めておいて、オブジェクト間でデータの参照や更新を行います。

組織パターン

組織パターンは，開発チームをどう編成すればいいのかをパターンとして整理したものです。組織パターンはアジャイル開発のひとつであるスクラム開発にも取り入れられていて、プロダクトオーナーとスクラムマスターは、それぞれ門番、防火壁に相当します。チームへのインタフェースを限定し、外部からチームを守ります。チームをカプセル化するわけです。アジャイル開発に限らず、チームを外部から守り、必要な情報を提供できれば、チームは外部のストレスを受けないで開発に集中できます。また依頼すべき役割を担うチームを知り、適切な方法でアクセスすることでチーム間の連携ができます。

データストアによる情報共有はその方法によってメリット・デメリットがあります。

• タスクカード：壁やホワイトボードに張り出すことでチームの状況を見える化します。無意識に目に入るので常にゴールを共有できます。その反面、色分けなどで工夫しないと管理や検索が難しいので電子化されることも増えています。
• チケット：RedmineやGitHUBなどのチケット（イシュー）を使ってタスクを管理します。優先順序などそのままでは扱いにくいので、タスクカード風のUIをもつJIRAやプラグインが使われることもあります。
• 資料：チーム内で資料を共有します。いつでも再確認ができる反面、資料の質がコミュニケーションの質になります。
• ミーティング：もっともアナログな情報共有です。音声による情報共有はニュアンスなど情報量鵜が多いので、チケットや資料などの共有と併せて実施されます。人数や時間によって工数がかかります。

システム開発と同じように、どのようにチーム間あるいはチーム内で連携するかで、成否が決まります。ウォータフォールや味あるなど既存のプロセスを利用するとある程度の品質は得られますが、そのプロセスのメリット・デメリットを把握していないと効率的な開発は行えないでしょう。

この記事はSRAアドベントカレンダーでも公開しています。

Greedy algorithmと2割8割の法則 - Software Processes are Software, Too -

プロセスプログラミングを提唱したオスターワイル(Leon J. Osterweil)氏のことば
　“Software Processes are Software, Too”
　(ソフトウェアプロセスもソフトウェアである)
をヒントに、開発とマネージメントの共通点として、今回は「Greedy algorith」と「2割8割の法則」を考えてみます。開発者からマネージメントをするようになった方には経験を生かした管理を、管理をされている方には技術的な裏付けを知る機会になれば幸いです。

greedy algorithm

世の中には簡単な問題と難しい問題があり、例えば並べ替えするときに単純に2重ループするとデータ数Nが増えるとその2乗（N^2）ほど時間がかかりますが、処理を工夫して木構造にデータを並べておけばその木の高さ（logN）で処理が済みます（実装者のための計算量のはなし - O(logN)などをわかり易く説明しました -）。

これに対してナップザックにいろいろな大きさの荷物を入れるような問題は、NP困難と呼ばれる難しい問題です。すべての組み合わせを確認しないと隙間を最も少なくできないからです。そこで Greedy algorithmという手法がとられます。これは隙間の少ない（価値のある）大きなものから貪欲に詰めていく方法です。最適ではないですが、ほどほどにうまく詰める方法です。

プロジェクト管理においても最適な計画を立てることは簡単ではありません。そこで、大事な作業や後回しにすると問題になる作業から実行あるいは計画すると、ほどほどに良い計画を作ることができます。アジャイル開発のやり方はまさにこのような方法です。計画駆動な開発ならこの方法でできた計画をたたき台に、より最適な計画を作成することができるでしょう。

＃初期のスクラムガイドは優先順序だけで実行時順序を決めていたので、リスクの考慮が乏しいものでしたが、その後見直されたようですね。

閑話休題。プロジェクトの実行や計画には様々な要素があって簡単ではありません。まずはどの作業が価値があるか、すなわち重要あるいは後回しにできないかをまずは見極めてそれに基づいて計画しましょう。

もちろん、そもそものソフト性能にも利用できます。ソフトウェアの処理データが増えることで処理が遅くなるような場合に、網羅的で単純な繰り返し処理になっていないか、調査してみてください。

2割8割の法則

網羅的に実施しない場合に重要なものから実施するとどのような効果があるのでしょう。2割8割の法則はパレートの法則とも呼ばれ、度数順に要素を並べるパレート図を描くと、一般に上位2割が8割を占めているという法則です。

この法則に基づくと、アプリケーションの価値のある2割の機能を実現するだけで8割の価値があり、残りの8割の機能はあまり価値がないということになります。アジャイル開発では価値のあるものから開発し、随時リリースすることで価値の少ない8割の開発よりもリリース後の外界の変化に対応することを選んでいると考えられます。

2割8割の法則は障害の対応や改善において用いられています。分析して障害の量や質が問題になる上位2割の障害対策を行えば、より効果が得られるでしょう。

プロジェクトを進化させる

プロジェクトは日々変化します。プロジェクトもそのままではうまくいかず、常に変え続けないといけません。ソフトウェア開発ではリソースが潤沢ではない場合が多いので、孫氏の兵法に示されるようにパワーを分散せずにポイントを絞って攻めるとうまくいくでしょう。

グリーディアルゴリズムや2割8割の法則も同じようにポイントを絞る方法で、大事なことを見極め、優先順位をつけるという特徴があります。これらを生かせば、プロジェクトを変え続けてより効果的に進化させることができるでしょう。

参考：
（[#agileto2012] 『チェンジ！』の考え方 ～マネしやんと！～）

「任せて、任せず」「魚を与えるのではなく"釣り"を教えよ」

松下幸之助氏の言葉です。

パナソニック新社長が「過去」を研究し続ける真意 停滞続く巨艦が松下時代から失ったものは何か
http://a.msn.com/01/ja-jp/AAMFYBp?ocid=st 

この記事によると

「仕事は部下に任せていても、経営者は常に事業を見て、必要なときには指示をする。事細かに指示せず、自主責任を求める」

とあります。事細かに指導していては成長しない。任せるべきは任せ、ここぞというときに「過ちすな。心して降りよ。」と高名の木登りのように指示をするのでしょう。

この「任せて、任せず」は結構難しいと思います。前提として以下の3つがあります。

• 任せられる人であること：わかっていない人には任せられません
• 任せた人の弱点を知っていること：どのような失敗をしそうか知らないと事細かに言ってしまいそうです
• 任せた作業のポイントがわかっていること：どのような作業かわかっていないことを丸投げしてはここぞという指示ができません

これらを満たすには、教育（育てること）がポイントだと思います。実現可能性が検討できているなら、たぶん3番目はできているのでしょうから、任せたい人を任せられる人に育てることでしょう。育てる中で2番目はわかると思います。

では、育てるにはどうすれば良いかというと、思い浮かぶのは「魚を与えるのではなく釣り方を教えよ」です。答えを教えるのでなく、答えを導く方法を教えることです。

それで良いと思っていたのですが、検索してみると

 ”魚を与えるのではなく釣り方を教えよ”じゃダメだと思う。 

https://toksato.hatenablog.com/entry/2010/03/24/123936

という記事にあたりました。「楽しさや意義という土台から、テクニックまで。『釣りとはなんぞや』を教えることが、大切」とのこと。ソフトウェア開発のいろいろな技術だけでなく、そもそも会社がどう成り立っていて周りから何を期待されているか、自分の人生においてソフトウェア開発をなぜするのか、輝いている先輩の原動力は何か、これらがわかっていないとこなすことだけになり、やがて仕事が辛くなるでしょう。

人生について教えることはむずかしいですが、モノづくりの楽しさや、人の役に立つ喜びを感じてもらうことが、任せられる人への第一歩かなぁ。などと思いました。

Tweet

メールやチャットでも役立つテクニック

「開発現場で役立つ論文の書き方のお話」の前半を社内向けにした際のおまけです。
似たようなテクニックはこれ以外にも色々あると思います。整理できていない内容を口頭で説明する場合は「とりあえず最後まで聞いてもらえますか？」という方法もありますね。

メールやチャットでも役立つテクニック from Makoto SAKAI

Tweet