野狐消暇録

所感を記す

『漢文入門』(魚返善雄著)を読んだ。

漢文には関心があり、漢文の読み方も、高校生のとき、少し習った。しかし、この本を読み、知らなったことをいくつも新たに知った。

■ 漢文は暗号

漢文は、中国人の自然な会話を書き取ったものではない。漢文は文章語である。昔は字を彫っていたので、語を節約するように努めている。そのため、中国人であっても、簡単に読めるわけではない。

■ 主題語と説明語

漢文の先頭に来る語は主題であることが多い。その主題を続く語で説明する。主語、術語、目的語という英語の文法を漢文に当てはめて理解しようとしてもうまくいかない。

■ 漢文は孤立語

漢文には「てにをは」がない。また、英語にみられるような語尾変化もない。石ころがゴロゴロ並んでいるような具合である。そのため、文章の意味がひとつに定まらないことがある。

著者の理解で関心したのは、「中国人の考え方にとって自然なことは何か」ということを含めて漢文を解釈しようとしていることである。漢文では、主要なことをまず挙げ、続いてその主題を後段で説明するようになっているらしい。著者はそういう、文章を書く者の発想、思想を捉えて文章を読もうとしている。これは本当に理解するという営みであろう。

著者の本を他にも読んでみたいが、電子化されているものは少なそうなので、図書館で借りて読もうかと思う。

2019/05/27

  • マイペースということは、周りの影響を受けずに自分のペースで歩むことを指すが、否定的に言われることもある。しかし、自分のペースで歩むことは望ましいことだ。
  • 形に囚われず、なすべきことをなすべきだ。学校に行っていないから、あるポジションに自分がいないから、そういうことは皆くだらない囚われなのだ。なすべきことをなすことが大切だ。今できることは常にあるのに、それがみえなくなってしまうようではダメだ。
  • 「持ち物」を気にしすぎてはダメだ。持ち物はお金のときもあるし、健康のときもある。家族かもしれない。持ち物ばかり気にしていては何もできない。気にしないことだ。

観覧車

観覧車に乗ったら、ロマンチックな気持ちになるのではないか、と妻は考えていたそうである。実のところ、自分もロマンチックとまではいかないでも、観覧車は楽しい乗り物だと思っていた。

f:id:nogitsune413:20190406184243j:plain

横浜コスモワールドの大観覧車「コスモクロック21

それがどうだろうか、乗ってみてすぐに怖くなった。何しろ、観覧車の人が乗る部分は、上から吊られているのである。これが怖い。足の下には何の支えもないのだ。妻も怖くなったようで、設置されていたタブレット端末を触って、「これを見ていれば怖くないはず。これを見よう」と、早くも怖さを紛らわせる方法を探してきた。

それでちょっとタブレットを触ったのだが、せっかく乗ったのに勿体ないという気がして、景色を眺めてみた。実際、観覧車というのは、中で何もすることがなくて、外の景色でも見るしかないのだ。しかし、ずっと怖い。

f:id:nogitsune413:20190406191141j:plain

眼下の景色を眺める。

やっと下に降りてくると、心からほっとした。こんなに観覧車が怖いとは思わなかった。妻は「二度と乗らない」と云った。僕も賛成だ。もう乗らなくていいだろう。

こんな怖い乗り物にわざわざお金を払って乗るなんて、どうにも意味が分からないことである。

細かくて予想できないタスクを管理する - 社内SEのタスクマネジメント -

これはドラフトである。まだまとまっていないが、書きながら整理していきたい。

状況

  • 0.5人日~3人日程度の規模の小さなタスクが多い。
  • 定例作業があり、0.5H~4H程度かかる。
  • 納品日や作業期日は厳しくなく、ずらす事ができる。ただし、時々、外部システム連携などで期日がずらせないタスクがある。
  • 開発人員は2人~3人と少数体制。

管理の目標

  • 期日のあるタスクの場合、期日にタスクが終わっていること。
  • 生産性を上げること。

管理方法

タスク一覧表で管理する。

f:id:nogitsune413:20190331002838p:plain

タスク一覧

■ 説明

まず、割り込み案件が多いため、スケジュールを引いてもあまり意味がない。しかし、期日があるタスクはあるし、タスクに前後関係があるケースもある。そのため、クリティカルパスを見る必要はある。また、人の数よりタスクの数の方が多いが、タスクを処理しきれるだけの人員リソースが割り当てられる事はない。人の手が空くと人件費が無駄になるためである。そのため、タスクが待ち行列のように作業員の前に溜まっていくことになる。

人を増やす事はできないので、コントロールできるのは以下である。

  • タスクの着手順
  • リリース分割などの作業分割

作業が期日に間に合うかを判定するには、作業の工数を見積もる必要があるので、各タスクの最小工数と最大工数を計上する。工数が見えないタスクは要注意タスクなので、早めに着手し、見通しが立つところまで作業を進める。これはそもそも要件が出たばかりで、必要な工数の見積もりが出せない案件も同様である。案件が浮かんできた状態で放っておいてはいけない。

見積もりを出すと目標としているリリース日に間に合うかどうか大体見通しが立つが、どこまで他の案件をシャットアウトして良いかが次の問題として出てくる。割り込み案件を無視してはいけないが、既に上がっている案件が期日に間に合わなくてもいけない。基本的には期日のあるタスクを優先しながら、割り込み案件にも適宜応えていく事になる。当然の事ではあるが、全てそのタスクに時間を割けるつもりでスケジュールを組んではいけない。日の半分の時間は、定例作業や問い合わせ対応に当てられる事を見込む必要がある。具体的には、7.5Hのタスクがあったら、スケジュール時間で2~4日程度で完了するということである。2日は特別に作業がなかった場合で、4日は障害対応などが発生して普段より割り込み案件が多く、ほとんど作業に手が出せなかったケースである。もちろん、これより遅れる事も考えられる。7.5Hのタスクが1日で終わる事はない。

リカバリ

タスクが処理しきれず、期日を超過しそうになったらどうするか? これといったアイデアが今のところない。今のところ、残業したり、休日に出勤したりしている。障害対応で追われるとこれになる。

ボトルネック

自分がある程度進めて、新しく入った開発者Aに仕事を渡すようにしていたら、自分がボトルネックになっていたことがあった。それで、要求のヒアリング、調査、障害対応など、非定型案件を自分が中心に処理し、定型的な案件をAに渡す事にした。

定型的な案件が本当に定型的であれば、システム化できるはずなので、効果の大きいところを見極めて、順次システム化したい。これも効率化になる。古典的な機械化による効率化であるといって良いだろう。

お茶請けの工夫

中国の山東省に崂山(ろうざん)という山があるそうで、その崂山で採れるお茶を崂山茶と云い、青島市の名産になっている。妻の故郷である青島市に訪ねていった帰り、崂山茶をお土産に貰い、日本の神奈川で飲むようになった。崂山茶は釜炒り茶と云い、通常のお茶が加熱のために蒸すのと異なり、釜で炒って加熱するとのことである。それで葉っぱを見ると、丸く捩れていて、普段見る緑茶の葉っぱと違う。緑茶と紅茶をそれぞれお土産で貰ったのだが、緑茶の方は飲み切ってしまい、余った紅茶を大切に飲んでいる。なぜ紅茶が余ったかと言えば、話は青島の義弟の処に宿泊していた頃に遡る。

f:id:nogitsune413:20190323195506j:plain
f:id:nogitsune413:20190323195549j:plain
大切に飲んでいる崂山紅茶。水筒に入れて妻が職場に持っていくので、最近減りが早い。右はお茶を淹れた後の茶葉。葉っぱが捻じれているのが釜炒り茶の特徴。

リビングで家族一緒にテレビを見ているとき、たまたま淹れてくれた紅茶がとても美味しく、これは美味しいねと妻に言っていたら、お土産にくれる事になったのである。僕が最初に美味しいと云ったのが、紅茶だったから、紅茶を多めにお土産に持たせてくれたのだ。

さて、紅茶を飲むのはいいのだが、中国のお茶というのは、比較的味がしっかりしているようで、烏龍茶なども味があって香りがしっかりしていると思うが、崂山紅茶もまたそうである。日本人である僕には、それがちょっと濃過ぎるように思うので、かなり薄めに紅茶を淹れる。なんだったら、五番煎じぐらいまで紅茶を飲めるのも、薄い紅茶が好きだからであり、また最初に淹れる崂山紅茶がそれだけ濃いからでもある。

そうやって紅茶を飲んでいると、何かつまみが欲しくなる。所謂、お茶請けである。

このお茶請けについてだが、最初は甘いものを食べていた。場合によっては、木の実入りの月餅であり、シュークリームであった。お抹茶のときの和菓子の感覚で、紅茶のお菓子を合わせていたのである。

しかし、飲んでいてどうも違うな、と思った。それは、お菓子が強い、つまり、お菓子が主役になって、お茶がお菓子の引き立て役になってしまっていると思ったのである。極端な例を挙げると、ショートケーキと紅茶が出てきたら、ショートケーキが中心になってしまうのは明らかである。お菓子が食べたいならそれで良い訳なのだが、自分はどちらかというと、お茶をメインに味わいたいのである。さて、どうしたら良いか。自分はこの問題に解決策を見出そうと試み、自分なりの回答を得た。

それは、お菓子の分量を減らすということである。お抹茶に当てる主菓子で云うと、あれを菓子切りで半分に切ったぐらいの大きさでちょうどいいのではないか? チョコレートなら、二かけらぐらいで良さそうだ。

とりあえず、すぐに手に入るチョコレートで試してみた。

f:id:nogitsune413:20190126195742j:plain

チョコレート2かけらとたっぷりの紅茶

 見た目はちょっと寂しいものの、薄いお茶との組み合わせとしては、ちょうど良い塩梅である。自分はこの発見を世界に発信せねばと思い、このブログを書いた。お試し頂ければ幸いである。

要件を整理することでシステムの品質を上げる。

ソフトウェア要求をヒアリングしていくと、要求を出した人達が何をしたいのかが分かってくる。要求を良く理解する事で、システム要件が整理でき、結果としてシステムの品質を上げられる。以下に成功例と失敗例を挙げる。

【成功事例】チラシ同梱機能の修正①

商品発送時に宣伝チラシを同梱するシステムを改修する事になった。最初にヒアリングしたとき、顧客が出してきたシステム要件は以下であった。

■ 最初のシステム要件

チラシA、B、CをまとめてチラシXにしたので、システムもそれに合わせて修正してほしい。

■ 修正前のシステム

調べてみると、システムは以下の状況であった。

〇 商品ごとに同梱するチラシを決めて同梱を行う。

  • 商品A → チラシA
  • 商品B → チラシB
  • 商品C → チラシC

これを顧客の出してきた要件そのままに修正した場合、おそらく以下になるだろう。

■ 修正後のシステム(案1)

  • 商品A → チラシX
  • 商品B → チラシX
  • 商品C → チラシX

■ 整理後のシステム要件

しかし、もうちょっと要求を掘り下げてみると、システム要件を整理できる事が分かった。整理した後のシステム要件は以下である。

  • 定期お届け商品発送時にチラシXを同梱する。

商品A,B,Cは全て定期お届け商品であり、それらの商品の発送時に同梱するチラシをチラシXに統一した、という事であった。

■ 修正後のシステム(案2)

整理後のシステム要件に従えば、そもそも商品ごとに入れるチラシではなく、定期お届け商品に入れるチラシという事になるので、システムの改修は以下になるだろう。

  • 定期お届け商品(商品A,商品B,商品C, …) → チラシX

案1と比較したとき、この方式には以下の利点がある。

  • 商品ではなく、定期お届け商品という商品カテゴリにチラシが紐付いている事が明確になる。
  • 今後新しい商品が販売されても、カテゴリだけ決めれば自動的にチラシの同梱要否が決定されるため、変更に強い。
  • チラシを同梱するべきか否かの判定ロジックが一か所にまとまるので、システムがシンプルになり、改修にかかる工数を削減できる。

■ まとめ

顧客の要求をヒアリングする中で、システム要件を整理でき、案2にたどり着いた。案2の一番良い点は、顧客の要求をそのまま実装している点である。

【失敗事例】チラシ同梱機能の修正②

これは焦って実装して失敗した例である。

■ システム要件

定期お届け商品をお届けするにあたり、3回発送するごとに他の商品を紹介するチラシを同梱してほしい。

■ 修正前のシステム

定期お届け商品の発送回数を指定して、チラシを同梱する機能があった。

■ 修正後のシステム

発送回数指定のチラシ同梱機能に、今回向けの指定を追加する事にした。

追加する指定回数は以下である。

・3,6,9,12,15

こうする事で5回は同梱できる。5回以上の定期発送が発生したら、またデータ指定を追加する。

■ この修正のデメリット

  • システム要件と実装があっていない。「3回ごと」というシステム要件を実装するのは容易であるにも関わらず、「指定回数でチラシを同梱する」という別の機能を使っているため、一々データを正しく設定しなければならなくなっている。これでは手間がかかり、間違いが起きる可能性も高くなる。それはまた、保守要員の作業が増える事でもあるので、人件費という形で費用もかかる。
  • 修正後の同梱仕様を画面で確認すると、指定した回数が画面上に羅列され、「3回ごとに同梱する」という設定になっているのか確認できない。3回ごとなのかどうか、自分で数えて判断する必要がある。

■ なぜ失敗したか

顧客の要求をシステム上で表現できていない事が失敗の原因である。システム要件を実現するために別の機能を代用したため、手間がかかり、かつ分かりにくいシステムになってしまった。

幸い、このシステムを修正する事は容易であり、単に指定回数ごとにチラシを同梱する機能を追加してやれば良い。

【全体のまとめ】

システム要件を整理する事が根本的なリファクタリングになる。

システムが複雑になっている要因を以下のふたつに分けて考えてみる。

1. システム要件自体の複雑性

上記の例のように、システム要件を整理する。これはシステム要件のリファクタリングであると言っても良いと思う。

 2. ソースコードが整理されていない

システム要件を素直に表現したコードにしていくのが大切であると思う。後はいわゆるコードリファクタリングであるが、この記事の目的ではないから省略する。

作業をまとめて実施することで、ソフトウェア開発の効率を上げる。

ソフトウェア開発を進めるに当たり、開発時のコントロールによってある程度開発効率を上げる事ができる。結論を先に書くと、開発効率を上げるには、作業をなるべくまとめて実施する。これから書く例は、2,3人で回す小規模な開発案件を念頭に置いている。

開発効率を落とす事柄

まず、開発効率が落ちる例を挙げる。これらは作業を分けて実施する事により、効率が落ちる例である。

■作業の分担

開発作業を一人で担当した場合、開発チーム内のコミュニケーションコストはゼロである。一人しか要員がいなければ、当然そうなる。しかし、要員が二人、三人と増えると、コミュニケーションコストも要員の増加に従って増える。これを規模の不経済と言う。この不経済を防ぐには、ひとつの案件に対する担当人数を可能な範囲で少なくすると良い。従って、一人で担当できる案件を二人に分割してはならない。ただし、他人にレビューしてもらったり、追加でテストしてもらう事で品質が上がる事がある。そうした活動が品質改善に役立つ場合、それは良いと思う。自分がここで考えているのは、途中で他の人に案件を渡したりするケースである。これは無駄なコストが発生するから、こうしたケースが起きないようにしなければならない。

■リリースの分割

開発が納期に間に合わなくなり、リリースを分割する事が良くある。一次リリース、二次リリースに分割してリリースするのだ。これが非効率的である事については、スティーブ・マコネルの『ソフトウェア見積もり』にも書いてある。リリースを分割すると、後で捨てることになる暫定版を作る工数がかかる。更に暫定版にバグが出れば、そのバグを直す工数もかかる。これはリリースが一回であれば、不要だった工数である。そのため、急いで作る必要があるときにリリースを分割するのは有効な方策であるが、開発効率は落ちるため、リリース分割をしなくて済むのが最善である。そのためには納期に間に合う必要があり、余裕を持ったスケジューリングが必要になる。

開発効率を上げる事柄

これらは作業をまとめて実施することにより、効率を上げる例である。

■ 案件に関わる箇所をリファクタリングする

リファクタリングを案件の対応作業と一緒に実施すると、影響調査とテストが一度で済むため、修正作業とリファクタリングをそれぞれ単独で実施した場合よりもコストが下がる。そのため、リファクタリングが必要な箇所を予めリストアップし、気付いたらリストに追記するようにしておくと良い。こうすることで、何かで修正作業が発生したとき、修正対象機能の周りでリファクタリングする箇所があるかどうか、調べる事ができる。

■ 担当案件に関わる箇所をドキュメントにまとめる

プログラミングでは、細かい仕様やソースコードの構成など、その場では理解しているものの、しばらく経つとすっかり忘れてしまうような事柄がある。時間を経てから作業を再開しようとすると、同じ疑問についてもう一度調べたり、一度依頼主から聞いたことを再度確認する必要が出てきたりして、非効率である。そのため、ある案件で理解した設計仕様や要件などは、なるべくドキュメントにしてまとめておくと良い。

開発効率に関するまとめ

一言でまとめれば、「なるべくまとめて作業をする」ということである。

  • リリース分割や作業分担は、作業を分割する事で効率を下げる。
  • リファクタリングやドキュメント作成を案件対応と一緒に実施する事は、作業をまとめる事で効率を上げる。

これらを実施するには、作業期限に余裕がある事が重要である。

逆に言えば、期限に余裕がある場合は、上記を実施する。